Re: Missing dimm-info properties in openbios ?

qemu-ppc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing dimm-info properties in openbios ?

From:	BALATON Zoltan
Subject:	Re: Missing dimm-info properties in openbios ?
Date:	Fri, 21 Mar 2025 20:21:54 +0100 (CET)

On Fri, 21 Mar 2025, Andrew Randrianasulu wrote:

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

If it gets further after a lot of these then maybe not that important,only if it stops with this and never progresses. But looking atqemu/include/hw/scsi/esp.h:


#define STAT_GE 0x40

and in qemu/hw/m68k/q800.c:

#define ESP_BASE              (IO_BASE + 0x10000)

So this seems very similar, maybe just try copying over the parts fromq800_machine_init() that create the esp device to a macio_realize_mesh()function in qemu/hw/misc/macio/macio.c and call it frommacio_oldworld_realize (or macio_common_realize if newworld macio also hasthis cell) and see if that helps. This should map the registers in themacio's mmio region at offset 0x10000 as done for other devices but youcan look at those for examples.


Regards,
BALATON Zoltan

[Prev in Thread]

Current Thread

[Next in Thread]

Re: Missing dimm-info properties in openbios ?, (continued)

Prev by Date: Re: Missing dimm-info properties in openbios ?
Next by Date: Re: Missing dimm-info properties in openbios ?
Previous by thread: Re: Missing dimm-info properties in openbios ?
Next by thread: Re: Missing dimm-info properties in openbios ?
Index(es):
- Date
- Thread