Building coreboot for peppy

[John Floren]

I'm trying to work out how to build a coreboot+chromiumos pair using my own keys all the way through, but I'm having a bit of difficulty. We have a peach_pit and a peppy.

1. Mere mortals cannot yet build for peach_pit, it would seem, so that's out.

2. Regarding the peppy, someone more knowledgeable in ChromiumOS than I said I should do "emerge-peppy coreboot chromeos-bootimage" to try building coreboot, but it says "emerge: there are no ebuilds to satisfy "sys-boot/chromeos-mrc" for /build/peppy/" which is not too surprising because Intel.

It seems like if I want to get something done in the meantime, it would make sense to pursue the peppy a bit further. Has anyone successfully extracted the MRC bits from an existing peppy firmware image and slapped them into a freshly-build coreboot?

Additional question, is using emerge the best way to build coreboot for experimentation? I was planning to use my em100 to test firmware, then use flashrom to write it if it actually works.

Thanks,

John

[Duncan Laurie]

Hi John,

You should be able to extract the binary blobs from Peppy using the
image that is provided with the firmware update bundle with Chrome OS.

Several months ago I made some notes on doing this here:
http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/upstream-coreboot-on-intel-haswell-chromebook

It is targeted at using the upstream coreboot repository which worked
at the time this page was written. but may or may not work now given
that I don't regularly test upstream.

If you want to make sure you have a coreboot that is known to work on
Peppy (at least as a starting point) you may want to use coreboot from
the Peppy firmware branch on the chromium server instead of upstream:
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-falco_peppy-4389.B

Another useful resource may be the custom chromebook firmware images
that are collected here:
https://johnlewis.ie/custom-chromebook-firmware/

EM100 is definitely useful for testing this, but without the debug
connector on the board it can be hard to get it attached and hold off
the actual SPI chip so you can use it...

-duncan

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[John Floren]

Thanks Duncan!

I found that wiki article a few days ago and tried it, but while I
think I did it correctly, I see only a black screen when I power on
the chromebook. The "on" light remains on, but nothing is ever
displayed on the screen.

I still have proper ChromeOS installed, which probably won't *boot*
but I thought I might see a splash screen or something.

Is there a preparation step I forgot?

Thanks


John

[Duncan Laurie]

Hi John,

You should see something on the panel when SeaBIOS loads, so something
does seem amiss. A couple possibilities come to mind:

1) It could be something wrong in current upstream coreboot or SeaBIOS
since they can both end up with unrelated changes that break things
subtly and are unable to be tested on all hardware.

2) Is this by chance an i3 peppy? It may have a different PCI device
ID for the internal graphics, which would mean SeaBIOS isn't able to
find and load the option ROM successfully.

This step may need to be tweaked if the PCI device ID for 00:02.0 is not 0x0a06:
cbfstool bios.bin extract -n pci8086,0406.rom -f pci8086,0a06.rom

For debug you could try enabling CONFIG_USBDEBUG and using a USB debug
dongle to try and get some output from coreboot to see if it is
hanging.

However, this isn't something we regularly use here (we can get serial
from the embedded controller out the debug header) and it appears to
have undergone some changes upstream recently so it may or may not
work on Peppy either...

-duncan

[Julius Werner]

> 1. Mere mortals cannot yet build for peach_pit, it would seem, so that's
> out.

I'm not sure if the overlays are all public, but there should be
nothing intrinsically preventing you from building firmware for
peach_pit. If emerge doesn't work, you could still piece together the
necessary steps to compile it from the respective ebuilds and run them
manually (start at sys-boot/chromeos-bootimage and work your way
backwards through the dependencies). You can either build U-Boot as it
shipped, or the experimental coreboot/depthcharge port (enabled with
USE=depthcharge).

There is only one small proprietary blob that the coreboot Makefile
expects in 3rdparty/cpu/samsung/exynos5420/bl1.bin. You can simply
dump the first 8K of any official peach_pit firmware image to get it.

[Mike Frysinger]

On Fri, Aug 29, 2014 at 6:45 PM, Julius Werner <jwe...@chromium.org> wrote:

> 1. Mere mortals cannot yet build for peach_pit, it would seem, so that's
> out.

I'm not sure if the overlays are all public

they are not yet

-mike

[John Floren]

Well, we sorta got part way to a toolchain by making a toolchain.conf
in overlay-peach and copying in overlay-daisy's make.conf, setup_board
completed at least.

However, trying to emerge chromeos-bootimage dies on a dependency for
exynos-preboot. Is this the package that provides that bl1.bin file
you mentioned?

We're looking at building coreboot and such by hand at this moment,
hopefully that will give us some progress.

john

[Mike Frysinger]

coreboot isn't used on peach_pit, only u-boot is, so if your goal is to learn how to build & customize & install coreboot, then peach pit/pi won't help there.

