Hi,
On 27.03.2008 09:10, Robin Randhawa wrote:
On Thu, 2008-03-27 at 02:54 +0100, Carl-Daniel Hailfinger wrote:
Coreboot is designed to make lowlevel init fast and easy with clean and well-structured code, supporting diverse payloads. Target settings (northbridge, southbridge, SuperI/O) are compiled in except for the usual bus probing stuff. A Coreboot MIPS target could do it all differently, though. Unfortunately linux-mip.org is down and I could not find out whether Yamon really tries to support all available hardware with one binary. That would be impossible in the x86 world due to inability to probe certain stuff and due to size constraints.
Firstly, linux-mips.org is being relocated and should be back up in a week or so. I was told that a backup version on a leaner pipe is accessible though.
Thanks for the info.
To answer your question, Yamon, as provided by MIPS does indeed attempt to support all MIPS cores and platforms built around them which yields binaries of significant sizes. The problem is further compounded by Yamon's bi-endian support which is basically some early init endian-neutral code which jumps to one of 2 images of different endianness as needed after probing. They have a kind of abstracted design where one can register a core and a platform (system controller, south bridges etc) which has a lot of indirections and isn't very easy to debug.
Ugh. At least probing is somewhat possible.
Bear in mind that Yamon's design goals were intentional - to have one mega-image for the world - and that isn't necessarily what is needed for all platforms. For example u-boot supports MIPS based platforms such as the IncaIP etc and it only has common processor identification and init code followed by platform specific stuff (which shares code when possible, of course).
So we'd probably handle MIPS in a way similar to what u-boot does.
If you decide to look into Coreboot MIPS support, please don't study coreboot v2. The coreboot v3 architecture is a lot cleaner because we learned a lot with previous generations, the code is nicer and we even have a design document which is reasonably accurate. Of course, if the MIPS angle shows considerable problems with the current Coreboot v3 design, we'd be happy to hear about it to improve the design.
Getting my hands dirty with Coreboot has been on my mind since a bit. I've just ended up with some MIPS based development boards which were being essentially thrown away by my employer (MIPS incidentally). These were made by Algorithmics (which got taken over by MIPS in the 90s) and are nifty embedded platforms with 64-bit cores such as the NEC VR4300 (Of Nintendo fame) and QED 52xx. While these are a bit dated, I hope to work with Coreboot on these in my spare time.
Great, so we now have three people interested in working on MIPS support: Robin, Jake and Marc.
By the way, it would be nice to know how execution starts on MIPS (top or bottom of address space). I have a patch which adds handling for bottom-booting architectures to v3, but so far we have seen no use case.
Traditionally, the MIPS reset vector has been in what is known as the KSEG1 window which is an uncached view of the lower 512MB of physical memory and is accessible from physical address 0x1FC00000 onwards. I'll be happy to provide any hints if you need them.
Good. Now I just need to know how the ROM is mapped into that window.
Regards, Carl-Daniel