A block diagram of the GuruPlug standard edition is shown in the image below:
Since my NetBSD blog is also in suspended mode for a year (due to lack of time/toys), I'm hoping that this new toy will bring it back alive. This first step consists out of obtaining some source:
edb@lapedb:~$ mkdir netbsd edb@lapedb:~$ cd netbsd/ edb@lapedb:~/netbsd$ export CVS_RSH="ssh" edb@lapedb:~/netbsd$ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot" edb@lapedb:~/netbsd$ cvs co -P src
And then we need to use the NetBSD build system to build up a toolchain (the crosscompiler capable of cross-compiling the NetBSD kernel for the ARM architecture which runs on my standard Linux/x86 laptop) for the NetBSD/evbarm port. This we can do by executing:
edb@lapedb:~/netbsd$ cd src/ edb@lapedb:~/netbsd/src$ time ./build.sh -u -m evbarm tools ...
One sidenote, my Debian gave me a GCC 4.6.1 which can check for several new warnings, warnings which NetBSD's 5.99.22 external binutils cannot cope with, requiring me to use an older gcc. This can be accomplished with prefixing the build with:
edb@lapedb:~/netbsd/src$ export HOST_CC=/usr/bin/gcc-4.5 edb@lapedb:~/netbsd/src$ export HOST_CXX=/usr/bin/g++-4.5
Update 6 August 2011: , I created a ticket for the problem described above, and in the meantime the CVS repository of NetBSD contains a fix for this issue. You can track this at NetBSD ticket #45140.
This gives use a nice cross-compiler as a result:
edb@lapedb:~/netbsd/src$ obj/tooldir.Linux-2.6.39-2-686-pae-i686/arm--netbsdelf/bin/gcc -v Using built-in specs. Target: arm--netbsdelf Configured with: /home/edb/netbsd/src/tools/gcc/../../gnu/dist/gcc4/configure --target=arm--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion=NetBSD nb1 20110620 --enable-__cxa_atexit --disable-nls --disable-multilib --program-transform-name=s,^,arm--netbsdelf-, --enable-languages=c c++ objc --prefix=/home/edb/netbsd/src/obj/tooldir.Linux-2.6.39-2-686-pae-i686 Thread model: posix gcc version 4.1.3 20080704 (prerelease) (NetBSD nb2 20081120)
A next step is building a kernel. First try is trying to steal a default configuration file and src/sys/arch/evbarm/conf contains a configuration file called SHEEVAPLUG which was the name of the predecessor of the Guruplug, which means this one should be worth the shot.
edb@lapedb:~/netbsd/src$ ./build.sh -j 2 -u -m evbarm kernel=SHEEVAPLUG ... ===> Summary of results: build.sh command: ./build.sh -j 2 -u -m evbarm kernel=SHEEVAPLUG build.sh started: Wed Jul 13 17:55:38 CEST 2011 NetBSD version: 5.99.55 MACHINE: evbarm MACHINE_ARCH: arm Build platform: Linux 2.6.39-2-686-pae i686 HOST_SH: /bin/sh TOOLDIR path: /home/edb/netbsd/src/obj/tooldir.Linux-2.6.39-2-686-pae-i686 DESTDIR path: /home/edb/netbsd/src/obj/destdir.evbarm RELEASEDIR path: /home/edb/netbsd/src/obj/releasedir Updated makewrapper: /home/edb/netbsd/src/obj/tooldir.Linux-2.6.39-2-686-pae-i686/bin/nbmake-evbarm Building kernel without building new tools Building kernel: SHEEVAPLUG Build directory: /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG Kernels built from SHEEVAPLUG: /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG/netbsd build.sh ended: Wed Jul 13 17:57:21 CEST 2011 ===> . edb@lapedb:~/netbsd/src$ file /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG/netbsd /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG/netbsd: ELF 32-bit LSB executable, ARM, version 1, statically linked, for NetBSD 5.99.55, not stripped edb@lapedb:~/netbsd/src$ ls -hal /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG/netbsd -rwxr-xr-x 1 edb edb 4.8M Jul 13 17:57 /home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG/netbsd
At this point I am already a proud owner of a tftp service operating on 10.0.0.1, connect a UTP cable between my laptop and the Guruplug, so I just need to wrap the netbsd file in a u-boot compatible format (using u-boots mkimage tool) copy the netbsd kernel which is now inside the u-boot image to my tftp root:
edb@lapedb:~/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG$ mkimage -A arm -O netbsd -T kernel -C none -a 0 -e 0 -n netbsd -d netbsd /srv/tftp/uImage Image Name: netbsd Created: Wed Jul 13 18:17:52 2011 Image Type: ARM NetBSD Kernel Image (uncompressed) Data Size: 4980825 Bytes = 4864.09 kB = 4.75 MB Load Address: 00000000 Entry Point: 00000000
Update August 6, 2011: Actually mkimage, or at least the NetBSD variant of this tool mkubootimage are part of the toolchain, and if you build the kernel, build.sh will already create a proper image for you. This will be called netbsd.ub and you can see how it gets created just before the summary of the build, this will look as follows:
/home/edb/netbsd/src/obj/tooldir.Linux-2.6.39-2-686-pae-i686/bin/nbmkubootimage -A arm -T kernel -a 0x00008000 -n NetBSD/sheevaplug 5.99.55 -C none netbsd.bin netbsd.ub magic: 0x27051956 time: Sat Aug 6 17:14:25 2011 size: 4415424 load addr: 0x00008000 entry point: 0x00008000 data crc: 0x128165e8 os: 2 (netbsd) arch: 2 (arm) type: 2 (kernel) comp: 0 (none) name: NetBSD/sheevaplug 5.99.55 header crc: 0xa6c200d2
Next on the serial connection with the Guruplug from the U-boot prompt I attempt the following:
U-Boot 2009.11-rc1-00602-g8e6db3d (Dec 24 2009 - 03:11:17)
Marvell-Plug2
SoC: Kirkwood 88F6281_A0
DRAM: 512 MB
NAND: 512 MiB
In: serial
Out: serial
Err: serial
Net: egiga0
88E1121 Initialized on egiga0
Hit any key to stop autoboot: 0
Marvell>> setenv serverip 10.0.0.1
Marvell>> setenv ipaddr 10.0.0.2
Marvell>> tftpboot 0x100000 uImage
Using egiga0 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'uImage'.
Load address: 0x100000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###############
done
Bytes transferred = 4980889 (4c0099 hex)
Marvell>> bootm 0x100000
## Booting kernel from Legacy Image at 00100000 ...
Image Name: netbsd
Image Type: ARM NetBSD Kernel Image (uncompressed)
Data Size: 4980825 Bytes = 4.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
## Transferring control to NetBSD stage-2 loader (at address 00000000) ...
NetBSD/evbarm (sheevaplug) booting ...
Loaded initial symtab at 0xc0388ec8, strtab at 0xc03bf1e4, # entries 13786
pmap_postinit: Allocated 35 static L1 descriptor tables
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.99.55 (SHEEVAPLUG) #0: Wed Jul 13 17:57:19 CEST 2011
edb@lapedb:/home/edb/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG
total memory = 512 MB
avail memory = 497 MB
mainbus0 (root)
cpu0 at mainbus0: Sheeva 88SV131 rev 1 (ARM9E-S core)
cpu0: DC enabled IC enabled WB enabled EABT branch prediction enabled
cpu0: 16KB/32B 4-way Instruction cache
cpu0: 16KB/32B 4-way write-back-locking-C Data cache
mvsoc0 at mainbus0: Marvell 88F6281 Rev. A1 Kirkwood
mvsoc0: CPU Clock 1200.000 MHz SysClock 400.000 MHz TClock 200.000 MHz
mvsoctmr0 at mvsoc0 unit 0 offset 0x20300-0x203ff: Marvell SoC Timer
mvsocgpp at mvsoc0 unit 0 not configured
mvsocrtc0 at mvsoc0 unit 0 offset 0x10300-0x10317: Marvell SoC Real Time Clock
com0 at mvsoc0 unit 0 offset 0x12000-0x1201f irq 33: ns16550a, working fifo
com0: console
com1 at mvsoc0 unit 1 offset 0x12100-0x1211f irq 34: ns16550a, working fifo
ehci0 at mvsoc0 unit 0 offset 0x50000-0x51fff irq 19: Marvell USB 2.0 Interface
usb0 at ehci0: USB revision 2.0
gttwsi0 at mvsoc0 unit 0 offset 0x11000-0x11fff irq 29: Marvell TWSI controller
iic0 at gttwsi0: I2C bus
mvcesa at mvsoc0 unit 0 not configured
mvgbec0 at mvsoc0 unit 0 offset 0x70000-0x73fff: Marvell Gigabit Ethernet Controller
mvgbe0 at mvgbec0 port 0 irq 11
mvgbe0: Ethernet address f0:ad:4e:ff:11:d5
OUI 0x784a7a model 0x0014 rev 9 at mvgbe0 phy 0 not configured
mvgbe0: no PHY found!
mvgbec1 at mvsoc0 unit 1 offset 0x74000-0x77fff: Marvell Gigabit Ethernet Controller
mvgbe at mvgbec1 port 0 not configured
mvpex at mvsoc0 unit 0 not configured
mvsata at mvsoc0 unit 0 not configured
mvsdio0 at mvsoc0 unit 0 offset 0x90000-0x9ffff irq 28: Marvell Secure Digital Input/Output Interface
sdmmc0 at mvsdio0
uhub0 at usb0: Marvell EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
sdmmc0: bad CIS ptr 0
sdmmc0: couldn't read CIS
sdmmc0: i/o init failed
sdmmc0: bad CIS ptr 0
sdmmc0: couldn't read CIS
sdmmc0: i/o init failed
"Marvell, 802.11 SDIO ID: 10, " (manufacturer 0x2df, product 0x9103) at sdmmc0 function 1 not configured
"Marvell, 802.11 SDIO ID: 10, " (manufacturer 0x2df, product 0x9103) at sdmmc0 function 2 not configured
uhub1 at uhub0 port 1: Genesys Logic USB2.0 Hub, class 9/0, rev 2.00/77.63, addr 2
uhub1: single transaction translator
umass0 at uhub1 port 3 configuration 1 interface 0
umass0: Hama SD Card Reader, rev 2.00/94.04, addr 3
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: disk removable
sd0: fabricating a geometry
sd0: 7600 MB, 7600 cyl, 64 head, 32 sec, 512 bytes/sect x 15564800 sectors
boot device: <unknown>
root device:
use one of: mvgbe0 sd0[a-h] ddb halt reboot
So far, so good, so we set the ip address for the guruplug to use, the ip address of the tftp server, we loaded the image (uImage) which we put in our tftp root into DDR memory (at offset 0x100000) and we asked the bootloader (U-boot) to boot the image which we put at memory address 0x100000. And then we see the NetBSD kernel messages appearing on our serial line. After loading the kernel it stops and prompts us for a root device to use (but we are not yet at that phase).
Some preliminary comments on this output:
- My unit has a USB to SD convertor attached to the USB port, one which was detected, this will in the future be the first host for a root filesystem, since this is easier to deal with than internal NAND flash.
- Some guruplug/sheevaplugs have an onboard microSD slot, here an attempt to probe it is done which fails.
- The Guruplug I'm using is known to have some problems with its ethernet phy, it looses the link every now and then, hence some oddities can be expected there.
External sources:
Posts
