Add Talos 2 board (OpenPower)

[SergiiDmytruk]

This provides a configuration for OpenPower that builds (wasn't fully tested yet). It seems to be the first non-x86 target for Heads and might be the time to think how you want to support multiple targets.

This isn't a finished PR and the point is to request comments. Below are some suggestions which you might want to consider.

---

I haven't tried to enable all modules. I think this is a typical config with some things disabled. I'm not sure which are necessary. Might enable and fix build of other things. At the moment at least 31 out of 48 available modules build fine.

Building for power produces zImage instead of bzImage. The latter doesn't work (no rule to make bzImage). Image name is configurable now.

For coreboot, I specifed -b in coreboot_repo to switch to the branch. Might want to improve this.

For now I hoisted everything to board configuration via CONFIG_<MODULE>_TARGET variables and I don't really like how it looks (naming is very inconsistent). Maybe you want to have a generic CONFIG_TARGET, which will then be translated within each module and fail for unknown targets? This might ease adding new targets in the future thanks to more obvious errors.

[tlaurion]

@SergiiDmytruk did a regression build against 7efe7ce and it was successful.

Everything x86 builds as expected from last commit. I would recommend following your branch from CircleCI so that each commit pushed triggers a CircleCI build for that commit.

[tlaurion]

@SergiiDmytruk

You could change this for something similar to the following and tune to have your boards built first with save_cache. (build_and_persist is costy since saving workstpace and restoring workspaces). You might want to only build talos_2 and talos_2_lite and wipe the rest to speed up testing also if regression testing is not needed in all builds (I think changes that are coming next should probably only happen in linux and coreboot configs and trees, so touching other x86 and testing for regression might not be needed.

# Below, sequentially build one board for each coreboot
# version. The last board in the sequence is the dependency
# for the parallel boards built at the end, and also save_cache.
      #Coreboot Talos
      - build_and_persist:
          name: talos_2
          target: talos_2
          requires:
            - prep_env

      # Coreboot 4.8.1
      - build_and_persist:
          name: qemu-coreboot
          target: qemu-coreboot
          requires:
            - prep_env

      # Coreboot 4.11
      - build_and_persist:
          name: kgpe-d16_workstation
          target: kgpe-d16_workstation
          requires:
            - qemu-coreboot

      # Coreboot 4.13
      - build_and_persist:
          name: librem_mini
          target: librem_mini
          requires:
            - kgpe-d16_workstation


      - save_cache:
          requires:
            - librem_mini

#
#
# Those onboarding new boards should add their entries below.
#
#
      - build:
          name: talos_2_le
          target: talos_2_le
          requires:
            - talos_2

      - build:
          name: x220-hotp-maximized
          target: x220-hotp-maximized
          requires:
            - librem_mini

      - build:
          name: x220-maximized
          target: x220-maximized
          requires:
            - librem_mini

      - build:
          name: t420-hotp-maximized
          target: t420-hotp-maximized
          requires:
            - librem_mini

      - build:
          name: t420-maximized
          target: t420-maximized
          requires:
            - librem_mini

      - build:
          name: x230-flash
          target: x230-flash
          requires:
            - librem_mini

      - build:
          name: t430-flash
          target: t430-flash
          requires:
            - librem_mini

      - build:
          name: t430
          target: t430
          requires:
            - librem_mini

      - build:
          name: x230
          target: x230
          requires:
            - librem_mini

      - build:
          name: x230-hotp-verification
          target: x230-hotp-verification
          requires:
            - librem_mini

      - build:
          name: x230-maximized
          target: x230-maximized
          requires:
            - librem_mini

      - build:
          name: t430-hotp-maximized
          target: t430-hotp-maximized
          requires:
            - librem_mini

      - build:
          name: x230-hotp-maximized
          target: x230-hotp-maximized
          requires:
            - librem_mini

      - build:
          name: t430-maximized
          target: t430-maximized
          requires:
            - librem_mini

      - build:
          name: qemu-coreboot-fbwhiptail
          target: qemu-coreboot-fbwhiptail
          requires:
            - librem_mini

      - build:
          name: kgpe-d16_workstation-usb_keyboard
          target: kgpe-d16_workstation-usb_keyboard
          requires:
            - librem_mini

      - build:
          name: kgpe-d16_server
          target: kgpe-d16_server
          requires:
            - librem_mini

      - build:
          name: kgpe-d16_server-whiptail
          target: kgpe-d16_server-whiptail
          requires:
            - librem_mini

      - build:
          name: librem_l1um
          target: librem_l1um
          requires:
            - librem_mini

      - build:
          name: librem_mini_v2
          target: librem_mini_v2
          requires:
            - librem_mini

[tlaurion]

Or without x86 regression testing this simpler version:

# Below, sequentially build one board for each coreboot
# version. The last board in the sequence is the dependency
# for the parallel boards built at the end, and also save_cache.
      #Coreboot Talos
      - build_and_persist:
          name: talos_2
          target: talos_2
          requires:
            - prep_env

      - save_cache:
          requires:
            - talos_2

#
#
# Those onboarding new boards should add their entries below.
#
#
      - build:
          name: talos_2_le
          target: talos_2_le
          requires:
            - talos_2

[SergiiDmytruk]

@tlaurion, thanks. I left one x86 target to see if CI works in this case. I'm not sure because it's not enough to just replace build/ to switch targets, need to also remove install/ and crossgcc/ or they will mess up the build (libraries and includes will be used from wrong toolchain).

[tlaurion]

@tlaurion, thanks. I left one x86 target to see if CI works in this case. I'm not sure because it's not enough to just replace build/ to switch targets, need to also remove install/ and crossgcc/ or they will mess up the build (libraries and includes will be used from wrong toolchain).

@SergiiDmytruk

I see.... x86 centric and completely understandable until now :/

Probably better to fix INSTALL by appending TARGET/arch suffix to that directory (while musl-cross path should deal with x86 and power from inclusion of the module def) from now on.

Fixating caches to include those new directories into them would also be required to be reused:

• Include Makefile so that caches digests (tag) are not reused when Makefile changes (that didn't change for a while and wasn't included)
  • Names for cache save/restore can be reused without change (above will change digest, so caches will not be saved/restored if digest changed)
• Where cache directories saved/restored should be changed to match new directories created having TARGET (or arch) appended

[tlaurion]

@SergiiDmytruk your board dir and board names are matching to "talos-2" and "talos-2-le" not "talos_2" and "talos_2_le" which you fixed under https://github.com/osresearch/heads/blob/61002eb088c5819867e12dcdb0d5591bc33a9aca/.circleci/config.yml

The last build was manually cancelled, but should have continued the build!

[SergiiDmytruk]

@tlaurion It wasn't me:

We have detected an anomaly that violates the CircleCI Terms of Service.
We did not test this push because the project has been suspended. Please contact us if you think this is a mistake.

[tlaurion]

@SergiiDmytruk weird. This is an error.
Building here meanwhile, but yes, this is open source project so should not be a violation of their terms of services.

Let's see if that build is also suspended.

[tlaurion]

@SergiiDmytruk note that old cache is being reused for last successful build with same modules and patches created digests as explained in previous post. Those are saved into workspace now and will be passed to board builds to be reused, so it will probably fail since ./install and ./crossgcc (and build/musl-cross) will be shared between x86 and power.

Builds taking more then 3 hours per task are also cancelled per terms and services, which is why we struggle using CIs for Heads.

[SergiiDmytruk]

@tlaurion CI works again for me after contacting support. Haven't updated how caching is done yet.

[SergiiDmytruk]

@tlaurion Currently Heads produces kernel and initrd separately. Was embedding of initrd into the kernel ever considered? We probably won't need this for coreboot (skiroot needs it), but I thought I'll bring it up just in case there were attempts and known issues. At the moment I only see this way:

1. Create empty initrd.cpio
2. Build everything including real initrd
3. (Re)link kernel

[tlaurion]

@tlaurion Currently Heads produces kernel and initrd separately. Was embedding of initrd into the kernel ever considered?
@SergiiDmytruk never thought about it....

initrd is actually what Heads is (outside of the patches applied to linux kernel and patches applied to coreboot (less and less, but still.) Just to make sure, you can see those compressed artifacts under /build/$BOARD dir and under CI. Example artifacts for a built board

• bzImage (kernel)
• hashes.txt (contains hashes of all compiled and bundled steps to be able to compare between builds)
• final rom for board (coreboot+ kernel + initrd per coreboot last step of putting everything together)
• heads.cpio (scripts under /initrd)
• modules.cpio (linux kernel modules per linux heads's module)
• tools.cpio (modules bin, modules libs)
• initrd.cpio.xz emcompassing dev.cpio, then modules.cpio, tools.cpio and heads.cpio above.

Some reverse understanding is currently possible since initrd is built separately:
tools.cpio, modules.cpio initrd.cpio and heads.cpio are bundled under initrd.cpio.xz. The more we bundle things the more difficult it is for newcomers to reverse the bundling inspect and diagnose reproducibility problems, but that might be only a documentation guide away. I do not have a preference over this, if you think the same outcome can be achieved, while understanding what is happening here.

We probably won't need this for coreboot (skiroot needs it), but I thought I'll bring it up just in case there were attempts and known issues. At the moment I only see this way:

1. Create empty `initrd.cpio`

2. Build everything including real initrd

3. (Re)link kernel

Let me know if this idea is still applicable following details provided above.

[SergiiDmytruk]

@tlaurion, thanks for the detailed explanation.

Let me know if this idea is still applicable following details provided above.

I think everything should be OK as is once coreboot will be able to use Heads as payload.

[macpijan]

I think everything should be OK as is once coreboot will be able to use Heads as payload.

I do not think it will be in the near future. The goal for now is to replace skiroot with heads (while still using skiboot as the only available coreboot payload). As defined here: #720 (comment)

We won't be able to start heads kernel as a coreboot Linux payload as it is currently done for other platforms. At least for now, we only can start skiboot from coreboot. We need it for OPAL. Then, the skiboot can load Linux - in this case it could load heads kernel and initramfs.

[SergiiDmytruk]

@tlaurion I've re-committed changes and marking this PR for review (but will see if CI passes with all the boards). Below is a summary of the changes since the previous comment.

The build eventually started to fail due to mixing of files of different architectures under build/, I looked into updating makefiles of modules, but it seemed unfeasible (very specific to each project and would add many more patches), so now it's build/<arch>/<module|board> with gawk being build in build/ once. Hopefully, I updated configs and CircleCI configuration right.

It's just one board again with BE coreboot and LE everywhere else, which seems to be typical for PowerPC.

Because we need skiboot, Heads can now optionally build bundled Linux kernel and the new board asks for it.

Patches for coreboot can be dropped after 3mdeb/coreboot#79 is merged.

There is now CONFIG_TARGET (x86 by default) and modules which had build issues branch on it to determine host triplet instead of hard-coding this module-specific knowledge in board definition.

[SergiiDmytruk]

Finally, CI is green.

[tlaurion]

I think everything should be OK as is once coreboot will be able to use Heads as payload.

@SergiiDmytruk Not sure about the next steps here. Do we wait to merge once Heads can be used as a payload?

I see from here:

Uploading /root/project/build/ppc64/talos-2 to build/ppc64/talos-2
Uploading /root/project/build/ppc64/talos-2/hashes.txt (9.8 kB): DONE
Uploading /root/project/build/ppc64/talos-2/heads-talos-2-v0.2.0-1047-g586ddd0.rom (2.1 MB): DONE
Uploading /root/project/build/ppc64/talos-2/heads.cpio (167 kB): DONE
Uploading /root/project/build/ppc64/talos-2/initrd.cpio (15 MB): DONE
Uploading /root/project/build/ppc64/talos-2/initrd.cpio.xz (3.8 MB): DONE
Uploading /root/project/build/ppc64/talos-2/logs.tar.gz (1.2 MB): DONE
Uploading /root/project/build/ppc64/talos-2/modules.cpio (560 kB): DONE
Uploading /root/project/build/ppc64/talos-2/tools.cpio (14 MB): DONE
Uploading /root/project/build/ppc64/talos-2/zImage (7.9 MB): DONE
Uploading /root/project/build/ppc64/talos-2/zImage.bundled (12 MB): DONE

Where coreboot image doesn't seem to bundle much. Can you detail the current state of the build?

[SergiiDmytruk]

@tlaurion

Do we wait to merge once Heads can be used as a payload?

It's not clear when that will be the case (i.e., when coreboot will support OPAL). A much closer target is the ability to start skiboot, although I don't know its exact status (might work already, not much changes on the branch) and when it will make its way upstream.

Where coreboot image doesn't seem to bundle much. Can you detail the current state of the build?

It's small because its payload is skiboot. zImage.bundled should be inserted into flash separately (with pflash commands like here, the alternative is flashing everythin in one go with a full image composed locally) and skiboot will pick it up from there. coreboot needs to be installed the same way. Actually we need .signed.ecc ROM as well as bootblock.signed.ecc in this case. I'll change that and also test all build artifacts together, thanks.

Not sure about the next steps here.

My concern about this PR is mostly about changes to the build system, which is the bulk of it. Do they look OK or something needs to be done differently?

[tlaurion]

As a basic regression test, I flashed https://113-380596387-gh.circle-artifacts.com/0/build/x86/x230-hotp-maximized/heads-x230-hotp-maximized-v0.2.0-1047-g586ddd0.rom internally and booted Tails with detached signature file verified successfully.

My concern about this PR is mostly about changes to the build system, which is the bulk of it. Do they look OK or something needs to be done differently?

@SergiiDmytruk: I will review the changes done on the build system, but I do not see anything problematic and it opens the door for integration of other architectures then x86.

One consideration for Heads (usability) is to use gui-init instead of generic-init, which dependencies are outlined when comparing qemu-coreboot and qemu-coreboot-fbwhiptail (which requires functional graphic framebuffer under linux config). That means that CAIRO and FBWHIPTAIL modules and dependencies might cause you some problems along the way for a workstation aimed build, but I think this would be the desired outcome of the board to be functionally the same as other boards also testing gui-init implemented policy vs the old generic-init which is less used (and mostly deprecated).

Note that for the qemu-coreboot board config here, one could simply replace generic-init script with gui-init and have whiptail do the prompts on the console without fb (uglier) but would also work, in case no graphical framebuffer is chosen/possible (that would also work remotely over console, just like for the kgpe-d16 boards configs what were made: server (whiptail) vs workstation (fbwhiptail), where server is aimed to be accessed over the BMC console for remote attestation).

@MrChromebox: See any change you do not like in the build system?

[SergiiDmytruk]

@tlaurion Switched the board to use gui-init with whiptail in console mode. Tested GUI mode and it works fine, but it's much less convenient to use remotely.

Also flashed coreboot and kernel built by Heads, but skiboot hanged on CPU initialization. Something is probably not finished yet.

[tlaurion]

@SergiiDmytruk some notes on your last build https://app.circleci.com/pipelines/github/SergiiDmytruk/heads/71/workflows/9b7ca741-8921-4c71-8200-525d6a151448 for SergiiDmytruk@087b754 which included two patches as opposed to last full build that successfully created a cache.

https://app.circleci.com/pipelines/github/SergiiDmytruk/heads/71/workflows/9b7ca741-8921-4c71-8200-525d6a151448/jobs/1111/parallel-runs/0/steps/0-108

No cache is found for key: heads-modules-and-patches-_HRCdgnWzy9K7C1h2vPMrcofQlTuTqUhlZCb+2+6dC4=ci-opt-build
Found a cache from build 1052 at heads-coreboot-musl-cross-vb2jPQCaIG8cDtAF01mvN1JR0NxouC8UzROMPf+3mWo=ci-opt-build
Size: 4.7 GiB
Cached paths:
  * /root/project/crossgcc
  * /root/project/build/x86/musl-cross-38e52db8358c043ae82b346a2e6e66bc86a53bc1
  * /root/project/build/ppc64/musl-cross-38e52db8358c043ae82b346a2e6e66bc86a53bc1
  * /root/project/packages
  * /root/project/build/x86/coreboot-4.11
  * /root/project/build/x86/coreboot-4.13
  * /root/project/build/x86/coreboot-4.14
  * /root/project/build/x86/coreboot-4.15
  * /root/project/build/ppc64/coreboot-git

Downloading cache archive...
Unarchiving cache...

This is why builds took a little longer, they were only taking coreboot cache from built modules. So a rebuild should take less time then what we see here, which is good news. (was not understanding why it was longer build times, this explains that!)

[tlaurion]

As noted under SergiiDmytruk@9879e58

I doubt save_cache https://app.circleci.com/pipelines/github/SergiiDmytruk/heads/72/workflows/a1515fdc-e92b-4276-b35b-ee114ba66de0 will work, since packages dir will contain conflicting files :/

[tlaurion]

Rebuilding from clean commit ( Changed CACHE_VERSION under CircleCI project) with save_cache depending on Talos II server so that cache contains variants of whiptail and fbwhiptail https://app.circleci.com/pipelines/github/tlaurion/heads/1158/workflows/ee43e8e4-d487-43a9-b705-2caa833c7948

This is really good progress for CircleCI caching! Thanks @SergiiDmytruk !

Hmmm. We would need a way to skip already applied patches if packages cannot be cached, otherwise patches creating files will fail, just like it is happening under https://app.circleci.com/pipelines/github/tlaurion/heads/1158/workflows/ee43e8e4-d487-43a9-b705-2caa833c7948/jobs/9467?invite=true#step-103-3342 for the already created src/syscfg/lock-obj-pub.powerpc64le-unknown-linux-musl.h

The actual logic is that decompressed archives have ./packages/package-version_verify file created after file integrity validation, which tells archives to not be decompressed again nor patched on top of it if it was already downloaded, verified and extracted.

[tlaurion]

Not sure if the following would resolve the issue, but we could:

• skip the strong dependency between build/arch/package_name-version/.canary and ./packages/package_name-version_verify, so that if canary exists, package is not re-extracted and re-patched if package is downloaded while build dir exists (so that patches creating files are not making builds fail if to be created files are already existing in build dir)
• have the packages downloaded under ./arch/packages, but that would be a tweak oriented to CI/CD environments for caching,

No cache is found for key: heads-modules-and-patches-_HRCdgnWzy9K7C1h2vPMrcofQlTuTqUhlZCb+2+6dC4=ci-opt-build
Found a cache from build 1052 at heads-coreboot-musl-cross-vb2jPQCaIG8cDtAF01mvN1JR0NxouC8UzROMPf+3mWo=ci-opt-build
Size: 4.7 GiB
Cached paths:

• /root/project/crossgcc
• /root/project/build/x86/musl-cross-38e52db8358c043ae82b346a2e6e66bc86a53bc1
• /root/project/build/ppc64/musl-cross-38e52db8358c043ae82b346a2e6e66bc86a53bc1
• /root/project/packages
• /root/project/build/x86/coreboot-4.11
• /root/project/build/x86/coreboot-4.13
• /root/project/build/x86/coreboot-4.14
• /root/project/build/x86/coreboot-4.15
• /root/project/build/ppc64/coreboot-git

Downloading cache archive...
Unarchiving cache...

@SergiiDmytruk : It is to note that the builds succeeded because ./packages was part of the cache here too.

[tlaurion]

#1188 was merged, so two additional boards+coreboot config files need #1009 relative fixes
Edit: sorry for the noise, I see you already added the changes https://github.com/osresearch/heads/compare/b787de261c2045c12711d20067819c7073995226..af08530f30bcca76c357c2ede92dde38a3a13181

[tlaurion]

My last attempt didn't have globs and still failed. Judging from the logs the paths should start with project/..., so it might work this time, then can return to experiments with globs.

Exactly what my intuition gave as well seeing https://app.circleci.com/pipelines/github/tlaurion/heads/1155/workflows/16ea4be7-b7da-49a7-bf18-8c744a2a0687/jobs/9392/parallel-runs/0/steps/0-108 output:

Found a cache from build 9230 at heads-modules-and-patches-HPrq963VYPLJeLxLr181U2MT1a3QYHAudaIgR4N9beg=<no value>
Size: 6.4 GiB
Cached paths:
  * /root/project/crossgcc
  * /root/project/build
  * /root/project/packages
  * /root/project/install

Downloading cache archive...
Unarchiving cache...

I think this might work!

As can be seen here, the old cache for heads-modules-and-patches-HPrq963VYPLJeLxLr181U2MT1a3QYHAudaIgR4N9beg (biggest cache available) included packages as well, which explains why builds were successful (_verify and .canary files being present)

[tlaurion]

@SergiiDmytruk please rebase on master where #1009 has been merged.
(So this merge and PR contains only Talos II relative changes.)

Wondering if I should merge #1201 first prior of your master rebasing?

[SergiiDmytruk]

Wondering if I should merge #1201 first prior of your master rebasing?

Rebased. Order shouldn't matter. I don't think the two PRs conflict. This one doesn't add any new patch invocations.

[tlaurion]

@SergiiDmytruk please take a look at https://github.com/tlaurion/heads/tree/replace_util-linux_agetty_busybox_getty which is built on top of this branch.

Basically, those two changes:

• tlaurion@d020609#diff-7906e5e771d8da6406d4081c2f8e0b51443c1dd41b0300f55f50c016034e9077R528
• tlaurion@d020609#diff-63d474ce25ab525343c0d061b286b1cd45199cd14fdf9ea535f396fd8be5de45R140-R142

As a result, we would be not asking all board roms to have a 70kb agetty binary that most do not need to use, where adding getty from busybox costs an additional 1k.

user@heads-tests:/tmp/talos-without-getty-in-busybox$ wget https://output.circle-artifacts.com/output/job/c9af1bd2-335e-4712-bbc9-34d3946ca4ee/artifacts/0/build/ppc64/talos-2_server/initrd.cpio.xz
user@heads-tests:/tmp/talos-without-getty-in-busybox$ xz -d initrd.cpio.xz ; for i in initrd.cpio modules.cpio tools.cpio heads.cpio; do cpio -i < $i; done
user@heads-tests:/tmp/talos-without-getty-in-busybox$ ls bin/busybox -al
-rwx------ 1 user user 724952 Aug 31 12:23 bin/busybox
user@heads-tests:/tmp/talos-without-getty-in-busybox$ ls -al bin/agetty 
-rwx------ 1 user user 68376 Aug 31 12:23 bin/agetty

user@heads-tests:/tmp/testing-getty-in-busybox$ wget https://output.circle-artifacts.com/output/job/64aaf2b4-bf77-4679-8c85-1eff5a92fa3b/artifacts/0/build/ppc64/talos-2_workstation/initrd.cpio.xz
user@heads-tests:/tmp/testing-getty-in-busybox$ xz -d initrd.cpio.xz ; for i in initrd.cpio modules.cpio tools.cpio heads.cpio; do cpio -i < $i; done
user@heads-tests:/tmp/testing-getty-in-busybox$ ls -al bin/busybox 
-rwx------ 1 user user 725040 Aug 31 12:48 bin/busybox

Question of course is to know if it works, build is happening here: https://app.circleci.com/pipelines/github/tlaurion/heads/1181/workflows/500aea6c-a6a9-4009-9251-0e09e24b26b3

[tlaurion]

@SergiiDmytruk feel free to borrow code from tlaurion@143adfd if it is doing its job. I was just a bit against adding util-linux's agetty when busybox could provide the same functionality with near to none footprint.

Just include what is needed and force push.

[SergiiDmytruk]

getty works from a recovery shell (how I tested it), but doesn't seem to work from /init. Doesn't error, just does nothing there. /dev/tty0 should be in the same state there, don't see why it should fail.

How would you include agetty binary only for Talos boards? Something like CONFIG_USE_AGETTY=y in config and then like this in modules/util-linux?

util-linux_agetty-$(CONFIG_USE_AGETTY) := agetty
util-linux_output := $(util-linux_agetty-y)

[tlaurion]

getty works from a recovery shell (how I tested it), but doesn't seem to work from /init. Doesn't error, just does nothing there. /dev/tty0 should be in the same state there, don't see why it should fail.

How would you include agetty binary only for Talos boards? Something like CONFIG_USE_AGETTY=y in config and then like this in modules/util-linux?

util-linux_agetty-$(CONFIG_USE_AGETTY) := agetty
util-linux_output := $(util-linux_agetty-y)

@SergiiDmytruk yes, exactly.
Best example for this is how board config options are encompassing kernel modules to be added by kernel under module/linux.

user@heads-tests:~/heads$ grep -R CONFIG_LINUX_E1000E boards/x230-hotp-maximized modules/ Makefile
boards/x230-hotp-maximized/x230-hotp-maximized.config:CONFIG_LINUX_E1000E=y
boards/x230-hotp-maximized/x230-hotp-maximized.config:#SSH server (requires ethernet drivers, eg: CONFIG_LINUX_E1000E)
modules/linux:linux_modules-$(CONFIG_LINUX_E1000E)	+= drivers/net/ethernet/intel/e1000e/e1000e.ko

[tlaurion]

A more complicated example was for ifdtool under coreboot module, needed to be crosscompiled where ifdtool also needed to be natively compiled for coreboot to continue to be able to pack firmware.

Giving example because this one was relative to module binary, not kernel module as under linux.
Otherwise, everything under Heads is include/exclude as of now, we are now starting to create exceptions :)

a4b5381#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R464-R479