Someone with a bricked (dead motherboard) t420/x220 willing to provide firmware backup?

[tlaurion]

@SebastianMcMillan @techge @eganonoa @shamen123 @Thrilleratplay @userongihu @BlackMaria:

The goal here would be to use the ifd of that sacrificed beast, in the goal of providing full ROMs containing generated GBE, extracte ME from Lenovo and a ifd dump of a scarificed x220/t420 (that I do not own)

@Ivyrain maybe?

[Thrilleratplay]

@tlaurion Are you only asking for just a copy of the IFD? IDF layout? I am not sure why it must be bricked.

Here is the layout of the X220

[snmcmillan]

Just curious, but what's stopping us from using a functional system's IFD? And onto the question at hand, I have a fried T420 but one of the things that's fried on it is the SPI flash chip (flashrom cannot detect it on any of my flashers).

…

On Sun, Nov 1, 2020, 15:36 tlaurion ***@***.***> wrote: @SebastianMcMillan <https://github.com/SebastianMcMillan> @techge <https://github.com/techge> @eganonoa <https://github.com/eganonoa> @shamen123 <https://github.com/shamen123> @Thrilleratplay <https://github.com/Thrilleratplay> @userongihu <https://github.com/userongihu> @BlackMaria <https://github.com/BlackMaria>: The goal here would be to use the ifd of that sacrificed beast, in the goal of providing full ROMs containing generated GBE <#796>, extracte ME from Lenovo <#307> and a ifd dump of a scarificed x220/t420 (that I do not own) @Ivyrain <https://github.com/Ivyrain> maybe? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#884>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNTUNBV4MUBQY36BGJZDYTSNXIFRANCNFSM4TGYNMZA> .

[tlaurion]

The idea here is to not have a IFD under heads repo that comes from a laptop existing in the wild. While I agree that might me overkill to dodge probal legal problems. Unless that IFD also contains Windows CoA and some other shit..... Which is why I would prefer a dump coming from a grilled/trashed/destroyed t420/x220.

[tlaurion]

@tlaurion Are you only asking for just a copy of the IFD? IDF layout? I am not sure why it must be bricked.

Here is the layout of the X220

@Thrilleratplay @SebastianMcMillan No, I really mean the IFD itself, to be able to provide it under repo in the goal of providing fully reproducible, bit by bit, externally+internally fully flashable ROM images coming from CIs (not only flash BIOS regions from within Heads anymore) for the xx30 and xx20, including GBE, ME and that IFD on all boards.

@osresearch agreed that it was not a legal problem. Gbe can now be generated, and ME extracted directly from Lenovo website per local builds (CI will just apply recipe).

[Thrilleratplay]

@tlaurion I feel like am missing something. coreboot can generate the ifd. As you said, the GBE can be generated and the ME extracted from the lenvo website.

[tlaurion]

@Thrilleratplay : no. coreboot uses ifdfake to fill generated rom space and cannot be flashed with it. This is why coreboot takes as an input your original ifd, where the x230-flash board is a requirement, and where std boards only flashes BIOS region internally, from BOARD config instructions to flashrom.

You can provide an external flashmap to be modified inside of IFD, but the IFD i where the info for that laptop is actually stored. It cannot be fully generated as of now, unless I really missed something, on which I would be stunned and totally curious, since everything could be fully generated and therefore no uncertainty at all in just storing blobs on the Heads repo. (we would have generated ifd, GBE and extracted ME from Lenovo.)

[Thrilleratplay]

@tlaurion Huh. I could have sworn that coreboot could generate a fully valid IFD. This sounds like another blob generator project to do. I'll start that after finishing up the shellcheck PR.

[Thrilleratplay]

@tlaurion I did a diff on the IFD files I extracted from my x220 and x220 tablet as well as two other x220 firmware files I found on github. The only difference between them is the ME version. A IFD from a sacrificial board likely will not work unless it died with the most up to date ME version installed. Although, using any IFD and modifying it using a hex editor will will work until I can create a script that will be able to generate them on the fly.

[Maccraft123]

points at https://github.com/coreboot/coreboot/tree/master/util/bincfg

[Thrilleratplay]

@Maccraft123 That is for the X200, not the X220. That isn't 100% true. Apparently they use the same IFD version but there are a number of differences between what is generated for the X200 and the X220.

[tlaurion]

@Thrilleratplay coreboot divided to conquer. ifdtool unlocks ifd and can optionally deactivate ME with HAP bit, bincfg generates blobs, me_cleaner is now included and permits calls (custom?) and writes output where desired from provided external blob dependencies.

