Newer uBoot as workaround to 3.2 kernel problem?

*shrug* I got nothing.... here is my environment as seen from uboot:

u-boot>> printenv
arcNumber=2097
baudrate=115200
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
bootdelay=3
console=ttyS0,115200
ethact=egiga0
ethaddr=00:10:75:1A:91:D5
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
stderr=serial
stdin=serial
stdout=serial
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_device=0:1
usb_init=run usb_scan
usb_root=/dev/sda1
usb_rootdelay=10
usb_rootfstype=ext2
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_scan_list=1 2 3 4
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params

Environment size: 2342/131068 bytes

and after boot:

root@dockstar-db:~# fw_printenv
ethact=egiga0
bootdelay=3
baudrate=115200
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_init=run usb_scan
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
ethaddr=00:10:75:1A:91:D5
arcNumber=2097

They both have the same ethaddr.... which is the same as before I put the newest uboot on.

I tried booting off of a stick with 3.3.2 on it. That also worked fine except for not giving me an IP address.

Configuring network interfaces...[   26.173800] mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 100 Mb/s, half duplex, flow control disabled
err, eth0: timed out
warn, eth0: using IPV4LL address 169.254.196.88
dhcpcd.sh: interface eth0 has been configured with new IP=169.254.196.88
done.

Old 2.6.32xxx fail lines:

Configuring network interfaces...[   17.453881] eth0: link up, 100 Mb/s, half duplex, flow control disabled
err, eth0: timed out
warn, eth0: using IPV4LL address 169.254.39.223
dhcpcd.sh: interface eth0 has been configured with new IP=169.254.39.223
done.

Edited 1 time(s). Last edit at 06/02/2012 10:37PM by optim.

*sigh* I apologize. this is a local issue. I set my router to assign both boxes to the same IP.

kk, thanks anyway... np - no apologies needed ... helping us test stuff is appreciated. ... and glad your box is up and running. ;^)

=====================================================

• davy's Github Repo's rescue-dg

davygravy Wrote:
->
> At least one issue to mention here, and a big
> one.
>
> E02 is different from P21 ... E02 is
> Kirkwood, while P21 is OXNAS (or at least, as far
> as I know, the _correctly_ labeled P21's are
> OXNAS...). This is important to make sure that
> Pogoplug P21 owners do not attempt to use this.
> If they are 100% sure that their device is
> Kirkwood, then maybe OK maybe, but TTBOMK, P21 is
> supposed to be OXNAS, and fully
> incompatible w/ the Kirkwood devices when it comes
> to either kernel or bootloader. Please
> (humbly asked) correct me, everyone, if this is
> not correct.
>
> Supposing it is a mislabeled E02/Kirkwood ... If
> you already have it installed then maybe it
> doesn't like being reinstalled? It probably
> _should_ want to decline installing the same (or
> older) uboot over again.

It's black and came in a box labeled P21. The label on the bottom of the foot stand says "Model Pogoplug E02". It's definitely Kirkwood I've got two of them, bought from Buy.com, months a part. They are (were) both running your latest uBoot, your latest Rescue and ARMedSlack.

Is there any reason why the nanddump arguments (-o) would make a difference in the resulting checksum of the dumped file? As i said in my first post, I do get the correct checksum if I don't use the -o argument and the installer works if i remove the -o argument from the nanddump commands in the script.

BTW, thanks for the work that you have done on the uBoot and Rescu systems; they are working great on my dockstars and Pogo here.

What kernel are you running? I wonder if there's something in your kernel/linux environment that's causing the NAND to be accessed differently.

You probably know most of this, but just a quick recap of what the -o switch does to make sure we're all trying to fix the same problem:

The -o parameter tells nanndump to omit the OOB data, which I believe is used internally by the NAND to do some CRC correction. There's something like 3 bits OOB for every 8 bits of data (These numbers may be wildly inaccurate, it's been a long while since I looked into this) The actual information on the nand ends up something like: DDDDDDDDOOODDDDDDDDOOO where D is a bit of data and O is a bit of OOB/CRC.

The uboot images are just data images without any embedded OOB (DDDDDDDD), but when nandwrite dumps them to mtd0, they should end up in the usual Data+OOB format.(DDDDDDDDOOO)

