Re: attempting to boot gumstix kernel via QEMU

[Robin Randhawa <robin.randhawa%gmail.com@localhost>]

Hi Michael.

On Sun, Jan 10, 2010 at 11:45:29PM +0000, Michael Litchard wrote:
 
>  dd of=cflash.img bs=1k conv=notrunc
> if=/home/michael/Downloads/u-boot-connex-400-r1578.bin
> 
> lucius# qemu-system-arm -M connex -m 289 -pflash cflash.img
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x01000000

Works for me. I pretty much replicated your setup and got this :

$ ./arm-softmmu/qemu-system-arm -M connex -pflash flash -monitor null
-nographic -s -m 289
pxa2xx_clkpwr_write: CPU frequency change attempt


U-Boot 1.2.0 (Dec 21 2007 - 13:31:10) - 400 MHz - 1578M

*** Welcome to Gumstix ***

DRAM:  64 MB
pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000,
wcycle 0x0 cmd 0x0 value 0x90)
Flash: 16 MB
Using default environment

SMC91C1111-0
pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000,
wcycle 0x0 cmd 0x0 value 0x90)
Net:   SMC91C1111-0
Hit any key to stop autoboot:  0 
GUM>

Note that I'm using a bleeding edge qemu build from top-of-tree. Are you
doing the same ?

> I can't find anything using google that specifically talks about using
> qemu on NetBSD to run an emulated gumstix. Guidance for my more
> immediate goal,
> and perhaps my larger goal would be appreciated.

I've never tried using qemu with NetBSD but clearly qemu only really
does special initialisation for Linux AFAIK (for the system emulation,
that is) which includes ATAG list initialisation for ARM and a bit of
setup for secondary cores on an SMP emulation.

I suppose something similar could be done for NetBSD as well. Ideally
qemu should parse the NetBSD kernel ELF image header and take care of
loading the image before starting the emulation from the ELF entry
point. Interestingly, Qemu can only work with Linux zImages (and not
uncompressed vmlinux images) so there's definitely some customisation
needed IMHO.

For the moment, your approach is likely to be the least painful. Ensure
that the flash image that already contains u-boot also has the NetBSD
binary image (not ELF) at a 'safe' offset and then use u-boot to
relocate the binary to the addresses the NetBSD kernel expects to be run
from and then 'go' to that address.

HTH,
Robin