Re: [PATCH 00/15] ppc/ppc405: decade cleanup

[Cédric Le Goater]

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.