Telling nanddump to omit the OOB data (with the -o flag) tells it to write just the data bits to the file (DDDDDDDD) to the file that's being dumped. Without that switch, it would dump files that look like (DDDDDDDDOOO) which obviously will not match the original file in the (DDDDDDDD) format

In your case, however, it sounds like one of two things are happening:

1) the ALARM version of nandwrite is writing to the NAND without inserting proper OOB formatting
or
2) something in your environment is preventing nanddump from actually reading the OOB data, so that the -o switch ends up skipping real data values.

You mention having two devices, does one of them still work properly? You may be able to use a hex-editor to compare the output of nanddump with/without the -o switch on both devices to track down where the real problem lies.

You may also want to look at how the environment data at 0xC000000 is written to your NAND (I believe it should use the same DDDDDDDDOOO) format that the uboot image does.

Davy and Jeff thanks for your replies. I did some more testing this morning and it turns out that there is a difference in the behavior of the -o argument in the nanddump command used in ARMedSlack and the nanddump used is the Rescue System (and I assume Debian). In ARMedSlack the -o argument is used to "Dump OOB data" whereas in the rescue nandump it used to "Omit oob data". Seems to me that these are complete oposite behaviors and would seem to explain the different checksums.

In attempting to prove this I unwittingly (thankfully the uboot was ok) rebooted my pogoplug serveral times, switching between the Rescues system and ARMedSlack. Every time I did a nandump using the -o argument in ARMedSlack, the checksum of the resulting file came up as "42ead564226458d558d29ab38c0b44cc". Omitting the -o argument resulted in a checksum of "e84a5fd0a0205bb79aed07c3c6fbd145".

In the rescue system l got the opposite results. Using the -o argument resulted in a checksum of "e84a5fd0a0205bb79aed07c3c6fbd145". When I omitted the -o argument the checksum was "42ead564226458d558d29ab38c0b44cc".

So, this is resolved for me, I'll just have to remember to be in the Rescue system before updating uBoot.

Fyi:

ARMedSlack nanddump version:

root@pogo_162:~# nanddump --version
nanddump 1.4.6

root@pogo_162:~# nanddump --help
\Usage: nanddump [OPTIONS] MTD-device
Dumps the contents of a nand mtd partition.

           --help               Display this help and exit
           --version            Output version information and exit
           --bb=METHOD          Choose bad block handling method (see below).
-a         --forcebinary        Force printing of binary data to tty
-c         --canonicalprint     Print canonical Hex+ASCII dump
-f file    --file=file          Dump to file
-l length  --length=length      Length
-n         --noecc              Read without error correction
           --omitoob            Omit OOB data (default)
-o         --oob                Dump OOB data
-p         --prettyprint        Print nice (hexdump)
-q         --quiet              Don't display progress and status messages
-s addr    --startaddress=addr  Start address

--bb=METHOD, where METHOD can be `padbad', `dumpbad', or `skipbad':
    padbad:  dump flash data, substituting 0xFF for any bad blocks
    dumpbad: dump flash data, including any bad blocks
    skipbad: dump good data, completely skipping any bad blocks (default)

Rescue System nanddump version:

rescue:~# nanddump --version
nanddump $Revision: 1.29 $

rescue:~# nanddump
Usage: nanddump [OPTIONS] MTD-device
Dumps the contents of a nand mtd partition.

           --help               Display this help and exit
           --version            Output version information and exit
-f file    --file=file          Dump to file
-i         --ignoreerrors       Ignore errors
-l length  --length=length      Length
-n         --noecc              Read without error correction
-o         --omitoob            Omit oob data
-b         --omitbad            Omit bad blocks from the dump
-p         --prettyprint        Print nice (hexdump)
-q         --quiet              Don't display progress and status messages
-s addr    --startaddress=addr  Start address

Added info: Seems that the Rescue System nanddump behavior is depriciated:
http://git.infradead.org/mtd-utils.git/commit/40d253cb7b761de673877782f540aaed62bef86a



Edited 4 time(s). Last edit at 06/03/2012 04:01PM by laprjns.

