[coreboot] MIPS Yamon replacement?

[Robin Randhawa]

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