Barebox instead of U-Boot

[Till Klocke]

Hello everyone,

due to a project with embedded hardware I came across the bootloader barebox. It evolved from U-Boot and seems to have much better (organized) code base, has a more powerful shell etc. I really enjoyed working with barebox instead of U-Boot and now I wanted to ask if anyone has thought about using barebox instead of U-Boot or if it is possibly already on some roadmap?

I know that U-Boot has been modified to enable features like verified boot, selection of kernel and root partition etc. but these modification should also be possible for barebox.

So, had anyone had a look at barebox?

Greetings

[Vadim Bendebury]

Til, note that u-boot is not used in recent and upcoming chrome OS
devices anymore. Chrome OS has its own dedicated bootloader now.

--vb

> --
> --
> 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
>

[Mike Frysinger]

well, we're using Coreboot now for all boards ... not really our own dedicated bootloader

-mike

[Vadim Bendebury]

Not to split hairs here, but if you insist: coreboot is not a bootloader. Coreboot is used to initialize hardware and to start the Chrome OS dedicated bootloader.

--vb

[Mike Frysinger]

i wasn't splitting hairs, but being pedantic about firmware/bootloader is pretty nitty.  your response to Till was vague at best, so i was just trying to provide real details.

the fact that coreboot isn't used to load the final OS (Linux) is kind of irrelevant.  coreboot is an early stage bootloader that is usually run as the first thing we control after power on.  depending on the SoC, there might be some vendor logic that is executed first (like Intel's MRC).  but coreboot runs and boots/chains the next stage (depthcharge) and hence is a bootloader.  depthcharge i guess is what you're calling "our own dedicated bootloader" even though it's largely copy & paste from coreboot, and probably should get merged back into coreboot.

coreboot tree:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/

depthcharge tree:

https://chromium.googlesource.com/chromiumos/platform/depthcharge/

-mike

[Gabe Black]

No, it isn't largely copy pasted from coreboot. As a matter of fact, the opposite was frequently true on ARM.

Gabe

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Till Klocke]

Thanks for the interesting replies. So if I want to port ChromiumOS to a new SoC I need to modify depthcharge and coreboot? Is there a document describing the reason for this? In my understanding the bootloader needs to do only a few things. Initialize the hardware, select and verify the partition and kernel to boot from, load the kernel with correct parameters. Or did I miss something important?

At least from my current point of view it looks strange to have coreboot and depthcharge and the need to modify both to get ChromiumOS to boot on a new platform.

[Aaron Durbin]

On Mon, Sep 15, 2014 at 10:21 AM, Till Klocke <till....@gmail.com> wrote:
> Thanks for the interesting replies. So if I want to port ChromiumOS to a new
> SoC I need to modify depthcharge and coreboot? Is there a document
> describing the reason for this? In my understanding the bootloader needs to
> do only a few things. Initialize the hardware, select and verify the
> partition and kernel to boot from, load the kernel with correct parameters.
> Or did I miss something important?
> At least from my current point of view it looks strange to have coreboot and
> depthcharge and the need to modify both to get ChromiumOS to boot on a new
> platform.
>

The current division of labor is that coreboot doesn't have the
bits/flow for loading the kernel. Depthcharge has that logic. Because
of that the 2 projects both need to be updated to handle the ChromeOS
boot flow. A non-ChromeOS boot flow could still use coreboot and a
different kernel loading program (e.g. SeaBIOS on x86 pc systems).

-Aaron

[Till Klocke]

So if I understand this correctly: Depthcharge is for deciding which kernel and rootfs to boot and booting it. Coreboot initializes the hardware and loads depthcharge, but depthcharge chould also be loaded by something different (like U-Boot, barebox, an x86 BIOS etc.)? But if Coreboot just initializes the hardware, why not move this functionality to depthcharge? This way you have to modify to projects with low level hardware stuff and no possibility of sharing code.

[Aaron Durbin]

On Mon, Sep 15, 2014 at 10:39 AM, Till Klocke <till....@gmail.com> wrote:
> So if I understand this correctly: Depthcharge is for deciding which kernel
> and rootfs to boot and booting it. Coreboot initializes the hardware and
> loads depthcharge, but depthcharge chould also be loaded by something
> different (like U-Boot, barebox, an x86 BIOS etc.)? But if Coreboot just
> initializes the hardware, why not move this functionality to depthcharge?
> This way you have to modify to projects with low level hardware stuff and no
> possibility of sharing code.

