On Sun, 19 May 2024, BALATON Zoltan wrote:
> On Sun, 19 May 2024, BALATON Zoltan wrote:
>> On Sun, 19 May 2024, Andrew Randrianasulu wrote:
>>> сб, 18 мая 2024 г., 23:33 BALATON Zoltan <balaton@eik.bme.hu>:
>>>
>>>> On Sat, 18 May 2024, Andrew Randrianasulu wrote:
>>>>> On Sat, May 18, 2024 at 11:14 PM BALATON Zoltan <balaton@eik.bme.hu>
>>>> 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)
>
> So the MACIO_OUT8 macro pokes macio->base and it's not listed here unlike in
> the log from real machine so not sure it's writing the right address. You can
> check witn info mtree in QEMU monitor where things appear but may need
> another kernel which logs thinks similar to the log you got from real
> machine. Does the finnix kernel work better with -append debuglevel=<some
> number here but I don't know what's a good number". Maybe can also enable
> openpic and macio traces to see if their regs are accessed. Something like
> QEMU option -trace enable="macio*" maybe?
The finnix kernel prints an address here which seems to match where mac-io
is mapped at. I believe the writes from smp_core99_kick_cpu() should end
up in QEMU's macio/gpio emulation in qemu/hw/misc/macio/gpio.c. You could
verify that with -trace eneable="macio*".
It prints something like
macio_nvram_read read addr=0x099e val=0x00
macio_nvram_read read addr=0x099f val=0x00
macio_nvram_read read addr=0x099f val=0x00
macio_nvram_read read addr=0x09a0 val=0x00
macio_nvram_read read addr=0x09a0 val=0x00
macio_nvram_read read addr=0x09a1 val=0x00
macio_nvram_read read addr=0x09a1 val=0x00
macio_nvram_read read addr=0x09a2 val=0x00
macio_nvram_read read addr=0x09a2 val=0x00
macio_nvram_read read addr=0x09a3 val=0x00
macio_nvram_read read addr=0x09a3 val=0x00
macio_nvram_read read addr=0x09a4 val=0x00
macio_nvram_read read addr=0x09a4 val=0x00
macio_nvram_read read addr=0x09a5 val=0x00[ 0.000000] nvram: OF partition at 0xffffffff
[ 0.000000] nvram: XP partition at 0xffffffff
[ 0.000000] nvram: NR partition at 0xffffffff
but I can't see it poking around smp init?
[ 0.144619] PowerMac SMP probe found 2 cpus
[ 0.147225] Processor timebase sync using GPIO 0x73
[ 0.147847] mpic: requesting IPIs...
[ 0.153859] CPU0: L2CR is 0
[ 0.169098] rcu: Hierarchical SRCU implementation.
[ 0.188753] smp: Bringing up secondary CPUs ...
smp_core99_kick_cpu
smp_core99_kick_cpu done
[ 5.230919] Processor 1 is stuck.
[ 5.238874] smp: Brought up 1 node, 1 CPU
probably more tracing need to be added to macio.c ?
Any ideas where to look for examples?
I also noticed that L2CR reg is 0 - shouldn't it represent some enabled L2 cache
on specifically PowerMacs ?
I think the GPIO lines to reset
the CPU should be implemented here but I don't know if this should be the
default 3,4,15,16 from KL_GPIO_RESET_CPU0-3 that is used without
soft-reset property or the 33,34 that is implied by the device tree dump
you've found. For Linux the defaults probably will do know then no need to
hack OpenBIOS for that. For Mac OS X we may need to match real machine
later. I also don't know if these gpios should poke the openpic where the
CPU reset lines seem to be connected or the reset lines should instead be
connected to these gpio lines.
I've also found this document which describes the hardware:
http://cdn.preterhuman.net/texts/computing/apple_hardware_devnotes/PowerMac%20G4%20(summer%2700).pdf
but it does not have much dettails, only high level overview.
One more thing that could be confusing. QEMU has qemu_*_gpio_* functions
that are described here:
https://www.qemu.org/docs/master/devel/qdev-api.html and are really
related to qemu_irqs that is QEMU's model of an interrupt or gpio line.
This is not the same as gpio lines of a chip (but a chip's gpio lines can
be modelled with QEMU gpios) so make sure you understand what is referred
to when you see gpio as it could be a QEMU gpio/qemu_irq or a chip gpio
that could be confusing at first.
twice yes
Regards,
BALATON Zoltan