LibremKey/Nitrokey with x220 #690
Comments
|
@SebastianMcMillan : can you do a clean build with prior proposed settings (add CONFIG_LIBREMKEY in board config and CBFS correction in coreboot config) and confirm 50 seconds delay is gone doing so? |
|
Or, it would be time to create x220-libremkey board with different coreboot CBFS size? |
Before doing that I would double-check on whether the new CBFS size is appropriate for the x220 at all. As I say, in my case I couldn't get the GPG key to save permanently. It would save and reflash and boot properly the first time. But then on shutdown it would start again as if there was never a GPG key and would ask me to flash one. The only changes made to get everything working from that build were (1) resize CBFS to old size; and (2) add librem key. Otherwise everything else was left as is. So my assumption is that the CBFS size should never have been reduced and its reduction wasn't necessary to fixing the 50 second boot issue. But that's just my uninformed assumption. |
|
With a clean master, my X220 stores my gpg key just fine. |
Interesting. That is with the new CBFS size 0x700000 or the old one? Mine wouldn't store it, but will now.
The issue with the Libremkey was that it wouldn't build at all as there wasn't enough space with the new CBFS size (but was with the old size). |
|
Yes, that is with the new size. also, I just built the libremkey build with the new size, and it's building just fine. edit: I just pulled an updated version of master, and now it's erroring out. Looks like something changed that puts the size requirements above what's currently offered. |
|
Reverting to the old CBFS does once again bring back the 50 second delay. |
|
@SebastianMcMillan : the CBFS size is probably just not matching. (which is the hypothesis for the delay) |
|
Can't wait to have an agreement on #307 for blobs.... |
|
@merge: I'm still not understanding how to adjust CBFS size according to me_cleaner and ifd expended size output. Some clarifications for clearer understanding would be more then welcome. |
|
|
|
@merge : now. What do we put in x220 coreboot CBFS section? |
|
We don't have consistent changes to the regions. That could explain why the OP doesn't have the issue. |
Which reinforce need to have blobs disclosed somewhere to have consistent CBFS region defined. :) #307 for the win! |
|
Yes, I did that with my x220 backup and got the results above. |
|
@merge: What to put in CBFS with logic explanation? |
|
I've changed the region to 0x750000 and it doesn't delay and it builds. It stores my gpg key on the libremkey builds. I do not have a libremkey to test if libremkey functionality works as expected, however. Do agree with above: what to put in CBFS with calculations would be helpful. |
|
@SebastianMcMillan : well, we are not basing ourselves on the same version. Yours:
Backup I had in hands:
Goal would be to specify, minimally, original ROM that needs to be applied on Lenovo prior of extracting ROM for consistency in blob directory. On X230, the goal is to apply the latest EC not considered for signature validation, for easy revert of original BIOS reflash, that original BIOS needing to be backuped (2.75, 2.76) |
|
that explains it. More the reason to push #307. |
|
Just realized, but this problem affects T420 as well, since the T420 and X220 are practically identical devices in terms of the flashchip. I'll make a band-aid fix for both devices, PR opening up in a second. |
|
Alright, PR is open |
Just to say, I've tested it with this CBFS size and indeed it all works, including the Libremkey and with no major delay. It isn't nearly as snappy as with the original 0x7e8000. That really is near instantaneous and must mean that the libremkey add-on is just the perfect size. But it will do if you're going with one x220 board (I did the vanilla, no Libremkey, with the 0x7e800o size just to see the delay and it was horrible). |
|
@eganonoa : there is no magic here. Waiting for input to do this correctly (legally, challenging status quo) and provide those binaries like for #307. |
Last time I checked, cbfs size does not correlate to how snappy or sluggish the build is? |
Ah, there you go. I stripped it all out from rom image pulled off of my x220 that was (a) running the modified version of bios 1.46 that you use on the x220 to unlock various advanced settings. (see http://x220.mcdonnelltech.com/resources/) (bios available at http://www.mcdonnelltech.com/X220_v1.46_Modified_BIOS.zip); and (b) had the 2017 ME firmware update applied (https://pcsupport.lenovo.com/se/en/downloads/ds014884). Used the script in the Heads master to pull out the blobs for the x220 directory, etc. Use 0x7e8000 CBFS size + libremkey and its near perfect. I know nothing about the reasons why CBFS size should matter, but I can confirm that for me and based on a rom image with those two bits added: (1) master + 0x7e8000 - libremkey = 50 second boot time; (2) master + 0x750000 + libremkey = maybe 3-4 second boot time; (3) master + 0x7e8000 + libremkey = instant on. |
|
I ran into this problem two weeks ago and tried with 0x72000 which works fine. If 0x75000 works, too that's even better. I do not understand why the boot delay happened with 0x7e8000 in the past, but not now for @eganonoa 🤔 |
|
@techge @eganonoa @SebastianMcMillan : CBFS space should be smaller then available space defined in IFD, that is my only logical explanation: ME init/TPM measurements probably being confused and timing out (We see here that ME seems to suffer a lot!!!). Played with CBFS calculations a bit for the x230 and successfully increased CBFS to 11.5Mb for xx30 here. This is why we want reproducible, expended ifd, matching reduced neutered ME and consequent coreboot config CBFS defined region for a specific original bios version So my recommendation would be:
Theoritically, those blobs should work for all Lenovo xx20 based boards: |
|
Confused by the state of the boards right now. @eganonoa ? |
With the current master branch, which includes the changes to the x220 configs, amongst others, a new CBFS size ("to fix 50 seconds boot delay problems"), I found that you cannot build Heads with the additional libremkey/nitrokey module because there isn't sufficient space.
Reverting to the prior CBFS size (0x7e8000) fixes that problem. With that change made to the coreboot-x220.config file and CONFIG_LIBREMKEY=y added to x220.config, my x220 boots incredibly quickly and everything works. To be honest, it appears to boot faster than the x230s I have used with either Heads or Pureboot. So it doesn't seem to bring back any 50 second boot delay problem that there was before (this is my first time with an x220 in heads so I don't know about the boot delay).
In addition, even before using the libremkey/nitrokey module, I found that current master cannot build Heads on an x220 that properly stores the GPG key. Each time I would reboot it would ask me to flash it afresh. Given the above, I suspect that this is also related to the CBFS size.
All of which leads me to believe that the CBFS size from "T420 initial support + X220 FBWhiptail Support #578" merged into the master branch on February 19 isn't right for the x220 and that it should revert to a CBFS size of 0x7e8000.
The text was updated successfully, but these errors were encountered: