Newer uBoot as workaround to 3.2 kernel problem?

Got the new uBoot installed, but now I can't fire up any of my archlinux media. I suspect I typo'd something when recreating the env. I have working netconsole access, and tftload functionality in uBoot. Whenever I try to launch a kernel all life stops at "Starting kernel ..." with no signs of activity after, including zilch from the NIC watching with tcpdump. Any suggestions on how to proceed or recover?

Well, I think your suspicion about the env could be right. (as I've run this U-Boot with various builds, distros and tarballs, I don't think the problem is w/ the U-Boot itself...)

Two thoughts:

My first guess would be to check the usb_rootfs_type value. What was it before the flash? How is it now defined? (perhaps restored to ext2 when putting in the new U-Boot ...)

A broader approach would be to print out the env and post it here (though you need to XXXX out your MAC/ethaddr). Someone here or from the ALARM side may see the problem.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 05/29/2012 09:52PM by davygravy.

Seems whatI'm missing is hd_args_0 and hd_args_1 and I can't seem to set them correctly from uboot.

What I had before:

hd_args_0=boot_dev='ide 0:1'; dev_args='root=/dev/sda1'
hd_args_1=boot_dev='ide 1:1'; dev_args='root=/dev/sdb1'

I can't seem to coax setenv to get those internal apostrophes to stick.

Edit: With a lil manual coaxing, I have it booting now. It's even booting my 3.4 test kernel which is an added bonus. Now I just have to beat on it a bit more to get autobooting working. I'll get my env posted up shortly.



Edited 1 time(s). Last edit at 05/29/2012 10:44PM by Kurlon.

Good to hear that it's booting for you.

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

• davy's Github Repo's rescue-dg

http://pastie.org/3998285

So this is my current stumbling block. If I plug in my Kensington dock and power up the GFN, I get the EHCI time out and then it hangs at scanning the bus.

The dock is a bit of a PITA as the displaylink device in it initially comes up looking like a mass storage device. With Jeff's original u-boot and the arch env the scan would complete, it would then try to boot off the fake mass storage device and hang there instead. My intended work around was to alter the boot order to try from SATA first which I've now done, but it seems the new u-boot REALLY doesn't like my dock.

The dock in question is a K33926, http://www.kensington.com/kensington/us/us/p/1421/K33926US/universal-docking-station-with-video-and-ethernet-sd400v.aspx

Any suggestions on how to bodge around this?

It is clear that it doesn't like your USB on the Kensington.

For myself, I can say that my usb hub here seems to work OK (usually) but there is something in the timings that sometimes causes a hickup. Is there anyway you can change the placemnt of the usb cords... ie. change the topology of the connections?

Other ideas: introduce a wait/pause before starting USB...???

FWIW, the second (pinned) thread in the Debian subforum is a thread dedicated SOLELY to finding and reporting USB flash drives that worked properly w/ UBoot. About a year or so ago they made achange that seemed to fix this, at least for USB flash drives... but maybe your Kensington device has some different odd timeing.

Has anyone at ALARM worked through this problem?

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/01/2012 06:46AM by davygravy.

Unfortunately because the GFN only has one USB port, I'm limited in how I can setup the topology. GFN to dock, my keyboard and wifi adapter hang off the dock's hub, as do the dock's sound, video (mass storage till you change it's profile number), and ethernet interface.

I think I'm the only nutball foolish enough to try using a GFN as a full workstation, I don't know as any of the ALARM crew have any displaylink adapters.

I've been testing these out for incorporation into the installer and I'm seeing a similar hang when trying to boot with a SanDisk Cruzer micro drive attached:

scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices...

The same thing happens on both a GoflexHome and on a Dockstar.

Here's the drive info:

USB device found, idVendor=0781, idProduct=5406
USB device strings: Mfr=1, Product=2, SerialNumber=3
Product: U3 Cruzer Micro
Manufacturer: SanDisk Corporation

Other flash drives work as expected, and the Cruzer works fine with the older uboot images.

Any thoughts?



Edited 1 time(s). Last edit at 05/31/2012 08:03AM by Jeff.

@ both Jeff and Kurlon : when you say "hang", do you see any output whatsoever on netconsole? Is there no timeout message?

@ Kurlon: Are there multiple USB ports on the Kensington? If so, have you tried different combinations of placements of items on that?

Quote
Jeff
Other flash drives work as expected, and the Cruzer works fine with the older uboot images.

