[coreboot] Are any Chromebooks able to run fully libre?

[mr.nuke.me at gmail.com]

On Saturday, December 28, 2013 03:01:10 PM Oliver Schinagl wrote:
> On 12/27/13 16:23, Alex G. wrote:
> > On 12/27/2013 04:43 AM, Oliver Schinagl wrote:
> >> That said, how is A13, A20 support for coreboot?
> > 
> > Non-existent. On A10, we're still figuring out how to read from MMC
> > (partially working with code stolen from uboot), and how to init DRAM
> > (hangs with code stolen from uboot).
> 
> Well our u-boot patches are all GPL so feel free to use them, don't need
> to steal ;)
> 
I guess "you cannot steal something that was designed to be free". (For 
detailed explanation, see 'Tron: Legacy').

> There currently is a MMC driver being written and submitted (already) to
> the lkaml etc that should help you out a lot. MMC support is maybe
> 'ugly' in u-boot but should be done reasonable (we rely on it a lot as
> its the main way to boot with our u-boot). SPI i'm working on right now,
> gotta find a way though to hook up an SPI flash module. Nand is very
> very much WiP.
> 
I'm already able to use the uboot code to load anything from microSD. I just 
need to figure out how to sanely incorporate it into our tree. We have a 
pedantic guy who will notice even the most innocent, yet misplaced, space in a 
comment. :p

For SPI, you can just get any DIP SPI flash chip. There are 4 or 5 pins you 
need to connect. No brain surgery needed.

> As for initing of DRAM, that's a horrible affair and i've been putting
> off refactoring that, afraid things may break if things are even in the
> wrong order. The code is a GPL donation from allwinner and based of
> their GPL boot0/boot1 code.
>
At least Allwinner is providing code, that is also suitably licensed, so 
there's no need to reverse engineer binaries.

> besides the 'because you can' why would you want to replace u-boot with
> coreboot here? (I do think it's great to have multiple ways, just
> inquiring).
> 
This whole thing started when I was running fedora on my cubieboard, and after 
a kernel update, uboot decided to not load the new kernel.

On a more practical note, we need to get our feet in the water with this whole 
ARM thing. The A10 has a number of things that we really like:
1. Blob-free (other than the BROM, but that becomes irrelevant once we reach 
our reset vector).
2. It presents a whole new set of problems that need to be addressed. For 
example, how do we load different stages of the boot process from a media that 
is not memory-mapped? How do we handle devices with limited amounts of Cache-
as-RAM (SRAM in this case)? How do we adjust our payload ecosystem to 
accommodate loading the OS kernel?
3. It already has working code (uboot), so we can stay focused on #2, rather 
than also trying to figure out how to get the hardware init working.
4. It has USB OTG, so we're hoping to be able to use that as an EHCI debug 
port (hint: linux gadget driver).

I have already submitted a few fundamental changes to our infrastructure to 
start solving a subset of these problems.

Alex