cbmk/config/coreboot/d945gclf_8mb/target.cfg

tree="default"
xarch="i386-elf"
payload_grub="n"
payload_grub_withseabios="n"
payload_seabios="y"
payload_memtest="n"
status="untested"
Canoeboot 20231101 Pull all suitable changes from Libreboot 20231101. Signed-off-by: Leah Rowe <leah@libreboot.org> 2023-11-01 05:18:08 +00:00			`tree="default"`
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"`
Canoeboot 20231101 Pull all suitable changes from Libreboot 20231101. Signed-off-by: Leah Rowe <leah@libreboot.org> 2023-11-01 05:18:08 +00:00			`payload_grub="n"`
			`payload_grub_withseabios="n"`
			`payload_seabios="y"`
			`payload_memtest="n"`
build/roms: report status when building images export CBMK_VERSION_TYPE=x x can be: stable, unstable in target.cfg files, specify: status=x x can be: stable, unstable, broken, untested if unset, cbmk defaults to "unknown" if CBMK_VERSION_TYPE is set, no confirmation is asked if the given target matches what's set (but what's set in that environmental variable can only be stable or unstable) if CBMK_RELEASE="y", no confirmation is asked, unless the target is something other than stable/unstable "unstable" means it works, but has a few non-breaking bugs, e.g. broken s3 on dell e6400 whereas, if raminit regularly fails or it is so absolutely unreliable as to be unusable, then the board should be declared "broken" untested means: it has not been tested With this change, it should now be easier to track whether a given board is tested, in preparation for releases. When working on trees/boards, status can be set for targets. Also: in the board directory, you can add a "warn.txt" file which will display a message. For example, if a board has a particular quirk to watch out for, write that there. The message will be printed during the build process, to stdout. If status is anything other than stable, or it is unstable but CBMK_VERSION_TYPE is not set to "unstable", and not building a release, a confirmation is passed. If the board is not specified as stable or unstable, during a release build, the build is skipped and the ROM is not provided in that release; this is in addition to release="n" or release="y" that can be set in target.cfg, which will skip the release build for that target if "n" Signed-off-by: Leah Rowe <info@minifree.org> 2024-04-26 18:41:00 +00:00			`status="untested"`