mbox series

[00/15] ppc/ppc405: decade cleanup

Message ID 20211206103712.1866296-1-clg@kaod.org
Headers show
Series ppc/ppc405: decade cleanup | expand

Message

Cédric Le Goater Dec. 6, 2021, 10:36 a.m. UTC
Hello,

The goal of these changes is to refresh the QEMU ref405ep machine and
enable boot from a Linux kernel without relying on a U-Boot firmware.
The reason for doing so is that we are unable to find a "ppc405_rom.bin"
firmware image or a flash image for the 405EP machines.

Thomas fought is way through on a v2015.10 U-Boot and taihu defconfig
and provided a compatible image available here :

 https://gitlab.com/huth/u-boot/-/tree/taihu/

With this image, QEMU reaches the U-Boot prompt (with a simple
workaround in the SDRAM).

On the Linux side, the only available 405EP CPU board is the one for
the ESTeem 195E (PPC405EP) SBC (hotfoot). It was added in 2009. The
board information structure in Linux, in U-Boot and in QEMU are not in
sync and the hotfoot board also adds its own flavor because the FW was
an ancient U-Boot without dual ethernet support [1].

For this kernel to be loaded by the U-Boot image provided by Thomas,
we either need to modify U-Boot or Linux. The same question arise for
QEMU, see the last patch of this series which is controversial. Please
advise !

Thanks,

C.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074487.html

Cédric Le Goater (14):
  ppc/ppc405: Change kernel load address
  ppc: Add trace-events for DCR accesses
  ppc/ppc405: Convert printfs to trace-events
  ppc/ppc405: Drop flag parameter in ppc405_set_bootinfo()
  ppc/ppc405: Change ppc405ep_init() return value
  ppc/ppc405: Add some address space definitions
  ppc/ppc405: Remove flash support
  ppc/ppc405: Rework FW load
  ppc/ppc405: Introduce ppc405_set_default_bootinfo()
  ppc/ppc405: Fix boot from kernel
  ppc/ppc405: Change default PLL values at reset
  ppc/ppc405: Fix bi_pci_enetaddr2 field in U-Boot board information
  ppc/ppc405: Add update of bi_procfreq field
  ppc/ppc405: Update U-Boot board information for hotfoot

Thomas Huth (1):
  ppc: Mark the 'taihu' machine as deprecated

 docs/about/deprecated.rst |   9 ++
 hw/ppc/ppc405.h           |  14 +-
 hw/ppc/ppc.c              |   2 +
 hw/ppc/ppc405_boards.c    | 245 ++++++++++++++++++----------------
 hw/ppc/ppc405_uc.c        | 270 +++++++++++++++++++++-----------------
 hw/ppc/trace-events       |  23 ++++
 6 files changed, 327 insertions(+), 236 deletions(-)

Comments

Cédric Le Goater Dec. 15, 2021, 4:49 p.m. UTC | #1
On 12/6/21 11:36, Cédric Le Goater wrote:
> Hello,
> 
> The goal of these changes is to refresh the QEMU ref405ep machine and
> enable boot from a Linux kernel without relying on a U-Boot firmware.
> The reason for doing so is that we are unable to find a "ppc405_rom.bin"
> firmware image or a flash image for the 405EP machines.
> 
> Thomas fought is way through on a v2015.10 U-Boot and taihu defconfig
> and provided a compatible image available here :
> 
>   https://gitlab.com/huth/u-boot/-/tree/taihu/
> 
> With this image, QEMU reaches the U-Boot prompt (with a simple
> workaround in the SDRAM).
> 
> On the Linux side, the only available 405EP CPU board is the one for
> the ESTeem 195E (PPC405EP) SBC (hotfoot). It was added in 2009. The
> board information structure in Linux, in U-Boot and in QEMU are not in
> sync and the hotfoot board also adds its own flavor because the FW was
> an ancient U-Boot without dual ethernet support [1].
> 
> For this kernel to be loaded by the U-Boot image provided by Thomas,
> we either need to modify U-Boot or Linux. The same question arise for
> QEMU, see the last patch of this series which is controversial. Please
> advise !

Applied patch 1-14 to ppc-next.

I kept the hotfoot hack for later. We need to fix user space first.

Thanks,

