July 2019 - OpenBIOS - mail.coreboot.org

Re: [Qemu-ppc] ATY 'NDRV'
by Jd Lyons July 21, 2019

July 21, 2019

With nVidia FCode ROM’s these AGP properties were just ignored by Open Firmware and the drivers for a hacked PCI nVidia card. I don’t think they will be any trouble with ATI cards either, but we’ll burn that bridge when we get there, tho PCI FCode RoM’s have Fast-back-to-back. 0 > .properties vendor-id 00001002 device-id 00005245 revision-id 00000000 class-code 00030000 interrupts 00000001 min-grant 00000008 max-latency 00000000 subsystem-vendor-id 0000b530 subsystem-id 00000408 devsel-speed 00000001 fast-back-to-back fcode-rom-offset 00000000 ATY,Status 00000000 ATY,Flags 0717009b EDID 00ffffff ffffff00 1e6ddb56 f7470200 0c130103 6a301b78 ea3d85a6 564a9a24 125054a7 6b80b300 81808140 714f0101 01010101 0101023a 80187138 2d40582c 4500dd0c 1100001a 21399030 621a2740 68b03600 dd0c1100 001c0000 00fd0038 4b1e530f 000a2020 20202020 000000fc 00573232 35330a20 20202020 2020008a depth 00000008 device_type display character-set ISO8859-1 iso6429-1983-colors reg 00011800 00000000 00000000 00000000 00000000 02011830 00000000 00000000 00000000 00020000 42011810 00000000 00000000 00000000 08000000 02011818 00000000 00000000 00000000 00004000 name ATY,Rage128y model ATY,Rage128 ATY,Rom# 3131332d 35373430 312d3131 3600 ATY,Card# 3130392d 35373430 322d3030 00 ATY,Fcode 312e3633 00 driver,AAPL,MacOS,PowerPC 4a6f7921 70656666 70777063 00000001 b2943306 00000000 00000000 00000000 00030002 00000000 ffffffff 00000000 0000c4a8 0000c4a8 0000c4a8 00000630 00040400 ffffffff 00000000 00002b61 000026c3 00001c34 0000cae0 02010400 ffffffff 00000000 00000000 00000000 000005b0 00000080 04040400 00000000 ffffffff 00000000 ffffffff 00000000 ffffffff 00000000 00000005 0000002a 00000001 00000164 000001d0 0000058c 00000001 00000002 00000000 00000000 00000000 00000011 00000000 00000000 00000012 00000000 00000000 00000001 00000011 00000000 0000001f 00000000 00000000 0000000e 00000012 00000000 ... 0000e714 bytes total assigned-addresses c2011810 00000000 88000000 00000000 08000000 82011830 00000000 800a0000 00000000 00020000 82011818 00000000 80088000 00000000 00004000 address 88000000 width 00000280 height 000001e0 linebytes 00000280 ok > On Jul 20, 2019, at 11:31 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 20 Jul 2019, Howard Spoelstra wrote: >> This rom does define some AGP stuff, so I don't know whether that will be a >> problem with PCI? > > Not sure but maybe not unless it wants to do something with AGP. As far as I could get from the FCode that only adds some AGP related parameters to device tree that are hard-coded and does not do anything with AGP itself so it should not be a problem for the ROM itself, maybe the OS later wants to set some AGP stuff but those are probably just ignored and if the right addresses of the card are available for frame buffer and mmio regs it should then work. But we'll see, this is again something that I don't know much about so will have to learn when it turns out to cause problem but until then I'm going to ignore it. > > Regards, > BALATON Zoltan

2 5

Re: [Qemu-ppc] ATY 'NDRV'
by Jd Lyons July 20, 2019

July 20, 2019

