Date: Mon, 11 Jul 2011 23:01:36 -0400 From: "Brian J. McGovern" <mcgovern@beta.com> To: Mark Tinguely <marktinguely@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? Message-ID: <1310439696.1438.6.camel@bmcgover-laptop.beta.com> In-Reply-To: <4E1B83F8.3070700@gmail.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> <4E1B83F8.3070700@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2011-07-11 at 18:15 -0500, Mark Tinguely wrote: > 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 > Its pretty much dying right away. The entire session is at the end. A few details to make sure you're up to speed on how I got here... The kernel was built with (note I'm not putting an MFS in it yet - want to get something booting first. Oh, and outside of the ARM_CACHE_LOCK_ENABLE change, is running a "stock" 8.2 codebase): cd /usr/src && make TARGET=arm TARGET_ARCH=arm KERNCONF=GUMSTIX DESTDIR=/usr/tmp/armbuild buildkernel installkernel And then post-processed with mkimage -A arm -O freebsd -T kernel -C none -a 30008000 -e 300080e0 -n "FreeBSD" -d /usr/tmp/armbuild/boot/kernel/kernel /usr/tmp/kernel.armboot Then running: qemu-system-arm -m 512 -kernel /usr/tmp/kernel.armboot If there are any questions as to why I'm doing something a particular way, the answer is "Because the documentation I can find says so". QEMU is 0.14.1 from ports/emulators/qemu-devel. ESC[mUsing AAlib driver: Curses driver 1.0 (curses) ESC[HESC[Jqemu: fatal: Trying to execute code outside RAM or ROM at 0x300080e0 R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=300080e0 PSR=400001d3 -Z-- A svc32
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1310439696.1438.6.camel>