Jeff: do you mean "Other drives & Cruzer work as expected on the older uboot images." Or do you mean that "Other drives work as expected w/ the newer images, but the Cruzer only works w/ the older images"?

Quote
Jeff
Any thoughts?

Yes, several:
1. These two changes may be related, but I'm not 100% sure.
http://lists.denx.de/pipermail/u-boot/2011-August/097948.html
http://lists.denx.de/pipermail/u-boot/2011-February/087043.html
These show some changes in delays for reading USB Mass Storage. Is there a longer lag time when your USB devices are recognized and mounted on either your computer or your Kensington hub?

We could try increasing the delays (say doubling them...) just a wild guess.


2. I've tried it here w/ 4 different flash drives: Sandisk Cruzer Micro 8GB (thin, low-profile model), Sandisk Cruzer 8GB (a larger, kind of clunker profile), Kingston 8GB DataTraveler, and a very old 1GB that I can find no name or identification on. I can only reproduce a problem on the old 1GB drive:

pogoE02> 
U-Boot 2011.12 (May 28 2012 - 11:59:39)
Pogoplug E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
pogoE02> usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... EHCI timed out on TD - token=0x80008c80
1 Storage Device(s) found
pogoE02> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller 
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 -  USB2.0 Hub 
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x05e3  Product 0x0608 Version 9.1
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - Generic Mass Storage Device MSU3JY4T
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x058f  Product 0x6387 Version 1.66
   Configuration: 1
   - Interfaces: 1 Bus Powered 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 Out Bulk MaxPacket 512
     - Endpoint 2 In Bulk MaxPacket 512

