Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Sat, 18 May 2024, BALATON Zoltan wrote:
> On Sat, 18 May 2024, Andrew Randrianasulu wrote:
> > On Sat, May 18, 2024 at 10:24 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >
> > > On Sat, 18 May 2024, Andrew Randrianasulu wrote:
> > > > Using attached patch I get this  new dmesg:
> > > >
> > > > Quiescing Open Firmware ...
> > > > > > of_client_interface: quiesce
> > > > > > of_client_interface return:
> > > > Booting Linux via __start() @ 0x01000000 ...
> > > > Hello World !
> > > > [    0.000000] Total memory = 512MB; using 1024kB for hash table
> > > > [    0.000000] Activating Kernel Userspace Execution Prevention
> > > > [    0.000000] Activating Kernel Userspace Access Protection
> > > > [    0.000000] Linux version 5.13.12_1 (voidlinux@voidlinux) (gcc (GCC)
> > > 10.2.1 20201203, GNU ld (GNU Binutils) 2.35.1) #1 SMP Thu Aug 19 14:12:26
> > > UTC 2021
> > > > [    0.000000] ioremap() called early from pmac_feature_init+0xd4/0xad4.
> > > Use early_ioremap() instead
> > > > [    0.000000] Found UniNorth memory controller & host bridge @
> > > 0xf8000000 revision: 0x07
> > > > [    0.000000] Mapped at 0xf73c0000
> > > > [    0.000000] ioremap() called early from probe_one_macio+0x17c/0x2b4.
> > > Use early_ioremap() instead
> > > > [    0.000000] Found a Keylargo mac-io controller, rev: 0, mapped at
> > > 0x(ptrval)
> > > > [    0.000000] PowerMac motherboard: PowerMac G4 AGP Graphics
> > > > [    0.000000] ioremap() called early from udbg_scc_init+0x1e4/0x3f8.
> > > Use early_ioremap() instead
> > > > [    0.000000] boot stdout isn't a display !
> > > > [    0.000000] ioremap() called early from find_via_cuda+0xb4/0x404. Use
> > > early_ioremap() instead
> > > > [    0.000000] Using PowerMac machine description
> > > > [    0.000000] printk: bootconsole [udbg0] enabled
> > > > [    0.000000] CPU maps initialized for 1 thread per core
> > > > [    0.000000] -----------------------------------------------------
> > > > [    0.000000] phys_mem_size     = 0x20000000
> > > > [    0.000000] dcache_bsize      = 0x20
> > > > [    0.000000] icache_bsize      = 0x20
> > > > [    0.000000] cpu_features      = 0x000000000501a00a
> > > > [    0.000000]   possible        = 0x00000000277de14a
> > > > [    0.000000]   always          = 0x0000000001000000
> > > > [    0.000000] cpu_user_features = 0x9c000001 0x00000000
> > > > [    0.000000] mmu_features      = 0x00000001
> > > > [    0.000000] Hash_size         = 0x100000
> > > > [    0.000000] Hash_mask         = 0x3fff
> > > > [    0.000000] -----------------------------------------------------
> > > > [    0.000000] ioremap() called early from pmac_setup_arch+0x118/0x290.
> > > Use early_ioremap() instead
> > > > [    0.000000] ioremap() called early from pmac_nvram_init+0x150/0x53c.
> > > Use early_ioremap() instead
> > > > [    0.000000] nvram: Checking bank 0...
> > > > [    0.000000] Invalid signature
> > > > [    0.000000] Invalid checksum
> > > > [    0.000000] nvram: gen0=0, gen1=0
> > > > [    0.000000] nvram: Active bank is: 0
> > > > [    0.000000] nvram: OF partition at 0xffffffff
> > > > [    0.000000] nvram: XP partition at 0xffffffff
> > > > [    0.000000] nvram: NR partition at 0xffffffff
> > > > [    0.000000] Zone ranges:
> > > > [    0.000000]   DMA      [mem 0x0000000000000000-0x000000001fffffff]
> > > > [    0.000000]   Normal   empty
> > > > [    0.000000]   HighMem  empty
> > > > [    0.000000] Movable zone start for each node
> > > > [    0.000000] Early memory node ranges
> > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001fffffff]
> > > > [    0.000000] Initmem setup node 0 [mem
> > > 0x0000000000000000-0x000000001fffffff]
> > > > [    0.000000] percpu: Embedded 22 pages/cpu s59884 r8192 d22036 u90112
> > > > [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages:
> > > 129920
> > > > [    0.000000] Kernel command line: console=ttyPZ0
> > > > [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144
> > > bytes, linear)
> > > > [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
> > > bytes, linear)
> > > > [    0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
> > > > [    0.000000] Kernel virtual memory layout:
> > > > [    0.000000]   * 0xf7bdf000..0xfffff000  : fixmap
> > > > [    0.000000]   * 0xf7400000..0xf7800000  : highmem PTEs
> > > > [    0.000000]   * 0xf7338000..0xf7400000  : early ioremap
> > > > [    0.000000]   * 0xe1000000..0xf7338000  : vmalloc & ioremap
> > > > [    0.000000] Memory: 500988K/524288K available (10912K kernel code,
> > > 1444K rwdata, 2512K rodata, 1420K init, 516K bss, 23300K reserved, 0K
> > > cma-reserved, 0K highmem)
> > > > [    0.000000] random: get_random_u32 called from
> > > __kmem_cache_create+0x38/0x57c with crng_init=0
> > > > [    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > > > [    0.000000] ftrace: allocating 29527 entries in 87 pages
> > > > [    0.000000] ftrace: allocated 87 pages with 5 groups
> > > > [    0.000000] rcu: Hierarchical RCU implementation.
> > > > [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=2048 to
> > > nr_cpu_ids=4.
> > > > [    0.000000]  Trampoline variant of Tasks RCU enabled.
> > > > [    0.000000]  Rude variant of Tasks RCU enabled.
> > > > [    0.000000]  Tracing variant of Tasks RCU enabled.
> > > > [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
> > > is 25 jiffies.
> > > > [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16,
> > > nr_cpu_ids=4
> > > > [    0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
> > > > [    0.000000] mpic: Setting up MPIC " MPIC 1   " version 1.2 at
> > > 80040000, max 4 CPUs
> > > > [    0.000000] mpic: ISU size: 64, shift: 6, mask: 3f
> > > > [    0.000000] mpic: Initializing for 64 sources
> > > > [    0.000000] GMT Delta read from XPRAM: 0 minutes, DST: on
> > > > [    0.001114] clocksource: timebase: mask: 0xffffffffffffffff
> > > max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
> > > > [    0.002661] clocksource: timebase mult[28000000] shift[24] registered
> > > > [    0.022081] Console: colour dummy device 80x25
> > > > [    0.059474] printk: console [ttyPZ0] enabled
> > > > [    0.059474] printk: console [ttyPZ0] enabled
> > > > [    0.060950] printk: bootconsole [udbg0] disabled
> > > > [    0.060950] printk: bootconsole [udbg0] disabled
> > > > [    0.063583] pid_max: default: 32768 minimum: 301
> > > > [    0.066030] LSM: Security Framework initializing
> > > > [    0.068483] Yama: becoming mindful.
> > > > [    0.075446] AppArmor: AppArmor initialized
> > > > [    0.076811] Mount-cache hash table entries: 1024 (order: 0, 4096
> > > bytes, linear)
> > > > [    0.077566] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> > > bytes, linear)
> > > > smp_core99_probe
> > > > [    0.140858] PowerMac SMP probe found 4 cpus
> > >
> > > You're still using too many CPUs. Try to get close to real hardware and
> > > only try 2 CPUs at first so we don't have to care about things that don't
> > > happen on real machine.
> >
> > yeah, but linux define all four :}
> >
> > core99_reset_cpu(struct device_node *node, long param, long value)
> >
> > const int dflt_reset_lines[] = { KL_GPIO_RESET_CPU0,
> > KL_GPIO_RESET_CPU1,
> > KL_GPIO_RESET_CPU2,
> > KL_GPIO_RESET_CPU3 };
> >
> > and those defined in keylargo.h as
> >
> > #define KEYLARGO_GPIO_EXTINT_0 0x58
> >
> > #define KL_GPIO_RESET_CPU0 (KEYLARGO_GPIO_EXTINT_0+0x03)
> > #define KL_GPIO_RESET_CPU1 (KEYLARGO_GPIO_EXTINT_0+0x04)
> > #define KL_GPIO_RESET_CPU2 (KEYLARGO_GPIO_EXTINT_0+0x0f)
> > #define KL_GPIO_RESET_CPU3 (KEYLARGO_GPIO_EXTINT_0+0x10)
>
> Still it may be simpler to deal with only 1 additional CPU first just to 
> reduce complexity. So CPU reset seems to be done by core99_reset_cpu() which 
> will:
>
> 1. Look for something in open firmware device tree - is that there with 
> OpenBIOS, is it needed? Could be found by comparing to device tree from real 
> machine but you'd need to find a PowerMac3,3 dual CPU dump as PowerMac3,1 
> only was single CPU. Otherwise it defaults to the above defines.
>
> 2. Poke mac-io to lower the reset line as far as I understand. Is this 
> emulated in QEMU and connected to reset the CPUs? The mac_newworld.c seems to 
> connect CPU reset to openpic not macio/keylargo or is that the same device? 
> Are these KEYLARGO_GPIO_EXTINT_0 registers emulated correctly?

So macio is in qemu/hw/misc/macio/macio.c and embeds an 
OPENPIC_MODEL_KEYLARGO openpic. It also has GPIOs but only if you use -M 
mac99.via=pmu so make sure you test with that as the CUDA one surely does 
not match a multi CPU Mac. CUDA was probably only used on some PowerBooks. 
Now I don't know where those GPIOs are handled and if they would go 
thorugh the openpic to reset the CPU which is where the reset interrupt 
seems to be connected in mac_newworld.c so probably macio should poke its 
openpic which would then raise the reset line of the CPU.

(And also find out the assert as I think the CPU objects need to be 
realized for correct operation.)

Regards,
BALATON Zoltan