lbmk/config/coreboot/e6430_12mb/target.cfg

tree="default"
xarch="i386-elf"
payload_seabios="y"
payload_grub="y"
payload_memtest="y"
grub_scan_disk="ahci"
vcfg="ivybridge"
Add Dell Latitude E6430 This was only tested on the iGPU model, though a dGPU model does exist. The vendor firmware used a 16KiB gbe.bin, which was modified with a random MAC address as well as shrinking it to 8KiB. As with the E6400, GRUB doesn't like the way the EC implements the keyboard controller and thus GRUB payloads are disabled at this time. Suspend does not currently work, and this is believed to be due to the EC controlling the DRAM reset gate which is required to prevent DRAM from being reset on resume. With some tweaks, the e6400-flash-unlock utility also works on this system, though both flash chips can be accessed through removal of only the keyboard. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> 2023-09-02 20:44:07 +00:00			`tree="default"`
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"`
Add Dell Latitude E6430 This was only tested on the iGPU model, though a dGPU model does exist. The vendor firmware used a 16KiB gbe.bin, which was modified with a random MAC address as well as shrinking it to 8KiB. As with the E6400, GRUB doesn't like the way the EC implements the keyboard controller and thus GRUB payloads are disabled at this time. Suspend does not currently work, and this is believed to be due to the EC controlling the DRAM reset gate which is required to prevent DRAM from being reset on resume. With some tweaks, the e6400-flash-unlock utility also works on this system, though both flash chips can be accessed through removal of only the keyboard. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> 2023-09-02 20:44:07 +00:00			`payload_seabios="y"`
roms: only support SeaBIOS/SeaGRUB on x86 Never, ever build images where GRUB is the primary payload. These options have been removed from target.cfg handling: * seabios_withgrub * grub_withseabios The "payload_grub" variable now does the same thing as the old "seabios_withgrub" variable, if set. The "grubonly" configuration is retained, and enabled by default when SeaGRUB is enabled (non-grubonly also available). Due to lbmk issue #216, it is no longer Libreboot policy to make GRUB the primary payload on any board. GRUB's sheer size and complexity, plus the large number of memory corruption issues similar to it that have been fixed over the years, tells me that GRUB is a liability when it is the primary payload. SeaBIOS is a much safer payload to run as primary, on x86, due to its smaller size and much more conservative development; it is simply far less likely to break. If GRUB breaks in the future, the user's machine is not bricked. This is because SeaBIOS is the default payload. Since I no longer wish to ever provide GRUB as a primary payload, supporting it in lbmk adds needless bloat that will later probably break anyway due to lack of testing, so let's just assume SeaGRUB in all cases where the user wants to use a GRUB payload. You can mitigate potential security issues with SeaBIOS by disabling option ROM execution, which can be done at runtime by inserting integers into CBFS. The SeaBIOS documentation says how to do this. Libreboot's GRUB hardening guide still says how to add a bootorder file in CBFS, making SeaBIOS only load GRUB from CBFS, and nothing else. This, combined with the disablement of option ROM execution (if using Intel graphics), pretty much provides the same security benefits as GRUB-as-primary, for example when setting a GRUB password and GPG checks, with encrypted /boot as in the hardening guide. Signed-off-by: Leah Rowe <leah@libreboot.org> 2024-06-22 21:57:39 +00:00			`payload_grub="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_memtest="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"`
lib.sh: more unified config handling replace it with logic that simply uses "." to load files directly. for this, "vcfg" is added as a variable in coreboot target.cfg files, referring to a directory in config/vendor/ containing a file named pkg.cfg, and this file then contains the same variables as the erstwhile config/vendor/sources config/git files are now directories, also containing pkg.cfg files each with the same variables as before, such as repository link and commit hash this change results in a noticeable reduction in code complexity within the build system. unified reading of config files: new function setcfg() added to lib.sh setcfg checks if a config exists. if a 2nd argument is passed, it is used as a return value for eval, otherwise a string calling err is passed. setcfg output is passed through eval, to set strings based on config; eval must be used, so that the variables are set within the same scope, otherwise they'd be set within setcfg which could lead to some whacky results. there's still a bit more more to do, but this single change results in a substantial reduction in code complexity. Signed-off-by: Leah Rowe <leah@libreboot.org> 2024-06-22 01:35:25 +00:00			`vcfg="ivybridge"`