TBH, the older drive may actually be faulty (I'd had it in my desk for the last 5 years : it was a USB/Hacking drive for our XBOX original onto which we put XBMC... I'm thinking that it has a weird proprietary XBOX (original) format on it... so this may not be a good "negative" data point.

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

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 05/31/2012 05:22PM by davygravy.

In my case, no further output, no other signs of activity or life after 'scanning for storage devices...'

The dock has 5 USB ports off it's internal hub, my keyboard has it's own hub with two more ports. I've tried booting booting with just the wifi or keyboard plugged into the GFN, no issues. Any combination of devices off the dock results in the same hang if it's plugged into the GFN while uboot does it's initial scan. If I plug in after that uboot continues on to autoboot without issue.

I've got the parts to setup a serial port on the GFN, a friend has a ttl converter, so I'll be able to get better diag info soon.

@ Kurlon : is it possible to try : GFN<--> Keyboard'sBuiltInHub<--->Kensington + Mouse + Wireless ?

Is it possible that there is a cable somewhere that is of possible-less-than-optimal-quality?

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

• davy's Github Repo's rescue-dg

I can give it a try, although that will introduce new issues with the displaylink interface down the line as the keyboard's hub is only 1.1 and udlfb doesn't like usb 1.1. :D The cables are new, once fired up I'm saturating the usb bus fairly constantly doing video over the link with no errors that I can see. I'll have to poke to see if there are any error counters hiding in /proc somewhere.

Nope, no timeout (or, at least, none within 5 minutes at which point I reset the device)

I meant "Other drives & Cruzer work as expected on the older uboot images" ie: all drives work on the old images, and all drives except the cruzer work on the new image.

The Cruzer drive is an older 2 GB drive. I'd be more than happy to drop it in an envelope and send it to you, if you want want to try debugging this hands on. I don't think we should have any workarounds specifically to support my 2GB Cruzer Micro drives, but I do think it's a regression and I don't want any uBoot upgrades to break existing hardware configurations.

I should diff (2011.12 vs 2010.08-or_whatever_you_used_Jeff) the include/usb* files.

Quote
Jeff
... but I do think it's a regression and I don't want any uBoot upgrades to break existing hardware configurations.

Well, if it is a regression, then its a mainline regression, not a local-flavored one, as we haven't touched any usb-related code.
BTW Jeff, in reading through some of the first chaff to fly as I googled 'usb u-boot hub' and a few other relatives, I found this and other similar stories. http://lists.denx.de/pipermail/u-boot/2010-September/077746.html

Zundels comment about the words "USB" and "robust" not belonging in the same sentence together may seem an exaggeration. But underneath it does have an objective core of validity. Zundel and Denk are the two top people at U-Boot, IIUC.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 05/31/2012 09:39PM by davygravy.

TBH, after actually sitting down to read/scan all 124 reports here http://forum.doozan.com/read.php?2,1915 it looks like this is a persistent, longstanding and widespread problem. Not enough to call the CDC but at least enough to warrant 5 pages of reports.

Those two patches applied in 2011 may have helped some machines/devices with timing problems yet worsened it for others.
I'm not confident that trying to debug it now would make more sense than it did back in 2010 when the thread started, Jeff.

What I can offer to do is to compile 2 more versions: one with just the first USB patch from 2011, and another with neither USB patch from 2011.

The current Newer UBoot images I have posted have -both- USB patches applied to them.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 05/31/2012 10:06PM by davygravy.

I am more than happy to test as many images as you're willing to build. I think the new builds are great and I'm eager to roll them out.

I'm just worried about those users who have working devices that could end up with non-working devices after an upgrade. The upgrade instructions you've posted require netconsole/serial access which is great because it means anyone who ends up with a 'hanging' device can see what's happening. The upgrade script doesn't assume console access, which means we would need a big warning saying "Not all USB devices that worked with the old uBoot work with the newer uBoot. Before upgrading, please test that your device boots *without* a USB device attached. You may also want to take this opportunity to setup netconsole access." That way if USB breaks, they should still be left with a means of accessing their system and possibly configuring netconsole or installing an alternative-USB patched image.

ack!

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

• davy's Github Repo's rescue-dg

@ Jeff & Kurlon:

If you follow link 5 in my sig: Kirkwood Downloads > uboot > images-without-BulkUSBTimingPatch you should find images that you can try. Use w/ caution : I've tried the PogoPlug one & it works on all my USB drives as well as the previous one (based on straight 2011.12), except that it _doesn't_ work with my USB hub.

But Kurlon, it really sounds like the function of your Kensington's hub might actually be a "lucky fluke". The way you say that it recognizes it as a mass storage device. I've not had a chance to try the goflexnet image. In any event, I hope it will work for you.

I'll try to put a Dockstar image (w/o the BulkUSBTimingPatch) in that same dir, also. Directions for flashing it are the same as any other image.

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

• davy's Github Repo's rescue-dg

I'll give it a go Monday as my setup is at work, suspect it'll balk as it always shows as a hub, it's just the video device off the hub that starts off identifying as a mass storage device... really annoying design unless you're running Windows really.

Oh, I now have serial access too so I'll be able to capture better debug info now.

Here's the results of my testing on the GoFlex:

uboot.goflexNetHome-IDEfixed-L2Coff-EFIon = Cruzer does not work, other drives OK
uboot.goflexnet-IDEfixed-L2Coff-EFIon-NoUSBBulkStorPatch = Cruzer does not work, other drives OK
uboot.goflexnet-IDEpatched-arcNumOK = All drives OK

Thanks Jeff. You know, this makes me suspicious*** of the EFI partition setting. I enabled this to allow folks to use GPT/EFI partitions so that drives larger than 2TB could be handled transparently. It has apparently been in stable for about 4 years, but interestingly enough, there are very few users in mainline Kirkwood that have it enabled by default (IIRC, some of the Keymile boards use it). Maybe it has some sort of (latent/unnoticed) problem.

In my Kirkwood->UBoot dir there is a subdir w/ _non_GPT/EFI friendly UBoot images [these images have been tested for 3 or 4 months ]. It looks like you have tried the the whole lot - all three subflavors for GoFlexNet.

If the other two main machine types (Dockstar and PogoE02) show the exact same behavior (favoring the non_EFI-GPT friendly images), we could just leave the non_EFI ones as the default images, and if a user really needed the GPT/EFI version, they could easily install that on their own manually.

***Actually, I'm a bit shocked. The three GoFlexNet images are from the same source, same compiler (CS arm 2009.q3, IIRC). This is very strange. TBH, if the other two boards show the same behavior, then it certainly deserves bringing up the subject on the UBoot mailing list, as there would almost certainly be a problem/bug. Maybe there is some interaction between USB and EFI that is not understood?

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/02/2012 12:49PM by davygravy.

I'm seeing the some results on a Dockstar (I don't have a pogo v2 to test with):

uboot.dockstar-L2Coff-EFIon-NoUSBBulkStorPatch = Cruzer does not work, other drives OK
uboot.dockstar-L2Coff-EFIon = Cruzer does not work, other drives OK
uboot.mtd0.kwb-2011.12-Dockstar-L2Cdisabled-davysconfig = All drives OK