Th ATI Driver Update extension from 9.2.2 has these ‘NDRV’s for the Rage128. ATY,Rage128k ATY,Rage128Pk ATY,Rage128Ps ATY,Rage128s ATY,Rage128y ATY,Rage128Pd ATY,Rage128P2ks I thought I was able to use them in a very limited mode, however checking the IOReg I see the display “NDRV’ from the Mac OS ROM. So the Rage128 ‘NDRV’s try to load, but at some point they abort and never get built in the device tree for the card. So maybe the FCode can fix these issues. BTW does anyone know how to trail the serial output of Qemu? May debug trace of “ate*” and “pci*" is longer than the line buffer of my terminal and I’d like to be able to save it as a text file. Something like -serial stdio > atidebug.txt. > On Jul 20, 2019, at 4:53 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 20 Jul 2019, Howard Spoelstra wrote: >> I used Graphiccelerator ( http://thomas.perrier.name/graphiccelerator.html > > This page lists compatibility with these ROMs: > > Rage 128 Pro OEM, rev 108, 110, 125, 130 and 136 > Rage 128 OEM, rev 108, 112, 116 and 204 > > So I think there are ROMs (and NDRVs) for Rage128 which are not compatible with the ati-vga emulation as that's for a Rage128 chip and there are ROMs/NDRVs for Rage 128 Pro of which we have 110 and 136 (there are other versions as well but these two are probably enough). So we should not try yo use a Rage128 ROM/NDRV only Rage 128 Pro one. > > For the RV100 emulation maybe these could work (eventually, as rv100 emulation is very incomplete yet but in case you want to try anyway): > > Radeon 7000 Mac Edition, rev 119, 208, 218 and 226 > Radeon 7000 OEM, rev 109 and 110 > > although we really emulate a Mobility Radeon 7000 aka M6 chip as that's what is found on the fulong2e board also emulated by QEMU but these are probably not much different on the register level. I'm not sure this is correct though and don't know what the other Radeon ROMs are without a specific model number on that page. But the above are probably the only ROMs (and corresponding NDRVs) that are supposed to work, anything else is not useful for testing. > > (The rv100 emulation is less likely to work because its drivers usually try to talk to the card via memory buffers and assume 3D is there but none of these are emulated yet, so trying it would likely only confirm this but not get you anywhere currently.) > > Regards, > BALATON Zoltan

1 0

Re: ATY 'NDRV'
by Jd Lyons July 20, 2019

July 20, 2019

