Re: [OpenBIOS] [PATCH] Use exception vectors from ROM instead of copying them to page zero
On Mon, 26 May 2014, Mark Cave-Ayland wrote:
Just as a general comment: I know that some OSs using Sun's PROM expect to be able to write to the trap table (which is why it is copied to RAM) so you'd need to check this thoroughly. Or, if MSR_IP uses virtual addresses you could do some MMU twiddling so that the virtual address actually points into a safe area of RAM rather than ROM.
As far as I understand MSR_IP just selects between exception vectors at 0x0 or 0xfff00000. Clients normaly use the vectors at page zero while the latter is typically used for ROM based boot code. Also I think the ROM is already copied to RAM anyway so it can be overwritten by the clients (MorophOS does this later after finished calling OF client interface functions or maybe it maps some RAM over it I'm not sure). In any case, clients should not modify the firmware code and I think they use vectors at 0x0.
As a starting point, have you tried booting any other OS with this change?
Yes but not very throughly. The Darwin images boot as far as before and Finnix has a different issue due to the change in cuda to via pmu where the IRQ is handled differently. I intend to fix that later by adding a USB driver to OpenBIOS and use that as the real hardware has USB instead of ADB anyway. This would also fix qemu-system-ppc64 with -M mac99. I already have a version here: http://www.openfirmware.info/pipermail/openbios/2014-May/008244.html but I'll need to fix it to work on big endian systems.
For my OpenBIOS tests I have a collection of various NetBSD, FreeBSD, Linux, Darwin and HelenOS that I use to check for regressions.
It would be appreciated if you could do some tests with these. Regards, BALATON Zoltan
On Mon, 26 May 2014, Segher Boessenkool wrote:
Many OSes use 0000..00ff for their own purposes. OpenBIOS should not use that area for anything, for its own good.
MSR[IP] is optional. OpenBIOS should not use it if it wants to run on more than just 970. On Mon, 26 May 2014, Segher Boessenkool wrote: Ugh, how could I forget... 970 does not implement MSR[IP] either. So how was this patch tested?
Since OpenBIOS does not work with qemu-system-ppc64 due to lack of USB support currently I could only try with qemu-system-ppc with a G4 CPU. So then I guess this patch cannot work then for newer ppc-s and I will have to get back to my older patch that moves the exception vectors from the beginning of RAM. I'll send that again instead for review. Regards, BALATON Zoltan
On 26/05/14 17:49, BALATON Zoltan wrote:
As a starting point, have you tried booting any other OS with this change?
Yes but not very throughly. The Darwin images boot as far as before and Finnix has a different issue due to the change in cuda to via pmu where the IRQ is handled differently. I intend to fix that later by adding a USB driver to OpenBIOS and use that as the real hardware has USB instead of ADB anyway. This would also fix qemu-system-ppc64 with -M mac99. I already have a version here: http://www.openfirmware.info/pipermail/openbios/2014-May/008244.html but I'll need to fix it to work on big endian systems.
For my OpenBIOS tests I have a collection of various NetBSD, FreeBSD, Linux, Darwin and HelenOS that I use to check for regressions.
It would be appreciated if you could do some tests with these.
One of the things I learned very quickly with OpenBIOS is that the more images you use for testing, the more bugs that you find. For example, here my FreeBSD/NetBSD images hang somewhere in PCI bus enumeration on -M mac99 which could be a similar bug to the one you are seeing on MorphOS (maybe interrupts?). But at least for the *BSDs you have the source code available so you can figure out what the code *should* be doing which helps narrow down the problem space considerably. ATB, Mark.
On Wed, 28 May 2014, Mark Cave-Ayland wrote:
For example, here my FreeBSD/NetBSD images hang somewhere in PCI bus enumeration on -M mac99 which could be a similar bug to the one you are
Can you point me to such an image please?
seeing on MorphOS (maybe interrupts?). But at least for the *BSDs you have the source code available so you can figure out what the code *should* be doing which helps narrow down the problem space considerably.
The problem with MorphOS seems to be that it cannot receive from the network. It initialises the card (I'm using rtl8139 as that's what has a driver in MorphOS) and seems to talk to it but packets are not received or not handled. I believe the problem may be that the interrupt is not handled correctly. I base this on the following: Bus 0, device 14, function 0: Ethernet controller: PCI device 10ec:8139 IRQ 29. BAR0: I/O at 0x0400 [0x04ff]. BAR1: 32 bit memory at 0x82020000 [0x820200ff]. BAR6: 32 bit memory at 0x82040000 [0x8207ffff]. id "" /pci #interrupt-cells 1 interrupt-map 00000000 00000000 00000000 00000001 fff56630 0000001b 00000003 00000000 00000000 00000000 00000002 fff56630 0000001c 00000003 00000000 00000000 00000000 00000003 fff56630 0000001d 00000003 00000000 00000000 00000000 00000004 fff56630 0000001e 00000003 00000000 00000000 00000000 00000005 fff56630 000000ff 00000003 00000000 00000000 00000000 00000006 fff56630 000000f3 00000003 00000000 00000000 00000000 00000007 fff56630 00000042 00000003 00000000 00000000 00000000 00000008 fff56630 000000cc 00000003 interrupt-map-mask 00000000 00000000 00000000 00000007 interrupt-parent fff56630 /pci/RTL8139 interrupts 1 But MorphOS says for all cards it finds: "Board uses custom interrupt ID 0x0400001b" Changing interrupts to 3 in /pci/RTL8139 does not change anything. Does the above make sense to anyone who could please explain how it should work and what could be the problem? I'll try to find out more by testing with other OSes but maybe someone has other ideas that might help. Regards, BALATON Zoltan
On 28/05/14 12:11, BALATON Zoltan wrote:
On Wed, 28 May 2014, Mark Cave-Ayland wrote:
For example, here my FreeBSD/NetBSD images hang somewhere in PCI bus enumeration on -M mac99 which could be a similar bug to the one you are
Can you point me to such an image please?
Just download the latest FreeBSD/NetBSD PPC ISO releases from their respective websites and try and boot them under QEMU with -M mac99 :) For one of them you need to manually punch in "boot cd:,\ofwboot.xcf" in order to start the boot from memory.
seeing on MorphOS (maybe interrupts?). But at least for the *BSDs you have the source code available so you can figure out what the code *should* be doing which helps narrow down the problem space considerably.
The problem with MorphOS seems to be that it cannot receive from the network. It initialises the card (I'm using rtl8139 as that's what has a driver in MorphOS) and seems to talk to it but packets are not received or not handled. I believe the problem may be that the interrupt is not handled correctly. I base this on the following:
Bus 0, device 14, function 0: Ethernet controller: PCI device 10ec:8139 IRQ 29. BAR0: I/O at 0x0400 [0x04ff]. BAR1: 32 bit memory at 0x82020000 [0x820200ff]. BAR6: 32 bit memory at 0x82040000 [0x8207ffff]. id ""
/pci #interrupt-cells 1 interrupt-map 00000000 00000000 00000000 00000001 fff56630 0000001b 00000003 00000000 00000000 00000000 00000002 fff56630 0000001c 00000003 00000000 00000000 00000000 00000003 fff56630 0000001d 00000003 00000000 00000000 00000000 00000004 fff56630 0000001e 00000003 00000000 00000000 00000000 00000005 fff56630 000000ff 00000003 00000000 00000000 00000000 00000006 fff56630 000000f3 00000003 00000000 00000000 00000000 00000007 fff56630 00000042 00000003 00000000 00000000 00000000 00000008 fff56630 000000cc 00000003 interrupt-map-mask 00000000 00000000 00000000 00000007 interrupt-parent fff56630
/pci/RTL8139 interrupts 1
But MorphOS says for all cards it finds: "Board uses custom interrupt ID 0x0400001b"
Changing interrupts to 3 in /pci/RTL8139 does not change anything. Does the above make sense to anyone who could please explain how it should work and what could be the problem? I'll try to find out more by testing with other OSes but maybe someone has other ideas that might help.
You may find the following thread helpful here: http://comments.gmane.org/gmane.comp.bios.openbios/4992. But again, you should be able to cross-check with the *BSD sources exactly how the interrupts are being routed to the CPU in QEMU based upon these properties which will make life much easier. And don't forget to make yourself familiar with the IEEE1275 PCI bindings too: http://www.openfirmware.org/1275/bindings/pci/pci2_1.pdf. HTH, Mark.
On Wed, 28 May 2014, Mark Cave-Ayland wrote:
Just download the latest FreeBSD/NetBSD PPC ISO releases from their respective websites and try and boot them under QEMU with -M mac99 :) For one
OK, I've tried FreeBSD and it paniced because it has found an ide controller in the device tree with interrupts set but no interrupt parent. Since QEMU only emulates 2 ata ports of the three the third one should not be there in the device tree. With just this patch: diff --git a/openbios-devel/drivers/macio.c b/openbios-devel/drivers/macio.c index 00d7149..fc08c30 100644 --- a/openbios-devel/drivers/macio.c +++ b/openbios-devel/drivers/macio.c @@ -311,7 +312,7 @@ ob_macio_keylargo_init(const char *path, phys_addr_t addr) /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("", 0); escc_init(path, addr); - macio_ide_init(path, addr, 3); + macio_ide_init(path, addr, 2); openpic_init(path, addr); ob_unin_init(); } it probably goes further (I have some more ide patches in my tree too that I'll submit later some of which may also be needed) but then crashed when starting to use the VGA card. With -vga none -nographic it goes up to finding its CD but not very useful without a display. (Also QEMU segfaulted with -vga none but without -nographic but I did not investigate that either.) This image seems to break wherever I touch it so using it as a test case would cause more problems than it would help so I gave up on it. I think I'm better off fixing the keyboard under Finnix and use that as that seems to work better on QEMU already.
You may find the following thread helpful here: http://comments.gmane.org/gmane.comp.bios.openbios/4992. But again, you should be able to cross-check with the *BSD sources exactly how the interrupts are being routed to the CPU in QEMU based upon these properties which will make life much easier.
I've hoped someone already understands these and can explain it so I don't have to dig up sources.
And don't forget to make yourself familiar with the IEEE1275 PCI bindings too: http://www.openfirmware.org/1275/bindings/pci/pci2_1.pdf.
I've already read that document but probably not enough times so I still don't get all of this. Regards, BALATON Zoltan
On 28.05.14 22:28, BALATON Zoltan wrote:
On Wed, 28 May 2014, Mark Cave-Ayland wrote:
Just download the latest FreeBSD/NetBSD PPC ISO releases from their respective websites and try and boot them under QEMU with -M mac99 :) For one
OK, I've tried FreeBSD and it paniced because it has found an ide controller in the device tree with interrupts set but no interrupt parent. Since QEMU only emulates 2 ata ports of the three the third one should not be there in the device tree. With just this patch:
diff --git a/openbios-devel/drivers/macio.c b/openbios-devel/drivers/macio.c index 00d7149..fc08c30 100644 --- a/openbios-devel/drivers/macio.c +++ b/openbios-devel/drivers/macio.c @@ -311,7 +312,7 @@ ob_macio_keylargo_init(const char *path, phys_addr_t addr) /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("", 0); escc_init(path, addr); - macio_ide_init(path, addr, 3); + macio_ide_init(path, addr, 2);
If real hardware emulates 3 ports, QEMU should do so as well. If it emulates 2, then this patch is correct. Do you have any reference dts that can show which one it is?
openpic_init(path, addr); ob_unin_init(); }
it probably goes further (I have some more ide patches in my tree too that I'll submit later some of which may also be needed) but then crashed when starting to use the VGA card. With -vga none -nographic it goes up to finding its CD but not very useful without a display. (Also QEMU segfaulted with -vga none but without -nographic but I did not investigate that either.) This image seems to break wherever I touch it so using it as a test case would cause more problems than it would help so I gave up on it. I think I'm better off fixing the keyboard under Finnix and use that as that seems to work better on QEMU already.
You may find the following thread helpful here: http://comments.gmane.org/gmane.comp.bios.openbios/4992. But again, you should be able to cross-check with the *BSD sources exactly how the interrupts are being routed to the CPU in QEMU based upon these properties which will make life much easier.
I've hoped someone already understands these and can explain it so I don't have to dig up sources.
And don't forget to make yourself familiar with the IEEE1275 PCI bindings too: http://www.openfirmware.org/1275/bindings/pci/pci2_1.pdf.
I've already read that document but probably not enough times so I still don't get all of this.
Maybe these references are of some help: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/e500.c;h=223bab9eea18dad7990... http://www.devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Alex
On Thu, 29 May 2014, Alexander Graf wrote:
diff --git a/openbios-devel/drivers/macio.c b/openbios-devel/drivers/macio.c index 00d7149..fc08c30 100644 --- a/openbios-devel/drivers/macio.c +++ b/openbios-devel/drivers/macio.c @@ -311,7 +312,7 @@ ob_macio_keylargo_init(const char *path, phys_addr_t addr) /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("", 0); escc_init(path, addr); - macio_ide_init(path, addr, 3); + macio_ide_init(path, addr, 2);
If real hardware emulates 3 ports, QEMU should do so as well. If it emulates 2, then this patch is correct. Do you have any reference dts that can show which one it is?
In qemu/hw/misc/macio/macio.c only 2 ide ports are initialised. Also there's a comment in qemu/hw/ppc/mac_newworld.c saying the same. But look at the device tree dumps that I referenced at the end of my QEMU patch. Real hardware has three ports that are named: ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk Really! There are two times ata-3 but no 1 and 2 and MorphOS actually expects these names. So to avoid confusion it's better to stay at emulating 2 ports and call them ata-3 and ata-4.
Maybe these references are of some help:
http://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/e500.c;h=223bab9eea18dad7990...
http://www.devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
Thanks for these. I've already seen the second one but I still can't tell if the current mappings are correct or not. Regards, BALATON Zoltan
participants (3)
-
Alexander Graf -
BALATON Zoltan -
Mark Cave-Ayland