Add support for T420 and T430, enable FBWhiptail for X220. #539

snmcmillan · 2019-03-20T14:31:09Z

The T420 support is currently untested, but currently builds and should work.

Blob extraction scripts now autodetect coreboot's ifdtool and me_cleaner.

snmcmillan · 2019-03-20T19:02:15Z

Alright, so I am going to do another build and test if T420 will work. Will update with results.

snmcmillan · 2019-03-21T00:51:14Z

Alright, T420 builds and boots. Over the weekend, I will do usability tests and see if there are any major issues with the build and try to iron them out.

Edit: So I've done a bit of testing and outside of the seemingly platform independent issue I referenced above, everything looks good.

snmcmillan · 2019-03-22T13:15:48Z

One thing that's an issue currently is that ifdtool and me_cleaner are not present on a clean tree. You need to run a make job to get the coreboot repo cloned and then patch said repo.

snmcmillan · 2019-03-27T13:01:45Z

Currently working on issue #541 as well as updating the X220 and T420 builds to FBWhiptail.

snmcmillan · 2019-03-27T13:39:19Z

FBWhiptail is now working on X220 and T420. I left X230 IOMMU kernel command line options enabled and I do not have working graphics in the current OS (Xubuntu 18.10). I'll commit changes when I get home today (in about 9 hours).

Edit: OK, so I managed to temporarily disable those config options (why do we copy /etc/config to /tmp/config? Seems silly since its already temporary). I've recovered from that roadblock and am back on the main system.

…estarting, or during S3 resume. If they actually bring functionality to builds, replace the patch with something that is tested.

snmcmillan · 2019-03-27T18:51:44Z

PR now solves #541.

Pull request is ready to be merged.

flammit

Dropping these sandybridge patches removes a core bit of functionality that makes Heads work (i.e. measuring the first few levels of coreboot segments). This will impact not just the x220, but also the x230.

NAK until we can figure out a performant replacement that works or doesn't impact other platforms.

snmcmillan · 2019-03-27T21:12:25Z

I'll continue taking a look at this, as the delay is a pretty big issue for other platforms.

Edit: This issue only affects non-X230 platforms. X230 has no delay, but literally any other sandy/ivy-based device has this delay.

snmcmillan · 2019-03-27T22:13:20Z

@flammit I've found that the second tpm measurement in the romstage, precisely these lines are causing the issue:

extern char _romstage, _eromstage;
tlcl_measure(1, &_romstage, &_eromstage - &_romstage);

snmcmillan · 2019-03-27T23:45:55Z

This should keep the TPM measurements of the romstage as well as fix the delay, ready for review.

Edit: Before review, let me make some final changes.

flammit · 2019-03-28T16:52:16Z

@SebastianMcMillan nice catch btw - try this patch out: https://gist.github.com/flammit/247ca7877f5f885b5d9bb5d9c56196ce. If it works for you, would you mind opening another PR for that so we can merge it separately from the x220 support?

snmcmillan · 2019-03-28T17:42:48Z

I can do that, just recovered from accidentally enabling NO_GFX_INIT by blindly remoting into my main system and rebuilding. I can test right now...

snmcmillan · 2019-03-28T21:03:36Z

@flammit the patch you sent doesn't fix the problem (it even gives the same coreboot.rom checksum as the previous patch). I'll revert the sandy patch commits so T420 support and updating X220 to FBWhiptail changes can be merged.

Update: Ready for merge

This reverts commit 584690f.

…ng up, restarting, or during S3 resume. If they actually bring functionality to builds, replace the patch with something that is tested." This reverts commit 41e5301.

flammit · 2019-03-28T21:31:30Z

@SebastianMcMillan I see a change to the payload and hash when switch the patches. Remember that the Heads module patches are only applied when the module is first pulled, so you have to remove build/coreboot-4.8.1 and make again for the new patch to apply.

merge · 2019-05-22T11:49:58Z

IMO this should be tested by at least one of us who didn't write the changes. Also, I think it would make sense to stash the commits together nicely and improve the commit messages. Why do they mention "merging"?

techge · 2019-05-22T12:24:29Z

I might be able to help. I just do not understand if this still is a fix for x220 too or if there is still problem with timeout or whatever. But I can test it for x220 if you are interested (actually I am waiting for being able to use it on my device).

Would I just checkout this pr and build it? Or is there anything else I need to do before flashing?

tlaurion · 2019-05-22T15:02:49Z

@techge

I might be able to help. I just do not understand if this still is a fix for x220 too or if there is still problem with timeout or whatever. But I can test it for x220 if you are interested (actually I am waiting for being able to use it on my device).

