> > > 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" <dant...@gmail.com> > A: "Paolo Bonzini" <pbonz...@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 <pbonz...@redhat.com>: > > > >> 2013/3/6 Paolo Bonzini <pbonz...@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 <dant...@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