Skip to content

Refreshed to make it work with coreboot 24.12/25.03#5

Open
micgor32 wants to merge 4 commits into
linuxboot:masterfrom
micgor32:master
Open

Refreshed to make it work with coreboot 24.12/25.03#5
micgor32 wants to merge 4 commits into
linuxboot:masterfrom
micgor32:master

Conversation

@micgor32
Copy link
Copy Markdown

@micgor32 micgor32 commented Jun 7, 2025

As in the title. Apart from that, I have changed a few things:

  • resolving dependencies was limited to Debian and its forks, now it is extended to Fedora and Arch as well.
  • the config was previously setting payload with CONFIG_PAYLOAD_LINUX and setting path to the kernel compiled separately. This is kinda broken in latest coreboot release (at least it never worked for me), so the workaround here is to use CONFIG_PAYLOAD_LINUXBOOT, and CONFIG_LINUXBOOT_COMPILE_KERNEL=y by default, and in case someone wants to provide a different kernel by passing customkern flag. It will then overwrite the default path where coreboot places the kernel.
  • instead of having full config text in the vars in the config.go, both, CONFIG and COREBOOTCONFIG are now embedded on the compile time (not sure whether this is the best way, but I found it a bit cleaner than the previous approach).
  • removed deprecated stuff (for e.g. ioutil and pflag).

Michal Gorlas added 3 commits June 7, 2025 16:13
Signed-off-by: Michal Gorlas <micgor32@fsfe.org>
Signed-off-by: Michal Gorlas <micgor32@fsfe.org>
Signed-off-by: Michal Gorlas <micgor32@fsfe.org>
@micgor32
Copy link
Copy Markdown
Author

micgor32 commented Jun 7, 2025

The last force push was due to me forgetting to signoff the last two commits, so I had to rebase it

@tlaurion
Copy link
Copy Markdown

tlaurion commented Jun 9, 2025

  • the config was previously setting payload with CONFIG_PAYLOAD_LINUX and setting path to the kernel compiled separately. This is kinda broken in latest coreboot release (at least it never worked for me), so the workaround here is to use CONFIG_PAYLOAD_LINUXBOOT, and CONFIG_LINUXBOOT_COMPILE_KERNEL=y by default, and in case someone wants to provide a different kernel by passing customkern flag. It will then overwrite the default path where coreboot places the kernel.

24.12 is used like this under Heads. ie
https://github.com/linuxboot/heads/blob/9fabe7f26cacea874fac6502ddded564ee2f8af5/config/coreboot-x230-maximized.config#L668-L671

CONFIG_PAYLOAD_LINUX=y
CONFIG_PAYLOAD_FILE="@BOARD_BUILD_DIR@/bzImage"
# CONFIG_PXE is not set
CONFIG_LINUX_INITRD="@BOARD_BUILD_DIR@/initrd.cpio.xz"

And

https://github.com/linuxboot/heads/blob/9fabe7f26cacea874fac6502ddded564ee2f8af5/config/coreboot-x230-maximized.config#L235
CONFIG_LINUX_COMMAND_LINE="quiet loglevel=2"

Was wondering what issues you had, while it make sense that linuxboot is used instead; while I thought this was for automatic building of latest version(CONFIG_PAYLOAD_LINUXBOOT) as opposed to static one (CONFIG_PAYLOAD_LINUX). If it is so then not sure what CONFIG_PAYLOAD_LINUX use is nowadays. Should Heads switch to the CONFIG_PAYLOAD_LINUXBOOT?

What were your issues when you tried using CONFIG_PAYLOAD_LINUX?

@micgor32
Copy link
Copy Markdown
Author

micgor32 commented Jun 9, 2025

IIRC I was getting no rule to make target "/abs_path_to/bzImage" quite frequently, so I started to do the automatic build (i.e. let coreboot compile Linux under payloads/external/LinuxBoot/build/Image), and overwriting the image with my custom kernel build. It is possible, however, that I have messed up something in either Makefile or some Kconfig (as the tree I was building on was dirty most of the time). Will check that again.
Anyway, I think the default way for this script should be to use CONFIG_PAYLOAD_LINUXBOOT, because we can then spare the use of kernelGet and buildKernel. For customKern flag, if CONFIG_PAYLOAD_LINUX works (have to check again :D), it is indeed cleaner to use it instead of overwriting payloads/external/LinuxBoot/build/Image.

Should Heads switch to the CONFIG_PAYLOAD_LINUXBOOT?

Not sure, is the kernel you need using any different defconfig than the one under payloads/external/LinuxBoot/x86_64 (or i386)? If so, then no. If not, it could be reasonable.

@micgor32
Copy link
Copy Markdown
Author

micgor32 commented Jun 9, 2025

Ah, the issues were not with CONFIG_PAYLOAD_LINUX but with CONFIG_PAYLOAD_LINUXBOOT and non-default path to the kernel, so for e.g.

CONFIG_PAYLOAD_LINUXBOOT=y
CONFIG_LINUXBOOT_KERNEL_PATH="/tmp/bzImage"
CONFIG_LINUXBOOT_INITRAMFS_PATH="/tmp/initramfs_u-root.cpio.xz"

My bad. Will make another commit where CONFIG_PAYLOAD_LINUX is used if customkern flag is passed.

Signed-off-by: Michal Gorlas <micgor32@fsfe.org>
@micgor32
Copy link
Copy Markdown
Author

micgor32 commented Jun 9, 2025

Will make another commit where CONFIG_PAYLOAD_LINUX is used if customkern flag is passed.

Done.
Also removed buildKern and kernelGet in favour of passing the paths to the "custom" kernel build and initramfs.

@tlaurion
Copy link
Copy Markdown

tlaurion commented Nov 17, 2025

@rminnich @pamolloy @orangecms interested in seeing more collaboration in this repo? Some comments on this PR?

Copy link
Copy Markdown

@orangecms orangecms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent!

Seeing all the chunky config files and hundreds-of-lines strings gone is a huge plus to me. It was a big burden to begin with.

Multi-distro support is 🚀✨ neat.

IMHO, this can be merged ASAP. 🥳

@orangecms
Copy link
Copy Markdown

@rminnich @pamolloy @orangecms interested in seeing more collaboration in this repo? Some comments on this PR?

I love it, thank you for havig me take a look!

Anything that is still open here?
Otherwise, I'd just merge it by the end of the week.
It's been waiting for almost half a year anyway.

@micgor32
Copy link
Copy Markdown
Author

@orangecms thanks for having a look at it! I think the only thing that can still be added to this PR is the default version of coreboot. At the time when this was first submitted, the latest release was 25.03, now it is 25.09. Or the version could also not be hardcoded here at all, but not sure if this is important :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants