On 12/24/2013 07:31 PM, Gregg Levine wrote:
Hello! He's complaining about a missing memo regarding Coreboot and such like.
[...]
I must have missed the memo about no coreboot.
Fancy unpacking that statement for those of us who prefer less cryptic expression? :)
Guys! This is getting ridiculous. Somebody forgot to tell me to NOT work on A10 support[1].
[1] http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
Am 25.12.2013 02:53 schrieb Alex G.:
I must have missed the memo about no coreboot.
Fancy unpacking that statement for those of us who prefer less cryptic expression? :)
Guys! This is getting ridiculous. Somebody forgot to tell me to NOT work on A10 support[1].
[1] http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
I saw it, and it is very much appreciated.
Regards, Carl-Daniel
On 12/25/13 02:53, Alex G. wrote:
On 12/24/2013 07:31 PM, Gregg Levine wrote:
Hello! He's complaining about a missing memo regarding Coreboot and such like.
[...]
I must have missed the memo about no coreboot.
Fancy unpacking that statement for those of us who prefer less cryptic expression? :)
Guys! This is getting ridiculous. Somebody forgot to tell me to NOT work on A10 support[1].
I'm sorry Alex! I was unaware!
In any case, I work on the kernel and on u-boot a lot, so any colaboration/questions are more then welcome.
I hope to start cleaning up and improving the DRAM block in u-boot soon (months soon, not weeks :p) so if you have any questions or tips, don't hesitate to send me an e-mail. That said, how is A13, A20 support for coreboot?
Oliver
[1] http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
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). We don't have an infrastructure for block devices, let alone MMC. Our ARM support is still wearing diapers.
Alex
Just to clarify a couple things...
On Fri, Dec 27, 2013 at 7:23 AM, Alex G. mr.nuke.me@gmail.com wrote:
We don't have an infrastructure for block devices, let alone MMC.
Up until now this has been considered the work of the payload. The existing ARM platforms supported in coreboot use SPI ROM to store the firmware.
Our ARM support is still wearing diapers.
In a generic sense, ARM support is working quite well. We've used it on a few different SoCs already, not just in the Exynos family. Most of that code is quite simple and portable.
If you're referring to the relatively few boards we support, that's another matter.
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 ;)
Anyway, as I said, if you need help or thoughts, feel free to poke me or our Mailing list, we are surely interested to also have boot support from coreboot.
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.
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.
We don't have an infrastructure for block devices, let alone MMC. Our ARM support is still wearing diapers.
Understood,
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).
Oliver
Alex
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
#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
-
Alex G. -
Carl-Daniel Hailfinger -
David Hendricks -
Gabe Black -
mr.nuke.me＠gmail.com
-
Oliver Schinagl