Gigabyte GA-J1900N-D3V-1.x data

[Matt Taggart]

Hi coreboot and flashrom,

I recently got a Gigabyte GA-J1900N-D3V-1.x board. This board is 
interesting to me because A) it's Bay Trail, B) it's got dual NICs and real 
serial ports, and C) it's inexpensive. I followed the guide at

http://www.coreboot.org/Motherboard_Porting_Guide

I put the logs and a README with more info at

http://lackof.org/taggart/hacking/coreboot/GA-J1900N-D3V-1.x/

(and a tarball of that dir in the parent dir)

The flashrom output is from SVN trunk as of today to ensure latest chip 
support.
In particular flashrom reports untested:

Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c.
  Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI).

I haven't yet attempted anything beyond that. I don't yet have an off-board 
way to flash the chips, I'm hoping to order something soon.
If you have ideas of other things to try please let me know.

Thanks,

[Stefan Tauner]

On Mon, 15 Dec 2014 16:24:36 -0800
Matt Taggart  wrote:
> Hi coreboot and flashrom,
>
> I recently got a Gigabyte GA-J1900N-D3V-1.x board. This board is 
> interesting to me because A) it's Bay Trail, B) it's got dual NICs and real 
> serial ports, and C) it's inexpensive. I followed the guide at
>
> http://www.coreboot.org/Motherboard_Porting_Guide
>
> I put the logs and a README with more info at
>
> http://lackof.org/taggart/hacking/coreboot/GA-J1900N-D3V-1.x/
>
> (and a tarball of that dir in the parent dir)
>
> The flashrom output is from SVN trunk as of today to ensure latest chip 
> support.
> In particular flashrom reports untested:
>
> Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c.
>   Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI).
>
> I haven't yet attempted anything beyond that. I don't yet have an off-board 
> way to flash the chips, I'm hoping to order something soon.
> If you have ideas of other things to try please let me know.

Hi Matt,

thanks for you report. The flash chip is marked as untested... have you
verified visually that the actual chip on the board is either a
MX25U6435E or MX25U6435F, and if the read data seems legit? That would
be interesting for flashrom's database. Apart from that I see no
obvious problems with that board from flashrom's perspective.

[Matt Taggart]

Stefan Tauner writes:
> thanks for you report. The flash chip is marked as untested... have you
> verified visually that the actual chip on the board is either a
> MX25U6435E or MX25U6435F,

Yes, they (2, since it's 'Dual BIOS') are marked

MXIC MX
  25U6435F
  M2I-10G
  8A615600
   L140295

More notes about the board at

http://lackof.org/taggart/hacking/coreboot/GA-J1900N-D3V-1.x/README
> and if the read data seems legit?

How would I test for that? The checksum of the image read does not match 
the blob in the vendor update package of the same version (but I suspect 
'Dual BIOS' has something to do with that). Can I binary diff them somehow 
or would something like compression interfere with that? Are there tools 
for picking apart the image to make comparison easier?

Also I'm a little concerned about something I read somewhere about 
Gigabyte's "Dual Bios" feature and possibly needing to give flashrom 
additional info in order to deal with that (but I can't find where I read 
it now).

How should I process with testing? I haven't setup a way to external flash 
yet, maybe the first step getting a good external read that I'd be able to 
write back if things went wrong?

Thanks,

[Stefan Tauner]

On Sat, 20 Dec 2014 14:03:43 -0800
Matt Taggart  wrote:
> Stefan Tauner writes:
> > thanks for you report. The flash chip is marked as untested... have you
> > verified visually that the actual chip on the board is either a
> > MX25U6435E or MX25U6435F,
>
> Yes, they (2, since it's 'Dual BIOS') are marked
>
> MXIC MX
>   25U6435F
>   M2I-10G
>   8A615600
>    L140295
>
> More notes about the board at
>
> http://lackof.org/taggart/hacking/coreboot/GA-J1900N-D3V-1.x/README
> > and if the read data seems legit?
>
> How would I test for that? The checksum of the image read does not match 
> the blob in the vendor update package of the same version (but I suspect 
> 'Dual BIOS' has something to do with that).

That's not unusual for various reasons (e.g. the firmware uses the
flash as scratchpad). The rom.bin on your website looks sane to me and
since I don't expect any problems regarding reading the chip with
flashrom, I will mark probing and reading as tested, thanks.
> Can I binary diff them somehow 
> or would something like compression interfere with that? Are there tools 
> for picking apart the image to make comparison easier?

There is ich_descriptor_tool (in flashrom's util directory), there is
ifd_tool in coreboot's repository, and there is bios_extract and
various related tools.
> Also I'm a little concerned about something I read somewhere about 
> Gigabyte's "Dual Bios" feature and possibly needing to give flashrom 
> additional info in order to deal with that (but I can't find where I read 
> it now).

Flashrom supports accessing both chips. For the second one there is a
command line option, see the man page.
> How should I process with testing? I haven't setup a way to external flash 
> yet, maybe the first step getting a good external read that I'd be able to 
> write back if things went wrong?

Getting a way to recover is certainly a good idea ;) I'd expect the
image you have read already to be fine, but without an external
programmer it does not help much.

I am not up to date how coreboot handles dualbios. In earlier days it
was a problem because the backup bios always kicked in to replace
coreboot without a hardware hack. That might be different now and
something the coreboot guys could probably answer.

From flashrom's perspective there is no need to test anything
specifically at this point on that board... if you happen to test
writing the chip/on this board I'd be happy to know about though.
Everything else should be addresses to the coreboot mailing list.