I think that's a fair assessment w.r.t. making changes in 2 different
places. However, the code in depthcharge is more of driver
infrastructure for peripherals. I can't recall any hardware
initialization in depthcharge off the top of my head, but this may be
a disagreement in terms. I consider "hardware initialization" to be
setting up memory, configuring gpios per board use, etc.

You are right that it is possible to place the code/logic on either
side of the current coreboot/depthcharge split. And for certain
drivers, that definitely requires duplication. I'm not a fan of code
duplication either, but this how things are currently structured --
for better or worse. I will say, though, that having the vast majority
of the hardware bits in coreboot (or a single place) allows for reuse
of the SoC support. Since coreboot is designed to be agnostic to the
"payload" (depthcharge in ChromeOS) then it means people can reuse
that support for an SoC while using a different kernel loader w/o
being married to ChromeOS's kernel loader.

Hope that helps.

-Aaron

[Vadim Bendebury]

On Mon, Sep 15, 2014 at 8:39 AM, Till Klocke <till....@gmail.com> wrote:

So if I understand this correctly: Depthcharge is for deciding which kernel and rootfs to boot and booting it. Coreboot initializes the hardware and loads depthcharge, but depthcharge chould also be loaded by something different (like U-Boot, barebox, an x86 BIOS etc.)? But if Coreboot just initializes the hardware, why not move this functionality to depthcharge? This way you have to modify to projects with low level hardware stuff and no possibility of sharing code.

Depthcharge is meant to be as hardware agnostic as possible - its main function is to decide which one of the two available kernel instances to boot, or declare that there is not good kernel and fall back into recovery mode. This logic is the same on all platforms.

Of course this is easier said than done, and drivers for i2c/spi/usb/ssd/emmc are required for new SOCs in case their controllers are different from the ones used earlier; platform startup code is required for new platforms (x86/arm/mips/...).

A few x86 chromebooks used coreboot for hardware initialization and u-boot for loading the OS, in this sense depthcharge is a replacement for u-boot.

--vb

[Arpita Biswas]

On a similar note, can we use Coreboot + SeaBIOS ? Coreboot for all hardware initializations and then SeaBIOS as the payload,  instead of UBoot ? I was trying to flash Peppy with SeaBIOS as noted in the tutorial, but it stops at :

PCH watchdog disabled 

Jumping to boot code at 000fd55a(7bf6a000)

CPU0: stack: 7bfee000 - 7bfef000, lowest used address 7bfee908, stack used: 1784 bytes. 

On comparing with bios log of the original bios, the boot code address is different :

PCH watchdog disabled

Jumping to boot code at 02104020

CPU0: stack: 7bfde000 - 7bfdf000, lowest used address 7bfdead8, stack used: 1320 bytes

Any pointers on what could be the issue ? My guess is that the Entry point in case (1) is below 1 MiB and probably caused due to incorrect payload. Is it so ?

Thanks in advance!

- Arpita 

[Stefan Reinauer]

Arpita,

did you compile SeaBIOS with support for coreboot and serial console?

SeaBIOS ships as "legacy boot mode" (CTRL-L at the dev mode screen) on most x86 Chrome OS devices now, and is generally working.

From your log it looks like coreboot is loading SeaBIOS fine, but then SeaBIOS does not provide any output.

Stefan

--

[Arpita Biswas]

Hi Stefan, 

Nope. I did not make any config changes to SeaBIOS. Just make menuconfig from coreboot --> payload --> SeaBIOS --> master. Although now that you mention, it looks like I should be doing some changes to SeaBIOS's config too. 

Thanks for the pointer. I will tinker with SeaBIOS and get back if I get stuck again ! 

- Arpita 

[Arpita Biswas]

Update : 

I compiled SeaBIOS separately with the following settings in seabios/.config: 

CONFIG_COREBOOT=y

CONFIG_DEBUG_LEVEL=8

CONFIG_DEBUG_SERIAL is not set

CONFIG_DEBUG_COREBOOT=y

Then, updated coreboot's .config as payload --> Add a payload --> coreboot/payloads/external/SeaBIOS/seabios/out/bios.bin.elf

The VGA bios I am using is the one I extracted from Peppy's original bios.bin -- pci8086,0a06.rom . Do I need to enable any further settings ?

Thanks,

- Arpita