<p dir="ltr">#2 has already largely been addressed in the Exynos, Tegra and Beaglebone ports.</p>
<p dir="ltr">Gabe</p>
<div class="gmail_quote">On Dec 28, 2013 2:21 PM,  <<a href="mailto:mr.nuke.me@gmail.com">mr.nuke.me@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Saturday, December 28, 2013 03:01:10 PM Oliver Schinagl wrote:<br>
> On 12/27/13 16:23, Alex G. wrote:<br>
> > On 12/27/2013 04:43 AM, Oliver Schinagl wrote:<br>
> >> That said, how is A13, A20 support for coreboot?<br>
> ><br>
> > Non-existent. On A10, we're still figuring out how to read from MMC<br>
> > (partially working with code stolen from uboot), and how to init DRAM<br>
> > (hangs with code stolen from uboot).<br>
><br>
> Well our u-boot patches are all GPL so feel free to use them, don't need<br>
> to steal ;)<br>
><br>
I guess "you cannot steal something that was designed to be free". (For<br>
detailed explanation, see 'Tron: Legacy').<br>
<br>
> There currently is a MMC driver being written and submitted (already) to<br>
> the lkaml etc that should help you out a lot. MMC support is maybe<br>
> 'ugly' in u-boot but should be done reasonable (we rely on it a lot as<br>
> its the main way to boot with our u-boot). SPI i'm working on right now,<br>
> gotta find a way though to hook up an SPI flash module. Nand is very<br>
> very much WiP.<br>
><br>
I'm already able to use the uboot code to load anything from microSD. I just<br>
need to figure out how to sanely incorporate it into our tree. We have a<br>
pedantic guy who will notice even the most innocent, yet misplaced, space in a<br>
comment. :p<br>
<br>
For SPI, you can just get any DIP SPI flash chip. There are 4 or 5 pins you<br>
need to connect. No brain surgery needed.<br>
<br>
> As for initing of DRAM, that's a horrible affair and i've been putting<br>
> off refactoring that, afraid things may break if things are even in the<br>
> wrong order. The code is a GPL donation from allwinner and based of<br>
> their GPL boot0/boot1 code.<br>
><br>
At least Allwinner is providing code, that is also suitably licensed, so<br>
there's no need to reverse engineer binaries.<br>
<br>
> besides the 'because you can' why would you want to replace u-boot with<br>
> coreboot here? (I do think it's great to have multiple ways, just<br>
> inquiring).<br>
><br>
This whole thing started when I was running fedora on my cubieboard, and after<br>
a kernel update, uboot decided to not load the new kernel.<br>
<br>
On a more practical note, we need to get our feet in the water with this whole<br>
ARM thing. The A10 has a number of things that we really like:<br>
1. Blob-free (other than the BROM, but that becomes irrelevant once we reach<br>
our reset vector).<br>
2. It presents a whole new set of problems that need to be addressed. For<br>
example, how do we load different stages of the boot process from a media that<br>
is not memory-mapped? How do we handle devices with limited amounts of Cache-<br>
as-RAM (SRAM in this case)? How do we adjust our payload ecosystem to<br>
accommodate loading the OS kernel?<br>
3. It already has working code (uboot), so we can stay focused on #2, rather<br>
than also trying to figure out how to get the hardware init working.<br>
4. It has USB OTG, so we're hoping to be able to use that as an EHCI debug<br>
port (hint: linux gadget driver).<br>
<br>
I have already submitted a few fundamental changes to our infrastructure to<br>
start solving a subset of these problems.<br>
<br>
Alex<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>