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

[tlaurion]

@Thrilleratplay
EDIT Building here https://app.circleci.com/pipelines/github/tlaurion/heads/313/workflows/64861cb0-e757-414b-9e66-8a4a9c7b7231/jobs/340

[tlaurion]

There was an issue with the buildsystem whcih was fixed in latest commit.
I integrated generated blob in the following PR master...tlaurion:x230-external-flash

Which is included in following build: https://app.circleci.com/pipelines/github/tlaurion/heads/332/workflows/f628e891-58d0-4dd3-8800-b26ae677d0c9/jobs/360

[tlaurion]

@Thrilleratplay unfortunately, this is what seems to happen when GBE is absent, but last time I injected an invalid GBE laptop was failing to boot, bot booting giving me this error as troubelshooted in #700

[tlaurion]

@Thrilleratplay you can see in this commit what is linked to your proposed change

[Thrilleratplay]

@tlaurion I'm confused. You are receiving probe of 0000:00:19.0 failed with error error -3 with the generate GBE or it does not boot at all?

[tlaurion]

@Thrilleratplay I reveive error -3, just like if no gbe was inside of the rom.
When the laptop was not booting, I was not duplicating gbe1.bin (cat gbe1.bin gbe1.bin > gbe.bin) which is probably why the laptop refused to boot altogether.

I guess the best way to troubleshoot this is for you to have a valid gbe.bin knowing the mac address and attempting to generate a valid gbe.bin twin from bincfg? Let me know how it goes! This is exciting!

[Thrilleratplay]

@tlaurion Gotcha. After reading through #700 and #703, I was more concerned with it booting. When doing the physical testing, I wanted to verify that the ethernet was still functioning after it booted up and since it was I didn't think to check dmesg. When receiving this error, was your ethernet still operational? If it is was, this is likely due to driver expecting functionality that has been disabled.

I'll look into it. This is going to be interesting; the error is related to PCI addressing within the e1000e driver and the specs stress that the physical hardware is not true PCI.

[tlaurion]

@Thrilleratplay I'm reverting gbe.bin to commit 3dbce28 (extracted gbe.bin) where mac: F0:DE:F1:F7:E4:AF for functional testing and to give you full functional dmesg output. the e1000e driver is not able to communicate with the device since it wasn't low level activated.

[tlaurion]

@Thrilleratplay if needed, I can merge the changes of x230-debug board into x230-external-flash_debug board to give more output

[Thrilleratplay]

@tlaurion Thanks but not just yet. I need to do more digging.

[tlaurion]

@Thrilleratplay might have been my error. With last commit, GBE is actually included in coreboot as expected (ioriginal gbe.bin extracted.) If this boots successfully, I'll switch back to generated gbe.bin per commit 8a0cda1

[tlaurion]

@Thrilleratplay WORKS (well builds and detected... more tests to be done)
DEAD COFFEE shows on ifconfig under heads after calling network-init-recovery :)

How much would be the invoice to open collective?

[Thrilleratplay]

@tlaurion Sweet. Is that error still in dmesg? Sorry, I don't understand what you mean by invoice to open collective?

[tlaurion]

Well, if you can provide a bill of work, that work was needed, which is why bounty tag was added

[Thrilleratplay]

Oh I see. Honestly, I did this for my own curiosity and maybe add my resume. I get so much out of coreboot, I wanted to be able to give something back. Knowing this works is payment enough. Although, if you want, take whatever would be a reasonable bounty and donate it to the EFF.

[tlaurion]

@Thrilleratplay the goal here is to give credit to the person who contributed to the project.
Please: how many hours have your spent on this? 150$ would be fair? Please create an invoice!
This invoice would be paid to you through paypal from the open collective. After which you can donate that to EFF if you will. We are trying to entice paid contributions for needed work here. That work was needed and should be paid.

[Thrilleratplay]

@tlaurion Probably 10.

[tlaurion]

This is why we prefer having a quote given prior of work being done. 200$?

[Thrilleratplay]

Sure.

[tlaurion]

This is why we prefer having a quote given prior of work being done. 200$?

@Thrilleratplay : Please submit expense of 200$ here, specifying "Fix issue #796" in the invoice!

If you want your name inside of the commit, please supply a PR equivalent to 8a0cda1 and the credit will be all yours!

[Thrilleratplay]

@tlaurion Thank you. I submitted the invoice. As the PR already links to the coreboot commit, it already gives me credit.

[tlaurion]

Payment approved https://opencollective.com/insurgo/expenses/24021, closing this issue!

@Thrilleratplay : Thanks for your contribution! If you want to tackle other bounty issues and do SOME word of mouth for other developers to join forces on other issues needing work/quotes agreement prior of payment upon PoW, don't hesitate!