| Message ID | 20211206103712.1866296-1-clg@kaod.org |
|---|---|
| Headers | show |
| Series | ppc/ppc405: decade cleanup | expand |
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.
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
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.
>> 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.
> > 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.
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. >
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 ....