Good to know - a change in behavior about something as important as mtd-utils.

I have rolled yet another revision of the Rescue System - and its mtd-utils (including nanddump, nandwrite, etc) are version 1.4.9.

This is a lot more up-to-date, but your experience underlines the importance of both keeping up with changes in code/apps, as well as being wary of new interactions/unforeseen variations in commands.

=====================================================

• davy's Github Repo's rescue-dg

I've updated the install script to work around the opposing behaviors of the different nanddump revisions. Thank you for tracking that down laprjns.

Just to verify, the suggested update method is to snag http://projects.doozan.com/uboot/install_uboot_mtd0.sh and let it do the dirty work? Will it preserve my bootenv or will I have to reset that info again?

@Jeff : The install script didn't preserve the ethernet mac address on the GoFlex Home. I had to manually set the ethaddr uboot variable to the correct value after installation. Without so, it used random mac ids and got a different IP each time it booted.

Will you please check what's the exact issue?

@ everyone, it is very importatnt to dump out your env (either as a file, or as text) and keep a copy of it.

Make sure you restore it before resetting or power cycling your Kirkwood device. A list (not exhaustive, just some that come to mind) of key crucial things to check on :

• ethaddr (MAC address)
• ipaddr
• serverip
• netconsole related variables/commands/values
• special custom values that you've changed to fit your own situation, such as commands and variables to handle SATA drives

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/04/2012 04:52PM by davygravy.

Or, when the installer says

Your current uBoot environment should be reasonable. However, if you're having
any probems booting, you can reset the environment variables to know good values.
Would you like to reset the uBoot environment? [N/y]