C.
Christophe Leroy Dec. 17, 2021, 4:36 p.m. UTC | #2
Le 15/12/2021 à 17:49, Cédric Le Goater a écrit :
> On 12/6/21 11:36, Cédric Le Goater wrote:
>> Hello,
>>
>> The goal of these changes is to refresh the QEMU ref405ep machine and
>> enable boot from a Linux kernel without relying on a U-Boot firmware.
>> The reason for doing so is that we are unable to find a "ppc405_rom.bin"
>> firmware image or a flash image for the 405EP machines.
>>
>> Thomas fought is way through on a v2015.10 U-Boot and taihu defconfig
>> and provided a compatible image available here :
>>
>>   https://gitlab.com/huth/u-boot/-/tree/taihu/
>>
>> With this image, QEMU reaches the U-Boot prompt (with a simple
>> workaround in the SDRAM).
>>
>> On the Linux side, the only available 405EP CPU board is the one for
>> the ESTeem 195E (PPC405EP) SBC (hotfoot). It was added in 2009. The
>> board information structure in Linux, in U-Boot and in QEMU are not in
>> sync and the hotfoot board also adds its own flavor because the FW was
>> an ancient U-Boot without dual ethernet support [1].
>>
>> For this kernel to be loaded by the U-Boot image provided by Thomas,
>> we either need to modify U-Boot or Linux. The same question arise for
>> QEMU, see the last patch of this series which is controversial. Please
>> advise !
> 
> Applied patch 1-14 to ppc-next.
> 
> I kept the hotfoot hack for later. We need to fix user space first.
> 


Don't know if this is the reason of our problems but I think there is 
something to investigate around timer interrupts:


/ # cat /proc/interrupts
            CPU0
  16:         68       UIC   1 Level     serial
LOC:          0   Local timer interrupts for timer event device
LOC:          0   Local timer interrupts for others
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
MCE:          0   Machine check exceptions

Any idea what the problem can be ? How does QEMU generates timer 
interrupts ?

Christophe
Cédric Le Goater Dec. 17, 2021, 5:18 p.m. UTC | #3
On 12/17/21 17:36, Christophe Leroy wrote:
> 
> 
> Le 15/12/2021 à 17:49, Cédric Le Goater a écrit :
>> On 12/6/21 11:36, Cédric Le Goater wrote:
>>> Hello,
>>>
>>> The goal of these changes is to refresh the QEMU ref405ep machine and
>>> enable boot from a Linux kernel without relying on a U-Boot firmware.
>>> The reason for doing so is that we are unable to find a "ppc405_rom.bin"
>>> firmware image or a flash image for the 405EP machines.
>>>
>>> Thomas fought is way through on a v2015.10 U-Boot and taihu defconfig
>>> and provided a compatible image available here :
>>>
>>>    https://gitlab.com/huth/u-boot/-/tree/taihu/
>>>
>>> With this image, QEMU reaches the U-Boot prompt (with a simple
>>> workaround in the SDRAM).
>>>
>>> On the Linux side, the only available 405EP CPU board is the one for
>>> the ESTeem 195E (PPC405EP) SBC (hotfoot). It was added in 2009. The
>>> board information structure in Linux, in U-Boot and in QEMU are not in
>>> sync and the hotfoot board also adds its own flavor because the FW was
>>> an ancient U-Boot without dual ethernet support [1].
>>>
>>> For this kernel to be loaded by the U-Boot image provided by Thomas,
>>> we either need to modify U-Boot or Linux. The same question arise for
>>> QEMU, see the last patch of this series which is controversial. Please
>>> advise !
>>
>> Applied patch 1-14 to ppc-next.
>>
>> I kept the hotfoot hack for later. We need to fix user space first.
>>
> 
> 
> Don't know if this is the reason of our problems but I think there is
> something to investigate around timer interrupts:
> 
> 
> / # cat /proc/interrupts
>              CPU0
>    16:         68       UIC   1 Level     serial
> LOC:          0   Local timer interrupts for timer event device
> LOC:          0   Local timer interrupts for others
> SPU:          0   Spurious interrupts
> PMI:          0   Performance monitoring interrupts
> MCE:          0   Machine check exceptions
> 
> Any idea what the problem can be ? How does QEMU generates timer
> interrupts ?

Indeed.

With some extra QEMU traces (-trace ppc4* -trace ppc_decr*), we can see :

