MVME 5100
Thanks, but I have already set up a BAT to cover the area from 0xf0000000 - 0xffffffff because everything is there on the MVME5100 - the serial ports (via the Hawk external registers) [fef88000+], the MPIC [f3f80000+] and the PHC PCI registers [fe000000+].
The CONFIG_ADDRESS and CONFIG_DATA registers are on fe000cf8 and fe00cfc, and still writing to the CONFIG_ADDRESS and then reading the CONFIG_DATA sometime works and sometimes not !!!??
Torsten
-----Ursprungliche Nachricht-----
Von: Matt Porter [SMTP:[email protected]]
Gesendet am: Mittwoch, 13. Dezember 2000 21:41
An: Torsten Rissel
Cc: Linuxppc-Embedded (E-Mail)
Betreff: Re: MVME 5100
Quoted 8 lines · Torsten Rissel
Hi Everybody !
I am trying to run Linux on an MVME5100 board. I am using PReP-style booting and got the boot process and some of the kernel initialization running. But I am missing any knowledge of other PowerPC boards or machines, so that it is relativly hard to find out what exactly to change. So I have a question: The MVME5100 is missing all ISA stuff. Is the IRQ mapping (first 16 for the 8259 and the other 16 for the MPIC) still valid ?
Might as well just use 16-31 and stick with the MPIC convention. If somebody else is using the 5100 with the IPMC761 then they will have ISA and will thank you many times for not changing things.
Quoted 2 lines
Also I run in a problem: the indirect mechanism for generating PCI config cycles is set up correctly, but the board seems to hang when reading from the
CONFIG_DATAaddress !!!???
Make sure you have those Hawk registers covered with a BAT or PTEs. Notice the areas covered by BATs in the MACH_prep BAT setup case in arch/ppc/mm/init.c.
--
Matt Porter
MontaVista Software, Inc.
[email protected]
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Torsten Rissel
Thanks, but I have already set up a BAT to cover the area from
0xf0000000-0xffffffffbecause everything is there on the MVME5100 - the serial ports (via the Hawk external registers) [fef88000+], the MPIC [f3f80000+] and the PHC PCI registers [fe000000+].
Right, I have one as well as a similar Hawk-based board that has Linux on it.
Quoted 3 lines
The
CONFIG_ADDRESSandCONFIG_DATAregisters are onfe000cf8and fe00cfc, and still writing to theCONFIG_ADDRESSand then reading theCONFIG_DATAsometime works and sometimes not !!!??
I can consistently read from and write to config space on my 5100 board via PPCBUG. The only thing I can think of is that you have somehow locked up the Hawk bridge. I've managaged this on other host bridges only by getting a PIB locked up and squatting on the bus.
What kernel version are you using as a basis for your port? Are you basing the port off the existing prep_*.c support?
--
Matt Porter
MontaVista Software, Inc.
[email protected]
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 9 lines · Matt Porter
Quoted 3 lines · Torsten Rissel
Thanks, but I have already set up a BAT to cover the area from
0xf0000000-0xffffffffbecause everything is there on the MVME5100 - the serial ports (via the Hawk external registers) [fef88000+], the MPIC [f3f80000+] and the PHC PCI registers [fe000000+].Right, I have one as well as a similar Hawk-based board that has Linux on it.
Quoted 8 lines
Quoted 3 lines
The
CONFIG_ADDRESSandCONFIG_DATAregisters are onfe000cf8and fe00cfc, and still writing to theCONFIG_ADDRESSand then reading theCONFIG_DATAsometime works and sometimes not !!!??I can consistently read from and write to config space on my 5100 board via PPCBUG. The only thing I can think of is that you have somehow locked up the Hawk bridge. I've managaged this on other host bridges only by getting a PIB locked up and squatting on the bus.
On the MVME2400 (and older Raven/Falcon based boards) the config space by default is at 0x80000cf8 and 0x8000cfc. Does it mean that on the MVME5100, the Hawk is reprogrammed by PPCBUG to look like a CHRP system ?
Regards,
Gabriel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 17 lines · Gabriel Paubert
Quoted 13 lines · Matt Porter
Quoted 3 lines · Torsten Rissel
Thanks, but I have already set up a BAT to cover the area from
0xf0000000-0xffffffffbecause everything is there on the MVME5100 - the serial ports (via the Hawk external registers) [fef88000+], the MPIC [f3f80000+] and the PHC PCI registers [fe000000+].Right, I have one as well as a similar Hawk-based board that has Linux on it.
Quoted 3 lines
The
CONFIG_ADDRESSandCONFIG_DATAregisters are onfe000cf8and fe00cfc, and still writing to theCONFIG_ADDRESSand then reading theCONFIG_DATAsometime works and sometimes not !!!??
Quoted 8 lines
Quoted 4 lines
I can consistently read from and write to config space on my 5100 board via PPCBUG. The only thing I can think of is that you have somehow locked up the Hawk bridge. I've managaged this on other host bridges only by getting a PIB locked up and squatting on the bus.
On the MVME2400 (and older Raven/Falcon based boards) the config space by default is at
0x80000cf8and0x8000cfc. Does it mean that on the MVME5100, the Hawk is reprogrammed by PPCBUG to look like a CHRP system ?
Yes...and Yes. :) The only thing the newer MCG boards really do (correctly) that looks like a PReP system is the disk booting mechanism.
BTW, the MVME2100 (8240/Universe II board) is put in map B for a CHRP map as well.
--
Matt Porter
MontaVista Software, Inc.
[email protected]
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 10 lines · Matt Porter
Quoted 3 lines
On the MVME2400 (and older Raven/Falcon based boards) the config space by default is at
0x80000cf8and0x8000cfc. Does it mean that on the MVME5100, the Hawk is reprogrammed by PPCBUG to look like a CHRP system ?Yes...and Yes. :) The only thing the newer MCG boards really do (correctly) that looks like a PReP system is the disk booting mechanism.
BTW, the MVME2100 (8240/Universe II board) is put in map B for a CHRP map as well.
Ok, fine. It means that my code to reprogram the Raven/Hawk on 2[467]xx just makes things more uniform. I still don't like the fact that the DMA is offset, though (unless it's a residual data bug, and map B on 106/107 does not have this DMA offset).
Regards,
Gabriel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/