just say No (it's the default, you can just press enter.

Still, even if you say Yes, it should preserve your ethernet address. I'll look into that later when I have some time.

I can confirm the new uboot does not hang with my USB dock plugged in at power up any more on my GFN. Now if I can just figure out why 3.4 hangs at reboot... :D

Jeff Wrote:
-------------------------------------------------------
> I've updated the install script to work around the
> opposing behaviors of the different nanddump
> revisions.

And I can confirm that the updated script works with my ARMedSlack nanddump

## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0.

Thanks
Rich (laprjns)

Kurlon Wrote:
-------------------------------------------------------
> 1. I can confirm the new uboot does not hang with my
> USB dock plugged in at power up any more on my GFN.
>
> 2. Now if I can just figure out why 3.4 hangs
> at reboot... :D

1. That is great to hear. It seems that the culprit was almost assuredly related to the EFI/GPT feature. It may be messing up some timings. I will pass on what we've seen here to U-Boot mainline, so that developers are aware of it there and have a record of something to look for.

We will put up a special EFI/GPT + 64BIT-LBA enabled U-Boot for those who really need drives that are larger than 2.1GB. It will have to be a manual install, and we'll _warn_ them that USB seems to act less robustly.



2. Are you saying that your 3.4 boots but reboot does not behave has expected?
(FWIW, 3.4.1 is just out...)

=====================================================

• davy's Github Repo's rescue-dg

davygravy Wrote:
> 2. Are you saying that your 3.4 boots but
> reboot does not behave has
> expected?
> (FWIW, 3.4.1 is just out...)

Correct, runs beautifully, if I shutdown -h -P it powers down like I'd expect, but if I reboot it spits out "Restarting System.", turns the status LED off, and just sits there. I have to yank the power to get it to boot again. It was doing this with the earlier updated uboot also, so it's not a uboot regression that I'm aware of. I'll start a discussion thread for it somewhere else to see what can be figured out.

Right after I ram together a 3.5rc1 test kernel. :D

@ Kurlon: thank you for feedback etc. Much appreaciated.

I'm building 3.4.1 tonight and will check it out.

=====================================================

• davy's Github Repo's rescue-dg

@ davygravy
When you build 3.4.1 would you please include filesystem support for jfs?
Not as a Module I'd like to have my GoFlexNet boot from a jfs partition.

Thanks

kk, will do, if size permits and if it functions correctly. But have you tried ext4? I used to use jfs, but have been won over by it. Understood, if you have some preference or established need for it, though.

==============================

jfs support built-in... I may not be able to do this. To avoid breaking anything, I really try to keep to the exact debian profile/config. If you really need a kernel package, I can either build one for you, or walk you through the process.

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 06/04/2012 11:34PM by davygravy.

My GoFlexNet has been working so well...that I haven't been to this forum for what seems like over a year.
Thanks for the new uboot and kernel they work great!
I really like the jfs filesystem. If you post your .config .... like you did for the 3.3.2 build I'll build my own.
Which reminds me.....I should fit a heat sink on my cpu...gets warm when I work it hard.

@Jeff: I've checked the uBoot environment which I found here: https://github.com/doozan/uBoot/blob/10af78d93e0d22afabae9087ca0e3f6539f5e25a/environment/uboot.environment.txt

As far as I understand the following lines (posted by others in the forum) should be added/modified to enable booting from SATA drives:

sata_boot=ide reset; mw 0x800000 0 1; ext2load ide 0:1 0x800000 /boot/uImage; if ext2load ide 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
sata_bootcmd=run usb_set_bootargs; run sata_boot
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run sata_bootcmd; run rescue_bootcmd; run pogo_bootcmd; reset

My GoFlex Net works perfectly after I've manually changed the uBoot environment.

Thanks to everybody whose results like uBoot, kernel etc. I can use !

Klaus

Line 466 of the file http://projects.doozan.com/uboot/install_uboot_mtd0.sh is:

if [ "$UPDATE_UBBOT" = "0" ]; then

I suppose it should be:

if [ "$UPDATE_UBOOT" = "0" ]; then

Fixed! Thanks for spotting that.

Is this newer uboot install can be used to install >3.2 kernels?

It contains a bugfix that makes booting default config 3.2 kernels possible.

=====================================================

• davy's Github Repo's rescue-dg

@davygravy

Hi

Installed squeeze on my pogo plug (pink) v2 according to the instructions here

Changed sources.list to wheezy, did apt-get update, apt-get dist-upgrade. Unfortunately on reboot device hangs (fails to get a dhcp address), and I do have the latest uboot (used Jeff's boot updater script). I'm guessing the problem with 3.2 kernels and boot is not fixed, or is it the manner in which I carried out the dist-upgrade?

Sadly I don't have a serial hooked up to tell you any more.

I am trying again following the advice from cefn

spearfish Wrote:
-------------------------------------------------------
> @davygravy
>
> Hi
>
> Installed squeeze on my pogo plug (pink) v2
> according to the instructions
> here
>
>
> Changed sources.list to wheezy, did apt-get
> update, apt-get dist-upgrade. Unfortunately on
> reboot device hangs (fails to get a dhcp address),
> and I do have the latest uboot (used Jeff's boot
> updater script). I'm guessing the problem with
> 3.2 kernels and boot is not fixed, or is it the
> manner in which I carried out the dist-upgrade?
>
> Sadly I don't have a serial hooked up to tell you
> any more.
>
> I am trying again following the advice
> fro
> m cefn

Did you enable netconsole before you upgraded to Wheezy?

Did you upgrade to your U-Boot to handle the newer Debian kernel? Can you remember what kernel version it said you were upgrading to?

=====================================================

• davy's Github Repo's rescue-dg

OK I have got netconsole up and running. For info my uBoot is pinkpogo davygravy-2012-02-20-current (what Jeff's script picks up):

f you agree, type 'ok' and press ENTER to continue: ok
# checking for /usr/sbin/nandwrite...
# checking for /usr/sbin/nanddump...
# checking for /usr/sbin/flash_erase...
# checking for /usr/sbin/fw_printenv...
# checking for /etc/fw_env.config...

# 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 (50.116.34.13:80)
valid-uboot.md5      100% |*******************************|  1133  --:--:-- ETA
## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0.


You are already running the latest uBoot.
Your current uBoot environment should be reasonable.  However, if you're having
any probems booting, you can reset the environment variables to know good values

Will attempt to dist-upgrade to wheezy again and see what netconsole picks up.....

Well, that's strange.. on that dist-upgrade the kernel didn't upgrade to the 3.2.0-2 version.... anyway went ahead and installed davygravy's 3.3.2 kernel and it all works :)