The 50 second delay is still there and not well understood yet. From cbmem timestamp log the problem seems to be linked to Intel ME or TPM measurements, but neither with BBB Screwdriver USB debugging gadget or by inceasing cbmem logs were enough to get the culprit trace. USB dongle arrives too late, while cbmem maximum log length is not big enough to show early messages and get troncated.

I do not have a X220 in hands anymore to continue testing, but the same bug impacts all Ivy/Sandy bridge but x230. So anyone having those models and knowledge are more then welcome to jump in and troubleshoot the issue. Merging this makes those board supported, with 50 second delay at bootup and resume path (which makes me believe it's not a TPM issue, but Intel ME... While a pure coreboot build/removing TPM measurements patch removes the delay so it needs to be TPM measurements.... Then why no impact on X230?!?)

Would I just checkout this pr and build it? Or is there anything else I need to do before flashing?

Check instructions in the blobs directory. Get backups of your rom. Having an external flasher like ch431a is always a good idea to flash things back in case of a brick.

Once you have your extracted binary blobs in blobs/x220:
Build:
https://github.com/osresearch/heads-wiki/blob/master/Building.md
Basically: make BOARD=x220 CONFIG=config/x220-generic.config

Then:
https://github.com/osresearch/heads-wiki/blob/master/Installing-Heads.md
and flashing from the inside following blobs/x220/README.md or externally through flashrom.

Let us know how it goes. If things are unclear, it's a good time to do PR on the unclear stuff!
Thanks!

tlaurion · 2019-05-22T15:57:19Z

@merge

IMO this should be tested by at least one of us who didn't write the changes. Also, I think it would make sense to stash the commits together nicely and improve the commit messages.

I agree. I reviewed those changes myself and tested the outcome on a X220 and it works but does not resolve the 50 seconds delay. IMHO, it can be merged but 030 coreboot patch needs review since it only works on the x230.

Why do they mention "merging"?

The commit trace shows what was done to troubleshoot the issue.
I understand the logic with clean commits, but do not understand the strong emphasis put on it in community driven projects.

Those commit logs actually show what was done and is generally helpful for newcomers, trying to help and understand issues and troubleshooting paths. Squashing them makes it look like if the bugs were killed and make them question in issues and even reinvent the wheel, loosing precious time in the process.

As a tester, I don't look at the commit logs, just the outcome diff from master.
As a developer, I look at the commit logs to help me understand the process involved in the development of a feature or a fix.
I'm personally against squashing. But i'm open to produce cleaner commit logs myself.

In the present case, those logs show how to activate debugging features (TPM, CBMEM_TIMESTAMPS, augment cbmem log size...) which will even be helpful for new board ports.

tlaurion

typo making gpg-gui fail

tlaurion · 2019-05-22T20:55:31Z

initrd/bin/flash.sh

+    FLASHROM_OPTIONS='--force --noverify-all -p internal:laptop=force_I_want_a_brick --ifd --image bios'
+  ;;
+  x220* )
+    FLASHROM_OPTIONS='--force --noverify-all -p internal --ifd -image bios -c MX25L6405D'


-image -> --image

credits goes to @BlackMaria :)

Oh lord, thanks for the heads up! Fixed.

techge · 2019-05-27T14:48:10Z

I am not able to build this PR. Using make board=X220 it fails reproducably while making libgcrypt for the toolchain.