From what you've said this certainly looks like something weird caused by the EFI patch, which we can just leave out for most users and let those lucky enough to need GPT/EFI support install the other version at their own risk.

Yes, that sounds fine. In addition, I've just discovered a (rather dunderheaded) shortcoming (I failed to set CONFIG_64BIT_LBA) on my config for the EFI images - so I'm pulling/hiding them immediately. I'll re-link the previous "Newer U-Boot Images" - the ones that have been tested since February and show best function in your tests - later this afternoon.

I'd rather not do any advertising about support for drives of size greater than 2.1TB or GPT/EFI until I can get a 3TB drive and actually monkey w/ it, and test it for a few months. (... will go back and expunge any of my talk/comments about it as well...) In an effort to get more understanding about this, I've put in another request for first-hand experience/information regarding EFI on Kirkwood, as well as on 64BIT. I heard very little back from anyone the previous request, but maybe something will turn up this time.

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

• davy's Github Repo's rescue-dg

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

It's official, Davy's images are the new default!

Anyone using older uboot images can safely upgrade using the uBoot install script:

cd /tmp
wget http://projects.doozan.com/uboot/install_uboot_mtd0.sh
chmod +x install_uboot_mtd0.sh
./install_uboot_mtd0.sh

Thank you for all the effort you've put into this, Davy!

I just tried to run this script on my working dockstar, originally installed with slyd's scripts.

It will not boot into Debian nor the built in dockstar OS. I have a Sandisk Cruser Edge 4G USB if that matters. I did this because I wanted to install a newer version of debian then the 2.6.x.x that is installed.

Here is the log:

root@dockstar-db:/tmp# wget http://projects.doozan.com/uboot/install_uboot_mtd0.sh
--2012-06-02 21:15:20--  http://projects.doozan.com/uboot/install_uboot_mtd0.sh
Resolving projects.doozan.com... 50.116.34.13
Connecting to projects.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 18362 (18K) [text/x-sh]
Saving to: `install_uboot_mtd0.sh'

100%[======================================>] 18,362      --.-K/s   in 0.08s

2012-06-02 21:15:20 (227 KB/s) - `install_uboot_mtd0.sh' saved [18362/18362]

root@dockstar-db:/tmp# chmod +x install_uboot_mtd0.sh
root@dockstar-db:/tmp# ./install_uboot_mtd0.sh


!!!!!!  DANGER DANGER DANGER DANGER DANGER DANGER  !!!!!!

If you lose power to your device while running this script,
it could be left in an unusable state.

This script will replace the bootloader on /dev/mtd0.

This installer will only work on the following devices:
 Seagate Dockstar
 Seagate GoFlex Net
 Seagate GoFlex Home
 Pogoplug v1
 Pogoplug Pink (v2)
Do not run this installer on any other device.

By typing ok, you agree to assume all liabilities and risks
associated with running this installer.

If you agree, type 'ok' and press ENTER to continue: ok
# checking for /usr/sbin/nandwrite...

# Installing /usr/sbin/nandwrite...
--2012-06-02 21:15:53--  http://download.doozan.com/uboot/nandwrite.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/usr/sbin/nandwrite.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:15:54 (1.18 MB/s) - `/usr/sbin/nandwrite.md5' saved [32]

--2012-06-02 21:15:54--  http://download.doozan.com/uboot/nandwrite
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11500 (11K) []
Saving to: `/usr/sbin/nandwrite'

100%[======================================>] 11,500      --.-K/s   in 0.04s

2012-06-02 21:15:54 (252 KB/s) - `/usr/sbin/nandwrite' saved [11500/11500]

# Successfully installed /usr/sbin/nandwrite.
# checking for /usr/sbin/nanddump...

# Installing /usr/sbin/nanddump...
--2012-06-02 21:15:54--  http://download.doozan.com/uboot/nanddump.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/usr/sbin/nanddump.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:15:55 (1.14 MB/s) - `/usr/sbin/nanddump.md5' saved [32]

--2012-06-02 21:15:55--  http://download.doozan.com/uboot/nanddump
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21286 (21K) []
Saving to: `/usr/sbin/nanddump'

100%[======================================>] 21,286      --.-K/s   in 0.08s

2012-06-02 21:15:55 (249 KB/s) - `/usr/sbin/nanddump' saved [21286/21286]

# Successfully installed /usr/sbin/nanddump.
# checking for /usr/sbin/flash_erase...