I think generating ifd could be the only piece missing here, where coreboot module inside of heads could have different build options (now has added clean menuconfig and saveconfig, where ifdtool and bincfg would ease it, or could be bound to the all target of main coreboot module so that those tools are prebuilt and known in path)

Do I make sense?

[Thrilleratplay]

@tlaurion I think so. You are suggesting to be able to generate an IFD outside of the coreboot project itself and instead use the heads' coreboot module to create and more the file into the appropriate directory for coreboot to utilize it. Yes?

Regardless of how wrong I am in that understanding, the generation of the IFD files is key in being able to generate not only complete roms but fully reproducible. I am going back to an idea I had after finding the limitations of customizing bincfg; basically using python and with yaml based set/spec files but define blob schemas, default values and the ability for users to override defaults via command line or yaml file. For the X220, I think using using a preconfigured IFD file (modified to match the downloaded ME version, unlocked, layout resized, blah blah blah) included in the heads repo as a blob will be the quickest and easiest way to add the model to the CI builds.

[tlaurion]

@tlaurion I think so. You are suggesting to be able to generate an IFD outside of the coreboot project itself and instead use the heads' coreboot module to create and more the file into the appropriate directory for coreboot to utilize it. Yes?

@Thrilleratplay Yes, that is what I thought would be the easiest: take the x200.set and x200.spec file, just like you did for gbe if you will, and generate generic IFD, while it's not a problem, see below.

Regardless of how wrong I am in that understanding, the generation of the IFD files is key in being able to generate not only complete roms but fully reproducible.

Agreed. Or dump one xx20 and one xx30 (where sacrificed here seems less and less relevant).

I am going back to an idea I had after finding the limitations of customizing bincfg; basically using python and with yaml based set/spec files but define blob schemas, default values and the ability for users to override defaults via command line or yaml file. For the X220, I think using using a preconfigured IFD file (modified to match the downloaded ME version, unlocked, layout resized, blah blah blah) included in the heads repo as a blob will be the quickest and easiest way to add the model to the CI builds.

From my understanding, there is not even any check verifying that the ME version matches. I really begin to think more and more that we simply don't care and should just dump a modified ifd from me_cleaner in heads repo. and move from there.

I will clean my #703 branch soon to simply drop ifd and generated gbe.
Ideal would be to have a module for xx30_blobs which would download me_cleaner, make sure coreboot.ifdtool coreboot.bincfg are built (or modify coreboot module to build those by default in local toolchain) and have innoextract stated as additional dependencies, replicating extract.sh script but automated taking ME from Lenovo.

I haven't been able to wrap my head around how to actually call innoextract, have ifdtool and bincfg already build to completely automatize #703. That becomes the real priority.

[techge]

Honestly, I am a bit lost know. By fast reading your posts it looks like you were successful in making extracting parts from rom dump unnecessary, is that right? As I have my x220 again now, I could test any rom you like if you point me to it. I can build something and extract (actually have everything at hand already) if you like. I just want to make sure to test the process correctly to have a meaningful test case here...

[tlaurion]

#703 works and does it for xx30. Same work needs to be done for xx20 in the two scripts there.

[tlaurion]

We might have a problem
corna/me_cleaner#343

[tlaurion]

Honestly, I am a bit lost know. By fast reading your posts it looks like you were successful in making extracting parts from rom dump unnecessary, is that right? As I have my x220 again now, I could test any rom you like if you point me to it. I can build something and extract (actually have everything at hand already) if you like. I just want to make sure to test the process correctly to have a meaningful test case here...

@techge as opposed to xx20 Lenovo ME capsule provided, the xx30 ME exe is a full ME image that can be taken as input to be cleaned and dumped into the blobs/xx30 directory, where the triple me.bin, ifd.bin and gbe.bin are taken to produce a full ROM on CIs which is currently generating bottom.rom and top.rom to be both internally and externally flashable.

From my current understanding (not investigated), it seems that for xx20, there will be a need to download a user made flashrom backup to extract ME region out of it prior of cleaning it.

[tlaurion]

So, if someone has the latest firmware update applied and can share it in PM, extract.sh for xx20 could be modified so at least local extraction from an externally taken flashrom backup could be used to extrct, neuter, clean and produce ifd matching ME cleaned+neuter region, while gbe.bin and ifd.bin could be in heads' repo.

[tlaurion]

fixed under #912