2019-05-27 16:42:31+02:00 MAKE libgcrypt
tail /home/user/heads/build/log/libgcrypt.log
-----
make[3]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3/cipher'
make[2]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3/cipher'
Making install in random
make[2]: Entering directory '/home/user/heads/build/libgcrypt-1.8.3/random'
make[3]: Entering directory '/home/user/heads/build/libgcrypt-1.8.3/random'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3/random'
make[2]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3/random'
Making install in src
make[2]: Entering directory '/home/user/heads/build/libgcrypt-1.8.3/src'
/bin/sh ../libtool  --tag=CC   --mode=link /home/user/heads/install/bin/musl-gcc -fdebug-prefix-map=/home/user/heads=heads -gno-record-gcc-switches -D__MUSL__  -I//include -g -O2 -fvisibility=hidden -fno-delete-null-pointer-checks -Wall    -Wl,--version-script=./libgcrypt.vers -version-info 22:3:2  -o libgcrypt.la -rpath //lib libgcrypt_la-visibility.lo libgcrypt_la-misc.lo libgcrypt_la-global.lo libgcrypt_la-sexp.lo libgcrypt_la-hwfeatures.lo libgcrypt_la-stdmem.lo libgcrypt_la-secmem.lo libgcrypt_la-missing-string.lo libgcrypt_la-fips.lo libgcrypt_la-hmac256.lo libgcrypt_la-context.lo  hwf-x86.lo ../cipher/libcipher.la ../random/librandom.la ../mpi/libmpi.la ../compat/libcompat.la  -L//lib -lgpg-error 
libtool: link: /home/user/heads/install/bin/musl-gcc -fdebug-prefix-map=/home/user/heads=heads -gno-record-gcc-switches -D__MUSL__  -shared  -fPIC -DPIC  .libs/libgcrypt_la-visibility.o .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o .libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-hwfeatures.o .libs/libgcrypt_la-stdmem.o .libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o .libs/libgcrypt_la-fips.o .libs/libgcrypt_la-hmac256.o .libs/libgcrypt_la-context.o .libs/hwf-x86.o  -Wl,--whole-archive ../cipher/.libs/libcipher.a ../random/.libs/librandom.a ../mpi/.libs/libmpi.a ../compat/.libs/libcompat.a -Wl,--no-whole-archive  -L//lib -lgpg-error  -O2 -Wl,--version-script=./libgcrypt.vers   -Wl,-soname -Wl,libgcrypt.so.20 -o .libs/libgcrypt.so.20.2.3
/home/user/heads/crossgcc/x86_64-linux-musl/lib/gcc/x86_64-linux-musl/5.3.0/../../../../x86_64-linux-musl/bin/ld: /usr/lib/libc_nonshared.a(fstat.oS): unrecognized relocation (0x29) in section `.text'
/home/user/heads/crossgcc/x86_64-linux-musl/lib/gcc/x86_64-linux-musl/5.3.0/../../../../x86_64-linux-musl/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:594: libgcrypt.la] Error 1
make[2]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3/src'
make[1]: *** [Makefile:477: install-recursive] Error 1
make[1]: Leaving directory '/home/user/heads/build/libgcrypt-1.8.3'
make: *** [Makefile:377: /home/user/heads/build/libgcrypt-1.8.3/.build] Error 1

I am on Arch Linux, 64bit.

BlackMaria · 2019-05-27T18:13:25Z

@techge if its not a typo, board should be all caps BOARD.
This builds fine with both the debian and fedora docker images. What is your gcc/ld version?
I assume you did this but if not, can you use "make BOARD=x220 V=1" to get more verbose?

snmcmillan · 2019-05-28T22:42:36Z

sorry for being away for a long while, now that finals are done I can actually spend time fixing issues and helping others test my changes.

…

On Mon, May 27, 2019 at 1:13 PM Hroðgar Skjöldung ***@***.***> wrote: @techge <https://github.com/techge> if its not a typo, board should be all caps BOARD. This builds fine with both the debian and fedora docker images. What is your gcc/ld version? I assume you did this but if not, can you use "make BOARD=x220 V=1" to get more verbose? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#539>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFNTUNHJ6SUK22N5RFU5RYTPXQQETANCNFSM4G75Y55Q> .

snmcmillan · 2019-05-28T22:46:41Z

@techge board needs to be capitalized. The correct command for you is make BOARD=x220

Edit: It seems that that's an actual build issue. It builds fine on a clean copy of the repo on my end.

I've tested it on Ubuntu 19.04, Debian Testing (Buster), Fedora 29, Fedora 30 and Gentoo.

snmcmillan · 2019-05-28T23:02:27Z

I also need an additional X230 tester that can test the x230-flash build to cross-verify, and I need a T430 tester that can test t430-flash and t430 board builds, as I've converted the x230-flash.init file into a universal install.init file for all boards that make use of a dual-chip setup.

I do not have a T430 to test with, but I want someone else that has a T430 that they can put coreboot on to try it out. It will likely help on identifying the issue with the boot-time delay as well.

Currently getting x230-flash built to test it on my end.

merge · 2019-05-29T06:01:59Z

I also need an additional X230 tester that can test the x230-flash build to cross-verify, and I need a T430 tester that can test t430-flash and t430 board builds, as I've converted the x230-flash.init file into a universal install.init file for all boards that make use of a dual-chip setup.

I do not have a T430 to test with, but I want someone else that has a T430 that they can put coreboot on to try it out. It will likely help on identifying the issue with the boot-time delay as well.

Currently getting x230-flash built to test it on my end.

I'd very much prefer to have one change only in a pull request. Don't change existing boards and add new ones on one PR.

snmcmillan · 2019-05-29T21:49:51Z

@merge I can attempt to separate out the changes, but the T430 addition relies on the changes I made to X230.

merge · 2019-05-30T06:14:57Z

@merge I can attempt to separate out the changes, but the T430 addition relies on the changes I made to X230.

If that is the case then X230 changes are bugfixes anyways and will be merged quickly. why not do them seperately in a PR before adding a new board? Try to keep a PR simple if possible.

snmcmillan · 2019-06-07T00:43:10Z

The PR is now split. I will close this one and the others can be looked at.

techge · 2019-06-07T07:58:08Z

#578 #579 and #580

flawedworld · 2019-06-16T12:24:52Z

@techge Did you find out a solution to the build failing? I also am on Arch 64 bit and get the same error on the X230, T430, assuming it's a build thing for sure.

techge · 2019-06-16T12:48:41Z

@flawedworld Unfortunately, I didn't. I planned to just grab a VM and build it there, but actually I got distracted by other stuff to do and didn't even did that. :(

flawedworld · 2019-06-16T12:51:53Z

@techge nah its fine, funnily enough I was doing a T430 port last year and well, life happened, saw this yesterday and I reminded myself about it. I'll try a Debian VM.

flawedworld · 2019-06-16T12:53:55Z

@SebastianMcMillan I am happy to test out any T430 builds, I may as well help you with what I never could be bothered to finish.

snmcmillan · 2019-06-17T17:12:41Z

@flawedworld current PR #580 is where you should start. Build that branch.

Also, find me on the u-root slack, where we can do a private conversation.

tlaurion · 2019-11-18T17:56:27Z

@SebastianMcMillan : Just a quick insight about ME delaying boot.

Could you try to extract the ifd, me as per this guide, and reinject the binaries directly from coreboot config and see if it resolves the 50 seconds delay?

That is what i'm planning to do to resolve the 12MB internal flashing requirement from x230 board config and it works for it. Non-obstant the current musl blocker, if you don't checkout clean and have musl already compiled, you should be able to build and report. I have intuition that it could be the difference between x230 working and others not working... The ifd in x230 being faked, and x230 only reflashing the bios region of the ROM, not ever touching ME which sits on its own SPI, containing the original IFD.

Let me know!

snmcmillan · 2019-11-19T04:16:27Z

I'll try that this weekend, thanks for the advice.

…

On Mon, Nov 18, 2019, 11:56 tlaurion ***@***.***> wrote: @SebastianMcMillan <https://github.com/SebastianMcMillan> : Just a quick insight about ME delaying. Could you try to extract the ifd, me as per this guide <https://github.com/corna/me_cleaner/wiki/Internal-flashing-with-coreboot#neutralize-and-shrink-intel-me>, and reinject the binaries directly from coreboot config and see if it resolves the 50 seconds delay? That is what i'm planning to do to resolve the 12MB internal flashing requirement from x230 board config and it works for it. Non-obstant the current musl blocker, if you don't checkout clean and have musl already compiled, you hsould be able to build and report. Let me know! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#539>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNTUNCSAA45ABHJUNRY2ITQULJNBANCNFSM4G75Y55Q> .

techge · 2020-01-03T22:12:47Z

Could you try to extract the ifd, me as per this guide, and reinject the binaries directly from coreboot config and see if it resolves the 50 seconds delay?

I followed the guide and truncated the ME, still the boot delay is valid.

tlaurion · 2020-01-20T02:41:37Z

When inserting expended IFD and neutered+deactivated ME inside of the x230 and changing CBFS region to fit expended size, I get the 50 seconds delay on x230 also. When putting back
CONFIG_CBFS_SIZE=0x700000
inside of coreboot config, the 50 seconds delay disappears. Just a hint.

techge · 2020-01-20T11:03:56Z

Very interesting! I try to test it as soon as possible 👍

snmcmillan added 2 commits March 20, 2019 09:14

Add support for the Lenovo ThinkPad T420.

662a1dd

Fix the autodetection of ifdtool and me_cleaner.

94e6e09

snmcmillan mentioned this pull request Mar 20, 2019

X220 gives endless beep error code. #538

Closed

snmcmillan added 3 commits March 20, 2019 16:07

Whoops, added the entire directory!

be21220

Actually point to the T420 coreboot config file...

d38190e

Merge branch 'master' of https://github.com/SebastianMcMillan/heads

f2bdd98

snmcmillan mentioned this pull request Mar 21, 2019

Romstage TPM measuring cause a 50 second delay on power on, S3 resume and reboot on all sandy/ivy devices except X230. #541

Closed

Enable FBWhiptail mode for X220 and T420

62d6a6c

snmcmillan added 2 commits March 27, 2019 13:42

Don't use iommu settings because it breaks graphics after kexec.

6fb0a9d

Remove sandybridge patches. Causes 50 second delay when booting up, r…

41e5301

…estarting, or during S3 resume. If they actually bring functionality to builds, replace the patch with something that is tested.

snmcmillan changed the title ~~Add Support for T420 and fix blob extraction scripts.~~ Add support for T420, make X220 and T420 use FBWhiptail, fix sandybridge 50 second delay. Mar 27, 2019

flammit suggested changes Mar 27, 2019

View reviewed changes

Fixed TPM romstage measurements.

584690f

Turn on iommu, but do not enable igfx-off

04d7df7

snmcmillan added 3 commits March 28, 2019 16:13

Revert "Fixed TPM romstage measurements."

cb74314

This reverts commit 584690f.

Revert "Remove sandybridge patches. Causes 50 second delay when booti…

04b59d2

…ng up, restarting, or during S3 resume. If they actually bring functionality to builds, replace the patch with something that is tested." This reverts commit 41e5301.

One more thing: Add flash.sh definitions for X220 and T420.

fe03f79

tlaurion self-assigned this May 22, 2019

tlaurion requested changes May 22, 2019

View reviewed changes

Fixed typo in flash.sh

1e500d8

snmcmillan mentioned this pull request Jun 7, 2019

T420 initial support + X220 FBWhiptail Support #578

Merged

snmcmillan closed this Jun 7, 2019

BlackMaria mentioned this pull request Jul 22, 2019

Enabling GZIP compression support in initrd for x220 #596

Closed

Add support for T420 and T430, enable FBWhiptail for X220. #539

Add support for T420 and T430, enable FBWhiptail for X220. #539

Conversation

snmcmillan commented Mar 20, 2019

snmcmillan commented Mar 20, 2019

snmcmillan commented Mar 21, 2019 • edited Loading

snmcmillan commented Mar 22, 2019

snmcmillan commented Mar 27, 2019

snmcmillan commented Mar 27, 2019 • edited Loading

snmcmillan commented Mar 27, 2019

flammit left a comment

Choose a reason for hiding this comment

snmcmillan commented Mar 27, 2019 • edited Loading

snmcmillan commented Mar 27, 2019

snmcmillan commented Mar 27, 2019 • edited Loading

flammit commented Mar 28, 2019

snmcmillan commented Mar 28, 2019

snmcmillan commented Mar 28, 2019 • edited Loading

flammit commented Mar 28, 2019

merge commented May 22, 2019

techge commented May 22, 2019

tlaurion commented May 22, 2019 • edited Loading

tlaurion commented May 22, 2019

tlaurion left a comment

Choose a reason for hiding this comment

tlaurion May 22, 2019

Choose a reason for hiding this comment

tlaurion May 22, 2019

Choose a reason for hiding this comment

snmcmillan May 28, 2019 • edited Loading

Choose a reason for hiding this comment

techge commented May 27, 2019

BlackMaria commented May 27, 2019

snmcmillan commented May 28, 2019 via email

snmcmillan commented May 28, 2019 • edited Loading

snmcmillan commented May 28, 2019 • edited Loading

merge commented May 29, 2019

snmcmillan commented May 29, 2019

merge commented May 30, 2019

snmcmillan commented Jun 7, 2019

techge commented Jun 7, 2019 • edited Loading

flawedworld commented Jun 16, 2019

techge commented Jun 16, 2019

flawedworld commented Jun 16, 2019

flawedworld commented Jun 16, 2019

snmcmillan commented Jun 17, 2019 • edited Loading

tlaurion commented Nov 18, 2019 • edited Loading

snmcmillan commented Nov 19, 2019 via email

techge commented Jan 3, 2020

tlaurion commented Jan 20, 2020

techge commented Jan 20, 2020

snmcmillan commented Mar 21, 2019 •

edited

Loading

snmcmillan commented Mar 27, 2019 •

edited

Loading

snmcmillan commented Mar 27, 2019 •

edited

Loading

snmcmillan commented Mar 27, 2019 •

edited

Loading

snmcmillan commented Mar 28, 2019 •

edited

Loading

tlaurion commented May 22, 2019 •

edited

Loading

snmcmillan May 28, 2019 •

edited

Loading

snmcmillan commented May 28, 2019 •

edited

Loading

snmcmillan commented May 28, 2019 •

edited

Loading

techge commented Jun 7, 2019 •

edited

Loading

snmcmillan commented Jun 17, 2019 •

edited

Loading

tlaurion commented Nov 18, 2019 •

edited

Loading