Re: [Qemu-devel] [PATCH v6 07/24] hw/arm: add Faraday FTWDT010 watchdog timer support

[Paolo Bonzini <pbonzini@redhat.com>]

> > > It doesn't work while running under ROM mode. ( no -kernel )
> > > Because Faraday SoC Platform usually designed to boot from ROM and
> > > followed by an AHB remapping process (i.e. remap ROM/RAM address).
> >
> > What doesn't work exactly?  Why aren't these called?  Or are
> > you forcing a particular reset order?
> >
> > Paolo
> 
> While booting from ROM, the faraday soc usually remap the ROM / RAM
> before jumping into linux.
> 
> In other words,  the system mapping is:
> 
> 1. Power-On:
> 
>     ROM: 0x00000000
>     RAM: N/A
>     SRAM: 0xA0000000
> 
> 2. AHB Remap (u-boot/linux)
> 
>     ROM: 0x20000000
>     RAM: 0x00000000
> 
> So I have to register my own reset handler to
> 
> 1. Undo the ROM/RAM remap (i.e. device_reset(s->ahbc))
> 2. Reset CPU

----- Messaggio originale -----
> Da: "Kuo-Jung Su" <dantesu@gmail.com>
> A: "Paolo Bonzini" <pbonzini@redhat.com>
> Inviato: Mercoledì, 6 marzo 2013 11:00:49
> Oggetto: Re: [PATCH v6 07/24] hw/arm: add Faraday FTWDT010 watchdog timer support
> 
> 2013/3/6 Paolo Bonzini <pbonzini@redhat.com>:
> >
> >> 2013/3/6 Paolo Bonzini <pbonzini@redhat.com>:
> >> > Il 06/03/2013 08:27, Kuo-Jung Su ha scritto:
> >> >> The FTWDT010 is used to prevent system from infinite loop
> >> >> while software gets trapped in the deadlock.
> >> >>
> >> >> Under the normal operation, users should restart FTWDT010
> >> >> at the regular intervals before counter counts down to 0.
> >> >>
> >> >> If the counter does reach 0, FTWDT010 will try to reset
> >> >> the system by generating one or a combination of signals,
> >> >> system reset, system interrupt, and external interrupt.
> >> >>
> >> >> Signed-off-by: Kuo-Jung Su <dantesu@gmail.com>
> >> >> ---
> >> >>  hw/arm/Makefile.objs      |    1 +
> >> >>  hw/arm/faraday_a369_soc.c |   23 +++++
> >> >>  hw/arm/ftwdt010.c         |  212
> >> >>  +++++++++++++++++++++++++++++++++++++++++++++
> >> >>  hw/arm/ftwdt010.h         |   35 ++++++++
> >> >>  4 files changed, 271 insertions(+)
> >> >>  create mode 100644 hw/arm/ftwdt010.c
> >> >>  create mode 100644 hw/arm/ftwdt010.h
> >> >>
> >> >> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> >> >> index 2190edd..bc8e2de 100644
> >> >> --- a/hw/arm/Makefile.objs
> >> >> +++ b/hw/arm/Makefile.objs
> >> >> @@ -41,3 +41,4 @@ obj-y += ftintc020.o
> >> >>  obj-y += ftahbc020.o
> >> >>  obj-y += ftddrii030.o
> >> >>  obj-y += ftpwmtmr010.o
> >> >> +obj-y += ftwdt010.o
> >> >> diff --git a/hw/arm/faraday_a369_soc.c
> >> >> b/hw/arm/faraday_a369_soc.c
> >> >> index 66d9891..1bf64d4 100644
> >> >> --- a/hw/arm/faraday_a369_soc.c
> >> >> +++ b/hw/arm/faraday_a369_soc.c
> >> >> @@ -68,6 +68,25 @@ static void a369soc_reset(DeviceState *ds)
> >> >>  }
> >> >>
> >> >>  static void
> >> >> +a369soc_system_reset(void *opaque)
> >> >> +{
> >> >> +    FaradaySoCState *s = FARADAY_SOC(opaque);
> >> >> +
> >> >> +    if (s->scu) {
> >> >> +        device_reset(s->scu);
> >> >> +    }
> >> >> +    if (s->ddrc) {
> >> >> +        device_reset(s->ddrc);
> >> >> +    }
> >> >> +    if (s->ahbc) {
> >> >> +        device_reset(s->ahbc);
> >> >> +    }
> >> >> +    if (s->cpu) {
> >> >> +        cpu_reset(CPU(s->cpu));
> >> >> +    }
> >> >> +}
> >> >
> >> > Why is this needed?  Aren't they called already by
> >> >
> >> >     qemu_register_reset(qbus_reset_all_fn,
> >> >     sysbus_get_default());
> >> >
> >> > ?
> >> >
> >>
> >> It doesn't work while running under ROM mode. ( no -kernel )
> >> Because Faraday SoC Platform usually designed to boot from ROM and
> >> followed by an AHB remapping process (i.e. remap ROM/RAM address).
> >
> > What doesn't work exactly?  Why aren't these called?  Or are
> > you forcing a particular reset order?
> >
> > Paolo
> 
> While booting from ROM, the faraday soc usually remap the ROM / RAM
> before jumping into linux.
> 
> In other words,  the system mapping is:
> 
> 1. Power-On:
> 
>     ROM: 0x00000000
>     RAM: N/A
>     SRAM: 0xA0000000
> 
> 2. AHB Remap (u-boot/linux)
> 
>     ROM: 0x20000000
>     RAM: 0x00000000
> 
> So I have to register my own reset handler to
> 
> 1. Undo the ROM/RAM remap (i.e. device_reset(s->ahbc))
> 2. Reset CPU

I understand that.  What I'm missing is, why these reset handlers aren't
called anyway when QEMU does qemu_devices_reset(), for example from
qemu_system_reset().

Also, I do not understand who performs this again:

+        /* Remap AHB slave 4 (ROM) & slave 6 (RAM) */
+        /* 1. Remap RAM to base of ROM */
+        s->ram_base = s->ahb_slave[4] & 0xfff00000;
+        s->ahb_slave[6] = s->ram_base | (s->ahb_slave[6] & 0x000f0000);
+        /* 2. Remap ROM to base of ROM + size of RAM */
+        s->rom_base = s->ram_base
+                    + ((1 << extract32(s->ahb_slave[6], 16, 4)) << 20);
+        s->ahb_slave[4] = s->rom_base | (s->ahb_slave[4] & 0x000f0000);

when you do a system_reset and the board was started in kernel mode.

Paolo