- OpenBIOS - mail.coreboot.org

[PATCH] Add experimental SMP support for mac99/G4
by Andrew Randrianasulu 12 Mar '25

12 Mar '25

Surely something still wrong because it breaks -M g3beige :( but at least ./qemu-system-ppc64 -accel tcg,thread=multi -smp 2 -M mac99,via=pmu -cpu g4 -bios ~/obj-ppc/openbios-qemu.elf -display sdl -hda ~/QEMU/osx-tiger_10.4.11_installed-compressed.qcow starts fine and uses two processors with corresponding qemu patch Originally developed/posted at https://mail.gnu.org/archive/html/qemu-ppc/2025-03/msg00020.html

2 5

Re: SMP on Mac99
by Jd Lyons 24 Feb '25

24 Feb '25

My qemu local sources are a mess, I’ve made a huge amount of changes, most of them likely break more than they fix. I’ve reapplied the original two patches to fresh copies of the masters of openbios and qemu a few times, but I just end up building more and more on top of them. If I ever get smp working the hard part will be cleaning up the code so I can come up with a diff that others can actually use without breaking anything I did not test. Really it’s only changes to a few files, one in openbios, and about 4 in qemu, so it should not be too hard to fix. > On Feb 24, 2025, at 8:22 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > Do you have any other changes than the openbios patch and qemu-v2 patch I've sent? If so maybe try afresh with only these two patches to make sure you don't have any other change breaking anything.

1 0

Re: Openbios code for IRQ or interrupt handling?
by Jd Lyons 22 Feb '25

22 Feb '25

I’m starting cpu1 in the halted state, you’re one step ahead of me, and replying before zi see you have already answered the question. Sorry, that’s my fault for not checking before I hit send. > On Feb 22, 2025, at 9:54 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 22 Feb 2025, Jd Lyons wrote: >> There is IPI code in the openpic.c but I’m not sure it’s woking at all, I don’t see any IACK in my debug info for openpic.c when I turn on the debug option 1 to true. >> >> Maybe IACK is not logged, but clearly both CPUs are responding to IRQ requests, they just maybe stuck responding to the same requests, that’s all I can figure. > > If you start with both CPUs running they will both execute the whole boot in parallel but they will also both poke the same devices so this won't work. The second processor should stay halted until the kernel resets it through the GPIO line at which point it will have set up the code so the second CPU will run the code it should run and not mix up what CPU0 is doing. This also something I've explained before. > > Regards, > BALATON Zoltan

2 1

Re: Openbios code for IRQ or interrupt handling?
by Jd Lyons 22 Feb '25

22 Feb '25

I did not see your patch until I had already hacked in some code to read the level register just to see if my trace of macio* would log the reads. It seem to me the state of the level registers should not be zero at boot, that Linux would read the level registers first to we the state of the gpio so it would know what registers to write to when it tries to kick the second cpu? > On Feb 22, 2025, at 9:37 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Sat, 22 Feb 2025, Jd Lyons wrote: >> Ok the level register are read-only but that does not mean their status can not change, writes to the other register can change the status of the level registers because they should reflect the state of the mappings of the gpio, or something like that… > > Maybe but probably OS only cares about level for input GPIOs. For GPIOs set to output it probably only writes them. Why would it want to read their state when it just set it and knows what state is it. > >> I but in a function to read the status of the level registers when the MacIO device resets (via macio_gpio_reset) >> >> I get this logged at boot: >> >> trace_macio_gpio_read: addr=0x0, val=0x0 >> trace_macio_gpio_read: addr=0x1, val=0x0 >> trace_macio_gpio_read: addr=0x2, val=0x0 >> trace_macio_gpio_read: addr=0x3, val=0x0 >> trace_macio_gpio_read: addr=0x4, val=0x0 >> trace_macio_gpio_read: addr=0x5, val=0x0 >> trace_macio_gpio_read: addr=0x6, val=0x0 >> trace_macio_gpio_read: addr=0x7, val=0x0 > > How? macio_gpio_reset only calls macio_set_gpio(s, 1, true); > >> Then when this is written by the linux kernel trying to ‘kick’ CPU1 to start >> macio_gpio_write addr: 0xc value: 0x4 >> macio_gpio_write addr: 0xc value: 0x0 >> >> I get this logged: >> >> trace_macio_gpio_read: addr=0x4, val=0x4 >> trace_macio_gpio_read: addr=0x4, val=0x0 > > I can't make sense of these log excerpts so I have no idea what you're doing. Either post more meaningful logs showing what the kernel does or you're on your own. > >> So we know that macio_gpio_reset is called when linux tries to ‘kick’ the second CPU. > > No, reset is called when QEMU starts or when the macio device is reset. The part that kicks additional CPUs out of halt only writes the macio gpio regs so you should see trace_macio_gpio_read and trace_macio_gpio_write calls at that point. The problem is that qemu/hw/misc/macio/gpio.c does not seem to emulate what the real chip should do so this should be fixed. For example macio_gpio_read returns s->gpio_levels[addr]; for reading the level regs but nothing ever sets the gpio_levels so it will always read 0. This may not be an issue if there are no input GPIOs involved. macio_gpio_write also does not set any GPIO level so no matter what the guest writes here it won't have any effect. It should set the GPIO level for output GPIOs but then you still won't see it doing anything before also connecting that GPIO line somewhere. > >> Notice that it no longer tries to write to 0x4, I’m not sure why, my code causes linux to not try and write any values to the status register???? > > I don't know what your code is. If you see reads now after applying my patch then that just corrected the logs. These were always reads erroneously logged as writes that I was telling you to fix for days so you actually see what is happening and not base theories on wrong logs. You could also read what the Linux source does that I'm also telling you to do for a few days. You won't be able to figure this out without reading the linux/arch/powerpc/platforms/powermac/feature.c::core99_reset_cpu() function and qemu/hw/misc/macio/gpio.c files and understand what they are doing. These aren't too complex so if you can't read and understand these go back and start with some C programming tutorial to be able to understand what these code parts do. > > Regards, > BALATON Zoltan

2 1

Re: Openbios code for IRQ or interrupt handling?
by Jd Lyons 20 Feb '25

20 Feb '25

I can’t figure out this race condition but it causes an IRQ storm. I feel like I’m in the old days of PC’s when to had IRQ conflicts and had to sort them yourself deep in the bios. As a Mac person I only had to deal with that on a few friends PC’s. Starting the second CPU in a on state rather than halted just makes the race condition worse, twice as fast, and Openbios doesn’t want to get to the prompt, but throwing 3, 8, or 9 CPUs at it in a running state gets me to the prompt, but it ignores -prom-env setting with anything more that three. 300% cpu usage just speeds up the race condition and IRQ storm so IDE craps out before you can load BootX or a linux kernel. Then noting happens but the IRG storm and GPIO 1 asserting 0, likely to all the other CPUs, and that is likely the race conditions and pulling that low trigger the IRQ storm. I can’t make it stop, I even tied all IRQ and Interrupts handling to CPU0, and that working until the OS Kenral loads and starts sending stuff to CPU1, which is still in a halted state unless I start it with my hack. Even with only CPU0 dealing with IRQs and Interrupts the race condition is still there and the IRQ storm. I have to figure out why GPIO 1keeps getting triggered in a loop to pull low???? > On Feb 19, 2025, at 1:29 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > Thanks Mark, I got side traced thinking open-pic when I should have been looking at GPIO because it is the one that is the gpio-parent there should be no interrupt-parent property. I think the gpio phandle is 7. > > Can you tell me how IRQ’s get assigned to CPU0? > > Interrupts? > >> On Feb 18, 2025, at 5:00 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: >> >> On 18/02/2025 21:34, Jd Lyons via OpenBIOS wrote: >> >>> I don’t know why, I can’t seem to get Openbios to set and interrupt-parent in the init.c for any /cpus, this code should work, no? >>> void add_cpu_nodes(void) { >>> int num_cpus = fw_cfg_read_i32(FW_CFG_NB_CPUS); >>> printk("Detected %d CPUs\\n", num_cpus); >>> /* Ensure /cpus node exists */ >>> phandle cpus_node = dt_find_by_path("/cpus"); >>> if (!cpus_node) { >>> printk("ERROR: /cpus node not found! Delaying CPU setup.\\n"); >>> return; >>> } >>> /* Wait until the interrupt controller exists */ >>> phandle intc_node = NULL; >>> int retries = 5; >>> while (retries-- > 0) { >>> intc_node = dt_find_by_path("/pci/mac-io/@40000"); >> >> Is this for the mac99 machine? If so you probably want /pci@f2000000/mac-io@c/interrupt-controller@40000 (see the output of show-devs for the full device paths). >> >>> if (intc_node) { >>> break; >>> } >>> printk("Waiting for /pci/mac-io/@40000...\\n"); >>> msleep(100); // Wait 100ms before retrying >>> } >>> if (!intc_node) { >>> printk("ERROR: Interrupt controller (/pci/mac-io/@40000) not found! SMP will not work.\\n"); >>> return; >>> } >>> for (int i = 0; i < num_cpus; i++) { >>> phandle cpu_node = dt_new_node(cpus_node); >>> if (!cpu_node) { >>> printk("ERROR: Failed to create CPU node for CPU %d!\\n", i); >>> continue; >>> } >>> dt_set_property_string(cpu_node, "device_type", "cpu"); >>> dt_set_property_string(cpu_node, "compatible", "PowerPC,G4"); >>> /* Assign a unique CPU interrupt */ >>> int cpu_irq[2] = { 16 + i, 0 }; >>> dt_set_property_cells(cpu_node, "interrupts", cpu_irq, 2); >>> printk("CPU %d assigned IRQ %d\\n", i, cpu_irq[0]); >>> /* Ensure interrupt-parent is set */ >>> dt_set_property_phandle(cpu_node, "interrupt-parent", intc_node); >>> printk("CPU %d linked to interrupt-parent /pci/mac-io/@40000\\n", i); >>> /* Register CPU ID */ >>> PUSH(i); >>> fword("encode-int"); >>> push_str("reg"); >>> fword("property"); >>> fword("finish-device"); >>> printk("Initialized CPU %d\\n", i); >>> } >>> } >> >> >> ATB, >> >> Mark. >

3 13

Openbios code for IRQ or interrupt handling?
by Jd Lyons 18 Feb '25

18 Feb '25

Mark, anyone, is there code in Openbios that deals with IRQ’s or Interrupts? I’m tracking down an issue with IRQ’s casing the IDE,, RTC, USB…… not to work with SMP patches and I’m not sure if it’s an issue with QEMU or Openbios patches I have applied.

2 4

Re: OpenMPIC controller emulation in qemu
by Jd Lyons 15 Feb '25

15 Feb '25

I think the soft-reset is what we may need but the gpio stuff may also be important. Last login: Sat Feb 15 12:30:21 on ttys000 jam@Mac ~ % cd q3/qemu/build jam@Mac build % ./qemu-system-ppc64-unsigned -m 1024 -cpu 7455 -hda ~/Snow*.img -prom-env 'boot-args=-v -x -s' -smp 2,cores=1,threads=1,sockets=2 -accel tcg,thread=multi -d guest_errors -cdrom /Users/jam/Downloads/ubuntu-mate-16.04.1-desktop-powerpc.iso -boot d -device usb-mouse -boot d -prom-env 'auto-boot?=false' -M mac99,via=pmu -nographic -bios /Users/jam/Documents/openbios-qemu.elf WARNING: Image format was not specified for '/Users/jam/SnowLeopardPPC.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. s>> et_property: NULL phandle >> ============================================================= >> OpenBIOS 1.1 [Feb 14 2025 10:28] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 2 >> Memory: 1024M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Feb 14 2025 10:28 0 > dev /cpus/@0 .properties name "PowerPC,G4" device_type "cpu" cpu-version 80010302 d-cache-size 8000 i-cache-size 8000 d-cache-sets 80 i-cache-sets 80 d-cache-block-size 20 i-cache-block-size 20 tlb-sets 40 tlb-size 80 timebase-frequency 17d7840 clock-frequency 35a4e900 bus-frequency 5f5e100 state "running" reservation-granule-size 20 reg 00000000 available 00004000 03ffc000 04800000 3b458000 3fe10000 401f0000 translations 04000000 00800000 04000000 00000000 3fc58000 001b8000 3fc58000 00000000 fff00000 00100000 3ff00000 00000000 ok 0 > dev /cpus/@1 .properties name "PowerPC,G4" device_type "cpu" cpu-version 80010302 d-cache-size 8000 i-cache-size 8000 d-cache-sets 80 i-cache-sets 80 d-cache-block-size 20 i-cache-block-size 20 tlb-sets 40 tlb-size 80 timebase-frequency 17d7840 clock-frequency 35a4e900 bus-frequency 5f5e100 state "running" reservation-granule-size 20 reg 00000001 ok 0 > > On Feb 15, 2025, at 12:24 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > Don’t give up yet, we can get more people involved….. > > Here is the dump of the DP MDD /cpus node, there is some interesting stuff there…. > > > > > > > > > > > > 0 > dev /cpus/@0 .properties > name PowerPC,G4 > > device_type cpu > reg 00000000 > cpu-version 80010201 > state running > clock-frequency 33a848a8 > bus-frequency 07f0db85 > config-bus-frequency 07f0b5db > timebase-frequency 01fc36e1 > reservation-granule-size00000020 > tlb-sets 00000040 > tlb-size 00000080 > d-cache-size 00008000 > i-cache-size 00008000 > d-cache-sets 00000080 > i-cache-sets 00000080 > i-cache-block-size 00000020 > d-cache-block-size 00000020 > graphics > performance-monitor > altivec > data-streams > l2-cache ff87fd10 > l2cr 80080000 > existing 00000000 80000000 80000000 80000000 > available 00003000 7fffd000 d0000000 20000000 > translations 00000000 00003000 00000000 00000010 80000000 00080000 > 80000000 00000028 80080000 00001000 80080000 00000028 > 80081000 00001000 80081000 00000028 f0000000 00010000 > f0000000 00000028 f0800000 00001000 f0800000 00000028 > f0c00000 00001000 f0c00000 00000028 f2000000 00010000 > f2000000 00000028 f2800000 00001000 f2800000 00000028 > f2c00000 00001000 f2c00000 00000028 f4000000 00010000 > f4000000 00000028 f4800000 00001000 f4800000 00000028 > f4c00000 00001000 f4c00000 00000028 f5000000 00001000 > f5000000 00000028 f5200000 00200000 f5200000 00000028 > f5200000 00200000 f5200000 00000028 > ... 00000140 bytes total > cpu-info 8410c0bc 80080000 80010201 00000400 00000000 00000000 > 00000000 00000000 > soft-reset 00000071 <<—————————Here > gpio-mask 00000001 <<—————————Here > gpio-value 00000001 <<—————————Here > performance-monitor-cnt-enable 00000072 > timebase-enable 00000073 <<—————————Here > gpio-parent ff95c318 <<—————————Here > > ok > 0 > dev /cpus/@1 ok > 0 > .properties > name PowerPC,G4 > > device_type cpu > reg 00000001 > cpu-version 80010201 > state stopped > clock-frequency 33a848a8 > bus-frequency 07f0db85 > config-bus-frequency 07f0b5db > timebase-frequency 01fc36e1 > reservation-granule-size00000020 > tlb-sets 00000040 > tlb-size 00000080 > d-cache-size 00008000 > i-cache-size 00008000 > d-cache-sets 00000080 > i-cache-sets 00000080 > i-cache-block-size 00000020 > d-cache-block-size 00000020 > graphics > performance-monitor > altivec > data-streams > l2-cache ff880fd0 > l2cr 80080000 > cpu-info 8431c0bc 00000000 80010201 00000400 fff0376c 0000b010 > 00060110 21524110 > soft-reset 00000072 <<—————————Here > gpio-mask 00000001 <<—————————Here > gpio-value 00000001 <<—————————Here > timebase-enable 00000073 > cpu-interrupt-enable 00000074 <<—————————Here > gpio-parent ff95c318 <<—————————Here > > > > > > > > > > > > > > > > > > > > > customer-sw-config 694-4782 > > > color-code ff11 > scb# 00000000 > display-config-info ffffffff ffffffff > name device-tree > copyright Copyright 1983-2002 Apple Computer, Inc. All Rights Reserved > device_type bootrom > system-id 0000000000000 > #address-cells 00000001 > #size-cells 00000001 > clock-frequency 07f0db85 > AAPL,add-fcode-file ff860928 > > ok > 0 > > >> On Feb 15, 2025, at 11:53 AM, Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: >> >> >> >> сб, 15 февр. 2025 г., 19:37 Jd Lyons <lyons_dj(a)yahoo.com <mailto:lyons_dj@yahoo.com>>: >>> Mate Live CD does default to SMP: >> >> >> Thanks for testing. >> >> Unfortunately,I think I just fundamentally misunderstood how IRQ vs IPI works so .. in absence of someone with working understanding of how all this really work this probably will not progress much ... >> >> sorry! >> >> >>> >>> >> ============================================================= >>> >> OpenBIOS 1.1 [Feb 14 2025 10:28] >>> >> Configuration device id QEMU version 1 machine id 1 >>> >> CPUs: 2 >>> >> Memory: 1024M >>> >> UUID: 00000000-0000-0000-0000-000000000000 >>> >> CPU type PowerPC,G4 >>> >> CPU type PowerPC,G4 >>> milliseconds isn't unique. >>> Welcome to OpenBIOS v1.1 built on Feb 14 2025 10:28 >>> >>> 0 > boot Trying cd:,\\:tbxi... >>> >> switching to new context: >>> >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> call-method color!: exception -21 >>> >> call-method color! failed with error ffffffdf >>> >>> Config file read, 2702 bytes >>> >>> Welcome to Ubuntu MATE 16.04.1 LTS (Xenial Xerus)! >>> >>> This is an Ubuntu MATE live CDROM, >>> built on 20160719. >>> >>> The default option is 'live'. >>> >>> If the system fails to boot at all (the typical >>> symptom is a white screen which doesn't go away), >>> use 'live video=ofonly'. >>> >>> Press the tab key for a list of options, or type >>> 'help' for help. >>> >>> ************************************ >>> If in doubt, just press Enter, and if that >>> doesn't work, type 'live video=ofonly'. >>> ************************************ >>> Welcome to yaboot version 1.3.16 >>> Enter "help" to get some basic usage information >>> >>> WARNING: Bootstrap partition type is wrong: "Apple_HFS" >>> type should be: "Apple_Bootstrap" >>> >>> boot: live >>> Please wait, loading kernel... >>> Elf32 kernel loaded... >>> Loading ramdisk... >>> ramdisk loaded at 01b00000, size: 22562 Kbytes >>> OF stdout device is: /pci@f2000000/mac-io@c/escc@13000/ch-a@13020 >>> Preparing to boot Linux version 4.4.0-31-powerpc-smp (buildd@denneed03) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #50-Ubuntu SMP Wed Jul 13 00:23:04 UTC 2016 (Ubuntu 4.4.0-31.50-powerpc-smp 4.4.13) >>> Detected machine type: 00000400 >>> command line: >>> memory layout at init: >>> memory_limit : 00000000 (16 MB aligned) >>> alloc_bottom : 03109000 >>> alloc_top : 30000000 >>> alloc_top_hi : 40000000 >>> rmo_top : 30000000 >>> ram_top : 40000000 >>> found display : /pci@f2000000/QEMU,VGA@e, opening... done >>> copying OF device tree... >>> Building dt strings... >>> Building dt structure... >>> Device tree strings 0x0320a000 -> 0x0320a5ea >>> Device tree struct 0x0320b000 -> 0x03212000 >>> Quiescing Open Firmware ... >>> Booting Linux via __start() ... >>> Trying to read invalid spr 1012 (0x3f4) at 00000000c0015f18 >>> Hello World ! >>> setup_arch: initmem >>> arch: exit >>> smp_core99_probe >>> smp_core99_kick_cpu >>> smp_core99_kick_cpu done >>> [ 5.131667] Processor 1 is stuck. >>> [ 5.131667] Processor 1 is stuck. >>> >>> It tries to kickstart SMP but Processor 1 is stuck! >>> >>> >>> >>> [ 54.955254] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 54.955664] ata1.00: failed command: READ DMA >>> [ 54.955950] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 54.955950] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 54.956472] ata1.00: status: { DRDY } >>> [ 85.930746] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 85.931000] ata1.00: failed command: READ DMA >>> [ 85.931149] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 85.931149] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 85.931569] ata1.00: status: { DRDY } >>> [ 116.970014] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 116.970250] ata1.00: failed command: READ DMA >>> [ 116.970402] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 116.970402] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 116.970814] ata1.00: status: { DRDY } >>> [ 148.010809] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 148.011048] ata1.00: failed command: READ DMA >>> [ 148.011195] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 148.011195] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 148.011610] ata1.00: status: { DRDY } >>> [ 178.986502] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 178.986758] ata1.00: failed command: READ DMA >>> [ 178.986906] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 178.986906] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 178.987328] ata1.00: status: { DRDY } >>> [ 209.962237] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 209.962474] ata1.00: failed command: READ DMA >>> [ 209.962622] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 209.962622] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 209.963038] ata1.00: status: { DRDY } >>> [ 209.966227] blk_update_request: I/O error, dev sda, sector 0 >>> [ 209.966534] Buffer I/O error on dev sda, logical block 0, async page read >>> [ 240.937824] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 240.938059] ata1.00: failed command: READ DMA >>> [ 240.938205] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 240.938205] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 240.938642] ata1.00: status: { DRDY } >>> [ 245.234331] INFO: task swapper/0:1 blocked for more than 120 seconds. >>> [ 245.234688] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 245.234864] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 245.235822] INFO: task kworker/0:1:30 blocked for more than 120 seconds. >>> [ 245.236016] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 245.236176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 271.977850] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 271.978090] ata1.00: failed command: READ DMA >>> [ 271.978241] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 271.978241] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 271.978653] ata1.00: status: { DRDY } >>> [ 302.122355] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 302.122600] ata1.00: failed command: READ DMA >>> [ 302.122746] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 302.122746] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 302.123172] ata1.00: status: { DRDY } >>> [ 333.162381] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 333.162651] ata1.00: failed command: READ DMA >>> [ 333.162795] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 333.162795] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 333.163229] ata1.00: status: { DRDY } >>> [ 364.138445] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 364.138696] ata1.00: failed command: READ DMA >>> [ 364.138844] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 364.138844] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 364.139276] ata1.00: status: { DRDY } >>> [ 365.233579] INFO: task swapper/0:1 blocked for more than 120 seconds. >>> [ 365.233825] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 365.233992] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 365.234445] INFO: task kworker/0:1:30 blocked for more than 120 seconds. >>> [ 365.234633] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 365.234792] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 365.235276] INFO: task kworker/u4:2:79 blocked for more than 120 seconds. >>> [ 365.235467] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 365.235625] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 395.178285] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 395.178536] ata1.00: failed command: READ DMA >>> [ 395.178681] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 395.178681] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 395.179112] ata1.00: status: { DRDY } >>> [ 395.180504] blk_update_request: I/O error, dev sda, sector 0 >>> [ 395.180710] Buffer I/O error on dev sda, logical block 0, async page read >>> [ 426.154784] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 426.155025] ata1.00: failed command: READ DMA >>> [ 426.155173] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 426.155173] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 426.155585] ata1.00: status: { DRDY } >>> [ 457.130476] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>> [ 457.130713] ata1.00: failed command: READ DMA >>> [ 457.130859] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >>> [ 457.130859] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) >>> [ 457.131276] ata1.00: status: { DRDY } >>> [ 485.233894] INFO: task swapper/0:1 blocked for more than 120 seconds. >>> [ 485.234188] Not tainted 4.4.0-31-powerpc-smp #50-Ubuntu >>> [ 485.234347] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 485.234787] INFO: task kworker/0:1:30 blocked for more than 120 seconds. >

1 0

Re: OpenMPIC controller emulation in qemu ?
by Jd Lyons 13 Feb '25

13 Feb '25

Did you guys ever make more progress on adding spm to the Mac99 machine? Any patches?

1 0

[PATCH v3 0/3] esp: fixups to correctly terminate successful SCSI commands
by Mark Cave-Ayland 22 Sep '24

22 Sep '24

This series is an extension of the v2 patch with a couple of modifications to clear the FIFO at the start of the command, and to poll the ESP interrupt register to detect the end of the transfer. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v3: - Clear FIFO before issuing ESP command - Poll ESP interrupt register to detect end of transfer v2: - Fix typo in commit message spotted by Zoltan Mark Cave-Ayland (3): esp: clear FIFO before issuing ESP command esp: use ESP rather than DMA interrupt to detect end of transfer esp: correctly terminate successful SCSI commands drivers/esp.c | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) -- 2.39.2

1 4

[PATCH v2] README: change reference from LinuxBIOS to coreboot
by Mark Cave-Ayland 22 Sep '24

22 Sep '24

The linuxbios.org website does not exist anymore, so point the reader towards coreboot.org instead. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Resolves: https://github.com/openbios/openbios/issues/17 Reviewed-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) v2: - Add R-B and T-B tags from Phil - Replace Coreboot with coreboot as indicated by Segher diff --git a/README b/README index 9f4b705..bf7684a 100644 --- a/README +++ b/README @@ -17,8 +17,8 @@ kernel and three interfaces for user interaction, device initialization and client (operating system) control. While far not all possible applications of OpenBIOS are implemented yet, -a lot of functionality is already there. OpenBIOS can be used to enhance -LinuxBIOS (http://www.linuxbios.org), or be booted from any multiboot +a lot of functionality is already there. OpenBIOS can be used as a payload +for coreboot (http://www.coreboot.org), or be booted from any multiboot capable bootloader to bring Open Firmware to your machine. OpenBIOS can also be used when an operating system is already running. It provides the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS -- 2.39.2

1 1

[PATCH] cuda: fix len calculation in cuda_adb_req
by Amadeusz Sławiński 22 Sep '24

22 Sep '24

When advancing buffer by 1, len should be shorthened by appropriate amount, instead of setting it to -1. Found with cppcheck. Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> --- drivers/cuda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cuda.c b/drivers/cuda.c index 86d2ddb..93a935a 100644 --- a/drivers/cuda.c +++ b/drivers/cuda.c @@ -162,7 +162,7 @@ static int cuda_adb_req (void *host, const uint8_t *snd_buf, int len, } } else { pos = buffer + 1; - len = -1; + len -= 1; } memcpy(rcv_buf, pos, len); -- 2.44.0

2 2

[PATCH v2] esp: correctly terminate successful SCSI commands
by Mark Cave-Ayland 11 Sep '24

11 Sep '24

An upcoming series for QEMU's ESP emulation will check that ESP commands are only issued according to their valid states as listed in the datasheet, and otherwise generate an illegal command interrupt. Currently if a SCSI command is expected to return no data or transfers data successfully, the ASC is not returned to its disconnected state. This means that any subsequent ESP initiator commands should be rejected until the SCSI bus transaction is terminated. Update the ESP driver so that if a SCSI command is successful then the ICCS and MSGACC commands are issued by the host to complete the SCSI transaction. This ensures that the ASC is returned to the disconnected state which allows the ESP to accept subsequent SCSI commands without generating an illegal command interrupt. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/esp.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) v2: - Fix typo in commit message spotted by Zoltan diff --git a/drivers/esp.c b/drivers/esp.c index 0880ab2..b1b10f4 100644 --- a/drivers/esp.c +++ b/drivers/esp.c @@ -113,7 +113,8 @@ do_command(esp_private_t *esp, sd_private_t *sd, int cmdlen, int replylen) return status; } if (replylen == 0) { - return 0; + /* No reply expected, ICCS and MSGACC to complete */ + goto done; } /* Target went to status phase instead of data phase? */ if ((status & ESP_STAT_PMASK) == ESP_STATP) { @@ -139,10 +140,18 @@ do_command(esp_private_t *esp, sd_private_t *sd, int cmdlen, int replylen) DPRINTF("do_command_reply: status 0x%x\n", status); - if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) + if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) { return status; - else - return 0; // OK + } + +done: + // ICCS and MSGACC sequence to complete + esp->ll->regs[ESP_CMD] = ESP_CMD_ICCSEQ; + (void)esp->ll->regs[ESP_FDATA]; // Ignore 1st byte for now + (void)esp->ll->regs[ESP_FDATA]; // Ignore 2nd byte for now + esp->ll->regs[ESP_CMD] = ESP_CMD_MOK; + + return 0; // OK } // offset is in sectors -- 2.39.2

1 1

[PATCH] esp: correctly terminate successful SCSI commands
by Mark Cave-Ayland 08 Sep '24

08 Sep '24

An upcoming series for QEMU's ESP emulation will check that ESP commands are only issued according to their valid states as listed in the datasheet, and otherwise generate an illegal command interrupt. Currently if a SCSI command is expected to return no data or transfers data successfully, the ASC is not returned to its disconnected state. This means that any subsequent ESP initiator commands should be rejected until the the SCSI bus transaction is terminated. Update the ESP driver so that if a SCSI command is successful then the ICCS and MSGACC commands are issued by the host to complete the SCSI transaction. This ensures that the ASC is returned to the disconnected state which allows the ESP to accept subsequent SCSI commands without generating an illegal command interrupt. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/esp.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/esp.c b/drivers/esp.c index 0880ab2..b1b10f4 100644 --- a/drivers/esp.c +++ b/drivers/esp.c @@ -113,7 +113,8 @@ do_command(esp_private_t *esp, sd_private_t *sd, int cmdlen, int replylen) return status; } if (replylen == 0) { - return 0; + /* No reply expected, ICCS and MSGACC to complete */ + goto done; } /* Target went to status phase instead of data phase? */ if ((status & ESP_STAT_PMASK) == ESP_STATP) { @@ -139,10 +140,18 @@ do_command(esp_private_t *esp, sd_private_t *sd, int cmdlen, int replylen) DPRINTF("do_command_reply: status 0x%x\n", status); - if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) + if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) { return status; - else - return 0; // OK + } + +done: + // ICCS and MSGACC sequence to complete + esp->ll->regs[ESP_CMD] = ESP_CMD_ICCSEQ; + (void)esp->ll->regs[ESP_FDATA]; // Ignore 1st byte for now + (void)esp->ll->regs[ESP_FDATA]; // Ignore 2nd byte for now + esp->ll->regs[ESP_CMD] = ESP_CMD_MOK; + + return 0; // OK } // offset is in sectors -- 2.39.2

2 3

[PATCH] README: change reference from LinuxBIOS to Coreboot
by Mark Cave-Ayland 06 Sep '24

06 Sep '24

The linuxbios.org website does not exist anymore, so point the reader towards coreboot.org instead. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Resolves: https://github.com/openbios/openbios/issues/17 --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 9f4b705..7e299b0 100644 --- a/README +++ b/README @@ -17,8 +17,8 @@ kernel and three interfaces for user interaction, device initialization and client (operating system) control. While far not all possible applications of OpenBIOS are implemented yet, -a lot of functionality is already there. OpenBIOS can be used to enhance -LinuxBIOS (http://www.linuxbios.org), or be booted from any multiboot +a lot of functionality is already there. OpenBIOS can be used as a payload +for Coreboot (http://www.coreboot.org), or be booted from any multiboot capable bootloader to bring Open Firmware to your machine. OpenBIOS can also be used when an operating system is already running. It provides the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS -- 2.39.2

3 3

[PATCH 0/6] Fixes for Forth PCI config access words and implementation
by Mark Cave-Ayland 30 Jul '24

30 Jul '24

This series provides a set of fixes required to allow Forth PCI config access words to work correctly on both 32-bit and 64-bit platforms, along with Zoltan's original v4 patch. There are 2 main fixes included: - Implement and convert PCI encode-unit/decode-unit to static methods - Fix my-address and my-unit on 64-bit platforms With this series applied it is possible to execute the Forth PCI config words as documented in various drivers as below: PPC (32-bit): 0 > showstack ok 0 > " /pci/QEMU,VGA" open-dev to my-self ok 0 > my-space " config-w@" $call-parent u. 1234 ok 0 > my-space ok 800 < 1 > my-address ok 800 0 0 < 3 > SPARC64 (64-bit, including across PCI bridge): 0 > showstack ok 0 > " /pci/pci@1,1/QEMU,VGA" open-dev to my-self ok 0 > my-space " config-w@" $call-parent u. 1234 ok 0 > my-space ok 11000 < 1 > my-address ok 11000 0 0 < 3 > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> BALATON Zoltan (1): drivers/pci: Implement config access words Mark Cave-Ayland (5): libopenbios/clib.fs: add new is-2arg-cfunc for calling into C libopenbios: introduce BIND_NODE_STATIC_METHOD and supporting functions drivers/pci.c: convert encode-unit and decode-unit words to static methods package.fs: fix my-address on 64-bit systems package.fs: fix my-unit on 64-bit systems drivers/pci.c | 115 +++++++++++++++++++++++++++++++-- forth/device/package.fs | 8 +-- include/libopenbios/bindings.h | 7 ++ libopenbios/bindings.c | 26 ++++++++ libopenbios/clib.fs | 10 +++ 5 files changed, 155 insertions(+), 11 deletions(-) -- 2.30.2

2 14

[PATCH] kernel: fix spelling of endianness
by Mark Cave-Ayland 30 Apr '24

30 Apr '24

This is based upon a similar patch currently being carried in the QEMU Debian package sources. Reported-by: Michael Tokarev <mjt(a)tls.msk.ru> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- kernel/bootstrap.c | 4 ++-- kernel/dict.c | 2 +- kernel/include/dict.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index 9bc94bb..8ad3efe 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -171,9 +171,9 @@ static void write_dictionary(const char *filename) .version = 2, .cellsize = sizeof(ucell), #ifdef CONFIG_BIG_ENDIAN - .endianess = -1, + .endianness = -1, #else - .endianess = 0, + .endianness = 0, #endif .checksum = 0, .compression = 0, diff --git a/kernel/dict.c b/kernel/dict.c index 0986cb1..51afc67 100644 --- a/kernel/dict.c +++ b/kernel/dict.c @@ -252,7 +252,7 @@ void dump_header(dictionary_header_t *header) printk("OpenBIOS dictionary:\n"); printk(" version: %d\n", header->version); printk(" cellsize: %d\n", header->cellsize); - printk(" endianess: %s\n", header->endianess?"big":"little"); + printk(" endianness: %s\n", header->endianness?"big":"little"); printk(" compression: %s\n", header->compression?"yes":"no"); printk(" relocation: %s\n", header->relocation?"yes":"no"); printk(" checksum: %08x\n", target_long(header->checksum)); diff --git a/kernel/include/dict.h b/kernel/include/dict.h index 749fd6f..1e735fa 100644 --- a/kernel/include/dict.h +++ b/kernel/include/dict.h @@ -27,7 +27,7 @@ typedef struct dictionary_header { char signature[8]; u8 version; u8 cellsize; - u8 endianess; + u8 endianness; u8 compression; u8 relocation; u8 reserved[3]; -- 2.39.2

1 1

Re: [PATCH 4/7] drivers/usb.c: rework descriptor read logic in get_descriptor()
by Mark Cave-Ayland 25 Apr '24

25 Apr '24

On 24/04/2024 15:48, Philippe Mathieu-Daudé wrote: > Hi Mark, > > On 22/4/24 09:54, Mark Cave-Ayland wrote: >> When compiling with gcc 12 drivers/usb.c generates the following error: >> >> /root/drivers/usb.c: In function 'get_descriptor': >> /root/drivers/usb.c:200:23: error: array subscript 'device_descriptor_t[0]' is >> partly outside array bounds of 'u8[8]' {aka 'unsigned char[8]'} [-Werror=array-bounds] >> 200 | if (dd->bMaxPacketSize0 != 0) >> | ^~ >> /root/drivers/usb.c:181:12: note: object 'buf' of size 8 >> 181 | u8 buf[8]; >> | ^~~ >> cc1: all warnings being treated as errors >> make[1]: *** [rules.mak:229: target/drivers/usb.o] Error 1 >> make[1]: Leaving directory '/root/obj-ppc' >> >> The compiler is complaining that a device_descriptor_t pointer cast to the 8 byte >> buffer >> means that a pointer dereference to some members of the device_descriptor_t could go >> beyond the end of the 8 byte buffer. Whilst this sounds as if it should be allowed, >> some >> searching suggests that the behaviour of such a cast is undefined. >> >> Rework get_descriptor() so that an entire device_descriptor_t is used to store the >> first >> 8 bytes of the incoming descriptor, and update the buf references to use the >> equivalent >> device_descriptor_t fields instead. >> >> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> >> --- >> drivers/usb.c | 17 ++++++++--------- >> 1 file changed, 8 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/usb.c b/drivers/usb.c >> index 88b7580..d0e1ae5 100644 >> --- a/drivers/usb.c >> +++ b/drivers/usb.c >> @@ -178,7 +178,7 @@ u8 * >> get_descriptor (usbdev_t *dev, unsigned char bmRequestType, int descType, >> int descIdx, int langID) >> { >> - u8 buf[8]; >> + device_descriptor_t dd; >> u8 *result; >> dev_req_t dr; >> int size; >> @@ -189,24 +189,23 @@ get_descriptor (usbdev_t *dev, unsigned char bmRequestType, >> int descType, >> dr.wValue = __cpu_to_le16((descType << 8) | descIdx); >> dr.wIndex = __cpu_to_le16(langID); >> dr.wLength = __cpu_to_le16(8); >> - if (dev->controller->control (dev, IN, sizeof (dr), &dr, 8, buf)) { >> + if (dev->controller->control (dev, IN, sizeof (dr), &dr, 8, (u8 *)&dd)) { > > Still using dalen=8 seems odd. You only fill the first 8 bytes of dd, > leaving the rest uninitialized. Looking at which fields are used, it > is OK, but hard to review and possibly bugprone if this function were > modified in the future. > > Why not use sizeof (dd) instead? That still fits into a page, so > performance overhead is unlikely. > > My 2 cents, otherwise LGTM. Thanks! I did consider whether this would matter, but given that only the first 8 bytes were accessed it didn't seem to matter where the extra junk at the end of device_descriptor_t came from, so I kept it simple. The corresponding file upstream is very different from what is in OpenBIOS, so possibly this could be made clearer with an update, but that requires quite a bit more work :/ >> usb_debug ("getting descriptor size (type %x) failed\n", >> descType); >> } >> if (descType == 1) { >> - device_descriptor_t *dd = (device_descriptor_t *) buf; >> - usb_debug ("maxPacketSize0: %x\n", dd->bMaxPacketSize0); >> - if (dd->bMaxPacketSize0 != 0) >> - dev->endpoints[0].maxpacketsize = dd->bMaxPacketSize0; >> + usb_debug ("maxPacketSize0: %x\n", dd.bMaxPacketSize0); >> + if (dd.bMaxPacketSize0 != 0) >> + dev->endpoints[0].maxpacketsize = dd.bMaxPacketSize0; >> } >> /* special case for configuration descriptors: they carry all their >> subsequent descriptors with them, and keep the entire size at a >> different location */ >> - size = buf[0]; >> - if (buf[1] == 2) { >> - int realsize = __le16_to_cpu(((unsigned short *) (buf + 2))[0]); >> + size = dd.bLength; >> + if (dd.bDescriptorType == 2) { >> + int realsize = __le16_to_cpu(dd.bcdUSB); >> size = realsize; >> } >> result = malloc (size); ATB, Mark.

1 0

[PATCH 0/7] Build updates and improvements
by Mark Cave-Ayland 24 Apr '24

24 Apr '24

This series is based upon Amadeusz Sławiński's recent series at https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/OLS2… and updates the code to fix build issues on gcc 12 (as used by Debian stable), whilst also correcting the compiler flags so that the binaries are generated correctly. Finally the github workflows are updated to use the Debian cross-compilers, and the GitHub release action changed to use an actively maintained fork. [MCA: switching to the Debian cross-compilers substantially lowers the barrier to entry for people setting up their own compile environments and also brings OpenBIOS in line with QEMU's own CI cross-compiler containers]. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (7): .github/workflows: update to latest action releases arch/ppc/qemu/init.c: work around GCC bug for ppc64_patch_handlers() packages/pc-parts.c: fix bug in extended partition logic drivers/usb.c: rework descriptor read logic in get_descriptor() switch-arch: disable generation of position independent code (-fno-pic) docker: switch from kernel crosstools compilers to Debian cross-compilers .github/workflows: migrate release action to crowbarmaster/GH-Automatic-Releases .github/workflows/build-openbios-builder.yml | 8 ++++---- .github/workflows/main.yml | 8 ++++---- .github/workflows/release.yml | 8 ++++---- arch/ppc/qemu/init.c | 12 ++++++++++++ config/scripts/switch-arch | 10 +++++----- docker/Dockerfile.builder | 18 ++---------------- drivers/usb.c | 17 ++++++++--------- packages/pc-parts.c | 7 +++++-- 8 files changed, 44 insertions(+), 44 deletions(-) -- 2.39.2

2 11

[PATCH 0/7] Fix build issues
by Amadeusz Sławiński 24 Apr '24

24 Apr '24

Set of patches for few problems found when trying to build project. Also enable some additional checks and also fix issues found. Amadeusz Sławiński (7): adb_kbd.c: Fix function key definitions Change malloc to take size_t as argument Label fallthroughs in switch()es Makefile.target: Enable few additional warnings Disable stack protector on all architectures bootstrap: Check result of fread Tell linker that stack is not executable Makefile.target | 2 ++ arch/amd64/lib.c | 2 +- arch/ppc/build.xml | 8 ++++---- arch/ppc/ofmem.c | 2 +- arch/ppc/qemu/ofmem.c | 2 +- arch/sparc32/lib.c | 2 +- arch/sparc64/lib.c | 2 +- arch/x86/lib.c | 2 +- config/scripts/switch-arch | 14 +++++++------- drivers/adb_bus.c | 2 +- drivers/adb_kbd.c | 2 +- include/libc/stdlib.h | 2 +- kernel/bootstrap.c | 6 +++++- libc/vsprintf.c | 1 + 14 files changed, 28 insertions(+), 21 deletions(-) -- 2.43.2

2 9

GRUB causes Unhandled Exception in firmware for sparc64 build
by Glenn Washburn 01 Aug '23

01 Aug '23

Hi all, I've been running into an issue with a GRUB test where it is causing an Unhandled Exception from within the openbios sparc64 firmware. I've created an issue[1] on github mainly to store the reproducing ISO. I'm not sure what the root issue is, but it seems to have something to do with having the firmware open the floppy drive. This happens on a build from master, the latest release build, and an old build packaged with Debian. None of the other GRUB tests trigger this bug. Any ideas what's going on? Glenn [1] https://github.com/openbios/openbios/issues/14

1 0

[PATCH] kernel: Fix compiler format string warnings when some debugging options are enabled
by Glenn Washburn 29 Jul '23

29 Jul '23

Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- This compile-time errors from GCC 10.1.0 when the config options CONFIG_DEBUG_BOOT, CONFIG_DEBUG_DICTIONARY, and CONFIG_DEBUG_INTERPRETER are set to true in the ppc64_config.xml. I suspect these are issues for 32-bit PPC as well, but haven't checked. Glenn --- kernel/bootstrap.c | 8 ++++---- kernel/dict.c | 4 ++-- kernel/forth.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index b7658ab..6834597 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -133,9 +133,9 @@ static void relocation_table(unsigned char * dict_one, unsigned char *dict_two, } #ifdef CONFIG_DEBUG_DICTIONARY - printk("dict1 %lx dict2 %lx dict %lx\n",dict_one, dict_two, dict); + printk("dict1 %p dict2 %p dict %p\n",dict_one, dict_two, dict); for (i=0; i< relocation_length ; i++) - printk("reloc %d %lx\n",i+1, reloc_table[i]); + printk("reloc %d "FMT_ucellx"\n",i+1, reloc_table[i]); #endif relocation_address=reloc_table; } @@ -819,7 +819,7 @@ static int build_dictionary(void) dicthead = 0; #ifdef CONFIG_DEBUG_DICTIONARY - printk("building dictionary, %d primitives.\nbuilt words:", + printk("building dictionary, %lu primitives.\nbuilt words:", sizeof(wordnames) / sizeof(void *)); #endif @@ -1248,7 +1248,7 @@ int main(int argc, char *argv[]) printf("dict1: %p\n",bootstrapdict[0]); printf("dict2: %p\n",bootstrapdict[1]); printf("trampoline: %p\n",trampoline); - printf("size=%d, trampoline_size=%d\n",MEMORY_SIZE + (2 * + printf("size=%ld, trampoline_size=%ld\n",MEMORY_SIZE + (2 * DICTIONARY_SIZE) + TRAMPOLINE_SIZE, TRAMPOLINE_SIZE); #endif diff --git a/kernel/dict.c b/kernel/dict.c index 0986cb1..e449c5b 100644 --- a/kernel/dict.c +++ b/kernel/dict.c @@ -293,8 +293,8 @@ ucell load_dictionary(const char *data, ucell len) reloc_table=(ucell *)(data+dicthead); #ifdef CONFIG_DEBUG_DICTIONARY - printk("\nmoving dictionary (%x bytes) to %x\n", - (ucell)dicthead, (ucell)dict); + printk("\nmoving dictionary (%x bytes) to "FMT_ucellx"\n", + (ucell)dicthead, pointer2cell(dict)); printk("\ndynamic relocation..."); #endif diff --git a/kernel/forth.c b/kernel/forth.c index 61dd70d..ca3fda3 100644 --- a/kernel/forth.c +++ b/kernel/forth.c @@ -111,7 +111,7 @@ static void docol(void) PUSHR(PC); PC = read_ucell(cell2pointer(PC)); - dbg_interp_printk("docol: %s\n", cell2pointer( lfa2nfa(PC - sizeof(cell)) )); + dbg_interp_printk("docol: %s\n", (char *)cell2pointer( lfa2nfa(PC - sizeof(cell)) )); } static void semis(void) @@ -719,7 +719,7 @@ static void docol_dbg(void) debug_xt_item = debug_xt_item->next; } - dbg_interp_printk("docol_dbg: %s\n", cell2pointer(lfa2nfa(PC - sizeof(cell)))); + dbg_interp_printk("docol_dbg: %s\n", (char *)cell2pointer(lfa2nfa(PC - sizeof(cell)))); } static void semis_dbg(void) -- 2.30.2

2 4

[PATCH 0/3] Simplify pci.c by moving some parts to forth
by BALATON Zoltan 11 May '23

11 May '23

This is untested and probably should be marked RFC as it's mainly to show what I was suggesting as an alternative fix for the decode-unit problem discovered by Mark. This could be taken further to adopt the decode-unit and encode-unit words from openfirmware to reduce clutter in pci.c even more which I may attempt if this direction is accepted. My config words patch will also need to be rebased but let this part settle fitst and I can submit the rest as a follow up or a v2 for this series later. Regards, BALATON Zoltan (3): pci: Use forth to add trivial open/close methods pci: Add is-pci-bus word to install some methods from forth pci: Fix calling decode-unit without active-package drivers/pci.c | 78 +++++--------------------------------------------- drivers/pci.fs | 10 +++++++ 2 files changed, 17 insertions(+), 71 deletions(-) -- 2.30.8

3 16

[PATCH] usbhid: Implement get-key-map method
by BALATON Zoltan 07 Mar '23

07 Mar '23

Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +} + static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB -- 2.30.6

2 5

[PATCH v4] drivers/pci: Implement config access words
by BALATON Zoltan 06 Mar '23

06 Mar '23

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- v4: Added call parent word for bridge devices drivers/pci.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..084ebe9 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -424,6 +424,60 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); } +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); +} + static void ob_pci_dma_alloc(int *idx) { @@ -460,6 +514,12 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -476,12 +536,54 @@ ob_pci_bridge_map_in(int *idx) call_parent_method("pci-map-in"); } +static void +ob_pci_bridge_cread8(void) +{ + call_parent_method("config-b@"); +} + +static void +ob_pci_bridge_cwrite8(void) +{ + call_parent_method("config-b!"); +} + +static void +ob_pci_bridge_cread16(void) +{ + call_parent_method("config-w@"); +} + +static void +ob_pci_bridge_cwrite16(void) +{ + call_parent_method("config-w!"); +} + +static void +ob_pci_bridge_cread32(void) +{ + call_parent_method("config-l@"); +} + +static void +ob_pci_bridge_cwrite32(void) +{ + call_parent_method("config-l!"); +} + NODE_METHODS(ob_pci_bridge_node) = { { "open", ob_pci_open }, { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bridge_map_in }, + { "config-b@", ob_pci_bridge_cread8 }, + { "config-b!", ob_pci_bridge_cwrite8 }, + { "config-w@", ob_pci_bridge_cread16 }, + { "config-w!", ob_pci_bridge_cwrite16 }, + { "config-l@", ob_pci_bridge_cread32 }, + { "config-l!", ob_pci_bridge_cwrite32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, -- 2.30.6

2 3

[PATCH v5] drivers/pci: Implement config access words
by BALATON Zoltan 01 Feb '23

01 Feb '23

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- v5: Different approach to add call parent words for bridge v4: Added call parent word for bridge devices drivers/pci.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..1d6d973 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -424,6 +424,60 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); } +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); +} + static void ob_pci_dma_alloc(int *idx) { @@ -460,6 +514,12 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -494,6 +554,14 @@ NODE_METHODS(ob_pci_simple_node) = { { "close", ob_pci_close }, }; +static void pci_config_call_parent_methods(void) +{ + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + feval("\" config-b@\" is-call-parent \" config-b!\" is-call-parent " + "\" config-w@\" is-call-parent \" config-w!\" is-call-parent " + "\" config-l@\" is-call-parent \" config-l!\" is-call-parent "); +} + static void pci_set_bus_range(const pci_config_t *config) { phandle_t dev = find_dev(config->path); @@ -1831,6 +1899,7 @@ static phandle_t ob_configure_pci_device(const char* parent_path, case PCI_BASE_CLASS_BRIDGE: if (subclass != PCI_SUBCLASS_BRIDGE_HOST) { BIND_NODE_METHODS(phandle, ob_pci_bridge_node); + pci_config_call_parent_methods(); } else { BIND_NODE_METHODS(phandle, ob_pci_bus_node); } -- 2.30.6

1 0

[PATCH 0/3] Add parse hex words for compatibility
by BALATON Zoltan 31 Jan '23

31 Jan '23

Hello, Both Apple OF and SLOF has words to parse hex numbers from comma separated strings which is easily implemented using existing parse-ints word. Doing that removes some duplicated implementations and makes it easy to add compatibility words for Mac FCode ROMs. Originally I've also proposed to rename the existing parse-hex to patse-1hex as it does not matter what it's called as parse-hex is not standard. I still think that would be simpler but this series keeps that word and only adds another parse-1hex for ppc/qemu specifically. That patch renaming patse-hex could still be resurrected if needed. Regards, BALATON Zoltan BALATON Zoltan (3): Generalise parse-hex Use parse-nhex arch/ppc/qemu: Add parse hex words for compatibility with Apple OF arch/ppc/qemu/qemu.fs | 8 ++++++++ arch/sparc64/tree.fs | 6 +----- drivers/esp.fs | 6 +----- drivers/sbus.fs | 6 +----- forth/device/package.fs | 29 ----------------------------- forth/lib/string.fs | 36 ++++++++++++++++++++++++++++++++++-- 6 files changed, 45 insertions(+), 46 deletions(-) -- 2.30.6

2 5

[PATCH v3 0/6] Misc fixes for running FCode ROMs
by BALATON Zoltan 28 Jan '23

28 Jan '23

This starts from v3 as it contains the previous ATI ROM patch split up into smaller patches and also contains other changes that were submitted as separate patches to keep them together. After looking at this again I'm not sure about one patch defining register access words as io access which should work for io bars but I'm unsure about memory bars. Does somebody know what these words should do or what they do on other open firmware implementations? Regards, BALATON Zoltan BALATON Zoltan (6): Limit binary dump bytes in .properties output Don't add open/close words to unmanaged devices Define register access words drivers/pci: Implement config access words drivers/pci: Fix map-in and map-out words arch/ppc/qemu: Add parse-1hex word for compatibility with Apple OF arch/ppc/qemu/qemu.fs | 6 +++ drivers/pci.c | 91 ++++++++++++++++++++++++++++++++++------- drivers/pci.fs | 41 +++++++++++++++++++ drivers/vga.fs | 4 +- forth/admin/devices.fs | 7 ++-- forth/device/other.fs | 6 +++ forth/device/pathres.fs | 5 ++- 7 files changed, 140 insertions(+), 20 deletions(-) -- 2.30.4

3 14

get-key-map method for Mac OS (was Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option)
by BALATON Zoltan 27 Jan '23

27 Jan '23

On Fri, 27 Jan 2023, Howard Spoelstra wrote: > On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >> On Fri, 27 Jan 2023, BALATON Zoltan wrote: >>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: >>>> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton(a)eik.bme.hu> >> wrote: >>>>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: >>>>>> Mac OS X >>>>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to >> adb >>>>>> mouse. No recognition as HID device. >>>>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that >> point >>>>> kbd >>>>>> pcap shows normal interrupt operation and recognition as HID device >>>>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that >> point >>>>> kbd >>>>>> pcap shows normal interrupt operation and recognition as HID device >>>>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to >> adb >>>>>> mouse. pcap shows no recognition as HID device. >>>>>> #10.0 in both cases apple system profiler shows 2 usb buses but no >>>>> devices. >>>>> >>>>> These are all the logs I get booting a 10.0 install iso with >>>>> mac99,via=pmu >>>>> >>>>>>> ============================================================= >>>>>>> OpenBIOS 1.1 [May 25 2022 20:04] >>>>>>> Configuration device id QEMU version 1 machine id 1 >>>>>>> CPUs: 1 >>>>>>> Memory: 256M >>>>>>> UUID: 00000000-0000-0000-0000-000000000000 >>>>>>> CPU type PowerPC,G4 >>>>> milliseconds isn't unique. >>>>>>> switching to new context: >>>>>>> call-method slw_update_keymap failed with error ffffffdf >>>>>>> call-method slw_update_keymap failed with error ffffffdf >>>>> usb_ohci_reset pci-ohci >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_set_ctl pci-ohci: new state 0x0 >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_port_detach port #0 >>>>> usb_ohci_port_attach port #0 >>>>> usb_ohci_port_detach port #1 >>>>> usb_ohci_port_attach port #1 >>>>> dbdma_unassigned_flush: use of unassigned channel 0 >>>>> dbdma_unassigned_flush: use of unassigned channel 0 >>>>> usb_ohci_mem_write_bad_offset 0x30 >>>>> usb_ohci_set_ctl pci-ohci: new state 0x80 >>>>> usb_ohci_start pci-ohci: USB Operational >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_set_ctl pci-ohci: new state 0xc0 >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_port_reset port #0 >>>>> >>>>> It's probably OK until it restarts but the seems to be stopped. Anybody >>>>> wants to have a look? Maybe start with finding what the states mean. >>>>> >>>>> >>>> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS >>>> 9.0.4: >>>> >>>> usb_ohci_set_ctl pci-ohci: new state 0x80 >>>> usb_ohci_start pci-ohci: USB Operational >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_port_reset port #0 >>>> usb_ohci_port_reset port #0 >>>> >>>> So both usb mouse and kbd do not work. >>>> >>>> the pcap file for the mouse stalls here: >>>> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response >>> >>> Maybe the driver gets something from the emulated HID device that it >> cannot >>> handle and stops during init? Can you reproduce the same with OS X 10.0 >> and >>> try to correlate the events you see in pcap and trace with the driver >> source >>> or find out how to enable and read the messages in the driver (unless >> these >>> are stripped from the binary in Mac OS X but maybe there's something in >> the >>> guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are >>> implemented in hw/usb/dev-hid.c but this file does not have any debuging >> or >>> traces. You might try to add some printfs for testing. >>> >>>> However, when I use the usb probe tool from the USB DDK, to probe the >> buses >>>> I see the host emit a get descriptor >>>> >>>> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE >>>> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE >>>> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request >>>> etc. and this time the mouse is recognised as HID device, the host >> starts >>>> polling it and mouse and kbd start to work. >>> >>> It could be possible that the driver did not get to this point but once >>> something else get's past that it recognises the device but I have no >> idea >>> how this works and not even sure which OS you had this result with. Is >> this >>> still 9.0.4? That's hard to debug because we don't know what its driver >> is >>> doing. >>> >>> Is there a Darwin, OpenDarwin or whatever was that called during the >> years >>> iso that boots on this machine (also on the real one)? That should be >> fully >>> open source and probably have the same drivers as Mac OS X so >> reproducing >>> with that could give some more info or maybe its driver is more verbose >> about >>> errors and has debugging. So you could try to find an early Darwin >> version >>> that's about the same time as early OS X versions or look at the >> IOHIDFamily >>> and try to find what part of it is running when you see the logs (as >> this >>> driver is quite complex it may not be easy). >> >> The oldest Darwin CD I could find is 6.2 which boots and works so it's not >> old enough for us. >> >> The simplest driver is in the oldest 10.0 version so maybe we should try >> to look at that: >> >> https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6 >> >> and the low level part is in the xnu kernel: >> >> >> https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Familie… >> >> I don't quite know how it works and where it starts running but a large >> part of it looks like it handles key mapping. While booting I see an error >> from OpenBIOS saying: >> >>>> call-method slw_update_keymap failed with error ffffffdf >> >> Could this be related to the problem? What is this error about? This >> PearPC bug has some info on where it may come from: >> >> > This seem to come from here: > https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/… Great. That's now here (also this is the earilest 10.0 version which should be the simplest): https://github.com/apple-oss-distributions/BootX/blob/BootX-34/bootx.tproj/… This seems to want to call get-key-map method on keyboard. Searching for that in OpenBIOS shows we have that implemented in openbios/drivers/adb_kbd.c and arch/ppc/mol/methods.c but not for usb keyboard. I'm moving this thread to the openbios mailing list as it is now more about this issue than my qemu patch. Any idea/suggestion how should we add this method to the usb keyboard in OpenBIOS? I've ported the USB driver back then but I forgot all about it. There are some methods defined in openbios/drivers/usbhid.c so I guess I could copy it from one of the above two implementations but maybe it's a good time to try to share it between these places but I'm not sure what's the best way for that. Regards, BALATON Zoltan

1 1

[PATCH v3] Limit binary dump bytes in .properties output
by BALATON Zoltan 26 Jan '23

26 Jan '23

Some device trees can contain large chunks of binary data that result in .properties output to get lost in the dump of all binary bytes. Put an upper limit of the bytes dumped. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- forth/admin/devices.fs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 38f6ad6..879c271 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -307,15 +307,16 @@ : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " - swap >r 0 + swap >r dup 100 min 0 begin 2dup > while dup r@ + c@ ( len n ch ) 2 0.r space 1+ - repeat - 2drop r> drop 1 + repeat + drop > if ." ..." then + r> drop 1 ; \ this function tries to heuristically determine the data format -- 2.30.4

2 4

CHRP booting.
by Jd Lyons 03 Oct '22

03 Oct '22

I’m trying to figure how Openbios boots CHRP boot scrips like :tbxi, yet SOLF does not. Can anyone point me to the code in Openbios that enables :tbxi/CHRP booting? Also, does anyone know how exactly that works, what was done to Openbios to enable booting the Mac OS? I’d really like to try and get Apple’s BootX to load on Qemu’s pseries machines and as I understand it CHRP booting should work in SLOF, but it just errors out on BootX with "bad executable”, so there must be some magic I need to understand about :tbxi CHRP boot scripts that SLOF needs some sort of patch.

4 7

[PATCH] Rename parse-hex to parse-1hex
by BALATON Zoltan 25 Sep '22

25 Sep '22

This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/amd64/init.fs | 2 +- arch/ia64/init.fs | 2 +- arch/ppc/briq/briq.fs | 2 +- arch/ppc/mol/mol.fs | 2 +- arch/ppc/mol/tree.fs | 2 +- arch/ppc/pearpc/pearpc.fs | 2 +- arch/ppc/qemu/tree.fs | 2 +- arch/sparc64/tree.fs | 4 ++-- arch/unix/tree.fs | 4 ++-- arch/x86/init.fs | 2 +- drivers/esp.fs | 4 ++-- drivers/ide.c | 2 +- drivers/lsi.c | 2 +- drivers/pci.c | 4 ++++ drivers/sbus.fs | 4 ++-- forth/admin/nvram.fs | 4 ++-- forth/device/pathres.fs | 2 +- forth/device/tree.fs | 2 +- forth/lib/string.fs | 2 +- 19 files changed, 27 insertions(+), 23 deletions(-) diff --git a/arch/amd64/init.fs b/arch/amd64/init.fs index fda3acd..0a06383 100644 --- a/arch/amd64/init.fs +++ b/arch/amd64/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; finish-device diff --git a/arch/ia64/init.fs b/arch/ia64/init.fs index 5b65dd1..c7c83f6 100644 --- a/arch/ia64/init.fs +++ b/arch/ia64/init.fs @@ -24,7 +24,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; finish-device diff --git a/arch/ppc/briq/briq.fs b/arch/ppc/briq/briq.fs index 78d7797..c8e0502 100644 --- a/arch/ppc/briq/briq.fs +++ b/arch/ppc/briq/briq.fs @@ -58,7 +58,7 @@ over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/mol/mol.fs b/arch/ppc/mol/mol.fs index 10c99bd..2e1be19 100644 --- a/arch/ppc/mol/mol.fs +++ b/arch/ppc/mol/mol.fs @@ -51,7 +51,7 @@ over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/mol/tree.fs b/arch/ppc/mol/tree.fs index 228163f..434033b 100644 --- a/arch/ppc/mol/tree.fs +++ b/arch/ppc/mol/tree.fs @@ -64,7 +64,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; finish-device diff --git a/arch/ppc/pearpc/pearpc.fs b/arch/ppc/pearpc/pearpc.fs index 0d018b1..8201f17 100644 --- a/arch/ppc/pearpc/pearpc.fs +++ b/arch/ppc/pearpc/pearpc.fs @@ -59,7 +59,7 @@ over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/qemu/tree.fs b/arch/ppc/qemu/tree.fs index 06583ab..dc6f501 100644 --- a/arch/ppc/qemu/tree.fs +++ b/arch/ppc/qemu/tree.fs @@ -64,7 +64,7 @@ new-device ; : decode-unit ( str len -- unit ) - parse-hex + parse-1hex ; finish-device diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index af8948d..a1f2fc0 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -7,8 +7,8 @@ include config.fs : decode-unit-upa ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ; diff --git a/arch/unix/tree.fs b/arch/unix/tree.fs index a7529b0..3326b9b 100644 --- a/arch/unix/tree.fs +++ b/arch/unix/tree.fs @@ -22,7 +22,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; finish-device @@ -95,7 +95,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; \ testnode \ new-device diff --git a/arch/x86/init.fs b/arch/x86/init.fs index eef72e9..220bec0 100644 --- a/arch/x86/init.fs +++ b/arch/x86/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; finish-device diff --git a/drivers/esp.fs b/drivers/esp.fs index 9e37c0a..6f78ee4 100644 --- a/drivers/esp.fs +++ b/drivers/esp.fs @@ -5,8 +5,8 @@ : decode-unit-scsi ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ; diff --git a/drivers/ide.c b/drivers/ide.c index 4cc572c..79ea8dd 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1284,7 +1284,7 @@ NODE_METHODS(ob_ide) = { static void ob_ide_ctrl_decodeunit(int *idx) { - fword("parse-hex"); + fword("parse-1hex"); } static void diff --git a/drivers/lsi.c b/drivers/lsi.c index 51a541c..e5b09b3 100644 --- a/drivers/lsi.c +++ b/drivers/lsi.c @@ -590,7 +590,7 @@ static void ob_lsi_decodeunit(__attribute__((unused)) lsi_private_t **lsi_p) { /* ( str len -- id ) */ - fword("parse-hex"); + fword("parse-1hex"); } static void diff --git a/drivers/pci.c b/drivers/pci.c index 787fa93..1691e6d 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1072,11 +1072,13 @@ int vga_config_cb (const pci_config_t *config) uint32_t rom_size, size, bar; phandle_t ph; #endif + PCI_DPRINTF("%s 0x%x\n", __func__, config->assigned[0]); if (config->assigned[0] != 0x00000000) { setup_video(); #ifdef CONFIG_PPC if (config->assigned[6]) { + PCI_DPRINTF("%s Checking ROM\n", __func__); rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32, config->assigned[6] & ~0x0000000F); rom_size = config->sizes[6]; @@ -1092,10 +1094,12 @@ int vga_config_cb (const pci_config_t *config) p = (const char *)rom; if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') { size = *(uint32_t*)(p + 4); + PCI_DPRINTF("%s Found NDRV, size=%u\n", __func__, size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size); } else if (p[0] == 'J' && p[1] == 'o' && p[2] == 'y' && p[3] == '!') { + PCI_DPRINTF("%s Found PEF, size=%u\n", __func__, rom_size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p, rom_size); } diff --git a/drivers/sbus.fs b/drivers/sbus.fs index b84a3ac..cea2f14 100644 --- a/drivers/sbus.fs +++ b/drivers/sbus.fs @@ -5,8 +5,8 @@ : decode-unit-sbus ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ; diff --git a/forth/admin/nvram.fs b/forth/admin/nvram.fs index 3fbd935..d543a5e 100644 --- a/forth/admin/nvram.fs +++ b/forth/admin/nvram.fs @@ -104,7 +104,7 @@ constant config-info.size : exec-int-conf ( str len -- value ) \ fixme - parse-hex + parse-1hex ; : check-int-conf ( str len -- str len valid? ) true @@ -145,7 +145,7 @@ constant config-info.size 2dup s" false" strcmp 0= if 2drop false exit then 2dup s" TRUE" strcmp 0= if 2drop false exit then 2dup s" FALSE" strcmp 0= if 2drop false exit then - parse-hex 0<> + parse-1hex 0<> ; : check-bool-conf ( name len -- str len valid? ) diff --git a/forth/device/pathres.fs b/forth/device/pathres.fs index a185b95..7976d78 100644 --- a/forth/device/pathres.fs +++ b/forth/device/pathres.fs @@ -179,7 +179,7 @@ constant sinfo.size \ used if package lacks a decode-unit method : def-decode-unit ( str len -- unitaddr ... ) - parse-hex + parse-1hex ; : get-decode-unit-xt ( phandle -- xt ) diff --git a/forth/device/tree.fs b/forth/device/tree.fs index 6a4cb35..34c01e7 100644 --- a/forth/device/tree.fs +++ b/forth/device/tree.fs @@ -15,7 +15,7 @@ new-device 1 encode-int " #address-cells" property : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; : encode-unit ( addr -- str len ) pocket tohexstr ; diff --git a/forth/lib/string.fs b/forth/lib/string.fs index f97db23..55b24fc 100644 --- a/forth/lib/string.fs +++ b/forth/lib/string.fs @@ -122,7 +122,7 @@ \ string to number conversion \ ----------------------------------------------------- -: parse-hex ( str len -- value ) +: parse-1hex ( str len -- value ) base @ hex -rot $number if 0 then swap base ! ; -- 2.30.4

2 10

[PATCH v2] Implement missing words for the ATI FCode ROM ati-vga emulation
by BALATON Zoltan 25 Sep '22

25 Sep '22

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/pci.c | 89 ++++++++++++++++++++++++++++++++++++------- drivers/pci.fs | 41 ++++++++++++++++++++ drivers/vga.fs | 4 +- forth/device/other.fs | 6 +++ 4 files changed, 125 insertions(+), 15 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..787fa93 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -408,20 +408,68 @@ static void ob_pci_unmap(ucell virt, ucell size) { static void ob_pci_bus_map_in(int *idx) { - uint32_t ba; - ucell size; - ucell virt; + fword("pci-map-in"); +} + +static void +ob_pci_bus_map_out(int *idx) +{ + /* Should call pci-map-out but nothing to do in it yet */ + fword("2drop"); +} - PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} - size = POP(); - POP(); - POP(); - ba = POP(); +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} - virt = ob_pci_map(ba, size); +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} - PUSH(virt); +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); } static void @@ -459,7 +507,14 @@ NODE_METHODS(ob_pci_bus_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bus_map_in }, + { "map-in", ob_pci_bus_map_in }, + { "map-out", ob_pci_bus_map_out }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -473,7 +528,14 @@ static void ob_pci_bridge_map_in(int *idx) { /* As per the IEEE-1275 PCI specification, chain up to the parent */ - call_parent_method("pci-map-in"); + call_parent_method("map-in"); +} + +static void +ob_pci_bridge_map_out(int *idx) +{ + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + call_parent_method("map-out"); } NODE_METHODS(ob_pci_bridge_node) = { @@ -481,7 +543,8 @@ NODE_METHODS(ob_pci_bridge_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bridge_map_in }, + { "map-in", ob_pci_bridge_map_in }, + { "map-out", ob_pci_bridge_map_out }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, diff --git a/drivers/pci.fs b/drivers/pci.fs index a7b56e1..327c9c9 100644 --- a/drivers/pci.fs +++ b/drivers/pci.fs @@ -37,4 +37,45 @@ then ; +: pci-map-in ( addr.lo addr.mid addr.hi size -- virt ) + \ Ignore everything but addr.hi and find assigned addr for BAR + drop nip nip + \ Save my-self and set it to same as active package because otherwise + \ decode-phys below seems to be confused. Maybe this should not be needed + my-self swap active-package ihandle>phandle to my-self + " assigned-addresses" active-package get-package-property 0= if + begin + decode-phys ( bar prop prop-len phys.lo phys.mid phys.hi ) + dup 0fffffff and 6 pick 0fffffff and = if + 2drop -rot + decode-int drop decode-int drop 2drop + ( bar addr.lo ) + \ Now translate addr.lo, This may be wrong + \ maybe we should look at parent's ranges instead? + over 18 rshift 3 and 1 = if + " reg" active-package parent get-package-property 0= if + ( bar addr.lo prop prop-len reg.addr reg.size ) + decode-int -rot decode-int 3drop + + + then + then + nip swap to my-self + exit + else + 3drop \ no match, try next + then + \ Drop the size as we don't need it + decode-int drop decode-int drop + dup 0= + until + 3drop + to my-self + -1 \ not found + else + drop + to my-self + -1 \ could not find assigned-addresses + then + ; + [THEN] diff --git a/drivers/vga.fs b/drivers/vga.fs index 53dcff0..f3ffda7 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -146,14 +146,14 @@ defer vbe-iow! : map-fb ( -- ) cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to fb-addr then ; : map-mmio ( -- ) cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to mmio-addr then ; diff --git a/forth/device/other.fs b/forth/device/other.fs index 1bed9b8..0ff34b6 100644 --- a/forth/device/other.fs +++ b/forth/device/other.fs @@ -58,21 +58,27 @@ defer (poke) \ 5.3.7.2 Device-register access : rb@ ( addr -- byte ) + ioc@ ; : rw@ ( waddr -- w ) + iow@ ; : rl@ ( qaddr -- quad ) + iol@ ; : rb! ( byte addr -- ) + ioc! ; : rw! ( w waddr -- ) + iow! ; : rl! ( quad qaddr -- ) + iol! ; : rx@ ( oaddr - o ) -- 2.30.4

2 2

[PATCH] Don't add open/close words to unmanaged devices
by BALATON Zoltan 25 Sep '22

25 Sep '22

Devices that OpenBIOS does not have a driver for may have an FCode driver that would create the open/close methods but this results in duplicate words due to the empty defaults OpenBIOS adds. These empty defaults are added so that open-dev works (which is needed to run an FCode driver) but to avoid this clash change open-dev to check if open method exists before calling it so we can omit the empty defaults and let an FCode driver install them without getting duplicates. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/pci.c | 2 +- forth/device/pathres.fs | 5 ++++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 787fa93..aa8de6b 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1926,7 +1926,7 @@ static phandle_t ob_configure_pci_device(const char* parent_path, } /* if devices haven't supplied open/close words then supply them with simple defaults */ - if (!find_package_method("open", phandle) && !find_package_method("close", phandle)) { + if (pci_dev && !find_package_method("open", phandle) && !find_package_method("close", phandle)) { BIND_NODE_METHODS(phandle, ob_pci_simple_node); } diff --git a/forth/device/pathres.fs b/forth/device/pathres.fs index 7976d78..b2217f1 100644 --- a/forth/device/pathres.fs +++ b/forth/device/pathres.fs @@ -423,7 +423,10 @@ constant sinfo.size dup if r@ link-one then 1 = if dup active-package <> my-self >in.interposed ! - r@ invoke-open + " open" my-self >in.device-node @ find-method if + drop + r@ invoke-open + then r@ handle-interposers then active-package! -- 2.30.4

2 5

[PATCH] Limit binary dump bytes in .properties output
by BALATON Zoltan 15 Sep '22

15 Sep '22

Some device trees can contain large chunks of binary data that result in .properties output to get lost in the dump of all binary bytes. Put an upper limit of the bytes dumped. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- forth/admin/devices.fs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 38f6ad6..b856f28 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -307,7 +307,7 @@ : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " - swap >r 0 + swap >r 100 min 0 begin 2dup > while dup r@ + c@ ( len n ch ) -- 2.30.4

2 4

[PATCH v2] Limit binary dump bytes in .properties output
by BALATON Zoltan 15 Sep '22

15 Sep '22

Some device trees can contain large chunks of binary data that result in .properties output to get lost in the dump of all binary bytes. Put an upper limit of the bytes dumped. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- forth/admin/devices.fs | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 38f6ad6..7397047 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -307,15 +307,17 @@ : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " - swap >r 0 + swap >r dup 100 min dup 0 begin 2dup > while dup r@ + c@ ( len n ch ) 2 0.r space 1+ - repeat - 2drop r> drop 1 + repeat + 2drop + > if ." ..." then + r> drop 1 ; \ this function tries to heuristically determine the data format -- 2.30.4

1 0

[PATCH 0/4] Add GitHub workflows to generate OpenBIOS binaries
by Mark Cave-Ayland 24 Feb '22

24 Feb '22

This is something I've been keen to do for some time which is to generate an OpenBIOS builder image with the required cross-compilers pre-installed, and then implement workflows so that a push to a branch or a versioned release tag will automatically create OpenBIOS binaries. One of the barriers to OpenBIOS development is getting the correct cross compilers installed: not just for the architecture being developed on, but also for all current supported architectures to ensure there are no regressions. Up until now I was unable to find a set of compilers that built working binaries across all architectures, but since Glenn pointed out the existence of the crosstool releases on kernel.org I've done some tests and confirmed that the cross compilers produce working binaries for all of SPARC32, SPARC64 and PPC. This series adds a manual action to create an openbios-builder image that is then integrated into automated workflows for building debug and release OpenBIOS binaries for all supported architectures (amd64, sparc32, sparc64, ppc and x86). The behaviour is currently very simple: - A push to a branch will build OpenBIOS binaries, and if it is the upstream openbios repository, generate a "latest" release - A push to a versioned release tag matching "v*" will build the OpenBIOS binaries and generate a versioned release For an example of how this will look when merged take a look at the release page of my OpenBIOS fork on GitHub at https://github.com/mcayland/openbios/releases. As a bonus once this has been merged and the openbios-builder image is pushed to ghcr.io it is possible to perform a local development build with simply: git clone https://github.com/openbios/openbios.git docker run --rm -it -v "$(pwd)/openbios:/root" ghcr.io/openbios/openbios-builder:master cd /root ./config/scripts/switch-arch sparc32 && make V=1 ... ... exit Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (4): docker: introduce Dockerfile.builder for openbios-builder container .github/workflows: add build-openbios-builder.yml action .github/workflows: add main.yml for building OpenBIOS upon push .github/workflows: add release.yml for generating an OpenBIOS release .github/workflows/build-openbios-builder.yml | 42 ++++++++ .github/workflows/main.yml | 103 +++++++++++++++++++ .github/workflows/release.yml | 101 ++++++++++++++++++ docker/Dockerfile.builder | 19 ++++ 4 files changed, 265 insertions(+) create mode 100644 .github/workflows/build-openbios-builder.yml create mode 100644 .github/workflows/main.yml create mode 100644 .github/workflows/release.yml create mode 100644 docker/Dockerfile.builder -- 2.20.1

2 8

[PATCH] ppc: Do not generate .stabs ELF sections to prevent GDB from choking on them
by Glenn Washburn 23 Feb '22

23 Feb '22

Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2]. Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-) diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name): #define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: -/* some stab codes */ -#define N_FUN 36 - #endif /* arch/powerpc/lib/crtsavres.S continues */ -- 2.30.2

4 12

[PATCH 0/2] openbios: fix up x86 and amd64 builds
by Mark Cave-Ayland 17 Feb '22

17 Feb '22

The recent discussions about which architectures are currently supported has inspired me to revisit my work on adding GitHub workflow actions. Glenn pointed out that there are a couple of errors in the x86/amd64 builds which are fixed by this patchset. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): config/scripts/switch-arch: allow x86_64 prefix for x86 builds arch/unix/unix.c: fix build on x86 architecture with modern gcc compilers arch/unix/unix.c | 2 ++ config/scripts/switch-arch | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.20.1

2 6

[PATCH] ppc: fix ciface_milliseconds using incorrect frequency for delay
by Glenn Washburn 08 Feb '22

08 Feb '22

Instead of using a constant frequency for all CPUs, which have varying frequencies, use the time frequency as returned by the processor. This fixes issues where delays from ciface_milliseconds were not corresponding to elapsed time as given by the real time clock on certain platforms, eg. QEMU's mac99 machine. Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- Mark, if I missed something in the commit message, feel free to make edits as you see fit. Glenn --- arch/ppc/qemu/methods.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/ppc/qemu/methods.c b/arch/ppc/qemu/methods.c index 930b47c..a423b9f 100644 --- a/arch/ppc/qemu/methods.c +++ b/arch/ppc/qemu/methods.c @@ -126,7 +126,8 @@ ciface_quiesce( unsigned long args[], unsigned long ret[] ) } /* ( -- ms ) */ -#define TIMER_FREQUENCY 16600000ULL +/* From drivers/timer.c */ +extern unsigned long timer_freq; static void ciface_milliseconds( unsigned long args[], unsigned long ret[] ) @@ -146,7 +147,7 @@ ciface_milliseconds( unsigned long args[], unsigned long ret[] ) : "cc"); ticks = (((unsigned long long)tbu) << 32) | (unsigned long long)tbl; - msecs = (1000 * ticks) / TIMER_FREQUENCY; + msecs = (1000 * ticks) / timer_freq; PUSH( msecs ); } -- 2.30.2

3 8

Possible bug in PMU RTC
by Glenn Washburn 31 Jan '22

31 Jan '22

Resending this because I didn't realize I needed to be subscribed to the list to send emails to it. Sorry for any duplicates. --- Hi list, I've noticed what I think is a bug in the PPC OpenBIOS, but it could be in QEMU. First off, are github issues[1] an acceptable way of interacting with OpenBIOS developers? I have another potential bug to report with an attachment and github seems like a better place for the attachment than the mailing list. Also, I'm not subscribed, so a friendly reminder to do reply-all when responding. I'm running the GRUB functional test suite for PPC on QEMU using the machine type mac99,via=pmu and noticed the sleep test fails. The sleep test, one of the first several tests that gets run, uses the RTC to get the current time, waits 10 seconds and gets the time again. The output from GRUB shows that the "get-time" firmware command is returning times before and after the 10 second sleep that differ by 2 seconds. The sleep is implemented in GRUB using the firmware "milliseconds" method. It calls the method in a loop until the last call minus the first call is greater or equal to the number of milliseconds given (10000 in this case). It does seem that by my watch 10 seconds do not go by, so I suspect this is an issue with the clock speed being faster than OpenBIOS thinks it is. Could this be an issue with using two different time sources one from QEMU's RTC and the other using emulated CPU frequency? I've testing with QEMU 5.2 and 6.1 on debian stable with the same results. This can be reproduced by downloading the attached XZ compressed iso, uncompressing and invoking QEMU like this: $ qemu-system-ppc -m 2047M -nographic -monitor file:/dev/null -fw_cfg name=etc/sercon-port,string=0 -serial null -serial stdio -hda grub.iso -boot c I also noticed that the firmware outputs a message "milliseconds isn't unique." Is it just a coincidence that this mentions milliseconds and that is also the name of the firmware method that seems to be at issue here? $ qemu-system-ppc -M mac99,via=pmu -display none -serial stdio s>> et_property: NULL phandle >> ============================================================= >> OpenBIOS 1.1 [Apr 16 2021 09:43] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Glenn [1] https://github.com/openbios/openbios

3 7

[PATCH] ppc: Add TLB miss exception handlers for the 603 core
by Christophe Leroy 28 Jan '22

28 Jan '22

Unlike the 604 core, the 603 doesn't perform table search in HW. When a TLB Miss occurs, the 603 generates one of three specific TLB Miss exception: - Instruction TLB Miss - Data read TLB Miss - Data store TLB Miss The associated exception handlers have to search the match page table entry and load it in a TLB entry. This patch implements the exemple provided in the reference manual (with a couple of errors corrected). Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Fabiano Rosas <farosas(a)linux.ibm.com> Cc: Cédric Le Goater <clg(a)kaod.org> Cc: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/start.S | 158 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 155 insertions(+), 3 deletions(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index c679230..3d4102d 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -25,6 +25,14 @@ #define ILLEGAL_VECTOR( v ) .org __vectors + v ; vector__##v: bl trap_error ; #define VECTOR( v, dummystr ) .org __vectors + v ; vector__##v +#define SPR_DMISS 976 +#define SPR_DCMP 977 +#define SPR_HASH1 978 +#define SPR_HASH2 979 +#define SPR_IMISS 980 +#define SPR_ICMP 981 +#define SPR_RPA 982 + #ifdef CONFIG_PPC_64BITSUPPORT /* We're trying to use the same code for the ppc32 and ppc64 handlers here. @@ -329,9 +337,153 @@ ILLEGAL_VECTOR( 0xd00 ) ILLEGAL_VECTOR( 0xe00 ) ILLEGAL_VECTOR( 0xf00 ) ILLEGAL_VECTOR( 0xf20 ) -ILLEGAL_VECTOR( 0x1000 ) -ILLEGAL_VECTOR( 0x1100 ) -ILLEGAL_VECTOR( 0x1200 ) + +VECTOR( 0x1000, "IFTLB" ): + mfspr r2, SPR_HASH1 + li r1, 8 + mfctr r0 + mfspr r3, SPR_ICMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 2f + lwz r1, 4(r2) + andi. r3, r1, 8 + bne 3f + mtctr r0 + mfspr r0, SPR_IMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + ori r1, r1, 0x100 + srwi r1, r1, 8 + tlbli r0 + stb r1, 6(r2) + rfi +2: + andi. r1, r3, 0x0040 + bne 4f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b +3: + mfsrr1 r3 + andi. r2,r3,0xffff + addis r2, r2, 0x0800 + b 5f +4: + mfsrr1 r3 + andi. r2,r3,0xffff + addis r2, r2, 0x4000 +5: mtctr r0 + mtsrr1 r2 + mfmsr r0 + xoris r0, r0, 0x02 + mtcrf 0x80, r3 + mtmsr r0 + b real_isi + +VECTOR( 0x1100, "DLTLB" ): + mfspr r2, SPR_HASH1 + addi r1, 0, 8 + mfctr r0 + mfspr r3, SPR_DCMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 2f + lwz r1, +4(r2) + mtctr r0 + mfspr r0, SPR_DMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + ori r1, r1, 0x100 + srw r1, r1, 8 + tlbld r0 + stb r1, +6(r2) + rfi +2: + andi. r1, r3, 0x0040 + bne 7f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b + +VECTOR( 0x1200, "DSTLB" ): + mfspr r2, SPR_HASH1 + addi r1, 0, 8 + mfctr r0 + mfspr r3, SPR_DCMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 3f + lwz r1, +4(r2) + andi. r3,r1,0x80 + beq 4f +2: mtctr r0 + mfspr r0, SPR_DMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + tlbld r0 + rfi +3: + andi. r1, r3, 0x0040 + bne 7f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b +4: + rlwinm. r3,r1,30,0,1 + bge- 5f + andi. r3,r1,1 + beq+ 6f + b 8f +5: mfsrr1 r3 + andis. r3,r3,0x0008 + beq 6f + b 8f +6: ori r1, r1, 0x180 + sth r1, 6(r2) + b 2b +7: + mfsrr1 r3 + rlwinm r1, r3, 9,6,6 + addis r1, r1, 0x4000 + b 9f +8: + mfsrr1 r3 + rlwinm r1, r3, 9,6,6 + addis r1, r1, 0x0800 +9: mtctr r0 + andi. r2, r3, 0xffff + mtsrr1 r2 + mtdsisr r1 + mfspr r1, SPR_DMISS + rlwinm. r2,r2,0,31,31 + beq 10f + xor r1,r1,0x07 +10: mtdar r1 + mfmsr r0 + xoris r0, r0, 0x02 + mtcrf 0x80, r3 + mtmsr r0 + b real_dsi + ILLEGAL_VECTOR( 0x1300 ) ILLEGAL_VECTOR( 0x1400 ) ILLEGAL_VECTOR( 0x1500 ) -- 2.33.1

3 6

Issues compiling qemu-ppc64
by Glenn Washburn 28 Jan '22

28 Jan '22

Hi list, I've gotten the qemu-ppc target to build correctly, however, I'm having issues with the qemu-ppc64 target. I'm using the 10.1.0 GCC ppc64 compiler distributed at kernel.org[1]. I'm doing the following: $ PATH=/home/user/cross/gcc-10.1.0-nolibc/powerpc64-linux/bin:$PATH $ ./config/scripts/switch-arch qemu-ppc64 $ make V=1 The make is fine until the forthstrap command, which has this output: ./forthstrap -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/lib/ -I/home/user/openbios.git/forth/device/ -I/home/user/openbios.git/forth/debugging/ -I/home/user/openbios.git/forth/admin/ -I/home/user/openbios.git/forth/util/ -I/home/user/openbios.git/forth/packages/ -I/home/user/openbios.git/forth/system/ -I/home/user/openbios.git/libopenbios/ -I/home/user/openbios.git/packages/ -I/home/user/openbios.git/drivers/ -I/home/user/openbios.git/arch/ppc/ -I/home/user/openbios.git -I./forth -D bootstrap.dict -M bootstrap.dict.d -c bootstrap.dict-console.log forth/bootstrap/start.fs panic: segmentation violation at 0xa6dbc62c dict=0x7fa7a6dbc010 here=0x7fa7a6dbc638(dict+0x628) pc=0x0(dict+0x59243ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file Is anyone else seeing this? Can someone with forth experience help here? Glenn [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.1.0…

4 12

Link error when building amd64
by Glenn Washburn 27 Jan '22

27 Jan '22

Is amd64 is another non-working/unused build target? Here's the link error. ar cru liblibc.a target/libc/ctype.o target/libc/diskio.o target/libc/extra.o target/libc/misc.o target/libc/string.o target/libc/vsprintf.o; ranlib liblibc.a ar: `u' modifier ignored since `D' is the default (see `U') gcc -fno-builtin -O0 -g -DNATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH -USWAP_ENDIANNESS -Wall -Wredundant-decls -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels -Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes -Wnested-externs -Werror -MMD -MP -MT openbios-unix -MF '/.d' -rdynamic -o openbios-unix target/arch/unix/unix.o target/arch/unix/boot.o target/arch/unix/blk.o libbootstrap.a libpackages.a libopenbios.a libdrivers.a libfs.a liblibc.a /usr/bin/ld: liblibc.a(misc.o):/home/g10/openbios.git/libc/misc.c:20: multiple definition of `errno_int'; target/arch/unix/unix.o:/home/g10/openbios.git/arch/unix/unix.c:71: first defined here Indeed errno_int is declared in both those locations. It would be easy enough for me to fix for amd64 Linux, but I can't test that it would work on OS X (per the comment in ./arch/unix/unix.c). Glenn

2 1

[PATCH] cuda: fix get-time word
by Glenn Washburn 27 Jan '22

27 Jan '22

An extra byte is written after the CUDA_GET_TIME command causing the command to return an incorrect time. Running QEMU with CUDA debug messages on yields these messages: 1177318@1642469573.070752:cuda_packet_receive length 3 1177318@1642469573.070768:cuda_packet_receive_data [0] 0x01 1177318@1642469573.070771:cuda_packet_receive_data [1] 0x03 1177318@1642469573.070773:cuda_packet_receive_data [2] 0xfb 1177318@1642469573.070776:cuda_receive_packet_cmd handling command GET_TIME CUDA: GET_TIME: wrong parameters 2 Fix the outgoing command length to remove the extra byte. Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- drivers/cuda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cuda.c b/drivers/cuda.c index c89b174..86d2ddb 100644 --- a/drivers/cuda.c +++ b/drivers/cuda.c @@ -234,7 +234,7 @@ static inline int is_leap(int year) static void rtc_get_time(int *idx) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; ucell second, minute, hour, day, month, year; uint32_t now; int current; -- 2.30.2

2 4

Forth interpreter?
by Jd Lyons 24 Jan '22

24 Jan '22

Does OB support a forth interpreter? When I try and load one with the boot command it seems to treat it as a :tbxi and I just get the no valid init file. \ comment cr hex 00000000 encode-int " fcode-rom-offset" property " scsi" encode-string " device-type" property " UltraTek133" encode-string " name" property " UltraTek133" encode-string " compatible" property " 3.5.0" encode-bytes " Rom#" property " 3.5.0" encode-string " rom-revision" property " UltraTek133" encode-string " release" property " PDC20269" encode-string " model" property " UltraTek Firmware by FirmTek LLC, 2001. You may not alter or reverse engineer this product" \ encode-bytes " Copyright" property " Authors: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " authors" property " Szerzoek: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " Szerzoek" \ property " 10/23/02" encode-string " release-date" property " 12:33.03" encode-string " release-time" property 0000AD69 encode-int " subsystem-id" property " SLOT-5" encode-string " AAPL,slot-name” property The \ comment should trigger the forth interpreter, but that doesn’t seem to work with OpenBios. Also, how does Openbios handle Fcode ROM’s that use compression? The FCode probably has some compression and therefore loads itself in two different steps. The first step is something like this: Code: hex tokenizer[ 0000 ]tokenizer set-rev-level tokenizer[ 004A ]tokenizer pci-architecture tokenizer[ 002A ]tokenizer pci-data-structure-start tokenizer[ 0020 ]tokenizer pci-data-structure-length tokenizer[ 105A 4D69 018085 ]tokenizer pci-header tokenizer[ 10000 ]tokenizer rom-size fcode-version2 \ format: 0x08 \ checksum: 0x72c0 (ok) \ len: 0xfd1a (64794 bytes) hex headerless variable variable_800 \ (800) … variable variable_816 \ (816) : colon_l! \ (817) : colon_l@ \ (818) : colon_variable_805_l@ \ (819) : colon_variable_804_l@ \ (81a) : colon_definition_function_81b \ (81b) … : colon_definition_function_822 \ (822) : colon_variable_80a_l! \ (823) : colon_definition_function_824 \ (824) … : colon_definition_function_83f \ (83f) " "(…)" \ 252 bytes encode-bytes " "(…)" \ 252 bytes encode-bytes encode+ … " "(…)" \ < 252 bytes encode-bytes encode+ " driver,FirmTek,MacOS,PowerPC" property colon_definition_function_83f \ (83f) colon_definition_function_824 \ (824) ['] c@ byte-load fcode-end pci-end " driver,FirmTek,MacOS,PowerPC" is a property that's ≈ 61K bytes. Some stuff is done with this (colon_definition_function_83f), then it calls byte-load on the result which means there's more FCode in the result. colon_definition_function_83f is like this: Code: : colon_definition_function_83f \ (83f) " driver,FirmTek,MacOS,PowerPC" colon_definition_function_83e \ (83e) 0= if \ (0x5) 2drop exit then get-package-property if \ (0x4) exit then drop dup colon_l@ \ (818) dup 0 <> if \ (0x56) colon_variable_80a_l! \ (823) 4 + colon_variable_809_l! \ (821) " create driver-buffer" evaluate colon_variable_80a_l@ \ (822) allot " driver-buffer" evaluate colon_variable_80b_l! \ (825) colon_variable_80b_l@ \ (824) 0 <> if \ (0xb) colon_variable_80b_l@ \ (824) colon_variable_80a_l@ \ (822) erase colon_definition_function_83d \ (83d) then else \ (0x5) 2drop then " driver,FirmTek,MacOS,PowerPC" delete-property ; colon_definition_function_83d is maybe the decompression function. I have a PC Promise ATA 133 card that by all looks is identical to the one used by Sonnet Tech in the Tempo ATA 133 line, however there exists no tool for flashing the Mac Fcode ROM to the card sans the Sonnet Flashing tool that won’t recognize a PC Card. I tried using PCI-Passthough to Qemu-System-PPC to load the Fcode ROM from a file in OpenBios, but the compressed part of the ROM doesn’t seem to work correct in OpenBios. load hd:,\ppc\fwata3.bin “ /pci/@e” open-dev to my-self 400004a 1 byte-load

3 2

openbios wrongly considers e300 core as a 64 bits CPU
by Christophe Leroy 20 Jan '22

20 Jan '22

Hello, I have encountered a problem with Openbios while trying to run it under QEMU for a e300 CPU. openbios replaces rfi by rfid on e300 processors, leading to program check exception. Following function seems wrong, the pvr for CPUs with e300 core are inside the range static int is_ppc64(void) { #ifdef __powerpc64__ return 1; #elif defined(CONFIG_PPC_64BITSUPPORT) unsigned int pvr = mfpvr(); return ((pvr >= 0x330000) && (pvr < 0x70330000)); #else return 0; #endif } $ qemu-system-ppc -cpu help | grep -e mpc83 -e e300 PowerPC mpc8343 PVR 00830010 PowerPC mpc8349a PVR 00830010 PowerPC mpc8347at PVR 00830010 PowerPC mpc8347a (alias for mpc8347at) PowerPC e300c1 PVR 00830010 PowerPC mpc8343ea PVR 00830010 PowerPC mpc8349e PVR 00830010 PowerPC mpc8347ep PVR 00830010 PowerPC mpc8347p PVR 00830010 PowerPC mpc8347eap PVR 00830010 PowerPC mpc8349 PVR 00830010 PowerPC mpc8347et PVR 00830010 PowerPC mpc8347e (alias for mpc8347et) PowerPC mpc8347t PVR 00830010 PowerPC mpc8347 (alias for mpc8347t) PowerPC mpc8343a PVR 00830010 PowerPC mpc8347eat PVR 00830010 PowerPC mpc8347ea (alias for mpc8347eat) PowerPC mpc8347ap PVR 00830010 PowerPC mpc8349ea PVR 00830010 PowerPC mpc8343e PVR 00830010 PowerPC e300c2 PVR 00840010 PowerPC e300c3 PVR 00850010 PowerPC e300 (alias for e300c3) PowerPC mpc8379e PVR 00860010 PowerPC e300c4 PVR 00860010 PowerPC mpc8377e PVR 00860010 PowerPC mpc8377 PVR 00860010 PowerPC mpc8378 PVR 00860010 PowerPC mpc8379 PVR 00860010 PowerPC mpc8378e PVR 00860010 Christophe

1 0

[PATCH RESEND] ppc: Add PVRs for the MPC7450 family
by Fabiano Rosas 15 Jan '22

15 Jan '22

This allows the processors from the 7450 family to pass the initial PVR verification. Enables 7441, 7445, 7447, 7447a, 7450, 7451, 7455, 7457 and 7457a. This should be used along with a QEMU that includes commit 1da666cd8e ("target/ppc: Disable software TLB for the 7450 family"). With Linux 5.15: $ cd buildroot $ make qemu_ppc_mac99_defconfig $ make $ qemu-system-ppc -m 1G -M mac99,via=pmu -cpu 7450 \ -kernel ./output/images/vmlinux \ -append root=/dev/sda \ -drive file=./output/images/rootfs.ext2,format=raw \ -net nic,model=sungem -net user -serial mon:stdio -nographic >> ============================================================= >> OpenBIOS 1.1 [Jan 10 2022 13:27] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1024M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 (...) Booting Linux via __start() @ 0x01000000 ... (...) Welcome to Buildroot buildroot login: Signed-off-by: Fabiano Rosas <farosas(a)linux.ibm.com> --- arch/ppc/qemu/init.c | 52 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..e40385a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -569,6 +569,58 @@ static const struct cpudef ppc_defs[] = { .tlb_size = 0x80, .initfn = cpu_g4_init, }, + { + .iu_version = 0x80000000, + .name = "PowerPC,G4", + .icache_size = 0x8000, + .dcache_size = 0x8000, + .icache_sets = 0x80, + .dcache_sets = 0x80, + .icache_block_size = 0x20, + .dcache_block_size = 0x20, + .tlb_sets = 0x40, + .tlb_size = 0x80, + .initfn = cpu_g4_init, + }, + { + .iu_version = 0x80010000, + .name = "PowerPC,G4", + .icache_size = 0x8000, + .dcache_size = 0x8000, + .icache_sets = 0x80, + .dcache_sets = 0x80, + .icache_block_size = 0x20, + .dcache_block_size = 0x20, + .tlb_sets = 0x40, + .tlb_size = 0x80, + .initfn = cpu_g4_init, + }, + { + .iu_version = 0x80020000, + .name = "PowerPC,G4", + .icache_size = 0x8000, + .dcache_size = 0x8000, + .icache_sets = 0x80, + .dcache_sets = 0x80, + .icache_block_size = 0x20, + .dcache_block_size = 0x20, + .tlb_sets = 0x40, + .tlb_size = 0x80, + .initfn = cpu_g4_init, + }, + { + .iu_version = 0x80030000, + .name = "PowerPC,G4", + .icache_size = 0x8000, + .dcache_size = 0x8000, + .icache_sets = 0x80, + .dcache_sets = 0x80, + .icache_block_size = 0x20, + .dcache_block_size = 0x20, + .tlb_sets = 0x40, + .tlb_size = 0x80, + .initfn = cpu_g4_init, + }, { .iu_version = 0x00390000, .name = "PowerPC,970", -- 2.33.1

2 1

[PATCH] drivers: Spell QEMU all caps
by Philippe Mathieu-Daudé 15 Jan '22

15 Jan '22

Replace Qemu -> QEMU. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci_database.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci_database.c b/drivers/pci_database.c index 14ebd29..edcc0fd 100644 --- a/drivers/pci_database.c +++ b/drivers/pci_database.c @@ -247,7 +247,7 @@ static const pci_dev_t vga_devices[] = { }, { PCI_VENDOR_ID_QEMU, PCI_DEVICE_ID_QEMU_VGA, - NULL, "QEMU,VGA", "Qemu VGA", "VGA\0", + NULL, "QEMU,VGA", "QEMU VGA", "VGA\0", 0, 0, 0, NULL, NULL, }, -- 2.31.1

2 1

[PATCH] drivers/usb: Fix building with gcc 10.x
by BALATON Zoltan 15 Jan '22

15 Jan '22

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/usbohci.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/usbohci.c b/drivers/usbohci.c index 774164b..c2c0f78 100644 --- a/drivers/usbohci.c +++ b/drivers/usbohci.c @@ -232,12 +232,12 @@ ohci_init (void *bar) usb_debug("HCCA addr %p\n", OHCI_INST(controller)->hcca); /* Initialize interrupt table. */ - u32 *const intr_table = OHCI_INST(controller)->hcca->HccaInterruptTable; + ohci_t *const ohci = OHCI_INST(controller); ed_t *const periodic_ed; ofmem_posix_memalign((void **)&periodic_ed, sizeof(ed_t), sizeof(ed_t)); memset((void *)periodic_ed, 0, sizeof(*periodic_ed)); for (i = 0; i < 32; ++i) - intr_table[i] = __cpu_to_le32(virt_to_phys(periodic_ed)); + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(periodic_ed)); OHCI_INST (controller)->periodic_ed = periodic_ed; OHCI_INST (controller)->opreg->HcHCCA = __cpu_to_le32(virt_to_phys(OHCI_INST(controller)->hcca)); @@ -607,7 +607,7 @@ struct _intrq_td { u8 *data; struct _intrq_td *next; struct _intr_queue *intrq; -}; +} __attribute__ ((packed)); struct _intr_queue { volatile ed_t ed; @@ -698,14 +698,13 @@ ohci_create_intr_queue(endpoint_t *const ep, const int reqsize, /* Insert ED into periodic table. */ int nothing_placed = 1; ohci_t *const ohci = OHCI_INST(ep->dev->controller); - u32 *const intr_table = ohci->hcca->HccaInterruptTable; const u32 dummy_ptr = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); for (i = 0; i < 32; i += reqtiming) { /* Advance to the next free position. */ - while ((i < 32) && (intr_table[i] != dummy_ptr)) ++i; + while ((i < 32) && (ohci->hcca->HccaInterruptTable[i] != dummy_ptr)) ++i; if (i < 32) { usb_debug("Placed endpoint %lx to %d\n", virt_to_phys(&intrq->ed), i); - intr_table[i] = __cpu_to_le32(virt_to_phys(&intrq->ed)); + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(&intrq->ed)); nothing_placed = 0; } } @@ -729,10 +728,9 @@ ohci_destroy_intr_queue(endpoint_t *const ep, void *const q_) /* Remove interrupt queue from periodic table. */ ohci_t *const ohci = OHCI_INST(ep->dev->controller); - u32 *const intr_table = ohci->hcca->HccaInterruptTable; for (i=0; i < 32; ++i) { - if (intr_table[i] == __cpu_to_le32(virt_to_phys(intrq))) - intr_table[i] = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); + if (ohci->hcca->HccaInterruptTable[i] == __cpu_to_le32(virt_to_phys(intrq))) + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); } /* Wait for frame to finish. */ mdelay(1); -- 2.30.2

3 10

Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family
by Fabiano Rosas 08 Jan '22

08 Jan '22

Fabiano Rosas <farosas(a)linux.ibm.com> writes: > Hi all, > > We have this bug in QEMU which indicates that we haven't been able to > run openbios on a 7450 cpu for quite a long time: > > https://gitlab.com/qemu-project/qemu/-/issues/86 > > OK: > $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7410 > > >> ============================================================= > >> OpenBIOS 1.1 [Nov 1 2021 20:36] > ... > > NOK: > $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7450 -d int > Raise exception at fff08cc4 => 0000004e (00) > QEMU: Terminated > > The actual issue is straightforward. There is a non-architected > feature that QEMU has enabled by default that openbios doesn't know > about. From the user manual: > > "The MPC7540 has a set of implementation-specific registers, > exceptions, and instructions that facilitate very efficient software > searching of the page tables in memory for when software table > searching is enabled (HID0[STEN] = 1). This section describes those > resources and provides three example code sequences that can be used > in a MPC7540 system for an efficient search of the translation tables > in software. These three code sequences can be used as handlers for > the three exceptions requiring access to the PTEs in the page tables > in memory in this case-instruction TLB miss, data TLB miss on load, > and data TLB miss on store exceptions." > > The current state: > > 1) QEMU does not check HID0[STEN] and makes the feature always enabled > by setting these cpus with the POWERPC_MMU_SOFT_74xx MMU model, > instead of the generic POWERPC_MMU_32B. > > 2) openbios does not recognize the PVRs for those cpus and also does > not have any handlers for the software TLB exceptions (vectors 0x1000, > 0x1100, 0x1200). > > Some assumptions (correct me if I'm wrong please): > > - openbios is the only firmware we use for the following cpus: 7441, > 7445, 7450, 7451, 7455, 7457, 7447, 7447a, 7448. > - without openbios, we cannot have a guest running on these cpus. > > So to bring 7450 back to life we would need to either: > > a) find another firmware/guest OS code that supports the feature; > > b) implement the switching of the feature in QEMU and have the guest > code enable it only when supported. That would take some fiddling with > the MMU code to: merge POWERPC_MMU_SOFT_74xx into POWERPC_MMU_32B, > check the HID0[STEN] bit, figure out how to switch from HW TLB miss to > SW TLB miss on demand, block access to the TLBMISS register (and > others) when the feature is off, and so on; > > c) leave the feature enabled in QEMU and implement the software TLB > miss handlers in openbios. The UM provides sample code, so this is > easy; > > d) remove support for software TLB search for the 7450 family and > switch the cpus to the POWERPC_MMU_32B model. This is by far the > easiest solution, but could cause problems for any (which?) guest OS > code that actually uses the feature. All of the existing code for the > POWERPC_MMU_SOFT_74xx MMU model would probably be removed since it > would be dead code then; > > Option (c) seemed to me like a good compromise so this is a patch > series for openbios doing that and also adding the necessary PVRs so > we can get a working guest with these cpus without too much effort. > > I have also a patch for QEMU adding basic sanity check tests for the > 7400 and 7450 families. I'll send that separately to the QEMU ml. > > Fabiano Rosas (2): > ppc: Add support for MPC7450 software TLB miss interrupts > ppc: Add PVRs for the MPC7450 family > > arch/ppc/qemu/init.c | 52 ++++++++++ > arch/ppc/qemu/start.S | 236 +++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 285 insertions(+), 3 deletions(-) (Adding Mark because his email got somehow dropped from the original message) So with these patches in OpenBIOS we could get a bit further and call into the Linux kernel using the same image as the one used for the 7400. However there seems to be no support for the 7450 software TLB in the kernel. There are only handlers for the 4xx, 8xx and 603 which are different code altogether. There's no mention of the TLBMISS and PTEHI/LO registers in the code as well. Do we know of any guest OS that implements the 7450 software TLB at vectors 0x1000, 0x1100 and 0x1200? Otherwise replacing the POWERPC_MMU_SOFT_74xx model with POWERPC_MMU_32B might be the only way of getting an OS to run in the 7450 family.

5 23

[RFC PATCH v2 0/4] QEMU/openbios: PPC Software TLB support in the G4 family
by Fabiano Rosas 15 Dec '21

15 Dec '21

Hi all, Recap: - QEMU enables 7450 SW TLB search by default; - OpenBIOS does not know about SW TLB (vectors 0x1000, 0x1100, 0x1200); - OpenBIOS does not know about 7450s PVRs. Proposed solutions: a) find another firmware/guest OS code that supports the feature; b) implement the switching of the feature in QEMU and have the guest code enable it only when supported. That would take some fiddling with the MMU code to: merge POWERPC_MMU_SOFT_74xx into POWERPC_MMU_32B, check the HID0[STEN] bit, figure out how to switch from HW TLB miss to SW TLB miss on demand, block access to the TLBMISS register (and others) when the feature is off, and so on; c) leave the feature enabled in QEMU and implement the software TLB miss handlers in openbios. The UM provides sample code, so this is easy; d) remove support for software TLB search for the 7450 family and switch the cpus to the POWERPC_MMU_32B model. This is by far the easiest solution, but could cause problems for any (which?) guest OS code that actually uses the feature. All of the existing code for the POWERPC_MMU_SOFT_74xx MMU model would probably be removed since it would be dead code then; v1: https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00289.html v2: This series corresponds to option d) above. - patch 1 moves all of the 7450 CPUs* into the POWERPC_MMU_32B MMU model, which does the same as the POWERPC_MMU_SOFT_74xx minus the software TLB handling. It also removes the instructions (tlbld, tlbli) and SPRs (TLBMISS, PTEHI, PTELO) from the 7450s as these facilities are only used along with the software TLB. *- except for 7448, which is seen by QEMU as a 7400. - patch 2 removes the instructions and SPRs just like above, but from the e600 CPU. The e600 already uses the POWERPC_MMU_32B MMU model, so it already has software TLB disabled. - patch 3 removes all of the now dead code for the 74xx software TLB. I left a note in the code with keywords to help with grep in case people search for the feature in the future. - patch 4 adds smoke tests for all of the 74xx CPUs. These are broken pending the OpenBIOS patch. For OpenBIOS: We'd need to merge the patch 2/2 from the previous series: https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00290.html Message ID: 20211119134431.406753-3-farosas(a)linux.ibm.com this is just for the new PVRs. There is no need to add the handlers. Thanks! Fabiano Rosas (4): target/ppc: Disable software TLB for the 7450 family target/ppc: Disable unused facilities in the e600 CPU target/ppc: Remove the software TLB model of 7450 CPUs tests/avocado: ppc: Add smoke tests for MPC7400 and MPC7450 families target/ppc/cpu-qom.h | 6 +- target/ppc/cpu.h | 4 +- target/ppc/cpu_init.c | 57 ++++-------------- target/ppc/excp_helper.c | 29 --------- target/ppc/helper.h | 2 - target/ppc/mmu_common.c | 19 ------ target/ppc/mmu_helper.c | 31 ---------- target/ppc/translate.c | 26 -------- tests/avocado/ppc_74xx.py | 123 ++++++++++++++++++++++++++++++++++++++ 9 files changed, 140 insertions(+), 157 deletions(-) create mode 100644 tests/avocado/ppc_74xx.py -- 2.33.1

2 9

[PATCH v8] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree
by BALATON Zoltan 20 Nov '21

20 Nov '21

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there. As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more. Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 55 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..b1c2197 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,59 @@ static void kvm_of_init(void) fword("finish-device"); } +static void encode_int_plus(int n, ...) +{ + int i; + ucell v; + va_list ap; + + va_start(ap, n); + for (i = 0; i < n; i++) { + v = va_arg(ap, ucell); + PUSH(v); + fword("encode-int"); + if (i > 0) { + fword("encode+"); + } + } + va_end(ap); +} + +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + fword("new-device"); + push_str("pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + encode_int_plus(2, 0xf0000000, 0x02000000); + 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"); + encode_int_plus(12, + 0x01000000, 0, 0, 0xf0000000, 0, 0x00800000, + 0x02000000, 0, 0x90000000, 0x90000000, 0, 0x10000000); + push_str("ranges"); + fword("property"); + encode_int_plus(2, 0, 0); + push_str("bus-range"); + fword("property"); + fword("finish-device"); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -868,6 +921,8 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); break; -- 2.21.4

3 24

[PATCH v9] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree
by BALATON Zoltan 06 Nov '21

06 Nov '21

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there. As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more. Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 113 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..2bee848 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,116 @@ static void kvm_of_init(void) fword("finish-device"); } +static void encode_int_plus(int n, ...) +{ + int i; + ucell v; + va_list ap; + + va_start(ap, n); + for (i = 0; i < n; i++) { + v = va_arg(ap, ucell); + PUSH(v); + fword("encode-int"); + if (i > 0) { + fword("encode+"); + } + } + va_end(ap); +} + +static void empty_pci_bus_init(void) +{ + if (machine_id != ARCH_MAC99) { + return; + } + fword("new-device"); + push_str("pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + push_str("AAPL,UniNorth"); + fword("encode-string"); + push_str("model"); + fword("property"); + push_str("uni-north"); + fword("encode-string"); + push_str("compatible"); + fword("property"); + encode_int_plus(2, 0xf0000000, 0x02000000); + 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(66666666); + fword("encode-int"); + push_str("clock-frequency"); + fword("property"); + PUSH(0x800); + fword("encode-int"); + push_str("UNI-N"); + fword("encode-string"); + fword("encode+"); + push_str("built-in-names"); + fword("property"); + PUSH(0x10000); + fword("encode-int"); + push_str("SLOT-A"); + fword("encode-string"); + fword("encode+"); + push_str("slot-names"); + fword("property"); + encode_int_plus(18, + 0x02000000, 0, 0xf1000000, 0xf1000000, 0, 0x01000000, + 0x01000000, 0, 0, 0xf0000000, 0, 0x00800000, + 0x02000000, 0, 0x90000000, 0x90000000, 0, 0x10000000); + push_str("ranges"); + fword("property"); + encode_int_plus(2, 0, 0); + push_str("bus-range"); + fword("property"); + fword("finish-device"); +} + +static void empty_pci_bus_interrupts(void) +{ + phandle_t pic, dnode; + u32 props[8]; + + if (machine_id != ARCH_MAC99) { + return; + } + pic = dt_iterate_type(0, "open-pic"); + dnode = find_dev("/pci@f0000000"); + props[0] = 0x2d; + props[1] = 0x1; + set_property(dnode, "interrupts", (char *)props, 2 * sizeof(u32)); + set_int_property(dnode, "interrupt_patent", pic); + props[0] = 0x8000; + props[1] = 0; + props[2] = 0; + props[3] = 0; + props[4] = pic; + props[5] = 0x30; + props[6] = 0x1; + set_property(dnode, "interrupt-map", (char *)props, 7 * sizeof(u32)); + props[0] = 0xf800; + props[1] = 0; + props[2] = 0; + props[3] = 0; + set_property(dnode, "interrupt-map-mask", (char *)props, 4 * sizeof(u32)); +} + /* * filll ( addr bytes quad -- ) */ @@ -868,8 +978,11 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); + empty_pci_bus_interrupts(); break; default: ob_pci_init(); -- 2.30.2

1 0

Re: Installing OpenBIOS
by bernd1-1＠web.de 06 Nov '21

06 Nov '21

2 2

[PATCH] cuda: fix reset-all and power-off words
by Mark Cave-Ayland 30 Oct '21

30 Oct '21

There is a long-standing bug in the CUDA implementation of the reset-all and power-off words whereby an extra byte is written after the CUDA_RESET_SYSTEM and CUDA_POWERDOWN commands. This extra byte used to be ignored in QEMU until commits 017da0b568 ("cuda: port POWERDOWN command to new framework") and 54e894442e ("cuda: port RESET_SYSTEM command to new framework") added a check which rejects the command if the command length is incorrect. Fix the outgoing command length to remove the extra byte which allows the reset-all and power-off words to work in QEMU once again. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/624 --- drivers/cuda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cuda.c b/drivers/cuda.c index 56d73e1..c89b174 100644 --- a/drivers/cuda.c +++ b/drivers/cuda.c @@ -177,7 +177,7 @@ static cuda_t *main_cuda; static void ppc32_reset_all(void) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; cmdbuf[0] = CUDA_RESET_SYSTEM; cuda_request(main_cuda, CUDA_PACKET, cmdbuf, sizeof(cmdbuf), obuf); @@ -186,7 +186,7 @@ ppc32_reset_all(void) static void ppc32_poweroff(void) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; cmdbuf[0] = CUDA_POWERDOWN; cuda_request(main_cuda, CUDA_PACKET, cmdbuf, sizeof(cmdbuf), obuf); -- 2.20.1

2 2

[PATCH 0/2] escc: reset fixes for sun keyboard/mouse
by Mark Cave-Ayland 30 Oct '21

30 Oct '21

The sun4m machine uses 2 ESCC devices: one for use as normal serial ports and another for use with a Sun keyboard/mouse. The previous ESCC fixes added new code to send the ESCC soft reset sequence for the normal serial ports but failed to do so for the keyboard/mouse serial ports. This worked fine for OpenBIOS and all of my SPARC32 test images except for my OpenBSD test image which hangs on boot: whilst the OS sends the reset sequence to the normal serial port, it tries to access the Sun keyboard/mouse serial ports without sending the reset sequence first causing it to get stuck in a polling loop waiting for the status register bits to be set correctly. This patchset updates the kbd_init() function which initialises the ESCC used by the Sun keyboard/mouse so that it now sends the ESCC soft reset sequence to both ports. This ensures that the status register bits are set to their expected reset defaults which allows OpenBSD SPARC32 to boot successfully once again. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): escc: add speed parameter to kbd_init() for sun keyboard/mouse serial ports escc: initialise sun keyboard/mouse serial ports in kbd_init() arch/sparc32/openbios.c | 2 +- drivers/escc.c | 4 +++- include/drivers/drivers.h | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) -- 2.20.1

1 3

[PATCH] arch/ppc/qemu: Add a dummy device tree node for the first PCI bus
by BALATON Zoltan 24 Oct '21

24 Oct '21

Real PowerMac3,1 has two PCI and one AGP buses that are emulated in QEMU but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). MorphOS is confused by this and erroneously uses the address of the first bus to access PCI config registers for devices on the second bus if the first pci node is missing from the device tree, This results in either not booting at all or devices mapped via MMIO may still appear to work but they may not be correctly initialised and some cards are not detected because of this. However, adding the other /pci node causes problems with other guests such as NetBSD. Fortunately MorphOS is happy as long as any node of pci device-type comes before the actual /pci entry. Until proper support for multiple PCI buses is implemented, add such a dummy node in the device tree for QEMU mac99 to avoid this problem which fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..ef8b27a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -865,6 +865,16 @@ arch_of_init(void) switch (machine_id) { case ARCH_MAC99: + /* This adds a dummy node of pci device-type before the actual /pci + * node which is needed for MorphOS to find devices on PCI bus. + * (Real machine has 3 /pci nodes but we only have one.) */ + fword("new-device"); + push_str("dummy-pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + fword("finish-device"); + /* fall through */ case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); -- 2.21.4

1 0

[PATCH v7] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree
by BALATON Zoltan 23 Oct '21

23 Oct '21

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there. As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more. Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..5e3959e 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,44 @@ static void kvm_of_init(void) fword("finish-device"); } +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + 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"); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -868,6 +906,8 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); break; -- 2.21.4

2 11

Installing OpenBIOS
by bernd1-1＠web.de 23 Oct '21

23 Oct '21

Hi. I've watched a television broadcast where a hacker or security expert suspected that the BIOS of ThinkPads has a backdoor and therefore he installed OpenBIOS. I read https://www.openfirmware.info/OpenBIOS. 1. Please tell me whether a user without knowledge in programming or Linux command lines in Terminal is able to install OpenBIOS. 2. Would you provide step by step instructions (especially for my case) how to install OpenBIOS on my system? Regards,

2 1

[PATCH 0/2] escc: add missing port reset
by Mark Cave-Ayland 08 Sep '21

08 Sep '21

An upcoming change to QEMU's ESCC device reset mechanism exposed a bug that OpenBIOS's ESCC driver doesn't actually reset the port before attempting to configure it. Whilst this has no effect for now, once the QEMU ESCC changes have been merged (which implement the reset as documented in the datasheet), this port reset must be sent so that the registers are set to their default values after power-on. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): escc: add port index to uart_init_line() escc: send software reset command before configuring the port drivers/escc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.20.1

1 3

Move to github workflow?
by Mark Cave-Ayland 19 Aug '21

19 Aug '21

Hi all, Since the coreboot team moved the OpenBIOS project onto Github, there have been a number of steadily increasing pull requests and issues raised there and so I'm wondering if now is the time to start thinking about moving to a more Github-based workflow. The nice thing about Github is that we can start to put together some CI to allow build testing of PRs and open potential review to people outside of the OpenBIOS mailing list. However there are a number of very knowledgeable people on this mailing list who have helped with the project over the years and I am really keen to maintain the benefit of their expertise. On this basis I would like to propose the following changes: 1) Move to a merge request workflow and start accepting PRs from Github 2) Add the openbios(a)openbios.org mailing list automatically to Github PRs and Issues so people on the mailing can take part in the discussions. Note: this is currently VERY low volume. 3) Implement a basic Github workflow using the QEMU project cross-compiler docker images to enable build testing and artifact generation without requiring a cross-compiler to be built manually. (I've already tried a few experiments and made some progress here). Any further thoughts/ideas/suggestions? ATB, Mark.

4 5

[PATCH v3] pci: Rename pci_xbox_blacklisted() as pci_xbox_ignore_device()
by Philippe Mathieu-Daudé 16 Feb '21

16 Feb '21

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_ignore_device(), and remove an obvious comment. Suggested-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..0e12dc7 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1356,7 +1356,7 @@ static void ob_pci_add_properties(phandle_t phandle, } #ifdef CONFIG_XBOX -static char pci_xbox_blacklisted (int bus, int devnum, int fn) +static char pci_xbox_ignore_device (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1387,9 +1387,6 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) if (bus >= 2) return 1; - /* - * The device is not blacklisted. - */ return 0; } #endif @@ -1708,7 +1705,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, pci_addr addr; #ifdef CONFIG_XBOX - if (pci_xbox_blacklisted (bus, devnum, fn)) + if (pci_xbox_ignore_device (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

3 8

[PATCH v2] pci: Rename pci_xbox_blacklisted() as pci_xbox_skip_device()
by Philippe Mathieu-Daudé 11 Feb '21

11 Feb '21

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_skip_device(), and remove an obvious comment. Suggested-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..461e0fe 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1356,7 +1356,7 @@ static void ob_pci_add_properties(phandle_t phandle, } #ifdef CONFIG_XBOX -static char pci_xbox_blacklisted (int bus, int devnum, int fn) +static char pci_xbox_skip_device (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1387,9 +1387,6 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) if (bus >= 2) return 1; - /* - * The device is not blacklisted. - */ return 0; } #endif @@ -1708,7 +1705,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, pci_addr addr; #ifdef CONFIG_XBOX - if (pci_xbox_blacklisted (bus, devnum, fn)) + if (pci_xbox_skip_device (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

2 2

[PATCH] pci: Rename pci_xbox_blacklisted() as pci_xbox_denylisted()
by Philippe Mathieu-Daudé 07 Feb '21

07 Feb '21

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_denylisted(). Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..19b9027 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1356,7 +1356,7 @@ static void ob_pci_add_properties(phandle_t phandle, } #ifdef CONFIG_XBOX -static char pci_xbox_blacklisted (int bus, int devnum, int fn) +static char pci_xbox_denylisted (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1388,7 +1388,7 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) return 1; /* - * The device is not blacklisted. + * The device is not denylisted. */ return 0; } @@ -1708,7 +1708,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, pci_addr addr; #ifdef CONFIG_XBOX - if (pci_xbox_blacklisted (bus, devnum, fn)) + if (pci_xbox_denylisted (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

3 2

[PATCH 0/3] 40p: Match QEMU Raven IRQ swizzling change
by Philippe Mathieu-Daudé 07 Feb '21

07 Feb '21

As requested by Mark on qemu-devel list, update OpenBIOS to be consistent with QEMU change: https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03079.html Philippe Mathieu-Daudé (3): 40p: Allow Raven controller to handle all IRQs 40p: use is_apple() macro 40p: simplify IRQ swizzling drivers/pci.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) -- 2.26.2

3 6

[PATCH] PPC: mark first 4 pages of physical and virtual memory as unavailable
by Mark Cave-Ayland 25 Jul '20

25 Jul '20

The Debian ports images have now switched from using yaboot to grub as their bootloader. Recent versions of these images will hang rather than boot under QEMU despite there being no obvious changes to the boot process. Further investigation reveals that the second stage grub bootloader appears to use low memory whilst loading the kernel/initrd from disk: unfortunately the OpenBIOS vector table lives within the first few pages of physical RAM and so grub writes over the vector table (in particular overwriting the MMU fault handlers) causing them to fail next time they are executed which causes the hang. Fortunately just before this stage of the bootloader executes, it uses the CIF to request the contents of the /memory node "available" property. It seems that the low memory locations used by grub are taken from the start of the available range, so we can simply increase the number of RAM pages reserved at the bottom of RAM to ensure that the area chosen by the bootloader doesn't conflict with the vector table. This patch raises the start of available memory from 0x1000 to 0x4000 which allows grub to boot successfully in my tests. According to dumps of device trees taken from real PPC Macs there are already several examples where the start of available memory is set to 0x3000 or 0x4000, so as this is already present on real hardware it should not cause any regressions. Finally it is worth noting that even in the earlier grub images I could see write accesses to low memory that would overwrite the vector table: I think that until recently we were lucky that they happened to avoid anything that was critical to allow the kernel to load and boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/ofmem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 7a78a1e..4ff0803 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -571,9 +571,9 @@ ofmem_init(void) { ofmem_t *ofmem = ofmem_arch_get_private(); - /* Mark the first page as non-free */ - ofmem_claim_phys(0, PAGE_SIZE, 0); - ofmem_claim_virt(0, PAGE_SIZE, 0); + /* Mark the first 4 pages as non-free */ + ofmem_claim_phys(0, 4 * PAGE_SIZE, 0); + ofmem_claim_virt(0, 4 * PAGE_SIZE, 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); -- 2.20.1

1 0

[PATCH] SPARC: add implementation of addr word
by Mark Cave-Ayland 07 Jul '20

07 Jul '20

OpenBSD uses the addr word to retrieve the address of several framebuffer variables during initialisation. Provide an implementation of addr which allows OpenBSD to initialise the framebuffer correctly on SPARC32 and SPARC64. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- forth/util/util.fs | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/forth/util/util.fs b/forth/util/util.fs index 8247c7d..54dbf91 100644 --- a/forth/util/util.fs +++ b/forth/util/util.fs @@ -102,3 +102,18 @@ 2dup " tell" is-relay 2drop ; + +\ ------------------------------------------------------------------------- +\ Miscellaneous +\ ------------------------------------------------------------------------- + +[IFDEF] CONFIG_SPARC32 1 [ELSE] [IFDEF] CONFIG_SPARC64 1 [ELSE] 0 [THEN] [THEN] [IF] + +\ Return the address of a named constant or value +: addr ( <word> -- addr ) + parse-word $find if + cell + + then +; + +[THEN] -- 2.20.1

3 5

[PATCH] virtio: limit ring size to a maximum of 128 descriptor entries
by Mark Cave-Ayland 21 May '20

21 May '20

QEMU commit c9b7d9ec21 "virtio: increase virtqueue size for virtio-scsi and virtio-blk" increased the number of queue descriptors from 128 to 256 which caused OpenBIOS to fail when booting from a virtio-blk device under qemu-system-ppc due to a memory overflow. Update the virtio-blk driver so that it uses a maximum of 128 descriptor entries (the previous value) to fix the issue, and also ensure that any further increases in virtqueue size will not cause the same failure. Note that this commit also fixes the vring_area size calculation which was incorrectly based upon the number of virtqueues, and not the number of descriptor entries. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/virtio.c | 7 ++++++- drivers/virtio.h | 5 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/virtio.c b/drivers/virtio.c index ff7ed6f..7808d94 100644 --- a/drivers/virtio.c +++ b/drivers/virtio.c @@ -303,7 +303,12 @@ ob_virtio_configure_device(VDev *vdev) }; virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SELECT, i); + info.num = virtio_cfg_read16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE); + if (info.num > VIRTIO_MAX_RING_ENTRIES) { + info.num = VIRTIO_MAX_RING_ENTRIES; + virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE, info.num); + } vring_init(&vdev->vrings[i], &info); @@ -503,7 +508,7 @@ void ob_virtio_init(const char *path, const char *dev_name, uint64_t common_cfg, addr = POP(); vdev->vrings = cell2pointer(addr); - PUSH(VIRTIO_RING_SIZE * VIRTIO_MAX_VQS); + PUSH((VIRTIO_RING_SIZE * 2 + VIRTIO_PCI_VRING_ALIGN) * VIRTIO_MAX_VQS); feval("dma-alloc"); addr = POP(); vdev->ring_area = cell2pointer(addr); diff --git a/drivers/virtio.h b/drivers/virtio.h index 64b49e7..36cb205 100644 --- a/drivers/virtio.h +++ b/drivers/virtio.h @@ -147,8 +147,9 @@ struct VirtioDev { }; typedef struct VirtioDev VirtioDev; -#define VIRTIO_RING_SIZE (PAGE_SIZE * 8) -#define VIRTIO_MAX_VQS 3 +#define VIRTIO_MAX_RING_ENTRIES 128 +#define VIRTIO_RING_SIZE (sizeof(VRingDesc) * VIRTIO_MAX_RING_ENTRIES) +#define VIRTIO_MAX_VQS 1 #define KVM_S390_VIRTIO_RING_ALIGN 4096 #define VRING_USED_F_NO_NOTIFY 1 -- 2.20.1

1 1

[PATCH] pci: Enable bus-master on virtio_blk
by bdragon＠FreeBSD.org 16 May '20

16 May '20

From: Brandon Bergren <git(a)bdragon.rtk0.net> In qemu 9d7bd0826f2d19f88631ad7078662668148f7b5f, the behavior of vring processing was changed to not run whenever bus-mastering is disabled. Since we were never enabling it in the first place, OpenBIOS was no longer able to access virtio disks on qemu. Fix this by enabling bus-mastering before initializing. Signed-off-by: Brandon Bergren <git(a)bdragon.rtk0.net> --- drivers/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index 9d501d3..34ae69a 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -816,6 +816,9 @@ int virtio_blk_config_cb(const pci_config_t *config) return 0; } + /* Enable bus mastering to ensure vring processing will run. */ + ob_pci_enable_bus_master(config); + ob_virtio_init(config->path, "virtio-blk", common_cfg, device_cfg, notify_base, notify_mult, idx); #endif -- 2.25.1

2 1

[PATCH v2 0/2] SPARC64/SPARC32 fix kernel and initrd mapping
by Mark Cave-Ayland 04 May '20

04 May '20

Unfortunately it looks as if my original fix for this was wrong, and in particular causes one of the SPARC64 QEMU advent calendar images which uses a preloaded kernel to panic on boot. The SILO memory allocators search through the physical memory "available" property but then don't actually allocate the result: instead hardcoded virtual addresses are only mapped to the physical addresses that are determined to be free. These patches remove the physical and virtual allocations introduced as part of the original fix and map these memory areas in exactly the same way that SILO does. This also solves the issue the original patches were trying to fix, which was that clients could still claim the memory in-use by the kernel via the CIF - the virtual addresses used by SILO are higher up in memory, making a clash extremely unlikely (and indeed, if it did happen, would mean the kernel/initrd combination would also fail to boot under SILO). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Fix typo and cut/paste error patch 2 Mark Cave-Ayland (2): SPARC64: fix kernel and initrd mapping to match SILO SPARC32: fix kernel and initrd mapping to match SILO arch/sparc32/boot.h | 3 +++ arch/sparc32/openbios.c | 31 ++++++++++++++++--------------- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 3 +++ arch/sparc64/openbios.c | 16 +++++++--------- 5 files changed, 30 insertions(+), 25 deletions(-) -- 2.20.1

1 3

[PATCH 0/2] SPARC64/SPARC32 fix kernel and initrd mapping
by Mark Cave-Ayland 26 Apr '20

26 Apr '20

Unfortunately it looks as if my original fix for this was wrong, and in particular causes one of the SPARC64 QEMU advent calendar images which uses a preloaded kernel to panic on boot. The SILO memory allocators search through the physical memory "available" property but then don't actually allocate the result: instead hardcoded virtual addresses are only mapped to the physical addresses that are determined to be free. These patches remove the physical and virtual allocations introduced as part of the original fix and map these memory areas in exactly the same way that SILO does. This also solves the issue the original patches were trying to fix, which was that clients could still claim the memory in-use by the kernel via the CIF - the virtual addresses used by SILO are higher up in memory, making a clash extremely unlikely (and indeed, if it did happen, would mean the kernel/initrd combination would also fail to boot under SILO). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): SPARC64: fix kernel and initrd mapping to match SILO SPARC32: fix kernel and initrd mapping to match SILO arch/sparc32/boot.h | 3 +++ arch/sparc32/openbios.c | 31 ++++++++++++++++--------------- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 3 +++ arch/sparc64/openbios.c | 16 +++++++--------- 5 files changed, 30 insertions(+), 25 deletions(-) -- 2.20.1

1 2

[PATCH v2] Add davbus and sound nodes
by John Arbuckle 29 Dec '19

29 Dec '19

Adds the davbus and sound nodes like this: mac-io/davbus/sound This enables audio playback for a Mac OS 9 and a Mac OS X guest. To test sound playback go to the sound node: cd mac-io/davbus/sound Then type: test-sound This will play some tones. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> --- v2 changes: - Added sound test feature. config/examples/ppc_config.xml | 1 + drivers/build.xml | 1 + drivers/macio.c | 2 + drivers/pci.c | 4 + drivers/screamer.c | 636 +++++++++++++++++++++++++++++++++++++++++ drivers/screamer.h | 11 + 6 files changed, 655 insertions(+) create mode 100755 drivers/screamer.c create mode 100644 drivers/screamer.h diff --git a/config/examples/ppc_config.xml b/config/examples/ppc_config.xml index 19dc043..908d497 100644 --- a/config/examples/ppc_config.xml +++ b/config/examples/ppc_config.xml @@ -84,5 +84,6 @@ <option name="CONFIG_DRIVER_USB" type="boolean" value="true"/> <option name="CONFIG_DEBUG_USB" type="boolean" value="false"/> <option name="CONFIG_USB_HID" type="boolean" value="true"/> + <option name="CONFIG_DRIVER_SCREAMER" type="boolean" value="true"/> <option name="CONFIG_DRIVER_LSI_53C810" type="boolean" value="true"/> <option name="CONFIG_DRIVER_VIRTIO_BLK" type="boolean" value="true"/> diff --git a/drivers/build.xml b/drivers/build.xml index 5a28bc2..575ac6a 100644 --- a/drivers/build.xml +++ b/drivers/build.xml @@ -22,6 +22,7 @@ <object source="pc_kbd.c" condition="DRIVER_PC_KBD"/> <object source="pc_serial.c" condition="DRIVER_PC_SERIAL"/> <object source="escc.c" condition="DRIVER_ESCC"/> + <object source="screamer.c" condition="DRIVER_SCREAMER"/> <object source="fw_cfg.c" condition="DRIVER_FW_CFG"/> <object source="usb.c" condition="DRIVER_USB"/> <object source="usbhid.c" condition="USB_HID"/> diff --git a/drivers/macio.c b/drivers/macio.c index 496bab1..0f95705 100644 --- a/drivers/macio.c +++ b/drivers/macio.c @@ -21,6 +21,7 @@ #include "pmu.h" #include "escc.h" #include "drivers/pci.h" +#include "screamer.h" #define OW_IO_NVRAM_SIZE 0x00020000 #define OW_IO_NVRAM_OFFSET 0x00060000 @@ -391,6 +392,7 @@ ob_macio_keylargo_init(const char *path, phys_addr_t addr) escc_init(path, addr); macio_ide_init(path, addr, 2); openpic_init(path, addr); + screamer_init(addr); aliases = find_dev("/aliases"); set_property(aliases, "mac-io", path, strlen(path) + 1); diff --git a/drivers/pci.c b/drivers/pci.c index 9d501d3..b607fa5 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1978,6 +1978,10 @@ static phandle_t ob_pci_host_set_interrupt_map(phandle_t host) target_node = find_dev(path); set_int_property(target_node, "interrupt-parent", dnode); + snprintf(buf, sizeof(buf), "%s/mac-io/davbus", path); + target_node = find_dev(buf); + set_int_property(target_node, "interrupt-parent", dnode); + return dnode; } diff --git a/drivers/screamer.c b/drivers/screamer.c new file mode 100755 index 0000000..b9fced1 --- /dev/null +++ b/drivers/screamer.c @@ -0,0 +1,636 @@ +// File: screamer.c +// Description: Implements the davbus and sound nodes for sound support. + +#include "screamer.h" +#include "asm/types.h" +#include "kernel/stack.h" +#include "libopenbios/bindings.h" +#include <stddef.h> +#include <stdbool.h> +#include "libc/vsprintf.h" +#include "libc/stdlib.h" +#include "timer.h" +#include "libopenbios/ofmem.h" + +uint32_t screamer_base_address = 0; +uint32_t dma_base_address = 0; +uint32_t chip_freq = 8820; +int *sample_array = NULL; +int buffer_size = 0; +int append_index = 0; +int packet_size = 8000; + +#define DEAD 0x0800 +#define RUN 0x8000 + +#define DEBUG 0 +#define debug_print(fmt, ...) do { \ +if (DEBUG) { \ + printk(fmt, ## __VA_ARGS__); \ +} \ +} while (0) + +/* Prints to the console */ +static int print(const char *fmt, ...) +{ + va_list args; + int i; + char buf[100]; + va_start(args, fmt); + i=vsprintf(buf,fmt,args); + va_end(args); + push_str(buf); + fword("type"); + return i; +} + + +/* Makes the screen blank and places the cursor in the upper left corner */ +static void clear_screen(void) +{ + int i; + + // clears the screen + for (i = 0; i < 100; i++) { + print("\n"); + } + + // makes cursor go back to the top left corner + for (i = 0; i < 100; i++) { + print("%c", 11); + } +} + + +/* Centers and prints a message on the screen */ +static void print_center(const char *message) +{ + int message_length = strlen(message); + int screen_width = 96; + int padding = (screen_width - message_length) / 2; + if (padding < 0) { + padding = 0; + } + char output_string[81]; + memset(output_string, ' ', padding); + sprintf(output_string + padding, "%s", message); + print(output_string); +} + + +/* Writes a 32 bit value to the specified register in Screamer */ +static void write_screamer(int reg, uint32_t value) +{ + reg = reg << 4; + *(volatile uint32_t *)(screamer_base_address + reg) = value; + asm volatile("eieio" : : : "memory"); +} + + +/* Set sampling rate to 8820 Hz */ +static void set_sampling_rate(void) +{ + write_screamer(0, 0x60000); +} + + +/* Sets the volume to the maximum value */ +static void set_volume(void) +{ + write_screamer(1, 0x400000); +} + + +/* Clears the audio buffer */ +static void clear_buffer(void) +{ + memset(sample_array, 0, buffer_size); + append_index = 0; +} + + +/* Initializes the tone playing system */ +static void initialize(void) +{ + static bool is_initialized = false; + + /* Only need to do this once */ + if (is_initialized) { + return; + } + + /* Allocate memory for audio buffer */ + int i, status, current_size = 2000000; /* Start big and work our way down */ + for (i = 0; i < current_size; i++) { + status = ofmem_posix_memalign((void *)&sample_array, 32, sizeof(int) * + current_size); + if (status == 0) { + break; + } + current_size = current_size / 2; + } + if (!sample_array) { + print("Failed to allocate memory for samples!\n"); + return; + } else { + debug_print("buffer size: %d\n", current_size); + } + set_sampling_rate(); + set_volume(); + is_initialized = true; + buffer_size = current_size; + clear_buffer(); +} + + +/* Converts a big endian 16 bit value to little endian */ +static uint16_t convert2le16(uint16_t value) +{ + uint16_t byte1, byte2; + byte1 = (value & 0xff) << 8u; + byte2 = (value & 0xff00) >> 8u; + value = byte1 | byte2; + return value; +} + +/* Converts a big endian 32 bit value to little endian */ +static uint32_t convert2le32(uint32_t value) +{ + uint32_t byte1, byte2, byte3, byte4; + byte1 = (value & 0xff) << 24u; + byte2 = (value & 0xff00) << 8u; + byte3 = (value & 0xff0000) >> 8u; + byte4 = (value & 0xff000000) >> 24u; + value = byte1 | byte2 | byte3 | byte4; + return value; +} + +/* Read a register's value for channel 16 */ +static uint32_t read_dma(int reg) +{ + int channel = 16; // Screamer's output channel + uint32_t addr, return_value; + addr = channel << 7; // set channel + addr |= (4*reg); // set register + asm volatile("eieio" : : : "memory"); + return_value = *(volatile uint32_t *)(dma_base_address + addr); + return_value = return_value >> 8; + return return_value; +} + +/* Tell the dbdma the value to set for the register for channel 16 */ +static void write_dma(int reg, uint32_t value) +{ + int channel = 16; // Screamer's output channel + uint32_t addr; + addr = channel << 7; // set channel + addr |= (4*reg); // et register + value = convert2le32(value); // DMA controller uses little endian + *(volatile uint32_t *)(dma_base_address + addr) = value; + asm volatile("eieio" : : : "memory"); +} + + +/* Programs the DMA controller to send our samples to Screamer */ +static void send_samples_to_dma(int offset) +{ + typedef struct dbdma_cmd { + uint16_t req_count; /* length of data */ + uint16_t command; /* tells the dma what to do */ + uint32_t phy_addr; /* address of the sample buffer */ + uint32_t cmd_dep; /* command-dependent field - not used */ + uint16_t res_count; /* not used */ + uint16_t xfer_status; /* transfer status - not used */ + } dbdma_cmd; + + int num_of_descriptors; + if (packet_size > append_index) { + num_of_descriptors = 1; + } else { + num_of_descriptors = append_index/packet_size; + } + dbdma_cmd *descriptor_array; + + /* DMA expects 16 bit alignment */ + if (ofmem_posix_memalign((void *)&descriptor_array, 16, sizeof(dbdma_cmd) * + num_of_descriptors)) { + print("Error: failed to allocate memory for dbdma command!\n"); + return; + } + + /* === Initialize the descriptors === */ + int i; + for (i = 0; i < num_of_descriptors; i++) { + + /* Set the length of the data */ + descriptor_array[i].req_count = convert2le16(packet_size); + + if (i == (num_of_descriptors - 1)) { + /* + * Don't branch & OUTPUT_LAST & KEY_STREAM0 & interrupt never & + * wait never + */ + descriptor_array[i].command = convert2le16(0x1000); + } else { + /* + * Don't branch & OUTPUT_MORE & KEY_STREAM0 & interrupt never & + * wait never + */ + descriptor_array[i].command = 0; + } + + /* Set the address of the buffer used to feed Screamer samples */ + descriptor_array[i].phy_addr = convert2le32(sample_array + + (packet_size * i)); + } + /* send the above structure to the DMA for parsing */ + write_dma(3, descriptor_array); + + /* + * Disables branch select feature - makes dma load another descriptor + * automatically using an array of descriptors. The branch() and next() + * functions of the DMA both load the next descriptor. The only difference + * is which variable it is loaded from. The dma's next() function seems + * easier to use because it simply expects an array of descriptors. The + * branch function would want a linked list of descriptors. + */ + write_dma(5, 0); + + /* Set to disable interrupts because we use polling instead */ + write_dma(4, 0); + + /* + * Sets the upper 32 bits of the address to zero since the CPU is only 32 + * bits. + */ + write_dma(2, 0); + + /* Disable flushing so audio plays back correctly */ + write_dma(1, 0); + + /* Calls control write function - starts the whole DMA process */ + write_dma(0, 0x84008400); +} + + +/* Adds samples to a buffer */ +static int append(int value) +{ + if (append_index >= buffer_size) { + print("Can't append to buffer - out of space\n"); + return -1; + } + sample_array[append_index] = value; + append_index++; + return 0; +} + + +/* Creates a sample */ +static int get_sample(bool is_even) +{ + if (is_even) { + return 1; + } else { + return -1; + } +} + + +/* Delays execution by specified milliseconds */ +static void sleep(int milliseconds) +{ + mdelay(milliseconds); +} + + +/* Blocks execution while the dma plays the samples */ +static void play_samples(void) +{ + int i, iterations, offset; + uint32_t status; + + /* Nothing to do */ + if (append_index == 0) { + return; + } + + if (packet_size > append_index) { + iterations = 1; + } else { + iterations = append_index/packet_size; + } + + send_samples_to_dma(0); + for(i = 0; i < iterations; i++) + { + offset = i * packet_size; + status = read_dma(1); + debug_print("dma status: 0x%x\n", status); + while ((status & RUN) && !(status & DEAD)) { + debug_print("Still waiting - dma status: 0x%x\n", status); + sleep(10); + status = read_dma(1); + } + + if (status & DEAD) { + debug_print("dma status is dead\n"); + break; + } + } +} + + +/* + * Plays a note of a specified frequency and duration. + * Returns the number of samples added to the buffer. + * note_freq: in Hertz + * duration: in milliseconds + */ +static void play_note(uint32_t note_freq, int duration) +{ + // makes audio play for the correct duration + duration = duration * 2; + + if (note_freq <= 0 || duration <= 0) { + print("Error: note frequency and duration must be greater than zero\n"); + return; + } + int samples_between_changes = chip_freq/note_freq; + debug_print("chip_freq: %d\tnote_freq: %d\n", chip_freq, note_freq); + debug_print("samples between changes: %d\n", samples_between_changes); + int amplitude = 25000; + int iterations = (chip_freq * duration) / (samples_between_changes * 1000); + debug_print("iterations: %d\n", iterations); + int i, sample; + for (i = 0; i < iterations; i++) { + int s; + for (s = 0; s < samples_between_changes; s++) { + sample = get_sample(i % 2 == 0); + sample = sample * amplitude; + if (append(sample) != 0) { // if buffer is full + debug_print("Sending samples to screamer...\n"); + + /* Try to fix the problem with breaking up audio samples for the DMA */ + append_index = append_index - s; + s = 0; + + play_samples(); + clear_buffer(); + if (append(sample) != 0) { + print("Error: failure to add sample!\n"); + } + } + } + } + play_samples(); + clear_buffer(); +} + + +/* + * Implements the Forth play-note word. + * ( frequency duration(in ms) - ) + */ + static void forth_play_note(void) + { + uint32_t note_freq, duration; + duration = POP(); + note_freq = POP(); + initialize(); + clear_buffer(); + play_note(note_freq, duration); + } + + +/* + * Adds silence to the output. + * Returns the number of samples added to the buffer. + * duration: in milliseconds + */ +static void silence(int duration) +{ + // This make the correct amount of samples + duration = duration * 2; + + int number_of_samples = chip_freq * duration / 1000; + debug_print("silence samples: %d\n", number_of_samples); + int i; + for (i = 0; i < number_of_samples; i++) { + if (append(0) != 0) { + play_samples(); + clear_buffer(); + } + } +} + + +/* + * Implements the Forth silence word. + * ( duration - ) + */ +static void forth_silence(void) +{ + initialize(); + int duration = POP(); + silence(duration); +} + + +/* Creates a little song */ +static void create_samples(void) +{ + int i; + for (i = 0; i < 3; i++) { + play_note(400, 500); + play_note(600, 500); + play_note(800, 500); + play_note(1000, 500); + play_note(1200, 500); + silence(300); + } + + play_note(400, 400); + silence(50); + play_note(400, 400); + silence(50); + play_note(800, 400); + silence(50); + play_note(800, 400); + silence(50); + play_note(900, 400); + silence(50); + play_note(900, 400); + silence(50); + play_note(800, 400); +} + + +/* Lets the user know the sound test is complete */ +static void end_test(void) +{ + clear_screen(); + print_center("Testing Sound"); + print("\n\n"); + print_center("Done\n\n"); + sleep(700); +} + + +/* Tells user testing has begun and creates and plays samples */ +static void play_sound(void) +{ + clear_screen(); + print_center("Testing Sound"); + print("\n\n"); + print_center("Now playing..."); + create_samples(); + play_samples(); +} + + +/* Displays a countdown informing the user testing is about to begin */ +static void display_countdown(void) +{ + clear_screen(); + print_center("Testing Sound"); + print("\n"); + sleep(500); + print_center("3\n"); + sleep(500); + print_center("2\n"); + sleep(500); + print_center("1\n"); + sleep(500); + print_center("0\n"); + sleep(500); +} + + +/* Starts the sound test */ +static void test_sound(void) +{ + initialize(); + display_countdown(); + play_sound(); + end_test(); +} + + +/* Makes sound related functions available in Forth */ +static void add_words(phys_addr_t base_address) +{ + screamer_base_address = base_address + 0x14000; + dma_base_address = 0x80008000; + + bind_func("test-sound", test_sound); + bind_func("play-note", forth_play_note); + bind_func("silence", forth_silence); +} + + +/* Add the sound node for the screamer sound chip */ +static void setup_screamer_node(phys_addr_t base_address) +{ + phandle_t node; + + fword("new-device"); + push_str("sound"); + fword("device-name"); + + push_str("screamer"); + fword("encode-string"); + push_str("awacs"); + fword("encode-string"); + fword("encode+"); + push_str("compatible"); + fword("property"); + + push_str("343S0184"); + fword("encode-string"); + push_str("model"); + fword("property"); + + node = get_cur_dev(); + + set_int_property(node, "#-outputs", 1); + set_int_property(node, "#-detects", 3); + set_int_property(node, "#-features", 3); + set_int_property(node, "object-model-version", 1); + set_int_property(node, "device-id", 5); + + char *value = "init operation 2 param 00000001 param-size 4\0" + "feature index 0 model Proj7PowerControl\0" + "feature index 1 model USBSubwoofer\0" + "feature index 2 model NotifySSprockets\0" + "detect bit-mask 2 bit-match 2 device 2 index 0 model InSenseBitsDetect\0" + "detect bit-mask 4 bit-match 4 device 16 index 1 model InSenseBitsDetect\0" + "detect bit-mask 1 bit-match 0 device 32 index 2 model InSenseBitsDetect\0" + "input icon-id -16526 index 0 name-id -20520 port-connection 2 " + "port-type 0x656D6963 zero-gain 0 model ExternalMic\0" + "input icon-id -16526 index 1 name-id -20528 port-connection 2 " + "port-type 0x73696E6A zero-gain 0 model InputPort\0" + "input icon-id -20184 index 2 name-id -20540 port-connection 3 " + "port-type 0x6d6f646d zero-gain 0 model InputPort\0" + "input index 3 model NoInput\0" + "output device-mask 2 device-match 0 icon-id -16563 index 0 name-id -20525" + " port-connection 2 port-type 0x6973706B model OutputPort\0" + "output device-mask 2 device-match 2 icon-id -16563 index 1 name-id -20524" + " port-connection 1 port-type 0x6864706E model OutputPort\0"; + + set_property(node, "sound-objects", value, 996); + add_words(base_address); + fword("finish-device"); +} + + +/* Add the davbus node */ +static void setup_davbus_node(phys_addr_t base_address) +{ + phandle_t node; + fword("new-device"); + + push_str("davbus"); + fword("device-name"); + + push_str("soundbus"); + fword("encode-string"); + push_str("device_type"); + fword("property"); + + push_str("davbus"); + fword("encode-string"); + push_str("compatible"); + fword("property"); + + node = get_cur_dev(); + int properties[6]; + + /* reg property */ + properties[0] = 0x14000; + properties[1] = 0x1000; + properties[2] = 0x8800; + properties[3] = 0x100; + properties[4] = 0x8900; + properties[5] = 0x100; + set_property(node, "reg", (char *)properties, sizeof(int) * 6); + + /* interrupt property */ + properties[0] = 0x18; + properties[1] = 1; + properties[2] = 9; + properties[3] = 0; + properties[4] = 0xa; + properties[5] = 0; + set_property(node, "interrupts", (char *)properties, sizeof(int) * 6); + + setup_screamer_node(base_address); + + fword("finish-device"); +} + + +void screamer_init(phys_addr_t base_address) +{ + setup_davbus_node(base_address); +} diff --git a/drivers/screamer.h b/drivers/screamer.h new file mode 100644 index 0000000..64d9443 --- /dev/null +++ b/drivers/screamer.h @@ -0,0 +1,11 @@ +// File: screamer.h +// Description: header file for screamer.c + +#ifndef screamer_h +#define screamer_h + +#include "drivers/drivers.h" + +void screamer_init(phys_addr_t base_address); + +#endif /* screamer_h */ -- 2.14.3 (Apple Git-98)

1 0

[PATCH] Add davbus and sound nodes
by John Arbuckle 22 Dec '19

22 Dec '19

Adds the davbus and sound nodes like this: mac-io/davbus/sound This enables audio playback for a Mac OS 9 and a Mac OS X guest. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> --- config/examples/ppc_config.xml | 1 + drivers/build.xml | 1 + drivers/macio.c | 2 + drivers/pci.c | 4 ++ drivers/screamer.c | 112 +++++++++++++++++++++++++++++++++++++++++ drivers/screamer.h | 9 ++++ 6 files changed, 129 insertions(+) create mode 100644 drivers/screamer.c create mode 100644 drivers/screamer.h diff --git a/config/examples/ppc_config.xml b/config/examples/ppc_config.xml index 19dc043..908d497 100644 --- a/config/examples/ppc_config.xml +++ b/config/examples/ppc_config.xml @@ -84,5 +84,6 @@ <option name="CONFIG_DRIVER_USB" type="boolean" value="true"/> <option name="CONFIG_DEBUG_USB" type="boolean" value="false"/> <option name="CONFIG_USB_HID" type="boolean" value="true"/> + <option name="CONFIG_DRIVER_SCREAMER" type="boolean" value="true"/> <option name="CONFIG_DRIVER_LSI_53C810" type="boolean" value="true"/> <option name="CONFIG_DRIVER_VIRTIO_BLK" type="boolean" value="true"/> diff --git a/drivers/build.xml b/drivers/build.xml index 5a28bc2..575ac6a 100644 --- a/drivers/build.xml +++ b/drivers/build.xml @@ -22,6 +22,7 @@ <object source="pc_kbd.c" condition="DRIVER_PC_KBD"/> <object source="pc_serial.c" condition="DRIVER_PC_SERIAL"/> <object source="escc.c" condition="DRIVER_ESCC"/> + <object source="screamer.c" condition="DRIVER_SCREAMER"/> <object source="fw_cfg.c" condition="DRIVER_FW_CFG"/> <object source="usb.c" condition="DRIVER_USB"/> <object source="usbhid.c" condition="USB_HID"/> diff --git a/drivers/macio.c b/drivers/macio.c index 496bab1..15c74ac 100644 --- a/drivers/macio.c +++ b/drivers/macio.c @@ -21,6 +21,7 @@ #include "pmu.h" #include "escc.h" #include "drivers/pci.h" +#include "screamer.h" #define OW_IO_NVRAM_SIZE 0x00020000 #define OW_IO_NVRAM_OFFSET 0x00060000 @@ -391,6 +392,7 @@ ob_macio_keylargo_init(const char *path, phys_addr_t addr) escc_init(path, addr); macio_ide_init(path, addr, 2); openpic_init(path, addr); + screamer_init(); aliases = find_dev("/aliases"); set_property(aliases, "mac-io", path, strlen(path) + 1); diff --git a/drivers/pci.c b/drivers/pci.c index 9d501d3..b607fa5 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1978,6 +1978,10 @@ static phandle_t ob_pci_host_set_interrupt_map(phandle_t host) target_node = find_dev(path); set_int_property(target_node, "interrupt-parent", dnode); + snprintf(buf, sizeof(buf), "%s/mac-io/davbus", path); + target_node = find_dev(buf); + set_int_property(target_node, "interrupt-parent", dnode); + return dnode; } diff --git a/drivers/screamer.c b/drivers/screamer.c new file mode 100644 index 0000000..e494caa --- /dev/null +++ b/drivers/screamer.c @@ -0,0 +1,112 @@ +// File: screamer.c +// Description: Implements the davbus and sound nodes for sound support. + +#include "screamer.h" +#include "asm/types.h" +#include "kernel/stack.h" +#include "libopenbios/bindings.h" + + +/* Add the sound node for the screamer sound chip */ +static void setup_screamer_node() +{ + phandle_t node; + + fword("new-device"); + push_str("sound"); + fword("device-name"); + + push_str("screamer"); + fword("encode-string"); + push_str("awacs"); + fword("encode-string"); + fword("encode+"); + push_str("compatible"); + fword("property"); + + push_str("343S0184"); + fword("encode-string"); + push_str("model"); + fword("property"); + + node = get_cur_dev(); + + set_int_property(node, "#-outputs", 1); + set_int_property(node, "#-detects", 3); + set_int_property(node, "#-features", 3); + set_int_property(node, "object-model-version", 1); + set_int_property(node, "device-id", 5); + + char *value = "init operation 2 param 00000001 param-size 4\0" + "feature index 0 model Proj7PowerControl\0" + "feature index 1 model USBSubwoofer\0" + "feature index 2 model NotifySSprockets\0" + "detect bit-mask 2 bit-match 2 device 2 index 0 model InSenseBitsDetect\0" + "detect bit-mask 4 bit-match 4 device 16 index 1 model InSenseBitsDetect\0" + "detect bit-mask 1 bit-match 0 device 32 index 2 model InSenseBitsDetect\0" + "input icon-id -16526 index 0 name-id -20520 port-connection 2 " + "port-type 0x656D6963 zero-gain 0 model ExternalMic\0" + "input icon-id -16526 index 1 name-id -20528 port-connection 2 " + "port-type 0x73696E6A zero-gain 0 model InputPort\0" + "input icon-id -20184 index 2 name-id -20540 port-connection 3 " + "port-type 0x6d6f646d zero-gain 0 model InputPort\0" + "input index 3 model NoInput\0" + "output device-mask 2 device-match 0 icon-id -16563 index 0 name-id -20525" + " port-connection 2 port-type 0x6973706B model OutputPort\0" + "output device-mask 2 device-match 2 icon-id -16563 index 1 name-id -20524" + " port-connection 1 port-type 0x6864706E model OutputPort\0"; + + set_property(node, "sound-objects", value, 996); + + fword("finish-device"); +} + +/* Add the davbus node */ +static void setup_davbus_node() +{ + phandle_t node; + fword("new-device"); + + push_str("davbus"); + fword("device-name"); + + push_str("soundbus"); + fword("encode-string"); + push_str("device_type"); + fword("property"); + + push_str("davbus"); + fword("encode-string"); + push_str("compatible"); + fword("property"); + + node = get_cur_dev(); + int properties[6]; + + /* reg property */ + properties[0] = 0x14000; + properties[1] = 0x1000; + properties[2] = 0x8800; + properties[3] = 0x100; + properties[4] = 0x8900; + properties[5] = 0x100; + set_property(node, "reg", (char *)properties, sizeof(int) * 6); + + /* interrupt property */ + properties[0] = 0x18; + properties[1] = 1; + properties[2] = 9; + properties[3] = 0; + properties[4] = 0xa; + properties[5] = 0; + set_property(node, "interrupts", (char *)properties, sizeof(int) * 6); + + setup_screamer_node(); + + fword("finish-device"); +} + +void screamer_init() +{ + setup_davbus_node(); +} diff --git a/drivers/screamer.h b/drivers/screamer.h new file mode 100644 index 0000000..76624c0 --- /dev/null +++ b/drivers/screamer.h @@ -0,0 +1,9 @@ +// File: screamer.h +// Description: header file for screamer.c + +#ifndef screamer_h +#define screamer_h + +void screamer_init(); + +#endif /* screamer_h */ -- 2.14.3 (Apple Git-98)

1 0

building openbios sparc64 for qemu
by berrie.schuurhuis＠gmail.com 03 Dec '19

03 Dec '19

As a newbee in this space I got qemu-system-sparc[64] running on a linux machine. Trying to find out how qemu and openbios work together I'm currently looking into building openbios-sparc64. This goes with mixed success as https://www.openfirmware.info/OpenBIOS has nice description on how to build openbios, but there's a missing link as to how to harvest the openbios-sparc64 from this. My build of openbios is done on an Ultra60(Sparc) machine that runs: Linux ultra60 4.19.0-2-sparc64 #1 Debian 4.19.16-1 (2019-01-17) sparc64 GNU/Linux with gcc --version gcc (Debian 8.3.0-2) 8.3.0 It seems like the file openbios/obj-sparc64/openbios-builtin.elf may be the candidate to become openbios-sparc64?? When giving this a try, and moving openbios-builtin.elf to my x86 qemu machine, it crashes spectacularly with: qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state pc: 0000000000004c80 npc: 0000000000004c84 %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %l0-3: 00000000fff001e0 000001ff00000000 000001fff0080000 0000000000000000 %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 5 pil: 0 gl: 2 tbr: 0000000000000000 hpstate: 0000000000000000 htba: 0000000000000000 cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 On x86: Booting qemu with the provided openbios-sparc64 rom works flawless. On the Ultra60: Running ./openbios-unix openbios-sparc64.dict seems to behave as expected: Output device screen not found. Input device keyboard not found. Output device screen not found. Type 'help' for detailed information [unix] Booting default not supported. Trying disk... No valid state has been set by load or init-program 0 > help To get openbios build, I had to make a small change in Makefile.target: #CFLAGS+= -Werror CFLAGS+= -Wno-error To "fix": Building OpenBIOS for sparc64 Building... /usr/bin/xsltproc error: CC target/arch/unix/unix.o CC target/arch/unix/boot.o /sources/openbios/arch/unix/boot.c:101:6: error: redundant redeclaration of 'forth_fw_cfg_read_file' [-Werror=redundant-decls] void forth_fw_cfg_read_file(void); ^~~~~~~~~~~~~~~~~~~~~~ In file included from ./target/include/asm/io.h:8, from /sources/openbios/include/kernel/kernel.h:22, from /sources/openbios/include/libopenbios/bindings.h:21, from /sources/openbios/arch/unix/boot.c:6: /sources/openbios/include/arch/common/fw_cfg.h:104:6: note: previous declaration of 'forth_fw_cfg_read_file' was here void forth_fw_cfg_read_file(void); ^~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Any pointers or suggestions to continue this journey are appreciated.

5 8

Any known BIOS for Fujitsu LifeBook E744?
by fraczakmarek18＠gmail.com 02 Dec '19

02 Dec '19

Hello, I am searching for BIOS for the above mentioned Fujitsu. Best regards, M. Fraczek Scrascom Sp. z o.o. https://scrascom.pl

1 0

cbse schools near marathahalli
by foundationschoolindia＠gmail.com 14 Nov '19

14 Nov '19

Best CBSE Schools in Whitefield & Varthur: The Foundation Schools in Whitefield has created a name for itself through its excellence in education. The school has good connectivity to Varthur, Sarjapur road, Whitefield and Marathalli. https://www.foundationschoolindia.com/

1 0

Wireless Network Technician
by ashaikfe＠gmail.com 06 Nov '19

06 Nov '19

Wireless Network Technicians are responsible for resolving mediation applications and systems. A Network Technician must provide first- and second-tier production support relating to data mediation applications and servers. They must research, identify and resolve support tickets, system alarms, and production issues according to severity. The professional has to implement suitable and appropriate responses quickly and effectively. Read More: https://www.fieldengineer.com/skills/wireless-network-technician

1 0

[PATCH 0/2] ide: remove global channels list
by Mark Cave-Ayland 28 Oct '19

28 Oct '19

Here are another couple of patches which convert the IDE channel and drive pointers into instance variables, allowing the global IDE channels list to be removed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): ide: use instance values to hold C drive and channel structures ide: locate drives by iterating over the device tree during ob_ide_quiesce() drivers/ide.c | 71 +++++++++++++++++---------------------------------- drivers/ide.h | 1 - 2 files changed, 23 insertions(+), 49 deletions(-) -- 2.20.1

1 3

[PATCH] escc: explicitly mark variable containing incoming keyboard character as volatile
by Mark Cave-Ayland 28 Oct '19

28 Oct '19

Otherwise the compiler may not understand that a read from the assigned buffer is comming from memory-mapped IO space and fail to update accordingly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/escc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/escc.c b/drivers/escc.c index 392625e..d9e1990 100644 --- a/drivers/escc.c +++ b/drivers/escc.c @@ -284,7 +284,7 @@ keyboard_dataready(void) unsigned char keyboard_readdata(void) { - unsigned char ch; + volatile unsigned char ch; while (!keyboard_dataready()) { } -- 2.20.1

2 7

[PATCH] Implement missing words for the ATI FCode ROM to test ati-vga emulation
by BALATON Zoltan 26 Oct '19

26 Oct '19

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/pci.c | 51 +++++++++++++++++++++++++++++++++++++-------------- drivers/pci.fs | 41 +++++++++++++++++++++++++++++++++++++++++ drivers/vga.fs | 4 ++-- forth/device/other.fs | 6 ++++++ 4 files changed, 86 insertions(+), 16 deletions(-) This is on top of Mark's previous patches from the openbios mailing list applied to openbios master: 9a32ed9 Implement missing words for the ATI FCode ROM to test ati-vga emulation b90ac41 virtio: use instance value to initialise C instance parameter ac467a3 lsi: use instance value to hold sd_private_t pointer 177684a pc_kbd: use instance value to initialise C instance parameter d5fdb98 pc_serial: remove separate init word 7c20840 pci: call set-args before configuring PCI device nodes f37460e pci: remove explicit setting of my-self from PCI devices b548924 pci: remove explicit find-device from PCI devices b1ca78f x86: set active package and current instance to root device node before probe 6222a47 SPARC64: set active package and current instance to root device node before probe 5cd41e5 ppc: set active package and current instance to root device node before probe e68504f ppc: move New World uninorth and nvram device node creation to the root device 86aa740 nvram: ensure that NVRAM configuration is separate from NVRAM node creation e959bfd libopenbios: remove REGISTER_NAMED_NODE and REGISTER_NAMED_NODE_PHANDLE macros abc4553 pci: remove ob_pci_initialize() and ob_pci_empty_node 0a63c74 pci: convert to use BIND_NODE_METHODS() macro 57ff6ea virtio: convert to use BIND_NODE_METHODS() macro ea3a8eb lsi: convert to use BIND_NODE_METHODS() macro 32ff529 lsi: don't change active package when setting device alias f63f5ee nvram: convert to use BIND_NODE_METHODS() macro 03c53be usbhid: convert to use BIND_NODE_METHODS() macro 365b2c1 pmu: convert to use BIND_NODE_METHODS() macro 60125f5 macio: convert to use BIND_NODE_METHODS() macro 7d23b31 cuda: convert to use BIND_NODE_METHODS() macro 305d629 escc: convert to use BIND_NODE_METHODS() macro 4a0aea1 adb: convert to use BIND_NODE_METHODS() macro 0081f71 ide: convert to use BIND_NODE_METHODS() macro 79a241c floppy: convert to use BIND_NODE_METHODS() macro 01ea2e4 pc_serial: convert to use BIND_NODE_METHODS() macro 9eb09a9 pc_kbd: convert to use BIND_NODE_METHODS() macro 8945ab4 libopenbios: introduce BIND_NODE_METHODS() macro e9491ea admin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses property c79e0ec (origin/master, origin/HEAD) SPARC64: use serial console when QEMU is launched with -vga none admin/devices.fs: Format assigned-addresses property is https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WHL7… and additionally to the above I also have another patch from Mark that I can't find now in the list archives even though I remember I've replyed to it and had a discussion about having 3 or 2 cases if-else statement. diff --git a/drivers/pci.c b/drivers/pci.c index 4bc02c9..eb5f7d3 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -408,20 +408,32 @@ static void ob_pci_unmap(ucell virt, ucell size) { static void ob_pci_bus_map_in(int *idx) { - uint32_t ba; - ucell size; - ucell virt; - - PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); + fword("pci-map-in"); +} - size = POP(); - POP(); - POP(); - ba = POP(); +static void +ob_pci_bus_map_out(int *idx) +{ + /* Should call pci-map-out but nothing to do in it yet */ + fword("2drop"); +} - virt = ob_pci_map(ba, size); +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} - PUSH(virt); +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val & 0xff); } static void @@ -459,7 +471,10 @@ NODE_METHODS(ob_pci_bus_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bus_map_in }, + { "map-in", ob_pci_bus_map_in }, + { "map-out", ob_pci_bus_map_out }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -473,7 +488,14 @@ static void ob_pci_bridge_map_in(int *idx) { /* As per the IEEE-1275 PCI specification, chain up to the parent */ - call_parent_method("pci-map-in"); + call_parent_method("map-in"); +} + +static void +ob_pci_bridge_map_out(int *idx) +{ + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + call_parent_method("map-out"); } NODE_METHODS(ob_pci_bridge_node) = { @@ -481,7 +503,8 @@ NODE_METHODS(ob_pci_bridge_node) = { { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, - { "pci-map-in", ob_pci_bridge_map_in }, + { "map-in", ob_pci_bridge_map_in }, + { "map-out", ob_pci_bridge_map_out }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, diff --git a/drivers/pci.fs b/drivers/pci.fs index a7b56e1..327c9c9 100644 --- a/drivers/pci.fs +++ b/drivers/pci.fs @@ -37,4 +37,45 @@ then ; +: pci-map-in ( addr.lo addr.mid addr.hi size -- virt ) + \ Ignore everything but addr.hi and find assigned addr for BAR + drop nip nip + \ Save my-self and set it to same as active package because otherwise + \ decode-phys below seems to be confused. Maybe this should not be needed + my-self swap active-package ihandle>phandle to my-self + " assigned-addresses" active-package get-package-property 0= if + begin + decode-phys ( bar prop prop-len phys.lo phys.mid phys.hi ) + dup 0fffffff and 6 pick 0fffffff and = if + 2drop -rot + decode-int drop decode-int drop 2drop + ( bar addr.lo ) + \ Now translate addr.lo, This may be wrong + \ maybe we should look at parent's ranges instead? + over 18 rshift 3 and 1 = if + " reg" active-package parent get-package-property 0= if + ( bar addr.lo prop prop-len reg.addr reg.size ) + decode-int -rot decode-int 3drop + + + then + then + nip swap to my-self + exit + else + 3drop \ no match, try next + then + \ Drop the size as we don't need it + decode-int drop decode-int drop + dup 0= + until + 3drop + to my-self + -1 \ not found + else + drop + to my-self + -1 \ could not find assigned-addresses + then + ; + [THEN] diff --git a/drivers/vga.fs b/drivers/vga.fs index 53dcff0..f3ffda7 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -146,14 +146,14 @@ defer vbe-iow! : map-fb ( -- ) cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to fb-addr then ; : map-mmio ( -- ) cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) - " pci-map-in" $call-parent + " map-in" $call-parent to mmio-addr then ; diff --git a/forth/device/other.fs b/forth/device/other.fs index 1bed9b8..0ff34b6 100644 --- a/forth/device/other.fs +++ b/forth/device/other.fs @@ -58,21 +58,27 @@ defer (poke) \ 5.3.7.2 Device-register access : rb@ ( addr -- byte ) + ioc@ ; : rw@ ( waddr -- w ) + iow@ ; : rl@ ( qaddr -- quad ) + iol@ ; : rb! ( byte addr -- ) + ioc! ; : rw! ( w waddr -- ) + iow! ; : rl! ( quad qaddr -- ) + iol! ; : rx@ ( oaddr - o ) -- 2.13.7

2 2

[PATCH] admin/devices.fs: Format assigned-addresses property
by BALATON Zoltan 26 Oct '19

26 Oct '19

To help reading property listing also format assigned-addresses property the same way as reg was already formatted. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- Actually wanted to improve printing of ranges but I could not do that this one is simpler though. forth/admin/devices.fs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 6f9e8ef..38f6ad6 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -417,7 +417,7 @@ \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) - 2over " reg" strcmp 0= if + 2over 2dup " reg" strcmp 0= -rot " assigned-addresses" strcmp 0= or if my-#acells my-#scells 2swap .p-reg 2drop exit then -- 2.13.7

2 4

Experiments with OpenFirmware
by BALATON Zoltan 17 Sep '19

17 Sep '19

Hello, On Tue, 30 Jul 2019, BALATON Zoltan wrote: > 3. Try to get some other OF implementation working like OpenFirmware. Based > on previous work by Atar for the 40p this is possible although to do it > cleanly may be more work and hindered by the need to do it in Forth > completely. But Forth is needed to hack on OpenBIOS as well so once someone > gets over that hurdle it does not matter. I've started looking at this > posibility to find out how much work would this be that's why I was asking > the question. I've compiled Atar's work which is now upstram in Mitch > Bradley's tree and it worked well with 40p and even started with pegasos2 but > of course it did not init the hardware correctly expecting to run on 40p > (haven't tried with mac99 but I expect the same result). So OpenFirmware > already works on PPC and has some QEMU specific drivers what we may need is > porting drivers for mac specific and pegasos2 devices from OpenBIOS from C to > Forth (or get equivalents from somewhere else) and think about how to pass > the initial device tree similar to SLOF to avoid having to implement each > board in OpenFirmware separately (although doing hardcoded board > implementation like Atar's 40p might be a quick and dirty way to get it > working with much less work). I gave it a try playing with it for a few hours (without really knowing what am I doing) just to get to know it better and see what's needed. So I started by stripping down Atar's QEMU PReP port removing PReP specific parts and just leaving a bare minimum to work on PowerPC and I actually managed to build a ROM image that works with my pegasos2 emulation and gets me an OF environment over diag serial port now: $ qemu-system-ppc -M pegasos2 -bios ofw.rom -serial stdio setup_mem_windows: Should enable region 14 Mapping pci1-io-win 0x0+0x2000000 @ 0xfe000000 setup_mem_windows: Should enable region 20 Type 'i' to interrupt stand-init sequence First stand-init: Calibrate CIF buffers DHCP init memory node Instruction cache on Decrementer Enable machine check exceptions Set Memory Map MMU Root node Data cache on Fast CPU mode PCI host bridge CPU nodes Keyboard overrides Memory node not found. not found. /pci/isa/serial@i2f8 not found. /pci/isa/serial@i2f8 not found. not found. not found. , Serial #0, 128 MiB memory installed Open Firmware Copyright (c) 1995-2000, FirmWorks. Copyright (c) 2014,2017,2019 Artyom Tarasenko. Type any key to interrupt automatic startup 6 5 4 3 2 1 Boot device: net Arguments: Can't open boot device ok show-devs /dropin-fs /null-nvram /cpus /<Unnamed> /mmu /memory@0 /aliases /options /openprom /chosen /packages /cpus/PowerPC,603evARTHUR@0 /packages/ext2-file-system /packages/disk-label /packages/iso9660-file-system /packages/fat-file-system /packages/obp-tftp /packages/deblocker /packages/stringio /packages/terminal-emulator /packages/client-services ok printenv Variable Name Value Default Value hrp-memmap? false false virt-size 0x0 0xffffffff virt-base 0x0 0xffffffff real-size 0x0 0xffffffff real-base 0x0 0xffffffff real-mode? false false diag-switch? false false fcode-debug? false false ip-address 255.255.255.255 255.255.255.255 ip-router ip-domain ip-netmask 255.255.255.0 255.255.255.0 ip-dns-server local-mac-address? false false oem-logo oem-logo? false false oem-banner oem-banner? false false output-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 input-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 load-base 4194304 4194304 boot-command boot boot auto-boot? true true watchdog-reboot? false false diag-file diag-device net net boot-file boot-device disk net disk net ansi-terminal? true true screen-#columns 80 80 screen-#rows 34 34 silent-mode? false false use-nvramrc? false false nvramrc security-password security-#badlogins 0 security-mode none diag-switch? false false ok dev / ok .properties #address-cells 00000001 ok dev openprom ok .properties model FirmWorks,3.0 aligned-allocator relative-addressing name openprom ok dev /cpus/PowerPC,603evARTHUR ok .properties clock-frequency 05f5e100 reg 00000000 timebase-frequency 007de290 tlb-sets 00000080 tlb-size 00000100 d-cache-sets 00000080 d-cache-block-size 00000020 d-cache-size 00008000 i-cache-sets 00000080 i-cache-block-size 00000020 i-cache-size 00008000 device_type cpu name PowerPC,603evARTHUR ok Of course it's only the start and has a lot of missing parts yet: does not detect PCI bus and devices (I need to write a driver for the PCI host similar to what Atar did for 40p), it misdetects the CPU (or it may be hard coded somewhere), does not detect memory size (this is mentioned on Atar's blog) and may have other defficiencies. But for a start it works quite well and it was surprisingly easy to get it up thanks to previous work. Given that the Pegasos2 is quite close to PReP and PC hardware most of the drivers for PC like hardware are already there in OF, so maybe if I can make a working driver for the system controller chip the rest would just work or should be relatively easy to fix. So for the pegasos2 this seems to be a viable alternative that may not be too hard to get working if I limit the scope to just the pegasos2. For Mac machines more drivers would need to be written as these are not included in the open source OF version that was released for OLPC so only those drivers are included which were needed for that. Therefore it would be more work to write those missing drivers. We have USB driver (I've once tried porting that to OpenBIOS[1]) so keyboard and mouse might work where we have USB but we would still need drivers for uninorth and mac-io at least to get something working but maybe others as well, I'm not sure. For Sparc machines even CPU support is missing so it may be more difficult to get that working. Or maybe not as this could be added based on some other similar architecture: arm, mips and ppc are already there but these do have a lot of Forth files so it may take a while to understand those. I don't know Sparc hardware to tell what drivers may be needed. But from Atar's blog on getting OF working for QEMU PReP/40p I got the impression that Mitch Bradley (inventor of OpenFirmware and founder of FirmWorks) did help him by releasing some additional drivers or sources that he needed so maybe asking politely would not hurt and it may get easier, unless there are legal hurdles in releasing additional sources. Otherwise those need to be recreated but that may still be doable if someone does not mind learning enough Forth to do it. I'm not sure which is more work, getting OpenBIOS to the same level or writing drivers for OpenFirmware but maybe for PPC machines it's not much harder to rewrite the missing drivers. For Sparc I'm not sure, PPC support was already there so I don't know what it takes to add a new cpu support. Regards, BALATON Zoltan [1] One can follow the thread starting here: https://mail.coreboot.org/pipermail/openbios/2014-May/008244.html but basically the attempt to port OF driver to OpenBIOS ended with: https://mail.coreboot.org/pipermail/openbios/2014-May/008281.html some of those words are already there now but some are still missing. I've ended up finishing the C driver which was finally added, even though I only wanted to try qemu-system-ppc64 originally and did not plan to port a USB driver. That's what I meant saying I end up having to do fixes whenever I try something in OpenBIOS: like trying an FCode ROM the last time. At least OpenFirmware implements the standard already perfectly so we would only need to care about getting it to work with the machine and not if it has everythung that might be needed by stuff using it (or at least much less so than starting from scratch).

3 7

[PATCH v3 00/30] pci: build device tree from root
by Mark Cave-Ayland 23 Aug '19

23 Aug '19

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> v3: - Rebase onto master - Fix up USB debug string for keyboard reported by Zoltan - Fix for creating devices that don't have an entry in the PCI database - Fix for MacOS 9 not initialising network reported by Howard v2: - Fix up NVRAM initialisation so that -prom-env 'vga-ndrv?=false' works again Mark Cave-Ayland (30): 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 nvram: ensure that NVRAM configuration is separate from NVRAM node creation 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 pci: call set-args before configuring PCI device nodes 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 | 18 +++- 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 | 118 ++++++++++++------------ drivers/macio.h | 1 - drivers/pc_kbd.c | 48 +++++----- drivers/pc_serial.c | 32 +++---- drivers/pci.c | 132 +++++++++++++-------------- drivers/pmu.c | 152 +++++++++++++++++++++---------- drivers/usbhid.c | 17 ++-- drivers/virtio.c | 56 +++--------- include/drivers/drivers.h | 2 + include/libopenbios/bindings.h | 19 ++-- include/packages/nvram.h | 4 +- libopenbios/bindings.c | 10 +++ packages/nvram.c | 35 ++++++-- 24 files changed, 755 insertions(+), 544 deletions(-) -- 2.20.1

2 32

[PATCH 0/2] gcc 9 build fixes
by Mark Cave-Ayland 19 Aug '19

19 Aug '19

During the past couple of weeks I've updated my build chain to use gcc 9.1 which generates some additional warnings that cause the build to fail when building with -Werror. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): all: gcc 9 build fixes ppc: reduce size of Forth dictionary to 384K arch/ppc/qemu/kernel.c | 4 ++-- arch/sparc32/context.c | 2 +- drivers/cuda.c | 4 ++-- drivers/ide.c | 2 +- drivers/pmu.c | 4 ++-- fs/hfs/hfs_fs.c | 2 +- packages/nvram.c | 2 +- 7 files changed, 10 insertions(+), 10 deletions(-) -- 2.20.1

4 8

Muti CPU Support
by Jd Lyons 19 Aug '19

19 Aug '19

I’ve been working a little to see if I can get multi-threaded TGC to work for the Mac OS/X in qemu, but Openbios doesn’t seem to support more than one CPU and doesn’t build any device for a second CPU. I’ve looked at the openbios/arch/ppc/qemu/init.c, and that seems to be the place to apply a patch for multi cpu support, but I don’t really seem any graceful way of doing it. Can anyone offer any help? TGC-Work/bin/qemu-system-ppc -M mac99,via=pmu -serial stdio -smp 2,cores=2,threads=1 -accel tcg,thread=multi -cpu g4 -boot c -prom-env auto-boot?=true -prom-env boot-args=-v -hda /Users/jam/os9.2.1.img -m 256 -bios /Users/jam/aty7/openbios/obj-ppc/openbios-qemu.elf heathrow_class_init: init 2 core99_machine_class_init: init 2 qemu-system-ppc: warning: Guest not yet converted to MTTCG - you may get unexpected results s>> et_property: NULL phandle >> ============================================================= >> OpenBIOS 1.1 [Aug 6 2019 02:05] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 2 >> Memory: 256M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. >> switching to new context: >> call-method slw_update_keymap failed with error ffffffdf >> call-method slw_update_keymap failed with error ffffffdf

3 7

Re: R128 interrupts
by Jd Lyons 08 Aug '19

08 Aug '19

I’m 99% sure this is the trouble, I don’’t really understand IRQ’s and interrupts, there is some info in the Rage_128_register_referance_guide. I tested my theory via OS X 10.4.11and it mapped the VRAM rather than giving me the ATY:Not Usable, it also changed the screen resolution twice, once to 640x480 then to 1280x960. dev /pci/@f “ /pci/@f” select-dev “ ATY,Rage128Pd” encode-string “ name” property 1 encode-int “ interrupts” property boot OS X would not be able to change the screen resolution if the ‘NDRV’ didn’t load!!! So I’m 99% sure this is the trouble and we need to figure out how to create a mapped interrupt for the card, rather than this dummy Interrupt I create because I’m a dummy;-) > On Aug 8, 2019, at 12:41 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > > Could be the Rage128 ‘NDRV’ is aborting do to the lack of an interrupt……….

3 4

Debugging FCode ROM
by BALATON Zoltan 03 Aug '19

03 Aug '19

Hello, I'm trying to find out what's missing to use an FCode ROM for the ati-vga device to see how it would set up the card for MacOS. This has been done before for other FCode ROMs e.g. here: https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/E7PF… I can get some print out of compiling and defining new words by setting fcode-debug? and ?fcode-verbose to true as above but this only gives me what I can also get from detok but does not tell me where exactly it fails during executing these words afterwards. What I get is that after a lot of (compile), new-token and fcode# lines that define a lot of words it just ends in one of these (the second?) when executed: 400514a : [ 0x8bc ] 400514c : [ 0x926 ] byte-load: exception caught! But how can I see what's inside this word that caused the exception? There's the forth debugger I think to see or step through execution of words but how can I add an undefined/unnamed word to the debug before the the FCode runs? Looking at the definition of this word in the detok output does not get me further as it just calls more of these words defined in the FCode: 8512: b(:) 8513: (unnamed-fcode) [0x86a] 8515: (unnamed-fcode) [0x864] 8517: b(") ( len=7 ) " map-out" 8526: (unnamed-fcode) [0x91f] 8528: (unnamed-fcode) [0x86c] 8530: (unnamed-fcode) [0x866] 8532: b(") ( len=7 ) " map-out" 8541: (unnamed-fcode) [0x91f] 8543: 0 8544: b(to) (unnamed-fcode) [0x86c] 8547: 0 8548: b(to) (unnamed-fcode) [0x86a] 8551: b(;) 8552: new-token 0x926 so where can I get more details on execution of these words and the more precise location of the exception? Regards, BALATON Zoltan

5 71

Re: Implementing map-in
by Jd Lyons 30 Jul '19

30 Jul '19

I think I’ll just wait for all this stuff to git into the master of Qemu and Openbios and try and see if I can work with it then. > On Jul 30, 2019, at 8:38 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Tue, 30 Jul 2019, Jd Lyons wrote: >> patches, I really don’t want to format and apply 30 patches from emails, mostly because I don’t know how to properly use the patch command……... > > If you have the 30 patches in emails then git am is the tool to apply them. Save them in an mbox folder in ascending order (or just cat the raw message sources together in one file which is what an mbox folder is), or it may also work with messages in a folder, then use git am to apply them. Check git am --help for more info. > > Apparently there was some formatting error in my patch as others got problem with that as well so sorry about that. > > Regards, > BALATON Zoltan

1 0

Re: Implementing map-in
by BALATON Zoltan 30 Jul '19

30 Jul '19

On Tue, 23 Jul 2019, Mark Cave-Ayland wrote: > On 23/07/2019 20:13, BALATON Zoltan wrote: >> I hoped to be able to get some texual name or path that I can make sens than only hex >> numbers to identify where these point to. > > If you do show-devs before running your other commands then the values listed there > are the phandles. Otherwise you can convert the phandle to a string with the Forth > word get-package-path in OpenBIOS so: > > feval("active-package get-package-path type cr"); > > and: > > feval("my-self ihandle>phandle get-package-path type cr"); OK, adding back the list to cc because I dropped it accidentally in one of the replies but maybe someone else might also be interested or be able to add something. So now I've added more debug: static void ob_pci_bus_map_in(int *idx) { PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx); PCI_DPRINTF("active-package: "); feval("active-package get-package-path type"); PCI_DPRINTF(" my-self: "); feval("my-self u. my-self ihandle>phandle get-package-path type cd"); fword(".s"); fword("pci-map-in"); fword(".s"); } and removed 0-ing my-self from pci-map-in for testing. I get: 0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1554 1fc5aba4 -7e000000 0 2007818 4000 <0> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <3> 0 42007810 1000000 <-3> -c38c0 I think this breaks because my-self pointing to /pci breaks my-#acells used by decode-phys while map-in is called during open-dev. If I disable the open word in /pci/ATY before calling open-dev to avoid this problem to be able to try the FCode ROM I get: 0 > dev /pci/ATY ok 0 > : open -1 ; open isn't unique. ok 0 > load hd:\ati.rom >> ob_pci_decode_unit idx=1fc5ac54 >> ob_pci_decode_unit idx=1fc5ac54 addr=00000000 00000000 00006000 >> ob_pci_encode_unit space=0 dev=12 fn=0 buf=c ok 0 > " /pci/ATY" open-dev ok 1 > .s <1> 1fc5ae2c ok 1 > to my-self ok 0 > load-base 40 + 1 byte-load dimensions isn't unique. color! isn't unique. set-colors isn't unique. fill-rectangle isn't unique. >> ob_pci_bar_map_in idx=1fc5ae20 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5adf4 /pci@f2000000 <12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100 <b> -1 1 0 -1 0 0 -1 -bf5b8 0 0 -1 byte-load: exception caught! ok 0 > So this still breaks because my-self is /pci here. Adding back the 0-ing hack to pci-map-in which avoided the first problem with open-dev but still broke with FCode ROM: 0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1514 1fc5aba4 -7e000000 0 2007818 4000 <4> 1 -a1514 1fc5aba4 -7e000000 ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1514 1fc5aba4 -7f000000 0 42007810 1000000 <4> 1 -a1514 1fc5aba4 -7f000000 ok my-self and active package is the same yet it works now? I don't understand that. 1 > .s <1> 1fc5ac30 ok 1 > to my-self ok 0 > load hd:\ati.rom ob_pci_decode_unit idx=1fc5acf4 >> ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000 >> ob_pci_encode_unit space=0 dev=12 fn=0 buf=c ok 0 > debug pci-map-in Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > dev /pci/ATY ok 0 > load-base 40 + 1 byte-load dimensions isn't unique. color! isn't unique. set-colors isn't unique. fill-rectangle isn't unique. >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 100 ) fff56d38: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 ) fff56d3c: nip ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 1007814 ) fff56d40: nip ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 ) fff56d44: my-self ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 1fc5abf8 ) fff56d48: swap ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 ) fff56d4c: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 ) fff56d50: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 fff3c73c ) fff56d58: (to) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 ) fff56d5c: (") ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d64 12 ) fff56d78: active-package ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d64 12 fff5eaec ) fff56d7c: get-package-property ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c 0 ) fff56d80: 0= ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c ffffffff ) fff56d84: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c ) fff56d8c: (begin) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed1c 3c ) fff56d90: decode-phys ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed28 30 81000000 0 42007810 ) but it does not work here, decode-phys only returns addr.hi because my-#acells returns 1 here instead of 3 for some reason but maybe not because of my-self as that seems to be the same. OK, maybe I should set my-self to the same as active-package instead of 0-ing in pci-map-in? This actually seems to work better (although I don't like this but not having any better idea I have to go with this now): 0 > " /pci/ATY" open-dev >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1510 1fc5aba4 -7e000000 0 2007818 4000 <4> 1 -a1510 1fc5aba4 -7e000000 ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1510 1fc5aba4 -7f000000 0 42007810 1000000 <4> 1 -a1510 1fc5aba4 -7f000000 ok 1 > .s <1> 1fc5ac30 ok 1 > to my-self ok 0 > dev /pci/ATY ok 0 > load hd:\ati.rom ob_pci_decode_unit idx=1fc5acf4 >> ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000 >> ob_pci_encode_unit space=0 dev=12 fn=0 buf=c ok 0 > debug pci-map-in Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > load-base 40 + 1 byte-load dimensions isn't unique. color! isn't unique. set-colors isn't unique. fill-rectangle isn't unique. >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 100 ) fff56d38: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 0 1007814 ) fff56d3c: nip ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 0 1007814 ) fff56d40: nip ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 ) fff56d44: my-self ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1007814 1fc5abf8 ) fff56d48: swap ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 ) fff56d4c: active-package ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5eaf0 ) fff56d50: ihandle>phandle ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 ) fff56d54: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 0 fff3c73c ) fff56d5c: (to) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 ) fff56d60: (") ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d68 12 ) fff56d7c: active-package ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff56d68 12 fff5eaf0 ) fff56d80: get-package-property ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c 0 ) fff56d84: 0= ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c ffffffff ) fff56d88: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c ) fff56d90: (begin) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed20 3c ) fff56d94: decode-phys ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 ) Now we have the correct amount of addresses here fff56d98: dup ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 42007810 ) fff56d9c: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 42007810 fffffff ) fff56da4: and ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 ) fff56da8: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 6 ) fff56db0: pick ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 ) fff56db4: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 fffffff ) fff56dbc: and ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 2007810 1007814 ) fff56dc0: = ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 0 ) fff56dc4: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 81000000 0 42007810 ) fff56e68: 3drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed2c 30 ) fff56e6c: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed30 2c 0 ) fff56e70: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed30 2c ) fff56e74: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 1000000 ) fff56e78: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 ) fff56e7c: dup ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 28 ) fff56e80: 0= ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 0 ) fff56e84: (until) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 0 ) fff56e88: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed34 28 ) fff56d94: decode-phys ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 ) fff56d98: dup ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 ) fff56d9c: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 fffffff ) fff56da4: and ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 ) fff56da8: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 6 ) fff56db0: pick ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 ) fff56db4: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 fffffff ) fff56dbc: and ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 1007814 1007814 ) fff56dc0: = ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 ffffffff ) fff56dc4: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 0 1007814 ) fff56dcc: 2drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 fff5ed40 1c 1000 ) fff56dd0: -rot ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed40 1c ) fff56dd4: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed44 18 0 ) fff56dd8: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed44 18 ) fff56ddc: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed48 14 100 ) fff56de0: drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5ed48 14 ) fff56de4: 2drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 ) fff56de8: over ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1007814 ) fff56dec: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1007814 18 ) fff56df4: rshift ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 ) fff56df8: 3 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 3 ) fff56dfc: and ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 ) fff56e00: 1 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 1 1 ) fff56e04: = ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 ffffffff ) fff56e08: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 ) fff56e10: (") ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 ) fff56e1c: active-package ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 fff5eaf0 ) fff56e20: parent ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff56e18 3 fff5b11c ) fff56e24: get-package-property ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 0 ) fff56e28: 0= ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 ffffffff ) fff56e2c: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5bc 8 ) fff56e34: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 fff5b5c0 4 f2000000 ) fff56e38: -rot ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 fff5b5c0 4 ) fff56e3c: decode-int ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 fff5b5c4 0 2000000 ) fff56e40: 3drop ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 1000 f2000000 ) fff56e44: + ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 1007814 f2001000 ) fff56e48: nip ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 1fc5abf8 f2001000 ) fff56e4c: swap ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 1fc5abf8 ) fff56e50: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 1fc5abf8 fff3c73c ) fff56e58: (to) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff40a48 0 0 0 0 0 0 f2001000 ) fff56e5c: exit <f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000 and getting the correct mapped bar address here byte-load: exception caught! ok 0 > but it still breaks short after, probably in config-@. How to trace FCode execution? I only know about ?fcode-verbose so try that: 400514a : [ 0x8bc ] 400514c : [ 0x926 ] >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000<12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100 <f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000 byte-load: exception caught! ok still in the same word so likely it's config-b@ is wrong. Is it called at all? 0 > " /pci/ATY" open-dev to my-self >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1510 1fc5aba4 -7e000000 0 2007818 4000 <4> 1 -a1510 1fc5aba4 -7e000000 ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <7> 1 -a1510 1fc5aba4 -7f000000 0 42007810 1000000 <4> 1 -a1510 1fc5aba4 -7f000000 ok 0 > dev /pci/ATY ok 0 > debug config-b! Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > debug config-b@ Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > load hd:\ati.rom ob_pci_decode_unit idx=1fc5acf4 >> ob_pci_decode_unit idx=1fc5acf4 addr=00000000 00000000 00006000 >> ob_pci_encode_unit space=0 dev=12 fn=0 buf=c ok 0 > load-base 40 + 1 byte-load dimensions isn't unique. color! isn't unique. set-colors isn't unique. fill-rectangle isn't unique. >> ob_pci_bar_map_in idx=1fc5ac24 >> active-package: ob_pci_encode_unit space=0 dev=15 fn=0 buf=f /pci@f2000000/ATY@f>> my-self: 1fc5abf8 /pci@f2000000 <12> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 0 0 1007814 100 <f> -1 1 0 -1 0 0 -1 -bf5b8 0 0 0 0 0 0 -dfff000 byte-load: exception caught! ok 0 > Apparently not, so it probably has to be added as a method of the pci node so it can $call-parent it and implemented in C instead of the forth hack I've tried to add. (SLOF also seems to call back to rtas for this.) So I'll try that and see what happens.

5 16

[PATCH v2 00/30] pci: build device tree from root
by Mark Cave-Ayland 28 Jul '19

28 Jul '19

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> v2: - Fix up NVRAM initialisation so that -prom-env 'vga-ndrv?=false' works again Mark Cave-Ayland (30): 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 nvram: ensure that NVRAM configuration is separate from NVRAM node creation 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 pci: call set-args before configuring PCI device nodes 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 | 118 ++++++++++++------------ drivers/macio.h | 1 - drivers/pc_kbd.c | 48 +++++----- drivers/pc_serial.c | 32 +++---- drivers/pci.c | 123 ++++++++++++------------- drivers/pmu.c | 152 +++++++++++++++++++++---------- drivers/usbhid.c | 16 ++-- drivers/virtio.c | 56 +++--------- include/drivers/drivers.h | 2 + include/libopenbios/bindings.h | 19 ++-- include/packages/nvram.h | 4 +- libopenbios/bindings.c | 10 +++ packages/nvram.c | 35 ++++++-- 24 files changed, 744 insertions(+), 540 deletions(-) -- 2.20.1

2 38

Re: Debugging FCode ROM
by Jd Lyons 25 Jul '19

25 Jul '19

I think old world Macs always booted in 640x480x8, but new world can boot at a higher screen resolution setup in NVRAM. The change in modes to 640x480x8 maybe for compatibility with Old World Macs. I think reduced ATI ROM’s, that we removed the ‘NDRV’ so it would fit on a 64k EEROM always booted at 640x480x8 until the disk based “NDRV’ loaded. I don’t think anyone ever flashed a reduced Rage128 Pro ROM without the ‘NDRV’ sos I don’t really know how a new world Mac would handle that, if it could still set a higher screen resolution. Maybe we can we can get some info from the sources of the linux r128 driver? > On Jul 25, 2019, at 5:53 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > > On Thu, 25 Jul 2019, Jd Lyons wrote: >> I take it you’ve seen this: >> >> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEw… > > Sure, that's what I use for register reference all the time (and is linked from my qmiga.osdn.io page although not directly to avoid possible copyright problems but the card page where the doc is available linked and I've told you that before and also hinted on that page. There are more docs available from the pages linked from my qmiga page, all those might have useful info (the prg and sdk guides too, even though they are for different cards but these are similar so some details are the same). > > However it does not explain what AMCGPIO is, only what are the bits in those regs or did I miss that part where it actually says what should be accessible via that register? From the access pattern it looks similar to GPIO_MONID where we have the EDID so maybe the card has another connector the DDC/EDID of which is accessed via the AMCGPIO reg? The FCode checks both but switches mode after reading AMCGPIO and before getting EDID from GPIO_MONID so maybe we need to add EDID to the AMCGPIO reg? But I don't know which bits to connect it. Probably one could find out by reading the detok-ed FCode source to see what it does with the EDID and how does it select mode or find an open source driver that accesses this to find out how this should work. > > But the problem currently is with the offset 8000 in the selected mode which the QEMU VGA emulation can't handle or I don't know how to make it handle. That's why picture is wrong at the moment. So either we should allow this offset or find out why FCode wants that and when it uses different mode is that better aligned then? Where does it get this 640x480x8 mode and shouldn't it use something higher by default? I don't know how MacOS works and what its default mode is. > > Regards, > BALATON Zoltan

1 0

Implementing map-in
by BALATON Zoltan 23 Jul '19

23 Jul '19

On Sun, 21 Jul 2019, Mark Cave-Ayland wrote: > On 21/07/2019 15:16, BALATON Zoltan wrote: >> OK I came up with the attched patch (on top of your previous series and set-args >> patch) which is I think about what you've suggested. I kept ob_pci_map for existing >> callers but renamed it to ob_pci_map_in to keep symmetry between ob_pci_map and >> ob_pci_unmap with ob_pci_map now only doing mapping as its name suggests (although I >> think this should still be simpler) and ob_pci_bus_map_in is doing its own address >> decoding now. The previous ob_pci_map (now called ob_pci_map_in which is a C helper >> for some of what map-in should do) can be cleaned up as you like. Also cleaned up >> some white space (tab vs. spaces) but that's excluded from this patch for brevity. > > Now I'm really confused - I had a quick look at your patch and compared it with Good that you're only confused now. :-) I was and still am confused about it all the time so please bear with me. > pci_config_*() words and they show that you can't memory map PCI config space on a > Mac. So how did you get to the conclusion earlier in the thread that this was what > was required? Apparently I was confused... Now I realise that this usage of map-in in FCode ROM really wants to map the IO BAR1. My confusion probably comes from that after mapping it it uses config-b[!@] to tweak some regs so I thought it may want config space. (I'm still confused though after reading the description of map-in and addresses in the PCI binding doc. And we probably will need access to config space if we want to implement config-* words in Forth. We could add callbacks to C for those but that's not the nicest way.) >> But it does not seem to work yet: >> >> 0 > " /pci@f2000000/ATY" open-dev to my-self >>>> ob_pci_bar_map_in idx=1fc5ac54 >>>> pci_bus_addr_to_host_addr space=2 ba=0x82000000 >>>> ob_pci_map: phys=0x82000000 size=16384 >>>> ob_pci_bar_map_in idx=1fc5ac54 >>>> pci_bus_addr_to_host_addr space=2 ba=0x81000000 >>>> ob_pci_map: phys=0x81000000 size=16777216 >> ?ok > > Here we see 2 MMIO BARs being mapped: one of 16K and another of 16M. And this happens > as soon as you open the device? I think you'll have to explain more about your > command line and how you are getting OpenBIOS to execute the FCode, since I can't > tell if this is OpenBIOS or the FCode. No FCode here, just started OpenBIOS with patched openbios-elf and typed commands that I've seen in the FCode. All this comes from OpenBIOS, don't ask me why it calls this for open-dev. >> 0 > my-unit? ok >> 3 > . 7800? ok >> 2 > . 0? ok >> 1 > . 0? ok >> 0 > my-space? ok >> 1 > . 7800? ok >> 0 > my-address? ok >> 2 > . 0? ok >> 1 > . 0? ok >> 0 > my-address h# 1000014 my-space + h# 100? ok >> 4 > .s <4> 0 0 1007814 100 >> ?ok >> 4 > " map-in" $call-parent >>>> ob_pci_bar_map_in idx=1fc5ac54 >>>> pci_bus_addr_to_host_addr space=1 ba=0x0 >>>> ob_pci_map: phys=0xf2000000 size=256 >> ?ok > > This is trying to map an IO BAR with 256 bytes, but the phys address isn't going to > be correct because OpenBIOS copies arch->io_base into *io_base (and also *mem_base > for MMIO) during PCI configuration and advances that copy to hold the start of the > next free address. Where does OpenBIOS copy and advance these values and what do *io_base and *mem_base refer to here? I assume the map-in word runs after the device tree is already constucted so these should already be mapped and map-in might just need to return a virt address for the already mapped bars. > At a very minimum you're going to have to teach the PCI map-in how to use these > values instead of making the assumption that the BAR has already been mapped by Which values? > ob_pci_configure_bar() and the address can be calculated by adding the BAR address to > arch->io_base or arch->mem_base according to the space type. This is how > pci_bus_addr_to_host_addr() currently works. My patch called pci_bus_addr_to_host_addr in ob_pci_bus_map_in with the space decoded from phys.hi on the stack yet the virt address came out wrong at the end. Now I've tried to do instead what SLOF's map-in does: https://github.com/aik/SLOF/blob/master/slof/fs/pci-config-bridge.fs#L59 and ignore everything except phys.hi and get bar address from that like: size = POP(); phys[0] = POP(); phys[1] = POP(); phys[2] = POP(); PCI_DPRINTF("%s idx=%p, hi=%"PRIx32", mid=%"PRIx32", lo=%"PRIx32", size=" FMT_ucell"\n", __func__, idx, phys[0], phys[1], phys[2], size); pci_decode_phys_addr(phys, &flags, &space_code, &dev, &reg, &addr); /* Check if reg is actually a Base Address Reg */ if (reg < PCI_BASE_ADDR_0 || (reg > PCI_BASE_ADDR_5 && reg != PCI_ROM_ADDRESS)) { PUSH(-1); return; } addr = pci_config_read32(reg, dev); PCI_DPRINTF("%s bar=%"PRIx32"\n", __func__, addr); virt = ob_pci_map(addr, size); but then bar==-1 (even for MMIO regions which were mapped before) so it looks like it's not mapped at this point so map-in should program the BAR reg or call another function for that? > The other issue is that the PCI enumeration code will already have mapped the ATI > BARs once so you'll have to come up with a solution so that if you detect an FCode > ROM then the existing PCI configuration code is ignored. Otherwise you'll find that > you have mapped the 16M MMIO BAR twice which is going to take quite a bit of MMIO > memory and lead to more confusion. Does it map then unmap the region without freeing the allocated MMIO space? Or if it's still mapped we should just return a pointer to the already mapped space. Could we just get that from assigned-addresses? > Finally one other thing: I'm finding this thread really hard to follow - too much > information is spread across too many emails, and the subject line isn't really > helping me understand what topic we're following or where I can find related > information. May I suggest that it makes sense to break this down into a series of > smaller, more concise threads? I've tried to do that but forgot to update the subject. This thread is now about implementing map-in. The goal is still to run FCode ROMs but first step is to get map-in working. Thank you, BALATON Zoltan

3 13

RFC: porting SLOF's fdt.fs to OpenBIOS
by BALATON Zoltan 21 Jul '19

21 Jul '19

Hello, This is an attempt to port ftd.fs for FDT unflattening from SLOF to OpenBIOS. This compiles but I have not tried to feed it any fdt yet because I'm sure it won't work yet as some words are wrong. The words I had to implement for it (marked with a FIXME comment) should be reviewed and checked if they could work and the set-unit word is still missing so that needs to be implemented. Also 64bit stuff and claim usage should be clarified. Those words that are copied and do work may have better alternatives that I haven't found so could be replaced. Anyway this is a start to try to get this done. Once it works it will expect an FDT in memory at address fdt-start then the fdt-doit word at the end is an example of how to unflatten that into an OF device-tree (at least that's what SLOF does if I got that right). Any insight or comments on this are welcome. Regards, BALATON Zoltan diff --git a/forth/util/build.xml b/forth/util/build.xml index 4839d2c..25e02db 100644 --- a/forth/util/build.xml +++ b/forth/util/build.xml @@ -11,6 +11,7 @@ <dictionary name="openbios" target="forth"> <object source="util.fs"/> <object source="pci.fs"/> + <object source="fdt.fs"/>  diff --git a/forth/util/fdt.fs b/forth/util/fdt.fs new file mode 100644 index 0000000..af29bba --- /dev/null +++ b/forth/util/fdt.fs @@ -0,0 +1,586 @@ +\ ***************************************************************************** +\ * Copyright (c) 2011 IBM Corporation +\ * All rights reserved. +\ * This program and the accompanying materials +\ * are made available under the terms of the BSD License +\ * which accompanies this distribution, and is available at +\ * http://www.opensource.org/licenses/bsd-license.php +\ * +\ * Contributors: +\ * IBM Corporation - initial implementation +\ ****************************************************************************/ +\ Changes for OpenBIOS: BALATON Zoltan, 2019 + +1 VALUE fdt-debug +TRUE VALUE fdt-cas-fix? +0 VALUE fdt-start + +struct + 4 field >fdth_magic + 4 field >fdth_tsize + 4 field >fdth_struct_off + 4 field >fdth_string_off + 4 field >fdth_rsvmap_off + 4 field >fdth_version + 4 field >fdth_compat_vers + 4 field >fdth_boot_cpu + 4 field >fdth_string_size + 4 field >fdth_struct_size +constant /fdth + +h# d00dfeed constant OF_DT_HEADER +h# 1 constant OF_DT_BEGIN_NODE +h# 2 constant OF_DT_END_NODE +h# 3 constant OF_DT_PROP +h# 4 constant OF_DT_NOP +h# 9 constant OF_DT_END + +\ Create some variables early +0 value fdt-start-addr +0 value fdt-struct +0 value fdt-strings + + +\ FIXME: review the following words which were added for OpenBIOS +\ some of these copied verbatim from SLOF others try to implement +\ alternatives +\ +\ definitely wrong/missing: set-unit and claim disabled further below +\ +\ may be wrong: find-node, and other related node words and 64bit stuff +\ (SLOF seems to always be in 64bit mode and not sure if that's needed +\ to parse FDT or could it be changed for 32bit as OpenBIOS does not +\ define some words in 32bit mode.) + +: get-node ?active-package ; +: set-node active-package! ; +: node>path " ?" ; \ only used for debugging and errors +: get-parent get-node parent ; +: my-#address-cells my-#acells ; +: get-property get-package-property ; +: find-node ( path len -- phandle|0 ) + find-dev 0= if \ find-dev returns ( phandle true | false ) + 0 + then +; + +\ : 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 3drop ; \ set-space set-address ; + +: str= ( str1 len1 str2 len2 -- equal? ) + rot over <> IF 3drop false ELSE comp 0= THEN ; + +: from-cstring ( addr - len ) + dup dup BEGIN c@ 0 <> WHILE 1 + dup REPEAT + swap - +; + +: test-string ( param len -- true | false ) + 0 ?DO + dup i + c@ \ Get character / byte at current index + dup 20 < swap 7e > OR IF \ Is it out of range 32 to 126 (=ASCII) + drop FALSE UNLOOP EXIT \ FALSE means: No ASCII string + THEN + LOOP + drop TRUE \ Only ASCII found --> it is a string +; + +: find-substr ( basestr-ptr basestr-len substr-ptr substr-len -- pos ) + \ if substr-len == 0 ? + dup 0 = IF + \ return 0 + 2drop 2drop 0 exit THEN + \ if substr-len <= basestr-len ? + dup 3 pick <= IF + \ run J from 0 to "basestr-len"-"substr-len" and I from 0 to "substr-len"-1 + 2 pick over - 1+ 0 DO dup 0 DO + \ substr-ptr[i] == basestr-ptr[j+i] ? + over i + c@ 4 pick j + i + c@ = IF + \ (I+1) == substr-len ? + dup i 1+ = IF + \ return J + 2drop 2drop j unloop unloop exit THEN + ELSE leave THEN + LOOP LOOP + THEN + \ if there is no match then exit with basestr-len as return value + 2drop nip +; + +CREATE $catpad 400 allot +: $cat ( str1 len1 str2 len2 -- str3 len3 ) + >r >r dup >r $catpad swap move + r> dup $catpad + r> swap r@ move + r> + $catpad swap ; + +: split ( str len char -- left len right len ) + >r 2dup r> findchar IF >r over r@ 2swap r> 1+ /string ELSE 0 0 THEN ; +: generic-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + dup >r -rot BEGIN r@ WHILE r> 1- >r [char] , split 2swap + $number IF 0 THEN r> swap >r >r REPEAT r> 3drop + BEGIN dup WHILE 1- r> swap REPEAT drop ; +: generic-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + 0 0 rot ?dup IF 0 ?DO rot (u.) $cat s" ," $cat LOOP 1- THEN ; +: hex-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + base @ >r hex generic-decode-unit r> base ! ; +: hex-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + base @ >r hex generic-encode-unit r> base ! ; + +64bit? [IF] +: hex64-decode-unit ( str len ncells -- addr.lo ... addr.hi ) + dup 2 <> IF + hex-decode-unit + ELSE + drop + base @ >r hex + $number IF 0 0 ELSE xlsplit THEN + r> base ! + THEN +; +: hex64-encode-unit ( addr.lo ... addr.hi ncells -- str len ) + dup 2 <> IF + hex-encode-unit + ELSE + drop + base @ >r hex + lxjoin (u.) + r> base ! + THEN +; +[ELSE] +: hex64-decode-unit hex-decode-unit ; +: hex64-encode-unit hex-encode-unit ; +: x@ l@ ; +: xlsplit ( o -- quad.lo quad.hi ) + dup h# ffffffff and swap d# 32 rshift + ; +[THEN] + +\ functions to review end here, also see fdt-claim-reserve below + + +: fdt-init ( fdt-start -- ) + dup to fdt-start-addr + dup dup >fdth_struct_off l@ + to fdt-struct + dup dup >fdth_string_off l@ + to fdt-strings + drop +; + +\ Dump fdt header for all to see and check FDT validity +: fdt-check-header ( -- ) + fdt-start-addr dup 0 = IF + ." No flat device tree !" cr drop -1 throw EXIT THEN + hex + fdt-debug IF + ." Flat device tree header at 0x" dup . s" :" type cr + ." magic : 0x" dup >fdth_magic l@ . cr + ." total size : 0x" dup >fdth_tsize l@ . cr + ." offset to struct : 0x" dup >fdth_struct_off l@ . cr + ." offset to strings: 0x" dup >fdth_string_off l@ . cr + ." offset to rsvmap : 0x" dup >fdth_rsvmap_off l@ . cr + ." version : " dup >fdth_version l@ decimal . hex cr + ." last compat vers : " dup >fdth_compat_vers l@ decimal . hex cr + dup >fdth_version l@ 2 >= IF + ." boot CPU : 0x" dup >fdth_boot_cpu l@ . cr + THEN + dup >fdth_version l@ 3 >= IF + ." strings size : 0x" dup >fdth_string_size l@ . cr + THEN + dup >fdth_version l@ 11 >= IF + ." struct size : 0x" dup >fdth_struct_size l@ . cr + THEN + THEN + dup >fdth_magic l@ OF_DT_HEADER <> IF + ." Flat device tree has incorrect magic value !" cr + drop -1 throw EXIT + THEN + dup >fdth_version l@ 10 < IF + ." Flat device tree has usupported version !" cr + drop -1 throw EXIT + THEN + + drop +; + +\ Fetch next tag, skip nops and increment address +: fdt-next-tag ( addr -- nextaddr tag ) + 0 ( dummy tag on stack for loop ) + BEGIN + drop ( drop previous tag ) + dup l@ ( read new tag ) + swap 4 + swap ( increment addr ) + dup OF_DT_NOP <> UNTIL ( loop until not nop ) +; + +\ Parse unit name and advance addr +: fdt-fetch-unit ( addr -- addr $name ) + dup from-cstring \ get string size + 2dup + 1 + 3 + fffffffc and -rot +; + +\ Update unit with information from the reg property... +\ ... this is required for the PCI nodes for example. +: fdt-reg-unit ( prop-addr prop-len -- ) + decode-phys ( prop-addr' prop-len' phys.lo ... phys.hi ) + set-unit ( prop-addr' prop-len' ) + 2drop +; + +\ Lookup a string by index +: fdt-fetch-string ( index -- str-addr str-len ) + fdt-strings + dup from-cstring +; + +: fdt-create-dec s" decode-unit" $CREATE , DOES> @ hex64-decode-unit ; +: fdt-create-enc s" encode-unit" $CREATE , DOES> @ hex64-encode-unit ; + +\ Check whether array contains an zero-terminated ASCII string: +: fdt-prop-is-string? ( addr len -- string? ) + dup 1 < IF 2drop FALSE EXIT THEN \ Check for valid length + 1- + 2dup + c@ 0<> IF 2drop FALSE EXIT THEN \ Check zero-termination + test-string +; + +\ Encode fdt property to OF property +: fdt-encode-prop ( addr len -- ) + 2dup fdt-prop-is-string? IF + 1- encode-string + ELSE + encode-bytes + THEN +; + +\ Method to unflatten a node +: fdt-unflatten-node ( start -- end ) + \ this can and will recurse + recursive + + \ Get & check first tag of node ( addr -- addr) + fdt-next-tag dup OF_DT_BEGIN_NODE <> IF + s" Weird tag 0x" type . " at start of node" type cr + -1 throw + THEN drop + + new-device + + \ Parse name, split unit address + fdt-fetch-unit + dup 0 = IF drop drop " /" THEN + 40 left-parse-string + \ Set name + device-name + + \ Set preliminary unit address - might get overwritten by reg property + dup IF + " #address-cells" get-parent get-package-property IF + 2drop + ELSE + decode-int nip nip + hex-decode-unit + set-unit + THEN + ELSE 2drop THEN + + \ Iterate sub tags + BEGIN + fdt-next-tag dup OF_DT_END_NODE <> + WHILE + dup OF_DT_PROP = IF + \ Found property + drop dup ( drop tag, dup addr : a1 a1 ) + dup l@ dup rot 4 + ( fetch size, stack is : a1 s s a2) + dup l@ swap 4 + ( fetch nameid, stack is : a1 s s i a3 ) + rot ( we now have: a1 s i a3 s ) + fdt-encode-prop rot ( a1 s pa ps i) + fdt-fetch-string ( a1 s pa ps na ns ) + 2dup s" reg" str= IF + 2swap 2dup fdt-reg-unit 2swap + THEN + property + + 8 + 3 + fffffffc and + ELSE dup OF_DT_BEGIN_NODE = IF + drop ( drop tag ) + 4 - + fdt-unflatten-node + ELSE + drop -1 throw + THEN THEN + REPEAT drop \ drop tag + + \ Create encode/decode unit + " #address-cells" get-node get-package-property IF ELSE + decode-int dup fdt-create-dec fdt-create-enc 2drop + THEN + + finish-device +; + +\ Start unflattening +: fdt-unflatten-tree + fdt-debug IF + ." Unflattening device tree..." cr THEN + fdt-struct fdt-unflatten-node drop + fdt-debug IF + ." Done !" cr THEN +; + +\ Find memory size +: fdt-parse-memory + \ XXX FIXME Handle more than one memory node, and deal + \ with RMA vs. full access + " /memory@0" find-device + " reg" get-node get-package-property IF throw -1 THEN + + \ XXX FIXME Assume one entry only in "reg" property for now + decode-phys 2drop decode-phys + my-#address-cells 1 > IF 20 << or THEN + + fdt-debug IF + dup ." Memory size: " . cr + THEN + \ claim.fs already released the memory between 0 and MIN-RAM-SIZE, + \ so we've got only to release the remaining memory now: +\ MIN-RAM-SIZE swap MIN-RAM-SIZE - release + 2drop device-end +; + +\ FIXME: Find out if this is needed and what should it do +: claim 3drop ; + +\ Claim fdt memory and reserve map +: fdt-claim-reserve + fdt-start-addr + dup dup >fdth_tsize l@ 0 claim drop + dup >fdth_rsvmap_off l@ + + BEGIN + dup dup x@ swap 8 + x@ + dup 0 <> + WHILE + fdt-debug IF + 2dup swap ." Reserve map entry: " . ." : " . cr + THEN + 0 claim drop + 10 + + REPEAT drop drop drop +; + +\ The following functions are use to replace the FDT phandle and +\ linux,phandle properties with our own OF1275 phandles... + +\ This is used to check whether we successfully replaced a phandle value +0 VALUE (fdt-phandle-replaced) + +\ Replace phandle value in "interrupt-map" property +: fdt-replace-interrupt-map ( old new prop-addr prop-len -- old new ) + BEGIN + dup ( old new prop-addr prop-len prop-len ) + WHILE + \ This is a little bit ugly ... we're accessing the property at + \ hard-coded offsets instead of analyzing it completely... + swap dup 10 + ( old new prop-len prop-addr prop-addr+10 ) + dup l@ 5 pick = IF + \ it matches the old phandle value! + 3 pick swap l! + TRUE TO (fdt-phandle-replaced) + ELSE + drop + THEN + ( old new prop-len prop-addr ) + 1c + swap 1c - + ( old new new-prop-addr new-prop-len ) + REPEAT + 2drop +; + +: (fdt-replace-phandles) ( old new propname propnamelen node -- ) + get-property IF 2drop EXIT THEN + BEGIN + dup + WHILE ( old new prop-addr prop-len ) + over l@ + 4 pick = IF + 2 pick 2 pick l! \ replace old with new in place + TRUE TO (fdt-phandle-replaced) + THEN + 4 - swap 4 + swap + REPEAT + 2drop 2drop +; + +\ Replace one phandle "old" with a phandle "new" in "node" and recursively +\ in its child nodes: +: fdt-replace-all-phandles ( old new node -- ) + \ ." Replacing in " dup node>path type cr + >r + s" interrupt-map" r@ get-property 0= IF + ( old new prop-addr prop-len R: node ) + fdt-replace-interrupt-map + THEN + + 2dup s" interrupt-parent" r@ (fdt-replace-phandles) + 2dup s" ibm,gpu" r@ (fdt-replace-phandles) + 2dup s" ibm,npu" r@ (fdt-replace-phandles) + 2dup s" ibm,nvlink" r@ (fdt-replace-phandles) + 2dup s" memory-region" r@ (fdt-replace-phandles) + + \ ... add more properties that have to be fixed here ... + r> + \ Now recurse over all child nodes: ( old new node ) + child BEGIN + dup + WHILE + 3dup RECURSE + PEER + REPEAT + 3drop +; + +\ Replace one FDT phandle "val" with a OF1275 phandle "node" in the +\ whole tree: +: fdt-update-phandle ( val node -- ) + >r + FALSE TO (fdt-phandle-replaced) + r@ s" /" find-node ( val node root ) + fdt-replace-all-phandles + (fdt-phandle-replaced) IF + r@ set-node + s" phandle" delete-property + s" linux,phandle" delete-property + ELSE + diagnostic-mode? IF + cr ." Warning: Did not replace phandle in " r@ node>path type cr + THEN + THEN +r> drop +; + +\ Check whether a node has "phandle" or "linux,phandle" properties +\ and replace them: +: fdt-fix-node-phandle ( node -- ) + >r + s" phandle" r@ get-property 0= IF + decode-int nip nip + \ ." found phandle: " dup . cr + r@ fdt-update-phandle + THEN + r> drop +; + +\ Recursively walk through all nodes to fix their phandles: +: fdt-fix-phandles ( node -- ) + \ ." fixing phandles of " dup node>path type cr + dup fdt-fix-node-phandle + child BEGIN + dup + WHILE + dup RECURSE + PEER + REPEAT + drop + device-end +; + +: fdt-create-cas-node ( name -- ) + 2dup + 2dup " memory@" find-substr 0 = IF + fdt-debug IF ." Creating memory@ " cr THEN + new-device + 2dup " @" find-substr nip device-name \ Parse the node name + 2dup + 2dup " @" find-substr rot over + 1 + -rot - 1 - \ Jump to addr afte "@" + parse-2int nip xlsplit set-unit \ Parse and set unit + finish-device + ELSE + 2dup " ibm,dynamic-reconfiguration-memory" find-substr 0 = IF + fdt-debug IF ." Creating ibm,dynamic-reconfiguration-memory " cr THEN + new-device + device-name + finish-device + ELSE + 2drop 2drop + false to fdt-cas-fix? + ." Node not supported " cr + EXIT + THEN + THEN + + find-node ?dup 0 <> IF set-node THEN +; + +: fdt-fix-cas-node ( start -- end ) + recursive + fdt-next-tag dup OF_DT_BEGIN_NODE <> IF + ." Error " cr + false to fdt-cas-fix? + EXIT + THEN drop + fdt-fetch-unit + dup 0 = IF drop drop " /" THEN + 40 left-parse-string + 2swap ?dup 0 <> IF + nip + 1 + + \ Add the string len +@ + ELSE + drop + THEN + fdt-debug IF ." Setting node: " 2dup type cr THEN + 2dup find-node ?dup 0 <> IF + set-node 2drop + ELSE + fdt-debug IF ." Node not found, creating " 2dup type cr THEN + fdt-create-cas-node + THEN + fdt-debug IF ." Current now: " pwd cr THEN + BEGIN + fdt-next-tag dup OF_DT_END_NODE <> + WHILE + dup OF_DT_PROP = IF + fdt-debug IF ." Found property " cr THEN + drop dup ( drop tag, dup addr : a1 a1 ) + dup l@ dup rot 4 + ( fetch size, stack is : a1 s s a2) + dup l@ swap 4 + ( fetch nameid, stack is : a1 s s i a3 ) + rot ( we now have: a1 s i a3 s ) + fdt-encode-prop rot ( a1 s pa ps i) + fdt-fetch-string ( a1 s pa ps na ns ) + property + fdt-debug IF ." Setting property done " cr THEN + + 8 + 3 + fffffffc and + ELSE dup OF_DT_BEGIN_NODE = IF + drop ( drop tag ) + 4 - + fdt-fix-cas-node + get-parent set-node + fdt-debug IF ." Returning back " pwd cr THEN + ELSE + ." Error " cr + drop + false to fdt-cas-fix? + EXIT + THEN + THEN + REPEAT + drop \ drop tag +; + +: fdt-fix-cas-success + fdt-cas-fix? +; + +: fdt-doit + \ Bail out if no fdt + fdt-start 0 = IF + ." No fdt-start" cr + -1 throw + THEN + fdt-start fdt-init + fdt-check-header + fdt-unflatten-tree + fdt-parse-memory + fdt-claim-reserve + s" /" find-node fdt-fix-phandles +;

3 4

Re: [Qemu-ppc] ATY 'NDRV'
by Jd Lyons 21 Jul '19

21 Jul '19

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 21 Jul '19

21 Jul '19

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 20 Jul '19

20 Jul '19

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 20 Jul '19

20 Jul '19

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 19 Jul '19

19 Jul '19

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 13 Jul '19

13 Jul '19

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 04 Jul '19

04 Jul '19

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

[PATCH 0/2] SPARC32: fix crash when starting qemu-system-sparc with no framebuffer
by Mark Cave-Ayland 28 Jun '19

28 Jun '19

A recent patch to QEMU that allows sun4m machines to be launched with -vga none revealed a crash on startup due to the missing framebuffer. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): sbus: don't use internal fallback TCX driver with QEMU SPARC32: use serial console when QEMU is launched with -vga none arch/sparc32/init.fs | 7 +++++-- arch/sparc32/openbios.c | 8 ++++++++ drivers/sbus.c | 11 +++++++++++ 3 files changed, 24 insertions(+), 2 deletions(-) -- 2.11.0

2 11

[PATCH] SPARC64: use serial console when QEMU is launched with -vga none
by Mark Cave-Ayland 26 Jun '19

26 Jun '19

If no display device has been installed in the DT e.g. passing -vga none into the QEMU command line then fall back to using the serial console as already occurs when launching QEMU in -nographic mode. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc64/openbios.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index a783c1f..e2f7e59 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -537,10 +537,11 @@ void arch_nvram_get(char *data) uint32_t temp; uint64_t ram_size; uint32_t clock_frequency; - uint16_t machine_id; + uint16_t machine_id, nographic; const char *stdin_path, *stdout_path; char *bootorder_file, *boot_path; uint32_t bootorder_sz, sz; + phandle_t display_ph; fw_cfg_init(); @@ -701,7 +702,15 @@ void arch_nvram_get(char *data) push_str("/chosen"); fword("find-device"); - if (fw_cfg_read_i16(FW_CFG_NOGRAPHIC)) { + nographic = fw_cfg_read_i16(FW_CFG_NOGRAPHIC); + + /* Check to see if any framebuffer present */ + display_ph = dt_iterate_type(0, "display"); + if (display_ph == 0) { + nographic = 1; + } + + if (nographic) { stdin_path = stdout_path = "ttya"; } else { stdin_path = "keyboard"; -- 2.11.0

1 1

Re: Build sparc32 openbios
by Mark Cave-Ayland 17 May '19

17 May '19

On 16/05/2019 08:09, BALARD Arnaud wrote: > Hi Mark, > > > I finally build my bios for SS20 and finish to install my solaris 7 + soft (with 2 cpu of 170Mhz). > > That's works great ! I just have two question if you can have a time : > > - I can't add more than 512M of RAM, I have qemu fatal trap when I try it. > - My screen are limited to the TCX model, when I try to use CG3 with args -"g 1152x900" I get "stopping execution" > > > Thanks you for all your answers, I would never have succeeded without your help ! Hi Arnaud, Excellent news! I see from Wikipedia that the SS-20 would only support a maximum of 512M RAM anyhow, but it seems qemu-system-sparc doesn't detect this correctly as the maximum address doesn't look right. For the moment I'd simply say "don't do that" and I'll try and find out a way to have qemu-system-sparc fail on a more friendly way. Also note that that target/sparc is not MTTNG enabled so your 2 vCPUs are currently running on just 1 physical CPU. It's something on my TODO list to look at but fairly low priority right now. As for CG3 due to memory constraints in OpenBIOS you can only run it at a maximum of 1024x768 unless you have a real Sun PROM and a CG3 FCode ROM which will allow it to run at the higher 1152x900 resolution. ATB, Mark.

1 0

Build sparc32 openbios
by BALARD Arnaud 03 Mar '19

03 Mar '19

Hi, Openbios ! I try to build a bios sparc32 for qemu. I use the script "./config/scripts/switch-arch sparc32" Initializing build tree ok Creating taget config.mak ok Creating taget rules.mak ok Creating config files ok When I do the "make build-verbose" I get the following error : "PATH/openbios/arch/sparc32/context.c: In function 'switch_to': "PATH/openbios/arch/sparc32/context.c:116:5: error: PIC register clobbered by 'l7' in 'asm' Asm_volatile_("\n\tcall_switch_context" ^~~ Rules.mak:219 « target/arch/sparc32/context.o » failed Make[1]: *** [target/arch/sparc32/context.o error 1 Makefile:32 target "subdir-sparc32" failed Make: *** [subdir-sparc32] error 2 I was try to build ppc and sparc64, that's ok, I can boot on my ppc's bios (not on sparc64, I think I need to do another thing). Do you know what I'm doing wrong for sparc 32 ? Thanks, Libre (C=0) Interne (C=1) Restreint (C=2) Confidentiel (C=3) X [X] Arnaud BALARD Chargé d'Exploitation et d'Affaires EDF - DPNT - DAIP - UNITEP AEI - Groupe SIMU UFPI Bugey CD 20 - BP 70130 01155 LAGNIEU arnaud.balard(a)edf.fr Tél. : 04 37 63 62 72 Un geste simple pour l'environnement, n'imprimez ce message que si vous en avez l'utilité. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

3 4

[PATCH v2 0/5] SPARC32/SPARC64: allocate and map both kernel and initrd memory
by Mark Cave-Ayland 15 Feb '19

15 Feb '19

Bootloaders such as SILO will have already allocated and mapped the memory for the kernel and initrd before jumping into the kernel, so this patchset does the same for a kernel/initrd loaded directly by QEMU. Otherwise if the kernel/initrd grow beyond the default 1:1 memory region mapped by the PROM then the kernel will panic when clearing the memory on startup. In order for this to work on SPARC32 then the corresponding QEMU patch at https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06635.html must also be applied. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Add missing PAGE_ALIGN() macro around the ofmem_map() size parameter Mark Cave-Ayland (5): SPARC32: fix obp_arg.argv when no kernel command line specified SPARC32: mark kernel memory as mapped SPARC32: mark initrd memory as mapped and in use before booting kernel SPARC64: mark kernel memory as mapped and in use before booting kernel SPARC64: mark initrd memory as mapped and in use before booting kernel arch/sparc32/boot.c | 2 ++ arch/sparc32/openbios.c | 29 ++++++++++++++++++++--------- arch/sparc64/boot.c | 2 ++ arch/sparc64/boot.h | 2 ++ arch/sparc64/openbios.c | 18 +++++++++++++++++- include/drivers/drivers.h | 2 ++ 6 files changed, 45 insertions(+), 10 deletions(-) -- 2.11.0

1 6

[PATCH 0/5] SPARC32/SPARC64: allocate and map both kernel and initrd memory
by Mark Cave-Ayland 01 Feb '19

01 Feb '19

Bootloaders such as SILO will have already allocated and mapped the memory for the kernel and initrd before jumping into the kernel, so this patchset does the same for a kernel/initrd loaded directly by QEMU. Otherwise if the kernel/initrd grow beyond the default 1:1 memory region mapped by the PROM then the kernel will panic when clearing the memory on startup. In order for this to work on SPARC32 then the corresponding QEMU patch at https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06635.html must also be applied. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (5): SPARC32: fix obp_arg.argv when no kernel command line specified SPARC32: mark kernel memory as mapped SPARC32: mark initrd memory as mapped and in use before booting kernel SPARC64: mark kernel memory as mapped and in use before booting kernel SPARC64: mark initrd memory as mapped and in use before booting kernel arch/sparc32/boot.c | 2 ++ arch/sparc32/openbios.c | 29 ++++++++++++++++++++--------- arch/sparc64/boot.c | 2 ++ arch/sparc64/boot.h | 2 ++ arch/sparc64/openbios.c | 18 +++++++++++++++++- include/drivers/drivers.h | 2 ++ 6 files changed, 45 insertions(+), 10 deletions(-) -- 2.11.0

1 5

[PATCH] SPARC32: divide physical memory reg property into physical SIMM sized ranges
by Mark Cave-Ayland 25 Jan '19

25 Jan '19

Currently the /memory node reg property is set to a single range encompassing the entire physical RAM of the machine. This seems to cause issues with Solaris when booting on QEMU SS-10 and SS-20 machines whereby having just a single entry causes the top of physical memory to be calculated incorrectly and triggers a panic on boot. Instead copy the behaviour of OBP which is to divide the reg property into a set of ranges representing the physical SIMM arrangement in the machine, which fixes the error and allows Solaris to boot under the QEMU SS-10 and SS-20 machines. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc32/boot.h | 2 +- arch/sparc32/lib.c | 14 +++++++++----- arch/sparc32/openbios.c | 6 +++++- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/arch/sparc32/boot.h b/arch/sparc32/boot.h index e372acc..366e0f6 100644 --- a/arch/sparc32/boot.h +++ b/arch/sparc32/boot.h @@ -33,5 +33,5 @@ extern struct linux_mlist_v0 *ptphys; extern struct linux_mlist_v0 *ptmap; extern struct linux_mlist_v0 *ptavail; -void ob_init_mmu(void); +void ob_init_mmu(uint32_t simm_size); void init_mmu_swift(void); diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c index e88c0bf..727929c 100644 --- a/arch/sparc32/lib.c +++ b/arch/sparc32/lib.c @@ -294,12 +294,13 @@ static void ignore_dfault_addr(void) } void -ob_init_mmu(void) +ob_init_mmu(uint32_t simm_size) { ucell *memreg; ucell *virtreg; phys_addr_t virtregsize; ofmem_t *ofmem = ofmem_arch_get_private(); + int i, c; /* Find the phandles for the /memory and /virtual-memory nodes */ push_str("/memory"); @@ -315,14 +316,17 @@ ob_init_mmu(void) ofmem_register(s_phandle_memory, s_phandle_mmu); /* Setup /memory:reg (totphys) property */ - memreg = malloc(3 * sizeof(ucell)); - ofmem_arch_encode_physaddr(memreg, 0); /* physical base */ - memreg[2] = (ucell)ofmem->ramsize; /* size */ + c = ofmem->ramsize / simm_size; + memreg = malloc(3 * c * sizeof(ucell)); + for (i = 0; i < c; i++) { + ofmem_arch_encode_physaddr(&memreg[i * 3], simm_size * i); /* physical base */ + memreg[i * 3 + 2] = simm_size; /* size */ + } push_str("/memory"); fword("find-device"); PUSH(pointer2cell(memreg)); - PUSH(3 * sizeof(ucell)); + PUSH(3 * c * sizeof(ucell)); push_str("reg"); PUSH_ph(s_phandle_memory); fword("encode-property"); diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 3ec8fd7..17a6550 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -42,6 +42,7 @@ struct hwdef { unsigned long aux1_offset, aux2_offset; uint64_t dma_base, esp_base, le_base; uint64_t tcx_base; + uint32_t simm_size; int intr_ncpu; int mid_offset; int machine_id_low, machine_id_high; @@ -65,6 +66,7 @@ static const struct hwdef hwdefs[] = { .dma_base = 0x78400000, .esp_base = 0x78800000, .le_base = 0x78c00000, + .simm_size = 0x2000000, .mid_offset = 0, .machine_id_low = 32, .machine_id_high = 63, @@ -86,6 +88,7 @@ static const struct hwdef hwdefs[] = { .dma_base = 0xef0400000ULL, .esp_base = 0xef0800000ULL, .le_base = 0xef0c00000ULL, + .simm_size = 0x4000000, .mid_offset = 8, .machine_id_low = 64, .machine_id_high = 65, @@ -107,6 +110,7 @@ static const struct hwdef hwdefs[] = { .dma_base = 0xef0081000ULL, .esp_base = 0xef0080000ULL, .le_base = 0xef0060000ULL, + .simm_size = 0x4000000, .mid_offset = 8, .machine_id_low = 66, .machine_id_high = 66, @@ -874,7 +878,7 @@ arch_init( void ) openbios_init(); modules_init(); - ob_init_mmu(); + ob_init_mmu(hwdef->simm_size); ob_init_iommu(hwdef->iommu_base); bind_func("(sparc32-dma-alloc)", dma_alloc); -- 2.11.0

1 1

Qemu 3.1.0 Sparc still does'nt boot Solaris 8 for SS-20
by Ulrich Gräpel 01 Jan '19

01 Jan '19

Just gave the latest Qemu a try to boot an emulated SparcStation 20 from the original Solaris install CD: /opt/qemu-3.1.0/sparc-softmmu/qemu-system-sparc \ -M SS-20 -m 256 \ -nographic \ -monitor telnet::3001,server,nowait \ -cdrom /mnt/iso/sol-8-hw4-install-sparc32.iso \ -boot d The resulting output: Configuration device id QEMU version 1 machine id 65 Probing SBus slot 0 offset 0 Probing SBus slot 1 offset 0 Probing SBus slot 2 offset 0 Probing SBus slot 3 offset 0 Probing SBus slot 15 offset 0 Invalid FCode start byte CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.1 built on Oct 5 2018 08:20 Type 'help' for detailed information Trying cdrom:d... Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f ,800000/sd@2,0:d switching to new context: SunOS Release 5.8 Version Generic_108528-29 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. \ panic[cpu0]/thread=f0244020: BAD TRAP: type=9 (Data fault) rp=f0243624 addr=0 mmu_fsr=126 rw=1 occurred in module "unix" due to a NULL pointer dereference qemu: fatal: Trap 0x29 while interrupts disabled, Error state pc: f0163298 npc: f016329c %g0-7: 00000000 f00c220c 3024a52c f024fe14 4000020d f0243b88 00000000 f0244020 %o0-7: 00001fff 00001000 00001000 f5c89000 00000000 f5918240 f02500a0 f0074d94 %l0-7: fbcf4834 f013cc18 00000001 f026eb30 f5917c60 f02727e0 f5917c40 00001010 %i0-7: f5c89000 00001000 00000001 00000000 00000000 f5917c68 f0250100 f013d4a4 %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 psr: 40000fc5 (icc: ---- SPE: SP-) wim: 00000020fsr: 00000000 y: 00000000 Everything works fine though, if configured for the default SparcStation 5 (SS-5). I also tried other machine types: The only working configuration is the SS-5. I guess there is some issue with the device tree.

3 3

openbios support for netboot? (qemu-system-sparc32/solaris)
by Joe Dery 22 Dec '18

22 Dec '18

Intrepid openBIOS developers, Though not new news, thank you for providing an openBIOS that is able to boot solaris in qemu-system-sparc32! While I am able to disk boot (with qcow2 image containing ufs filesystems), but would prefer to serve as much of my guest filesystem from NFS as possible. Netboot allows a 'diskless' system, so that is the most extreme case, but I'm open to other suggestions. Does OpenBIOS 1.1 (eg the snapshot attached to QEMU GIT HEAD as of last Friday) support boot net:rarp, boot net:dhcp, or any other more manual method of providing the kernel&parameters? I haven't been able to find this in the documentation or code so I imagine it does not. PS - FWIW this is the command line I am presently using for a 'disk0' boot. Note that the tftp/bootfile do not do anything, but I included them as an example based on the other qemu documentation. qemu/sparc-softmmu/qemu-system-sparc \ -net nic,macaddr=00:03:BA:04:A5:AD -net user,hostfwd=tcp::8023-:23,hostfwd=tcp::5911-:5911,tftp=/tftpboot,bootfile=inetboot.sun4m \ -hda sol8_36G.disk.install \ -nographic -serial telnet:0.0.0.0:3000,server \ -m 256 PPS Mark Cave-Ayland, it appears you're active on this list. Thanks again for your help (now years ago!) fixing the MUTEX_HELD & related problems in 2.6.... the current GIT still runs clean. I have not really worked with QEMU since ~2.6, around that time I picked up a SunBlade 1000, which is supported by the old kernel I need, and is able to run the (mostly CC compile) workloads an order of magnitude faster. QEMU remains interesting for applications requiring less performance, e.g. lmgrd license server.

2 1

SVN to github migration
by BALATON Zoltan 09 Dec '18

09 Dec '18

Hello, The links on the pages https://www.openfirmware.org/Open_Firmware https://www.openfirmware.org/SmartFirmware https://www.openfirmware.org/OpenBOOT seem to be broken since the SVN to github migration. I think these are now at https://github.com/openbios but the above pages should also be updated to point to there instead. Thank you, BALATON Zoltan

2 1

Need help : sparc64 ULTRA5 under Solaris 7 64 bits
by BALARD Arnaud 07 Dec '18

07 Dec '18

Bonjour, je vous envoie un mail car j'essaie de virtualiser une machine ULTRA5 sous solaris 7 en 64 bits. j'ai réussi à démarrer sur un cd solaris 7 32bits pour restaurer les partitions sur mon disque virtuel (ufsrestore). Quand j'essaie de démarrer avec qemu-system-sparc64 j'obtiens l'erreur "no valid state has been set by load or init-program" dans le prompt qemu "Not linux kernel image, Not a bootable ELF image, Not a bootable a.out image, Not a bootable FCode image" au bout d'un certain nombre de test ma dernière commande ressemble à ca : sparc64-softmmu#./qemu-system-sparc64 -M sun4u -bios /usr/local/share/qemu/openbios-sparc64 -m 256 -drive file=/home/qemu/QEMU_SRV/SRV.qcow2 -prom-env "auto-boot?=flase" Je vois bien mon disque présent sur /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 est-t 'il possible de virtualiser une machine ultra5 sous solaris 7 64bits ? La barrière de ma machine réel ressemble à ca : Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz),OpenBoot 3.25 256 MB.... J'ai entendu parler de ce patch : https://patchwork.kernel.org/patch/9175879/ ou est-ce qu'il y a une configuration à faire dans sparc64-softmmu ? Je ne sais pas si il peut m'aider à trouver mon bonheur. Dans l'attente de votre réponse, merci. **************************************************************************************************************************************************************** Hello, I send you an email because I try to virtualize an ULTRA5 machine under solaris 7 in 64 bits. I managed to boot on a cd solaris 7 32bits to restore the partitions on my virtual disk (ufsrestore). When I try to start with qemu-system-sparc64 I get the error "no valid state has been set by load or init-program" in the qemu prompt "Not linux kernel image, Not a bootable ELF image, Not a bootable a.out image, Not a bootable Image mode " after a certain number of tests my last command looks like this: sparc64-softmmu#./qemu-system-sparc64 -M sun4u -bios /usr/local/share/qemu/openbios-sparc64 -m 256 -drive file=/home/qemu/QEMU_SRV/SRV.qcow2 -prom-env "auto-boot? = flase" I can see my disk present on /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 is it possible to virtualize an ultra5 machine under solaris 7 64bits? The barrier of my real machine looks like this: Sun Ultra 5/10 UPA / PCI (UltraSPARC-IIi 400MHz), OpenBoot 3.25 256 MB .... I heard about this patch: https://patchwork.kernel.org/patch/9175879/ or is there a configuration to do in sparc64-softmmu? I do not know if he can help me find my happiness. Looking forward to your reply, thank you. Libre (C=0) Interne (C=1) Restreint (C=2) Confidentiel (C=3) X [X] Arnaud BALARD Chargé d'Exploitation et d'Affaires EDF - DPNT - DAIP - UNITEP AEI - Groupe SIMU UFPI Bugey CD 20 - BP 70130 01155 LAGNIEU arnaud.balard(a)edf.fr Tél. : 04 37 63 62 72 Un geste simple pour l'environnement, n'imprimez ce message que si vous en avez l'utilité. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

2 1

[PATCH 0/4] Add virtio-blk driver support
by Mark Cave-Ayland 18 Oct '18

18 Oct '18

These patches add support for booting from virtio-blk (PCI) devices as used by QEMU. Patches 1 and 2 add bootindex support which is the new way for passing boot order information from QEMU to OpenBIOS. Note that there are also corresponding patches for QEMU required, without which the generated device paths will be incorrect and cause virtio boot to fail. Patch 3 adds the legacy virtio-blk driver (it follows the 0.9 rather than the 1.0 specification). Patch 4 enables the new driver for both PPC and SPARC64 architectures so that virtio-blk devices will be usable out-of-the-box with QEMU. Once these patches have been applied to OpenBIOS (along with the corresponding fw path fixes for QEMU) it is possible to boot from virtio-blk devices like this: PPC: ./qemu-system-ppc -drive file=debian-9.0-powerpc-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,drive=cd,bootindex=0 -m 256 -boot d SPARC: ./qemu-system-sparc64 -drive debian-9.0-sparc64-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,bus=pciB,drive=cd,bootindex=0 -m 256 -boot d -nographic Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (4): ppc: add bootindex support SPARC64: add bootindex support drivers: add legacy virtio-blk driver config: enable virtio-blk driver for default PPC and SPARC64 builds arch/ppc/qemu/init.c | 55 ++++- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 2 +- arch/sparc64/openbios.c | 38 +++- config/examples/ppc_config.xml | 1 + config/examples/sparc64_config.xml | 1 + drivers/build.xml | 1 + drivers/pci.c | 18 ++ drivers/pci_database.c | 4 +- drivers/pci_database.h | 1 + drivers/virtio.c | 424 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 331 +++++++++++++++++++++++++++++ include/drivers/drivers.h | 4 + 13 files changed, 862 insertions(+), 20 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

3 8

Ppc guest debugging?
by Jd Lyons 14 Oct '18

14 Oct '18

I need to try and debug the macOS trampoline inits during the early boot process of OS 9. I’m thinking Qemu supports this, but I’m unsure how to set it up? I installed gdb-multiarch and started qemu with: Qemu-system-ppc -s -S The launched gdb-multiarch and connected to port 1234. Is this the correct toolchain for debugging PPC code on an X86 host, or do I need to do something else?

3 11

[PATCH 0/2] 40p: update interrupt routing and model name
by Mark Cave-Ayland 05 Oct '18

05 Oct '18

These patches update OpenBIOS to match the lastest 40p changes merged into QEMU and allow the Linux sandalfoot zImage to boot all the way to userspace. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): 40p: update interrupt routing code to match QEMU 40p: change residual data model name to IBM PPS Model 6015 arch/ppc/qemu/context.c | 2 +- arch/ppc/qemu/init.c | 2 +- drivers/pci.c | 24 ++++++++++++++++++++---- 3 files changed, 22 insertions(+), 6 deletions(-) -- 2.11.0

2 7

[PATCH] prep: change residual data model name to IBM PPS Model 6015
by Mark Cave-Ayland 10 Sep '18

10 Sep '18

With the corresponding QEMU patches applied, it is now possible to change the reported firmware name to that of a real 40p machine and boot to a working userspace with the Linux sandalfoot zImage. Note that whilst guest OSs should be relying on residual data rather than the OF device tree to determine the hardware, we still update the interrupt properties to match the new code in QEMU for consistency. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/context.c | 2 +- drivers/pci.c | 24 ++++++++++++++++++++---- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/arch/ppc/qemu/context.c b/arch/ppc/qemu/context.c index 06e0122..5815895 100644 --- a/arch/ppc/qemu/context.c +++ b/arch/ppc/qemu/context.c @@ -111,7 +111,7 @@ static void * residual_build(uint32_t memsize, uint32_t load_base, uint32_t load_size) { residual_t *res; - const unsigned char model[] = "Qemu\0PPC\0"; + const unsigned char model[] = "IBM PPS Model 6015\0"; int i; res = malloc(sizeof(residual_t)); diff --git a/drivers/pci.c b/drivers/pci.c index 8f97ae1..df6d9d0 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1986,10 +1986,26 @@ static phandle_t ob_pci_host_set_interrupt_map(phandle_t host) static void ob_pci_host_bus_interrupt(ucell dnode, u32 *props, int *ncells, u32 addr, u32 intno) { *ncells += pci_encode_phys_addr(props + *ncells, 0, 0, addr, 0, 0); - props[(*ncells)++] = intno; - props[(*ncells)++] = dnode; - props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3]; - props[(*ncells)++] = 1; + + if (is_oldworld() || is_newworld()) { + /* Mac machines */ + props[(*ncells)++] = intno; + props[(*ncells)++] = dnode; + props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3]; + props[(*ncells)++] = 1; + } else { + /* PReP machines */ + props[(*ncells)++] = intno; + props[(*ncells)++] = dnode; + + if (PCI_DEV(addr) == 1 && PCI_FN(addr) == 0) { + /* LSI SCSI has fixed routing */ + props[(*ncells)++] = 2; + } else { + props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 1]; + } + props[(*ncells)++] = 1; + } } #elif defined(CONFIG_SPARC64) -- 2.11.0

2 2

[PATCH 0/2] 40p minor fixes
by Mark Cave-Ayland 31 Aug '18

31 Aug '18

Here are a couple of 40p fixes I noticed whilst debugging the interrupt routing in QEMU's 40p PReP machine. Note that the IRQ changes in patch 2 are dependent upon my fix for the 40p PCI IRQ routing posted at https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg05705.html. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): 40p: fix up generation of interrupt properties 40p: update PReP configuration to match 40p machine arch/ppc/qemu/init.c | 4 ++-- drivers/pci.c | 15 +++++++-------- 2 files changed, 9 insertions(+), 10 deletions(-) -- 2.11.0

3 6

[PATCH v3 0/4] Add virtio-blk driver support
by Mark Cave-Ayland 31 Aug '18

31 Aug '18

These patches add support for booting from virtio-blk (PCI) devices as used by QEMU. Patches 1 and 2 add bootindex support which is the new way for passing boot order information from QEMU to OpenBIOS. Note that there are also corresponding patches for QEMU required, without which the generated device paths will be incorrect and cause virtio boot to fail. Patch 3 adds the virtio-1.0 compliant virtio-blk PCI driver. Patch 4 enables the new driver for both PPC and SPARC64 architectures so that virtio-blk-pci devices will be usable out-of-the-box with QEMU. Once these patches have been applied to OpenBIOS (along with the corresponding fw path fixes for QEMU) it is possible to boot from virtio-blk-pci devices like this: PPC: ./qemu-system-ppc -drive file=debian-9.0-powerpc-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,drive=cd,bootindex=0 -m 256 -boot d SPARC: ./qemu-system-sparc64 -drive debian-9.0-sparc64-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,bus=pciB,drive=cd,bootindex=0 -m 256 -boot d -nographic Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v3: - Rebase onto master - Convert from legacy driver to virtio-1.0 driver v2: - Switch over to using dma-* words to allocate rings and descriptors - Fix up some minor whitespace issues Mark Cave-Ayland (4): ppc: add bootindex support SPARC64: add bootindex support drivers: add virtio-1.0 virtio-blk driver config: enable virtio-blk driver for default PPC and SPARC64 builds arch/ppc/qemu/init.c | 55 +++- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 2 +- arch/sparc64/openbios.c | 38 ++- config/examples/ppc_config.xml | 1 + config/examples/sparc64_config.xml | 1 + drivers/build.xml | 1 + drivers/pci.c | 63 +++++ drivers/pci_database.c | 14 +- drivers/pci_database.h | 1 + drivers/virtio.c | 555 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 370 +++++++++++++++++++++++++ include/drivers/drivers.h | 5 + include/drivers/pci.h | 6 + 14 files changed, 1093 insertions(+), 21 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

1 5

[PATCH] ppc: make sure that we correctly map loader RAM at load-base
by Mark Cave-Ayland 31 Aug '18

31 Aug '18

An error in the logic related to FREE_BASE meant that instead of mapping the RAM for the loader at load-base, a small section was being mapped at the bottom of RAM instead. Fix this by deferring the mapping of the load-base RAM to arch_init() when we can access the load-base variable and map 8MB RAM with a 1:1 phys to virt mapping. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/init.c | 8 ++++++++ arch/ppc/qemu/ofmem.c | 12 ------------ 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index af15682..f5acf87 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -844,6 +844,7 @@ arch_of_init(void) uint32_t temp = 0; char *boot_device; ofmem_t *ofmem = ofmem_arch_get_private(); + ucell load_base; openbios_init(); modules_init(); @@ -1105,4 +1106,11 @@ arch_of_init(void) bind_func("platform-boot", boot); bind_func("(arch-go)", arch_go); + + /* Allocate 8MB memory at load-base */ + fword("load-base"); + load_base = POP(); + ofmem_claim_phys(load_base, 0x800000, 0); + ofmem_claim_virt(load_base, 0x800000, 0); + ofmem_map(load_base, load_base, 0x800000, 0); } diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 7b8ced0..7a78a1e 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -46,7 +46,6 @@ extern void setup_mmu(unsigned long code_base); * */ -#define FREE_BASE 0x00004000UL #define OF_CODE_START 0xfff00000UL #define OF_CODE_SIZE 0x00100000 #define IO_BASE 0x80000000UL @@ -81,12 +80,6 @@ get_ram_top(void) return get_hash_base() - (32 + 64 + 64) * 1024 - OFMEM_SIZE; } -static unsigned long -get_ram_bottom(void) -{ - return FREE_BASE; -} - static unsigned long get_heap_top(void) { return get_hash_base() - (32 + 64 + 64) * 1024; @@ -578,11 +571,6 @@ ofmem_init(void) { ofmem_t *ofmem = ofmem_arch_get_private(); - /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ - ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - /* Mark the first page as non-free */ ofmem_claim_phys(0, PAGE_SIZE, 0); ofmem_claim_virt(0, PAGE_SIZE, 0); -- 2.11.0

1 3

[PATCH] SPARC64: fix up dma-* words
by Mark Cave-Ayland 26 Aug '18

26 Aug '18

Commit 8584d42 "SPARC64: implement dma-* words" introduced the dma-* words for SPARC64 but accidentally introduced an older prototype implementation (probably introduced during a rebase) rather than using the correct defer words. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc64/tree.fs | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index a1d5620..af8948d 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -52,26 +52,23 @@ include config.fs : decode-unit decode-unit-upa ; : dma-sync ( virt devaddr size -- ) - s" (dma-sync)" $find if execute then + (dma-sync) ; : dma-alloc ( size -- virt ) - \ OpenBIOS doesn't enable the sun4u IOMMU so we can fall back to using - \ alloc-mem - h# 2000 + alloc-mem dup - h# 2000 1 - and - \ align to 8K page size + (dma-alloc) ; : dma-free ( virt size -- ) - 2drop + (dma-free) ; : dma-map-in ( virt size cacheable? -- devaddr ) - 2drop + (dma-map-in) ; : dma-map-out ( virt devaddr size -- ) - dma-sync + (dma-map-out) ; new-device -- 2.11.0

1 1

[PATCH] ppc: move init-program client stack to 1:1 virt to phys mapped memory
by Mark Cave-Ayland 26 Aug '18

26 Aug '18

The default context used by init-program is allocated from the OpenBIOS heap which uses a different virt to phys mapping to avoid having to physically relocate the PROM on startup for PPC machines. It seems that the OpenBSD bootloader isn't happy with this change introduced by the context rework, most likely because there is an assumption that the client stack is mapped 1:1 virt to phys. Fix this by overriding the default context stack during init-program to a location just under the MMU hash table (SDR1) which was its previous hard-coded location in 1:1 virt to phys mapped memory, and allow OpenBSD to boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/context.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/ppc/qemu/context.c b/arch/ppc/qemu/context.c index 03ca173..06e0122 100644 --- a/arch/ppc/qemu/context.c +++ b/arch/ppc/qemu/context.c @@ -16,6 +16,7 @@ #include "libopenbios/ofmem.h" #include "libopenbios/initprogram.h" #include "libopenbios/sys_info.h" +#include "arch/ppc/processor.h" #define MAIN_STACK_SIZE 16384 #define IMAGE_STACK_SIZE 4096*2 @@ -232,6 +233,14 @@ arch_init_program(void) ctx->regs[REG_R6] = 0; ctx->regs[REG_R7] = 0; + /* Override the stack in the default context: the OpenBSD bootloader + fails soon after setting up virt to phys mappings with the default + stack. My best guess is that this is because the malloc() heap + doesn't have a 1:1 virt to phys mapping. So for the moment we use + the original (pre-context) location just under the MMU hash table + (SDR1) which is mapped 1:1 and makes the bootloader happy. */ + ctx->sp = mfsdr1() - 32768 - 65536; + /* Set param */ feval("load-state >ls.param @"); param = POP(); -- 2.11.0

1 1

[PATCH v2 0/4] Add virtio-blk driver support
by Mark Cave-Ayland 19 Aug '18

19 Aug '18

These patches add support for booting from virtio-blk (PCI) devices as used by QEMU. Patches 1 and 2 add bootindex support which is the new way for passing boot order information from QEMU to OpenBIOS. Note that there are also corresponding patches for QEMU required, without which the generated device paths will be incorrect and cause virtio boot to fail. Patch 3 adds the legacy virtio-blk driver (it follows the 0.9 rather than the 1.0 specification). Patch 4 enables the new driver for both PPC and SPARC64 architectures so that virtio-blk devices will be usable out-of-the-box with QEMU. Once these patches have been applied to OpenBIOS (along with the corresponding fw path fixes for QEMU) it is possible to boot from virtio-blk devices like this: PPC: ./qemu-system-ppc -drive file=debian-9.0-powerpc-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,drive=cd,bootindex=0 -m 256 -boot d SPARC: ./qemu-system-sparc64 -drive debian-9.0-sparc64-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,bus=pciB,drive=cd,bootindex=0 -m 256 -boot d -nographic Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Switch over to using dma-* words to allocate rings and descriptors - Fix up some minor whitespace issues Mark Cave-Ayland (4): ppc: add bootindex support SPARC64: add bootindex support drivers: add legacy virtio-blk driver config: enable virtio-blk driver for default PPC and SPARC64 builds arch/ppc/qemu/init.c | 55 +++- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 2 +- arch/sparc64/openbios.c | 38 ++- config/examples/ppc_config.xml | 1 + config/examples/sparc64_config.xml | 1 + drivers/build.xml | 1 + drivers/pci.c | 18 ++ drivers/pci_database.c | 4 +- drivers/pci_database.h | 1 + drivers/virtio.c | 516 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 330 ++++++++++++++++++++++++ include/drivers/drivers.h | 4 + 13 files changed, 953 insertions(+), 20 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

1 4

[PATCH 0/3] Miscellaneous fixes
by Mark Cave-Ayland 18 Aug '18

18 Aug '18

Here is a set of fixes discovered during my work on adding virtio-blk support to OpenBIOS. Patch 1 changes the way in which the IDE controller DT nodes are generated so that they use the controller index as the address, and not the value programmed in the PCI BAR. Otherwise it is impossible for QEMU to determine the fw path for IDE boot devices, since the PCI BARs are programmed after the machine has been initialised. Patches 2 and 3 contain fixes for bugs that were discovered whilst trying to initialise the virtio-blk device for both PPC and SPARC64 architectures. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): ide: don't use ioports as part of the controller node address libopenbios: don't allow find_package_method() to push a NULL for empty strings pci: use absolute PCI IO addresses when programming bridge IO limits config/examples/ppc64_config.xml | 2 +- config/examples/ppc_config.xml | 2 +- drivers/ide.c | 18 ++++++++---------- drivers/pci.c | 2 +- libopenbios/bindings.c | 7 ++++++- 5 files changed, 17 insertions(+), 14 deletions(-) -- 2.11.0

2 6

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Joe van Tunen 14 Jul '18

14 Jul '18

I finally got around to updating my fcode to forth conversion scripts (see attached zip, also at https://www.dropbox.com/s/u2lojlc6vtuphbs/joevtOpen_Firmware_and_Forth.zip?… ). It's a Unix bash shell script which converts a PCI rom (containing fcode) to a forth source file that can be edited and tokenized to a new rom file. The bash script deals with extracting the PCI header and uses detok to extract the fcode. It then calls a perl script to convert the output from detok. It takes a couple minutes to do about 25000 lines. The version of toke and detok are based on older versions with enhancements and bug fixes to correctly handle the roms I've tested them with. The conversion process depends on the formatting (indenting) produced by detok. The generated forth source file has tokenizer commands (used by toke) to more faithfully reproduce the PCI header. These may be specific to my version of toke. To verify the output, do the following: DumpPCIRom the original rom. toke the result to create a new rom. DumpPCIRom the new rom and compare the result with the original. See example commands in joevtNewOFCommands.worksheet {.txt if you don't have BBEdit}). You'll notice the new rom is smaller because toke uses the more compact words for values {-1, 0, 1, 2, 3} instead of just b(lit). You may want to comment out the line "tokenizer[ xxxxx ]tokenizer rom-size" so that the rom size is set automatically (unless you want the size to be the same as the original). I didn't include a preprocessor. I had made one for MPW where you can embed shell commands to modify the forth source file to make it more compact/readable. For example, sections of duplicated code could be replaced by a loop. Large binary properties could be replaced by a command to encode-bytes from a binary file (e.g. for the macOS driver property). Defines and conditional compilation could be used to easily create roms for different purposes (debug or release, different hardware or settings). > On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca> wrote: > > Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code. > > > On 5/6/18, 8:11 AM, "Jd Lyons" <lyons_dj(a)yahoo.com> wrote: > > Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do? > > Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception.

1 0

[PATCH v4] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
by BALATON Zoltan 30 Jun '18

30 Jun '18

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(a)eik.bme.hu> --- v4: Rebased to latest master v3: See: https://mail.coreboot.org/pipermail/openbios/2017-January/009867.html arch/ppc/qemu/init.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index af15682..d362b0e 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,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 -- ) */ @@ -857,6 +899,7 @@ arch_of_init(void) feval("['] ppc-dma-sync to (dma-sync)"); #ifdef CONFIG_DRIVER_PCI + empty_pci_bus_init(); ob_pci_init(); #endif -- 2.7.6

2 4

[PATCH 0/5] mac99 PMU patches
by Mark Cave-Ayland 17 Jun '18

17 Jun '18

Here is a reworked version of Ben's mac99 PMU patches for OpenBIOS along with a minor fix for the keyboard alias. The main difference between Ben's version and this version are that instead of defining a new mac99p machine, the aim is to keep using the existing mac99 machine and then switch it over to use PMU by default once the remaining issues with USB and timers have been fixed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (5): ppc: add fw_cfg interface for passing VIA/ADB configuration from QEMU ppc: add GPIO devices to the device tree when PMU hardware detected adb: set compatible property differently if PMU is present ppc: add PMU driver usbhid: fix up keyboard alias for USB keyboards arch/ppc/qemu/init.c | 28 +- drivers/adb_bus.c | 8 +- drivers/adb_bus.h | 5 + drivers/build.xml | 1 + drivers/macio.c | 80 +++++- drivers/pci.c | 18 ++ drivers/pmu.c | 625 +++++++++++++++++++++++++++++++++++++++++++ drivers/pmu.h | 17 ++ drivers/usbhid.c | 2 +- include/arch/common/fw_cfg.h | 1 + include/drivers/drivers.h | 10 + 11 files changed, 785 insertions(+), 10 deletions(-) create mode 100644 drivers/pmu.c create mode 100644 drivers/pmu.h -- 2.11.0

2 8

[PATCH 00/11] PReP support for QEMU 40p machine
by Mark Cave-Ayland 08 Jun '18

08 Jun '18

The current PReP firmware provided with OpenBIOS is OpenHackWare which provides a basic set of OpenFirmware interfaces but does this without providing any kind of Forth implementation which limits its usefulness and compatibility. Whilst the project has allowed QEMU PReP development to continue to date, it is sadly now abandonware with no patches for over 4 years, and with no-one willing to take on maintenance it is now time for a different approach. This patchset adds PReP support for the QEMU 40p machine allowing it to start booting NetBSD and the sandalfoot Linux zImage. The main features required for this are support for the LSI SCSI controller, resdidual data and PReP boot partitions. In order to test these patches you'll need a recent QEMU with the following patches applied: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05480.html https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05964.html Next you'll need an updated openbios-ppc binary, and for those without access to a cross-compiler setup I've uploaded the resulting binary to https://www.ilande.co.uk/tmp/qemu/openbios-ppc.prep. To boot the sandalfoot zImage from http://www.juneau-lug.org/zImage.initrd.sandalfoot you can do: qemu-system-ppc -M 40p -bios openbios-ppc.prep -cdrom zImage.initrd.sandalfoot -boot d Note that it seems to get stuck trying to initialise the LSI SCSI controller, presumably due to a bug in the existing QEMU emulation. NetBSD works much better and in fact boots all the way to userspace: qemu-system-pcc -M 40p -bios openbios-ppc.prep -cdrom NetBSD-7.1.2-prep.iso -boot d -nographic In terms of functionality I think this patchset is just about there: there are a few questions around device names but hopefully someone with real PReP experience can point me in the right direction. Finally I've added various people on CC who have expressed interest in PReP and/or OpenHackWare in the past: if this is no longer of any interest to you, do let me know and I'll drop your email address from future versions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (11): pc_kbd: ensure that we properly reset the 8042 controller and keyboard device pci: rename i82378 keyboard device from 8042 to keyboard pci: add AMD PCNET information to PCI database bootcode_load: ensure LOADER_NOT_SUPPORT is returned if no bootcode is present ppc: add PReP support to dma-map-in pci: add driver for LSI 53C810 SCSI controller ppc: add PReP residual data block ppc: use proper context when pre-loading kernels pc-parts: allow successful detection of PReP boot partitions libopenbios: add PReP boot partition loader for PPC prep: disable VBE extensions when executing client program arch/ppc/qemu/context.c | 129 ++++++- arch/ppc/qemu/context.h | 1 + arch/ppc/qemu/init.c | 34 ++ arch/ppc/qemu/kernel.h | 1 - arch/ppc/qemu/main.c | 11 +- arch/ppc/qemu/switch.S | 43 --- arch/ppc/qemu/tree.fs | 5 - config/examples/ppc_config.xml | 2 + drivers/build.xml | 1 + drivers/lsi.c | 770 ++++++++++++++++++++++++++++++++++++++++ drivers/pc_kbd.c | 22 +- drivers/pci.c | 21 +- drivers/pci_database.c | 14 + drivers/pci_database.h | 1 + drivers/vga.fs | 11 + forth/debugging/client.fs | 1 + include/arch/ppc/residual.h | 116 ++++++ include/drivers/drivers.h | 4 + include/drivers/pci.h | 6 + include/libopenbios/prep_load.h | 24 ++ libopenbios/bootcode_load.c | 2 + libopenbios/build.xml | 1 + libopenbios/initprogram.c | 8 + libopenbios/load.c | 11 + libopenbios/prep_load.c | 106 ++++++ packages/pc-parts.c | 10 + 26 files changed, 1300 insertions(+), 55 deletions(-) create mode 100644 drivers/lsi.c create mode 100644 include/arch/ppc/residual.h create mode 100644 include/libopenbios/prep_load.h create mode 100644 libopenbios/prep_load.c -- 2.11.0

2 14

[PATCH 00/15] Implement dma-* words
by Mark Cave-Ayland 26 May '18

26 May '18

This patchset is something I've been working on for a while and started off with the aim of getting rid of the "dma-alloc" console warnings whilst booting *BSD images on PPC, but ended up as a full implementation for SPARC32/SPARC64 and PPC. The patchset is fairly straightfoward: the first few patches rework the SPARC32 DVMA functions to make them usable from Forth, whilst patch 8 adds a missing D-cache flush for PPC which could certainly do with another set of eyes. The remainder of the patches add PPC and SPARC64 support before adding in the complete "dma-*" $call-parent chains to enable devices to call the DMA functions as indicated in the IEEE-1275 specification and various FCode examples found around the net. Finally the last 2 patches switch the esp SCSI driver over to use the IEEE-1275 Forth words instead of calling the low-level C functions directly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (15): dma: add defers for the dma-* words SPARC32: rename dvma_alloc()'s ba variable to iova SPARC32: allocate contiguous physical memory for DVMA SPARC32: implement dvma_map_in() for DMA IOVA to phys translation SPARC32: move pgtsrmmu.h from arch/sparc32 to include/arch/sparc32 SPARC32: implement dvma_sync() function for synchronising DMA memory SPARC32: implement dma-* words PPC: add flush_dcache_range() to start.S PPC: implement dma-* words SPARC64: implement dma-* words macio: add missing REGISTER_NODE for New World macio devices pci: add dma-* call-parent chain to all PCI devices and bridges sbus: add dma-* call-parent chain to all PCI devices and bridges esp: switch creation of esp device over to use new-device esp: switch over to using dma-alloc/dma-map-in arch/ppc/qemu/init.c | 35 +++++++ arch/ppc/qemu/kernel.h | 1 + arch/ppc/qemu/start.S | 21 ++++ arch/ppc/qemu/tree.fs | 40 ++++++++ arch/sparc32/lib.c | 2 +- arch/sparc32/ofmem_sparc32.c | 2 +- arch/sparc32/openbios.c | 47 ++++++++- arch/sparc32/tree.fs | 56 +++++++++++ arch/sparc64/openbios.c | 40 ++++++++ arch/sparc64/tree.fs | 47 +++++++++ drivers/esp.c | 159 ++++++++++++++++++++---------- drivers/ide.c | 40 ++++++++ drivers/iommu.c | 95 +++++++++++++++--- drivers/macio.c | 36 +++++++ drivers/pci.c | 40 ++++++++ forth/device/other.fs | 8 +- forth/device/table.fs | 2 +- forth/util/util.fs | 9 ++ {arch => include/arch}/sparc32/pgtsrmmu.h | 0 include/drivers/drivers.h | 4 +- packages/disk-label.fs | 39 ++++++++ 21 files changed, 646 insertions(+), 77 deletions(-) rename {arch => include/arch}/sparc32/pgtsrmmu.h (100%) -- 2.11.0

1 16

[PATCH] pci: fix OHCI driver PCI address
by Mark Cave-Ayland 22 May '18

22 May '18

Commit a1c2e4f "Add USB OHCI + HID driver" hardcoded the high order bit of the PCI address to that used on PPC machines instead of using the correct PCI_ADDR() macro. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci.c b/drivers/pci.c index 295be7e..7085a3a 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1111,7 +1111,10 @@ int i82378_config_cb(const pci_config_t *config) int usb_ohci_config_cb(const pci_config_t *config) { #ifdef CONFIG_DRIVER_USB - ob_usb_ohci_init(config->path, 0x80000000 | config->dev); + pci_addr addr = PCI_ADDR( + PCI_BUS(config->dev), PCI_DEV(config->dev), PCI_FN(config->dev)); + + ob_usb_ohci_init(config->path, addr); #endif return 0; } -- 2.11.0

2 2

[PATCH 0/2] ppc: minor fixups
by Mark Cave-Ayland 19 May '18

19 May '18

Here are a couple of minor fixups which have been kicking around my OpenBIOS git repository for a little while. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): ppc: don't hardcode the system bus frequency macio: set correct UniNorth device revision arch/ppc/qemu/init.c | 4 ++-- drivers/macio.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.11.0

1 3

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 10 May '18

10 May '18

> On May 10, 2018, at 8:52 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > > >> On May 10, 2018, at 6:46 AM, Jd Lyons via OpenBIOS <openbios(a)openbios.org <mailto:openbios@openbios.org>> wrote: >> >> >> : execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff )<—— We should be seeing fff5723c 0 here? >>> On May 10, 2018, at 6:33 AM, Jd Lyons <lyons_dj(a)yahoo.com <mailto:lyons_dj@yahoo.com>> wrote: >>> >>> >> >> -- >> OpenBIOS http://openbios.org/ <http://openbios.org/> >> Mailinglist: http://lists.openbios.org/mailman/listinfo <http://lists.openbios.org/mailman/listinfo> >> Free your System - May the Forth be with you > > Here is how SLOF seems to deal with the code I’m hangin on: > > Tho, I don’t know if it tells us anything useful. > > 14051: [ 14] b?branch 0 0 2 1 7e783de0 > 14054: [ 11] b(') 0 0 2 1 7e783de0 7e78e740 > 14057: [ c3] b(to) 0 0 2 1 7e783de0 > 1405a: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 0 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 0 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 ) | 0 0 2 1 7e783de0 > 1405b: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 0 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 0 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 ) | 0 0 2 1 7e783de0 > 1405d: [ddf] xddf 0 0 2 1 7e783de0 > 1405f: [e04] xe04 0 0 2 1 7e783de0 > 14061: [e38] xe38 0 0 2 1 7e783de0 > 14063: [e06] xe06 0 0 2 1 7e783de0 > 14065: [ce5] xce5 0 0 2 1 7e783de0 > 14067: [db0] xdb0 0 0 2 1 7e783de0 > 14069: [e07] xe07 0 0 2 1 7e783de0 > 1406b: [e1a] xe1a 0 0 2 1 7e783de0 > 1406d: [c5b] xc5b 0 0 2 1 7e783de0 > 1406f: [e28] xe28 0 0 2 1 7e783de0 > 14071: [e20] xe20 0 0 2 1 7e783de0 > 14073: [dfa] xdfa 0 0 2 1 7e783de0 > 14075: [e37] xe37 0 0 2 1 7e783de0 > 14077: [e2c] xe2c 0 0 2 1 7e783de0 > 14079: [e2d] xe2d 0 0 2 1 7e783de0 > 1407a: [ 12] b(") 0 0 2 1 7e783de0 1407c b > 14088: [201] device-name 0 0 2 1 7e783de0 > 14089: [ a6] 1 0 0 2 1 7e783de0 1 > 1408b: [111] encode-int 0 0 2 1 7e783de0 7e7d4788 4 > 1408c: [ 12] b(") 0 0 2 1 7e783de0 7e7d4788 4 1408e e > 1409d: [110] property 0 0 2 1 7e783de0 > 1409e: [ a5] 0 0 0 2 1 7e783de0 0 > 140a0: [111] encode-int 0 0 2 1 7e783de0 7e7d47d0 4 > 140a1: [ 12] b(") 0 0 2 1 7e783de0 7e7d47d0 4 140a3 b > 140af: [110] property 0 0 2 1 7e783de0 > 140b1: [9c7] x9c7 0 0 2 1 7e783de0 > 140b3: [93d] x93d 0 0 2 1 7e783de0 43 > 140b4: [ 10] b(lit) 0 0 2 1 7e783de0 43 35 > 140b9: [ 42] >= 0 0 2 1 7e783de0 -1 > 140ba: [ 14] b?branch 0 0 2 1 7e783de0 > 140bd: [ a6] 1 0 0 2 1 7e783de0 1 > 140bf: [933] x933 0 0 2 1 7e783de0 1 5 > 140c0: [ 27] LSHIFT 0 0 2 1 7e783de0 20 > 140c2: [935] x935 0 0 2 1 7e783de0 20 2cf > 140c3: [ 24] OR 0 0 2 1 7e783de0 2ef > 140c4: [ c3] b(to) 0 0 2 1 7e783de0 > 140c7: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 0 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 0 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 ) | 0 0 2 1 7e783de0 > 140c9: [941] x941 0 0 2 1 7e783de0 50 > 140ca: [ 10] b(lit) 0 0 2 1 7e783de0 50 10 > 140cf: [ 27] LSHIFT 0 0 2 1 7e783de0 500000 > 140d1: [935] x935 0 0 2 1 7e783de0 500000 2ef > 140d2: [ 24] OR 0 0 2 1 7e783de0 5002ef > 140d4: [111] encode-int 0 0 2 1 7e783de0 7e7d4860 4 > 140d5: [ 12] b(") 0 0 2 1 7e783de0 7e7d4860 4 140d7 d > 140e5: [110] property 0 0 2 1 7e783de0 > 140e6: [ a6] 1 0 0 2 1 7e783de0 1 > 140e8: [111] encode-int 0 0 2 1 7e783de0 7e7d48a8 4 > 140e9: [ 12] b(") 0 0 2 1 7e783de0 7e7d48a8 4 140eb a > 140f6: [110] property 0 0 2 1 7e783de0 > 140f7: [ a5] 0 0 0 2 1 7e783de0 0 > 140f8: [ a5] 0 0 0 2 1 7e783de0 0 0 > 140fa: [e2e] xe2e 0 0 2 1 7e783de0 7e7d48f0 14 > 140fc: [9bc] x9bc 0 0 2 1 7e783de0 7e7d48f0 14 2000010 > 140fe: [9c3] x9c3 0 0 2 1 7e783de0 7e7d48f0 14 2000010 -ff000000 > 14100: [e2e] xe2e 0 0 2 1 7e783de0 7e7d48f0 14 7e7d4904 14 > 14102: [112] encode+ 0 0 2 1 7e783de0 7e7d48f0 28 > 14104: [9c0] x9c0 0 0 2 1 7e783de0 7e7d48f0 28 200001c > 14106: [9c6] x9c6 0 0 2 1 7e783de0 7e7d48f0 28 200001c -ff000000 > 14108: [e2e] xe2e 0 0 2 1 7e783de0 7e7d48f0 28 7e7d4918 14 > 1410a: [112] encode+ 0 0 2 1 7e783de0 7e7d48f0 3c > 1410c: [9be] x9be 0 0 2 1 7e783de0 7e7d48f0 3c 42000014 > 1410e: [9c4] x9c4 0 0 2 1 7e783de0 7e7d48f0 3c 42000014 -f0000000 > 14110: [e2e] xe2e 0 0 2 1 7e783de0 7e7d48f0 3c 7e7d492c 14 > 14112: [112] encode+ 0 0 2 1 7e783de0 7e7d48f0 50 > 14114: [9bf] x9bf 0 0 2 1 7e783de0 7e7d48f0 50 2000030 > 14116: [9c5] x9c5 0 0 2 1 7e783de0 7e7d48f0 50 2000030 -ffff0000 > 14118: [e2e] xe2e 0 0 2 1 7e783de0 7e7d48f0 50 7e7d4940 14 > 1411a: [112] encode+ 0 0 2 1 7e783de0 7e7d48f0 64 > 1411b: [ 12] b(") 0 0 2 1 7e783de0 7e7d48f0 64 1411d 3 > 14121: [110] property 0 0 2 1 7e783de0 > 14122: [ a6] 1 0 0 2 1 7e783de0 1 > 14124: [111] encode-int 0 0 2 1 7e783de0 7e7d4990 4 > 14125: [ 12] b(") 0 0 2 1 7e783de0 7e7d4990 4 14127 e > 14136: [110] property 0 0 2 1 7e783de0 > 14137: [ a5] 0 0 0 2 1 7e783de0 0 > 14139: [111] encode-int 0 0 2 1 7e783de0 7e7d49d8 4 > 1413a: [ 12] b(") 0 0 2 1 7e783de0 7e7d49d8 4 1413c b > 14148: [110] property 0 0 2 1 7e783de0 > 14149: [ 12] b(") 0 0 2 1 7e783de0 1414b 1a > 14165: [ cd] EVALUATE 0 0 2 1 7e783de0 > 14167: [c7c] xc7c 0 0 2 1 7e783de0 10000000 > 14168: [ 47] DUP 0 0 2 1 7e783de0 10000000 10000000 > 1416a: [111] encode-int 0 0 2 1 7e783de0 10000000 7e7d4a50 4 > 1416b: [ 4a] ROT 0 0 2 1 7e783de0 7e7d4a50 4 10000000 > 1416d: [111] encode-int 0 0 2 1 7e783de0 7e7d4a50 4 7e7d4a54 4 > 1416f: [112] encode+ 0 0 2 1 7e783de0 7e7d4a50 8 > 14170: [ 12] b(") 0 0 2 1 7e783de0 7e7d4a50 8 14172 c > 1417f: [110] property 0 0 2 1 7e783de0 > 14180: [ a5] 0 0 0 2 1 7e783de0 0 > 14181: [ c3] b(to) 0 0 2 1 7e783de0 > 14185: [951] x951 0 0 2 1 7e783de0 2 > 14186: [ a5] 0 0 0 2 1 7e783de0 2 0 > 14187: [ 18] b(?do) 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 1418a: [ 19] 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 1418c: [a41] 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 1418e: [a4a] 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 14190: [8ea] 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 14191: [ 3d] 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 14192: [ 14] b?branch 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 > 14195: [ 19] 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 > 14196: [ c3] b(to) 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 > 14199: [ 1b] b(leave) 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 > 1419a: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 2 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 2 ) | > 7e7848b8 : THEN ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0ee60 : ?COMP ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0e780 : STATE ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0e788 : @ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc0e6f0 ) | > 7dc0e790 : 0BRANCH ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 2 ) | > 7dc0e7a0 : EXIT ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0ee68 : RESOLVE-ORIG ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0ed60 : HERE ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 ) | > 7dc0ed68 : OVER ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 ) | > 7dc0ed70 : CELL+ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f148 ) | > 7dc09f40 : NA1+ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f148 ) | > 7dc09ee8 : /N ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f148 ) | > 7dc09ef0 : + ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f148 8 ) | > 7dc09ef8 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f150 ) | > 7dc09f48 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f150 ) | > 7dc0ed78 : - ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 7dc5f180 7dc5f150 ) | > 7dc0ed80 : SWAP ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc5f148 30 ) | > 7dc0ed88 : ! ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 30 7dc5f148 ) | > 7dc0ed90 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ee70 : -COMP ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ecb8 : -1 ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ecc0 : STATE ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 -1 ) | > 7dc0ecc8 : +! ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 -1 7dc0e6f0 ) | > 7dc0bcc8 : TUCK ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 -1 7dc0e6f0 ) | > 7dc0a178 : SWAP ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 -1 7dc0e6f0 ) | > 7dc0a180 : OVER ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 -1 ) | > 7dc0a188 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 -1 7dc0e6f0 ) | > 7dc0bcd0 : @ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 -1 7dc0e6f0 ) | > 7dc0bcd8 : + ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 -1 2 ) | > 7dc0bce0 : SWAP ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 1 ) | > 7dc0bce8 : ! ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 1 7dc0e6f0 ) | > 7dc0bcf0 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ecd0 : STATE ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ecd8 : @ ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 7dc0e6f0 ) | > 7dc0ece0 : 0BRANCH ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 1 ) | > 7dc0ecf0 : EXIT ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7dc0ee78 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 2 0 0 7dc5f110 ) | 0 0 2 1 7e783de0 2 0 0 7dc5f110 > 1419b: [ 15] b(loop) 0 0 2 1 7e783de0 > 1419f: [946] x946 0 0 2 1 7e783de0 2 > 141a0: [ 38] 0> 0 0 2 1 7e783de0 -1 > 141a1: [ 14] b?branch 0 0 2 1 7e783de0 > 141a5: [952] x952 0 0 2 1 7e783de0 0 > 141a7: [a41] xa41 0 0 2 1 7e783de0 > 141a9: [11f] new-device 0 0 2 1 7e783de0 > 141ab: [e32] xe32 0 0 2 1 7e783de0 > 141ac: [ b5] new-token 0 0 2 1 7e783de0 > 141af: [ b7] b(:) 0 0 2 1 7e783de0 > 141b1: [952] 0 0 2 1 7e783de0 > 141b3: [a41] 0 0 2 1 7e783de0 > 141b5: [df1] 0 0 2 1 7e783de0 > 141b6: [ c3] b(to) 0 0 2 1 7e783de0 > 141b9: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 141ba: [ b5] new-token 0 0 2 1 7e783de0 > 141bd: [ b7] b(:) 0 0 2 1 7e783de0 > 141bf: [952] 0 0 2 1 7e783de0 > 141c1: [a41] 0 0 2 1 7e783de0 > 141c3: [df2] 0 0 2 1 7e783de0 > 141c4: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 141c5: [ b6] named-token 0 0 2 1 7e783de0 > 141d1: [ b7] b(:) 0 0 2 1 7e783de0 > 141d3: [dcb] 0 0 2 1 7e783de0 > 141d4: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 141d5: [ b6] named-token 0 0 2 1 7e783de0 > 141e3: [ b7] b(:) 0 0 2 1 7e783de0 > 141e5: [dcc] 0 0 2 1 7e783de0 > 141e6: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 141e7: [ ca] external-token 0 0 2 1 7e783de0 > 141f3: [ b7] b(:) 0 0 2 1 7e783de0 > 141f5: [952] 0 0 2 1 7e783de0 > 141f7: [a41] 0 0 2 1 7e783de0 > 141f9: [dca] 0 0 2 1 7e783de0 > 141fa: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 141fb: [ ca] external-token 0 0 2 1 7e783de0 > 1420d: [ b7] b(:) 0 0 2 1 7e783de0 > 1420f: [952] 0 0 2 1 7e783de0 > 14211: [a41] 0 0 2 1 7e783de0 > 14213: [dd5] 0 0 2 1 7e783de0 > 14214: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14215: [ ca] external-token 0 0 2 1 7e783de0 > 14227: [ b7] b(:) 0 0 2 1 7e783de0 > 14229: [952] 0 0 2 1 7e783de0 > 1422b: [a41] 0 0 2 1 7e783de0 > 1422d: [dd7] 0 0 2 1 7e783de0 > 1422e: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1422f: [ ca] external-token 0 0 2 1 7e783de0 > 14241: [ b7] b(:) 0 0 2 1 7e783de0 > 14243: [952] 0 0 2 1 7e783de0 > 14245: [a41] 0 0 2 1 7e783de0 > 14247: [dd6] 0 0 2 1 7e783de0 > 14248: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14249: [ ca] external-token 0 0 2 1 7e783de0 > 14253: [ b7] b(:) 0 0 2 1 7e783de0 > 14255: [952] 0 0 2 1 7e783de0 > 14257: [a41] 0 0 2 1 7e783de0 > 14259: [cf7] 0 0 2 1 7e783de0 > 1425a: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1425b: [ ca] external-token 0 0 2 1 7e783de0 > 14265: [ b7] b(:) 0 0 2 1 7e783de0 > 14267: [952] 0 0 2 1 7e783de0 > 14269: [a41] 0 0 2 1 7e783de0 > 1426b: [cf9] 0 0 2 1 7e783de0 > 1426c: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1426d: [ ca] external-token 0 0 2 1 7e783de0 > 1427b: [ b7] b(:) 0 0 2 1 7e783de0 > 1427d: [952] 0 0 2 1 7e783de0 > 1427f: [a41] 0 0 2 1 7e783de0 > 14281: [cf3] 0 0 2 1 7e783de0 > 14282: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14283: [ ca] external-token 0 0 2 1 7e783de0 > 14291: [ b7] b(:) 0 0 2 1 7e783de0 > 14293: [952] 0 0 2 1 7e783de0 > 14295: [a41] 0 0 2 1 7e783de0 > 14297: [cf5] 0 0 2 1 7e783de0 > 14298: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14299: [ ca] external-token 0 0 2 1 7e783de0 > 142a7: [ b7] b(:) 0 0 2 1 7e783de0 > 142a9: [b70] 0 0 2 1 7e783de0 > 142ab: [b71] 0 0 2 1 7e783de0 > 142ac: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 142ad: [ ca] external-token 0 0 2 1 7e783de0 > 142bf: [ b7] b(:) 0 0 2 1 7e783de0 > 142c1: [952] 0 0 2 1 7e783de0 > 142c3: [a41] 0 0 2 1 7e783de0 > 142c5: [df3] 0 0 2 1 7e783de0 > 142c6: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 142c7: [ ca] external-token 0 0 2 1 7e783de0 > 142d8: [ b7] b(:) 0 0 2 1 7e783de0 > 142da: [952] 0 0 2 1 7e783de0 > 142dc: [a41] 0 0 2 1 7e783de0 > 142de: [df4] 0 0 2 1 7e783de0 > 142df: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 142e0: [ ca] external-token 0 0 2 1 7e783de0 > 142f2: [ b7] b(:) 0 0 2 1 7e783de0 > 142f4: [952] 0 0 2 1 7e783de0 > 142f6: [a41] 0 0 2 1 7e783de0 > 142f8: [df5] 0 0 2 1 7e783de0 > 142f9: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 142fb: [95f] x95f 0 0 2 1 7e783de0 0 > 142fc: [ a6] 1 0 0 2 1 7e783de0 0 1 > 142fe: [952] x952 0 0 2 1 7e783de0 0 1 0 > 142ff: [ 27] LSHIFT 0 0 2 1 7e783de0 0 1 > 14300: [ 23] AND 0 0 2 1 7e783de0 0 > 14301: [ 35] 0<> 0 0 2 1 7e783de0 0 > 14302: [ 14] b?branch 0 0 2 1 7e783de0 > 14345: [ 11] b(') 0 0 2 1 7e783de0 7e7d4d68 > 14349: [11c] is-install 0 0 2 1 7e783de0 > 1434a: [ 11] b(') 0 0 2 1 7e783de0 7e7d4dc0 > 1434e: [11d] is-remove 0 0 2 1 7e783de0 > 14350: [127] finish-device 0 0 2 1 7e783de0 > 14351: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 0 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 0 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 ) | 0 0 2 1 7e783de0 > 14353: [946] x946 0 0 2 1 7e783de0 2 > 14354: [ a6] 1 0 0 2 1 7e783de0 2 1 > 14355: [ 3b] > 0 0 2 1 7e783de0 -1 > 14356: [ 14] b?branch 0 0 2 1 7e783de0 > 14359: [ a4] -1 0 0 2 1 7e783de0 -1 > 1435b: [951] x951 0 0 2 1 7e783de0 -1 2 > 1435c: [ a5] 0 0 0 2 1 7e783de0 -1 2 0 > 1435d: [ 18] b(?do) 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 > 14360: [ 19] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 > 14362: [952] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 > 14363: [ 3d] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 > 14364: [ 14] b?branch 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14367: [ 47] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14368: [ a4] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14369: [ 3c] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 1436a: [ 14] b?branch 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 > 1436d: [ 46] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 > 1436e: [ 19] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 > 1436f: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 3 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 3 ) | > 7e7848b8 : THEN ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0ee60 : ?COMP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0e780 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0e788 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc0e6f0 ) | > 7dc0e790 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 3 ) | > 7dc0e7a0 : EXIT ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0ee68 : RESOLVE-ORIG ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0ed60 : HERE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 ) | > 7dc0ed68 : OVER ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 ) | > 7dc0ed70 : CELL+ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f160 ) | > 7dc09f40 : NA1+ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f160 ) | > 7dc09ee8 : /N ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f160 ) | > 7dc09ef0 : + ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f160 8 ) | > 7dc09ef8 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f168 ) | > 7dc09f48 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f168 ) | > 7dc0ed78 : - ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 7dc5f178 7dc5f168 ) | > 7dc0ed80 : SWAP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f160 10 ) | > 7dc0ed88 : ! ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 10 7dc5f160 ) | > 7dc0ed90 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ee70 : -COMP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ecb8 : -1 ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ecc0 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 -1 ) | > 7dc0ecc8 : +! ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 -1 7dc0e6f0 ) | > 7dc0bcc8 : TUCK ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 -1 7dc0e6f0 ) | > 7dc0a178 : SWAP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 -1 7dc0e6f0 ) | > 7dc0a180 : OVER ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 -1 ) | > 7dc0a188 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 -1 7dc0e6f0 ) | > 7dc0bcd0 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 -1 7dc0e6f0 ) | > 7dc0bcd8 : + ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 -1 3 ) | > 7dc0bce0 : SWAP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 2 ) | > 7dc0bce8 : ! ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 2 7dc0e6f0 ) | > 7dc0bcf0 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ecd0 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ecd8 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc0e6f0 ) | > 7dc0ece0 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 2 ) | > 7dc0ecf0 : EXIT ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ee78 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14370: [ 19] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14372: [a41] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14374: [a4a] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14376: [8ea] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14377: [ 3d] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 14378: [ 14] b?branch 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 > 1437b: [ 46] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 > 1437c: [ 19] 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 > 1437d: [ 1b] b(leave) 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 > 1437e: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7e783398 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7e7833a0 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc0e6f0 ) | > 7e7833a8 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 3 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 3 ) | > 7e7848b8 : THEN ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0ee60 : ?COMP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0e780 : STATE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0e788 : @ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc0e6f0 ) | > 7dc0e790 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 3 ) | > 7dc0e7a0 : EXIT ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0ee68 : RESOLVE-ORIG ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0ed60 : HERE ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 ) | > 7dc0ed68 : OVER ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 ) | > 7dc0ed70 : CELL+ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1a8 ) | > 7dc09f40 : NA1+ ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1a8 ) | > 7dc09ee8 : /N ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1a8 ) | > 7dc09ef0 : + ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1a8 8 ) | > 7dc09ef8 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1b0 ) | > 7dc09f48 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1b0 ) | > 7dc0ed78 : - ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 7dc5f1d0 7dc5f1b0 ) | > 7dc0ed80 : SWAP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 7dc5f1a8 20 ) | > 7dc0ed88 : ! ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 20 7dc5f1a8 ) | > 7dc0ed90 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ee70 : -COMP ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7dc0ee78 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 > 1437f: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 2 ) | > 7e7848b8 : THEN ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 7dc5f138 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 ) | 0 0 2 1 7e783de0 -1 2 0 0 7dc5f110 > 14380: [ 15] b(loop) 0 0 2 1 7e783de0 1 > 14383: [ 47] DUP 0 0 2 1 7e783de0 1 1 > 14384: [ c3] b(to) 0 0 2 1 7e783de0 1 > 14388: [a41] xa41 0 0 2 1 7e783de0 > 1438a: [11f] new-device 0 0 2 1 7e783de0 > 1438c: [e32] xe32 0 0 2 1 7e783de0 > 1438d: [ b5] new-token 0 0 2 1 7e783de0 > 14390: [ b7] b(:) 0 0 2 1 7e783de0 > 14392: [953] 0 0 2 1 7e783de0 > 14394: [a41] 0 0 2 1 7e783de0 > 14396: [df1] 0 0 2 1 7e783de0 > 14397: [ c3] b(to) 0 0 2 1 7e783de0 > 1439a: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1439b: [ b5] new-token 0 0 2 1 7e783de0 > 1439e: [ b7] b(:) 0 0 2 1 7e783de0 > 143a0: [953] 0 0 2 1 7e783de0 > 143a2: [a41] 0 0 2 1 7e783de0 > 143a4: [df2] 0 0 2 1 7e783de0 > 143a5: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 143a6: [ b6] named-token 0 0 2 1 7e783de0 > 143b2: [ b7] b(:) 0 0 2 1 7e783de0 > 143b4: [dcb] 0 0 2 1 7e783de0 > 143b5: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 143b6: [ b6] named-token 0 0 2 1 7e783de0 > 143c4: [ b7] b(:) 0 0 2 1 7e783de0 > 143c6: [dcc] 0 0 2 1 7e783de0 > 143c7: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 143c8: [ ca] external-token 0 0 2 1 7e783de0 > 143d4: [ b7] b(:) 0 0 2 1 7e783de0 > 143d6: [953] 0 0 2 1 7e783de0 > 143d8: [a41] 0 0 2 1 7e783de0 > 143da: [dca] 0 0 2 1 7e783de0 > 143db: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 143dc: [ ca] external-token 0 0 2 1 7e783de0 > 143ee: [ b7] b(:) 0 0 2 1 7e783de0 > 143f0: [953] 0 0 2 1 7e783de0 > 143f2: [a41] 0 0 2 1 7e783de0 > 143f4: [dd5] 0 0 2 1 7e783de0 > 143f5: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 143f6: [ ca] external-token 0 0 2 1 7e783de0 > 14408: [ b7] b(:) 0 0 2 1 7e783de0 > 1440a: [953] 0 0 2 1 7e783de0 > 1440c: [a41] 0 0 2 1 7e783de0 > 1440e: [dd7] 0 0 2 1 7e783de0 > 1440f: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14410: [ ca] external-token 0 0 2 1 7e783de0 > 14422: [ b7] b(:) 0 0 2 1 7e783de0 > 14424: [953] 0 0 2 1 7e783de0 > 14426: [a41] 0 0 2 1 7e783de0 > 14428: [dd6] 0 0 2 1 7e783de0 > 14429: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1442a: [ ca] external-token 0 0 2 1 7e783de0 > 14434: [ b7] b(:) 0 0 2 1 7e783de0 > 14436: [953] 0 0 2 1 7e783de0 > 14438: [a41] 0 0 2 1 7e783de0 > 1443a: [cf7] 0 0 2 1 7e783de0 > 1443b: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1443c: [ ca] external-token 0 0 2 1 7e783de0 > 14446: [ b7] b(:) 0 0 2 1 7e783de0 > 14448: [953] 0 0 2 1 7e783de0 > 1444a: [a41] 0 0 2 1 7e783de0 > 1444c: [cf9] 0 0 2 1 7e783de0 > 1444d: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1444e: [ ca] external-token 0 0 2 1 7e783de0 > 1445c: [ b7] b(:) 0 0 2 1 7e783de0 > 1445e: [953] 0 0 2 1 7e783de0 > 14460: [a41] 0 0 2 1 7e783de0 > 14462: [cf3] 0 0 2 1 7e783de0 > 14463: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 14464: [ ca] external-token 0 0 2 1 7e783de0 > 14472: [ b7] b(:) 0 0 2 1 7e783de0 > 14474: [953] 0 0 2 1 7e783de0 > 14476: [a41] 0 0 2 1 7e783de0 > 14478: [cf5] 0 0 2 1 7e783de0 > 14479: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1447a: [ ca] external-token 0 0 2 1 7e783de0 > 14488: [ b7] b(:) 0 0 2 1 7e783de0 > 1448a: [b70] 0 0 2 1 7e783de0 > 1448c: [b71] 0 0 2 1 7e783de0 > 1448d: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 1448e: [ ca] external-token 0 0 2 1 7e783de0 > 144a0: [ b7] b(:) 0 0 2 1 7e783de0 > 144a2: [953] 0 0 2 1 7e783de0 > 144a4: [a41] 0 0 2 1 7e783de0 > 144a6: [df3] 0 0 2 1 7e783de0 > 144a7: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 144a8: [ ca] external-token 0 0 2 1 7e783de0 > 144b9: [ b7] b(:) 0 0 2 1 7e783de0 > 144bb: [953] 0 0 2 1 7e783de0 > 144bd: [a41] 0 0 2 1 7e783de0 > 144bf: [df4] 0 0 2 1 7e783de0 > 144c0: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 144c1: [ ca] external-token 0 0 2 1 7e783de0 > 144d3: [ b7] b(:) 0 0 2 1 7e783de0 > 144d5: [953] 0 0 2 1 7e783de0 > 144d7: [a41] 0 0 2 1 7e783de0 > 144d9: [df5] 0 0 2 1 7e783de0 > 144da: [ c2] fc-locals-b(;) 0 0 2 1 7e783de0 > 144dc: [95f] x95f 0 0 2 1 7e783de0 0 > 144dd: [ a6] 1 0 0 2 1 7e783de0 0 1 > 144df: [953] x953 0 0 2 1 7e783de0 0 1 1 > 144e0: [ 27] LSHIFT 0 0 2 1 7e783de0 0 2 > 144e1: [ 23] AND 0 0 2 1 7e783de0 0 > 144e2: [ 35] 0<> 0 0 2 1 7e783de0 0 > 144e3: [ 14] b?branch 0 0 2 1 7e783de0 > 14526: [ 11] b(') 0 0 2 1 7e783de0 7e7d55a8 > 1452a: [11c] is-install 0 0 2 1 7e783de0 > 1452b: [ 11] b(') 0 0 2 1 7e783de0 7e7d5600 > 1452f: [11d] is-remove 0 0 2 1 7e783de0 > 14531: [127] finish-device 0 0 2 1 7e783de0 > 14532: [ b2] b(>resolve) > 7e7848a0 : ?compile-mode ( 0 0 2 1 7e783de0 ) | > 7e7848a8 : 0BRANCH ( 0 0 2 1 7e783de0 0 ) | > 7e7848c0 : SEMICOLON ( 0 0 2 1 7e783de0 ) | 0 0 2 1 7e783de0 > 14534: [11f] new-device 0 0 2 1 7e783de0 > 14535: [ 12] b(") 0 0 2 1 7e783de0 14537 d > 14545: [201] device-name 0 0 2 1 7e783de0 > 14546: [ 12] b(") 0 0 2 1 7e783de0 14548 12 > 1455b: [114] encode-string 0 0 2 1 7e783de0 7e7d5be0 13 > 1455c: [ 12] b(") 0 0 2 1 7e783de0 7e7d5be0 13 1455e a > 14569: [110] property 0 0 2 1 7e783de0 > 1456a: [ a7] 2 0 0 2 1 7e783de0 2 > 1456c: [111] encode-int 0 0 2 1 7e783de0 7e7d5c38 4 > 1456d: [ 12] b(") 0 0 2 1 7e783de0 7e7d5c38 4 1456f 17 > 14587: [110] property 0 0 2 1 7e783de0 > 14588: [ a7] 2 0 0 2 1 7e783de0 2 > 1458a: [111] encode-int 0 0 2 1 7e783de0 7e7d5c90 4 > 1458b: [ 12] b(") 0 0 2 1 7e783de0 7e7d5c90 4 1458d 15 > 145a3: [110] property 0 0 2 1 7e783de0 > 145a5: [951] x951 0 0 2 1 7e783de0 2 > 145a7: [111] encode-int 0 0 2 1 7e783de0 7e7d5ce0 4 > 145a8: [ 12] b(") 0 0 2 1 7e783de0 7e7d5ce0 4 145aa 3 > 145ae: [110] property 0 0 2 1 7e783de0 > 145af: [ a6] 1 0 0 2 1 7e783de0 1 > 145b1: [111] encode-int 0 0 2 1 7e783de0 7e7d5d20 4 > 145b2: [ 12] b(") 0 0 2 1 7e783de0 7e7d5d20 4 145b4 e > 145c3: [110] property 0 0 2 1 7e783de0 > 145c4: [ a5] 0 0 0 2 1 7e783de0 0 > 145c6: [111] encode-int 0 0 2 1 7e783de0 7e7d5d68 4 > 145c7: [ 12] b(") 0 0 2 1 7e783de0 7e7d5d68 4 145c9 b > 145d5: [110] property 0 0 2 1 7e783de0 > 145d7: [11f] new-device 0 0 2 1 7e783de0 > 145d8: [ 12] b(") 0 0 2 1 7e783de0 145da 15 > 145f0: [201] device-name 0 0 2 1 7e783de0 > 145f1: [ 12] b(") 0 0 2 1 7e783de0 145f3 b > 145ff: [11a] device-type 0 0 2 1 7e783de0 > 14600: [ 12] b(") 0 0 2 1 7e783de0 14602 9 > 1460c: [114] encode-string 0 0 2 1 7e783de0 7e7d5ed0 a > 1460d: [ 12] b(") 0 0 2 1 7e783de0 7e7d5ed0 a 1460f 8 > 14618: [110] property 0 0 2 1 7e783de0 > 1461a: [20a] my-parent 0 0 2 1 7e783de0 7e42a000 > 1461c: [20b] ihandle>phandle 0 0 2 1 7e783de0 7e7d5b30 > 1461d: [ 10] b(lit) 0 0 2 1 7e783de0 7e7d5b30 8 > 14622: [ 27] LSHIFT 0 0 2 1 7e783de0 7e7d5b3000 > 14624: [111] encode-int 0 0 2 1 7e783de0 7e7d5f20 4 > 14625: [ 12] b(") 0 0 2 1 7e783de0 7e7d5f20 4 14627 9 > 14631: [110] property 0 0 2 1 7e783de0 > 14632: [ a5] 0 0 0 2 1 7e783de0 0 > 14634: [111] encode-int 0 0 2 1 7e783de0 7e7d5f68 4 > 14635: [ 12] b(") 0 0 2 1 7e783de0 7e7d5f68 4 14637 3 > 1463b: [110] property 0 0 2 1 7e783de0 > 1463c: [ a7] 2 0 0 2 1 7e783de0 2 > 1463e: [111] encode-int 0 0 2 1 7e783de0 7e7d5fa8 4 > 1463f: [ 12] b(") 0 0 2 1 7e783de0 7e7d5fa8 4 14641 7 > 14649: [110] property 0 0 2 1 7e783de0 > 1464a: [ 10] b(lit) 0 0 2 1 7e783de0 ff000002 > 14650: [111] encode-int 0 0 2 1 7e783de0 7e7d5ff0 4 > 14651: [ 12] b(") 0 0 2 1 7e783de0 7e7d5ff0 4 14653 4 > 14658: [110] property 0 0 2 1 7e783de0 > 14659: [ 10] b(lit) 0 0 2 1 7e783de0 550000 > 1465f: [111] encode-int 0 0 2 1 7e783de0 7e7d6030 4 > 14660: [ 12] b(") 0 0 2 1 7e783de0 7e7d6030 4 14662 c > 1466f: [110] property 0 0 2 1 7e783de0 > 14670: [ 10] b(lit) 0 0 2 1 7e783de0 1e > 14676: [111] encode-int 0 0 2 1 7e783de0 7e7d6078 4 > 14677: [ a5] 0 0 0 2 1 7e783de0 7e7d6078 4 0 > 14679: [111] encode-int 0 0 2 1 7e783de0 7e7d6078 4 7e7d607c 4 > 1467b: [112] encode+ 0 0 2 1 7e783de0 7e7d6078 8 > 1467c: [ 12] b(") 0 0 2 1 7e783de0 7e7d6078 8 1467e e > 1468d: [110] property 0 0 2 1 7e783de0 > 1468f: [127] finish-device 0 0 2 1 7e783de0 > 14691: [127] finish-device 0 0 2 1 7e783de0 > 14693: [de0] xde0 0 0 2 1 7e783de0 > 14694: [ 0] end0 0 0 2 1 7e783de0 > restored fcode@ 7e783de0 > restored fcode-spread 1 > restored fcode-offset 2 > restored fcode-end 0 > restored ip 0 > ok > 0 > >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 08 May '18

08 May '18

If you’ll note, the one thing that jumps out at me, in the 6602.txt( openbios ), abort is called 50 times, yet it doesn’t appear at all in the 6600.txt( SLOF ). This may have something to do with the fact that SLOF reaches the end of the Fcode without error. > On May 8, 2018, at 3:41 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > Not sure if this is what you’re asking for, but the verbose output of both Openbios and SLOF executing the option rom. > > <6600.txt> > <6602.txt> > > >> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca <mailto:joevt@shaw.ca>> wrote: >> >> Can you send the full output directly to me or post a link? >> > > > >> Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used? > > Not sure how to check the value of here?

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

Ok,I got a little excited, [ddf] vs [dff]. Sometimes I’m easily confused. > On May 7, 2018, at 10:54 AM, Joe van Tunen <joevt(a)shaw.ca> wrote: > > > > On 5/7/18, 4:56 AM, "Segher Boessenkool" <segher(a)kernel.crashing.org> wrote: > > On Mon, May 07, 2018 at 07:33:04AM -0400, Jd Lyons wrote: >> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different. >> >> s” /pci/@x” select-dev >> >> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node. > > You should use begin-package and new-device or the like. See the Open > Firmware specification glossary entries for those words and byte-load . > >> Doesn’t anyone know how I can view the active device tree node? > > my-self ihandle>phandle ( -- phandle) and do some stuff with that, > or just use pwd . > > > Segher > > > > Is there a reason this thread isn't going to the openbios mailing list? > > Do you mean [dff] or [ddf]? Wasn't the evidence pointing to [ddf]? > > [ddf] calls the parent's map-in function a few times. The "PCI Bus Binding to Open Firmware" document mentions a bug with map-in which existed in Apple's original Open Firmware implementation. Do QEMU and the Quicksilver G4 both have a correctly implemented map-in function? > > What is the maximum dictionary space allowed by QEMU's OpenBIOS? If the maximum is reached, does it grow or does an exception occur? It's probably not likely that the nvidia fcode is exceeding this limit, but it would be good to have a method to confirm this. > > >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

Sorry, that wan me forgeting to include the list. > On May 7, 2018, at 10:54 AM, Joe van Tunen <joevt(a)shaw.ca> wrote: > > > > On 5/7/18, 4:56 AM, "Segher Boessenkool" <segher(a)kernel.crashing.org> wrote: > > On Mon, May 07, 2018 at 07:33:04AM -0400, Jd Lyons wrote: >> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different. >> >> s” /pci/@x” select-dev >> >> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node. > > You should use begin-package and new-device or the like. See the Open > Firmware specification glossary entries for those words and byte-load . > >> Doesn’t anyone know how I can view the active device tree node? > > my-self ihandle>phandle ( -- phandle) and do some stuff with that, > or just use pwd . > > > Segher > > > > Is there a reason this thread isn't going to the openbios mailing list? > > Do you mean [dff] or [ddf]? Wasn't the evidence pointing to [ddf]? > > [ddf] calls the parent's map-in function a few times. The "PCI Bus Binding to Open Firmware" document mentions a bug with map-in which existed in Apple's original Open Firmware implementation. Do QEMU and the Quicksilver G4 both have a correctly implemented map-in function? > > What is the maximum dictionary space allowed by QEMU's OpenBIOS? If the maximum is reached, does it grow or does an exception occur? It's probably not likely that the nvidia fcode is exceeding this limit, but it would be good to have a method to confirm this. > > >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 7, 2018, at 7:33 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > > >> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca> wrote: >> >> It is unclear to me if the exception is caused by compiling the fcode or interpreting (executing) it. Your verbose output (which I'm unfamiliar with) shows only "(compile)". Without trying it myself or looking at Apple's byte-load code, I'm guessing that's some kind of context, and perhaps there's an interpret (execute) context? Can you send the full output directly to me or post a link? >> >> Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used? I wonder if an exception would cause a rewind of some kind, or just leave everything as is. >> >> The fcode in question is at the top level and looks like this: >> >> >> new-token 0xe38 >> b(:) >> ... >> b(;) >> b(') (unnamed-fcode) [0xc84] >> b(to) (unnamed-fcode) [0x9a9] >> (unnamed-fcode) [0xe34] >> (unnamed-fcode) [0xdff] >> (unnamed-fcode) [0x93d] >> b(lit) 0xf >> <> >> b?branch 0x0026 ( =dec 38) >> (unnamed-fcode) [0x9bd] >> b(lit) 0xff >> and >> my-space >> + >> (unnamed-fcode) [0xa08] >> b(lit) 0x6 >> and >> b(lit) 0x4 >> = >> b?branch 0x0009 () >> b(') (unnamed-fcode) [0x9c1] >> b(to) (unnamed-fcode) [0x9c0] >> b(>resolve) >> b(>resolve) >> (unnamed-fcode) [0xddf] >> ... >> >> >> Since it's at the top level, it probably must be getting executed. The problem might be in executing 0xddf (defined earlier in the fcode). >> >> Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code. >> >> You should look at the 1275.pdf document "IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices" to get a description of the tokens. "b?branch ... b(>resolve)" are the tokens for the forth "if ... then" statements (when the b?branch fcode offset is positive). The document also describes how a token behaves while the fcode evaluator is in interpretation state and compilation state. >> >> >> On 5/6/18, 8:11 AM, "Jd Lyons" <lyons_dj(a)yahoo.com> wrote: >> >> Ok, now that I know we can load a Fcode Rom for an nVidia card in Apple’s Open Firmware implementation, I figured I try this again. >> >> I have to catch up a little one what we did before, so I maybe tripping over something I got passed before. >> >>> true to ?fcode-verbose >>> “ /pci/@10” open-dev to my-self >>> load hd:,\ppc\6600.rom >>> 4000040 1 byte-load >> >> ……. >> >> >> (offset) 26 >> 400fff9 : (compile) [ 0x9bd ] >> 400fffa : (compile) b(lit) [ 0x10 ] >> 400ffff : (compile) and [ 0x23 ] >> 4010001 : (compile) my-space [ 0x103 ] >> 4010002 : (compile) + [ 0x1e ] >> 4010004 : (compile) [ 0xa08 ] >> 4010005 : (compile) b(lit) [ 0x10 ] >> 401000a : (compile) and [ 0x23 ] >> 401000b : (compile) b(lit) [ 0x10 ] >> 4010010 : (compile) = [ 0x3c ] >> 4010011 : (compile) b?branch [ 0x14 ] >> (offset) 9 >> 4010014 : (compile) b(') [ 0x11 ] >> 4010017 : (compile) b(to) [ 0xc3 ] >> 401001a : (compile) b(>resolve) [ 0xb2 ] >> 401001b : (compile) b(>resolve) [ 0xb2 ] >> >> byte-load: exception caught! >> ok >> 0 > 4010014 200 dump >> 4010014 11 09 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 ..��.��.�...8.. >> 4010024 0c e5 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa .�.�.....[.(. .� >> 4010034 0e 37 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 .7.,.-..NVDA,Par >> 4010044 65 6e 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 ent..�....#addre >> 4010054 73 73 2d 63 65 6c 6c 73 01 10 a5 01 11 12 0b 23 ss-cells..�....# >> 4010064 73 69 7a 65 2d 63 65 6c 6c 73 01 10 09 c7 09 3d size-cells...�.= >> 4010074 10 00 00 00 35 42 14 00 0d a6 09 33 27 09 35 24 ....5B...�.3'.5$ >> 4010084 c3 09 35 b2 09 41 10 00 00 00 10 27 09 35 24 01 �.5�.A.....'.5$. >> 4010094 11 12 0d 4e 56 44 41 2c 46 65 61 74 75 72 65 73 ...NVDA,Features >> 40100a4 01 10 a6 01 11 12 0a 4e 56 44 41 2c 4c 65 76 65 ..�....NVDA,Leve >> 40100b4 6c 01 10 a5 a5 0e 2e 09 bc 09 c3 0e 2e 01 12 09 l..��...�.�..... >> 40100c4 c0 09 c6 0e 2e 01 12 09 be 09 c4 0e 2e 01 12 09 �.�.....�.�..... >> 40100d4 bf 09 c5 0e 2e 01 12 12 03 72 65 67 01 10 a6 01 �.�......reg..�. >> 40100e4 11 12 0e 23 61 64 64 72 65 73 73 2d 63 65 6c 6c ...#address-cell >> 40100f4 73 01 10 a5 01 11 12 0b 23 73 69 7a 65 2d 63 65 s..�....#size-ce >> 4010104 6c 6c 73 01 10 12 1a 3a 20 64 65 63 6f 64 65 2d lls....: decode- >> 4010114 75 6e 69 74 20 70 61 72 73 65 2d 31 68 65 78 20 unit parse-1hex >> 4010124 3b cd 0c 7c 47 01 11 4a 01 11 01 12 12 0c 56 52 ;�.|G..J......VR >> 4010134 41 4d 2c 6d 65 6d 73 69 7a 65 01 10 a5 c3 09 52 AM,memsize..��.R >> 4010144 09 51 a5 18 00 16 19 0a 41 0a 4a 08 ea 3d 14 00 .Q�.....A.J.�=.. >> 4010154 08 19 c3 09 52 1b b2 15 ff ee 09 46 38 14 01 b0 ..�.R.�.��.F8..� >> 4010164 09 52 0a 41 01 1f 0e 32 b5 0e 39 b7 09 52 0a 41 .R.A...2�.9�.R.A >> 4010174 0d f1 c3 01 62 c2 b5 0e 3a b7 09 52 0a 41 0d f2 .��.bµ.:�.R.A.� >> 4010184 c2 b6 08 67 65 74 2d 6d 6f 64 65 0e 3b b7 0d cb ¶.get-mode.;�.� >> 4010194 c2 b6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 3c b7 ¶.show-modes.<� >> 40101a4 0d cc c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 3d b7 .��.set-mode.=� >> 40101b4 09 52 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 .R.A.��.draw-re >> 40101c4 63 74 61 6e 67 6c 65 0e 3e b7 09 52 0a 41 0d d5 ctangle.>�.R.A.� >> 40101d4 c2 ca 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c ��.fill-rectangl >> 40101e4 65 0e 3f b7 09 52 0a 41 0d d7 c2 ca 0e 72 65 61 e.?�.R.A.��.rea >> 40101f4 64 2d 72 65 63 74 61 6e 67 6c 65 0e 40 b7 09 52 d-rectangle.@�.R >> 4010204 0a 41 0d d6 c2 ca 06 63 6f 6c 6f 72 21 0e 41 b7 .A.��.color!.A� >> ok >> 0 > my-self . fc5ac34 ok >> >> I think this is the point I got to before. I’m not real sure what is going wrong here? >> >> Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do? >> >> Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception. >> >> b?branch 0x0009 () >> b(') (unnamed-fcode) [0x9c1] >> b(to) (unnamed-fcode) [0x9c0] >> b(>resolve) >> b(>resolve) <—Here? >> (unnamed-fcode) [0xddf] >> (unnamed-fcode) [0xe04] >> (unnamed-fcode) [0xe38] >> (unnamed-fcode) [0xe06] >> (unnamed-fcode) [0xce5] >> (unnamed-fcode) [0xdb0] >> (unnamed-fcode) [0xe07] >> (unnamed-fcode) [0xe1a] >> (unnamed-fcode) [0xc5b] >> (unnamed-fcode) [0xe28] >> (unnamed-fcode) [0xe20] >> (unnamed-fcode) [0xdfa] >> (unnamed-fcode) [0xe37] >> (unnamed-fcode) [0xe2c] >> (unnamed-fcode) [0xe2d] >> b(") ( len=0xb [11 bytes] ) >> " NVDA,Parent" >> device-name >> 1 >> encode-int >> b(") ( len=0xe [14 bytes] ) >> " #address-cells" >> property >> 0 >> >> > > Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different. > > s” /pci/@x” select-dev > > That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node. > > Using that code in Openbios still raises the same exception at 401005b, but I really think it’s the next thing [dff], it can’t resolve the device? > > Doesn’t anyone know how I can view the active device tree node? > > > > >> >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 7, 2018, at 5:21 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > Sorry, I wasn’t clear, no trouble executing this in Apple’s Open Firmware implementation. I’ve moved back to Openbios to see if I can get PCI Passthough working with Qumu-system-ppc. > > The host is an AMD B350 board running Debian 9. With a Geforce 6600 PCI-E card from a G5. > > > >> On May 6, 2018, at 10:25 PM, Joe van Tunen <joevt(a)shaw.ca> wrote: >> >> I'm not sure about QEMU. Jd Lyons is getting the exception using Apple's Open Firmware implementation on a Quicksilver PowerMac G4. >> >> >> On 5/6/18, 5:21 PM, "OpenBIOS on behalf of Tarl Neustaedter" <openbios-bounces(a)openbios.org on behalf of tarl-b2(a)tarl.net> wrote: >> >> For what it's worth: >> >> On 2018-May-6 20:12 , Joe van Tunen wrote: >>> b(lit) 0xff >>> and >>> my-space >>> + >>> (unnamed-fcode) [0xa08] >>> b(lit) 0x6 >>> and >>> b(lit) 0x4 >>> = >> >> That sequence is probably testing a BAR for 64-bit capability. Bits 1-2 >> are the type of memory referenced by a BAR (0=IO, 1=32-bit mem, 2=64-bit >> mem). >> >> https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration >> >> Does QEMU do something funny with 64-bit BARs? An NVIDIA card is almost >> certain to have 64-bit addressing in at least one BAR, and if QEMU >> doesn't support it, bad things may be happening. >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >> >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 6, 2018, at 1:08 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > True, I’m just not sure yet what to fix, I forgot the point we got to before, so I’ll have to do a little back tracking. > > I tried to b?branch before, but the way I did it just made things worse. > > Once I get down to the exact reason for the exception here, should give me a little better idea what I need to fix. > > I do remember getting passed this before, but things didn’t get much further. > > Sometimes it’s better to be lucky than good. > >> On May 6, 2018, at 12:21 PM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: >> >> On Sun, May 06, 2018 at 12:08:47PM -0400, Jd Lyons wrote: >>> I noticed that openbios builds the open and close methods for the pci device( nVidia ). >>> >>> Is there a way to destroy these words/methods before I call 1 byte-load? >> >> It is probably easier to make openbios do the right thing here, make it >> more standard-compliant -- you can add workaround on top of workaround, >> but at some point it becomes easier to just fix things, no matter how >> much work that is. >> >> >> Segher >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 6, 2018, at 12:08 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > I noticed that openbios builds the open and close methods for the pci device( nVidia ). > > Is there a way to destroy these words/methods before I call 1 byte-load? > > > >> On May 6, 2018, at 11:11 AM, Jd Lyons via OpenBIOS <openbios(a)openbios.org> wrote: >> >> Ok, now that I know we can load a Fcode Rom for an nVidia card in Apple’s Open Firmware implementation, I figured I try this again. >> >> I have to catch up a little one what we did before, so I maybe tripping over something I got passed before. >> >>> true to ?fcode-verbose >>> “ /pci/@10” open-dev to my-self >>> load hd:,\ppc\6600.rom >>> 4000040 1 byte-load >> >> ……. >> >> >> (offset) 26 >> 400fff9 : (compile) [ 0x9bd ] >> 400fffa : (compile) b(lit) [ 0x10 ] >> 400ffff : (compile) and [ 0x23 ] >> 4010001 : (compile) my-space [ 0x103 ] >> 4010002 : (compile) + [ 0x1e ] >> 4010004 : (compile) [ 0xa08 ] >> 4010005 : (compile) b(lit) [ 0x10 ] >> 401000a : (compile) and [ 0x23 ] >> 401000b : (compile) b(lit) [ 0x10 ] >> 4010010 : (compile) = [ 0x3c ] >> 4010011 : (compile) b?branch [ 0x14 ] >> (offset) 9 >> 4010014 : (compile) b(') [ 0x11 ] >> 4010017 : (compile) b(to) [ 0xc3 ] >> 401001a : (compile) b(>resolve) [ 0xb2 ] >> 401001b : (compile) b(>resolve) [ 0xb2 ] >> >> byte-load: exception caught! >> ok >> 0 > 4010014 200 dump >> 4010014 11 09 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 ..��.��.�...8.. >> 4010024 0c e5 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa .�.�.....[.(. .� >> 4010034 0e 37 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 .7.,.-..NVDA,Par >> 4010044 65 6e 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 ent..�....#addre >> 4010054 73 73 2d 63 65 6c 6c 73 01 10 a5 01 11 12 0b 23 ss-cells..�....# >> 4010064 73 69 7a 65 2d 63 65 6c 6c 73 01 10 09 c7 09 3d size-cells...�.= >> 4010074 10 00 00 00 35 42 14 00 0d a6 09 33 27 09 35 24 ....5B...�.3'.5$ >> 4010084 c3 09 35 b2 09 41 10 00 00 00 10 27 09 35 24 01 �.5�.A.....'.5$. >> 4010094 11 12 0d 4e 56 44 41 2c 46 65 61 74 75 72 65 73 ...NVDA,Features >> 40100a4 01 10 a6 01 11 12 0a 4e 56 44 41 2c 4c 65 76 65 ..�....NVDA,Leve >> 40100b4 6c 01 10 a5 a5 0e 2e 09 bc 09 c3 0e 2e 01 12 09 l..��...�.�..... >> 40100c4 c0 09 c6 0e 2e 01 12 09 be 09 c4 0e 2e 01 12 09 �.�.....�.�..... >> 40100d4 bf 09 c5 0e 2e 01 12 12 03 72 65 67 01 10 a6 01 �.�......reg..�. >> 40100e4 11 12 0e 23 61 64 64 72 65 73 73 2d 63 65 6c 6c ...#address-cell >> 40100f4 73 01 10 a5 01 11 12 0b 23 73 69 7a 65 2d 63 65 s..�....#size-ce >> 4010104 6c 6c 73 01 10 12 1a 3a 20 64 65 63 6f 64 65 2d lls....: decode- >> 4010114 75 6e 69 74 20 70 61 72 73 65 2d 31 68 65 78 20 unit parse-1hex >> 4010124 3b cd 0c 7c 47 01 11 4a 01 11 01 12 12 0c 56 52 ;�.|G..J......VR >> 4010134 41 4d 2c 6d 65 6d 73 69 7a 65 01 10 a5 c3 09 52 AM,memsize..��.R >> 4010144 09 51 a5 18 00 16 19 0a 41 0a 4a 08 ea 3d 14 00 .Q�.....A.J.�=.. >> 4010154 08 19 c3 09 52 1b b2 15 ff ee 09 46 38 14 01 b0 ..�.R.�.��.F8..� >> 4010164 09 52 0a 41 01 1f 0e 32 b5 0e 39 b7 09 52 0a 41 .R.A...2�.9�.R.A >> 4010174 0d f1 c3 01 62 c2 b5 0e 3a b7 09 52 0a 41 0d f2 .��.bµ.:�.R.A.� >> 4010184 c2 b6 08 67 65 74 2d 6d 6f 64 65 0e 3b b7 0d cb ¶.get-mode.;�.� >> 4010194 c2 b6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 3c b7 ¶.show-modes.<� >> 40101a4 0d cc c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 3d b7 .��.set-mode.=� >> 40101b4 09 52 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 .R.A.��.draw-re >> 40101c4 63 74 61 6e 67 6c 65 0e 3e b7 09 52 0a 41 0d d5 ctangle.>�.R.A.� >> 40101d4 c2 ca 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c ��.fill-rectangl >> 40101e4 65 0e 3f b7 09 52 0a 41 0d d7 c2 ca 0e 72 65 61 e.?�.R.A.��.rea >> 40101f4 64 2d 72 65 63 74 61 6e 67 6c 65 0e 40 b7 09 52 d-rectangle.@�.R >> 4010204 0a 41 0d d6 c2 ca 06 63 6f 6c 6f 72 21 0e 41 b7 .A.��.color!.A� >> ok >> 0 > my-self . fc5ac34 ok >> >> I think this is the point I got to before. I’m not real sure what is going wrong here? >> >> Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do? >> >> Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception. >> >> b?branch 0x0009 () >> b(') (unnamed-fcode) [0x9c1] >> b(to) (unnamed-fcode) [0x9c0] >> b(>resolve) >> b(>resolve) <—Here? >> (unnamed-fcode) [0xddf] >> (unnamed-fcode) [0xe04] >> (unnamed-fcode) [0xe38] >> (unnamed-fcode) [0xe06] >> (unnamed-fcode) [0xce5] >> (unnamed-fcode) [0xdb0] >> (unnamed-fcode) [0xe07] >> (unnamed-fcode) [0xe1a] >> (unnamed-fcode) [0xc5b] >> (unnamed-fcode) [0xe28] >> (unnamed-fcode) [0xe20] >> (unnamed-fcode) [0xdfa] >> (unnamed-fcode) [0xe37] >> (unnamed-fcode) [0xe2c] >> (unnamed-fcode) [0xe2d] >> b(") ( len=0xb [11 bytes] ) >> " NVDA,Parent" >> device-name >> 1 >> encode-int >> b(") ( len=0xe [14 bytes] ) >> " #address-cells" >> property >> 0 >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >

1 0

Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

Ok, now that I know we can load a Fcode Rom for an nVidia card in Apple’s Open Firmware implementation, I figured I try this again. I have to catch up a little one what we did before, so I maybe tripping over something I got passed before. > true to ?fcode-verbose > “ /pci/@10” open-dev to my-self > load hd:,\ppc\6600.rom > 4000040 1 byte-load ……. (offset) 26 400fff9 : (compile) [ 0x9bd ] 400fffa : (compile) b(lit) [ 0x10 ] 400ffff : (compile) and [ 0x23 ] 4010001 : (compile) my-space [ 0x103 ] 4010002 : (compile) + [ 0x1e ] 4010004 : (compile) [ 0xa08 ] 4010005 : (compile) b(lit) [ 0x10 ] 401000a : (compile) and [ 0x23 ] 401000b : (compile) b(lit) [ 0x10 ] 4010010 : (compile) = [ 0x3c ] 4010011 : (compile) b?branch [ 0x14 ] (offset) 9 4010014 : (compile) b(') [ 0x11 ] 4010017 : (compile) b(to) [ 0xc3 ] 401001a : (compile) b(>resolve) [ 0xb2 ] 401001b : (compile) b(>resolve) [ 0xb2 ] byte-load: exception caught! ok 0 > 4010014 200 dump 4010014 11 09 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 ..��.��.�...8.. 4010024 0c e5 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa .�.�.....[.(. .� 4010034 0e 37 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 .7.,.-..NVDA,Par 4010044 65 6e 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 ent..�....#addre 4010054 73 73 2d 63 65 6c 6c 73 01 10 a5 01 11 12 0b 23 ss-cells..�....# 4010064 73 69 7a 65 2d 63 65 6c 6c 73 01 10 09 c7 09 3d size-cells...�.= 4010074 10 00 00 00 35 42 14 00 0d a6 09 33 27 09 35 24 ....5B...�.3'.5$ 4010084 c3 09 35 b2 09 41 10 00 00 00 10 27 09 35 24 01 �.5�.A.....'.5$. 4010094 11 12 0d 4e 56 44 41 2c 46 65 61 74 75 72 65 73 ...NVDA,Features 40100a4 01 10 a6 01 11 12 0a 4e 56 44 41 2c 4c 65 76 65 ..�....NVDA,Leve 40100b4 6c 01 10 a5 a5 0e 2e 09 bc 09 c3 0e 2e 01 12 09 l..��...�.�..... 40100c4 c0 09 c6 0e 2e 01 12 09 be 09 c4 0e 2e 01 12 09 �.�.....�.�..... 40100d4 bf 09 c5 0e 2e 01 12 12 03 72 65 67 01 10 a6 01 �.�......reg..�. 40100e4 11 12 0e 23 61 64 64 72 65 73 73 2d 63 65 6c 6c ...#address-cell 40100f4 73 01 10 a5 01 11 12 0b 23 73 69 7a 65 2d 63 65 s..�....#size-ce 4010104 6c 6c 73 01 10 12 1a 3a 20 64 65 63 6f 64 65 2d lls....: decode- 4010114 75 6e 69 74 20 70 61 72 73 65 2d 31 68 65 78 20 unit parse-1hex 4010124 3b cd 0c 7c 47 01 11 4a 01 11 01 12 12 0c 56 52 ;�.|G..J......VR 4010134 41 4d 2c 6d 65 6d 73 69 7a 65 01 10 a5 c3 09 52 AM,memsize..��.R 4010144 09 51 a5 18 00 16 19 0a 41 0a 4a 08 ea 3d 14 00 .Q�.....A.J.�=.. 4010154 08 19 c3 09 52 1b b2 15 ff ee 09 46 38 14 01 b0 ..�.R.�.��.F8..� 4010164 09 52 0a 41 01 1f 0e 32 b5 0e 39 b7 09 52 0a 41 .R.A...2�.9�.R.A 4010174 0d f1 c3 01 62 c2 b5 0e 3a b7 09 52 0a 41 0d f2 .��.bµ.:�.R.A.� 4010184 c2 b6 08 67 65 74 2d 6d 6f 64 65 0e 3b b7 0d cb ¶.get-mode.;�.� 4010194 c2 b6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 3c b7 ¶.show-modes.<� 40101a4 0d cc c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 3d b7 .��.set-mode.=� 40101b4 09 52 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 .R.A.��.draw-re 40101c4 63 74 61 6e 67 6c 65 0e 3e b7 09 52 0a 41 0d d5 ctangle.>�.R.A.� 40101d4 c2 ca 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c ��.fill-rectangl 40101e4 65 0e 3f b7 09 52 0a 41 0d d7 c2 ca 0e 72 65 61 e.?�.R.A.��.rea 40101f4 64 2d 72 65 63 74 61 6e 67 6c 65 0e 40 b7 09 52 d-rectangle.@�.R 4010204 0a 41 0d d6 c2 ca 06 63 6f 6c 6f 72 21 0e 41 b7 .A.��.color!.A� ok 0 > my-self . fc5ac34 ok I think this is the point I got to before. I’m not real sure what is going wrong here? Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do? Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception. b?branch 0x0009 () b(') (unnamed-fcode) [0x9c1] b(to) (unnamed-fcode) [0x9c0] b(>resolve) b(>resolve) <—Here? (unnamed-fcode) [0xddf] (unnamed-fcode) [0xe04] (unnamed-fcode) [0xe38] (unnamed-fcode) [0xe06] (unnamed-fcode) [0xce5] (unnamed-fcode) [0xdb0] (unnamed-fcode) [0xe07] (unnamed-fcode) [0xe1a] (unnamed-fcode) [0xc5b] (unnamed-fcode) [0xe28] (unnamed-fcode) [0xe20] (unnamed-fcode) [0xdfa] (unnamed-fcode) [0xe37] (unnamed-fcode) [0xe2c] (unnamed-fcode) [0xe2d] b(") ( len=0xb [11 bytes] ) " NVDA,Parent" device-name 1 encode-int b(") ( len=0xe [14 bytes] ) " #address-cells" property 0

4 5

Re: [OpenBIOS] Apple's Open Firmware.
by Jd Lyons 03 May '18

03 May '18

Ok, I got a PC bios nVidia card working by loading the FCode rom from a file in my Quicksilver. load hd:12,ppc/GMC.rom dev agp/@10 800000 1 byte-load “ agp/@10” open-dev to my-self 800000 1 byte-load bye I likely wouldn’t have to call 1 byte-load twice if I knew how to properly call device-open, I think the first time I call it, it’s setting up the open and close methods for the device, because if I do “ agp/@10” open-dev to my-self before it complains that the device has no open and close methods. OS X didn’t care for it( kernel panic ), but it didn’t properly build the compatible properties. OS 9 was fine with it, as soon as I Mac-boot/bye I get video from the card, and everything works as expected 2D/3D and DVD playback. Now I just have to figure out how to get Openbios to do this with PCI Passthrough;-) Thanks everyone.

2 1

[PATCH] openbios: compile fixes for GCC 7.3
by Mark Cave-Ayland 03 May '18

03 May '18

This fixes additional warnings found when upgrading my compiler toolset from GCC 5.x to 7.x. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- fs/hfs/hfs_fs.c | 2 +- libopenbios/video_common.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfs/hfs_fs.c b/fs/hfs/hfs_fs.c index 2d62ec0..2e63dbf 100644 --- a/fs/hfs/hfs_fs.c +++ b/fs/hfs/hfs_fs.c @@ -101,7 +101,7 @@ _search( hfsvol *vol, const char *path, const char *sname, hfsfile **ret_fd ) *p = 0; topdir = 0; - strncat( buf, ent.name, sizeof(buf) ); + strncat( buf, ent.name, sizeof(buf) - 1); if( (status=_search(vol, buf, sname, ret_fd)) != 2 ) continue; topdir = 1; diff --git a/libopenbios/video_common.c b/libopenbios/video_common.c index 9bbc18c..7496446 100644 --- a/libopenbios/video_common.c +++ b/libopenbios/video_common.c @@ -191,7 +191,7 @@ void setup_video() values in the Forth dictionary. Hence everything is always in sync. */ phandle_t options; - char buf[6]; + char buf[10]; feval("['] display-ih cell+"); video.ih = cell2pointer(POP()); -- 2.11.0

1 1

Probing the PCI bus for Option ROMs.
by Jd Lyons 06 Apr '18

06 Apr '18

Joe, if it would be something that interests you, and you have the time, we could work on adding proper PCI Probing to Openbios. As it stands the Qemu_VGA is a pci device, and Qemu loads an Option rom, but it’s the VGA Bios and Opennbios doesn’t probe for option roms. Openbios has the Fcode for the Qemu-Vga device and there is a NDRV that gets loaded from a file. What we really need is to make a proper FCode Rom image with the NDRV for the Qemu_VGA device, we could make a hybrid Bios/Fcode rom and not have to change the code in Qemu at all, I don’t think. Here are some instructions on setting up and building Openbios on OS X Intel. There is an effective tutorial on the openbios site. If you run OSX, you nee to install the fcode utils and use the awos cross compiler linked to: http://www.mediafire.com/download/wy5xg ... pilers.zip <http://www.mediafire.com/download/wy5xgj2hwjp8k4k/AWOS_Cross-Compilers.zip> This is my script to build the OpenBIOS binary: PATH=:/usr/local/ppcelf/ppcelf/bin:/users/hsp/src/fcode-utils-devel/toke:$PATH export PATH cd openbios CROSS_COMPILE=ppc-elf- ./config/scripts/switch-arch ppc #(remove -Werror from CFLAGS in Makefile.target in top directory) make Best, Cat_7 I forget the file that has the Forth for the Qemu_VGA device, Mark? Also SLOF has some code for probing option roms for at least the GeForce 6600 PCI-E card, so that maybe something we can use to add support for option roms to OB. \ ***************************************************************************** \ * Copyright (c) 2004, 2008 IBM Corporation \ * All rights reserved. \ * This program and the accompanying materials \ * are made available under the terms of the BSD License \ * which accompanies this distribution, and is available at \ * http://www.opensource.org/licenses/bsd-license.php \ * \ * Contributors: \ * IBM Corporation - initial implementation \ ****************************************************************************/ my-space pci-class-name type my-space pci-device-generic-setup pci-io-enable pci-mem-enable 30 config-l@ pci-find-fcode execute-rom-fcode : check-display ( nodepath len -- true|false ) \ true if display found and "screen" alias set \ check if display available, set screen alias 2dup find-node \ ( path len phandle|0 ) find node ?dup IF \ node found, get "display-type" property s" display-type" rot get-property ( path len true|propaddr proplen 0 ) 0= IF ( path len propaddr proplen ) \ property found, check if the value is not "NONE" s" NONE" 0 char-cat ( path len propaddr proplen str strlen ) \ null-terminated NONE string str= 0= IF ( path len ) \ "display-type" property is not "NONE" so we can set "screen" alias s" screen" 2swap set-alias true ( true ) \ return true ELSE 2drop false ( false ) \ return false THEN THEN THEN ; get-node node>path s" /NVDA,DISPLAY-A" $cat check-display 0= IF \ no display found on DISPLAY-A ... check DISPLAY-B get-node node>path s" /NVDA,DISPLAY-B" $cat check-display drop \ drop result THEN s" name" get-my-property drop s" ( " type type s" ) " type cr

3 3

Apple's Open Firmware.
by James Lyons 04 Apr '18

04 Apr '18

As an addition to our work trying to get the 6600 PCI-E working with PCI Passthrough, I've got a QuickSilver G4 and a couple of Geforce/ Quadro cards. I've been working on some FCode Roms for them, and I'd like to test them before I flash it to the EEProm, however I don't seem to have the commands correct. " agp/@10" open-dev to my-self load hd:12,\ppc\4600.rom 800000 1 byte-load That all returns ok, but the FCode doesn't seem to execute. Also, I had to strip the PCI Header from the ROM to get the load command to work. Have a look at this ROM and see if the FCode starts at 0x40, looks like it does to me?

6 29

Re: [OpenBIOS] Apple's Open Firmware.
by James Lyons 20 Mar '18

20 Mar '18

Seems I wasn't using a crossover cable, I don't know why anyone would make a yellow cable that wasn't crossover. Anyway, now I have input via telnet, but I can't get the Mac to boot to a OF telnet session? I tried to set it via nvramrc, but that doesn't seem to work: setenv auto-boot? false nvedit " enet:telnet,10.1.2.3" io nvstore setenv use-nvramrc? true reset-all Returns me to the OF prompt but no in telnet. I seem to recall doing this on an Old World Mac many years ago, I need to change the input-device and output-device to enet?

1 0

[PATCH] ofmem: restrict ofmem_claim() allocations to RAM size
by Mark Cave-Ayland 22 Feb '18

22 Feb '18

As OFMEM memory ranges don't provide an explicit upper limit, we must manually check that CIF claim calls lie within a valid maxmimum range if attempting to allocate a specific address. Since the claim method provides a 1:1 mapping between physical and virtual addresses, the valid maximum address is therefore equivalent to the machine RAM size. This fixes booting yaboot 1.3.17 which implements a top-down search using claim to find the next free memory region to locate its heap. Without this fix we blindly accept a claim for physical addresses far above the available RAM which fails silently when we try to use the mapping later. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- libopenbios/ofmem_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libopenbios/ofmem_common.c b/libopenbios/ofmem_common.c index 217bd9b..fc19d27 100644 --- a/libopenbios/ofmem_common.c +++ b/libopenbios/ofmem_common.c @@ -623,7 +623,7 @@ ucell ofmem_claim( ucell addr, ucell size, ucell align ) virt = phys = 0; if( !align ) { if( is_free(addr, size, ofmem->virt_range) && - is_free(addr, size, ofmem->phys_range) ) { + is_free(addr, size, ofmem->phys_range) && addr < get_ram_size() ) { ofmem_claim_phys_( addr, size, 0, 0, 0, 0 ); ofmem_claim_virt_( addr, size, 0, 0, 0, 0 ); virt = phys = addr; -- 2.11.0

1 1

Re: [OpenBIOS] SunOS 5.8 64bit emulate SUNW, Ultra 2
by Mark Cave-Ayland 15 Feb '18

15 Feb '18

On 14/02/18 10:57, Weidemann, Maik (M-SO) wrote: > Hello Mark, > > thanks for your answer. > > The tip with the bios binary from git was good. It’s look like my own > build is faulty. > > Now I get this error messages: > > #qemu-system-sparc64 -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c > -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios > pc-bios_openbios-sparc64 > > OpenBIOS for Sparc64 > > Configuration device id QEMU version 1 machine id 0 > > kernel cmdline > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c > > Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53 > > Type 'help' for detailed information > > Trying disk:a... > > Not a bootable ELF image > > Not a bootable a.out image > > Loading FCode image... > > Loaded 5936 bytes > > entry point is 0x4000 > > Evaluating FCode... > > open isn't unique. > > Alloc of 0x2000 bytes at 0x16000 refused. > > panic[cpu0]/thread=10408000: BOP_ALLOC failed > > 0000000010406e90 unix:boot_alloc+44 (2000, 2000, 1000, 30000016000, > 10775860, 30000014000) > > %l0-3: 000000001041aac0 0000030ffffff138 0000000000000001 > 000000001044a9c8 > > %l4-7: 0000000010449b20 0000000010449b00 000000001044a928 > 000000000000000b > > 0000000010406f40 unix:segkmem_alloc+30 (30000016000, 2000, 0, 0, > 1044dbe8, 10449f08) > > %l0-3: 0000030ffffff5c0 ffffffffffffe000 0000000000000000 > 000000001044a9c8 > > %l4-7: 0000000010449b20 0000000010449b00 000000001044e448 > 0000000010045d68 > > 0000000010407000 genunix:vmem_xalloc+3d8 (1044d620, 1044da28, > ffffffffffffffff, ffffffffffffffff, 0, 0) > > %l0-3: 0000000010045ce4 ffffffffffffe000 000000001044d620 > 0000000000002000 > > %l4-7: 0000000000000000 0000000000000000 0000000000002000 > 000000001044d640 > > 0000000010407130 genunix:kmem_slab_create+8c (0, 0, 2000, 300000043c0, > 0, 1044d620) > > %l0-3: 0000000000000000 0000030ffffff220 0000000000000000 > 000000001044a9c8 > > %l4-7: 0000000010449b20 00000300000043c0 000000001044e448 > 00000000ffecb1d0 > > 0000000010407220 genunix:kmem_cache_alloc+180 (0, 0, 0, 300000043c0, 0, 0) > > %l0-3: 0000030000004740 ffffffffffffe000 000000001044d620 0000000000002000 > > %l4-7: 0000030ffffff220 0000000000000000 0000000000002000 > 000000001044d640 > > 00000000104072d0 genunix:kmem_slab_create+130 (200, 30000014000, 2000, > 3000000da40, 0, 200) > > %l0-3: 0000000000000000 ffffffffffffe000 000000001044d620 > 0000000000002000 > > %l4-7: 0000030fffffef68 000003000000da40 0000000000002000 > 000000001044d640 > > 00000000104073c0 genunix:kmem_cache_alloc+180 (0, 0, 0, 3000000da40, 0, 0) > > %l0-3: 000003000000ddc0 0000000000000000 0000000000010000 > ffffffffffffffff > > %l4-7: 0000030000013fc8 00000300000052c0 0000030000013fc8 > 0000030000013fc0 > > 0000000010407470 genunix:kmem_alloc+2c (2000, 0, 2000, 3000000da40, 0, > 30000013fb8) > > %l0-3: 0000030000005640 000000001013671a 0000000000000000 0000000000000020 > > %l4-7: 0000000010445280 000000001045114b 0000000000000000 > 0000000000000000 > > 0000000010407520 krtld:kobj_zalloc+c (2000, 1000, 2000, 300000052c0, f0, 0) > > %l0-3: 000003000000e740 ffffffffffffffc0 000000001044e4e8 00000000000003c0 > > %l4-7: 0000000010449678 0000000000000000 0000000000000000 > 000000000000000b > > 00000000104075d0 krtld:kobj_open_file+38 (2000, 30000011f88, 10438418, > 0, 0, 1) > > %l0-3: 0000000000000008 0000000000000000 0000000000000000 > 0000000000000000 > > %l4-7: 0000000000000008 0000000010045ce4 0000000010451140 > 0000000010045d68 > > 0000000010407680 genunix:mod_read_system_file+70 (10436800, 2000, 1, 0, > 26, 10438d20) > > %l0-3: 0000000000004000 0000000000000008 0000000000004008 > 0000000000000000 > > %l4-7: 0000000000002000 0000000010045ce4 0000000010450278 > 0000000010045d68 > > 00000000104077a0 genunix:kmem_init+1b8 (10460470, 0, 0, 10614bd0, > 10775c80, 30000016160) > > %l0-3: 000000001041d000 0000000000002000 0000000010045ce4 > 0000000010045d68 > > %l4-7: 0000000010417ea8 0000000000001fff 000000001040d920 > 00000000ffecb1d0 > > 0000000010407870 unix:startup_memlist+99c (10417c00, 300000160a0, > 10417ee0, 10417eb0, 10417ec8, 30000016000) > > %l0-3: 0000000000000103 0000030000000000 0000000010423000 > 0000000010424190 > > %l4-7: 0000000000000000 0000000000002000 0000030000016000 > 000000001041c800 > > 0000000010407970 unix:startup+c (10428000, 0, 0, 7e7c000, 2000, > ffffffffffffffff) > > %l0-3: 00000000100243b8 000000000000cbec 000000000000114c > 0000000000000000 > > %l4-7: 00000000104619b8 00000000002de9d8 00000000000b514c > 000000000000114c > > 0000000010407a20 genunix:main+4 (1040d400, 2000, 10407ec0, 10408030, > fff2, 1004df8c) > > %l0-3: 0000000010408000 0000000000000001 0000000000000015 > 0000000000000e69 > > %l4-7: 00000000104287b0 00000000104619b8 00000000000ca6a0 > 0000000000000540 > > skipping system dump - no dump device configured > > rebooting... > > BOOTpanic - kernel: prom_reboot: reboot call returned! > > EXIT > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > boot disk > > Not a Linux kernel image > > Not a bootable ELF image > > Not a bootable a.out image > > Loading FCode image... > > Loaded 5936 bytes > > entry point is 0x6000 > > Evaluating FCode... > > open isn't unique. > > Boot load failed. > > Do the error messages come from the Bios or already from the booting OS? Those are from the Solaris kernel so that's a good start. This looks similar to what I get from my Solaris 9 test ISO and I suspect it's related to memory initialisation. Solaris 11 gets all the way to userspace, but still needs the MMU IE support added to QEMU. > When I try to start the vm with the define of the disk, who it described > in the current documentation > (https://wiki.qemu.org/Documentation/Platforms/SPARC#All_PCI_devices_are_att…), > > then I get this notification: > > #qemu-system-sparc64 > > -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c \ > > -nographic \ > > -drive > id=hd,if=none,file=/var/lib/libvirt/images/sun14_disk.raw,format=raw \ > > -device virtio-blk-pci,bus=pciB,drive=hd \ > > -L . \ > > -bios pc-bios_openbios-sparc64 \ > > -m 256 > > OpenBIOS for Sparc64 > > Configuration device id QEMU version 1 machine id 0 > > kernel cmdline > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c > > Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53 > > Type 'help' for detailed information > > Trying disk:a... > > No valid state has been set by load or init-program > > What mean the message “No valid state has been set by load or > init-program”? Wrong disk? Or try to boot form wrong / faulty partion? Yeah, that means that "load" couldn't locate a supported binary format to execute from the boot device. Sadly OpenBIOS doesn't (yet) boot from virtio devices, but you can boot from the CDROM in Linux and add a separate virtio drive to get extra speed if you really want to. Also I believe that Solaris has doesn't have virtio drivers anyway, so I don't think you'd manage to get far there either. To the best of my knowledge, only Linux and NetBSD support virtio devices on qemu-system-sparc64 to date. ATB, Mark.

1 0

Re: [OpenBIOS] SunOS 5.8 64bit emulate SUNW, Ultra 2
by Mark Cave-Ayland 14 Feb '18

14 Feb '18

On 13/02/18 13:15, Weidemann, Maik (M-SO) wrote: Hi Maik, > Hello, > > I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu. > As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu. > The qemu Version is: > QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0) > > I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message: > # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw > OpenBIOS for Sparc64 > set_property: NULL phandle > set_property: NULL phandle > Unhandled Exception 0x0000000000000030 > PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc > Stopping execution Yes, unfortunately that combination of QEMU/OpenBIOS won't work because at the moment there is no way to pass the device tree from QEMU to OpenBIOS and so the two must generally be kept in sync. Hopefully this requirement will be something that can be relaxed in time. > I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message: > # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf > Unhandled Exception 0x0000000000000030 > PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c > Stopping execution Something definitely looks wrong there - for 2.11 have you tried grabbing the relevant OpenBIOS binary direct from git? It's available as a direct download from https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/openbios-sparc64;h=a4a3b8…. > Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)? > SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2 The default sun4u model emulates an Ultra 5, so assuming your image contains enough drivers then in theory you should be able to at least boot into the kernel and get somewhere close to userspace. To the best of my knowledge the main outstanding feature missing from the SPARC64 emulation preventing it from booting SunOS is the MMU IE bit which is required to program PCI devices. I suspect this will still be the case for SunOS 5.8. There has been a lot of work done over the past couple of releases to fix up all the PCI bridge issues so I would hope that getting qemu-system-sparc64 to boot Solaris 64-bit is now within reach, so watch this space :) ATB, Mark.

2 1

SunOS 5.8 64bit emulate SUNW, Ultra 2
by Weidemann, Maik (M-SO) 13 Feb '18

13 Feb '18

Hello, I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu. As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu. The qemu Version is: QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0) I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message: # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw OpenBIOS for Sparc64 set_property: NULL phandle set_property: NULL phandle Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc Stopping execution I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message: # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c Stopping execution Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)? SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2 Best regards Maik

1 0

Apple's BootX
by Jd Lyons 02 Feb '18

02 Feb '18

In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code. I found some BootX sources at: https://opensource.apple.com/tarballs/BootX/ <https://opensource.apple.com/tarballs/BootX/> Tho I’m not sure what versions correspond to which release of OS X? And it’s not clear how to build them, tho I haven’t tried yet. I found some info on BootX as well as some idea how to do what I’m looking to do: https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf There are few other useful debugging tech- niques. Setting "auto-boot?" to false will cause the system to enter the OpenFirmware User In- terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution. I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends some info to the screen, seemingly via open firware, while displaying the “Apple Logo” boot graphic. The info show some of the boot process and what stage it’s loading” loading mach_kernel’ “ loading the .mkext” It would be nice to get this output going via Open Bios, if anyone has any idea how I might be able to do that?

8 34

L2 Cache Settings
by James Lyons 30 Jan '18

30 Jan '18

Looks like for the 7447a we set SPR 1017( L2CR ) bit 0 ( L2E ) or just write 0x8000000 to the reg. Not sure how we do this in Openbios.

4 13

Re: [OpenBIOS] Apple's BootX
by Jd Lyons 28 Jan '18

28 Jan '18

> On Jan 27, 2018, at 4:22 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: > > >> like for example how Apple added Penryn support to 10.4.11 even tho the first Penryn macs shipped with 10.5” >> >> PK, I wonder why removing Bail/halt if unknown CPU doesn’t make the 7447a cpu boot this kernel. >> >> Anyway, if you could give me so tips on building a new kernel, I’ll play around with it and see if I can get some more cpu’s in qemu-ppc to boot. > > Attached are all the software I used to help build the XNU kernel. Let me know if you have any difficulties with installing them. You should build Mac OS 10.4's kernel on Mac OS 10.4.<bootstrap_cmds-49.tar.gz><cctools-622.3.tar><IOKitUser-277.6.tar.gz><kext_tools-59.tar.gz><Libstreams-24.1.tar.gz><xnu-compiletools-20050515.tar.bz2> Thanks PK, I’l give it a go.

1 0

[PATCH 0/5] SPARC: implement power-off functionality
by Mark Cave-Ayland 24 Jan '18

24 Jan '18

These patches, in conjunction with the corresponding QEMU patch, implement the power-off word for SPARC32 and SPARC64. For SPARC64 we also implement the SUNW,power-off CIF service which is used by most OSs to power down the machine. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (5): admin: add power.fs with initial dummy power-off implementation SPARC32: implement power-off word SPARC64: add power device under the ebus device SPARC64: implement power-off word ciface.fs: implement SUNW,power-off service arch/sparc64/openbios.c | 27 +++++++++++++++++++++++++++ drivers/obio.c | 10 ++++++++++ drivers/pci.c | 34 ++++++++++++++++++++++++++++++++++ forth/admin/build.xml | 1 + forth/admin/power.fs | 9 +++++++++ forth/system/ciface.fs | 8 ++++++++ 6 files changed, 89 insertions(+) create mode 100644 forth/admin/power.fs -- 2.11.0

1 6

Patch:Add 7447a support.
by Jd Lyons 21 Jan '18

21 Jan '18

This patch should get all 7447a cpus working with openbios, needs a corresponding patch to Qemu-ppc for the v1.5 diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 5ce080c..09b2db4 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -550,6 +550,18 @@ static const struct cpudef ppc_defs[] = { .tlb_size = 0x80, .initfn = cpu_g4_init, }, + .iu_version = 0x80030000, + .name = "PowerPC,G4", + .icache_size = 0x8000, + .dcache_size = 0x8000, + .icache_sets = 0x80, + .dcache_sets = 0x80, + .icache_block_size = 0x20, + .dcache_block_size = 0x20, + .tlb_sets = 0x40, + .tlb_size = 0x80, + .initfn = cpu_g4_init, +}, { .iu_version = 0x00390000, .name = "PowerPC,970",

3 6

Adding support for more CPUs
by Jd Lyons 20 Jan '18

20 Jan '18

As an addition to my post at qemu-ppc, I’d like to add support for a few more cpus to Openbios, so when I get KVM to support -cpu host: openbios will be able to boot from the cpu’s I have. Right now I have a Powerbook6,8 with a 7447a ( PRV 80030105 ) I think this CPU is V1.5. I also have a iBook with a 750fx ( PVR 70000112 ). Soon I will have a Quicksilver with Dual 1Ghz G4’s, and an iBook G4 with a 7447a, not sure of the PVR’s yet. So, I see that I need to edit the init.c, and I noticed we might need some real values from some of the chips. { // XXX find out real values .iu_version = 0x800c0000, .name = "PowerPC,74xx", .icache_size = 0x8000, .dcache_size = 0x8000, .icache_sets = 0x80, .dcache_sets = 0x80, .icache_block_size = 0x20, .dcache_block_size = 0x20, .tlb_sets = 0x40, .tlb_size = 0x80, .initfn = cpu_750_init, Mark, how can I get the values needed from my CPU’s? I’m assuming we need the values for the .icach_size etc.

4 4

[PATCH 0/2] x86 build fixes
by Mark Cave-Ayland 19 Jan '18

19 Jan '18

Following up from the x86 build failures reported on-list by Jens, here are the proper unsquashed versions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): pci: fix compilation for architectures where OFMEM isn't available x86: remove static declaration from mbheader definition arch/x86/multiboot.c | 2 +- drivers/pci.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.11.0

1 3

Re: [OpenBIOS] failed to build
by BALATON Zoltan 13 Jan '18

13 Jan '18

On Fri, 12 Jan 2018, Jens Bauernfeind wrote: > I build openbios in the x86 version and added the openbios-bultin.elf as addtional payload to the image (with seabios as primary, so i could easily test openbios ) > Unfortunately when I start it, it doesn't recognize the keyboard and several messages "cannot manage <device name>...." > I know that the laptop keyboard is attached via PS/2, and in the drivers/pci.c is a PS2 Keyboard block. This is not relevant to PS/2 keyboard but the "cannot manage" messages about USB devices reminded me that I've only ported the OHCI driver from coreboot so it likely won't work on a PC where UHCI (or EHCI) is more common. If you want to use USB peripherals then you may need to port at least one of those too. If you also want to boot from USB then maybe the usbmsc driver will also be needed which I've also skipped (I've only added a HID driver in OpenBIOS sufficient for a keyboard so that's the only thing expected to work currently). In case you've tried booting from an HDD not from a USB drive then I'd check if that has a driver (if the ATA/SATA controller is mentioned in one of the cannot manage lines then it's likely missing a driver). Looking at drivers/pci_database.c I think we only have driver for virtio and CMD646 based IDE controllers although the IDE one may work for similar controllers, but I'm not sure about that. Regards, BALATON Zoltan

1 0

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

On 12/01/18 13:55, Jens Bauernfeind wrote: > Directly pointing to openbios-builtin.elf shows this: > qemu: could not load PC BIOS > :-( That's a shame. Does it work using the instructions from the previous link I sent through? https://www.coreboot.org/QEMU#coreboot_v3_.2B_OpenBIOS ATB, Mark.

3 2

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

On 12/01/18 13:19, Jens Bauernfeind wrote: > It seems that out of the box my coreboot image is not able to start in qemu: > 8<--- > qemu-system-x86_64 -M q35 -bios coreboot/build/coreboot.rom -nographic > qemu-system-x86_64: Trying to execute code outside RAM or ROM at 0x00000000000a0000 > 8<--- > > Jens How about instead pointing directly to the OpenBIOS ELF binary instead, e.g. -bios path/to/openbios.elf? That should definitely work. Also you can try both with and without -nographic depending upon whether the VGA driver is enabled or not. ATB, Mark.

2 1

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

On 12/01/18 12:32, Jens Bauernfeind wrote: > Hi Mark, > > the keyboard is still not working, but the line with the ISA bridge disappeared. > > Jens Gah, that's a shame. Do you see the same issue in QEMU with the q35 machine i.e. qemu-system-x86 -M q35 -bios path/to/bios ? If I can reproduce it here, I'm sure I can debug it. ATB, Mark.

2 1

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

On 12/01/18 11:03, Jens Bauernfeind wrote: > Hi Mark, > > I installed coreboot succesfully on my t430. > I build openbios in the x86 version and added the openbios-bultin.elf as addtional payload to the image (with seabios as primary, so i could easily test openbios ) > Unfortunately when I start it, it doesn't recognize the keyboard and several messages "cannot manage <device name>...." > I know that the laptop keyboard is attached via PS/2, and in the drivers/pci.c is a PS2 Keyboard block. > Is there anything I can debug? > > Best Regards, > Jens Fascinating, thanks for the screenshot! I suspect the issue with the keyboard is because it exists behind the PCI-ISA bridge, and since OpenBIOS isn't able to match your particular bridge against its internal list then it never generates the appropriate DT nodes. Now it appears that OpenBIOS does have a default set of legacy devices for the i82378 PCI-ISA bridge, however they should be equally valid for your QM77 PCI-ISA bridge and fairly standard. How about the attached patch which renames i82378_config_cb() to isa_bridge_config_cb() and also adds in the PCI device and vendor ids for your particular PCI-ISA bridge into the OpenBIOS configuration? If this is able to get your keyboard working, a photo of the output of "show-devs" would be quite helpful :) ATB, Mark.

2 1

failed to build
by mr.jb＠gmx.de 12 Jan '18

12 Jan '18

Hello, I want to build the openbios image for use in coreboot, but it fails. I am running a 32bit debian 8.10 vm. $ make /usr/bin/xsltproc Building OpenBIOS for x86 Building... error: AR libfs.a CC target/libgcc/ashldi3.o CC target/libgcc/ashrdi3.o CC target/libgcc/__lshrdi3.o CC target/libgcc/__divdi3.o CC target/libgcc/__udivdi3.o CC target/libgcc/__udivmoddi4.o CC target/libgcc/__umoddi3.o AR libgcc.a LINK openbios.multiboot libdrivers.a(pci.o): In function `ob_pci_unmap': /tmp/openbios/drivers/pci.c:405: undefined reference to `ofmem_unmap' rules.mak:235: recipe for target 'openbios.multiboot' failed make[1]: *** [openbios.multiboot] Error 1 make[1]: Leaving directory '/tmp/openbios/obj-x86' Makefile:19: recipe for target 'build' failed make: *** [build] Error 1 if i select amd64 on a 64bit machine it works without a problem. What is the problem here? Thanks Jens

3 4

Re: [OpenBIOS] b?branch
by Jd Lyons 02 Jan '18

02 Jan '18

> On Dec 29, 2017, at 12:14 AM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2017-Dec-29 00:00 , Jd Lyons wrote: >> >> Segher, do you think I maybe tripping over the “ config-l@“? >> >> Seems to be a few words called next, after the b(>resolve) I’m catching the exception on. >> >> config-l@ >> config-l! >> config-w@ >> config-w! > > Those are words to read and write config space on pci cards. I'm pretty sure the words work (otherwise the vendor-id and product-id values wouldn't have been able to be fetched), the question is whether they are being called with unexpected values. The config-l@ must be called with a mod 4 values, the config-w@ must be called with a mod 2 value. > > The usual mode of accessing config space is adding your desired offset to my-space, and then call config-l@. That looks to be what you are in the middle of: > > 8010039 : (compile) [ 0x9bd ] > 801003a : (compile) b(lit) [ 0x10 ] > 801003f : (compile) and [ 0x23 ] > 8010041 : (compile) my-space [ 0x103 ] > 8010042 : (compile) + [ 0x1e ] > 8010044 : (compile) [ 0xa08 ] <<<<<<< is this config-l@? > 8010045 : (compile) b(lit) [ 0x10 ] > 801004a : (compile) and [ 0x23 ] > 801004b : (compile) b(lit) [ 0x10 ] > 8010050 : (compile) = [ 0x3c ] > > The above looks to me like he's testing for the presence of 0x10 in a register (0x10 and 0x10 =). If he's looking at a series of BARs, that's the prefetchable bit he's looking for. > Do you think it’s having trouble reading the PCI Configuration registers, it was able to change the subsystem-id from 0x50 to 0x10, so I was hoping it had calculated the base address of the PCI card correctly. I’m really at a loss, never had to dive this deep into forth when hacking these Rom’s for card flashing. It seemed to me that: b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08 new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 ) I’m sure I’m being too linear in my thinking, as you’ve already pointed out, my-space and config-l@ were called before my exception. I just can’t figure out what is throwing the exception?

5 22

[PATCH] Add tbu@ and tbl@ words
by John Arbuckle 30 Dec '17

30 Dec '17

The PowerPC timebase register is made available to forth using the tbu@ and tbl@ words. The tbu@ word pushes the upper 32 bits of this register. The tbl@ word pushes the lower 32 bits of this register. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> --- arch/ppc/qemu/init.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 5ce080c..d12084c 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -751,6 +751,22 @@ static void adler32(void) RET(s2 << 16 | s1); } +/* reads the upper timebase register ( -- tbu ) */ +static void get_tbu(void) +{ + int time; + asm volatile("mftbu %0" : "=r"(time)); // load from TBU register + PUSH(time); +} + +/* reads the lower timebase register ( -- tbl ) */ +static void get_tbl(void) +{ + int time; + asm volatile("mftb %0" : "=r"(time)); // load from TBL register + PUSH(time); +} + void arch_of_init(void) { @@ -1022,4 +1038,8 @@ arch_of_init(void) bind_func("platform-boot", boot); bind_func("(arch-go)", arch_go); + + /* Makes the timebase register accessible from forth */ + bind_func("tbu@", get_tbu); + bind_func("tbl@", get_tbl); } -- 2.14.3 (Apple Git-98)

5 13

Re: [OpenBIOS] b?branch
by Jd Lyons 30 Dec '17

30 Dec '17

> On Dec 28, 2017, at 7:08 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: > >> >> On Dec 28, 2017, at 7:05 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >> >> >> >>> On Dec 28, 2017, at 3:02 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>> >>>> >>>> On Dec 28, 2017, at 11:01 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>> >>>> >>>> >>>>> On Dec 28, 2017, at 10:47 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> On Dec 28, 2017, at 10:39 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Dec 28, 2017, at 10:20 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Dec 28, 2017, at 10:13 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 28, 2017, at 9:56 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 28, 2017, at 9:36 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Dec 27, 2017, at 5:02 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Dec 21, 2017, at 6:51 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 21 Dec 2017, Programmingkid wrote: >>>>>>>>>>>>>> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >>>>>>>>>>>>>> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>>>>>>>>>>>>>> On Dec 21, 2017, at 9:59 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>>>>>>>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>>>>>>>>>>> I don’t know, this maybe an issue with the way we have defined “us”. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure the us word is related to problems with b?branch but I don't know anything about this other than reading the conversation here. They look unrelated to me but it could well be I did not undersand this at all. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looking through the SLOF code it seems they call it like this in the timebase.fs: >>>>>>>>>>>>>>>>> : tb@ ( -- tb ) >>>>>>>>>>>>>>>>> BEGIN tbu@ tbl@ tbu@ rot over <> WHILE 2drop REPEAT >>>>>>>>>>>>>>>>> 20 lshift swap ffffffff and or >>>>>>>>>>>>>>>>> ; >>>>>>>>>>>>>>>>> : milliseconds ( -- ms ) tb@ d# 1000 * tb-frequency / ; >>>>>>>>>>>>>>>>> : microseconds ( -- us ) tb@ d# 1000000 * tb-frequency / ; >>>>>>>>>>>>>>>>> : ms ( ms-to-wait -- ) milliseconds + BEGIN milliseconds over >= UNTIL drop ; >>>>>>>>>>>>>>>>> : get-msecs ( -- n ) milliseconds ; >>>>>>>>>>>>>>>>> : us ( us-to-wait -- ) microseconds + BEGIN microseconds over >= UNTIL drop ; >>>>>>>>>>>>>>>>> Not sure if I can port/hack this code over, the copier seems to have trouble with tbu@ tbl@? >>>>>>>>>>>>>>>> The ms and get-msecs words don't appear to be implemented correctly on OpenBIOS. 10000 ms should pause OpenBIOS for 10 seconds. It does not. >>>>>>>>>>>>>>>> I did find a function called udelay() in the drivers/timer.c file. Maybe I can implement the word us using udelay(). Then the ms word could be implemented using the us word. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See what you can do about : us, but we maybe running into an issue with Qemu/mac99. Every version of the Mac OS reports a different bus and cpu speed, so we maybe having trouble with the way the timebase is calculated in Qemu. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you have two choices for this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Either export udelay (or _wait_ticks it's based on) to Forth and implement these words based on that. But this comment in drivers/timer.c: >>>>>>>>>>>>> >>>>>>>>>>>>> How would I do this? >>>>>>>>>>>>> >>>>>>>>>>>>>> /* >>>>>>>>>>>>>> * TODO: pass via lb table >>>>>>>>>>>>>> */ >>>>>>>>>>>>>> unsigned long timer_freq = 10000000 / 4; >>>>>>>>>>>>>> >>>>>>>>>>>>>> suggests you may need to fix this first to take into accound the actual TB frequency from the CPU instead of some hardcoded value. >>>>>>>>>>>>> >>>>>>>>>>>>> This would make a good next step. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Alternatively, you could either add new helpers (maybe in arch/ppc/timebase.S) to implement tbl@ and tbu@ which probably should just do mftb and mftbu respectively or export to Forth the already existing _get_ticks which returns these as a combined 64 bit value and derive the lower and upper 32 bits from Forth and then maybe you can use the above implementation from SLOF. >>>>>>>>>>>>> >>>>>>>>>>>>> It is a possibility. >>>>>>>>>>>>> >>>>>>>>>>>>> We still need a way to access any new C function from forth. The only thing that I think would work is implementing the us word in a device node, then make another definition of us that is available to the dictionary. If anyone has a way to do this, an example would be great. >>>>>>>>>>>> >>>>>>>>>>>> I don't know much about this but looking at the code I think _get_ticks is almost equivalent to tb@ above except that _get_ticks returns tbu@ in %r3 and tbl@ in %r4 but tb@ also combines these into one value. Then you can see e.g. in arch/ppc/qemu/init.c that the bind_func() function is used to make C functions available from Forth. So you could make a C function which calls _get_ticks then combines %r3 and %r4 into a 64bit value (so implements what tb@ does in C) then bind this to tb@. Or bind _get_ticks and implement tb@ calling this and combining the upper and lower values from Forth like above (I think this is what '20 lshift swap ffffffff and or' does but I don't know Forth to tell). >>>>>>>>>>>> >>>>>>>>>>>> You'll also need tb-frequency which can be found in the cpu properties (added in arch/ppc/qemu/init.c by reading the correct value from QEMU). SLOF has a function that seems to be called during init but I can't read Forth enough to tell for sure what it actually does: >>>>>>>>>>>> >>>>>>>>>>>> \ Fixup timebase frequency from device-tree >>>>>>>>>>>> : fixup-tbfreq >>>>>>>>>>>> " /cpus/@0" find-device >>>>>>>>>>>> " timebase-frequency" get-node get-package-property IF >>>>>>>>>>>> 2drop >>>>>>>>>>>> ELSE >>>>>>>>>>>> decode-int to tb-frequency 2drop >>>>>>>>>>>> THEN >>>>>>>>>>>> device-end >>>>>>>>>>>> ; >>>>>>>>>>>> fixup-tbfreq >>>>>>>>>>>> >>>>>>>>>>>> But I think this is what sets tb-frequency global value so you'll probably need something similar somewhere (maybe ppc.fs). Then you have tb@ and tb-frequency so the rest should work. >>>>>>>>>>>> >>>>>>>>>>>> Now it's your turn to find out how to do this in OpenBIOS. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> BALATON Zoltan >>>>>>>>>>> >>>>>>>>>>> This code can be directly pasted into OpenBIOS: >>>>>>>>>>> >>>>>>>>>>> 0 value tb-frequency >>>>>>>>>>> >>>>>>>>>>> \ Fixup timebase frequency from device-tree >>>>>>>>>>> : fixup-tbfreq >>>>>>>>>>> " /cpus/@0" find-device >>>>>>>>>>> " timebase-frequency" active-package get-package-property IF >>>>>>>>>>> 2drop >>>>>>>>>>> ELSE >>>>>>>>>>> decode-int to tb-frequency 2drop >>>>>>>>>>> THEN >>>>>>>>>>> device-end >>>>>>>>>>> ; >>>>>>>>>>> fixup-tbfreq >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I applied your patch, and used this code in Openbios, then booted the Mac OS to see if it reported the correct Bus Frequency, but it still reporting 400mhz bus speed. >>>>>>>>> >>>>>>>>> How do you define "correct bus frequency"? >>>>>>>>> >>>>>>>>> From what I remember Mac OS only supports certain bus frequencies. Well I'm not sure if it was bus or CPU frequencies that I am thinking about. >>>>>>>>> >>>>>>>> Seems to be just the ASP getting the Bus Frequency wrong, for mac99. It reposts it correct for g3beige, and skidmarks GT reports the correct Timebase for each. Mac99 isn’t really any one machine, so I’t no wonder we have these odd quirks. >>>>>>> >>>>>>> What is Apple System Profiler reporting as the bus frequency? It is calculating it, looking the value up in a table, or reading the value from hardware. >>>>>> >>>>>> For mac99 it reports 400mhz bus speed, for g3biege it reports 67mhz( This is correct 4x the timebase ) There maybe some code in Qemu that is multiplying the timebase by 4 to set the bus speed, I haven’t looked into it. Really, it doesn’t matter, as long as the timebase is reported correctly, and it is. >>>>>> >>>>>>> >>>>>>>> Are you trying to get the correct timing for the ms and us words, was that part of the point of your patch? >>>>>>> >>>>>>> I was trying to make the words from SLOF work on OpenBIOS. Making the ms and us words work correctly would be an added bonus. I was debating on whether the tb-frequency value should be calculated instead of just copied. If it was calculated, then words like ms and us would work correctly. >>>>>> >>>>>> Yes, I think the issue I’m having with the nVidia option rom is related to the us word, as all the b?branch and b(<resolve) words work correct until us is called. >>>>>> >>>>>> I wish I could be more help, but we’re way over my head now. >>>>>> >>>>>> I can’t seem to debug the us word, when I call debug us, then 4000040 1 byte-load, it just goes right past the us word? >>>>> >>>>> I don't think you need to debug the us word. All it does is delay execution for a specified amount of microseconds. Would it help if I implemented the us word in C instead of forth? >>>> >>>> I’m not sure how long the delay should be: >>>> >>>> : us ( n — ) d# 1000 / 1+ ms ; >>>> >>>> Seems to do the same thing SLOF does: >>>> >>>> >>>> : tb@ ( -- tb ) >>>> BEGIN tbu@ tbl@ tbu@ rot over <> WHILE 2drop REPEAT >>>> 20 lshift swap ffffffff and or >>>> ; >>>> >>>> : milliseconds ( -- ms ) tb@ d# 1000 * tb-frequency / ; >>>> : microseconds ( -- us ) tb@ d# 1000000 * tb-frequency / ; >>>> >>>> : ms ( ms-to-wait -- ) milliseconds + BEGIN milliseconds over >= UNTIL drop ; >>>> : get-msecs ( -- n ) milliseconds ; >>>> : us ( us-to-wait -- ) microseconds + BEGIN microseconds over >= UNTIL drop ; >>>> >>>> But the system doesn’t pause that I can tell, when the us word is called. >>>> >>>> I was just hoping this was the issue I was having, that ms and us were not working the way they should, and the fcode was “trying” to write a register before the state of the card was “ready”, if that makes sense. >>>> >>>> It would be helpful if you could add the us word to openbios, save me from typing it in each time, and it’s always better to have more words in our emulator. >>>> >>>> Thanks >>> >>> Ok this will add the us and ms words to the dictionary. I hand tuned them to actually be accurate on my system. I don't know how accurate they will be on your system. Hopefully it will be enough to move forward with the video card work. >>> <0001-add-support-for-ms-and-us-words.patch> >>> You can adjust the multiplier variable to meet your needs. To test it out you would need a stop watch or a stop watch app. >>> In the openbios terminal type these commands: >>> decimal >>> 10000 ms >>> >>> If this delays openbios by 10 seconds, then the ms word is working on your system. >>> >>> The us word would be tested like this: >>> decimal >>> 1000000 us >>> >> >> Not sure, us is still an undefined word, and: >> >> decimal >> 10000 ms >> >> Just returns OK immediately. >> >> I think I got e patch right? >> >> >> <init.c> > > The file looks correct. Are you sure you using the right openbios file? Did you rebuild openbios after applying the patch? Got the wrong build dir ;-( I can’t seem to apply both patches, assuming the second patch for ms and us relies on the first? patch -p3 < /Users/jam/Desktop/0001-add-support-for-ms-and-us-words.patch can't find file to patch at input line 15 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From c33e547fc38f1c8ddb49addb76aa6fc97407a0f6 Mon Sep 17 00:00:00 2001 |From: John Arbuckle <programmingkidx(a)gmail.com> |Date: Thu, 28 Dec 2017 14:54:04 -0500 |Subject: [PATCH] add support for ms and us words | |Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> |--- | arch/ppc/qemu/init.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1 file changed, 69 insertions(+) | |diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c |index 5ce080c..bbb2c4e 100644 |--- a/arch/ppc/qemu/init.c |+++ b/arch/ppc/qemu/init.c -------------------------- File to patch: /Users/jam/obnew2/master/arch/ppc/qemu/init.c patching file /Users/jam/obnew2/master/arch/ppc/qemu/init.c Jamess-Mac-Pro:master jam$ patch -p3 < /Users/jam/Desktop/0001-Add-tbu-and-tbl-words.patch can't find file to patch at input line 20 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From 7c267d518a22f7762013da5b5c5d5bbb162ab3ce Mon Sep 17 00:00:00 2001 |From: John Arbuckle <programmingkidx(a)gmail.com> |Date: Wed, 27 Dec 2017 13:28:17 -0500 |Subject: [PATCH] Add tbu@ and tbl@ words | |The PowerPC timebase register is made available to forth using |the tbu@ and tbl@ words. The tbu@ word pushes the upper 32 bits |of this register. The tbl@ word pushes the lower 32 bits of |this register. | |Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> |--- | arch/ppc/qemu/init.c | 20 ++++++++++++++++++++ | 1 file changed, 20 insertions(+) | |diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c |index 5ce080c..d12084c 100644 |--- a/arch/ppc/qemu/init.c |+++ b/arch/ppc/qemu/init.c -------------------------- File to patch: /Users/jam/obnew2/master/arch/ppc/qemu/init.c patching file /Users/jam/obnew2/master/arch/ppc/qemu/init.c Hunk #1 succeeded at 818 with fuzz 1 (offset 67 lines). Hunk #2 FAILED at 1105. 1 out of 2 hunks FAILED -- saving rejects to file /Users/jam/obnew2/master/arch/ppc/qemu/init.c.rej Jamess-Mac-Pro:master jam$ Just applying the us/ms patch did allow me to debug the b(>resolve) word that I am catching the exception on: 8010035 : b?branch [ 0x14 ] (offset) 26 8010039 : (compile) [ 0x9bd ] 801003a : (compile) b(lit) [ 0x10 ] 801003f : (compile) and [ 0x23 ] 8010041 : (compile) my-space [ 0x103 ] 8010042 : (compile) + [ 0x1e ] 8010044 : (compile) [ 0xa08 ] 8010045 : (compile) b(lit) [ 0x10 ] 801004a : (compile) and [ 0x23 ] 801004b : (compile) b(lit) [ 0x10 ] 8010050 : (compile) = [ 0x3c ] 8010051 : (compile) b?branch [ 0x14 ] (offset) 9 8010054 : (compile) b(') [ 0x11 ] 8010057 : (compile) b(to) [ 0xc3 ] 801005a : (compile) b(>resolve) [ 0xb2 ] : b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c0: execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c4: (semis) [ Finished b(>resolve) ] 801005b : (compile) b(>resolve) [ 0xb2 ] : b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff469c0: execute-tmp-comp byte-load: exception caught! ok

3 4

b?branch
by Jd Lyons 28 Dec '17

28 Dec '17

I’ve run into trouble with b?branch not working as expected by the nVidia Option Rom Fcode. What Openbios does now for b?branch is: From fcode.fs: === \ b?branch ( continue? -- ) \ Conditional branch FCode. Followed by FCode-offset. : b?branch fcode-offset 0< if \ if we jump backwards, we can forsee where it goes ['] do?branch , resolve-dest execute-tmp-comp else setup-tmp-comp ['] do?branch , here 0 0 , then- ; immediate === I fond some code from SLOF that may work a little better: : b?branch ( flag -- ) ?compile-mode IF read-fcode-offset ?negative IF dest-on-top postpone until ELSE postpone if THEN ELSE ( flag ) IF fcode-offset jump-n-ip \ Skip over offset value ELSE read-fcode-offset ?jump-direction jump-n-ip THEN THEN ; immediate Unfortunately it’s not just a simple copy and paste, I get errors when trying to compile Openbios with this code. When you have time, could you help me step though it and figure out where it is failing, and how to fix it, I’m just not very good at C and could really use some help from someone that understands what the code is trying to do, and what I need to port over from SLOF to get it to compile. Thanks, James

4 24

[PATCH] libopenbios/bootinfo_load.c: Implement Mac OS 9.2 boot script support
by Programmingkid 25 Dec '17

25 Dec '17

This patch makes booting Mac OS 9.2 possible. It replaces all occurrences of >r and r> with sub_>r and sub_r>. This allows for the return stack to be left alone. This patch also makes it so that the boot script is executed one line at a time. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Note: this patch depends on the strstr() and return stack substitution patches. Index: libopenbios/bootinfo_load.c =================================================================== --- libopenbios/bootinfo_load.c (revision 1395) +++ libopenbios/bootinfo_load.c (working copy) @@ -19,6 +19,7 @@ #include "libopenbios/bootinfo_load.h" #include "libopenbios/ofmem.h" #include "libc/vsprintf.h" +#include "libc/string.h" //#define DEBUG_BOOTINFO @@ -116,6 +117,75 @@ return LOADER_NOT_SUPPORT; } +// Replace all occurrences of orig_str in buffer with replace_str +static void replace_string(char *buffer, const char *orig_str, const char *replace_str) +{ + char *ptr; + int index, new_buf_index = 0; + const int max_size = 5000; + char *new_buffer = malloc(max_size * sizeof(char)); + + for (index = 0; index < strlen(buffer); index++) { + if (buffer[index] == orig_str[0]) { + ptr = strstr(buffer + index, orig_str); + + // if we encountered an orig_str in the buffer + if (index == (ptr - buffer)) { + sprintf(new_buffer + new_buf_index, "%s ", replace_str); + new_buf_index += strlen(replace_str) + 1; + index += strlen(orig_str); + continue; + } + } + new_buffer[new_buf_index++] = buffer[index]; + } + + // copy new_buffer into buffer + for (index = 0; index < strlen(new_buffer); index++) { + buffer[index] = new_buffer[index]; + } + buffer[index+1] = '\0'; +} + +/* Replace >r and r> with sub_>r and sub_r> */ +static void replace_return_stack_words(char *bootscript) +{ + const char *find_str1 = ">r"; + const char *replace_str1 = "sub_>r"; + const char *find_str2 = "r>"; + const char *replace_str2 = "sub_r>"; + + replace_string(bootscript, find_str1, replace_str1); + replace_string(bootscript, find_str2, replace_str2); +} + +/* Runs the bootscript one line at a time */ +void run_script(char *bootscript) +{ + int index = 0, buf_index = 0; + char c; + char *buffer = malloc(1000 * sizeof(char)); + + while (1) { + c = bootscript[index]; + + // fill up buffer + while (c != '\n' && c != '\r' && c != '\0') { + buffer[buf_index++] = c; + c = bootscript[++index]; + } + buffer[buf_index] = '\0'; + buf_index = 0; + index++; + DPRINTF("%s\n", buffer); + feval(buffer); + if (c == '\0') { + break; + } + } + free(buffer); +} + /* Parse SGML structure like: <chrp-boot> @@ -209,9 +279,6 @@ script = 0; bootscript[scriptlen] = '\0'; - DPRINTF("got bootscript %s\n", - bootscript); - scriptvalid = -1; break; @@ -261,8 +328,8 @@ /* If the payload is bootinfo then we execute it immediately */ if (scriptvalid) { - DPRINTF("bootscript: %s\n", bootscript); - feval(bootscript); + replace_return_stack_words(bootscript); + run_script(bootscript); } else DPRINTF("Unable to parse bootinfo bootscript\n");

4 9

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 22 Dec '17

22 Dec '17

Looks like the spot were I’m stuck is: b(;) ( 0x0c2 ) 25612: b(') ( 0x011 ) (unnamed-fcode) [0xc84] 25613: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a9] 25614: (unnamed-fcode) [0xe34] 25615: (unnamed-fcode) [0xdff] 25616: (unnamed-fcode) [0x93d] 25617: b(lit) ( 0x010 ) 0xf 25618: <> ( 0x03d ) 25619: b?branch ( 0x014 ) 0x0026 ( =dec 38) 25620: (unnamed-fcode) [0x9bd] 25621: b(lit) ( 0x010 ) 0xff 25622: and ( 0x023 ) 25623: my-space ( 0x103 ) 25624: + ( 0x01e ) 25625: (unnamed-fcode) [0xa08] 25626: b(lit) ( 0x010 ) 0x6 25627: and ( 0x023 ) 25628: b(lit) ( 0x010 ) 0x4 25629: = ( 0x03c ) 25630: b?branch ( 0x014 ) 0x0009 () 25631: b(') ( 0x011 ) (unnamed-fcode) [0x9c1] 25632: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c0] 25633: b(>resolve) ( 0x0b2 ) 25634: b(>resolve) ( 0x0b2 ) It seems to break right here………………………………. 25635: (unnamed-fcode) [0xddf] 25636: (unnamed-fcode) [0xe04] 25637: (unnamed-fcode) [0xe38] 25638: (unnamed-fcode) [0xe06] 25639: (unnamed-fcode) [0xce5] 25640: (unnamed-fcode) [0xdb0] 25641: (unnamed-fcode) [0xe07] 25642: (unnamed-fcode) [0xe1a] 25643: (unnamed-fcode) [0xc5b] 25644: (unnamed-fcode) [0xe28] 25645: (unnamed-fcode) [0xe20] 25646: (unnamed-fcode) [0xdfa] 25647: (unnamed-fcode) [0xe37] 25648: (unnamed-fcode) [0xe2c] 25649: (unnamed-fcode) [0xe2d] The next thing seems to be: new-token ( 0x0b5 ) 0xddf 21913: b(:) ( 0x0b7 ) 21914: b(lit) ( 0x010 ) 0x10 21915: (unnamed-fcode) [0xdde] 21916: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c3] 21917: b(lit) ( 0x010 ) 0x14 21918: (unnamed-fcode) [0xdde] 21919: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c4] 21920: (unnamed-fcode) [0x9c0] 21921: b(lit) ( 0x010 ) 0xff 21922: and ( 0x023 ) 21923: (unnamed-fcode) [0xdde] 21924: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c6] 21925: b(lit) ( 0x010 ) 0x30 21926: (unnamed-fcode) [0xdde] 21927: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c5] 21928: (unnamed-fcode) [0x9bf] 21929: (unnamed-fcode) [0xa03] 21930: (unnamed-fcode) [0x9c5] 21931: (unnamed-fcode) [0xa04] 21932: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a5] 21933: (unnamed-fcode) [0x9bc] 21934: (unnamed-fcode) [0xa03] 21935: (unnamed-fcode) [0x9c3] 21936: (unnamed-fcode) [0xa04] 21937: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a3] 21938: (unnamed-fcode) [0x9c0] 21939: (unnamed-fcode) [0xa03] 21940: (unnamed-fcode) [0x9c6] 21941: (unnamed-fcode) [0xa04] 21942: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a6] 21943: (unnamed-fcode) [0x9bd] 21944: (unnamed-fcode) [0xa03] 21945: (unnamed-fcode) [0x9c4] 21946: (unnamed-fcode) [0xa04] 21947: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a4] 21948: (unnamed-fcode) [0xa3b] 21949: (unnamed-fcode) [0xa3d] 21950: (unnamed-fcode) [0xddd] 21951: b(;) ( 0x0c2 ) I don’t really understand this (unnamed-fcode) [0xddf], or any of the (unnamed-fcode)? Could someone explain that to me.

3 10

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 19 Dec '17

19 Dec '17

> On Dec 18, 2017, at 7:29 PM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: > > Hi! > > On Mon, Dec 18, 2017 at 06:37:54PM -0500, Jd Lyons wrote: >> I must not be doing init correct >> >> “ /pci/pci10de,141,@f” open-dev” >> >> But my-self . Returns 0? > > Something like > > “ /pci/pci10de,141,@f” open-dev to my-self > > is all you need :-) > > But, I think you mistyped it, it is > > “ /pci/pci10de,141@f” open-dev to my-self > > (or even just > > “ /pci/@f” open-dev to my-self > > if you are just as lazy as I am). > Thanks, Segher, I was missing the "to my-self”. I think we’re almost to the end of the file, and it’s at least changing the value of the subsystem ID. C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 17 2017 13:36] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1536M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36 0 > dev /pci/@f .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 50 cache-line-size 10 assigned-addresses -- 3c : 02 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 c3 00 78 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 78 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 reg 00007800 00000000 00000000 00000000 00000000 02007810 00000000 00000000 00000000 01000000 c3007814 00000000 00000000 00000000 10000000 8300781c 00000000 00000000 00000000 01000000 ok 0 > : us ( n -- ) d# 1000 / 1+ ms ; ok 0 > " /pci/@f" open-dev to my-self ok 0 > load hd:,\ppc\6600.fcode ok 0 > 4000040 1 byte-load (offset) 26 4010039 : (compile) [ 0x9bd ] 401003a : (compile) b(lit) [ 0x10 ] 401003f : (compile) and [ 0x23 ] 4010041 : (compile) my-space [ 0x103 ] 4010042 : (compile) + [ 0x1e ] 4010044 : (compile) [ 0xa08 ] 4010045 : (compile) b(lit) [ 0x10 ] 401004a : (compile) and [ 0x23 ] 401004b : (compile) b(lit) [ 0x10 ] 4010050 : (compile) = [ 0x3c ] 4010051 : (compile) b?branch [ 0x14 ] (offset) 9 4010054 : (compile) b(') [ 0x11 ] 4010057 : (compile) b(to) [ 0xc3 ] 401005a : (compile) b(>resolve) [ 0xb2 ] 401005b : (compile) b(>resolve) [ 0xb2 ] byte-load: exception caught! ok 0 > here 200 - 400 dump fffcd7d0 50 80 08 00 93 01 6c 02 12 05 6e 29 60 2a 00 2e P�..�.l...n)`*.. fffcd7e0 00 2f 20 74 80 3e 71 50 80 08 00 93 ff f6 e2 b0 ./ t�>qP�..�� fffcd7f0 ff f6 e2 e4 ff f6 6c 78 00 00 00 fc 01 6c 02 12 ��lx...�.l.. fffcd800 05 6e 29 60 2a 00 2e 00 2f 20 74 80 3e 71 50 80 .n)`*.../ t�>qP� fffcd810 08 00 93 01 6b 02 12 05 6e 29 60 2a 00 2e 00 2f ..�.k...n)`*.../ fffcd820 20 50 81 08 00 93 01 6b 02 12 05 6e 29 60 2a 00 P�..�.k...n)`*. fffcd830 2e 00 2f 20 74 80 3e 71 50 80 08 00 93 01 6c 02 ../ t�>qP�..�.l. fffcd840 12 05 6e 29 60 2a 00 2e 00 2f 20 50 81 08 00 93 ..n)`*.../ P�..� fffcd850 01 6c 02 12 05 6e 29 60 2a 00 2e 00 2f 20 74 80 .l...n)`*.../ t� fffcd860 3e 71 50 80 08 00 93 01 6c 02 12 05 6e 29 60 2a >qP�..�.l...n)`* fffcd870 00 2e 00 2f 20 50 81 08 00 93 01 6c 02 12 05 6e .../ P�..�.l...n fffcd880 29 60 2a 00 2e 00 2f 20 74 80 3e 71 50 80 09 00 )`*.../ t�>qP�.. fffcd890 93 01 6c 02 12 04 89 05 6e 31 00 32 00 33 00 2e �.l...�.n1.2.3.. fffcd8a0 15 74 50 c3 74 50 c3 50 80 01 01 62 50 81 06 3b .tP�tP�P�..bP�.; fffcd8b0 00 3c 00 3d 00 3e 00 3f 00 3a 81 71 50 80 09 00 .<.=.>.?.:�qP�.. fffcd8c0 13 01 71 02 32 04 89 05 6e 30 00 31 00 32 00 33 ..q.2.�.n0.1.2.3 fffcd8d0 00 50 81 0a 00 13 01 71 02 32 04 81 05 2e 30 00 .P�....q.2.�..0. fffcd8e0 31 00 32 00 33 00 3a 80 74 50 c3 74 50 c3 71 50 1.2.3.:�tP�tP�qP fffcd8f0 80 06 00 93 01 6b 02 52 ff f6 e2 b0 ff f6 e2 e4 �..�.k.R�� fffcd900 ff f6 6c 78 00 00 00 6b 04 81 05 6e 3a 80 6e 88 ��lx...k.�.n:�n� fffcd910 15 00 00 00 00 00 00 25 20 00 00 71 71 6e 80 08 .......% ..qqn�. fffcd920 68 00 ff ff ff df 00 00 00 00 71 6e 80 28 68 00 h.��....qn�(h. fffcd930 ff ff ff cf 00 00 00 00 71 7a 04 13 00 00 00 08 ��....qz...... fffcd940 00 00 58 00 14 00 00 04 a2 1d a8 a9 23 1e b7 7f ..X.....�.��#.� fffcd950 d7 25 c8 c9 16 c2 27 7f 6e 98 10 00 00 f7 ff ff �%��.�'n�...�� fffcd960 ff 00 00 00 00 6e 10 13 00 00 ff ff ff ff 00 00 �....n....��.. fffcd970 00 00 71 00 ff f6 e2 b0 ff f6 e2 e4 ff f6 44 d0 ..q.��D� fffcd980 00 00 00 08 ff fc 8f c0 ff f6 41 88 ff f6 41 58 ....��A��AX fffcd990 ff f6 40 d4 ff fa c9 58 ff f6 4b c0 ff fc b6 7c ��@��X��K��| fffcd9a0 ff f6 e2 e4 ff f6 41 38 ff f6 40 d4 ff fa c9 68 ��A8��@��h fffcd9b0 ff f6 4b c0 ff f6 40 d4 ff fa c9 58 ff f6 4b c0 ��K��@��X��K� fffcd9c0 ff fb 65 24 ff f6 e4 bc ff f6 40 c4 00 00 00 10 ��e$��@�.... fffcd9d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcd9e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcd9f0 00 34 30 30 66 34 30 30 66 34 30 30 66 66 31 32 .400f400f400ff12 fffcda00 ff fc d9 fe 00 00 00 00 00 00 00 00 00 00 00 00 ��............ fffcda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda60 00 00 00 00 00 00 00 00 00 00 00 00 00 34 30 31 .............401 fffcda70 30 34 30 31 30 34 30 31 30 30 63 35 ff 34 30 31 0401040100c5�401 fffcda80 30 34 30 31 30 34 30 31 30 34 30 31 30 30 63 33 04010401040100c3 fffcda90 ff fc da 8e 00 34 30 31 30 34 30 31 30 34 30 31 ��ڎ.40104010401 fffcdaa0 30 34 30 31 30 30 63 33 ff fc da a6 00 34 30 31 040100c3��ڦ.401 fffcdab0 30 30 63 33 ff fc da b2 00 34 30 31 30 34 30 31 00c3��ڲ.4010401 fffcdac0 30 34 30 31 30 34 30 31 66 66 66 63 64 61 63 30 04010401fffcdac0 fffcdad0 ff fc da c8 00 00 00 00 00 00 00 00 00 00 00 00 ��............ fffcdae0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdaf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdba0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdbb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdbc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 0 > my-self . 5fc5ac34 ok 0 > dev /pci/@f .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 10 cache-line-size 10 assigned-addresses -- 3c : 02 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 c3 00 78 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 78 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 reg 00007800 00000000 00000000 00000000 00000000 02007810 00000000 00000000 00000000 01000000 c3007814 00000000 00000000 00000000 10000000 8300781c 00000000 00000000 00000000 01000000 ok 0 > > > Segher

1 0

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

> On Dec 18, 2017, at 2:44 AM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: > > On Mon, Dec 18, 2017 at 01:13:49AM -0500, Jd Lyons wrote: >>> On Dec 18, 2017, at 12:48 AM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: >>> On Mon, Dec 18, 2017 at 12:05:17AM -0500, Jd Lyons wrote: >>>> Still bombing out at the same place: >>> >>>> 401002a : [ 0xe34 ] >>>> >>>> byte-load: exception caught! >>> >>> : xe33 $find invert IF ABORT THEN ; >>> : xe34 >>> " us" xe33 TO x9a7 >>> " case-closed?" $find invert IF 2drop ['] 0 THEN >>> TO x9a8 ; >>> >>> So the thing that throws is fcode e33, when trying to find the word "us". >>> >>> (Btw, "invert" is weird here; I suppose it was coded as its synonym "not". >>> In some other Forth systems "not" is a synonym for "0=", which makes more >>> sense here. Either works as long as $find returns a canonical true/false, >>> as it supposed to). >>> >>> So, implement "us", and you'll get further :-) It's just like "ms", but >>> microseconds, instead; so you could do >>> >>> : us ( n -- ) d# 1000 / 1+ ms ; >>> >>> (which waits way too long for short timeouts, of course). >>> >> >> Ok, thanks, that makes since. I did see the “case-closed?” When I searched for 0xe34 in the detoked rom, but I wan’t sure what to make of it. >> >> So, the “us” word is unimplemented in Openbios, and we need to add it to get past this part? > > Exactly. And I gave a (not super great) implementation above, enough to > see if you get further :-) Ok, I see, the code you gave was a command for Openbios, I kept trying to find where to add it to the source, thinking it was C code;-) Only got one byte further: (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ] 401002c : [ 0xdff ] byte-load: exception caught! ok 1 > > > > Segher

2 5

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

> On Dec 17, 2017, at 11:42 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2017-Dec-17 23:39 , Jd Lyons wrote: >> It has the open and close words, really two open words now, because we added one. >> >> I’ll rebuild Openbios and edit out the: >> >> feval("['] vga-driver-fcode 2 cells + 1 byte-load”); >> >> That should keep the Fcode for VGA devices from loading….. > > If all it has are the open and close, leave it alone. The newer open > and close are supposed to replace the earlier ones (it may complain, but > you can live with that for the moment). You need the open in there so > that the open-dev works. Try the load/byte-load sequence inside that > node and see what happens. > Still bombing out at the same place: C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 18 2017 04:42] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1536M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 18 2017 04:42 0 > dev /pci ok 0 > dev @10 ok 0 > words close open ok 0 > " /pci/pci10de,141@10" open-dev ok 1 > load hd:,\ppc\6600.fcode ok 1 > 4000040 1 byte-load open isn't unique. close isn't unique. byte-load: exception caught! ok 1 > ls ok 1 > dev /pci ls fff8042c mac-io@c fff8336c usb@d fff836d8 QEMU,VGA@e fff83a8c NE2000@f fff83e3c pci10de,141@10 ok 1 > dev /pci/@10 .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 50 cache-line-size 10 assigned-addresses -- 3c : 02 00 80 10 00 00 00 00 83 00 00 00 00 00 00 00 01 00 00 00 c3 00 80 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 80 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 reg 00008000 00000000 00000000 00000000 00000000 02008010 00000000 00000000 00000000 01000000 c3008014 00000000 00000000 00000000 10000000 8300801c 00000000 00000000 00000000 01000000 ok 1 > setenv fcode-debug? true ok 1 > true to ?fcode-verbose ok 1 > dev /pci/@10 words close open close open ok 1 > 4010009 : (compile) b(endof) [ 0xc6 ] (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ] byte-load: exception caught! ok 1 >

3 4

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

Thanks Mark, I’m unsure how to get Openbios to execute the Fcode, I can load it to the correct address on my PCI card, via a little hack to Openbios. I’d really like to just go ahead and fix the fact that Openbios doesn’t probe for Fcode Rom’s on PCI devices. I know this will likely break a few things, requiring other fixes. If I had some idea of where to start, some sample code I maybe able to hack something together, but it would likely break more than it fixes. I’m sure you're busy, I’m retired and this is just something to keep my occupied, tho I’m not really qualified to do it. If it could be added as a priority to Openbios, to probe and execute FCode Rom’s on PCI devices, that would be great. I’m sure someone will take it up when they have a little spare time. I’m having trouble CC ing the list, I know stupid of me. Any idea what the unnamed FCode in the detok is? Does detok just not understand it, or is it words or methods? > On Dec 15, 2017, at 4:08 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 12/12/17 09:06, Jd Lyons wrote: >>> On Dec 12, 2017, at 3:24 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk <mailto:mark.cave-ayland@ilande.co.uk>> wrote: >>> >>> On 12/12/17 03:24, Jd Lyons wrote: >>> >>>>>> I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. >>>>> >>>>> Well... at the moment we actually cheat ;) Instead of reading the VGA FCode ROM from the virtual display adapter, OpenBIOS embeds its own copy of the FCode ROM and executes it unconditionally when it detects a VGA display device. I must admit I hadn't considered that someone would be interested in legacy device passthough to enable a device that isn't the standard QEMU display adapter. >>>> Are we talking about the ‘NDRV’ patch? >>>> I noticed that the ‘NDRV’ for the QEMU,VGA loads to any VGA card in the system. Yet the vga-pci.c loads a PC Video bios for the qemu,vga device, tho I’m pretty sure Openbios doesn’t use it. I’m having trouble locating how the QEMU,VGA device is able to be used by Openbios, how does it “init” the device? >>> >>> The NDRV driver is loaded into the "driver,AAPL..." property after the device node has been created by the FCode device so that occurs later in the process. >>> >>> OpenBIOS creates a basic PCI device node for every device it finds during a PCI bus scan and then executes a callback depending upon the resulting vendorid/deviceid. The code in OpenBIOS is in vga_config_cb() and as you can see, it currently executes the in-built FCode directly rather than trying to map the ROM using the process documented at http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200…. >>> >>>>> As a starting point I'd suggest that if you still have the old hardware lying around, you can use the article above to extract the ROM from a real Mac and then run the resulting code through fcode-utils detok which effectively "decompiles" the ROM and therefore give us an idea as to how many Forth words need to be implemented. >>>>> >>>> Ok, I’ve done some detok of nVidia Fcode Rom’s before, and I know about words that Openfirmware doesn’t understand, years ago I wanted two get an nVidia card to work in my Old World PM8600, and I figured it was the “map-in” bug, but as it turns out, it was some words in nVidia's FCode Rom that my version of OF didn’t have. >>>> Atriu Itra was able to get an nVidia card to work in OpenFimware on an Old World machine, but it wouldn’t boot the OS, however if he had stayed at it, I’m sure he’d have figured it out. He did basically what you are preposing. Guy was an Fcode master, we could really use him on this project. >>> >>> Sounds like someone has already done some of the work here - do you have a copy of the detok FCode or any emails related to the subject at all? >>> >>> Otherwise I would say the first step would be to hack OpenBIOS to expose the passthrough ROM and then dump it out from within QEMU. >> We had an online forum were we discussed hacking Fcode Roms, all gone now tho, but a lot of info, and Rom still at: >> http://themacelite.wikidot.com >> Most of all the old Fcode Roms in the downloads section, I don’t think anyone added the old 3dfx Roms for Powermac’s, but they can be extracted from the 3dfx control panel. I did some work emulating the Voodoo cards for Openbios/Qemu_PPC, really I’m just wanting to emulate a Voodo2, so I’m playing around with PCI Passthough while waiting to find an affordable Voodoo2, you wouldn’t believe what they sell for these days. >> The 6600 was only a few bucks, so I got it, but I was hoping to lighten the Emulated cpu load, as screen redraws seem to suck up all the CPU cycles under OS X. So a little QE may help there. >> Anyway, the Voodoo2 didn’t have a rom, and it wasn’t really a VGA card, those some people have hacked it to display the desktop, it was really a 3D Accelerator with VGA Passthough for the main system display card. So I don’t think I’ll have any trouble with PCI Passthrough with that. >> Anyway, I think we may want to work on some code for Openbios that detects vfio-pci and reads the rom for the device and tries to execute the Fcode, rather than what we have now, it’s not really a workable solution for PCI Passthrough of VGA. The pseries firmware is aware of a vfio-pci device, but it doesn’t seem to be aware of the Rom on the card either. >> I did some hacks to Openbios and got the rom mapped in @0x30 for the 6600, but Openbios still does not try and execute the rom. >> A quick look at the detok Fcode: > > Thanks for the dump of the ROM. At first glance I don't see anything too unusual in there - the main culprits to look at will be map-in, my-address and the config-* words for accessing PCI config space... > > Once you're able to run the FCode you can also do: > > true to fcode-debug? > > which should dump out the FCode tokens on the console as they are being debugged. > > > ATB, > > Mark.

4 9

Suggestion - add minor version number to banner
by Programmingkid 17 Dec '17

17 Dec '17

I was wondering if we could add a minor version number to the banner. It would mean instead of see "OpenBIOS v1.1", what would be printed is "OpenBIOS v1.1.x". I think this would help distinguish added features to a particular binary easier than how we do things now.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

> On Dec 17, 2017, at 1:28 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > From what I remember, there are a bunch of properties, the most important is the NVDA,BMP that’s where the GPU and Memory Registers get written. There is a Strap, the NVStrap near the beginning of the Rom, and one part of the NVStrap sets up how the NVDA,BMP is read and written. The BMP is common between PC and FCode Option Roms, as is the strap. In the BMP there are a series of tables 0-7 and one offset of the strap determines what table gets loaded. It was a throwback to a program nVidia gave to it board partners. The NVStap Editor, I think it was called, it allowed them to use a reference Bios and plug in some values depending on how they deviated from the reference PCB. The NVStrap has and And/Or mask, So you can append the resistors on the PCB, or just read them as they are, and you can change the last byte of the Device ID. > > So if one of there board partners used some cheap memory they could get a ready supply of, they could just plug the memory specs into the BMP Editor and set the Soft Strap(NVStrap) without the need to make a new Bios in assembly. > > We got lucky, and they used the BMP in the Fcode Rom too, and that allowed us to figure out how to edit it to flash PC cards for use in PPC systems. > > There is a GPU check in the Fcode rom too, so you have to bypass that check, if you want to use a GPU the Rom wasn’t made for. This is how we made the Geforce 6200 Rom from the Apple OEM Geforce 6600 Rom. Thank you for the info. You know a lot of Nvidia cards. Still there is the exception that we see when executing the card's Fcode. Finding out what is causing the exception would be very helpful. Were there any values in the stack that might mean anything when the exception happened? Did you see any other messages? The serial console may have something printed there. I found the definition to byte-load in the forth/device/feval.fs file. This is part of it: : byte-load ( addr xt -- ) ?fcode-verbose if cr ." byte-load: evaluating fcode at 0x" over . cr then \ save state >r >r fcode-push-state r> r> \ set fcode-c@ defer dup 1 = if drop ['] c@ then \ FIXME: uses c@ rather than rb@ for now... to fcode-c@ dup to fcode-stream-start to fcode-stream 1 to fcode-spread false to ?fcode-offset16 alloc-fcode-table false fcode-end ! \ protect against stack overflow/underflow 0 0 0 0 0 0 depth >r ['] (feval) catch if cr ." byte-load: exception caught!" cr then You see the message "exception caught!" takes place because the (feval) word has a problem with something. Looking at the (feval) word I see it has a (debug-feval) word that might be helpful. This word is also located in the feval.fs file. As an experiment could you set the ?fcode-verbose to true when running QEMU? I think this QEMU option would help: -prom-env ?fcode-verbose=true If this doesn't work, then maybe we should redefine the " word to print out what it finds to the serial console. That might tell us what is wrong.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

https://nouveau.freedesktop.org/wiki/DumpingVideoBios/ I found this really helpful page on obtaining information on properties. If you have Linux installed on a PowerPC Macintosh, then finding the properties is as simple as typing this command in the terminal: cd "/proc/device-tree/pci@f0000000/NVDA,Parent@10" Just checked my PowerPC iMac. It has an ATI Radeon video card, so it won't be much help. I think the reason why OpenBIOS fails to make the property is because there is something interesting about the name. Maybe an unhandled character type like unicode is used. Having a list of all the properties that this card has would be very helpful.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Jd Lyons 17 Dec '17

17 Dec '17

Ok, here's what I'm getting now: C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 17 2017 13:36] >> Configuration device id QEMU version 1 machine id 2 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36 0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�.......... 4000040 f1 08 17 0f 00 01 06 55 12 2a 00 00 00 00 00 00 �......U.*...... 4000050 00 00 00 00 de 10 50 00 3e 00 21 00 81 90 40 a3 ....�.P.>.!.��@� 4000060 00 00 00 00 90 04 00 80 00 00 a5 f4 00 00 00 00 ....�..�..��.... 4000070 00 00 00 00 52 a5 b5 08 00 ba a5 10 00 00 00 08 ....R��..��..... 4000080 b5 08 01 be a7 b5 08 02 be a7 b5 08 03 be 10 00 �..��..��..�.. 4000090 00 00 04 b5 08 04 be a7 b5 08 05 be a6 b5 08 06 ...�..��..��.. 40000a0 be a6 b5 08 07 be a6 b5 08 08 be a6 b5 08 09 be ��..��..��..� 40000b0 a6 b5 08 0a be a6 b5 08 0b be a6 b5 08 0c be 10 ��..��..��..�. 40000c0 00 00 00 0a b5 08 0d be a5 b5 08 0e be a6 b5 08 ....�..��..��. 40000d0 0f be a6 b5 08 10 be a6 b5 08 11 be 10 00 00 00 .��..��..�.... 40000e0 10 b5 08 12 be 10 00 00 00 48 b5 08 13 be a6 b5 .�..�....H�..�� 40000f0 08 14 be a6 b5 08 15 be b5 08 16 ba a5 a7 b5 08 ..��..��..��. 4000100 17 be a6 b5 08 18 be a6 b5 08 19 be a6 b5 08 1a .��..��..��.. 4000110 be a6 b5 08 1b be a6 b5 08 1c be a6 b5 08 1d be ��..��..��..� 4000120 a6 b5 08 1e be a6 b5 08 1f be a6 b5 08 20 be a6 ��..��..��. �� 4000130 b5 08 21 be a6 b5 08 22 be a6 b5 08 23 be a6 b5 �.!��."��.#�� 4000140 08 24 be a6 b5 08 25 be a6 b5 08 26 be a6 b5 08 .$��.%��.&��. 4000150 27 be b5 08 28 ba a5 a6 b5 08 29 be a6 b5 08 2a '��.(��.)��.* 4000160 be a5 b5 08 2b be a6 b5 08 2c be 10 00 00 00 04 ��.+��.,�..... 4000170 b5 08 2d be a6 b5 08 2e be a6 b5 08 2f be a6 b5 �.-��..��./�� 4000180 08 30 be a7 b5 08 31 be a7 b5 08 32 be 10 00 00 .0��.1��.2�... 4000190 00 06 b5 08 33 be 10 00 00 00 23 b5 08 34 be 10 ..�.3�....#�.4�. 40001a0 00 00 00 11 b5 08 35 be 10 00 00 00 09 b5 08 36 ....�.5�.....�.6 40001b0 be 10 00 00 00 2e b5 08 37 be a6 b5 08 38 be b5 �.....�.7��.8�� 40001c0 08 39 ba a5 a6 b5 08 3a be a6 b5 08 3b be a6 b5 .9��.:��.;�� 40001d0 08 3c be a6 b5 08 3d be a7 b5 08 3e be a7 b5 08 .<��.=��.>��. 40001e0 3f be a7 b5 08 40 be a7 b5 08 41 be a7 b5 08 42 ?��.@��.A��.B 40001f0 be a7 b5 08 43 be a7 b5 08 44 be a7 b5 08 45 be ��.C��.D��.E� 4000200 a7 b5 08 46 be a7 b5 08 47 be a7 b5 08 48 be a7 ��.F��.G��.H�� 4000210 b5 08 49 be 10 00 00 00 04 b5 08 4a be a6 b5 08 �.I�.....�.J��. 4000220 4b be a6 b5 08 4c be a6 b5 08 4d be a6 b5 08 4e K��.L��.M��.N 4000230 be a6 b5 08 4f be a6 b5 08 50 be a6 b5 08 51 be ��.O��.P��.Q� 4000240 a6 b5 08 52 be 10 00 00 00 04 b5 08 53 be 10 00 ��.R�.....�.S�.. 4000250 00 00 18 b5 08 54 be a6 b5 08 55 be a6 b5 08 56 ...�.T��.U��.V 4000260 be a6 b5 08 57 be a6 b5 08 58 be a6 b5 08 59 be ��.W��.X��.Y� 4000270 a6 b5 08 5a be a6 b5 08 5b be a6 b5 08 5c be 10 ��.Z��.[��.\�. 4000280 00 00 00 04 b5 08 5d be a6 b5 08 5e be a6 b5 08 ....�.]��.^��. 4000290 5f be a6 b5 08 60 be a6 b5 08 61 be a6 b5 08 62 _��.`��.a��.b 40002a0 be a6 b5 08 63 be a6 b5 08 64 be a6 b5 08 65 be ��.c��.d��.e� 40002b0 a7 b5 08 66 be a7 b5 08 67 be b5 08 68 ba a5 a6 ��.f��.g��.h�� 40002c0 b5 08 69 be a6 b5 08 6a be a6 b5 08 6b be a6 b5 �.i��.j��.k�� 40002d0 08 6c be a7 b5 08 6d be a7 b5 08 6e be a7 b5 08 .l��.m��.n��. 40002e0 6f be a7 b5 08 70 be a7 b5 08 71 be a6 b5 08 72 o��.p��.q��.r 40002f0 be a6 b5 08 73 be a6 b5 08 74 be a6 b5 08 75 be ��.s��.t��.u� 4000300 a6 b5 08 76 be b5 08 77 ba a5 a6 b5 08 78 be a6 ��.v��.w��.x�� 4000310 b5 08 79 be a6 b5 08 7a be a6 b5 08 7b be 10 00 �.y��.z��.{�.. 4000320 00 00 04 b5 08 7c be 10 00 00 00 04 b5 08 7d be ...�.|�.....�.}� 4000330 10 00 00 00 04 b5 08 7e be 10 00 00 00 04 b5 08 .....�.~�.....�. 4000340 7f be 10 00 00 00 04 b5 08 80 be 10 00 00 00 04 �.....�.��..... 4000350 b5 08 81 be b5 08 82 ba a5 10 00 00 00 04 b5 08 �.��.��.....�. 4000360 83 be 10 00 00 00 04 b5 08 84 be 10 00 00 00 04 ��.....�.��..... 4000370 b5 08 85 be 10 00 00 00 04 b5 08 86 be 10 00 00 �.��.....�.��... 4000380 00 04 b5 08 87 be 10 00 00 00 04 b5 08 88 be 10 ..�.��.....�.��. 4000390 00 00 00 04 b5 08 89 be 10 00 00 00 04 b5 08 8a ....�.��.....�.� 40003a0 be 10 00 00 00 04 b5 08 8b be 10 00 00 00 04 b5 �.....�.��.....� 40003b0 08 8c be 10 00 00 00 04 b5 08 8d be 10 00 00 00 .��.....�.��.... 40003c0 04 b5 08 8e be b5 08 8f ba a5 a6 b5 08 90 be a6 .�.��.��.�� 40003d0 b5 08 91 be a6 b5 08 92 be a6 b5 08 93 be b5 08 �.��.��.��. 40003e0 94 ba a5 a6 b5 08 95 be a6 b5 08 96 be a7 b5 08 ��.��.��. 40003f0 97 be 10 00 00 00 04 b5 08 98 be 10 00 00 00 04 ��.....�.��..... ok 0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > printenv name "options" boot-args "" boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "false" focde-debug? "true" ok 0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 > I'm not sure, I'm assuming something in the Rom is casing a stack overflow? Does openbios support fcode-verbose? gdb '/home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip' GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip...done. (gdb) target remote :1234 Remote debugging using :1234 warning: while parsing target description (at line 1): Target description specified unknown architecture "powerpc:common" warning: Could not load XML target description; ignoring 0x00000000 in ?? () (gdb) b load Breakpoint 1 at 0xfff16f7c: file /Users/jam/OpenBios/master/libopenbios/load.c, line 55. (gdb) c Continuing. gdb isn't breaking at the load command, but I'm not sure that matters anymore, as it's working, anyway. On Sunday, December 17, 2017, 9:44:34 AM EST, Jd Lyons <lyons_dj(a)yahoo.com> wrote: Sorry, I forgot I remained the Rom file and was trying to load a file that didn’t exist, lead us down a false path. Loading the correct file and dumping the load base address does yell the Rom. > On Dec 17, 2017, at 9:02 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 17/12/17 13:53, Jd Lyons wrote: > >>> On Dec 17, 2017, at 7:56 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: >>> >>> On 17/12/17 12:41, Jd Lyons wrote: >>> >>>>>>> Also what FS is your HD image? HFS/HFS+ should work best on qemu-system-ppc, ISO9660 works but is case-sensitive from memory. >>>>>> FS is HFS+, when I execute: >>>>>>> dir hd:,\ >>>>>> I get the list of files, so I know I’m trying to load the Rom from the correct place, and OB can read the drive. I can: >>>>>>> 4000 load hd:,\System\Library\CoreServices\BootX >>>>>> And the system boots. >>>>> >>>>> Which version of QEMU/OpenBIOS are you using? load should only copy the code and run init-program, rather than set up a CPU context and execute go. >>>>> >>>>> Presumably you are building OpenBIOS from git master to get extra debugging information? >>>> git clone https://github.com/openbios/openbios.git. ????? >>> >>> Yes, that looks correct. >>> >>>> Not sure I’m pulling from the master or not. >>>> Is there anything I need to do to enable extra debugging when I build? >>>> PATH=:/usr/local/ppcelf/ppcelf/bin:/users/hsp/src/fcode-utils-devel/toke:$PATH >>>> export PATH >>>> Make -j8 >>> >>> My normal build process for debugging OpenBIOS looks like this: >>> >>> vi Makefile.target >>> >>> (alter line 28 to build a debug ELF executable by changing the -Os option in CFLAGS to -O0) >>> >>> rm -rf obj-*; >>> ./config/scripts/switch-arch ppc >>> >>> Then start QEMU from a separate terminal like this: >>> >>> ./qemu-system-ppc -bios /patch/to/openbios/obj-pp/openbios-qemu.elf.nostrip -s -S >> Seems to fail here, never boots with -S? > > Yes indeed. -s -S tell QEMU to wait until the remote gdb connects to QEMU before starting the VM. > >>> >>> Swtich back to your OpenBIOS terminal and then do: >>> >>> powerpc-linux-gdb obj-ppc/openbios-qemu.elf.nostrip >>> target remote :1234 (connect to QEMU gdbstub) >>> b load (set breakpoint in libopenbios/load.c's load() function) >>> c >>> >>> You should then find that when you type load into OpenBIOS gdb hits the breakpoint and you can step through the C parts of the code to see what happens. Sadly gdb doesn't have support for debugging Forth, but if you can get this working it will help a lot since all of the ELF/load/init-program and PCI routines are all in C. >>> >>>> I didn’t thing the 4000 load hd:,\bootx should boot the system, yet it does. Assuming I put BootX at the root of my drive, I was thinking it should just load it into system memory at the address 4000. Adding -h doesn’t help, nor does adding -h to the boot command, I’m assuming -h is unemiplmented in Openbios. >>> >>> You actually don't need the 4000 since according to the specification "load" places the resulting image at the location specified by load-base: >>> >>> 0 > cd /options ok >>> 0 > .properties >>> name "options" >>> boot-args "" >>> boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" >>> use-generic? "false" >>> boot-script "" >>> boot-screen "" >>> vga-ndrv? "true" >>> virt-size "-1" >>> virt-base "-1" >>> load-base "4000000" >>> real-size "-1" >>> real-base "-1" >>> real-mode? "false" >>> little-endian? "false" >>> scroll-lock "true" >>> skip-netboot? "false" >>> default-mac-address "false" >>> pci-probe-mask "-1" >>> selftest-#megs "0" >>> screen-#rows "75" >>> screen-#columns "100" >>> output-device "/pci@80000000/mac-io@3/escc/ch-a" >>> input-device "/pci@80000000/mac-io@3/escc/ch-a" >>> use-nvramrc? "false" >>> oem-logo? "false" >>> oem-banner "" >>> oem-banner? "false" >>> nvramrc "" >>> fcode-debug? "false" >>> diag-switch? "false" >>> boot-file "" >>> boot-command "boot" >>> auto-boot? "true" >>> ok >>> 0 > >>> >>> Ahhh so wait a second - load-base is set to 0x4000000 rather than 0x4000 which is the default in SPARC. So how about something like: >>> >>> load hd:,\6600.fcode >>> 4000000 40 dump > > Any luck with this bit on your existing setup? > > > ATB, > > Mark.

5 10

Re: [OpenBIOS] Loading a PCI Option rom.
by Jd Lyons 17 Dec '17

17 Dec '17

> On Dec 15, 2017, at 4:02 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 14/12/17 13:36, Jd Lyons wrote: > >> I’m trying to see if I can get Openbios to execute the Option rom of my Geforce 6600. Using the method described here: >> https://docs.oracle.com/cd/E19253-01/806-1379-10/fctest.html#35443 >> I’m not understanding some of it, and I’m varying the commands, somewhat. >> ok4000 dload /stand/mydev.fcode >> ok0 0 " 4,0" " /pci@1f,2000" begin-package >> ok4020 1 byte-load >> okend-package > > Yeah OpenBIOS doesn't implement dload because it doesn't have a TCP/IP stack :( > >> Rather than the above I’m using: >> ok4000 load hd:,6600.rom >> ok0 0 " 4,0" " /pci@f2000000" begin-package >> ok4020 1 byte-load >> okend-package >> I’m not sure the deference between “dload” and “load”? >> dload is not a word in Openbios, yet, and should load a file over ethernet, if I’m reading the documentation right? > > Yes, that's correct - dload probably pulls a file via TFTP or similar. > >> I’m not sure I can just load the raw rom image like this, or I need just the FCode? >> Also, should I be using the address of the pci controller( @f2000000 ) or am I misunderstanding this part, should I be using the address of my pci card? > > From memory I think the FCode executes within the context of the parent, i.e. it is responsible for calling begin-package and end-package. And also I believe that for PCI the address of the package to be created should match the PCI slot I think you are fairly close with: > > 0 0 " 4,0" " /pci@f2000000" begin-package > 4020 1 byte-load > end-package > > What happens when you try and execute that? Do you get any messages? You should also be able to display the option ROM (assuming it has loaded successfully at 0x4000) with: > > 4000 1000 dump > > And with FCode it's always useful to test in -nographic mode until you know what commands you need as it's easier to cut/paste. Don’t seem to load the Rom at all, I get ok, but then: 1 > And dumping the first 100 bytes doesn’t yield anything but zeroes. I tested to see if load of a non existent file did the same thing, and it does. So I’m not getting the command right. > ATB, > > Mark.

2 1

Re: [OpenBIOS] PIC Passthough( VGA )
by Programmingkid 17 Dec '17

17 Dec '17

If someone wanted to enhance OpenBIOS to load a FCode ROM from a video card, what would need to be changed? My theory is this line in the pci.c file's vga_config_cb() function would need this line changed: feval("['] vga-driver-fcode 2 cells + 1 byte-load"); I think the vga-driver-fcode word is what points to the generic driver. Would this be a correct assumption?

2 1

Re: [OpenBIOS] PIC Passthough( VGA )
by Mark Cave-Ayland 12 Dec '17

12 Dec '17

On 12/12/17 03:24, Jd Lyons wrote: >>> I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. >> >> Well... at the moment we actually cheat ;) Instead of reading the VGA FCode ROM from the virtual display adapter, OpenBIOS embeds its own copy of the FCode ROM and executes it unconditionally when it detects a VGA display device. I must admit I hadn't considered that someone would be interested in legacy device passthough to enable a device that isn't the standard QEMU display adapter. > > Are we talking about the ‘NDRV’ patch? > > I noticed that the ‘NDRV’ for the QEMU,VGA loads to any VGA card in the system. Yet the vga-pci.c loads a PC Video bios for the qemu,vga device, tho I’m pretty sure Openbios doesn’t use it. I’m having trouble locating how the QEMU,VGA device is able to be used by Openbios, how does it “init” the device? The NDRV driver is loaded into the "driver,AAPL..." property after the device node has been created by the FCode device so that occurs later in the process. OpenBIOS creates a basic PCI device node for every device it finds during a PCI bus scan and then executes a callback depending upon the resulting vendorid/deviceid. The code in OpenBIOS is in vga_config_cb() and as you can see, it currently executes the in-built FCode directly rather than trying to map the ROM using the process documented at http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200…. >> As a starting point I'd suggest that if you still have the old hardware lying around, you can use the article above to extract the ROM from a real Mac and then run the resulting code through fcode-utils detok which effectively "decompiles" the ROM and therefore give us an idea as to how many Forth words need to be implemented. >> > > Ok, I’ve done some detok of nVidia Fcode Rom’s before, and I know about words that Openfirmware doesn’t understand, years ago I wanted two get an nVidia card to work in my Old World PM8600, and I figured it was the “map-in” bug, but as it turns out, it was some words in nVidia's FCode Rom that my version of OF didn’t have. > > Atriu Itra was able to get an nVidia card to work in OpenFimware on an Old World machine, but it wouldn’t boot the OS, however if he had stayed at it, I’m sure he’d have figured it out. He did basically what you are preposing. Guy was an Fcode master, we could really use him on this project. Sounds like someone has already done some of the work here - do you have a copy of the detok FCode or any emails related to the subject at all? Otherwise I would say the first step would be to hack OpenBIOS to expose the passthrough ROM and then dump it out from within QEMU. ATB, Mark.

1 0

PIC Passthough( VGA )
by Jd Lyons 11 Dec '17

11 Dec '17

I was hoping I could use PCI Passthrough with an old Apple OEM Geforce 6600 PCI-E card, as the display device, but I’m not having any luck. Openbios seems to have an error” Can not manage “VGA controller’ PCI device type ‘display’ 10de 141 ( 3 0 0 ) I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. I’m having trouble checking to see if Openbios can read the Rom of the card, I’m, sure I’m not doing it right, could someone offer a little guidance? http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200… >dev / ls >dev pci >dev @10 >.properties >” ..” find-device open >. This is where, I think it should return ffffffff, however it returns -1. I was thinking “-1” was 0xffffffff? Here is where I’m getting stuck: >1180e config-b@ config-b@ undefined word. Can anyone offer what I’m doing wrong, should I have another value for “1180e”? The address 1180e is the Configuration Space address we want to read. The word config-b@ reads a byte from this address. The . word displays the top item on the stack, which is the Header Type register. Since this is a Header Type Zero, we know the expansion ROM BAR is at offset 0x30. Thanks

2 1

Re: [OpenBIOS] Porting to custom board
by Mark Cave-Ayland 29 Nov '17

29 Nov '17

On 28/11/17 20:45, Max Ruttenberg wrote: > Hi all, > > I'm interested in porting openbios to a board with QorIQ ppce5500 > processor. The board currently uses U-Boot as its primary and > secondary boot loader. > > Is it possible to boot into an openbios image from U-Boot? > Is there a porting guide? Hi Max, Building OpenBIOS generates an ELF image, so if you can include an ELF payload then this should be possible. Regarding porting to a new board, I wrote some notes last year in response to a similar query at https://mail.coreboot.org/pipermail/openbios/2016-November/009837.html which you may find useful. Hopefully that gives you a good starting point, and feel free to ask any further questions you may have on list (posts are moderated by default unless you are a list member). ATB, Mark.

1 0

Porting to custom board
by Max Ruttenberg 28 Nov '17

28 Nov '17

Hi all, I'm interested in porting openbios to a board with QorIQ ppce5500 processor. The board currently uses U-Boot as its primary and secondary boot loader. Is it possible to boot into an openbios image from U-Boot? Is there a porting guide? Thank you, Max

1 0

Re: [OpenBIOS] Where is the issue tracker?
by Mark Cave-Ayland 09 Nov '17

09 Nov '17

On 07/11/17 02:23, Huang, Jie (Jackie) wrote: > Hi, > > I wanted to report an issue for openbios but failed to access the issue tracker: > > https://tracker.coreboot.org/trac/openbios > > Is this the correct issue tracker openbios is using? > > I found openbios is also in github, so I reported the issue there instead(but it > doesn't seem to be the correct one, there is 0 issue before I reported): > https://github.com/openbios/openbios/issues/2 > > Thanks, > Jackie Hi Jackie, The official OpenBIOS bug tracker moved to github a while back, so the above link is no longer correct. I updated the OpenBIOS wiki at https://www.openfirmware.info/OpenBIOS to reflect the new link *within* the page, however I don't currently have access to the link in the sidebar which might be where the confusion comes from. I'll see if I can talk to someone to get this fixed. Thanks for reporting the issue, I will try and take a look at this later. ATB, Mark.

2 1

Where is the issue tracker?
by Huang, Jie (Jackie) 07 Nov '17

07 Nov '17

Hi, I wanted to report an issue for openbios but failed to access the issue tracker: https://tracker.coreboot.org/trac/openbios Is this the correct issue tracker openbios is using? I found openbios is also in github, so I reported the issue there instead(but it doesn't seem to be the correct one, there is 0 issue before I reported): https://github.com/openbios/openbios/issues/2 Thanks, Jackie

1 0

[PATCH 0/3] SPARC64: update to simba PCI bridge configuration
by Mark Cave-Ayland 15 Oct '17

15 Oct '17

It looks as if the sun4u sabre/simba patchset is close to being merged into QEMU, so here are the related changes queued for OpenBIOS. All of the patches except the last have previously been posted on-list. Since QEMU freeze is coming up soon I plan to apply these as soon as possible once the QEMU changes land upstream. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): SPARC64: switch to simba PCI bridge machine configuration pci: set cmd646 name and device_type properties to "ide" pci: set sunhme name to "network" arch/sparc64/openbios.c | 2 +- drivers/pci.c | 22 ++++++++++++++-------- drivers/pci_database.c | 4 ++-- 3 files changed, 17 insertions(+), 11 deletions(-) -- 1.7.10.4

1 3

[PATCH] pci: add PCI bridge support for 32-bit PCI IO address spaces
by Mark Cave-Ayland 30 Sep '17

30 Sep '17

Make sure that we set the upper 16-bits of the IO address for both the PCI IO base and PCI IO limit registers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 3 +++ drivers/pci.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index 265ab0c..672dcd0 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1494,6 +1494,7 @@ static void ob_configure_pci_bridge(pci_addr addr, /* Set the base limit registers */ pci_config_write16(addr, PCI_MEMORY_BASE, ((*mem_base >> 16) & ~(0xf))); + pci_config_write16(addr, PCI_IO_BASE_UPPER, (*io_base >> 16)); pci_config_write8(addr, PCI_IO_BASE, ((*io_base >> 8) & ~(0xf))); /* Always ensure legacy ioports are accessible during enumeration. @@ -1501,6 +1502,7 @@ static void ob_configure_pci_bridge(pci_addr addr, the configuration process, so we allow them during the secondary bus scan and then set the correct IO limit below. */ io_scan_limit = *io_base + (0xffff - *io_base); + pci_config_write16(addr, PCI_IO_LIMIT_UPPER, (io_scan_limit >> 16)); pci_config_write8(addr, PCI_IO_LIMIT, (io_scan_limit >> 8) & ~(0xf)); /* make pci bridge parent device, prepare for recursion */ @@ -1535,6 +1537,7 @@ static void ob_configure_pci_bridge(pci_addr addr, /* Set the limit registers */ pci_config_write16(addr, PCI_MEMORY_LIMIT, (((*mem_base - 1) >> 16) & ~(0xf))); + pci_config_write16(addr, PCI_IO_LIMIT_UPPER, ((*io_base - 1) >> 16)); pci_config_write8(addr, PCI_IO_LIMIT, (((*io_base - 1) >> 8) & ~(0xf))); /* Disable unused address spaces */ diff --git a/drivers/pci.h b/drivers/pci.h index ea70e8a..883a531 100644 --- a/drivers/pci.h +++ b/drivers/pci.h @@ -47,7 +47,9 @@ #define PCI_BASE_ADDR_5 0x24 #define PCI_IO_BASE 0x1c +#define PCI_IO_BASE_UPPER 0x30 #define PCI_IO_LIMIT 0x1d +#define PCI_IO_LIMIT_UPPER 0x32 #define PCI_MEMORY_BASE 0x20 #define PCI_MEMORY_LIMIT 0x22 -- 1.7.10.4

1 1

[PATCH] package.fs: don't reveal interposed packages
by Mark Cave-Ayland 22 Sep '17

22 Sep '17

The IEEE-1275 interpose specification suggests that interposed packages should not be visible unless an interpose-aware Forth word is used. Commit 247c6169 "Fix for interpose problem" realised this by converting the romvec obp_inst2pkg() function over to use ihandle>non-interposed-phandle but didn't make the same change to the equivalent CIF call instance-to-path (which is presumably correct since the interpose specification also states that interposed packages are only visible to a new instance-to-interposed-path CIF call). Here we add a new instance-to-package word as a wrapper to ihandle>non-interposed-phandle and update obp_inst2pkg() and instance-to-path to use it accordingly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc32/romvec.c | 2 +- forth/device/package.fs | 4 ++++ forth/system/ciface.fs | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/sparc32/romvec.c b/arch/sparc32/romvec.c index 8757c28..7a01035 100644 --- a/arch/sparc32/romvec.c +++ b/arch/sparc32/romvec.c @@ -372,7 +372,7 @@ int obp_inst2pkg(int dev_desc) int ret; PUSH(dev_desc); - fword("ihandle>non-interposed-phandle"); + fword("instance-to-package"); ret = POP(); DPRINTF("obp_inst2pkg(fd 0x%x) = 0x%x\n", dev_desc, ret); diff --git a/forth/device/package.fs b/forth/device/package.fs index d5b52c3..3056c1d 100644 --- a/forth/device/package.fs +++ b/forth/device/package.fs @@ -32,6 +32,10 @@ >in.device-node @ ; +: instance-to-package ( ihandle -- phandle ) + dup 0<> if ihandle>non-interposed-phandle then +; + : ihandle>phandle ( ihandle -- phandle ) >in.device-node @ ; diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index 85a6076..9dc433c 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -159,7 +159,7 @@ external ; : instance-to-package ( ihandle -- phandle ) - ?ihandle ihandle>phandle + ?ihandle instance-to-package ; : package-to-path ( buflen buf phandle -- length ) -- 1.7.10.4

2 4

[PATCH 0/6] Improve network device support (with a bit of PCI map work)
by Mark Cave-Ayland 10 Sep '17

10 Sep '17

Now that QEMU 2.10 is out, here's the next set of patches in preparation for improving the NIC support for PPC Mac machines (sungem) and sun4u machines (sunhme). Also included is a little rework of the Forth ob_pci_bus_map_in() so PCI BARs can be mapped within the various _cb C functions which is needed to extract the MAC address from the sungem hardware and add it to the DT. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (6): pci: move pci_decode_pci_addr() towards the top of pci.c pci: split the PCI mapping code out of ob_pci_bus_map_in() into ob_pci_map() pci: add basic support for Apple SunGEM pci: add ob_pci_unmap() to unmap PCI memory pci: add SUN hme network device pci: add Intel e1000 network device to PCI database drivers/pci.c | 134 ++++++++++++++++++++++++++++++++++-------------- drivers/pci_database.c | 18 +++++++ drivers/pci_database.h | 2 + include/drivers/pci.h | 3 ++ 4 files changed, 118 insertions(+), 39 deletions(-) -- 1.7.10.4

1 7

System Health Monitoring and current build compatibility
by Rohret, David M 12 Aug '17

12 Aug '17

Greetings, I have a project to monitor the voltage from a mainboards power conditioner and trigger a warning when it exceeds normal parameters by more than 7%. Commercial bios dev teams are reluctant to divulge any information, so I would like to install my own instance to do the job. I have 1 quick and 1 not so quick questions: 1. ??I'm not confined to a specific motherboard, so I would like to use one that is compatible with the latest build of OpenBios; suggestions? 2. If anyone has dealt with system health, any suggestions where to start? I appreciate any help! Dave David M. Rohret, CSRA, Inc. Senior Principal Systems Engineer // Distinguished Engineer CSRA Inc. | Defense | Air force | FIERCE Labs david.rohret(a)csra.com<mailto:bob.donnelly@csra.com> Unique Mission Cell/JVAB, p: 210-218-1954 This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

3 2

Re: [OpenBIOS] [Qemu-ppc] Windows NT 4.0 for PowerPC
by Programmingkid 31 Jul '17

31 Jul '17

> On Jul 30, 2017, at 11:25 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 28/07/17 02:27, Programmingkid wrote: > >>> On Jul 27, 2017, at 12:36 PM, Răzvan Corneliu C.R. VILT <razvan.vilt(a)gmail.com> wrote: >>> >>> Andrei Warkentin managed to get as far as booting veneer.exe but it crashes at the NT Kernel using his prephv build (https://github.com/andreiw/prephv/). >>> >>> OpenBIOS cannot load PE Images and I believe that even if PE loading was added to it, it wouldn't help since you also have some special >> requirements for little endian booting and some for the load-base. > > I'd be very interested to discuss some of this over on the OpenBIOS > mailing list - writing a PE driver should be fairly simple these days. > >>> Veneer.exe is basically an emulator for the ARC Firmware needed by the NT OSLoader.exe on top of the openfirmware environment. >>> >>> About one year ago I did some digging into this documented on Artyom's blog. >>> http://tyom.blogspot.ro/2014/09/open-firmware-for-qemu-system-ppc-m-prep.ht… >>> >>> If you want, you can write a minimal MZ-PE Loader in Forth and we'll take it from there. > > All of the other OpenBIOS loaders are written in C, so I don't see why > the same couldn't be done for MZ-PE, especially as most people find that > considerably easier than Forth. > > > ATB, > > Mark. Hi Mark. I was just thinking about asking you about this. It would be fun to make Windows NT 4.0 PowerPC work in QEMU. For anyone who is interested I found this page on the PE format. It might be helpful: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).…

3 6

Adding new device in the middle of device-tree
by BALATON Zoltan 17 Jul '17

17 Jul '17

Hello, Is there a way to add a new device in the middle of the device tree (before or after an existing node) from Forth? If I try: dev / new-device " newdev" device-name finish-device show-devs /newdev appears at the end of the device-tree but that's not what I want. I need this device to go at a specific place in the middle but I could not find out how to achieve that. Any ideas? Thank you, BALATON Zoltan

4 17

[PATCH 0/2] SPARC64: complete switch to Simba PCI bridge configuration
by Mark Cave-Ayland 16 Jul '17

16 Jul '17

This is the final set of changes required to switch SPARC64 over to use the QEMU machine configuration with Simba bridges. Note that this is currently pending approval of pre-requisite patches for the corresponding sun4u patchset. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): SPARC64: switch to simba PCI bridge machine configuration pci: set cmd646 name and device_type properties to "ide" arch/sparc64/openbios.c | 2 +- drivers/pci.c | 22 ++++++++++++++-------- drivers/pci_database.c | 2 +- 3 files changed, 16 insertions(+), 10 deletions(-) -- 1.7.10.4

1 2

[PATCH 00/13] SPARC64: sabre/simba bridge fixups
by Mark Cave-Ayland 12 Jul '17

12 Jul '17

This patchset prepares the way for changing the QEMU sun4u machine to be much closer to a real Ultra 5. The main change we are aiming for is to replicate the PCI bus topology so that onboard devices are attached behind simba A and simba B is an empty PCI bus (although devices can be added via QEMU's -device syntax). Note that this patch does all of the preparation work but doesn't actually implement the changes required by the switch. This is because the QEMU patches are still awaiting upstream approval and change to the sun4u machine must be synchronised between QEMU and OpenBIOS. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (13): SPARC64: increase size of PCI memory space SPARC64: increase size of PCI IO space SPARC64: fix PCI memory base in host ranges SPARC64: fix PCI configuration space size SPARC64: implement custom PCI bus scan for sabre SPARC64: add custom sabre reg property to sabre_config_cb() pci: implement simba_config_cb() for programming device ranges pci: update interrupt-map-mask to include the bus during interrupt comparisons pci: don't set interrupt-map and interrupt-map-mask properties if empty pci: rename SUN4U_INTERRUPT to SUN4U_PCIAINTERRUPT pci: alter ob_configure_pci_device() to return its device phandle pci: use ob_pci_bus_set_interrupt_map() to configure interrupts for Simba PCI bus B pci: map Simba PCI bus A on-board devices to fixed interrupts arch/sparc64/openbios.c | 12 ++-- drivers/pci.c | 175 ++++++++++++++++++++++++++++++++++++++++++----- drivers/pci_database.c | 2 +- drivers/pci_database.h | 1 + 4 files changed, 167 insertions(+), 23 deletions(-) -- 1.7.10.4

1 14

[PATCH 0/5] pci: allow customisation of PCI host bridge ranges
by Mark Cave-Ayland 12 Jul '17

12 Jul '17

Whilst debugging some SPARC64 issues relating to PCI bridges, it became apparent that the logic for generating the ranges property for the PCI host bridge isn't flexible enough to allow generation of the correct values across all architectures. In order to allow per-architecture customisation of PCI host bridge properties, split them out into a separate struct within pci_arch_t and migrate all PCI architectures over to use them. As a side effect we can now remove the rbase and rlen members from pci_arch_t since they are no longer required. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (5): pci: define pci_range_t typedef and add it to pci_arch_t struct pci: move memory type enum from drivers/pci.c to include/drivers/pci.h arch: update pci_host_t host_ranges with values for each architecture pci: update pci_set_host_ranges() to use the new pci_arch_t host_ranges arch: remove rbase and rlen from pci_arch_t for all PCI architectures arch/ppc/qemu/init.c | 29 +++++++++++++++++------- arch/sparc64/openbios.c | 6 +++++ arch/x86/openbios.c | 4 ++++ drivers/pci.c | 56 ++++++++++++++--------------------------------- include/drivers/pci.h | 19 ++++++++++++++-- 5 files changed, 64 insertions(+), 50 deletions(-) -- 1.7.10.4

1 6

[PATCH 0/2] pc_kbd: implement 8042 controller and separate keyboard/mouse devices
by Mark Cave-Ayland 12 Jul '17

12 Jul '17

Compared with real SPARC/PReP device trees, an 8042 controller should be modelled as a separate device with keyboard (and optionally mouse) devices beneath it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): pc_kbd: place keyboard device under 8042 controller device pc_kbd: add optional mouse device support for 8042 devices drivers/pc_kbd.c | 112 ++++++++++++++++++++++++++++++++++++++------- drivers/pci.c | 4 +- include/drivers/drivers.h | 4 +- 3 files changed, 100 insertions(+), 20 deletions(-) -- 1.7.10.4

1 3

[PATCH 0/3] Misc fixup patches
by Mark Cave-Ayland 12 Jul '17

12 Jul '17

This is a small set of fixes that came out of my current queue of SPARC64 patches. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): vga.fs: do not attempt to map MMIO registers more than once pci: always use devfn 0 for PCI host bridge ranges SPARC64: fix up PCI-EBus interrupt map and ino for PS/2 keyboard device drivers/pci.c | 21 +++++++++++++++------ drivers/vga.fs | 4 +++- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4

1 4

[PATCH] pci: fix accidental io_base reset for PCI host bridge
by Mark Cave-Ayland 12 Jul '17

12 Jul '17

Commit c80a58b added a workaround to allow ioport access through the first PCI bridge found until its base and limits were programmed, so that on-board devices not directly attached to the PCI host bus could be used during OpenBIOS initialisation. Unfortunately the logic was broken, and in fact the reset should only occur if we're the first PCI bridge that isn't the host bridge - otherwise we end up resetting io_base for the PCI host bus causing its devices to be mapped over existing in-built ioports causing strange behaviour. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci.c b/drivers/pci.c index db92683..92938a4 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1426,7 +1426,7 @@ static void ob_configure_pci_bridge(pci_addr addr, /* Always expose the legacy ioports on the first PCI bridge. If we must have legacy devices behind a PCI bridge then they must be on the first one discovered to ensure that the ioports will work. */ - if (*io_base < 0x1000) { + if (primary_bus > 0 && *io_base < 0x1000) { *io_base = 0x0; } -- 1.7.10.4

1 1

[PATCH] vga.fs: add support for QEMU PCI MMIO register access
by Mark Cave-Ayland 18 Jun '17

18 Jun '17

Currently the driver works by using the legacy VGA ioports for programming the display. However this makes it much harder to configure e.g. multiple displays or VGA devices behind multiple PCI bridges. If building for QEMU, default to using the QEMU PCI MMIO registers to program the display. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/vga.fs | 85 ++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/drivers/vga.fs b/drivers/vga.fs index cbfa46c..d39b062 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -47,6 +47,22 @@ fcode-version3 : ioc! ioc!-xt execute ; : iow! iow!-xt execute ; +" le-w!" (find-xt) value le-w!-xt + +: le-w! le-w!-xt execute ; + +\ +\ PCI +\ + +" pci-bar>pci-addr" (find-xt) value pci-bar>pci-addr-xt +: pci-bar>pci-addr pci-bar>pci-addr-xt execute ; + +h# 10 constant cfg-bar0 \ Framebuffer BAR +h# 18 constant cfg-bar2 \ QEMU MMIO ioport BAR +-1 value fb-addr +-1 value mmio-addr + \ \ VGA registers \ @@ -55,12 +71,22 @@ h# 3c0 constant vga-addr h# 3c8 constant dac-write-addr h# 3c9 constant dac-data-addr +defer vga-ioc! + +: vga-legacy-ioc! ( val addr ) + ioc! +; + +: vga-mmio-ioc! ( val addr ) + h# 3c0 - h# 400 + mmio-addr + c! +; + : vga-color! ( r g b index -- ) \ Set the VGA colour registers - dac-write-addr ioc! rot - 2 >> dac-data-addr ioc! swap - 2 >> dac-data-addr ioc! - 2 >> dac-data-addr ioc! + dac-write-addr vga-ioc! rot + 2 >> dac-data-addr vga-ioc! swap + 2 >> dac-data-addr vga-ioc! + 2 >> dac-data-addr vga-ioc! ; \ @@ -86,17 +112,23 @@ h# 1 constant VBE_DISPI_ENABLED \ Bochs VBE register writes \ -: vbe-iow! ( val addr -- ) +defer vbe-iow! + +: vbe-legacy-iow! ( val addr -- ) h# 1ce iow! h# 1d0 iow! ; +: vbe-mmio-iow! ( val addr -- ) + 1 lshift h# 500 + mmio-addr + cr .s cr le-w! +; + \ \ Initialise Bochs VBE mode \ : vbe-init ( -- ) - h# 0 vga-addr ioc! \ Enable blanking + h# 0 vga-addr vga-ioc! \ Enable blanking VBE_DISPI_DISABLED VBE_DISPI_INDEX_ENABLE vbe-iow! h# 0 VBE_DISPI_INDEX_X_OFFSET vbe-iow! h# 0 VBE_DISPI_INDEX_Y_OFFSET vbe-iow! @@ -104,20 +136,14 @@ h# 1 constant VBE_DISPI_ENABLED openbios-video-height VBE_DISPI_INDEX_YRES vbe-iow! depth-bits VBE_DISPI_INDEX_BPP vbe-iow! VBE_DISPI_ENABLED VBE_DISPI_INDEX_ENABLE vbe-iow! - h# 0 vga-addr ioc! - h# 20 vga-addr ioc! \ Disable blanking + h# 0 vga-addr vga-ioc! + h# 20 vga-addr vga-ioc! \ Disable blanking ; \ -\ PCI +\ PCI BAR mapping \ -" pci-bar>pci-addr" (find-xt) value pci-bar>pci-addr-xt -: pci-bar>pci-addr pci-bar>pci-addr-xt execute ; - -h# 10 constant cfg-bar0 \ Framebuffer BAR --1 value fb-addr - : map-fb ( -- ) cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) " pci-map-in" $call-parent @@ -125,6 +151,32 @@ h# 10 constant cfg-bar0 \ Framebuffer BAR then ; +: map-mmio ( -- ) + cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size ) + " pci-map-in" $call-parent + to mmio-addr + then +; + +\ +\ Legacy IO port or QEMU MMIO accesses +\ +\ legacy: use standard VGA ioport registers +\ MMIO: use QEMU PCI MMIO VGA registers +\ +\ If building for QEMU, default to MMIO access since it allows +\ programming of the VGA card regardless of its position in the +\ PCI topology +\ + +[IFDEF] CONFIG_QEMU +['] vga-mmio-ioc! to vga-ioc! +['] vbe-mmio-iow! to vbe-iow! +[ELSE] +['] vga-legacy-ioc! to vga-ioc! +['] vbe-legacy-iow! to vbe-iow! +[THEN] + \ \ Publically visible words \ @@ -181,6 +233,7 @@ headerless \ : qemu-vga-driver-install ( -- ) + map-mmio vbe-init fb-addr -1 = if map-fb fb-addr to frame-buffer-adr default-font set-font @@ -193,8 +246,6 @@ headerless ; : qemu-vga-driver-init - - vbe-init openbios-video-width encode-int " width" property openbios-video-height encode-int " height" property depth-bits encode-int " depth" property -- 1.7.10.4

2 4

[PATCH 0/8] pci: fix up PCI bridges
by Mark Cave-Ayland 18 Jun '17

18 Jun '17

In order to progress further with sun4u in QEMU, it has become necessary to introduce PCI bridges similar to a real Ultra 5. This is because several OSs make assumptions about the PCI topology, and without the PCI bridge in place will either crash or fail to map memory regions correctly. This first patchset fixes up PCI bridges so that we can now enumerate them correctly. As an idea as to where I'm going with this, if you also take the WIP QEMU branch at https://github.com/mcayland/qemu/tree/sparc64-pcibridge then the output of show-devs looks like this: Welcome to OpenBIOS v1.1 built on Jun 11 2017 06:57 Type 'help' for detailed information 0 > show-devs ffe1bf40 / ffe1c118 /aliases ffe1c240 /openprom (BootROM) ffe26b58 /openprom/client-services ffe1c4f8 /options ffe1c5d8 /chosen ffe1c718 /builtin ffe1c840 /builtin/console ffe26620 /packages ffe28648 /packages/cmdline ffe28898 /packages/disk-label ffe2c8e0 /packages/deblocker ffe2cef8 /packages/grubfs-files ffe2d308 /packages/sun-parts ffe2d720 /packages/elf-loader ffe2b218 /memory@0,0 (memory) ffe2b378 /virtual-memory ffe2d880 /pci@1fe,0 (pci) ffe2e1b0 /pci@1fe,0/pci@1 (pci) ffe2e8c8 /pci@1fe,0/pci@1,1 (pci) ffe2efb0 /pci@1fe,0/pci@1,1/ebus@1 ffe2f7f0 /pci@1fe,0/pci@1,1/ebus@1/eeprom@0 ffe2f968 /pci@1fe,0/pci@1,1/ebus@1/fdthree@0 (block) ffe2feb8 /pci@1fe,0/pci@1,1/ebus@1/su@0 (serial) ffe30248 /pci@1fe,0/pci@1,1/ebus@1/kb_ps2@0 (serial) ffe305b8 /pci@1fe,0/pci@1,1/QEMU,VGA@2 (display) ffe31c30 /pci@1fe,0/pci@1,1/pci-ata@3 (pci-ide) ffe32188 /pci@1fe,0/pci@1,1/pci-ata@3/ide0@4000 (ide) ffe32468 /pci@1fe,0/pci@1,1/pci-ata@3/ide1@4100 (ide) ffe32700 /pci@1fe,0/pci@1,1/pci-ata@3/ide1@4100/cdrom@0 (block) ffe32d88 /pci@1fe,0/NE2000@2 (network) ffe33490 /SUNW,UltraSPARC-IIi (cpu) ok Note I have several more SPARC64-related fixes queued, however as this patchset is starting to get quite unwieldy it makes sense to split this part off separately. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (8): pci: add temporary bus-range property to PCI bridge devices pci: include PCI bus id in ob_pci_decode_unit() pci: create new ob_pci_bridge_node based upon ob_pci_bus_node pci: rename ob_pci_map_in() to ob_pci_bus_map_in() pci: implement ob_pci_bridge_map_in() for PCI-PCI bridge nodes pci: configure base and limit registers during PCI bridge configuration pci: split PCI bus interrupt maps from PCI host bridge interrupt maps pci: allow ob_pci_bus_set_interrupt_map() to take a callback function drivers/pci.c | 186 ++++++++++++++++++++++++++++++++++++++++++++------------- drivers/pci.h | 5 ++ 2 files changed, 150 insertions(+), 41 deletions(-) -- 1.7.10.4

1 9

[PATCH] libopenbios: add Forth LE memory access words
by Mark Cave-Ayland 18 Jun '17

18 Jun '17

These are particularly useful when accessing hardware registers from BE hosts. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- libopenbios/init.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/libopenbios/init.c b/libopenbios/init.c index aa99608..3ad9505 100644 --- a/libopenbios/init.c +++ b/libopenbios/init.c @@ -15,12 +15,56 @@ */ #include "config.h" +#include "libc/byteorder.h" #include "libopenbios/openbios.h" #include "libopenbios/bindings.h" #include "libopenbios/initprogram.h" #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h" + +/* + * le-w! ( w waddr -- ) + */ + +static void lewstore(void) +{ + u16 *aaddr = (u16 *)cell2pointer(POP()); + const u16 word = POP(); + *aaddr = __cpu_to_le16(word); +} + +/* + * le-l! ( quad qaddr -- ) + */ + +static void lelstore(void) +{ + u32 *aaddr = (u32 *)cell2pointer(POP()); + const u32 longval = POP(); + *aaddr = __cpu_to_le32(longval); +} + +/* + * le-w@ ( waddr -- w ) + */ + +static void lewfetch(void) +{ + const u16 *aaddr = (u16 *)cell2pointer(POP()); + PUSH(__le16_to_cpu(*aaddr)); +} + +/* + * le-l@ ( qaddr -- quad ) + */ + +static void lelfetch(void) +{ + const u32 *aaddr = (u32 *)cell2pointer(POP()); + PUSH(__le32_to_cpu(*aaddr)); +} + void openbios_init( void ) { @@ -36,4 +80,10 @@ openbios_init( void ) // Bind the C implementation of (go) into Forth bind_func("(go)", go); + + // Bind the LE access words + bind_func("le-w!", lewstore); + bind_func("le-l!", lelstore); + bind_func("le-w@", lewfetch); + bind_func("le-l@", lelfetch); } -- 1.7.10.4

1 1

[PATCH] libopenbios: fix build for platforms without fw_cfg interface
by Mark Cave-Ayland 18 Jun '17

18 Jun '17

Commit 7130437 "fw_cfg: implement fw-cfg-read-file Forth word" added a binding for the Forth version of fw_cfg_read_file() into libopenbios/init.c but forgot to only include the binding when CONFIG_DRIVER_FW_CFG was defined. This broke the build for platforms which don't have the fw_cfg interface enabled by default such as x86. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- libopenbios/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libopenbios/init.c b/libopenbios/init.c index aa99608..e08df19 100644 --- a/libopenbios/init.c +++ b/libopenbios/init.c @@ -28,8 +28,10 @@ openbios_init( void ) PUSH(pointer2cell((void *)&__context)); feval("['] __context cell+ !"); +#if defined(CONFIG_DRIVER_FW_CFG) // Bind the Forth fw_cfg file interface bind_func("fw-cfg-read-file", forth_fw_cfg_read_file); +#endif // Bind the C implementation of (init-program) into Forth bind_func("(init-program)", init_program); -- 1.7.10.4

1 1

Curious as to current status
by Jonathan C Day 10 Jun '17

10 Jun '17

Hi, The git repository seems alive, so there's someone out there, but the main website hasn't been updated in a while and the list is... quiet. I'm looking to find out where OpenBIOS is, if it handles large devices (or if I need TianoCore for that, which I'd really not like) and whether the project is still in serious development (good) or is more maintenance mode (proprietary vendors have won). I'm also curious as to what will boot cleanly. Coreboot only seems to give results for direct payloads and SeaBIOS, and I don't see a list on OpenBIOS' site (but may have missed it), so it's not obvious what works well, what's YMMV and what's in the paperweight category. If things are semi-active to active, and if I can find a way to program the flash chip when things fail, I'd be happy to do testing. Jonathan Day

2 1