[OpenBIOS] [PATCH 3/4] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Sat Dec 31 17:58:05 CET 2016


On 20/11/16 18:04, BALATON Zoltan wrote:

> 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
> 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 at eik.bme.hu>

I've given this a spin around my PPC images and I don't see any
regressions so I think this is going in the right direction - I think it
may need a couple of minor tweaks though.

Firstly, I now see the following PCI BAR warnings on boot for my old
openSUSE 11 boot ISO (openSUSE-11.1-NET-ppc.iso):


SuSE Linux zImage starting: loaded at 02000000-0325cd30
(4000000/0/fff025d0; sp: fffb9d40)
uncompressing ELF header done. (00000100 bytes)
Allocated 00900c04 bytes for kernel @ 03400000
Leave 00fd16ab bytes for initrd @ 0227ef52
uncompressing kernel done. (005a3590 bytes)
entering kernel at 03410000(227ef52/fd16ab/fff025d0)
OF stdout device is: /pci at f2000000/mac-io at c/escc at 13000/ch-a at 13020
command line:
memory layout at init:
  alloc_bottom : 03a15000
  alloc_top    : 20000000
  alloc_top_hi : 20000000
  rmo_top      : 20000000
  ram_top      : 20000000
Looking for displays
found display   : /pci at f2000000/QEMU,VGA at e, opening ... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x03d16000 -> 0x03d165c0
Device tree struct  0x03d17000 -> 0x03d1a000
Calling quiesce ...
returning from prom_init
Hello World !
setup_arch: bootmem
arch: exit

I/O resource not set for host bridge 0
Memory resource not set for host bridge 0
pci 0001:10:0e.0: BAR 0: can't allocate mem resource [0x0-0xffffff]
pci 0001:10:0c.0: BAR 0: can't allocate mem resource [0x0-0x7ffff]
pci 0001:10:0f.0: BAR 6: can't allocate mem resource [0x82040000-0x8207ffff]
pci 0001:10:0e.0: BAR 6: can't allocate mem resource [0x82010000-0x8201ffff]
pci 0001:10:0e.0: BAR 2: can't allocate mem resource [0x0-0xfff]
pci 0001:10:0d.0: BAR 0: can't allocate mem resource [0x0-0xff]
ohci_hcd 0001:10:0d.0: init 0001:10:0d.0 fail, -16
Moving into tmpfs... done.
Integrating /parts/00_lib
insmod /modules/squashfs.ko
mount: /parts/00_lib: we need a loop device
mount: using /dev/loop0
Integrating /parts/01_usr
mount: /parts/01_usr: we need a loop device
mount: using /dev/loop1


This is compared to the original below:


SuSE Linux zImage starting: loaded at 02000000-0325cd30
(4000000/0/fff025d0; sp: fffb9d40)
uncompressing ELF header done. (00000100 bytes)
Allocated 00900c04 bytes for kernel @ 03400000
Leave 00fd16ab bytes for initrd @ 0227ef52
uncompressing kernel done. (005a3590 bytes)
entering kernel at 03410000(227ef52/fd16ab/fff025d0)
OF stdout device is: /pci at f2000000/mac-io at c/escc at 13000/ch-a at 13020
command line:
memory layout at init:
  alloc_bottom : 03a15000
  alloc_top    : 20000000
  alloc_top_hi : 20000000
  rmo_top      : 20000000
  ram_top      : 20000000
Looking for displays
found display   : /pci at f2000000/QEMU,VGA at e, opening ... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x03d16000 -> 0x03d165c0
Device tree struct  0x03d17000 -> 0x03d1a000
Calling quiesce ...
returning from prom_init
Hello World !
setup_arch: bootmem
arch: exit

Moving into tmpfs... done.
Integrating /parts/00_lib
insmod /modules/squashfs.ko
mount: /parts/00_lib: we need a loop device
mount: using /dev/loop0
Integrating /parts/01_usr
mount: /parts/01_usr: we need a loop device
mount: using /dev/loop1


So perhaps you might need to fake up a few extra properties to get rid
of the warnings on boot?

Secondly while the address of the extra PCI node looks fine for -M mac99
in the device tree, I'm not sure it is correct for -M g3beige:


Welcome to OpenBIOS v1.1 built on Dec 31 2016 16:18

0 > show-devs
fff47c54 /
fff47d70 /aliases
fff47e14 /openprom (BootROM)
fff4dec0 /openprom/client-services
fff47fbc /options
fff48034 /chosen
fff480e4 /builtin
fff48188 /builtin/console
fff4dbcc /packages
fff4edb0 /packages/cmdline
fff4eef0 /packages/disk-label
fff50920 /packages/terminal-emulator
fff51884 /packages/deblocker
fff51bd8 /packages/hfsplus-files
fff51e78 /packages/hfs-files
fff52114 /packages/ext2-files
fff5234c /packages/iso9660-files
fff52584 /packages/grubfs-files
fff527bc /packages/mac-parts
fff52a34 /packages/pc-parts
fff52c68 /packages/xcoff-loader
fff52d34 /packages/elf-loader
fff52dfc /packages/bootinfo-loader
fff50508 /cpus
fff568f8 /cpus/PowerPC,750 at 0 (cpu)
fff50608 /memory at 0 (memory)
fff506d0 /rom at ff800000
fff507a8 /pci at f0000000 (pci)
fff52ec8 /pci at 80000000 (pci)
fff532f8 /pci at 80000000/QEMU,VGA at 1 (display)
fff53d34 /pci at 80000000/NE2000 at 2 (network)
fff540f0 /pci at 80000000/mac-io at 3 (mac-io)
fff5458c /pci at 80000000/mac-io at 3/via-cuda at 16000 (via-cuda)
fff547a8 /pci at 80000000/mac-io at 3/via-cuda at 16000/adb (adb)
fff54910 /pci at 80000000/mac-io at 3/via-cuda at 16000/adb/keyboard at 8 (keyboard)
fff54aec /pci at 80000000/mac-io at 3/via-cuda at 16000/adb/mouse at 9 (mouse)
fff54c78 /pci at 80000000/mac-io at 3/via-cuda at 16000/rtc (rtc)
fff54e1c /pci at 80000000/mac-io at 3/via-cuda at 16000/power-mgt (power-mgt)
fff55014 /pci at 80000000/mac-io at 3/nvram at 60000 (nvram)
fff55234 /pci at 80000000/mac-io at 3/escc at 13000 (escc)
fff55354 /pci at 80000000/mac-io at 3/escc at 13000/ch-a at 13020 (serial)
fff55628 /pci at 80000000/mac-io at 3/escc at 13000/ch-b at 13000 (serial)
fff558d0 /pci at 80000000/mac-io at 3/escc-legacy at 12000 (escc-legacy)
fff559f4 /pci at 80000000/mac-io at 3/escc-legacy at 12000/ch-a at 12002 (serial)
fff55c50 /pci at 80000000/mac-io at 3/escc-legacy at 12000/ch-b at 12000 (serial)
fff55e80 /pci at 80000000/mac-io at 3/ata-3 at 20000 (ata)
fff56118 /pci at 80000000/mac-io at 3/ata-3 at 21000 (ata)
fff563b0 /pci at 80000000/mac-io at 3/ata-3 at 21000/cdrom at 0 (block)


Perhaps the extra /pci node needs to be wrapped in an [IFDEF] block or
similar so that it only appears for -M mac99?


ATB,

Mark.




More information about the OpenBIOS mailing list