Coreboot at Your Service!
Listing 4. Configuration Parameters for Coreboot v2
1 target epia-m 2 mainboard via/epia-m 3 option MAXIMUM_CONSOLE_LOGLEVEL=8 4 option DEFAULT_CONSOLE_LOGLEVEL=8 5 option CONFIG_CONSOLE_SERIAL8250=1 6 option ROM_SIZE=256*1024 7 option HAVE_OPTION_TABLE=1 8 option CONFIG_ROM_PAYLOAD=1 9 option HAVE_FALLBACK_BOOT=1 10 option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1 11 option FALLBACK_SIZE=131072 12 option _RAMBASE=0x00004000 13 romimage "normal" 14 option USE_FALLBACK_IMAGE=0 15 option ROM_IMAGE_SIZE=64*1024 16 option COREBOOT_EXTRA_VERSION=".0-Normal" 17 payload $ (HOME)/filo/build/filo.elf 18 end 19 romimage "fallback" 20 option USE_FALLBACK_IMAGE=1 21 option ROM_IMAGE_SIZE=60*1024 22 option COREBOOT_EXTRA_VERSION=".0-Fallback" 23 payload $ (HOME)/filo/build/filo.elf 24 end 25 buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
Lines 1 and 2 define the board and board manufacturer that makes the board we're targeting. Lines 3–5 set the logging level. Higher values give you more information, and logging information comes out on a serial (RS-232) port.
Line 6 specifies the size of the Flash (ROM) memory chip on your board.
Line 7 indicates that coreboot may access CMOS memory for getting any parameters—in particular, the boot sequence.
Line 8 specifies that the boot image (payload) is located in ROM. In some situations you will want to load the payload via a serial port. For those cases, use this:
Line 9 sets the strategy used to start coreboot. For example, if the checksum from CMOS-memory is not valid, instead of loading the “normal” part, coreboot must start the backup part—that is, “fallback”.
Line 10 specifies the compression method (NRV2B). Because Flash chip sizes are somewhat limited, you can (or may have to) use a compressed payload. Instead of NRV2B, you can use LZMA—a more-advanced method:
Line 11 specifies the size of the backup (fallback) part: 128kB, half the size of the Flash chip.
Line 12 indicates where exactly in RAM the compressed coreboot will be placed upon power-up.
Lines 13–18 and 19–24 are almost identical except for name and ID. Here you define the “normal” and “fallback” parts. If coreboot can't start the “normal” part for some reason, it will start the reserved, “fallback” part instead.
The last line specifies how the build tool must combine both parts into a single file. See Resources for more information on all of these options.
That's all for the configuration; now compile coreboot for the EPIA-M:
$ cd coreboot-v2/ $ ./buildtarget via/epia-m $ cd via/epia-m/epia-m/ $ make
The coreboot image is ready. The next step is writing it into the Flash chip. To do this, you need a special tool, flashrom, which comes with the coreboot sources:
$ cd coreboot-v2/util/flashrom/ $ make
Before proceeding, take note, if problems occur when writing to the Flash or if you've configured coreboot improperly (such as forgetting to include a payload), you can brick your hardware. Therefore, it's highly recommended that you have a way to restore your BIOS, such as by using BIOS Savior from IOSS (Figure 1).
To write to the Flash chip, execute the following command:
# ./flashrom -w ~/coreboot-v2/targets/via/epia-m/epia-m/coreboot.rom
Then, verify that Flash has been written correctly:
# ./flashrom -v ~/coreboot-v2/targets/via/epia-m/epia-m/coreboot.rom
In order to see boot messages with OpenSUSE 11.0, I first need to modify my GRUB configuration to set the serial line to a speed of 115200 (Listing 5). Now, when I start my EPIA-M, I will be able to see coreboot's output in minicom.
Listing 5. Modifications added to GRUB's menu.lst in order to redirect output to serial port COM1.
serial --unit=0 --speed=115200 terminal serial default 0 timeout 8 gfxmenu (hd0,2)/boot/message title openSUSE 11.0 - 18.104.22.168-1.1 root (hd0,2) kernel /boot/vmlinuz-22.214.171.124-1.1-default ↪root=/dev/sda3 resume=/dev/sda5 ↪splash=silent showopts vga=0x317 ↪console=ttyS0,115200n8 initrd /boot/initrd-126.96.36.199-1.1-default
You now should be ready to reboot, so shut down the EPIA-M, connect a null-modem serial cable, and run minicom:
# minicom -o -8 ttyUSB
Next, restart the EPIA-M, and minicom should show you a GRUB-like boot menu (Figure 2). As the system boots, the operating systems' boot messages also appear in minicom (Figure 3).
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python