Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jul 2011 18:15:04 -0500
From:      Mark Tinguely <marktinguely@gmail.com>
To:        "Brian J. McGovern" <mcgovern@beta.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Suggestions for arm build for qemu?
Message-ID:  <4E1B83F8.3070700@gmail.com>
In-Reply-To: <1310412331.1466.41.camel@bmcgover-laptop.beta.com>
References:  <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/11/2011 2:25 PM, Brian J. McGovern wrote:
> [trimmed]
>> The 194609 change is also in FreeBSD 8.2 elf_trampoline.c. When it was
>> in the kernel, qemu would just sit there in some loop.
>>
>> With option ARM_CACHE_LOCK_ENABLE compiled into the kernel, qemu will
>> give an illegal instruction error.
>>
>> --Mark Tinguely
>>
> I saw that, but when you commented about hand-editing additional changes
> in to the file, I figured there was "more" that I hadn't picked up yet.
> As to ARM_CACHE_LOCK_ENABLE, I commented it
> in /usr/src/sys/arm/xscale/std.xscale, and that seems to removing it
> from the kernel.
>
> At this point, I'm still running in to a:
>
> "qemu: fatal: Trying to execute code outside of RAM or ROM at
> 0x300080e0" after having used an example at
> http://wiki.openmoko.org/wiki/FreeBSD  for mkimage with QEMU 0.14.1
> (qemu-devel).
>
> I remember there being a patch to allow for compressed kernels, so I
> need to dig that out when I get back to trying this again.
>

How far does the boot process get before this happens?

A quick look at the device map, and that seems to be the 
PXA2X0_PCMCIA_SLOT1 which is not mapped.

You could remove the mkimage and let it try to NFS mount - this is just 
a test to see if it will boot further.

Also with the GUMSTIX and qemu, certain network commands (ntpdate comes 
to mind) caused page fault in the smc driver. I never investigated.

--Mark Tinguely



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E1B83F8.3070700>