Date: Tue, 12 Jul 2011 08:15:26 -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: <4E1C48EE.3070905@gmail.com> In-Reply-To: <1310439696.1438.6.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> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/11/2011 10:01 PM, Brian J. McGovern wrote: > 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 > > Thank-you for the information. You are attempting to execute in device memory. Here is a link to steps that has been wisely given to me: http://lists.freebsd.org/pipermail/freebsd-arm/2009-July/001887.html As you can see from that file, there is also a problem with the console detection that I mentioned to qemu group. I downloaded the GUMSTIX uboot binary file. I don't have a URL handy. After doing the "dd" commands, I believe 'bootelf 40000' should be the correct start location since 0x40000 is hex for 256KB, which is the location that we loaded the kernel in the "flash" file. You will get warnings to the kernel loadable modules that are require for qemu to operate "aio" comes to mind. --Mark Tinguely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E1C48EE.3070905>