Print

[NewITMalcolm]

Download the latest uboot and copy onto a Fat32 usb stick

Put the usb into the Guru and using the Jtag Module boot to the Marvell>> prompt.

Note: For a Guru Plus you will need to use USB 1:1

Code: [Select]

usb start
fatload usb 0:1 0x6400000 /uboot-filename.bin
nand erase 0x0 0x0a0000
nand write 0x6400000 0x0 0xa0000
saveenv
reset

That's it.

[Confusticated]

Hi James,

Some info about this u-boot would be nice. A dump from the prompt of:
version
bdinfo (for the architecture number, before any environment override)
help (for a list of the supported commands)

A new release of u-boot is imminent which should support booting from
sdhc as well as usb & esata, it may pay to wait a fortnight.

[NewITMalcolm]

Hi Confusticated,

I have removed the link to the binary until I can put more information together. I will leave the rest as the method is still valid.

[arnonymous]

i tried this method with the Guruplug server - uboot.plug2.bin.zip binary found here: http://code.google.com/p/guruplug/downloads/list

It doesn't seem to change anything in the Boot screen message, still getting same version.
should i use the bin i from the link above, or another u-boot image, if so which?

[chthon]

Great tutorial!

One problem though, when I reboot the plug with the 2 USB ports occupied it hangs at this point in the boot but seems to eventually sort itself after some minutes:

Code: [Select]

U-Boot 2010.03-01161-gd91b0a9 (Apr 22 2010 - 03:24:41)
Marvell-GuruPlug

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
Hit any key to stop autoboot:  0
No link on egiga0
Using egiga1 device
ping failed; host 192.168.2.1 is not alive
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices...
    Request Sense returned 00 00 00

It normally boots fine if I remove the USB drive from the USB port closest to the base of the plug but does fail to boot sometimes if I boot from uboot via the JTAG module.  Have I messed up the uboot environment variables I wonder? Any pointers anyone can provide would be gratefully appreciated.   

My uboot environment variables are as follows:

Code: [Select]

bootcmd=${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000;
bootdelay=3
baudrate=115200
x_bootcmd_ethernet=ping 192.168.2.1
x_bootcmd_usb=usb start
x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000
x_bootargs=console=ttyS0,115200
x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
ethact=egiga0
bootargs=console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
ethaddr=F0:AD:4E:00:4D:40
ipaddr=192.168.0.3
serverip=192.168.1.20
filesize=2BFFC
eth1addr=02:50:43:54:2c:c4
arcNumber=2097
mainlineLinux=yes
stdin=serial
stdout=serial
stderr=serial

Environment size: 645/131068 bytes


[NewITMalcolm]

That's the wrong arcNumber for a Guru, should be 2659

NewIT Technical

[chthon]

Thanks, I've reset the arc number and run saveenv. 
It still hangs for about 5mins or more on boot if I have 2 USB sticks in -- seems to get there in the end though.

[Confusticated]

Note 'mainlineLinux' & 'archNumber' are not a valid environment variables for the version of uboot you are running,
which is just as well as getting it wrong will cause the kernel to stop immediately it executes and detects the mismatch.
As this doesn't happen your uboot and kernel are obviously defaulting to the correct value
('bdinfo' at the uboot prompt will show you what it is).

Globalscale privately forked both uboot and the kernel for the plug without getting an official machine ident,
they dreamt one up of their own. This means the machid (arcNumber) in Globalscale's uboot and kernel are invalid,
and only work with each other (this is what the plug was shipped with).

As James states the official machine id is 2659 for the guruplug, and this is what your mainline uboot will be set to.

The mainline uboot command to set the machine id has since changed from 'arcNumber' to 'machid',
With an updated mainline uboot, to use the original Globalscale kernel from NAND you must specify
setenv machid 2601

conversely with Globalscale's uboot and a mainline kernel
setenv arcNumber 2659
mainlineLinux=yes

with both mainline uboot and kernel you need specify nothing, as the default values are correct.

[chthon]

Thanks for the helpful clarification.

I think that I thought I was using a Globalscale uboot, just an updated version.  I got the .bin from here not from the uboot git repository. http://plugcomputer.org/index.php/us/resources/downloads?func=select&id=15
I downloaded the uboot.guruplug.bin file not u-boot-marvell-git.tar.gz. It must be a mainline uboot though as you say.

The kernel I am using is 2.6.33.7 - rather than compiling it I took the binary from this page of the Plug Wiki
http://www.plugcomputer.org/plugwiki/index.php/Setting_GuruPlug_to_be_a_stable_WiFi_Client
I think this kernel must be from vanilla sources.

So, if I understand you correctly I'm running the mainline kernel and a mainline uboot (albeit not the most recent version).  So I don't need to specify an arcNumber (uboot allows me to do this but ignores the variable).   So the issue I identify with respect to the problems booting when both USB ports are occupied isn't related to the arcNumber/machine id set in my environment variables.

So, perhaps it is a bug in the version of uboot I am using?  Perhaps I should get to grips with git and get a more recent version of uboot and try that?

[Confusticated]

The problem you are experiencing is most likely to do with the initialisation of one of your USB devices.
This could be the fault of either the device itself or uboot, try your USB peripherals one at a time and
see which one causes the delay. You will then know what to google for, I expect it to be a problem with
uboot and that particular device, else the kernel would also likely delay during its USB bus scan at boot.

There has been some recent progress with uboot development and USB devices, a newer uboot may be the answer.

[pietsnot]

there's is newer uboot 2010.03-01266-g42f7128_May.23.2010-192542
http://plugapps.com/os/guruplug/guruplug-u-boot.bin

[Drumknott]

Can I still follow this guide with my Guruplug+?

I'm having trouble getting the console working

[Drumknott]

by the way, pietsnot (or an admit) i'd remove that link .. i was *this* close to overwriting my uboot with a 404 html page..heh

[pietsnot]

by the way, pietsnot (or an admit) i'd remove that link .. i was *this* close to overwriting my uboot with a 404 html page..heh

you can find a copy here:
http://www.sendspace.com/file/ie72y3

[apemberton]

I havn't had to tinker with u-boot on my GP+'s but I have found I have messed up the kernel (by deleting the kernel version modules in '/lib/modules') on one of them. At present all are as set at the factory.

I found that as default, all my GP+'s have the uboot arcNumber set to 2097 (easy to change I know) but I also found that there is no ext2load capability built in. At the moment, my GP+'s are set by default to boot from nand but passes operation (modules etc.) to /dev/sdb2 which means that both nand and micro sd card must have the same kernel version. I wondered why, despite flashing a new kernel to sd card, the version remained set to 2.6.32-5-kirkwood!

It would be nice to know what versions of GP u-boot are available and the features built in, environment, memory settings and so on - in plain english. I am aware of the http://plugcomputer.org/plugforum/index.php?topic=5755.0 thread but again no indication whether it is safe to try any of the compiled u-boot's.

I would like to be able to boot from SD card rather than nand though I recognise that the boot partition (/dev/sdb1 or 'fatload usb ?:?') will have to be vfat. Plainly the kernel loads ext2/ext3 etc as these are availble after booting - but not in u-boot as in Sheevaplugs - hence having to boot from vfat. There also does not appear to be any eSata u-boot capability (again unlike the Sheeva) though I stand to be corrected on that. I am guessing that all kernels suitable for the GP do not have eSata built in and will rely on loading modules.

I am aware that I could boot from a FAT formatted USB stick but I don't want to have to use the v slow USB stick. I also find that the micro SD card extremely slow too. I am not sure that there is a 8GB SLC'ish micro SD card which could speed things plus have better wear capabilities.