On Fri, Nov 30, 2007 at 05:15:21PM +, Paul Brook wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
> > in the sh4 specific case, it doesn't make sense for sh4 to print an access
> > error to a physical address
On 11/30/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
> > > On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > > > The following patch enforces that the sh4 ta
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
> > On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > > The following patch enforces that the sh4 target is 32 bit to prevent
> > > qemu to expand incorrectly
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
> On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > The following patch enforces that the sh4 target is 32 bit to prevent qemu
> > to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
>
> This is wrong.
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> The following patch enforces that the sh4 target is 32 bit to prevent qemu
> to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need
to be
The following patch enforces that the sh4 target is 32 bit to prevent qemu to
expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
Carlo
---
Index: target-sh4/cpu.h
===
RCS file: /sources/qemu/qemu/target-sh4/cpu.h,v