# Installing /usr/sbin/flash_erase...
--2012-06-02 21:15:55--  http://download.doozan.com/uboot/flash_erase.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/usr/sbin/flash_erase.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:15:55 (1.22 MB/s) - `/usr/sbin/flash_erase.md5' saved [32]

--2012-06-02 21:15:55--  http://download.doozan.com/uboot/flash_erase
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12819 (13K) []
Saving to: `/usr/sbin/flash_erase'

100%[======================================>] 12,819      --.-K/s   in 0.04s

2012-06-02 21:15:55 (292 KB/s) - `/usr/sbin/flash_erase' saved [12819/12819]

# Successfully installed /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...
--2012-06-02 21:15:55--  http://jeff.doozan.com/uboot/valid-uboot.md5
Resolving jeff.doozan.com... 50.116.34.13
Connecting to jeff.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://projects.doozan.com/uboot/valid-uboot.md5 [following]
--2012-06-02 21:15:56--  http://projects.doozan.com/uboot/valid-uboot.md5
Resolving projects.doozan.com... 50.116.34.13
Connecting to projects.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1133 (1.1K) [text/plain]
Saving to: `/tmp/valid-uboot.md5'

100%[======================================>] 1,133       --.-K/s   in 0s

2012-06-02 21:15:56 (32.5 MB/s) - `/tmp/valid-uboot.md5' saved [1133/1133]

## Valid uBoot detected: [dockstar jeff-2010-10-23]

# Installing uBoot
## Installing dockstar davygravy-2012-02-12
--2012-06-02 21:15:56--  http://download.doozan.com/uboot/files/uboot/uboot.mtd0.dockstar.davygravy-2012-02-12.kwb.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/tmp/uboot.mtd0.kwb.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:15:56 (1.13 MB/s) - `/tmp/uboot.mtd0.kwb.md5' saved [32]

--2012-06-02 21:15:56--  http://download.doozan.com/uboot/files/uboot/uboot.mtd0.dockstar.davygravy-2012-02-12.kwb
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 524288 (512K) []
Saving to: `/tmp/uboot.mtd0.kwb'

100%[======================================>] 524,288      799K/s   in 0.6s

2012-06-02 21:15:57 (799 KB/s) - `/tmp/uboot.mtd0.kwb' saved [524288/524288]

Erase Total 4 Units
Performing Flash Erase of length 131072 at offset 0x60000 done
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
## Verifying new uBoot...
--2012-06-02 21:15:57--  http://download.doozan.com/uboot/files/uboot/uboot.mtd0.dockstar.davygravy-2012-02-12.kwb.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/tmp/uboot.mtd0.kwb.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:15:57 (1.14 MB/s) - `/tmp/uboot.mtd0.kwb.md5' saved [32]

# Verified successfully!


You are already running a modern 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.
Would you like to reset the uBoot environment? [N/y] y

# Installing uBoot environment
--2012-06-02 21:16:34--  http://download.doozan.com/uboot/files/environment/uboot.environment.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/tmp/uboot.environment.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:16:34 (1.16 MB/s) - `/tmp/uboot.environment.md5' saved [32]

--2012-06-02 21:16:34--  http://download.doozan.com/uboot/files/environment/uboot.environment
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 131072 (128K) []
Saving to: `/tmp/uboot.environment'

100%[======================================>] 131,072      446K/s   in 0.3s

2012-06-02 21:16:35 (446 KB/s) - `/tmp/uboot.environment' saved [131072/131072]

Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done
Writing data to block 6 at offset 0xc0000

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
--2012-06-02 21:16:35--  http://download.doozan.com/uboot/files/environment/uboot.environment.md5
Resolving download.doozan.com... 50.116.34.13
Connecting to download.doozan.com|50.116.34.13|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/tmp/uboot.environment.md5'

    [ <=>                                   ] 32          --.-K/s   in 0s

