[coreboot] MIPS Yamon replacement?

Marc Karasek Marc.Karasek at Sun.COM
Thu Mar 27 14:15:32 CET 2008

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
Sun Microsystems
mailto:marc.karasek at sun.com

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

More information about the coreboot mailing list