#2 has already largely been addressed in the Exynos, Tegra and Beaglebone ports.
Gabe On Dec 28, 2013 2:21 PM, mr.nuke.me@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 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:
- 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