2012-06-02 21:16:35 (1.19 MB/s) - `/tmp/uboot.environment.md5' saved [32]


# uBoot installation has completed successfully.
root@dockstar-db:/tmp# reboot

It never came back from the reboot. I will put a serial cable on this and fix it, but wanted to let you know I had this problem.

I just gave the installer a try with a Pogo P21 (E02) and ran into a problem. Here's where I started

1)Pogo P21 (EO2) running ARMedSlack
2)Already had Davys' uboot installed (uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff)using the method in the first post of this thread.

Ran the installer, typed in "ok" and it came back "unknown uBoot detected on mtd0. Reran with "--no-uboot-check" and selected 5 "Pogoplug V2 Pink" and got:

##
##
## VERIFICATION FAILED!
##
## uBoot was not properly installed to mtd0.
##
##
## YOUR DEVICE MAY BE IN AN UNUSABLE STATE.
## DO NOT REBOOT OR POWER OFF YOUR DEVICE
##
##
## Make a backup of /tmp/uboot-mtd0-dump someplace safe and
## then re-run this installer.

I backed up the dump and reran the installer several times with the same results. I then manually check the checksum on the file that was dumped and got "42ead564226458d558d29ab38c0b44cc", which obviously is different than what is listed in the valid-uboot.md5 file (e84a5fd0a0205bb79aed07c3c6fbd145). I then reflash uboot using flash_erase and flashwrite using the arguments that are in the installer script and using "uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff" file to fash.

flash_erase /dev/mtd0 0 4
nandwrite /dev/mtd0 uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff

Everything look like it worked so I then tried a nandump, again using the arguments from the installer script.

nanddump -no -l 0x80000 -f /tmp/richl /dev/mtd0

Doing a md5sum check on this dump (richl), I got the same "wrong" checksum (42ead564226458d558d29ab38c0b44cc). So after seeing this I started playing around with the nandump arguments and finally after running:

nanddump -n -l 0x80000 -f /tmp/richl /dev/mtd0

and doing a md5sum on the resulting file i got the correct checksum (e84a5fd0a0205bb79aed07c3c6fbd145).
Just to check I edited the installer script changing the nandump lines to delete the "o" argument, reran the script and got:
## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0

So there it sits. I think the uboot is ok but I'll wait until I hear back before rebooting.

laprjns Wrote:
-------------------------------------------------------
> I just gave the installer a try with a Pogo P21
> (E02) and ran into a problem. Here's where I
> started
>
> 1)Pogo P21 (EO2) running ARMedSlack
> 2)Already had Davys' uboot installed
> (uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff)using the
> method in the first post of this thread.
>
laprjns, thank you for testing...

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.

I can tell you that I just did a run of the installer on my own Pogoplug E02 using the --no-uboot-check option and it worked flawlessly. That is, I _forced_ it to install the new "current" uboot over a newer/experimental one that I had installed locally. The U-Boot Installer Script worked great.

I will also run the same on my Dockstar and GoFlex Home (again, again).
---------------------------------------
FOLLOWUP(S):
Ran it on my Dockstar : successful ... you may want to double check your env variables. That is to say, before you run the installer, print out your env, and keep a record of it. In particular, if you made any network related adjustments, such as enabling Netconsole, then you may have to re-enable it after the U-Boot (re)install.

root@AirDisk2:/tmp# fw_setenv if_netconsole 'ping $serverip'
root@AirDisk2:/tmp# fw_setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;'
root@AirDisk2:/tmp# fw_setenv preboot 'run if_netconsole start_netconsole'
root@AirDisk2:/tmp# fw_printenv serverip                                  
## Error: "serverip" not defined
root@AirDisk2:/tmp# fw_setenv serverip 192.168.11.yyy
root@AirDisk2:/tmp# fw_setenv ipaddr 192.168.11.xxx

did the trick for me, back in business with nary a slip.

.............................

Ran it on my GoFlexHome : successful ... make sure you double/triple check any env value that you have to re-enter/re-establish... I did print out my env for safe keeping... a few non-standard lines that I had written in seemed to be gone... but I made a typo or two when re-entering them, and thought something had broken or that I had semi-bricked my box. This was not the case, just typos.

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

• davy's Github Repo's rescue-dg

Edited 6 time(s). Last edit at 06/03/2012 12:05AM by davygravy.

Well, upon hooking up a serial cable I see it does in fact boot. Unfortunately it does not get an IP address. See what I can do with this.

Check your ethaddr/MAC address. That needs to be correctly defined.

There is nothing in the U-Boot code that should influence this... but it could be that something in env got clobbered.

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

• davy's Github Repo's rescue-dg

IT has been doing various odd things as it boots and fails. sometimes assigning a dummy IP.. sometimes hanging. BUt his last time it did something telling.

Configuring network interfaces...err, eth0: dhcpcd already running on pid 397 (/var/run/dhcpcd-eth0.pid)
Failed to bring up eth0.
done.

I would imagine that should not be happening.