From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDBrn-0000KH-C1 for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:46:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDBrl-0000Ac-U7 for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:46:35 -0500 Received: from mx3-phx2.redhat.com ([209.132.183.24]:60533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDBrl-0000AY-Ll for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:46:33 -0500 Date: Wed, 6 Mar 2013 05:46:25 -0500 (EST) From: Paolo Bonzini Message-ID: <1275401492.3147913.1362566785770.JavaMail.root@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 07/24] hw/arm: add Faraday FTWDT010 watchdog timer support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kuo-Jung Su Cc: Peter Maydell , Igor Mitsyanko , qemu-devel@nongnu.org, Blue Swirl , Paul Brook , Andreas , fred konrad > > > 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 >=20 > While booting from ROM, the faraday soc usually remap the ROM / RAM > before jumping into linux. >=20 > In other words, the system mapping is: >=20 > 1. Power-On: >=20 > ROM: 0x00000000 > RAM: N/A > SRAM: 0xA0000000 >=20 > 2. AHB Remap (u-boot/linux) >=20 > ROM: 0x20000000 > RAM: 0x00000000 >=20 > So I have to register my own reset handler to >=20 > 1. Undo the ROM/RAM remap (i.e. device_reset(s->ahbc)) > 2. Reset CPU ----- Messaggio originale ----- > Da: "Kuo-Jung Su" > A: "Paolo Bonzini" > Inviato: Mercoled=C3=AC, 6 marzo 2013 11:00:49 > Oggetto: Re: [PATCH v6 07/24] hw/arm: add Faraday FTWDT010 watchdog timer= support >=20 > 2013/3/6 Paolo Bonzini : > > > >> 2013/3/6 Paolo Bonzini : > >> > 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 > >> >> --- > >> >> 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 +=3D ftintc020.o > >> >> obj-y +=3D ftahbc020.o > >> >> obj-y +=3D ftddrii030.o > >> >> obj-y +=3D ftpwmtmr010.o > >> >> +obj-y +=3D 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 =3D 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 >=20 > While booting from ROM, the faraday soc usually remap the ROM / RAM > before jumping into linux. >=20 > In other words, the system mapping is: >=20 > 1. Power-On: >=20 > ROM: 0x00000000 > RAM: N/A > SRAM: 0xA0000000 >=20 > 2. AHB Remap (u-boot/linux) >=20 > ROM: 0x20000000 > RAM: 0x00000000 >=20 > So I have to register my own reset handler to >=20 > 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 =3D s->ahb_slave[4] & 0xfff00000; + s->ahb_slave[6] =3D s->ram_base | (s->ahb_slave[6] & 0x000f0000); + /* 2. Remap ROM to base of ROM + size of RAM */ + s->rom_base =3D s->ram_base + + ((1 << extract32(s->ahb_slave[6], 16, 4)) << 20); + s->ahb_slave[4] =3D s->rom_base | (s->ahb_slave[4] & 0x000f0000); when you do a system_reset and the board was started in kernel mode. Paolo