I have a lot of prior experience with MIPS based processors (7+years). I took YAMON and hacked it to take out the endianess stuff, added features (bootp support, tcp/ip stack(uip), commands, etc. I have most of the source code I have done for this, my prior company is a dead bug, if I can be of assistance fel free to email me.
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Robin Randhawa wrote:
Greetings.
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.
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.
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).
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.
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.
Cheers, Robin