ppc40x_timers_init frequency 33333333
ppc405_gpio_init offet 0xef600700
ppc4xx_gpt_init offet 0xef600000
ppc405ep_clocks_compute FBMUL 0xa 10
ppc405ep_clocks_compute FWDA 0x5 3
ppc405ep_clocks_compute CCDV 0x0 1
ppc405ep_clocks_compute CBDV 0x2 3
ppc405ep_clocks_compute OPDV 0x1 2
ppc405ep_clocks_compute EPDV 0x0 2
ppc405ep_clocks_compute MPDV 0x0 1
ppc405ep_clocks_compute PPDV 0x2 3
ppc405ep_clocks_compute U0DIV 0x46 70
ppc405ep_clocks_compute U1DIV 0x46 70
ppc405ep_clocks_setup Setup PPC405EP clocks - sysclk 33333333 VCO 999999990 PLL out 333333330 Hz
CPU 333333330 PLB 111111110 OPB 55555555 EBC 55555555 MAL 111111110 PCI 37037036 UART0 4761904 UART1 4761904

ppc40x_set_tb_clk new frequency 333333330

   ...

   clocksource: timebase mult[7800000] shift[24] registered
ppc40x_store_pit val 0x7fffffff
ppc4xx_pit_stop
ppc40x_store_pit val 0x82355
ppc4xx_pit_stop
   pid_max: default: 32768 minimum: 301


decrementer timer seems stop and so no decrementer exception. I suppose
this routine is in cause :


static void start_stop_pit (CPUPPCState *env, ppc_tb_t *tb_env, int is_excp)
{
     ppc40x_timer_t *ppc40x_timer;
     uint64_t now, next;

     ppc40x_timer = tb_env->opaque;
     if (ppc40x_timer->pit_reload <= 1 ||
         !((env->spr[SPR_40x_TCR] >> 26) & 0x1) ||
         (is_excp && !((env->spr[SPR_40x_TCR] >> 22) & 0x1))) {
         /* Stop PIT */
         trace_ppc4xx_pit_stop();
         timer_del(tb_env->decr_timer);
     } else {
         trace_ppc4xx_pit_start(ppc40x_timer->pit_reload);
         now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
         next = now + muldiv64(ppc40x_timer->pit_reload,
                               NANOSECONDS_PER_SECOND, tb_env->decr_freq);
         if (is_excp)
             next += tb_env->decr_next - now;
         if (next == now)
             next++;
         timer_mod(tb_env->decr_timer, next);
         tb_env->decr_next = next;
     }
}


C.
Cédric Le Goater Dec. 18, 2021, 9:33 a.m. UTC | #4
>> Don't know if this is the reason of our problems but I think there is
>> something to investigate around timer interrupts:
>>
>>
>> / # cat /proc/interrupts
>>              CPU0
>>    16:         68       UIC   1 Level     serial
>> LOC:          0   Local timer interrupts for timer event device
>> LOC:          0   Local timer interrupts for others
>> SPU:          0   Spurious interrupts
>> PMI:          0   Performance monitoring interrupts
>> MCE:          0   Machine check exceptions
>>
>> Any idea what the problem can be ? How does QEMU generates timer
>> interrupts ?

The ppc405 timers were trashed by ddd1055b07fd ("PPC: booke timers").
I guess at the time, in 2011, there were no possible ways to test
regressions :/

This is addictive. I will look into it, I hope it's only a question
of adding back the TSR and TCR store helpers.

Thanks,

C.
Cédric Le Goater Dec. 20, 2021, 8:33 a.m. UTC | #5
> 
> Don't know if this is the reason of our problems but I think there is
> something to investigate around timer interrupts:
> 
> 
> / # cat /proc/interrupts
>              CPU0
>    16:         68       UIC   1 Level     serial
> LOC:          0   Local timer interrupts for timer event device
> LOC:          0   Local timer interrupts for others
> SPU:          0   Spurious interrupts
> PMI:          0   Performance monitoring interrupts
> MCE:          0   Machine check exceptions
> 
> Any idea what the problem can be ? How does QEMU generates timer
> interrupts ?

I did some archeology and fixed the 405 timer (PIT). Please see commits in :

   https://github.com/legoater/qemu/commits/ppc405

but we are still getting segfaults. At some point /init tries to load from
fffffe04 which is obviously wrong.

Add -d int,mmu to have more info from QEMU internals.

I have gathered some info on this page :

   https://github.com/legoater/qemu/wiki/ref405ep

Thanks,

C.
Philippe Mathieu-Daudé Dec. 20, 2021, 6:07 p.m. UTC | #6
On 12/20/21 09:33, Cédric Le Goater wrote:
>>
>> Don't know if this is the reason of our problems but I think there is
>> something to investigate around timer interrupts:
>>
>>
>> / # cat /proc/interrupts
>>              CPU0
>>    16:         68       UIC   1 Level     serial
>> LOC:          0   Local timer interrupts for timer event device
>> LOC:          0   Local timer interrupts for others
>> SPU:          0   Spurious interrupts
>> PMI:          0   Performance monitoring interrupts
>> MCE:          0   Machine check exceptions
>>
>> Any idea what the problem can be ? How does QEMU generates timer
>> interrupts ?
> 
> I did some archeology and fixed the 405 timer (PIT). Please see commits
> in :
> 
>   https://github.com/legoater/qemu/commits/ppc405
> 
> but we are still getting segfaults. At some point /init tries to load from
> fffffe04 which is obviously wrong.

