On 27.03.2008 04:19, Jake Peavy wrote:
I'd be interested in trying to help with this effort. It would be certainly be a learning experience for me.
If Coreboot has been ported to PPC it might be very similar. Both PPC and MIPS architectures are RISC based, but maybe that's where the similarities end.
Well, only v2 has been ported to PPC and the structure of v3 is radically different. However, the v3 structure allows much easier porting, so I think v3 would be your preferred target.
Based on http://www.mips.com/media/files/MD00103-2B-4KE-SUM-02.04.pdfsection 6.1.5, MIPS execution begins at 0x1FC00000. At least on the MIPS32 core I have ;-)
I assume MIPS boards have some sort of ROM. How is that ROM mapped into the address space? Does execution begin at top of ROM, bottom of ROM or somewhere in between? That info is needed to check if our current ROM format (LAR) can handle MIPS or if we need to apply one of my patches.
You mentioned payload, is this typically the S1 (MBR) code in x86 arch?
It's a bit more complicated like that. A payload can either be a boot loader (like GRUB2/FILO) or an operating system (like Plan 9/Linux). It can also be some sort of bootloader-with-shell environment (like EFI/OpenFirmware) or something with a completely different scope (like Memtest).
Regards, Carl-Daniel
On Thu, Mar 27, 2008 at 03:14:36PM +0100, Carl-Daniel Hailfinger wrote:
On 27.03.2008 04:19, Jake Peavy wrote:
I'd be interested in trying to help with this effort. It would be certainly be a learning experience for me.
If Coreboot has been ported to PPC it might be very similar. Both PPC and MIPS architectures are RISC based, but maybe that's where the similarities end.
Well, only v2 has been ported to PPC and the structure of v3 is radically different. However, the v3 structure allows much easier porting, so I think v3 would be your preferred target.
Yep, definately.
v2 (or was it v1?) also had some support for Alpha, btw.
Based on http://www.mips.com/media/files/MD00103-2B-4KE-SUM-02.04.pdfsection 6.1.5, MIPS execution begins at 0x1FC00000. At least on the MIPS32 core I have ;-)
I assume MIPS boards have some sort of ROM. How is that ROM mapped into the address space?
Also, are there generic "PC"-like machines with a standard "ROM chip" as in x86-world, or are they exclusively embedded boards? How would you go about flashing such a board? Can flashrom be hacked to support them or do you usually use some sort of JTAG interface?
Uwe.
On Fri, 2008-03-28 at 00:55 +0100, Uwe Hermann wrote:
On Thu, Mar 27, 2008 at 03:14:36PM +0100, Carl-Daniel Hailfinger wrote:
Well, only v2 has been ported to PPC and the structure of v3 is radically different. However, the v3 structure allows much easier porting, so I think v3 would be your preferred target.
Yep, definately.
v2 (or was it v1?) also had some support for Alpha, btw.
Interesting.
I assume MIPS boards have some sort of ROM. How is that ROM mapped into the address space?
Please see my previous reply to Carl in this thread.
Also, are there generic "PC"-like machines with a standard "ROM chip" as in x86-world, or are they exclusively embedded boards?
While I have never played with them, there are a host of such machines based on MIPS processors made by SGI and Sun which I assume would have such standard "ROM chips".
The prevalent market as of now is of course the embedded space where MIPS processors have proliferated into networking gear, set top boxes, game consoles etc. The thumb rule is that MIPS tries to position itself wherever ARM does, but with a lot less luck. :)
How would you go about flashing such a board?
To quote an example of the "prescribed" method : For a while, I was working with a MIPS Malta board which is a baseboard containing the Intel PIIX based southbridge and the peripheral buses including the Flash at the reset vector. A number of "core cards" can be dropped onto the Malta which contain a supported MIPS core and a system controller (usually a Galileo GT64120 or one of several MIPS' in house controllers such as the Bonito etc).
Anyways, they stuck in some code in a CPLD on the baseboard which ran only if a physical switch was flipped and which would emulate a USB printer over the bus. You could then write an SREC firmware image to this printer from the host and the CPLD code would do the Flash unlock-erase-program bits.
Fortunately (or otherewise) I do not have a Malta which is an expensive beast. On the other hand, the board I do have is an Algorithmics P4032 which has the ability to conditionally (the condition being a jumper setting) boot off an external Flash chip for which there is a DIP socket provided which makes my task very easy. I just have to put in some working firmware such as pmon (which supports this board) onto the external Flash and then I can use it to program the board's internal boot flash mapped at 0x1FC00000 as much as I like (get images off of ethernet/RS-232 etc). This is what I aim to do basically, once I can get someone with a Flash programmer to sort things out for me initially.
Another idea I am playing with is to use GXEmul [http://gavare.se/gxemul/] which is a system emulator (not just the core). It currently supports the P5042 which is a souped up P4032. If I could get GXEmul to support my board, I have an excellent test bed ready to use. More on my experiments with this later.
Can flashrom be hacked to support them or do you usually use some sort of JTAG interface?
I'm not aware of flashrom just yet but most MIPS boards do have a JTAG interface which needs to be used with an emulator and (usually proprietary) software.
Cheers, Robin
On 28.03.2008 09:34, Robin Randhawa wrote:
On Fri, 2008-03-28 at 00:55 +0100, Uwe Hermann wrote:
On Thu, Mar 27, 2008 at 03:14:36PM +0100, Carl-Daniel Hailfinger wrote:
Also, are there generic "PC"-like machines with a standard "ROM chip" as in x86-world, or are they exclusively embedded boards?
While I have never played with them, there are a host of such machines based on MIPS processors made by SGI and Sun which I assume would have such standard "ROM chips".
The prevalent market as of now is of course the embedded space where MIPS processors have proliferated into networking gear, set top boxes, game consoles etc. The thumb rule is that MIPS tries to position itself wherever ARM does, but with a lot less luck. :)
High-speed switches/routers from Extreme Networks run with a MIPS64 CPU. It fits the definition of embedded, but I wouldn't claim they care much about power consumption.
How would you go about flashing such a board?
To quote an example of the "prescribed" method : For a while, I was working with a MIPS Malta board which is a baseboard containing the Intel PIIX based southbridge and the peripheral buses including the Flash at the reset vector. A number of "core cards" can be dropped onto the Malta which contain a supported MIPS core and a system controller (usually a Galileo GT64120 or one of several MIPS' in house controllers such as the Bonito etc).
Was the flash attached to the PIIX?
Anyways, they stuck in some code in a CPLD on the baseboard which ran only if a physical switch was flipped and which would emulate a USB printer over the bus. You could then write an SREC firmware image to this printer from the host and the CPLD code would do the Flash unlock-erase-program bits.
OK, so the CPLD acted as the programmer.
Fortunately (or otherewise) I do not have a Malta which is an expensive beast. On the other hand, the board I do have is an Algorithmics P4032 which has the ability to conditionally (the condition being a jumper setting) boot off an external Flash chip for which there is a DIP socket provided which makes my task very easy. I just have to put in some working firmware such as pmon (which supports this board) onto the external Flash and then I can use it to program the board's internal boot flash mapped at 0x1FC00000 as much as I like (get images off of
Sorry, I don't follow. How do you use the external flash to program the internal flash?
ethernet/RS-232 etc). This is what I aim to do basically, once I can get someone with a Flash programmer to sort things out for me initially.
Another idea I am playing with is to use GXEmul [http://gavare.se/gxemul/] which is a system emulator (not just the core). It currently supports the P5042 which is a souped up P4032. If I could get GXEmul to support my board, I have an excellent test bed ready to use. More on my experiments with this later.
Can flashrom be hacked to support them or do you usually use some sort of JTAG interface?
I'm not aware of flashrom just yet but most MIPS boards do have a JTAG interface which needs to be used with an emulator and (usually proprietary) software.
Short version: On most x86 machines, you can program EEPROM boot flash chips in-circuit. Most of these chips are attached to a LPC bus and after issuing a series of writes over LPC to predefined addresses of the flash chip, the flash chip enables erasing/writing to the chip. Chip identification is done the same way. The coreboot flashrom utility performs all these actions and eliminates the need for a special hardware programmer.
Regards, Carl-Daniel
On Fri, 2008-03-28 at 12:49 +0100, Carl-Daniel Hailfinger wrote:
High-speed switches/routers from Extreme Networks run with a MIPS64 CPU. It fits the definition of embedded, but I wouldn't claim they care much about power consumption.
I agree.
How would you go about flashing such a board?
To quote an example of the "prescribed" method : For a while, I was working with a MIPS Malta board which is a baseboard containing the Intel PIIX based southbridge and the peripheral buses including the Flash at the reset vector. A number of "core cards" can be dropped onto the Malta which contain a supported MIPS core and a system controller (usually a Galileo GT64120 or one of several MIPS' in house controllers such as the Bonito etc).
Was the flash attached to the PIIX?
Not in this case. There's a MIPS peripheral bus called the CBUS which allowed access to the Flash and is mastered by the system controller. So you first initialise the Processor<->Syscon Interface, then setup the CBUS and you then have access to the Flash directly (Its CFI compliant NOR Flash).
Anyways, they stuck in some code in a CPLD on the baseboard which ran only if a physical switch was flipped and which would emulate a USB printer over the bus. You could then write an SREC firmware image to this printer from the host and the CPLD code would do the Flash unlock-erase-program bits.
OK, so the CPLD acted as the programmer.
Exactly.
Fortunately (or otherewise) I do not have a Malta which is an expensive beast. On the other hand, the board I do have is an Algorithmics P4032 which has the ability to conditionally (the condition being a jumper setting) boot off an external Flash chip for which there is a DIP socket provided which makes my task very easy. I just have to put in some working firmware such as pmon (which supports this board) onto the external Flash and then I can use it to program the board's internal boot flash mapped at 0x1FC00000 as much as I like (get images off of
Sorry, I don't follow. How do you use the external flash to program the internal flash?
I first boot off the external flash which will contain the legacy pmon firmware (I still need to figure out how to program it there). I then have access to the internal boot flash which I can erase/write using the pmon CLI. A bit round-about, I know. There probably is a JTAG route to it as well but I do not have that luxury.
I'm not aware of flashrom just yet but most MIPS boards do have a JTAG interface which needs to be used with an emulator and (usually proprietary) software.
Short version: On most x86 machines, you can program EEPROM boot flash chips in-circuit. Most of these chips are attached to a LPC bus and after issuing a series of writes over LPC to predefined addresses of the flash chip, the flash chip enables erasing/writing to the chip. Chip identification is done the same way. The coreboot flashrom utility performs all these actions and eliminates the need for a special hardware programmer.
I see. Well, embedded MIPS boards all have one thing in common - the location of the Boot Flash (0x1FC00000 onwards). How one is to reach it will vary from system to system so flashrom may not be the way to go I would think.
Cheers, Robin
-
Carl-Daniel Hailfinger -
Robin Randhawa -
Uwe Hermann