On 1 August 2012 12:50, Rob Landley 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 would actually ru
On 07/27/2012 12:28 PM, Peter Maydell wrote:
> On 27 July 2012 18:16, Rob Landley 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, 3.
On 27 July 2012 18:16, Rob Landley wrote:
> On 07/27/2012 09:32 AM, Peter Maydell wrote:
>> On 27 July 2012 14:45, Rob Landley 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 atte
On 07/27/2012 09:32 AM, Peter Maydell wrote:
> On 27 July 2012 14:45, Rob Landley 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.
>>
>>
On 27 July 2012 14:45, Rob Landley 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 this (and pro
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 co
