Generate GBE blob from coreboot's bincfg tool

[tlaurion]

@PatrickRudolph @niftygeek @pietrushnic @miczyg1
@pgeorgi @GNUtoo (last two authors of coreboot's bincfg tool)

So in my novice path, to be able to generate a valid gbe.bin to be included under #703, I need to:

• Read specs
  • http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf
  • https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums
• Understand the mappings that led to the creation of gbe-ich6.spec out of precedent spec
• redo with Intel 6 Series Chipsets spec p.118 to create a valid gbe-cpt.spec file
• Test until user@x230-master:~/coreboot/util/bincfg$ ./bincfg -d gbe-cpt.spec heads/blobs/xx30/gbe.bin gbe-cpt.set creates a valid gbe-cpt.set file
• Test until ./bincfg gbe-cpt.spec gbe-cpt.set heads/blobs/xx30/gbe_mod.bin produces a valid gbe_mod.bin that can be included in a bootable rom under Add xx30-maximized and xx30-hotp-maximized boards (11.5mb flashable BIOS regions, reproducible me.bin and generated gbe.bin and totally externally and internally flashable roms) #703 ?

Originally posted by @tlaurion in #700 (comment)

[Thrilleratplay]

@tlaurion @pgeorgi @GNUtoo I have not tested this yet, but I think I have the beginnings of bincfg set/spec for the Intel 82579LM, used in the x230.

A few notes:

• Most set values are the Intel defaults, the LED light values are different to match those in the Lenovo firmware.
• Some of the settings will need to be changes to disable PXE or boot security.
• Not sure what to do with the mac address. If passed in via make commandline, not sure if it can be passed into bincfg or if done using a patch after flashregion_3_gbe.bin is generated. Suggestions?

https://github.com/Thrilleratplay/coreboot/tree/deblob_intel_82579_gbe

[tlaurion]

Wow.

[tlaurion]

Will review soon. Sorry overloaded but happy news!!!

[Thrilleratplay]

@tlaurion and I will try to test this today. If you get to it before I do, verify that bit 6 of word 0x19 is set to 1. A footnote in the spec mentions this need to be changed from the default value to indicate it is valid but I forgot to check this is done or not by the bincfg checksum. This slipped my mind and only remembered when I was half asleep last night.

EDIT: Looks like there is an issue. The checksum_gbe field isn't being populated because it seems like it expects to the last field. I have more work to do on this.

[tlaurion]

Thanks! How much would you ask to complete this work @Thrilleratplay ?

[Thrilleratplay]

@tlaurion At this point, I couldn't give an estimate on how much longer it would take. Even if I figure out how to append the gbe checksum when it is not the last field, there is still the issue of how to add in the MAC address without having to alter the set file. I will dig around bincfg source some more.

[Thrilleratplay]

@tlaurion The checksum was working but was missing a series of offsets so I was looking in the wrong place. This appears to be working now but still could not find a way to pass the mac address through the commandline. I tested it on my x220, which also has the same model Ethernet, no issues with basic internet function. When you get a chance, can you also test this and get feedback before submitting it for coreboot review?

[tlaurion]

@Thrilleratplay setting the mac address to 00:00:00:00:00 or 00:DE:AD:C0:FF:EE would do the job. QubesOS users should implement mac randomization to be applied by default, while in our #703 usecase, Heads will randomize on boot. Other tools, like clonezilla, will need to have preboot scripts randomizing the mac address prior of booting to not have mac collisions in same lan segment. If we do not apply mac randomization, we will not have a redistributabe GBE that is also bit by bit reproducible. Any thoughts welcome, while my preference would be to set it to 00:DE:AD:C0:FF:EE as a reference to Leah's prior work.

[Thrilleratplay]

@tlaurion I like 00:DE:AD:C0:FF:EE as a default. It seems this is a fine for heads but other implementations like skulls will have issues if a static binary is shared. You are welcome to include it in heads but before I do a PR for coreboot, I want to find a way to make setting the mac or other settings can be done with relative ease.

EDIT: I am not finding a way to do this without significant changes to the bincfg or implementing it in another binary schema.

[tlaurion]

@Thrilleratplay I will test asap

[Thrilleratplay]

@tlaurion When you have time, I already created the PR for coreboot