Hi all,
New member here so forgive this question if it's ridiculous.
Has anyone looked at porting Coreboot onto MIPS architecture? Can it be used as a Yamon replacement?
Thanks, Jake
Hi,
On Wed, Mar 26, 2008 at 02:05:50PM -0600, Jake Peavy wrote:
New member here so forgive this question if it's ridiculous.
No bad questions.
Has anyone looked at porting Coreboot onto MIPS architecture? Can it be used as a Yamon replacement?
The only non-x86 arch that has been tried so far is PPC. We aren't opposed to new archs in any way but also do not know/have a lot of them.
//Peter
Hi Jake,
On 26.03.2008 21:05, Jake Peavy wrote:
New member here so forgive this question if it's ridiculous.
The question is actually one I'm really glad to hear.
Has anyone looked at porting Coreboot onto MIPS architecture? Can it be used as a Yamon replacement?
Nobody has looked into it yet, but we welcome all contributions to Coreboot, especially for non-x86 architectures. Please note, though, that the x86 arch (main support area for Coreboot) traditionally has extremely crappy firmware/BIOS compared to any other architecture. I have to admit that I just started to read up on Yamon and it roughly seems to do what we would achieve with a combination of Coreboot and a payload like OpenFirmware.
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.
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.
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.
Regards, Carl-Daniel
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
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
On 27.03.2008 14:15, Marc Karasek wrote:
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.
That fits the bill nicely. Can you three guys coordinate your efforts?
To become more familiar with coreboot, I suggest you try to compile coreboot v3 for the qemu target (run "make menuconfig", exit, run "make", execute qemu with coreboot.rom) and look at the corresponding serial output. It's really verbose and gives you a good idea of the execution path in v3. There should be some qemu tutorial in the coreboot wiki, but I'm not completely sure whether it is about v2 or v3. The qemu command line should be the same, though. If you can't get it to run, please tell us and we'll help.
Regards, Carl-Daniel
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
Hi again.
On Thu, 2008-03-27 at 15:18 +0100, Carl-Daniel Hailfinger wrote:
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.
I see. Sorry, I should've been more specific. Since the reset vector is physical address 0x1FC00000 (which happens to be KSEG1 Addr 0xBFC00000 - but that's getting too involved too soon), system designers ensure that the Boot ROM begins at this address.
In the case of the Malta Evaluation board which MIPS advertises as the evaluation board of choice, there is 4MB of NOR Flash which is mapped at this location onwards.
Cheers, Robin
On 27.03.2008 15:32, Robin Randhawa wrote:
Hi again.
On Thu, 2008-03-27 at 15:18 +0100, Carl-Daniel Hailfinger wrote:
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.
I see. Sorry, I should've been more specific. Since the reset vector is physical address 0x1FC00000 (which happens to be KSEG1 Addr 0xBFC00000 - but that's getting too involved too soon), system designers ensure that the Boot ROM begins at this address.
In the case of the Malta Evaluation board which MIPS advertises as the evaluation board of choice, there is 4MB of NOR Flash which is mapped at this location onwards.
So the flash appears from 0x1FC00000-0x1FFFFFFF and the reset vector is located in the lowest address of the flash? That's what we call a bottom boot block. Bottom boot blocks need my special LAR patch. I'll make sure it will get merged (it was unmerged because we were not sure whether coreboot would ever support architectures with a bottom boot block).
Regards, Carl-Daniel
On Thu, 2008-03-27 at 19:02 +0100, Carl-Daniel Hailfinger wrote:
So the flash appears from 0x1FC00000-0x1FFFFFFF and the reset vector is located in the lowest address of the flash?
Correct.
That's what we call a bottom boot block. Bottom boot blocks need my special LAR patch. I'll make sure it will get merged (it was unmerged because we were not sure whether coreboot would ever support architectures with a bottom boot block).
Excellent.
Cheers, Robin
Jake Peavy wrote:
Hi all,
New member here so forgive this question if it's ridiculous.
Has anyone looked at porting Coreboot onto MIPS architecture? Can it be used as a Yamon replacement?
We looked at porting to MIPS and ARM back in 01 or 02. We even contacted and tried to work together with the U-boot group back in the early days of "LinuxBIOS". U-boot (and YAMON iirc) actually use a cache as ram scheme before ram init similar to Coreboot. Back then U-boot would use cache as ram and hope it would not use up too much space, it didn't always simply work.
U-boot and YAMON were the easier ways to go for and ARM or MIPS SOC's since they already worked and there were lots of supporters.
Coreboot's strength would come in handy if you are going to use an ARM or MIPS cpu along with multiple system buses, PCI controllers and bridges.
-Bari
-
bari -
Carl-Daniel Hailfinger -
Jake Peavy -
Marc Karasek -
Peter Stuge -
Robin Randhawa