On 07/27/2012 12:28 PM, Peter Maydell wrote:
On 27 July 2012 18:16, Rob Landley r...@landley.net wrote:
On 07/27/2012 09:32 AM, Peter Maydell wrote:
The thing this analysis is missing is any examination of the question
what is the hardware we are modelling documented to do?.
Given that 3.3,
On 1 August 2012 12:50, Rob Landley r...@landley.net wrote:
I can switch to a newer board, but I want to plug armv4tl, armv5l,
armv6l, and armv7l processors into it. (And eventually armv8 but nothing
supports that yet.) If it's always running armv7 then I can't _prove_
that this userspace
If you grab the current aboriginal linux build scripts:
http://landley.net/hg/aboriginal/archive/tip.tar.bz2
And ./build.sh sh4, then cd to build/system-image-sh4 and
./run-emulator.sh you get this:
sh_serial: unsupported read from 0x18
Aborted
The bug was triggered by linux kernel
On 27 July 2012 14:45, Rob Landley r...@landley.net wrote:
I.E. sci_getreg(port, SCFCR) move to before checking whether or not
we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort()
on an attempt to read from an unimplemented register.
I can patch the kernel to work around
On 07/27/2012 09:32 AM, Peter Maydell wrote:
On 27 July 2012 14:45, Rob Landley r...@landley.net wrote:
I.E. sci_getreg(port, SCFCR) move to before checking whether or not
we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort()
on an attempt to read from an unimplemented
On 27 July 2012 18:16, Rob Landley r...@landley.net wrote:
On 07/27/2012 09:32 AM, Peter Maydell wrote:
On 27 July 2012 14:45, Rob Landley r...@landley.net wrote:
I.E. sci_getreg(port, SCFCR) move to before checking whether or not
we'll ever possibly use the result. SCFCR is 0x18 and QEMU