-mike

[Julius Werner]

> However, trying to emerge chromeos-bootimage dies on a dependency for
> exynos-preboot. Is this the package that provides that bl1.bin file
> you mentioned?

Yes, exactly... the only thing that ebuild does is copy the BL1 to
/build/<board>/firmware/u-boot.bl1.bin. Just do that manually and
remove the dependency. (Or actually, that's only for U-Boot... since
we later changed coreboot to track it internally in the 3rdparty/
sub-repo, it shouldn't need the portage dependency at all anymore.)

> coreboot isn't used on peach_pit, only u-boot is, so if your goal is to
> learn how to build & customize & install coreboot, then peach pit/pi won't
> help there.
> -mike

We have experimental support for it. It may not be perfect and might
leave out minor luxuries like SMP or a stable memory configuration,
but it should generally boot and run. With an internal ChromeOS
toolchain you can just do 'USE=depthcharge emerge-peach_pit
chromeos-bootimage' to get it.

[John Floren]

Thanks Julius, I got a package built like that (after making an
overlay-peach_pit because libpayload didn't have a config for "peach")
and extracted it to get the image files, but after loading them into
the em100 we saw the following:

- image.bin and image.rw.bin make the power light come on, then you
have to pull the power and battery to shut it back off. No other signs
of life.
- image.dev.bin, image.dev.bin, and image.serial.bin make the
backlight turn on, but you still have to unplug everything to turn the
laptop back off.

Any thoughts?


John

[Julius Werner]

Hi John,

> - image.dev.bin, image.dev.bin, and image.serial.bin make the
> backlight turn on, but you still have to unplug everything to turn the
> laptop back off.
>
> Any thoughts?

Did you have a UART connected? Without that, I'm afraid you won't get
very far in firmware development. There should be an unstuffed
connector with two rows of 26 pins each close to the SD card slot on
your board. On the row facing towards the SD card the 16th and 17th
pin (counted from pin 1, the closest to the touchpad on that row)
should be the CPU UART Tx and Rx pins you can solder a connector to.
(As usual, opening the case will void your warranty and I'm not
responsible for any fried boards.)

With the UART, you should be able to at least see a few lines coming
out from the image.dev.bin or image.serial.bin images. The turned on
backlight indicates that there is some code running. Also, should
always be able to turn off the machine pressing the power button for 8
seconds (and reboot by pressing Refresh+Power), those are operations
that don't involve the CPU.

You could also try starting with the U-Boot firmware first, since that
is more stable on Pit. If you check out your whole ChromiumOS chroot
on branch cros/firmware-pit-4482.B and build it from there, your
should definitely get a working image. I think with U-Boot you can use
USE=cros-debug to get an image that will turn on a command line prompt
during boot... if you are lucky, even one reading from the keyboard
and outputting to the display.

[David Hendricks]

For what it's worth, I was able to build and boot a coreboot+depthcharge image using top of tree. But my test unit is pretty old, so maybe the newer units require newer DRAM init code. We never shipped coreboot on these devices the code is likely stale.

If you're specifically trying to use coreboot, then you can try syncing the DRAM init code from U-Boot (arch/arm/cpu/armv7/exynos/dmc*) to coreboot (src/soc/samsung/exynos5420/dmc* and src/mainboard/samsung/peach_pit/memory.c). If things don't magically work, rig the UART as Julius described and see where you're getting.

All that said, if you want to learn about running coreboot on ARM platforms, the recently released Acer Chromebook 13 will be much easier to work with since it's fully supported by coreboot. It may be worth it just to save time and effort.

--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.

[Arpita Biswas]

Hi guys, 

I am trying to flash a custom built core boot on peppy (Acer c720) with a bus pirate + flash clip. However, after flashing, I am still stuck with a black screen and the   LEDs on right corner flash intermittently. That's it - it doesn't boot up or even spew any debug msgs on the serial port. Anybody got any ideas on what might be bricking it?

So far, I have done the following steps : 

1. Read a backup copy of original peppy firmware from the chrome book. 

2. Extracted mrc.bin, pci8086,0406.rom from the original

3. Added the following options in menuconfig of coreboot

Mainboard vendor - Google 

Mainboard model - Peppy

ROM chip size - 8 MB

Add a system agent binary - mrc.bin extracted from peppy_firmware.rom

Add a VGA bios - pci8086,0a06.rom

VGA device PCI IDs - 8086,0a06

Enabled USB 2.0 EHCI debug dongle support - type of dongle (Net20DC)

Add a payload - SEABIOS

Payload version - master

4. Configured SEABIOS to use ESC key instead of F12

5. Added a bootsplash screen 

6. Flashed the modified coreboot.rom onto the chip. 

Thanks, 

- Arpita Biswas

Software Engineer, Palo Alto Networks.