QEMU emulates two of the three PCI buses found on real hardware because
some clients seem to need both and fail with only one present, but
OpenBIOS only handles a single PCI bus and initialises and puts in the
device tree only one of these: the second one which is where devices are
connected and also marks it bus 0. However, clients getting info from the
device tree may not know about this and thinking there is only one PCI
bus they erroneously use the address of the first bus to access PCI
…
[View More]config registers for devices on the second bus which silently fails as
these requests will go to the other empty bus emulated and return invalid
values. Devices mapped via MMIO still appear to work but they may not be
correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in
the device tree for the uninitialised bus to let clients know about it.
This is still not entirely correct as bus-range property does not match
real hardware but this fixes detecting PCI devices (such as USB) under
MorphOS and may also fix enabling the bus master bit needed with some
network cards and allow the workaround for this to be reverted.
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
---
arch/ppc/qemu/init.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
v3: Move device tree patching in its own function and call it from
init (otherwise same as v2, take which you like)
v2: Move to init.c from tree.fs and only add it for mac99
Patches 1 and 2 from original series
https://www.coreboot.org/pipermail/openbios/2016-November/009825.htmlhttps://www.coreboot.org/pipermail/openbios/2016-November/009824.html
are still valid and needed, patch 4 was already applied so only this
one (3/4) is resent but 1 and 2 should be applied as well with this.
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index ffbf08d..46a56a0 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -668,6 +668,48 @@ static void kvm_of_init(void)
fword("finish-device");
}
+static void empty_pci_bus_init(void)
+{
+ if (machine_id == ARCH_MAC99) {
+ /* Add empty node for first pci bus */
+ /* Remove this when pci driver is fixed to handle multiple buses */
+ activate_device("/");
+ fword("new-device");
+ push_str("pci");
+ fword("device-name");
+ push_str("pci");
+ fword("device-type");
+ PUSH(0xf0000000);
+ fword("encode-int");
+ PUSH(0x02000000);
+ fword("encode-int");
+ fword("encode+");
+ push_str("reg");
+ fword("property");
+ PUSH(3);
+ fword("encode-int");
+ push_str("#address-cells");
+ fword("property");
+ PUSH(2);
+ fword("encode-int");
+ push_str("#size-cells");
+ fword("property");
+ PUSH(1);
+ fword("encode-int");
+ push_str("#interrupt-cells");
+ fword("property");
+ PUSH(0);
+ fword("encode-int");
+ PUSH(0);
+ fword("encode-int");
+ fword("encode+");
+ push_str("bus-range");
+ fword("property");
+ fword("finish-device");
+ device_end();
+ }
+}
+
/*
* filll ( addr bytes quad -- )
*/
@@ -755,6 +797,7 @@ arch_of_init(void)
openbios_init();
modules_init();
setup_timers();
+ empty_pci_bus_init();
#ifdef CONFIG_DRIVER_PCI
ob_pci_init();
#endif
--
2.7.4
[View Less]
Hello Zoltan, hey list,
On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON Zoltan wrote:
> ...
> For forth commands I've found this page useful (not sure if this is linked
> from somewhere):
> http://www.firmworks.com/QuickRef.html
Thank you, I found this (and more) last week. The OLPC sites are the
best for me:
1: http://wiki.laptop.org/go/Open_Firmware
2: http://wiki.laptop.org/go/Forth_Lessons
3: http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware
> ...
> This is …
[View More]a bit confusing. There are multiple implementations of the IEEE
> standard (commonly referred to as Open Firmware) and one of these is also
> called Open Firmware. These are listed under Implementations on the left of
> the page at www.openfirmware.info. Another implementation used by QEMU for
Yes and I looked at them. But they are either very old or not usable for
ppc (too much work to implement a new arch).
> ...
> talking about Open Firmware: the standard or the implementation with the
> same name.
One thing is left which confuses me: In wikipedia and you say, that you
use the name "Open Firmware" (also, besides as name for a standard) for
an implementation. OK.
But the website gives the impression (and G 3 says), that the implementation
has the name "OpenBIOS"...
So I have two statements which don't fit well. Please remember that I am
new to this and did not live through the history.
> ...
> Actually running OpenBIOS on real hardware is not something that is well
> tested (I'm not sure if it was ever tried but I think it wasn't done
> recently) so if you try to do that be prepared for likely needing some
The OLPC project did it, e.g.
> fixing. This is true for any implementation that does not support the
> hardware you want to run it on, then you likely need to port it.
That there will be the need for porting was clear.
> ...
> it's enough to have the basics in there. Not sure how much up to date is
> this but this is discussed in the kernel documentation here:
> https://www.kernel.org/doc/Documentation/devicetree/booting-without-of.txt
>
Thank you, I missed this source.
> As for giving the device tree to OpenBIOS I think it should just know it or
> construct it from discovering the hardware as the point of the device tree
> is to describe the hardware for the operating system so the firmware should
> know the hardware and provide the device tree. It does not get it from
The "firmware" is our handmade init-assemblercode. It has to enable the
machine (beginning from Adam...) to run C-code in its RAM.
If there is no software-interface, then we provide the device-tree maybe in
forth or in a blob. Just thinking loudly.
> ...
> In fact OpenBIOS does not have that many drivers but maybe the basics are
> there, only the platform specific init code might need to be adapted for a
That would be very nice. We give it a try. Maybe with help from you / the
list.
> new board. For ppc these would be in arch/ppc. Running on QEMU is quite a
> bit simpler as we can skip a lot of init code (such as memory controller or
> other hardware) so maybe these are not well implemented or buggy as they
> were not tested with real hardware for a while.
> ...
Did you use OpenBIOS in a recent qemu and have you been able to remote-debug
it there? I was able to load and run the old OpenBIOS code (from svn repo)
on "qemu-system-ppc".
Thank you for your time and suggestions, greetings,
Michael
[View Less]
QEMU emulates two of the three PCI buses found on real hardware because
some clients seem to need both and fail with only one present, but
OpenBIOS only handles a single PCI bus and initialises and puts in the
device tree only one of these: the second one which is where devices are
connected and also marks it bus 0. However, clients getting info from the
device tree may not know about this and thinking there is only one PCI
bus they erroneously use the address of the first bus to access PCI
…
[View More]config registers for devices on the second bus which silently fails as
these requests will go to the other empty bus emulated and return invalid
values. Devices mapped via MMIO still appear to work but they may not be
correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in
the device tree for the uninitialised bus to let clients know about it.
This is still not entirely correct as bus-range property does not match
real hardware but this fixes detecting PCI devices (such as USB) under
MorphOS and may also fix enabling the bus master bit needed with some
network cards and allow the workaround for this to be reverted.
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
---
arch/ppc/qemu/init.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
v2: Move to init.c from tree.fs and only add it for mac99
Patches 1 and 2 from original series
https://www.coreboot.org/pipermail/openbios/2016-November/009825.htmlhttps://www.coreboot.org/pipermail/openbios/2016-November/009824.html
are still valid and needed, patch 4 was already applied so only this
one (3/4) is resent but 1 and 2 should be applied as well with this.
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index ffbf08d..629d71b 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -755,6 +755,44 @@ arch_of_init(void)
openbios_init();
modules_init();
setup_timers();
+ if (machine_id == ARCH_MAC99) {
+ /* Add empty node for first pci bus */
+ /* Remove this when pci driver is fixed to handle multiple buses */
+ activate_device("/");
+ fword("new-device");
+ push_str("pci");
+ fword("device-name");
+ push_str("pci");
+ fword("device-type");
+ PUSH(0xf0000000);
+ fword("encode-int");
+ PUSH(0x02000000);
+ fword("encode-int");
+ fword("encode+");
+ push_str("reg");
+ fword("property");
+ PUSH(3);
+ fword("encode-int");
+ push_str("#address-cells");
+ fword("property");
+ PUSH(2);
+ fword("encode-int");
+ push_str("#size-cells");
+ fword("property");
+ PUSH(1);
+ fword("encode-int");
+ push_str("#interrupt-cells");
+ fword("property");
+ PUSH(0);
+ fword("encode-int");
+ PUSH(0);
+ fword("encode-int");
+ fword("encode+");
+ push_str("bus-range");
+ fword("property");
+ fword("finish-device");
+ device_end();
+ }
#ifdef CONFIG_DRIVER_PCI
ob_pci_init();
#endif
--
2.7.4
[View Less]
I splitted the patch.
It was tested with an old Linux distro (RH 4.2) and with NetBSD.
The SMP kernel must be selected during install.
Here is, for example, a NetBSD/sparc32 image with SMP enabled :
temlib.org/pub/net702.qcow.bz2
qemu-system-sparc net702.qcow -M SS-20 -vga cg3 -smp 2
This SMP mode used to work a while ago, but it has so far no practical purpose as enabling it slows down QEMU considerably.
QEMU emulates two of the three PCI buses found on real hardware because
some clients seem to need both and fail with only one present, but
OpenBIOS only handles a single PCI bus and initialises and puts in the
device tree only one of these: the second one which is where devices are
connected and also marks it bus 0. However, clients getting info from the
device tree may not know about this and thinking there is only one PCI
bus they erroneously use the address of the first bus to access PCI
…
[View More]config registers for devices on the second bus which silently fails as
these requests will go to the other empty bus emulated and return invalid
values. Devices mapped via MMIO still appear to work but they may not be
correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in
the device tree for the uninitialised bus to let clients know about it.
This is still not entirely correct as bus-range property does not match
real hardware but this fixes detecting PCI devices (such as USB) under
MorphOS and may also fix enabling the bus master bit needed with some
network cards and allow the workarund for this to be reverted.
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
---
arch/ppc/qemu/tree.fs | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/ppc/qemu/tree.fs b/arch/ppc/qemu/tree.fs
index 5b6bbc6..e1708de 100644
--- a/arch/ppc/qemu/tree.fs
+++ b/arch/ppc/qemu/tree.fs
@@ -50,6 +50,18 @@ new-device
h# ff800000 encode-int encode+ " ranges" property
finish-device
+\ Add empty node for first pci bus
+\ Remove this when pci driver is fixed to handle multiple buses
+new-device
+ " pci" device-name
+ " pci" device-type
+ h# f0000000 encode-int 02000000 encode-int encode+ " reg" property
+ 3 encode-int " #address-cells" property
+ 2 encode-int " #size-cells" property
+ 1 encode-int " #interrupt-cells" property
+ 0 encode-int 0 encode-int encode+ " bus-range" property
+finish-device
+
\ -------------------------------------------------------------
\ /packages
\ -------------------------------------------------------------
--
2.7.4
[View Less]
When I push the tilda/grave-accent button, the character that shows up on OpenBIOS is the < or > character. Would you accept a patch that fixes this issue?