[coreboot] Are any Chromebooks able to run fully libre?
gabeblack at google.com
Sat Dec 28 20:27:27 CET 2013
#2 has already largely been addressed in the Exynos, Tegra and Beaglebone
On Dec 28, 2013 2:21 PM, <mr.nuke.me at gmail.com> wrote:
> 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
> 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
> 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
> 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
> 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
> is not memory-mapped? How do we handle devices with limited amounts of
> 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,
> 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.
> coreboot mailing list: coreboot at coreboot.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot