Dear coreboot folks,
Though not supported officially, I’d like to share, that I successfully built the board *QEMU armv7 (vexpress-a9)* with the Debian ARM toolchain from Debian Sid/unstable, and it worked with QEMU 2.8.0.
``` $ /usr/bin/arm-linux-gnueabi-gcc --version | head -1 arm-linux-gnueabi-gcc (Debian 6.3.0-5) 6.3.0 20170124 $ qemu-system-arm -version QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-2) Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers ```
There are three crosscompilers for ARM in Debian.
1. gcc-arm-linux-gnueabi 2. gcc-arm-linux-gnueabihf 3. gcc-arm-none-eabi
I wanted to install none-eabi, but just noticed, that by mistake installed the package *gcc-arm-linux-gnueabi*. (No idea if that matters for emulated boards like QEMU.)
Which one should be correct? The crossgcc script, sets the line below.
``` util/crossgcc/Makefile: @$(MAKE) build_tools BUILD_PLATFORM=arm-eabi ```
Anyway, running the resulting coreboot image with no payload, works.
``` $ git log --oneline -1 231c198e2c mainboard/google/eve: Generate FPC device using SPI SSDT generator $ git describe --tag 4.5-991-g231c198e2c $ build/cbfstool build/coreboot.rom print Name Offset Type Size cbfs master header 0x0 cbfs header 32 fallback/romstage 0x80 stage 8964 fallback/ramstage 0x23c0 stage 17728 config 0x6940 raw 117 revision 0x6a00 raw 575 (empty) 0x6c80 null 4035096 header pointer 0x3dfec0 cbfs header 4 $ qemu-system-arm -machine vexpress-a9 -nographic -bios build/coreboot.rom pulseaudio: set_sink_input_volume() failed pulseaudio: Reason: Invalid argument pulseaudio: set_sink_input_mute() failed pulseaudio: Reason: Invalid argument
coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 bootblock starting... Exception handlers installed. CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 2304
coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 romstage starting... CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 23c0 size 4540
coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 ramstage starting... Exception handlers installed. Enumerating buses... Show all devs... Before device enumeration. Root Device: enabled 1 I2C: 00:06: enabled 1 Compare with tree... Root Device: enabled 1 I2C: 00:06: enabled 1 Root Device scanning... root_dev_scan_bus for Root Device I2C: 00:06 enabled root_dev_scan_bus for Root Device done scan_bus: scanning of bus Root Device took 0 usecs done Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 I2C: 00:06 missing read_resources Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 I2C: 00:06 I2C: 00:06 Setting resources... Root Device assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Show resources in subtree (Root Device)...After assigning values. Root Device child on link 0 I2C: 00:06 I2C: 00:06 Done allocating resources. Enabling resources... done. Initializing devices... Root Device init ... Devices initialized Show all devs... After init. Root Device: enabled 1 I2C: 00:06: enabled 1 Finalize devices... Devices finalized Could not add CBMEM for coreboot table. CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/payload' CBFS: 'fallback/payload' not found. Payload not loaded. ```
So, using the Debian toolchain seems to work quite fine for those wanting to save the time to build the coreboot toolchain. But keep in mind it’s currently not supported officially.
The Debian toolchain also builds working images for the Lenovo X60 (Debian 8 (stable) with GCC 4.9.2) and the ASRock E350M1 (Debian 9 (unstable/sid) with GCC 6.3 (tested since GCC 4.9.2)).
Thanks,
Paul