Fetching an u32 value from a missing ROM?

> 
> Add -d int,mmu to have more info from QEMU internals.
> 
> I have gathered some info on this page :
> 
>   https://github.com/legoater/qemu/wiki/ref405ep
> 
> Thanks,
> 
> C.
>
Cédric Le Goater Dec. 20, 2021, 6:18 p.m. UTC | #7
On 12/20/21 19:07, Philippe Mathieu-Daudé wrote:
> On 12/20/21 09:33, Cédric Le Goater wrote:
>>>
>>> Don't know if this is the reason of our problems but I think there is
>>> something to investigate around timer interrupts:
>>>
>>>
>>> / # cat /proc/interrupts
>>>               CPU0
>>>     16:         68       UIC   1 Level     serial
>>> LOC:          0   Local timer interrupts for timer event device
>>> LOC:          0   Local timer interrupts for others
>>> SPU:          0   Spurious interrupts
>>> PMI:          0   Performance monitoring interrupts
>>> MCE:          0   Machine check exceptions
>>>
>>> Any idea what the problem can be ? How does QEMU generates timer
>>> interrupts ?
>>
>> I did some archeology and fixed the 405 timer (PIT). Please see commits
>> in :
>>
>>    https://github.com/legoater/qemu/commits/ppc405
>>
>> but we are still getting segfaults. At some point /init tries to load from
>> fffffe04 which is obviously wrong.
> 
> Fetching an u32 value from a missing ROM?


hmm, I don't think so. Here are some logs.

Thanks,

C.

....
mmu40x_get_physical_address: access granted b7bd6000 => 00000000005ba000 13 0

0xb7bd6744:  80dffff8  lwz      r6, -8(r31)
0xb7bd6748:  7ce63850  subf     r7, r6, r7
0xb7bd674c:  80a70008  lwz      r5, 8(r7)
0xb7bd6750:  7c843214  add      r4, r4, r6
0xb7bd6754:  8065000c  lwz      r3, 0xc(r5)
0xb7bd6758:  80c7000c  lwz      r6, 0xc(r7)
0xb7bd675c:  7c071800  cmpw     r7, r3
0xb7bd6760:  41a20008  beq      0xb7bd6768

