Installer could not detect the version of your current uBoot

Hello,
I just tried Jeff's amazing script to populate a new Dockstar I received in the mail today with Debian, to allow it to boot off a thumb drive. The install seemed to work, but the uBoot installer failed with the following:

Quote

# Validating existing uBoot...
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
Connecting to jeff.doozan.com (69.163.187.226:80)
valid-uboot.md5 100% |*******************************| 643 --:--:-- ETA
## Unknown uBoot detected on mtd0: 654d92c7e88a7a0debb136168fe822b7
##
## The installer could not detect the version of your current uBoot
## This may happen if you have installed a different uBoot on
## /dev/mtd0 or if you have bad blocks on /dev/mtd0
##
## If you have bad blocks on mtd0, you should not try to install uBoot.
##
## If you have installed a diffirent uBoot on mtd0, and understand the
## risks, you can re-run the installer with the --no-uboot-check parameter
##
## Installation cancelled.
# checking for /sbin/mke2fs...

Other items of potential interest:

Quote

-bash-3.2# cd /proc
-bash-3.2# cat version
Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) #57 Mon Aug 31 16:31:01 PDT 2009

-bash-3.2# cat mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "root"
mtd3: 0db00000 00020000 "data"
-bash-3.2# cat partitions
major minor #blocks name

31 0 1024 mtdblock0
31 1 4096 mtdblock1
31 2 32768 mtdblock2
31 3 224256 mtdblock3
-bash-3.2# /usr/sbin/fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
-bash-3.2#

Should I force the issue, or are there other things that should be investigated before doing so? I have some knowledge of uBoot from working with the SheevaPlug, but I'm certainly no expert.

Thanks,
Rob



Edited 1 time(s). Last edit at 11/16/2010 08:23PM by restamp.

Update: After an email conversation with Jeff, who determined my problem was due to a 1-byte (actually 1-bit) error in my original uBoot -- luckily, this error didn't appear to be in a critical leg of the code -- I went ahead and forced Jeff's latest uBoot onto my Dockstar. And, it installed with no problems, appearing to work as advertised. I'm now running Debian. Now, I just need to find a thumb drive that cold-boots OK.

Thanks Jeff!

BTW, does anyone know which version of Unix is on the Dockstar originally?

Hello restamp,
I am running into similar issues with "Unknown uBoot detected on mtd0:" and a different md5 checksum, during a debian install. I let the debian install proceed, but of course it will not boot up Debian during the reboot phase, just to Linux Pogoplug instead. Running "/usr/sbin/fw_printenv" shows the same CRC error that you saw previously.

I am tempted to believe that the problem source is the same, and went ahead and tried forcing uBoot install using the "--no-uboot-check" parameter. It still does not install uBoot, I am afraid.

It is worth noting that my Dockstar is not pristine, i.e. I registered it on Pogoplug site and its firmware may have been updated, as the output from "uname -a" seem to indicate:
Linux Pogoplug 2.6.22.18 #81 Tue Oct 19 16:05:00 PDT 2010 armv5tejl unknown


You mentioned that you had an email conversation with Jeff, and determined for sure that it is a 1-bit corruption in the original uBoot. Can you expound on how you came to that conclusion?

I am currently unsure whether my problem is due to bit corruption or the fact that Pogoplug may have reflashed my uBoot. Hoping to get some pointers to go one way or the other.

Also, is there any caveat to reflashing original uBoot back on, and then start the install scripts anew?

I have tried USB disks, and also an SD card on a USB adaptor, with the same failures.


Thanks,
Sam

I believe it is unlikely that your uBoot was reflashed at the time it was registered. Here's what Jeff wrote to me:

Quote

I think it's more likely that you have a bad block, but I'll take a look.

Run the following and send me the resulting file:

cd /tmp
wget http://jeff.doozan.com/debian/uboot/nanddump
chmod +x nanddump
nanddump -nof mtd0 /dev/mtd0

After doing this, Jeff compared my dump against a pristine one and located the error.

It's been a while since I looked into this. I think the CRC error may be due to fact that Jeff's uBoot stores its env at 0xc0000 whereas the original uBoot stores its env at 0xe0000. Or, maybe it's stored in a different format. In any event, Jeff concluded that the problem was either due to a bad block in the NAND or a bad flash at the factory. If the former, I stood a good chance of bricking the device by reflashing it. If the latter, it should work fine after being reflashed. I elected to try force-installing the new uBoot using the --no-uboot-check option and that did work for me.

Sam, you don't describe how attempting to do the forced flash failed nor did you provide any of the output from when you tried using the --no-uboot-check option. Since you aren't claiming your Dockstar was bricked, I'm presuming thta the install script aborted, leaving you with the original uBoot still installed. But, without knowing the details, it would be difficult to advise any further.

Hi restamp,

Thank you for your inputs.

I believe my attempts at flashing failed. The Dockstar is still operational though, and it boots into the Pogoplug Linux okay. My theory as to why Jeff's script failed to flash the first time is that my Dockstar firmware was updated, as I registered on the Pogoplug site (could hardly restrain myself to get at least the NAS functionality going previously). This seems to be backed by the revision date as indicated by output of the "uname -a" command. I presume this is based off the uBoot code in mtd2, which possibly was "touched" by Pogoplug.

I cannot explain why the second attempt failed, even after the "--no-uboot-check" option. I remember that I did not see "nandwrite" appearing in the output logs, so the install script must have aborted without flashing. [I am away from the Dockstar now, and so have no access to actual output logs at the moment].

Fearing a badblock in mtd0, especially with the "Bad CRC" message and possibility of bricking, as you also mentioned; I have not tried to force-flash it again.

I may try to download the code in mtd0 etc and do a compare, though if it was "touched", it would miscompare everywhere.

I do have another pristine Dockstar. I think I might use this and go through the whole install process. This would be a cleaner alternative, and I can come back to this later, once I have at least a working Debian system up.

I will post more, if something interesting crops up in the debug or install process.

Appreciate your comments and help.

~Sam