libreboot
/
lbmk
1
0
Fork 0
Code Packages Projects Releases Activity
lbmk/config/coreboot/kcma_d8-udimm_16mb/target.cfg

11 lines
195 B
INI
Raw Normal View History

merge coreboot/u-boot download logic to one script they are fundamentally the same, in an lbmk context. they are downloaded in the same way, and compiled in the same way! (Kconfig infrastructure, board-specific code, the way submodules are used in git, etc) ~200 sloc reduction in resources/scripts the audit begins Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-16 20:34:21 +00:00
tree="fam15h_udimm"
fam15h boards: define xtree these should be using the rdimm tree for crossgcc, so define it explicitly. the build system creates a symlink too, but it's still best that we use it. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-21 22:19:04 +00:00
xtree="fam15h_rdimm"
update/trees: further simplify crossgcc handling arch no longer needs to be set, on multi-tree projects, and it has been renamed to xarch the new behaviour is: if xarch is set, treat it as a list of crossgcc targets and go through the list. set the first one as the target, for what lbmk builds, but build all of the defined crossgccc targets crossgcc_ada is now xlang, and defines which languages to build, rather than whether to build gcc-gnat Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-27 15:18:21 +00:00
xarch="i386-elf"
coreboot: re-add asus kgpe-d16/kcma-d8/kfsn4-dre Libreboot 20220710 was the last release to support these boards. I plan to eventually port code differences between D8/D16 to Dasharo, for KCMA-D8 support in Dasharo, to then use in Libreboot for both KCMA-D8 and KGPE-D16, but I have no plans to update the KFSN4-DRE code, at least for now. Libreboot 20220710 used coreboot 4.11, whereas this patch makes use of coreboot 4.11_branch; the crossgcc toolchains no longer compile on modern distros, so I spent time patching those (tested in Debian Sid, will also work on Arch Linux and so on). The acpica downloads now fail, in 4.11_branch, because Intel made some changes upstream for these tarball downloads. Newer coreboot works around this by grabbing tarballs from github, itself a non-ideal solution, but I digress; this patch changes coreboot crossgcc (in 4.11_branch) to download the acpica tarball from libreboot rsync, where I've added it. This patch also re-introduces the PIKE2008 fix, where empty option ROMs for these are inserted into CBFS. This prevents SeaBIOS from loading the real option ROMs, which would cause SeaBIOS to hang. This means that SAS drives are not supported in SeaBIOS, for these boards in Libreboot. I previously said, in the Censored Libreboot c20230710 announcement, that I would *only* merge D8/D16 when I've added Dasharo support to Libreboot, and use that, but the work to make coreboot 4.11_branch compile is something I'm quite proud of and I see no reason to exclude from lbmk master branch. Honestly, there's not much different than 4.11, code-wise. I *probably* won't use 4.11_branch for the next Libreboot release, on D8/D16. By then, I might have Dasharo integrated in lbmk instead. We shall see. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-16 02:18:58 +00:00
payload_seabios="y"
coreboot: only run GRUB as a secondary payload See: https://codeberg.org/libreboot/lbmk/issues/216 Almost all users will be OK running GRUB, but a minority of users have experienced a fatal error pertaining to grub_free() or grub_realloc() (as my investigation of GRUB sources reveal when grepping the error reported in the link above). We don't yet know what the bug is, only that the error occurs, leading to an effective brick if the user has GRUB as their primary payload. So far, it has only been reported on some Intel SandyBridge-based Dell Latitudes in Libreboot, but we can't be too sure. The user reported that memtest86+ passes just fine, and SeaBIOS works; BIOS GRUB also works, which means that the bug is likely only in an area of GRUB that runs specifically on the coreboot payload, so it's probably a driver in GRUB when running on the metal rather than BIOS/UEFI. The build system supports a configuration whereby SeaBIOS is the primary payload, but GRUB is available in the SeaBIOS boot select menu, and an additional configuration is available where GRUB is what SeaBIOS executes first (while still providing boot select); both of these are now the *only* configurations available, on all x86 targets except QEMU. The QEMU target is fine because if the bug occurs there, you can just close QEMU and try a different image. Even after this bug is later identified and fixed, the GRUB source code is vastly over-engineered and there are likely many more such bugs. SeaBIOS is a reliable payload; the code is small and robust. Remember always: Code equals bugs Therefore, this configuration change is likely going to be permanent. This will apply in the next release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 13:24:26 +00:00
payload_seabios_withgrub="y"
coreboot: re-add asus kgpe-d16/kcma-d8/kfsn4-dre Libreboot 20220710 was the last release to support these boards. I plan to eventually port code differences between D8/D16 to Dasharo, for KCMA-D8 support in Dasharo, to then use in Libreboot for both KCMA-D8 and KGPE-D16, but I have no plans to update the KFSN4-DRE code, at least for now. Libreboot 20220710 used coreboot 4.11, whereas this patch makes use of coreboot 4.11_branch; the crossgcc toolchains no longer compile on modern distros, so I spent time patching those (tested in Debian Sid, will also work on Arch Linux and so on). The acpica downloads now fail, in 4.11_branch, because Intel made some changes upstream for these tarball downloads. Newer coreboot works around this by grabbing tarballs from github, itself a non-ideal solution, but I digress; this patch changes coreboot crossgcc (in 4.11_branch) to download the acpica tarball from libreboot rsync, where I've added it. This patch also re-introduces the PIKE2008 fix, where empty option ROMs for these are inserted into CBFS. This prevents SeaBIOS from loading the real option ROMs, which would cause SeaBIOS to hang. This means that SAS drives are not supported in SeaBIOS, for these boards in Libreboot. I previously said, in the Censored Libreboot c20230710 announcement, that I would *only* merge D8/D16 when I've added Dasharo support to Libreboot, and use that, but the work to make coreboot 4.11_branch compile is something I'm quite proud of and I see no reason to exclude from lbmk master branch. Honestly, there's not much different than 4.11, code-wise. I *probably* won't use 4.11_branch for the next Libreboot release, on D8/D16. By then, I might have Dasharo integrated in lbmk instead. We shall see. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-16 02:18:58 +00:00
payload_memtest="y"
update/trees: further simplify crossgcc handling arch no longer needs to be set, on multi-tree projects, and it has been renamed to xarch the new behaviour is: if xarch is set, treat it as a list of crossgcc targets and go through the list. set the first one as the target, for what lbmk builds, but build all of the defined crossgccc targets crossgcc_ada is now xlang, and defines which languages to build, rather than whether to build gcc-gnat Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-27 15:18:21 +00:00
xlang="c"
coreboot: only run GRUB as a secondary payload See: https://codeberg.org/libreboot/lbmk/issues/216 Almost all users will be OK running GRUB, but a minority of users have experienced a fatal error pertaining to grub_free() or grub_realloc() (as my investigation of GRUB sources reveal when grepping the error reported in the link above). We don't yet know what the bug is, only that the error occurs, leading to an effective brick if the user has GRUB as their primary payload. So far, it has only been reported on some Intel SandyBridge-based Dell Latitudes in Libreboot, but we can't be too sure. The user reported that memtest86+ passes just fine, and SeaBIOS works; BIOS GRUB also works, which means that the bug is likely only in an area of GRUB that runs specifically on the coreboot payload, so it's probably a driver in GRUB when running on the metal rather than BIOS/UEFI. The build system supports a configuration whereby SeaBIOS is the primary payload, but GRUB is available in the SeaBIOS boot select menu, and an additional configuration is available where GRUB is what SeaBIOS executes first (while still providing boot select); both of these are now the *only* configurations available, on all x86 targets except QEMU. The QEMU target is fine because if the bug occurs there, you can just close QEMU and try a different image. Even after this bug is later identified and fixed, the GRUB source code is vastly over-engineered and there are likely many more such bugs. SeaBIOS is a reliable payload; the code is small and robust. Remember always: Code equals bugs Therefore, this configuration change is likely going to be permanent. This will apply in the next release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 13:24:26 +00:00
grub_timout=10
re-configure grub_scan_disk on various targets Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 20:33:53 +00:00
grub_scan_disk="nvme ahci"
grub: only enable nvme if needed on a board remove nvme support from the "default" grub tree now there are three trees: * default: no xhci or nvme patches * nvme: contains nvme support * xhci: contains xhci and nvme support this is in case a bug like lbmk issue #216 ever occurs again, as referenced before during lbmk audit 5 there is no indication that the nvme patch causes any issues, but after previous experience i want to be sure Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-11 23:58:22 +00:00
grubtree="nvme"