ppcemb_tlb_check: TLB 14 address fffffe04 PID 3 <=> c0000000 ff000000 0 f
ppcemb_tlb_check: TLB 15 address fffffe04 PID 3 <=> c7000000 ff000000 0 f
ppcemb_tlb_check: TLB 16 address fffffe04 PID 3 <=> c1000000 ff000000 0 f
ppcemb_tlb_check: TLB 17 address fffffe04 PID 3 <=> b7bdc000 fffff000 2 d
ppcemb_tlb_check: TLB 19 address fffffe04 PID 3 <=> b7c30000 fffff000 2 b
ppcemb_tlb_check: TLB 20 address fffffe04 PID 3 <=> bfe4f000 fffff000 2 9
ppcemb_tlb_check: TLB 22 address fffffe04 PID 3 <=> b7c32000 fffff000 2 b
ppcemb_tlb_check: TLB 23 address fffffe04 PID 3 <=> b7bff000 fffff000 2 d
ppcemb_tlb_check: TLB 24 address fffffe04 PID 3 <=> 00913000 fffff000 2 d
ppcemb_tlb_check: TLB 25 address fffffe04 PID 3 <=> b7c64000 fffff000 3 b
ppcemb_tlb_check: TLB 26 address fffffe04 PID 3 <=> b7c2f000 fffff000 3 9
ppcemb_tlb_check: TLB 27 address fffffe04 PID 3 <=> b7bf5000 fffff000 3 d
ppcemb_tlb_check: TLB 28 address fffffe04 PID 3 <=> bfe4f000 fffff000 3 b
ppcemb_tlb_check: TLB 30 address fffffe04 PID 3 <=> 009bc000 fffff000 2 9
ppcemb_tlb_check: TLB 32 address fffffe04 PID 3 <=> 009c1000 fffff000 2 b
ppcemb_tlb_check: TLB 33 address fffffe04 PID 3 <=> 009c0000 fffff000 2 9
ppcemb_tlb_check: TLB 34 address fffffe04 PID 3 <=> 00970000 fffff000 2 d
ppcemb_tlb_check: TLB 35 address fffffe04 PID 3 <=> b7c44000 fffff000 3 b
ppcemb_tlb_check: TLB 36 address fffffe04 PID 3 <=> 00911000 fffff000 3 d
ppcemb_tlb_check: TLB 37 address fffffe04 PID 3 <=> 00912000 fffff000 3 d
ppcemb_tlb_check: TLB 38 address fffffe04 PID 3 <=> 0090e000 fffff000 3 d
ppcemb_tlb_check: TLB 39 address fffffe04 PID 3 <=> 00919000 fffff000 2 d
ppcemb_tlb_check: TLB 40 address fffffe04 PID 3 <=> 00971000 fffff000 2 d
ppcemb_tlb_check: TLB 41 address fffffe04 PID 3 <=> 009bf000 fffff000 2 9
ppcemb_tlb_check: TLB 42 address fffffe04 PID 3 <=> b7ba8000 fffff000 2 d
ppcemb_tlb_check: TLB 43 address fffffe04 PID 3 <=> 009c0000 fffff000 3 b
ppcemb_tlb_check: TLB 44 address fffffe04 PID 3 <=> 0090f000 fffff000 3 d
ppcemb_tlb_check: TLB 45 address fffffe04 PID 3 <=> 00910000 fffff000 3 d
ppcemb_tlb_check: TLB 46 address fffffe04 PID 3 <=> 008d9000 fffff000 3 d
ppcemb_tlb_check: TLB 47 address fffffe04 PID 3 <=> 00976000 fffff000 3 d
ppcemb_tlb_check: TLB 48 address fffffe04 PID 3 <=> b7bf4000 fffff000 3 d
ppcemb_tlb_check: TLB 49 address fffffe04 PID 3 <=> b7bd5000 fffff000 3 d
ppcemb_tlb_check: TLB 50 address fffffe04 PID 3 <=> b7c00000 fffff000 3 d
ppcemb_tlb_check: TLB 51 address fffffe04 PID 3 <=> b7ba7000 fffff000 3 d
ppcemb_tlb_check: TLB 52 address fffffe04 PID 3 <=> 0090d000 fffff000 3 d
ppcemb_tlb_check: TLB 53 address fffffe04 PID 3 <=> 00918000 fffff000 3 d
ppcemb_tlb_check: TLB 54 address fffffe04 PID 3 <=> 0097a000 fffff000 3 d
ppcemb_tlb_check: TLB 55 address fffffe04 PID 3 <=> b7bd6000 fffff000 3 d
ppcemb_tlb_check: TLB 56 address fffffe04 PID 3 <=> b7bf8000 fffff000 3 d
ppcemb_tlb_check: TLB 58 address fffffe04 PID 3 <=> b7c46000 fffff000 3 b
mmu40x_get_physical_address: access refused fffffe04 => ffffffffffffffff 4096 -1
NIP b7bd6744   LR b7bd66cc CTR b7bf471c XER 00000000 CPU#0
MSR 0000c030 HID0 00000300  HF 00004012 iidx 0 didx 0
TB 00000000 984786301 DECR 4294956920
GPR00 00000000b7bd66cc 00000000bfe4f9a0 00000000b7c6b470 0000000000000000
GPR04 00000000000000c8 00000000b7c30124 00000000009c140c 00000000fffffdfc
GPR08 000000002d740000 00000000009c12d0 0000000000000049 00000000bfe4f9a0
GPR12 0000000020004002 00000000009bfa94 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24 0000000000000004 00000000bfe4f9f8 00000000009c0054 0000000000000000
GPR28 00000000bfe4f9a8 00000000b7c4642c 00000000b7c2fd58 00000000009c1210
CR 20004002  [ E  -  -  -  G  -  -  E  ]             RES ffffffff
  SRR0 b7bd672c  SRR1 0000c030    PVR 51210950 VRSAVE 00000000
SPRG0 00000049 SPRG1 bfe4f9a0  SPRG2 bfe4f9a0  SPRG3 00c3ee70
SPRG4 20004002 SPRG5 00000049  SPRG6 00000049  SPRG7 bfe4f9a0
   TCR 04000000   TSR c8000000    ESR 00800000   DEAR b7c4642c
  EVPR 00000000  SRR2 00000000   SRR3 00000000  PID 00000003
Raise exception at b7bd674c => DTLB (13) error=00
....