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 - 126.96.36.199-1.1 root (hd0,2) kernel /boot/vmlinuz-188.8.131.52-1.1-default ↪root=/dev/sda3 resume=/dev/sda5 ↪splash=silent showopts vga=0x317 ↪console=ttyS0,115200n8 initrd /boot/initrd-184.108.40.206-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).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Peppermint 7 Released
- Client-Side Performance
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- Profiles and RC Files
- Snappy Moves to New Platforms
- The Giant Zero, Part 0.x
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide