OpenBIOS

openbios@openbios.org

2 participants
4297 discussions

[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 12 Feb '25

12 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

Jump to page: