Re: Missing dimm-info properties in openbios ?

[Andrew Randrianasulu]

On Fri, Mar 21, 2025 at 6:01 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Fri, 21 Mar 2025, Andrew Randrianasulu wrote:
> > On Fri, Mar 21, 2025 at 5:06 PM Andrew Randrianasulu
> > <randrianasulu@gmail.com> wrote:
> >> On Fri, Mar 21, 2025 at 4:49 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>> On Fri, 21 Mar 2025, Andrew Randrianasulu wrote:
> >>>> On Fri, Mar 21, 2025 at 7:55 AM Andrew Randrianasulu
> >>>> <randrianasulu@gmail.com> wrote:
> >>>>> On Fri, Mar 21, 2025 at 7:51 AM Andrew Randrianasulu
> >>>>> <randrianasulu@gmail.com> wrote:
> >>>>>> On Fri, Mar 21, 2025 at 6:44 AM Andrew Randrianasulu
> >>>>>> <randrianasulu@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> пт, 21 мар. 2025 г., 03:33 BALATON Zoltan <balaton@eik.bme.hu>:
> >>>>>>>>
> >>>>>>>> On Fri, 21 Mar 2025, Andrew Randrianasulu wrote:
> >>>>>>>>> чт, 20 мар. 2025 г., 23:41 BALATON Zoltan <balaton@eik.bme.hu>:
> >>>>>>>>>> On Thu, 20 Mar 2025, Andrew Randrianasulu wrote:
> >>>>>>>>>>> Will look at ATA situation, some said SATA was more likely to 
> >>>>>>>>>>> work on
> >>>>>>>>>> real
> >>>>>>>>>>> machines.
> >>>>>>>>>>
> >>>>>>>>>> I think we've tested that too at some point. There's -device 
> >>>>>>>>>> sii3112 that
> >>>>>>>>>> I've added for sam460ex and AmigaOS but this is a common chip also 
> >>>>>>>>>> found
> >>>>>>>>>> on some Mac compatible SATA cards. You just need the FCode ROM 
> >>>>>>>>>> from one of
> >>>>>>>>>> those, which were available in updates to these cards. There was 
> >>>>>>>>>> one from
> >>>>>>>>>> SeriTek and one from WiebeSATA3112 and I think at least one of 
> >>>>>>>>>> those
> >>>>>>>>>> worked with my patches to OpenBIOS to run the ROM so it should 
> >>>>>>>>>> work with
> >>>>>>>>>> real OpenFirmware too. Although that can be a workaround, it would 
> >>>>>>>>>> still
> >>>>>>>>>> be interesting to know why the on board IDE does not work. Maybe it
> >>>>>>>>>> emulates the IDE found on the G4 but the G3 had something 
> >>>>>>>>>> different? There
> >>>>>>>>>> were names like Keylargo and O'Hare but I don't remember what 
> >>>>>>>>>> these were
> >>>>>>>>>> exactly.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> according to dppc files ...
> >>>>>>>>>
> >>>>>>>>> https://github.com/dingusdev/dingusppc/blob/master/devices/ioctrl/heathrow.cpp
> >>>>>>>>>
> >>>>>>>>> https://github.com/dingusdev/dingusppc/blob/master/devices/ioctrl/macio.h
> >>>>>>>>>
> >>>>>>>>> Heathrow , O'hare, GrandCentral all revisions of macio chip ....
> >>>>>>>>>
> >>>>>>>>> /** PCI device IDs for various MacIO ASICs. */
> >>>>>>>>> enum {
> >>>>>>>>>    MIO_DEV_ID_GRANDCENTRAL = 0x0002,
> >>>>>>>>>    MIO_DEV_ID_OHARE        = 0x0007,
> >>>>>>>>>    MIO_DEV_ID_HEATHROW     = 0x0010,
> >>>>>>>>>    MIO_DEV_ID_PADDINGTON   = 0x0017,
> >>>>>>>>> };
> >>>>>>>>
> >>>>>>>> In QEMU macio-oldworld sets PCI device_id to 
> >>>>>>>> PCI_DEVICE_ID_APPLE_343S1201
> >>>>>>>> which is 0x10 so seems to match Heathrow. Does that match with what a
> >>>>>>>> beige G3 should have?
> >>>>>>>
> >>>>>>>
> >>>>>>> well, according to this file
> >>>>>>>
> >>>>>>> https://github.com/dingusdev/dingusppc/blob/master/machines/machinegossamer.cpp
> >>>>>>>
> >>>>>>> there are TWO types of G3 BEIGE
> >>>>>>>
> >>>>>>> Power Macintosh G3 (Beige) Tower
> >>>>>>> Power Macintosh G3 (Beige) Desktop
> >>>>>>>
> >>>>>>> hm, default storage device here seems to be ATA ....
> >>>>>>>
> >>>>>>> Also, I was wrong about Ethernet on those ...
> >>>>>>> https://github.com/dingusdev/dingusppc/blob/master/zdocs/developers/bmac.md
> >>>>>>>
> >>>>>>> =====
> >>>>>>>
> >>>>>>> BMac aka BigMac is an Ethernet media access controller cell 
> >>>>>>> integrated in the Heathrow and Paddington I/O controllers. According 
> >>>>>>> to a former Apple employee, BMac has been licensed from Sun. It's 
> >>>>>>> therefore not surprising that it has a lot in common with the Sun 
> >>>>>>> "Happy Meal" (HME) controller.
> >>>>>>>
> >>>>>>> BMac based Ethernet HW
> >>>>>>>
> >>>>>>> There are three BMac based HW configurations:
> >>>>>>>
> >>>>>>> BMac in a Heathrow I/O + LXT907 PHY used in Power Macintosh G3 (Old 
> >>>>>>> World)
> >>>>>>> BMac+ in a Paddington I/O + LXT970 aka ST10040 PHY in Power Macintosh 
> >>>>>>> Blue & White (New World)
> >>>>>>> BMac+ in a Paddington I/O + DP83843 PHY in a Bronze Keyboard 
> >>>>>>> PowerBook G3
> >>>>>>>
> >>>>>>> Documentation
> >>>>>>>
> >>>>>>> No official documentation has surfaced so far. Fortunately, the 
> >>>>>>> official source code as well as the STP2002 datasheet provide enough 
> >>>>>>> information on the BMac device.
> >>>>>>>
> >>>>>>> Apple source code: 
> >>>>>>> https://github.com/apple-oss-distributions/AppleBMacEthernet
> >>>>>>> STP2002 datasheet: https://people.freebsd.org/~wpaul/STP2002QFP-UG.pdf
> >>>>>>>
> >>>>>>> ===== quote end ====
> >>>>>>>
> >>>>>>> and yea, some people updated their G3 cpus to G4 in those machines, 
> >>>>>>> so G4 in g3beige is valid combo ..  not sure about real memory 
> >>>>>>> ceiling .. some said 1.5 Gb ?
> >>>>>>>
> >>>>>>>
> >>>>>>>> (G4 has Keylargo which is 0x22, G5 may have an even
> >>>>>>>> newer, something like K2 but that's not emulated and O'Hare may be in
> >>>>>>>> older Macs then so not interesting for us.)
> >>>>>>>>
> >>>>>>>>> but what worties me most - Dppc's emulation of
> >>>>>>>>> device_write/device_read/dma_read/dma_write seems to be much more 
> >>>>>>>>> complex
> >>>>>>>>> than qemu's (living in hw/intc and hw/misc/macio)
> >>>>>>>>>
> >>>>>>>>> And there is whole comment about ide1 being mediabay (so you can 
> >>>>>>>>> put floppy
> >>>>>>>>> there ...)
> >>>>>>>>>
> >>>>>>>>> uint8_t  cpu_id = 0xE0; // CPUID field (LSB of the MIO_HEAT_ID)
> >>>>>>>>>    uint8_t  mb_id  = 0x70; // Media Bay ID (bits 15:8 of the 
> >>>>>>>>> MIO_HEAT_ID)
> >>>>>>>>>    uint8_t  mon_id = 0x10; // Monitor ID (bits 23:16 of the 
> >>>>>>>>> MIO_HEAT_ID)
> >>>>>>>>>    uint8_t  fp_id  = 0x70; // Flat panel ID (MSB of the MIO_HEAT_ID)
> >>>>>>>>>    uint8_t  emmo_pin;      // factory tester status, active low
> >>>>>>>>>
> >>>>>>>>>    // subdevice objects
> >>>>>>>>>    MacioSndCodec*      snd_codec; // audio codec instance
> >>>>>>>>>
> >>>>>>>>>    NVram*              nvram;    // NVRAM
> >>>>>>>>>    ViaCuda*            viacuda;  // VIA cell with Cuda MCU attached 
> >>>>>>>>> to it
> >>>>>>>>>    MeshController*     mesh;     // MESH SCSI cell instance
> >>>>>>>>>    EsccController*     escc;     // ESCC serial controller
> >>>>>>>>>    IdeChannel*         ide_0;    // Internal ATA
> >>>>>>>>>    IdeChannel*         ide_1;    // Media Bay ATA
> >>>>>>>>>
> >>>>>>>>> ======
> >>>>>>>>>
> >>>>>>>>> of course dppc is modern (c++20?) c++ so  some of this might be
> >>>>>>>>> architecture difference between emulators, but I am afraid it might 
> >>>>>>>>> be more
> >>>>>>>>> complex than just wrong dma channel or address ....
> >>>>>>>>
> >>>>>>>> A lot of difference may just be different implementation and maybe 
> >>>>>>>> DPCC
> >>>>>>>> implements DMA in the same object whereas in QEMU there's a separate 
> >>>>>>>> DBDMA
> >>>>>>>> emulation that I think is also used for IDE and sound. So if you add 
> >>>>>>>> that
> >>>>>>>> too and all the IDE emulation in QEMU then it may be similar 
> >>>>>>>> complexity
> >>>>>>>> just broken down in different ways. But we're missing SWIM MESH and 
> >>>>>>>> the
> >>>>>>>> ethernet from QEMU for sure, these are only emulated for q800 but not
> >>>>>>>> hooked up in macio and may be needed for the Mac ROM.
> >>>>>>>>
> >>>>>>>> The macio IDE is in qemu/hw/ide/macio.c. It does not have traces but 
> >>>>>>>> has a
> >>>>>>>> debug define that you could enable and see if the Mac ROM tries to 
> >>>>>>>> access
> >>>>>>>> this device at all and if it gets some error or it could be guessed 
> >>>>>>>> from
> >>>>>>>> the accesses where it might fail. If it does not even poke the device
> >>>>>>>> there's some other problem before that but if it appears in the 
> >>>>>>>> device
> >>>>>>>> tree then probably it at least detected it but maybe failed to set 
> >>>>>>>> it up
> >>>>>>>> because got some unexpected results.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> yea, something to try and check out ;)
> >>>>>>>
> >>>>>>> But dog walk first ;)
> >>>>>>
> >>>>>> Interestingly, qemu's G3beige  boot original firmware with 2047 Mb ram.
> >>>>>>
> >>>>>> netbsd10$ ~/src/qemu/build/qemu-system-ppc -bios
> >>>>>> ~/K38_sdcard1/Documents/1997w-11\ -\ 78F57389\ -\ Power\ Mac\ G3\
> >>>>>> \(v3\).ROM     -d unimp,guest_errors -device
> >>>>>> ati-vga,addr=0x12,romfile=/home/guest/ati-fcode-roms/ati_oem_rage128pro_11
> >>>>>> 0_agp_full.rom    -m 2047 -M g3beige  -drive
> >>>>>> if=mtd,format=raw,file=nvram.img
> >>>>>> -cdrom ~/obj/releasedir/images/NetBSD-10.99.12-macppc.iso -trace *ide*
> >>>>>> -icount shift=1
> >>>>>> ide_reset IDEstate 0x76b6112c6818
> >>>>>> ide_reset IDEstate 0x76b6112c6bf0
> >>>>>> ide_reset IDEstate 0x76b6112c75b8
> >>>>>> ide_reset IDEstate 0x76b6112c7990
> >>>>>> ide_reset IDEstate 0x76b6112c75b8
> >>>>>> ide_reset IDEstate 0x76b6112c75b8
> >>>>>> ide_reset IDEstate 0x76b6112c7990
> >>>>>> ide_reset IDEstate 0x76b6112c6818
> >>>>>> ide_reset IDEstate 0x76b6112c6bf0
> >>>>>> portA_write unimplemented
> >>>>>> CUDA: unimplemented GET_SET_IIC read 0x28 1
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 2
> >>>>>> CUDA: unknown command 0x26
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x0e; bus 
> >>>>>> 0x76b6112c6790
> >>>>>> ide_reset IDEstate 0x76b6112c6818                                      
> >>>>>>        B
> >>>>>> ide_reset IDEstate 0x76b6112c6bf0                                      
> >>>>>>        e
> >>>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x08; bus 
> >>>>>> 0x76b6112c6790g
> >>>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x0e; bus 
> >>>>>> 0x76b6112c7530
> >>>>>> ide_reset IDEstate 0x76b6112c75b8                                      
> >>>>>>        w
> >>>>>> ide_reset IDEstate 0x76b6112c7990
> >>>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x08; bus 
> >>>>>> 0x76b6112c7530
> >>>>>> CUDA: COMBINED_FORMAT_IIC: wrong parameters 4
> >>>>>
> >>>>>
> >>>>>
> >>>>> aw, it was cut a bit by xterm's  width
> >>>>>
> >>>>> netbsd10$ ~/src/qemu/build/qemu-system-ppc -bios
> >>>>> ~/K38_sdcard1/Documents/1997-11\ -\ 78F57389\
> >>>>> -\ Power\ Mac\ G3\ \(v3\).ROM     -d unimp,guest_errors -device
> >>>>> ati-vga,addr=0x12,romfile=/home/guest/ati-fcode-roms/ati_oem_rage128pro_110_agp_full.rom
> >>>>>    -m 2047 -M g3beige  -drive if=mtd,format=raw,file=nvram.img -cdrom
> >>>>> ~/obj/releasedir/images/NetBSD-10.99.12-macppc.iso -trace *ide*
> >>>>> -icount shift=1
> >>>>> ide_reset IDEstate 0x7da75a76de18
> >>>>> ide_reset IDEstate 0x7da75a76e1f0
> >>>>> ide_reset IDEstate 0x7da75a76ebb8
> >>>>> ide_reset IDEstate 0x7da75a76ef90
> >>>>> ide_reset IDEstate 0x7da75a76ebb8
> >>>>> ide_reset IDEstate 0x7da75a76ebb8
> >>>>> ide_reset IDEstate 0x7da75a76ef90
> >>>>> ide_reset IDEstate 0x7da75a76de18
> >>>>> ide_reset IDEstate 0x7da75a76e1f0
> >>>>> portA_write unimplemented
> >>>>> CUDA: unimplemented GET_SET_IIC read 0x28 1
> >>>>> CUDA: GET_SET_IIC: wrong parameters 2
> >>>>> CUDA: unknown command 0x26
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> CUDA: unimplemented GET_SET_IIC write 0x45 3
> >>>>> CUDA: GET_SET_IIC: wrong parameters 4
> >>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x0e; bus 
> >>>>> 0x7da75a76dd90
> >>>>> ide_reset IDEstate 0x7da75a76de18
> >>>>> ide_reset IDEstate 0x7da75a76e1f0
> >>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x08; bus 
> >>>>> 0x7da75a76dd90
> >>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x0e; bus 
> >>>>> 0x7da75a76eb30
> >>>>> ide_reset IDEstate 0x7da75a76ebb8
> >>>>> ide_reset IDEstate 0x7da75a76ef90
> >>>>> ide_ctrl_write IDE PIO wr @ 0x0 (Device Control); val 0x08; bus 
> >>>>> 0x7da75a76eb30
> >>>>> CUDA: COMBINED_FORMAT_IIC: wrong parameters 4
> >>>>>
> >>>>>
> >>>>
> >>>> hm interesting.
> >>>>
> >>>> In DPPC and same rom
> >>>>
> >>>> netbsd10$ bin/dingusppc -b ~/K38_sdcard1/Documents/1997-11\ -\
> >>>> 78F57389\ -\ Power\ Mac\ G3\ \(v3\).ROM   -r --rambank1_size 256
> >>>> --rambank2_size 256 --rambank3_size 256
> >>>>
> >>>> if I press
> >>>>
> >>>> alt - windows - o -f (command-option-o-f) and get into OF console I
> >>>> *also* can't just dev into ide0/1 or ide.
> >>>>
> >>>> YET in both qemu and DPPC I can dump-device-tree and see disk methods
> >>>> for ATA .. :) :(
> >>>>
> >>>> qemu + OpenFirmware 2.4 indeed does not want to show image of diskette
> >>>> with blinking question mark after i type BYE in OF's prompt
> >>>>
> >>>> But may be last two lines
> >>>>
> >>>> Trying to write invalid spr 0 (0x000) at fff10d38
> >>>> Trying to read invalid spr 0 (0x000) at fff10d40
> >>>> Trying to write privileged spr 955 (0x3bb) at fff13190
> >>>> Trying to write invalid spr 959 (0x3bf) at fff131ac
> >>>> Trying to read invalid spr 959 (0x3bf) at fff131b4
> >>>> portA_write unimplemented
> >>>> portA_write unimplemented
> >>>
> >>> I don't know but I think maybe it just wants to check floppy and mesh for
> >>> boot device and stops there due to these not being emulated before getting
> >>> to try IDE so I think hooking up existing SWIM and ESP emulations to the
> >>> appropriate macio regions may help, but I don't know if these are register
> >>> compatible so just need instantiating the device and mapping their region
> >>> in macio or it also needs some register read/write functions to translate
> >>> the values and register layout. Mark has at least debugged these with 68k
> >>> q800 so maybe knows more about them.
> >>>
> >>>> have something to do with THAT (tried with 9.1 install iso working in
> >>>> DPPC - ~/src/qemu/build/qemu-system-ppc -bios
> >>>> ~/K38_sdcard1/Documents/1997-11\ -\ 78F57389\
> >>>> -\ Power\ Mac\ G3\ \(v3\).ROM     -d unimp,guest_errors -device
> >>>> ati-vga,addr=0x12,romfile=/home/guest/ati-fcode-roms/ati_oem_rage128pro_110_agp_full.rom
> >>>>   -m 2047 -M g3beige  -drive if=mtd,format=raw,file=nvram.img -cdrom
> >>>> ~/src/dingusppc/build/macos_91_ppc.iso  -trace *ide* -trace *dma*
> >>>> -trace *macio*  -icount shift=1
> >>>> )
> >>>>
> >>>> or may be it really want vertical interrupt  from onboard mach64 ? Or
> >>>> edid or something else ...
> >>>
> >>> There is a 60Hz VBlank interrupt in ati-vga which was needed for MacOS so
> >>> this should work. I think it's missing some macio parts that it assumes to
> >>> be there (which makes sense as it's part of the same chip) and cannot
> >>> handle them missing. Do you have the patch that adds unimp region to macio
> >>> to see access to unimplemented components? Maybe those would need to
> >>> return something sensible for it to continue.
> >>
> >> Not yet, will try to integrate it into my pike of  patches today.
> >
> > Patch added, log attached
> >
> > netbsd10$ ~/src/qemu/build/qemu-system-ppc -bios
> > ~/src/MacROMan/TestImages/4MB\ ROMs/1998-08-12\ -\ 78FDB784\ -\
> > PowerMac\ G3\ Minitower\ \(beige\ 266MHz\).ROM  -d unimp,guest_errors
> > -device
> > ati-vga,addr=0x12,romfile=/home/guest/ati-fcode-roms/ati_oem_rage128pro_110_agp_full.rom
> >   -m 768 -M g3beige  -drive if=mtd,format=raw,file=nvram.img -cdrom
> > ~/src/dingusppc/build/macos_91_ppc.iso -trace *macio* -S
> >
> >
> > ten "logfile filename' in Qemu monitor, then "c" and wait until it
> > boots intOFs framebuffer and gives prompt.
> >
> > Or should I try  to say BYE/BOOT ?
>
> Yes, the more interesting part is probably after bye

macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)
macio-unimp: unimplemented device read  (size 1, offset 0x10040)

much more of that

so  yes, it seems that it tries to  do something with MESH by default



but I'm not that
> interested in the log so instead of sending it you could try to find what
> the offsets correspond to and what whould be there and implement that in
> QEMU.
>
> Regards,
> BALATON Zoltan