canoeboot
/
cbmk
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
cbmk/config/coreboot/t60_intelgpu/target.cfg

6 lines
100 B
INI
Raw Normal View History

Update coreboot to LB 20240504 (sync lbmk cd9685d1) With other recent changes, and this patch, Canoeboot is now in sync with Libreboot lbmk, commit: cd9685d12d2b71a00cb6766bb85f392d4db92c83 This is with updated deblobbing, and Canoeboot's no-microcode patches, that disable microcode updates universally. Several patches from lbmk (for coreboot) aren't needed, due to being for boards that Canoeboot does not use, so those patches have been somewhat rebased, and configs adapted, but this is otherwise identical. As in previous Canoeboot updates, I've turned off this option in all coreboot configs: CONFIG_USE_BLOBS Turning off that option prevents the coreboot build system from ever attempting to use any blobs, but in practise it would not have done so anyway, because Canoeboot disables all handling of microcode in the build system. Signed-off-by: Leah Rowe <info@minifree.org>
2024-05-03 01:16:47 +00:00
tree="i945"
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
xarch="i386-elf"
censored libreboot c20230710 Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-10 00:50:01 +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"
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="ahci"