Upgrading uboot on Globalscale Sheevaplug

[aurelius]

I've got uboot 1.1.4 (Jul 14 2009 - 06:46:57) Marvell version: 3.4.16 & I'm looking to upgrade via usb.
Using OSX disk utility, I've formatted my 4 gig usb thumb drive with 3 Fat partitions named sda1, sda2 and sda3. On SDA1, I placed the files from Sheevaplug installer 1.0 2 and uboot.bin there as well.
I interrupt the boot process and get the Marvell>> prompt and type:
 fatload usb 0:1 0x08000000 uboot.bin

I've entered:
setenv mainlineLinux yes
setenv arcNumber 2097
saveenv
reset

and

setenv bootargs_console console=ttyS0,115200
setenv bootargs_root 'root=/dev/sda2 rootdelay=10'
setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x0800000 /uImage; ext2load usb 0:1 0x01100000 /uInitrd'
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_usb; bootm 0x0800000 0x01100000'
saveenv

run bootcmd returns the following:

(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00800000 ...
Bad Magic Number


I don't know where to go from here re: the bad partition & I'm confused where 008000000 is coming from, shouldn't it be 08000000?

[radael]

Don't know the answer to the problem, but the numbers are fine.  (Leading zeros can generally be ignored on input.)

It is a 4-Byte address:  00 80 00 00,

So, the leading zeros are included for a complete report.

[spinifex]

3 Fat partitions

setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x0800000 /uImage; ext2load usb 0:1 0x01100000 /uInitrd'

(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00800000 ...
Bad Magic Number
 

Try fatload instead?

[aurelius]

run fatload returns "## Error: "fatload" not defined"

[marcus]

Try fatload in place of ext2load

run fatload didn't work because fatload isn't an environment variable; it's a command.

[spinifex]

OK.
I was trying to point out that you are using ext2load from a fat device.
Either make it ext2 or use fatload

[aurelius]

# So I went back in & replaced ext2load with fatload as follows:

setenv bootargs_console console=ttyS0,115200
setenv bootargs_root 'root=/dev/sda2 rootdelay=10'
setenv bootcmd_usb 'usb start; fatload usb 0:1 0x0800000 /uImage; fatload usb 0:1 0x01100000 /uInitrd'
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_usb; bootm 0x0800000 0x01100000'
saveenv

#run bootcmd returns the following:


Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - usb 0:1 **
## Booting image at 00800000 ...
Bad Magic Number

#The SanDisk USB flash drive with the 3 fat partitions created in OSX's disk utility begins blinking it's LED.
#Also, "fatload usb 0:1 0x080000 uboot.bin" returns:

** Can't read from device 0 **

** Unable to use usb 0:1 for fatload **


#Huh?

[pingtoo]

First of all, I think you have failed to upgrade u-boot. from your early post, you state that you load u-boot.bin in memory but I did not see any description you write it back to nand. I could give you instruction on how to write the u-boot.bin in mmeory to NAND but I am not in front of plug, I don't trust my memory to give the right instruction so please search this fourms, I think you can find the right command sequence on how to write the uboot back to NAND.

the reset of message most likly because uboot 1.1.4 (3.4.16) have problem with USB device, so once you succeed upgrade u-boot you should have no problem.

Good luck

[crunch]

fatload usb 0:1 0x01100000 /uInitrd'

I've used
fatload usb 0 0x800000 /myimage

successfully from the Marvell shell. Device 0:1 might be your problem there. Also, a few on the forums here say to use FAT16 partitions. I believe this prevents you from accidentally creating partitions larger than 2GB, and possibly improves compatibility for the tools.

[birdman]

First of all, I think you have failed to upgrade u-boot. from your early post, you state that you load u-boot.bin in memory but I did not see any description you write it back to nand.

Related to this, can I test a new uboot by loading it and the running commands, but not the ones() to save it back to nand.  By test I mean try it, and if it fails then a power off/on will take me back to where I was with the previous, working uboot.
And, if I do update uboot, do I lose environment variables and have to reset them?

[aurelius]

# I'm thinking that the problem may be that OSX's disk utility formats to FAT32, hence the bad partition. So I used to Disk Utility to simply erase the existing partitions and reformat the drive to FAT32 "Unfortunately, when I try to repartition the USB thumb drive with:

diskutil partitiondisk /dev/disk2 1 MBRFormat "MS-DOS FAT16" "SDA1" 1000M

#I get the following error:

Started partitioning on disk2
Unmounting disk
Creating partition map
[ \ 0%..10%..20%......................................... ]
Waiting for disks to reappear
Formatting disk2s1 as MS-DOS (FAT16) with name SDA1
Error: -9962: The chosen size is not valid for the chosen filesystem

#I was thinking that the size might be too big, so I tried the same command with 250M, but got the same -9962 error.  Any ideas?

[crunch]

If it's possible to get on a Linux box (or boot with a Linux liveCD) you could use fdisk and mkdosfs, start on step 3 here:
http://www.netsonic.fi/~kelpf25b/sdfat16howto.html

[pingtoo]

You can test u-boot without writing it in to storage. you will need to have access to u-boot elf file, not the .kwb file. I use openond to load it into ram.

I think the procedure is:

Code:

openocd -f /path/to/broad/sheevaplug.conf

than from second windows

Code:

telnet localhost 4444
sheevaplug_init
load_image /path/to/u-boot.elf
resume 0x60000

I could be wrong since I don't have access to my plug now.

Good luck

First of all, I think you have failed to upgrade u-boot. from your early post, you state that you load u-boot.bin in memory but I did not see any description you write it back to nand.

Related to this, can I test a new uboot by loading it and the running commands, but not the ones() to save it back to nand.  By test I mean try it, and if it fails then a power off/on will take me back to where I was with the previous, working uboot.
And, if I do update uboot, do I lose environment variables and have to reset them?

[birdman]

You can test u-boot without writing it in to storage. you will need to have access to u-boot elf file, not the .kwb file. I use openond to load it into ram.

Thanks. 
But those instruction seemed to be a way of testing it on a running kernel!?!
I was really just wondering whether it could be tested at the "console prompt" (i.e. before any kernel had booted) without writing it to nand.

[pingtoo]

Read my code again, I said load u-boot.elf