From c97a4d903a75a35ebed248a3bacb4f179693a56b Mon Sep 17 00:00:00 2001 From: DiffieHellman Date: Fri, 26 Apr 2024 20:34:51 +0200 Subject: [PATCH] site: faq: don't refer to GNU Boot images as ROMs. One of the definitions of ROM is read-only-memory. Because of that it creates confusion when this term is used to refer to an image that is to be installed on a writable storage. Signed-off-by: DiffieHellman GNUtoo: split commit, commit message. Signed-off-by: Denis 'GNUtoo' Carikli Acked-by: Adrien 'neox' Bourmault --- site/faq.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/site/faq.md b/site/faq.md index 8d4274a..7785b50 100644 --- a/site/faq.md +++ b/site/faq.md @@ -86,9 +86,9 @@ module without loading the option ROM. Refer to the [LinuxBoot website](https://www.linuxboot.org/). This is a special system that uses BusyBox and the Linux kernel, which goes in the boot flash as a -coreboot payload. You can insert it into your GNU Boot ROM image using cbfstool, -if it's big enough. On KCMA-D8/KGPE-D16 it's trivial to upgrade the boot flash -to 16MiB, which is more than enough to fit LinuxBoot. See:\ +coreboot payload. You can insert it into your GNU Boot image using cbfstool, if +it's big enough. On KCMA-D8/KGPE-D16 it's trivial to upgrade the boot flash to +16MiB, which is more than enough to fit LinuxBoot. See:\ [External flashing guide](docs/install/spi.md) LinuxBoot has many advanced features. It provides a bootloader called uroot, @@ -654,14 +654,14 @@ Hi, I have <insert random system here>, is it supported? Most likely not. First, you must consult coreboot's own hardware compatibility list at and, if it is supported, check whether it can run without any -proprietary blobs in the ROM image. If it can: wonderful! GNU Boot can +proprietary blobs in the image. If it can: wonderful! GNU Boot can support it, and you can add support for it. If not, then you will need to figure out how to reverse engineer and replace (or remove) those blobs that do still exist, in such a way where the system is still usable in some defined way. For those systems where no coreboot support exists, you must first port -it to coreboot and, if it can then run without any blobs in the ROM +it to coreboot and, if it can then run without any blobs in the image, it can be added to GNU Boot. See: [Motherboard Porting Guide](http://www.coreboot.org/Motherboard_Porting_Guide) (this is just the tip of the iceberg!) @@ -742,41 +742,41 @@ cases. GNU Boot locks the CMOS table, to ensure consistent functionality for all users. You can use: - nvramtool -C yourrom.rom -w somesetting=somevalue + nvramtool -C yourimage.bin -w somesetting=somevalue To get a full list of available options, do this: - nvramtool -C yourrom.rom -a + nvramtool -C yourimage.bin -a -This will change the default inside that ROM image, and then you can +This will change the default inside that image, and then you can re-flash it. -How do I pad a ROM before flashing? +How do I pad a image before flashing? -------------------------------------- -It is advisable to simply use a larger ROM image. This section was written +It is advisable to simply use a larger image. This section was written mostly for ASUS KCMA-D8 and KGPE-D16 mainboards, where previously we only -provided 2MiB ROM images in GNU Boot, but we now provide 16MiB ROM images. +provided 2MiB images in GNU Boot, but we now provide 16MiB images. Other sizes are not provided because in practice, someone upgrading one of these chips will just use a 16MiB one. Larger sizes are available, but 16MiB is the maximum that you can use on all currently supported systems that use SPI flash. -Required for ROMs where the ROM image is smaller than the flash chip -(e.g. writing a 2MiB ROM to a 16MiB flash chip). +Required for images where the image is smaller than the flash chip +(e.g. writing a 2MiB image to a 16MiB flash chip). Create an empty (00 bytes) file with a size the difference between -the ROM and flash chip. The case above, for example: +the image and flash chip. The case above, for example: truncate -s +14MiB pad.bin -For x86 descriptorless images you need to pad from the *beginning* of the ROM: +For x86 descriptorless images you need to pad from the *beginning* of the image: - cat pad.bin yourrom.rom > yourrom.rom.new + cat pad.bin yourimage.bin > yourimage.bin.new For ARM and x86 with intel flash descriptor, you need to pad after the image: - cat yourrom.rom pad.bin > yourrom.rom.new + cat yourimage.bin pad.bin > yourimage.bin.new Flash the resulting file. Note that cbfstool will not be able to operate on images padded this way so make sure to make all changes to @@ -784,10 +784,10 @@ the image, including runtime config, before padding. To remove padding, for example after reading it off the flash chip, simply use dd(1) to extract only the non-padded portion. Continuing with the -examples above, in order to extract a 2MiB x86 descriptorless ROM from a +examples above, in order to extract a 2MiB x86 descriptorless image from a padded 16MiB image do the following: - dd if=flashromread.rom of=yourrom.rom ibs=14MiB skip=1 + dd if=flashromread.bin of=yourimage.bin ibs=14MiB skip=1 With padding removed cbfstool will be able to operate on the image as usual. @@ -871,7 +871,7 @@ the VBIOS (special kind of OptionROM) is usually embedded in the main boot firmware. For external graphics, the VBIOS is usually on the graphics card itself. This is usually proprietary; the only difference is that SeaBIOS can execute it (alternatively, you embed it -in a coreboot ROM image and have coreboot execute it, if you use a +in a coreboot image and have coreboot execute it, if you use a different payload, such as GRUB). On current GNU Boot systems, instead of VBIOS, coreboot native GPU init is used,