#2 has already largely been addressed in the Exynos, Tegra and Beaglebone ports.
Gabe On Dec 28, 2013 2:21 PM, <[email protected]> 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: > 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: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