Hmmmmm. Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e. dev /pci/@f “ ATY,Rage128v” encode-string “ name” property boot ATY,Rage128ns ATY,Rage128n ATY,Rage128o ATY,Rage128v qemu-system-ppc -M mac99 -m 512 -hda '/home/jam/os9/os9.img' -device ati-vga -prom-env 'vga-ndrv?=false' -display sdl -prom-env 'boot-args=-v romndrv=1' -prom-env 'auto-boot?=false' -bios '/home/jam/openbios-qemu.elf' -prom-env "aapl,debug=3013FFF" -trace enable="ati" -trace enable="pci" -serial stdio qemu-system-ppc: -trace enable=ati: warning: trace event 'ati' does not exist qemu-system-ppc: -trace enable=pci: warning: trace event 'pci' does not exist >> ============================================================= >> OpenBIOS 1.1 [Jul 14 2019 16:58] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 512M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. >> switching to new context: Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 00000000 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0000d032 6806e8c0 ResetSystem trap entered Kernel code base at 0x00f10000 Physical RAM size 0x1fffc000 bytes Created motherboard coherence group. ID 00010001 NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Created system address space. ID 00030001 BATs ffc0007f 00c00043 6800001f 00f00043 00000000 00000000 00000000 00000000 Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 0001f7c3 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0002d032 6806c9e8 CPU plugin registered ati_vga_switch_mode: 0 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_vga_switch_mode: 1 -> 0 ati_vga_switch_mode: 0 -> 0 ati_vga_switch_mode: 0 -> 1 qemu-system-ppc: /home/jam/aty/qemu/hw/display/ati.c:88: ati_vga_switch_mode: Assertion `bpp != 0' failed. Aborted > On Jul 20, 2019, at 6:57 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Fri, 19 Jul 2019, Jd Lyons wrote: >> Ok I enabled ati debuging and with an ‘NDRV’ loaded I get: >> >> ATI_vga_switch_mode 0 > 1 > > This just means the driver has enabled extended mode as opposed to VGA mode but this could also happen through OpenBIOS using VBE extension so only those are really the driver that happen after the Swtiching to new context message from OpenBIOS (maybe use -serial stdio to see these in your log). More interesting are the Switching to mode messages that tells what the emulation thinks what mode the driver has programmed the CRTC. This can be cross checked by seeing the register writes before that and decoding it from the docs. Those I've checked so far looked good but I don't think I've verified MacOS yet. > >> I noted this is in the ati.c but I only understand some of it( 15bit mode???, never saw that before;-) > > 15 bpp is just RGB555, it's stored in 16 bits but one bit is unused as opposed to RGB565 where the G component gets the additional bit. Maybe MacOS does not tell this difference and just says 16 bit mode but uses RBG555 internally? > >> Under OS 9 I get the error just after we jump into the 68k fire( right about the point it would draw the Happy Mac to the screen, booting continues, the CPU Plugin is registered and we get to count 9, and booting halts, normally to get to the desktop we would get to count 14 in the Nano Kernel log. >> >> Under OS X I see: >> >> >> ATI_vga_switch_mode 0 > 1 >> >> Just before >> >> ATY: not usable > > This is interesting, maybe we can try to find the condition where it decides it's not usable and see why it thinks so. Is this from an open source part of the kernel or from closed source driver? > >> I see that where we would see: >> ATY: vram [8100000:0100000] >> >> So something we are doing in ATI_vga_switch_mode isn’t working the way we need it to for the Mac OS, I’m just not sure what that would be? > > I'm not sure it's the mode switching part which is wrong here (although could be). But if the driver decides it does not like the card before it tries to switch mode or it expects the FCode to already set up the mode then it's not a problem in ati_vga_switch_mode but that the emulated card is not in a state expected by the driver. I think that's more likely, that's why I'm trying to get the FCode run to have it work the same way as on real hardware and see if that makes it any better. But there are still some work on OpenBIOS to get to that point. > > Regards, > BALATON Zoltan

2 3

[PATCH 00/28] pci: build device tree from root
by Mark Cave-Ayland July 20, 2019

July 20, 2019

This patchset started off with the aim of building the PCI-based machine device trees downwards from the root node to avoid switching either the active package and/or current instance at various points during the tree construction. The basis for this was to try and remove all named nodes (those which are placed at a given path) and instead build the hierarchy in order by using new-device and finish-device as per the IEEE-1275 specification. This was realised by creating a new BIND_NODE_METHODS() macro which is similar to REGISTER_NAMED_NODE() except that it doesn't alter either the active package or the current instance, and then working through the device tree from the root converting all the devices for the PCI-based machines to use it. Once this conversion has been completed for all devices beneath the PCI node, it becomes possible to remove both the REGISTER_NAMED_NODE() and REGISTER_NAMED_NODE_PHANDLE() macros to prevent future patches from accidentally changing the tree construction order. Next the x86, PPC and SPARC64 device tree roots were altered to set the active package and current instance, allowing the remaining places where the PCI code alters either of them to be removed. At this point instance variables were working correctly, and I noticed that there were several PCI devices which made use of C initialisation functions and/or properties for initial configuration. These can now be replaced with instance variables to keep everything simple and consistent. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (28): libopenbios: introduce BIND_NODE_METHODS() macro pc_kbd: convert to use BIND_NODE_METHODS() macro pc_serial: convert to use BIND_NODE_METHODS() macro floppy: convert to use BIND_NODE_METHODS() macro ide: convert to use BIND_NODE_METHODS() macro adb: convert to use BIND_NODE_METHODS() macro escc: convert to use BIND_NODE_METHODS() macro cuda: convert to use BIND_NODE_METHODS() macro macio: convert to use BIND_NODE_METHODS() macro pmu: convert to use BIND_NODE_METHODS() macro usbhid: convert to use BIND_NODE_METHODS() macro nvram: convert to use BIND_NODE_METHODS() macro lsi: don't change active package when setting device alias lsi: convert to use BIND_NODE_METHODS() macro virtio: convert to use BIND_NODE_METHODS() macro pci: convert to use BIND_NODE_METHODS() macro pci: remove ob_pci_initialize() and ob_pci_empty_node libopenbios: remove REGISTER_NAMED_NODE and REGISTER_NAMED_NODE_PHANDLE macros ppc: move New World uninorth and nvram device node creation to the root device ppc: set active package and current instance to root device node before probe SPARC64: set active package and current instance to root device node before probe x86: set active package and current instance to root device node before probe pci: remove explicit find-device from PCI devices pci: remove explicit setting of my-self from PCI devices pc_serial: remove separate init word pc_kbd: use instance value to initialise C instance parameter lsi: use instance value to hold sd_private_t pointer virtio: use instance value to initialise C instance parameter arch/ppc/qemu/init.c | 13 +++ arch/sparc64/openbios.c | 6 ++ arch/x86/openbios.c | 9 +- drivers/adb_bus.c | 57 +++++++----- drivers/adb_kbd.c | 25 ++++-- drivers/adb_mouse.c | 31 ++++--- drivers/cuda.c | 158 ++++++++++++++++++++------------- drivers/escc.c | 113 ++++++++++++++--------- drivers/floppy.c | 68 +++++++------- drivers/ide.c | 123 +++++++++++++++---------- drivers/lsi.c | 65 +++++++------- drivers/macio.c | 117 ++++++++++++------------ drivers/macio.h | 1 - drivers/pc_kbd.c | 48 +++++----- drivers/pc_serial.c | 32 +++---- drivers/pci.c | 102 +++++++-------------- drivers/pmu.c | 152 +++++++++++++++++++++---------- drivers/usbhid.c | 16 ++-- drivers/virtio.c | 49 +++------- include/drivers/drivers.h | 2 + include/libopenbios/bindings.h | 19 ++-- include/packages/nvram.h | 4 +- libopenbios/bindings.c | 10 +++ packages/nvram.c | 32 ++++++- 24 files changed, 722 insertions(+), 530 deletions(-) -- 2.20.1

1 28

set package unit in forth
by BALATON Zoltan July 19, 2019

July 19, 2019

Hello, I'm trying to port fdt unflattening from SLOF to OpenBIOS but need some help with understanding and implementing equivalent forth words, The SLOF fdt.fs uses set-unit which is defined in https://github.com/aik/SLOF/blob/master/slof/fs/node.fs : set-space get-node dup >r node>space ! true r> node>space? ! ; : set-address my-#address-cells 1 ?DO get-node node>space i cells + ! LOOP ; : set-unit set-space set-address ; These set the unit address manipulating the fields of the node struct as far as I understand. But I don't know how to do the same in OpenBIOS. OpenBIOS implements the word that returns these values that set-unit is supposed to change in https://github.com/openbios/openbios/blob/master/forth/device/package.fs#L1… as : my-unit ( -- phys.lo ... phys.hi ) ?my-self >in.my-unit my-#acells tuck /l* + swap 0 ?do /l - dup l@ swap loop drop ; but I don't understand how these are stored in OpenBIOS and how to change them. Could somone who understands forth or know OpenBIOS more suggest an implementation of set-unit for OpenBIOS please? We'll also need set-node which sets active-package I think so suggestions for that are also welcome. Thank you, BALATON Zoltan

2 3

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons July 13, 2019

July 13, 2019

Ok, I made those changes to openbios, here is the output. > On May 8, 2018, at 6:50 AM, Joe van Tunen <joevt(a)shaw.ca> wrote: > > : (debug-feval) ( fcode# -- fcode# ) > \ Address > fcode-stream 1 - . here u. ." : " > > \ Indicate if word is compiled > state @ 0<> if > ." (compile) " > then > dup fcode>xt cell - lfa2name type > dup ." [ 0x" . ." ]" cr > ;

7 54

[PATCH v5] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
by BALATON Zoltan July 4, 2019

July 4, 2019

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS only handles a single PCI bus and initialises and puts info in the device tree of the second PCI bus only which is where devices are connected and calls it bus 0. However, some clients may not know about this or have hardcoded assumptions and 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 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 that to be reverted. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index f72728c..a996404 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,46 @@ static void kvm_of_init(void) fword("finish-device"); } +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + 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 -- ) */ @@ -859,7 +899,17 @@ arch_of_init(void) feval("['] ppc-dma-sync to (dma-sync)"); #ifdef CONFIG_DRIVER_PCI + /* Add empty node for first pci bus on MAC99 */ + /* Remove this when pci driver is fixed to handle multiple buses */ + empty_pci_bus_init(); ob_pci_init(); + if (machine_id == ARCH_MAC99) { + phandle_t dev = find_dev("/pci@f2000000"); + if (dev) { + u32 props[2] = {0, 1}; + set_property(dev, "bus-range", (char *)props, 2 * sizeof(props[0])); + } + } #endif printk("\n"); -- 2.13.7

2 8