| Message ID | 1391419091-3020-1-git-send-email-sebastian.huber@embedded-brains.de |
|---|---|
| State | New |
| Headers | show |
On 02/03/2014 10:18 AM, Sebastian Huber wrote: > A lot of real world LEON3 systems are shipped with the GRMON boot > loader. This boot loader initializes the stack pointer with the end of > RAM address. The application can use this to detect the RAM size of a > particular board variant. > Looks good, thank you Sebastian. Reviewed-by: Fabien Chouteau <chouteau@adacore.com> > Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de> > --- > hw/sparc/leon3.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c > index c583c3d..c16e9e4 100644 > --- a/hw/sparc/leon3.c > +++ b/hw/sparc/leon3.c > @@ -45,6 +45,7 @@ > typedef struct ResetData { > SPARCCPU *cpu; > uint32_t entry; /* save kernel entry in case of reset */ > + target_ulong sp; /* initial stack pointer */ > } ResetData; > > static void main_cpu_reset(void *opaque) > @@ -58,6 +59,7 @@ static void main_cpu_reset(void *opaque) > cpu->halted = 0; > env->pc = s->entry; > env->npc = s->entry + 4; > + env->regbase[6] = s->sp; > } > > void leon3_irq_ack(void *irq_manager, int intno) > @@ -133,6 +135,7 @@ static void leon3_generic_hw_init(QEMUMachineInitArgs *args) > /* Reset data */ > reset_info = g_malloc0(sizeof(ResetData)); > reset_info->cpu = cpu; > + reset_info->sp = 0x40000000 + ram_size; > qemu_register_reset(main_cpu_reset, reset_info); > > /* Allocate IRQ manager */ >
On 02/05/2014 10:02 AM, Fabien Chouteau wrote: > On 02/03/2014 10:18 AM, Sebastian Huber wrote: >> A lot of real world LEON3 systems are shipped with the GRMON boot >> loader. This boot loader initializes the stack pointer with the end of >> RAM address. The application can use this to detect the RAM size of a >> particular board variant. >> > > Looks good, thank you Sebastian. > > Reviewed-by: Fabien Chouteau <chouteau@adacore.com> > Sorry Blue you should be in copy. Can you apply this patch please? Thanks,
03.02.2014 13:18, Sebastian Huber wrote: > A lot of real world LEON3 systems are shipped with the GRMON boot > loader. This boot loader initializes the stack pointer with the end of > RAM address. The application can use this to detect the RAM size of a > particular board variant. I don't really know much about sparc or leon3 stuff. But having a reviewed-by from Fabien I can apply it to trivial-patches. I'm not really sure why it can't go to sparc tree instead. Thanks, /mjt
On 2014-02-06 09:40, Michael Tokarev wrote: > 03.02.2014 13:18, Sebastian Huber wrote: >> A lot of real world LEON3 systems are shipped with the GRMON boot >> loader. This boot loader initializes the stack pointer with the end of >> RAM address. The application can use this to detect the RAM size of a >> particular board variant. > > I don't really know much about sparc or leon3 stuff. But having a > reviewed-by from Fabien I can apply it to trivial-patches. I'm not > really sure why it can't go to sparc tree instead. I sent this patch to the trivial patches list, since the last tiny patch for the LEON3 was ignored by the SPARC maintainer for several weeks. Even after review by Fabien Chouteau and Richard Henderson. http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg03488.html http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01783.html
On 6 February 2014 08:40, Michael Tokarev <mjt@tls.msk.ru> wrote: > 03.02.2014 13:18, Sebastian Huber wrote: >> A lot of real world LEON3 systems are shipped with the GRMON boot >> loader. This boot loader initializes the stack pointer with the end of >> RAM address. The application can use this to detect the RAM size of a >> particular board variant. > > I don't really know much about sparc or leon3 stuff. But having a > reviewed-by from Fabien I can apply it to trivial-patches. I'm not > really sure why it can't go to sparc tree instead. As far as I'm aware there is currently no sparc tree; Blue is the listed maintainer and typically just applied patches directly. In the absence of Blue, if somebody else who cares about sparc wishes to collect up reviewed sparc patches and submit them as a pull request so they don't just get ignored, I'm willing to apply that pull. thanks -- PMM
On 2014-02-06 09:57, Peter Maydell wrote: > On 6 February 2014 08:40, Michael Tokarev<mjt@tls.msk.ru> wrote: >> >03.02.2014 13:18, Sebastian Huber wrote: >>> >>A lot of real world LEON3 systems are shipped with the GRMON boot >>> >>loader. This boot loader initializes the stack pointer with the end of >>> >>RAM address. The application can use this to detect the RAM size of a >>> >>particular board variant. >> > >> >I don't really know much about sparc or leon3 stuff. But having a >> >reviewed-by from Fabien I can apply it to trivial-patches. I'm not >> >really sure why it can't go to sparc tree instead. > As far as I'm aware there is currently no sparc tree; Blue is the > listed maintainer and typically just applied patches directly. > In the absence of Blue, if somebody else who cares about sparc > wishes to collect up reviewed sparc patches and submit them as > a pull request so they don't just get ignored, I'm willing to apply > that pull. Ok, how do we want proceed here? I have an additional patch in the queue that adds AMBA plug and play support to the LEON3 support of QEMU so that you can run unmodified binaries for RTEMS, eCos and Linux.
On 12 February 2014 13:54, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote: > On 2014-02-06 09:57, Peter Maydell wrote: >> On 6 February 2014 08:40, Michael Tokarev<mjt@tls.msk.ru> wrote: >>> >I don't really know much about sparc or leon3 stuff. But having a >>> >reviewed-by from Fabien I can apply it to trivial-patches. I'm not >>> >really sure why it can't go to sparc tree instead. >> >> As far as I'm aware there is currently no sparc tree; Blue is the >> listed maintainer and typically just applied patches directly. >> In the absence of Blue, if somebody else who cares about sparc >> wishes to collect up reviewed sparc patches and submit them as >> a pull request so they don't just get ignored, I'm willing to apply >> that pull. > Ok, how do we want proceed here? I have an additional patch in the queue > that adds AMBA plug and play support to the LEON3 support of QEMU so that > you can run unmodified binaries for RTEMS, eCos and Linux. It's sparc-specific, it's pretty small, it's been reviewed. MJT: I suggest we take the pragmatic approach and apply it via -trivial. thanks -- PMM
12.02.2014 18:00, Peter Maydell wrote: [] > It's sparc-specific, it's pretty small, it's been reviewed. > MJT: I suggest we take the pragmatic approach and apply it > via -trivial. I actually applied it back at Feb-06. Should be in the next pull request at Friday. Thanks, /mjt
Am 12.02.2014 14:54, schrieb Sebastian Huber: > On 2014-02-06 09:57, Peter Maydell wrote: >> On 6 February 2014 08:40, Michael Tokarev<mjt@tls.msk.ru> wrote: >>> >03.02.2014 13:18, Sebastian Huber wrote: >>>> >>A lot of real world LEON3 systems are shipped with the GRMON boot >>>> >>loader. This boot loader initializes the stack pointer with the >>>> end of >>>> >>RAM address. The application can use this to detect the RAM size >>>> of a >>>> >>particular board variant. >>> > >>> >I don't really know much about sparc or leon3 stuff. But having a >>> >reviewed-by from Fabien I can apply it to trivial-patches. I'm not >>> >really sure why it can't go to sparc tree instead. >> As far as I'm aware there is currently no sparc tree; Blue is the >> listed maintainer and typically just applied patches directly. >> In the absence of Blue, if somebody else who cares about sparc >> wishes to collect up reviewed sparc patches and submit them as >> a pull request so they don't just get ignored, I'm willing to apply >> that pull. > > Ok, how do we want proceed here? I have an additional patch in the > queue that adds AMBA plug and play support to the LEON3 support of QEMU > so that you can run unmodified binaries for RTEMS, eCos and Linux. Whether or not someone submits a pull for the reviewed patches, you'll need to post your second patch for review. You can add either a tag in [PATCH ...] or indicate textually after --- that it depends on this patch, you don't need to wait for it to get applied first. Regards, Andreas
diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c index c583c3d..c16e9e4 100644 --- a/hw/sparc/leon3.c +++ b/hw/sparc/leon3.c @@ -45,6 +45,7 @@ typedef struct ResetData { SPARCCPU *cpu; uint32_t entry; /* save kernel entry in case of reset */ + target_ulong sp; /* initial stack pointer */ } ResetData; static void main_cpu_reset(void *opaque) @@ -58,6 +59,7 @@ static void main_cpu_reset(void *opaque) cpu->halted = 0; env->pc = s->entry; env->npc = s->entry + 4; + env->regbase[6] = s->sp; } void leon3_irq_ack(void *irq_manager, int intno) @@ -133,6 +135,7 @@ static void leon3_generic_hw_init(QEMUMachineInitArgs *args) /* Reset data */ reset_info = g_malloc0(sizeof(ResetData)); reset_info->cpu = cpu; + reset_info->sp = 0x40000000 + ram_size; qemu_register_reset(main_cpu_reset, reset_info); /* Allocate IRQ manager */
A lot of real world LEON3 systems are shipped with the GRMON boot loader. This boot loader initializes the stack pointer with the end of RAM address. The application can use this to detect the RAM size of a particular board variant. Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de> --- hw/sparc/leon3.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)