#2 has already largely been addressed in the Exynos, Tegra and Beaglebone ports.
Gabe
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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot