Newer uBoot as workaround to 3.2 kernel problem? You can now upgrade your older U-Boot using [url=http://forum.doozan.com/read.php?3,6965,8189#msg-8189][b]Jeff's U-Boot Updater Script[/b][/url] ... [b][color=#FF0000]but first[/color][/b] : 1. You may want check that your [b]netconsole[/b] or [b]serial console[/b] connection is working correctly, just in case. 2. [b]Before[/b] upgrading your U-Boot, it is a good idea to print out your U-Boot env and keep a copy of it as a file. This is especially important if you have made even the slightest alteration to the stock env. [u]After the installer finishes running [b][color=#3300FF][i]but before you reboot[/i][/color][/b][/u], make sure you check that you have your original values... a few of the values might have to be restored. ... [i]and if you don't want to do it by an automated script[/i] ... [b]MANUAL Directions for Upgrading Your U-Boot are Below!![/b] Kernel 3.2.y introduced a default setting for the kernel that affects kirkwood machines in particular, because of an unintended u-boot behavior with regard to the Level2Cache and decompression of the kernel image. Call it a latent bug in u-boot, a regression in the kernel, or whatever... the defconfig kirkwood kernel build of 3.2.y (and by extension, higher versions) will fail to boot in most/many cases. This left us with the choice between: [list] [*] not being able to boot a stock/normal debootstrapped Wheezy install (which will have a 3.2 or 3.3 kernel), and [u]not being able to boot into future stock Debian Kirkwood kernels[/u], or [*] [u]creating updated u-boot[/u] binaries that use the already-tested L2CacheDisable patch from Michael Walle (thanks Mike!) to the newest stable u-boot so [u]that a normal default kernel will boot[/u]. [/list] Since the kernel is updated more often than u-boot, it seems like it would be more of a hassle to kludge around it and compile a "special flavor" kernel just for kirkwood users. Working together, a few of us have put together patches and some basic testing to come up with updated u-boot images. [i]A big thank you to Robert Mugabe and Pazos.[/i] Our criteria were simple: [list=1] [*] make it boot 3.2 kernels and higher, with default (non-expert) config settings, as well as the older 2.6 and pre-3.2 stock Debian kernels, [*] base it on the newest possible stable u-boot release, in order to make future adjustments easier, [*] make it a drop-in replacement, fitting the footprint of Jeff's (etal) u-boot builds, [*] allow the Pogoplug software/firmware to function normally if a bootable rootfs on USB or SATA is not found, just as with Jeff's [*] no new features that would change the profile and, use the same u-boot environment space and values in NAND [*] fix a bug on SATA machines where a drive was not recognized correctly [/list] In short, "Keep It Simple, Stupid!", as much as possible. We know that folks running ArchLinuxARM and others use the u-boot that is piped out of this site, and we want to to be a seamless change for them, as well. At the moment, the following machines seem pretty much taken care of: [list] [*] [b]Dockstar[/b] [*] [b]Pogoplug V1/E01[/b] {same u-boot as Dockstar} [*] [b]Pogoplug V2/E02[/b] [*] [b]GoFlex Net[/b] & [b]GoFlex Home[/b] [/list] [Pazos tells me that the stock u-boot on his Iomega iConnect seems to boot 3.2 and higher kernels just fine, so at the moment, there is no reason to build a newer u-boot for it.] =========================================================================================== =========================================================================================== [b][u]Manual Directions for upgrading the u-boot on your Dockstar, Pogoplug, or GoFlex Net/Home[/u][/b]: 0. By doing any of the steps below, [color=#FF9900]you agree to hold me blameless[/color]. I've flashed my devices w/ my u-boots quite a few times now, but there are no promises. If you make a mistake, or if the power to your Kirkwood device goes off/fails while you are flashing it, your device might be bricked, recoverable only by JTAG. You have been warned. You are nevertheless invited to continue, but only if you accept risk and responsibility. 1. Prepare your equipment, data files and your brain. a. Backup your data and any contents you wish to keep. b. Read through to the end, and make sure you understand each step, and how to recover in case of a bad erase. c. Print out the contents of your NAND U-Boot env variables to a text file, or use nanddump. In either case, note your MAC address (aka hardware address, or [b]ethaddr[/b]). Make a mental note to yourself and check that is unchanged after the upgrade process. [mine didn't change ever, but YMMV] 2. You should consider having a serial cable/adapter so that you can connect to your Pogoplug, Dockstar or other Kirkwood device, for emergency recovery. 3. Either enable netconsole and confirm its functionality, or use a serial cable/adapter, so that you can control u-boot on your Kirkwood device. Make sure you understand how netconsole works before venturing into this, also. 4. Set up a tftp server on your desktop/laptop/other-computer. Confirm that tftp transfers are working before flashing anything. 5. Based on which machine you have, download and [b]_[color=#CC0000]untar/gunzip[/color]_[/b] one of these uboot.mtd0.kwb binaries: [list] [*] for [b][color=#FF0066]Dockstar[/color][/b] and [b][color=#FF9900]Pogoplug V1/E01[/color][/b] [wallwart-ish] : [url=http://dl.dropbox.com/u/1015928/Kirkwood/uboot/newer-uboots-nonEFI_GPT-TESTED/uboot.mtd0.kwb-2011.12-dockstar-L2Coff.tar.gz]dockstar and Pogoplug V[b]1[/b]/E0[b]1[/b] u-boot replacement[/url] filename=uboot.mtd0.kwb-2011.12-dockstar-L2Coff.kwb [*] for [b][color=#00FF00]Pogoplug V2/E02[/color][/b] : [url=http://dl.dropbox.com/u/1015928/Kirkwood/uboot/newer-uboots-nonEFI_GPT-TESTED/uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff.tar.gz]Pogoplug V[b]2[/b]/E0[b]2[/b] u-boot replacement[/url] filename=uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff.kwb [*] for [b][color=#0000FF]GoFlex Net/Home[/color][/b] : [url=http://dl.dropbox.com/u/1015928/Kirkwood/uboot/newer-uboots-nonEFI_GPT-TESTED/uboot.mtd0.kwb-2011.12-goflexnet-L2Coff-IDEpatched.tar.gz]GoFlex[b]Net/Home[/b] u-boot replacement[/url] filename=uboot.mtd0.kwb-2011.12-goflexnet-L2Coff-IDEpatched.kwb [/list] Put the desired uboot binary in the root directory of your tftp server. [i]*These images are based on 2011.12 source code, have all Jeff's features and capabilities, will boot the newer 3.2 (& higher) kernel, and contain a few minor fixes. I'll post patches ASAP. I'd originally thought to rework the patches based on 2012.6-ish source, but no further crucial changes would result from waiting for this, so its time to finish this.[/i] 6. (Re)Boot your Kirkwood device. Assuming it has one of Jeff's u-boot builds in NAND, when it powers up, you will see something like: [code] U-Boot 2010.09 (Oct 23 2010 - 11:51:16) Marvell-PinkPogo by Jeff Doozan SoC: Kirkwood 88F6281_A0 DRAM: 256 MiB NAND: 128 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>> Marvell>> [/code] Press any key to stop the boot process. You may have to press the key several times, or even hold it down for several seconds. [b]a.[/b] Once you see the [b]Marvell>>[/b] prompt, check that you can pull in the image via tftp. Execute: [code] tftpboot 0x800000 [/code] where is taken from the matching filename above If this is successful, you should see something like this: [code] Marvell>> tftpboot 0x800000 uboot.pogoplugE02-arcNumfixed-L2Coff.kwb tftpboot 0x800000 uboot.pogoplugE02-arcNumfixed-L2Coff.kwb Using egiga0 device TFTP from server 192.168.11.149; our IP address is 192.168.11.150 Filename 'uboot.pogoplugE02-arcNumfixed-L2Coff.kwb'. Load address: 0x800000 Loading: #################################### done Bytes transferred = 524288 (80000 hex) [/code] The "Bytes transferred" value should be hex 80000 (decimal 524288) - if you don't get that value, then something is wrong. [b][color=#FF0000]STOP[/color][/b]: Before going further double or triple check to make sure you have selected the correct filename that corresponds with your Kirkwood machine [Dockstar, Pogoplug E02, GoFlex Net/Home]. Flashing the wrong file in your machine will possibly brick it. Double check before going further. The filenames [b]_must_ match[/b]. The "Bytes transferred" value [b]_must_ match[/b]. [color=#CC0000]If not, you should stop here and go no further.[/color] [b]b.[/b] Erase and flash; execute [code] nand erase 0x0 0x80000 nand write.e 0x800000 0x0 0x80000 [/code] If you have an erase/block problem, read through Jeff's original u-boot thread to see how people got around that problem. If the nand write went as planned, you should see something like this: [code] Marvell>> nand erase 0x0 0x80000 nand erase 0x0 0x80000 NAND erase: device 0 offset 0x0, size 0x80000 Erasing at 0x60000 -- 100% complete. OK Marvell>> nand write.e 0x800000 0x0 0x80000 nand write.e 0x800000 0x0 0x80000 NAND write: device 0 offset 0x0, size 0x80000 524288 bytes written: OK [/code] [b]c.[/b] If all is well, reset. [code] Marvell>> reset [/code] Your device should reboot now, but you will see newer uboot version information in the console or netconsole window: [code] 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 [/code] You will now be able to boot a stock Debian 3.2 (or higher) kernel without having the decompression error that would cause so many Kirkwood machines to hang at boot time. If you followed this howto command-for-command, you [i]should[/i] not have to alter or restore any u-boot env variables. Of course, YMMV. ========================================================================================= This makes it look more official: we might be SOL if the 3.2 regression is indeed handled as "really just a latent bug in uboot". http://thread.gmane.org/gmane.linux.ports.arm.kernel/127951/focus=151172 Is anyone game to apply the L2cache disable patch? It looks like it may become a necessary upgrade if users want to use the mainline kernel inthe future. =========================== Has anyone tried this relatively new uBoot on their Dockstar? It looks like it was rolled by tbm (@debian.org)... http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html Hmmmm... sounds like a familiar problem: http://www.plugcomputer.org/plugforum/index.php?topic=5897.0 https://forum.doozan.com/read.php?3,6965,6965#msg-6965 Thu, 12 Mar 2026 22:14:15 -0500 Phorum 5.2.23 https://forum.doozan.com/read.php?3,6965,17384#msg-17384 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,17384#msg-17384
Quote

After the installer finishes running but before you reboot, make sure you check that you have your original values... a few of the values might have to be restored.
]]> WarheadsSE uBoot Thu, 28 Aug 2014 15:08:48 -0500 https://forum.doozan.com/read.php?3,6965,17379#msg-17379 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,17379#msg-17379 -------------------------------------------------------
> This shit bricked my goflex home. I followed the
> instructions to a tee, and double checked
> everything. Stupid shit.

So it was "bricked" because it overwrote the uboot environment variables, which meant no more IP address and no more netcat configuration. I cracked the piece of shit open and connected a serial port to recover (though in hindsight a USB boot device would have worked).
With the environment fixed, at least now it boots the latest kernel. This stupid shitty cache bug has cost me lots of time. It's fucking preposterous to update the kernel and get no error message when it doesn't boot.]]> santiago uBoot Thu, 28 Aug 2014 02:05:07 -0500 https://forum.doozan.com/read.php?3,6965,17377#msg-17377 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,17377#msg-17377 santiago uBoot Wed, 27 Aug 2014 22:38:51 -0500 https://forum.doozan.com/read.php?3,6965,15079#msg-15079 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,15079#msg-15079 bodhi uBoot Wed, 12 Feb 2014 15:43:15 -0600 https://forum.doozan.com/read.php?3,6965,15074#msg-15074 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,15074#msg-15074
Looks like i bricked my PP E-02. No LED activity on board, no output to serial console.

Pogoplug V2/E02

Here are the steps i did:
during step 6.a) tftpboot 0x800000 <filename>, by mistake i copied the .tar.gx instead of the extracted .kwb file
and continued with the rest of the steps.

After the step c) reset, I couldn't notice any thing happening in the device.

1) IS IT BRICKED?
2) IS THERE A WAY I CAN BRING IT BACK TO LIFE?
3) WHAT ARE THE OPTIONS I DO HAVE TO BRING IT BACK TO LIFE, LIKE JTAG...?

Some body please share your thoughts.

thanks,
Jagan]]> kadimijagan uBoot Wed, 12 Feb 2014 09:51:02 -0600 https://forum.doozan.com/read.php?3,6965,14871#msg-14871 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,14871#msg-14871 but is probably my key...]]> rsuinux uBoot Fri, 24 Jan 2014 05:03:47 -0600 https://forum.doozan.com/read.php?3,6965,14870#msg-14870 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,14870#msg-14870 My boot is: 
dockstar -> [ in hardisk 2,5"] sda1 -> |/vmlinuz with link for /boot/vmlinuz-xxx 
                                                                |/initrd with link for /boot/initrd-xxx
                                                                |/boot/uImage
                                                                |/boot/uInitrd
                                                                |/.....
Currently, I create a usb key with a new squeeze, with dockstar.debian-squeeze.sh
This script has a small probleme: parameter debootstrap, --no-check-gpg stops. Removing this option is my solution (the best?)
At the end of the installation, I start on the key and then chroot my hard drive]]> rsuinux uBoot Fri, 24 Jan 2014 04:05:14 -0600 https://forum.doozan.com/read.php?3,6965,14868#msg-14868 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,14868#msg-14868 
e18a2c7e308c249bc16f55bbaad31f50 dockstar davygravy-2012-02-12-current

Next, the uboot does not load standard vmlinux-* or vmlinuz-* kernel files. It loads specially packaged versions called uImage and uInitrd version. You need to produce these.

I'm a little confused by your english. Do you have a booting system or not? Or is just booting into the wrong kernel and that is your problem? If its just the wrong kernel, then you have to general a new uImage and uInitrd from shyd's kernel with mkimage.

I would suggest you totally dump squeeze and go to wheezy using the rootfs image from here:
http://forum.doozan.com/read.php?2,12096

Write that to a USB stick and it will boot on your uboot, assuming you have the standard uboot environment. If it doesn't TTL serial the way to go forward. After it boots you can install the updated tld-5 kernel on top of it.

You can then mount your old stick, chroot to it, and get the package list from dpkg --list. Exit to get out the chroot and just install those packages.]]> kraqh3d uBoot Thu, 23 Jan 2014 18:03:16 -0600 https://forum.doozan.com/read.php?3,6965,14863#msg-14863 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,14863#msg-14863 (Sorry for my verry poor english).
I have dockstar, with debian lenny, and no problem. But there are some days, I go to upgrade to squeeze, and boom!
No boot in my new debian
My uboot is 
dmesg | grep Linux 
[    0.000000] Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) #57 Mon Aug 31 16:31:01 PDT 2009
and my arc number is 
fw_printenv | grep arc
arcNumber=2998
In my harddisk, the kernel is vmlinuz-3.1.10-dockstar-shyd

The upgrade with install_uboot_mtd0.sh doesn't work, with no error: my uboot is "already up to date" !
md5sum for the uboot-mtd0-dump is 
 
md5sum uboot-mtd0-dump 
e18a2c7e308c249bc16f55bbaad31f50  uboot-mtd0-dump

At this moment, I do not use usb to ttl cable during the boot. This cable it's in commande.

I have multiple questions:
My "uboot" is really up to date, or is it my "debian" that no longer works?
I'm desperate...

Rémi.]]> rsuinux uBoot Thu, 23 Jan 2014 10:50:17 -0600 https://forum.doozan.com/read.php?3,6965,12836#msg-12836 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12836#msg-12836 habibie uBoot Fri, 28 Jun 2013 09:20:58 -0500 https://forum.doozan.com/read.php?3,6965,12830#msg-12830 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12830#msg-12830 -------------------------------------------------------
> Thank you. But, that doesn't seem to support SATA
> on a GoFLEX NET device, or does it?

It does. Use the right SATA port.]]> bodhi uBoot Fri, 28 Jun 2013 00:19:14 -0500 https://forum.doozan.com/read.php?3,6965,12829#msg-12829 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12829#msg-12829 habibie uBoot Thu, 27 Jun 2013 17:53:44 -0500 https://forum.doozan.com/read.php?3,6965,12823#msg-12823 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12823#msg-12823 http://projects.doozan.com/uboot/]]> bodhi uBoot Wed, 26 Jun 2013 23:19:15 -0500 https://forum.doozan.com/read.php?3,6965,12821#msg-12821 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12821#msg-12821 habibie uBoot Wed, 26 Jun 2013 11:30:33 -0500 https://forum.doozan.com/read.php?3,6965,12423#msg-12423 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12423#msg-12423
No, it's not safe to update uBoot for your NSA320 using the offical script. Unless you have assurance from Davy that you can use this standard installation script. But I don't think it will work.]]> bodhi uBoot Fri, 10 May 2013 17:42:17 -0500 https://forum.doozan.com/read.php?3,6965,12421#msg-12421 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,12421#msg-12421
I am currently trying to get a Zyxel NSA320 up and running. Using davy's basic setup, I am able to boot from a USB-drive, but the exact same rootfs on the first SATA drive gives: 

U-Boot 2011.12 (May 03 2012 - 17:04:23)
ZyXEL NSA320 2-Bay Power Media Server
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  0 

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: Model: ST3320413AS  Firm: JC45 Ser#: Z2A84WH4
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
  Device 1: Model: ST3320413AS  Firm: JC66 Ser#: Z2AJ97AK
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
Loading file "/boot/uImage" from ide device 0:1 (hda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - ide 0:1 **
Loading file "/boot/uInitrd" from ide device 0:1 (hda1)
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - ide 0:1 **
Wrong Image Format for bootm command
Error occured, error code = 108
ERROR: can't get kernel image!

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: Model: ST3320413AS  Firm: JC45 Ser#: Z2A84WH4
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
  Device 1: Model: ST3320413AS  Firm: JC66 Ser#: Z2AJ97AK
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
** Bad partition 1 **
** Bad partition 1 **
Wrong Image Format for bootm command
Error occured, error code = 108
ERROR: can't get kernel image!

No I am wondering whether I can safely upgrade to the official uBoot. I am somewhat put off by its output: 

root@debian-kirkwood-wide:~# ./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.

It would be just great if this listed the Zyxel NSA3xy devices ...

So:

a) Is it safe to update uBoot? (my guess: yes, since otherwise davy's rescue system post would not make much sense, would it?)
b) Will that take care of the SATA boot problem?


Help, as always, greatly appreciated.

Cheers,

chessplayer]]> chessplayer uBoot Fri, 10 May 2013 17:16:06 -0500 https://forum.doozan.com/read.php?3,6965,11794#msg-11794 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11794#msg-11794
Everything back to normal now! :)]]> varkey uBoot Sun, 10 Mar 2013 09:24:50 -0500 https://forum.doozan.com/read.php?3,6965,11527#msg-11527 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11527#msg-11527 -------------------------------------------------------
> The Arch GoFlex instructions don't say to skip the
> uboot check anywhere that I've seen. Could you
> post a link to where you saw that bit?
>
> Davy, if you're respinning the uboot images, would
> you be up for doing some with Device Tree support
> enabled for testing?

Looking at kernel 3.6.x.x arch/arm/mach-kirkwood/, there is a mix of device tree implementation and old mach-types devices such as Dockstar and Sheevaplug. Would this new uBoot work with 3.6.x.x ?]]> bodhi uBoot Sat, 16 Feb 2013 16:30:01 -0600 https://forum.doozan.com/read.php?3,6965,11333#msg-11333 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11333#msg-11333
The fw_setenv machid dd6 statement is to correct an oversight in the current uBoot (Davy confirmed this). On Pogoplug E02, setting arcNumber to 3542 alone does not make uBoot pass along the archNumber to the kernel. So the work around is to also set machid explicitly using fw_setenv.

archNumber 3542 only works if you have a kernel with the Pogoplug E02 patch. If you have a vanilla kernel, then arcNumber must be set to 2097. So in this case, the HW is recognized as SheevaPlug Reference Board.

Yes, with arcNumber 2097, you can still control the LED, but as you've found, the LED does not turn green, and the control is limited. OTOH, if arcNumber is 3542, and the kernel supports it, then you can control the LED better (e.g. green, orange, blinking, and so on).

bodhi]]> bodhi uBoot Fri, 25 Jan 2013 08:41:13 -0600 https://forum.doozan.com/read.php?3,6965,11327#msg-11327 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11327#msg-11327
Unfortunately, for me, setting "machid=dd6" in the uBoot environment (with "archNumber=3542") did not work. It would act like it was booting, but wouldn't come up. (The front LED never illuminated after the uBoot passed control the the kernel.) I didn't investigate; I presume it had something to do with my using the 2.6 kernel instead of 3.2 and just deleted the machid setting from the environment.

However, for the record, could one of you explain what having "machid=dd6" set buys you? It looks to me like I'm still able to control the front LED -- turn it on and off -- even if the hardware is declared a SheevaPlug Reference Board. I can only turn it on as orange, but I think there is only an orange LED on the board, right?

So for now, I'm leaving the uBoot environment intact, but I now have two additional PogoPlugs ready to deploy if I need them. Thanks again for your help!]]> restamp uBoot Thu, 24 Jan 2013 18:09:11 -0600 https://forum.doozan.com/read.php?3,6965,11282#msg-11282 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11282#msg-11282 -------------------------------------------------------
> It's been a while since I've hacked on my arm
> hardware, but I still have a couple of pristine
> PogoPlug E02s which need to be jail broken and
> have their uBoot reflashed so that they can
> eventually become the backup hardware for when my
> existing servers bite the dust. I am wondering
> what is the latest uBoot that I should use for
> this purpose. I am still running Squeeze here,
> not Wheezy, so I need a uBoot which will boot
> Squeeze, but I'd prefer to install one which will
> handle Wheezy and the later kernels for when I
> eventually upgrade. Is the top post of this
> thread by davygravy still the best version and the
> one I should be using? I can use tftp to install
> it, as davygravy suggests, but I'd prefer to use
> an installer if one is available. (Fewer
> possibilities for cockpit errors.) So, can
> someone please point me to the latest and greatest
> uBoot and installer?
>
> Thanks in advance.

Welcome back restamp :) the latest uBoot has been incorporated to Jeff script. So you can just run http://projects.doozan.com/uboot/install_uboot_mtd0.sh to install uBoot only. It will boot Squeeze. Or you can run the completed http://projects.doozan.com/debian/dockstar.debian-squeeze.sh on your new Pogo E02 as before, to install both uBoot and Squeeze.

Also note that the machid for E02 was not set correctly in this uBoot version, so when you change arcNumber you should also change machid as described in a couple posts above.]]> bodhi uBoot Tue, 22 Jan 2013 22:41:52 -0600 https://forum.doozan.com/read.php?3,6965,11279#msg-11279 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11279#msg-11279 moonman uBoot Tue, 22 Jan 2013 17:45:20 -0600 https://forum.doozan.com/read.php?3,6965,11278#msg-11278 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11278#msg-11278
Thanks in advance.]]> restamp uBoot Tue, 22 Jan 2013 16:44:28 -0600 https://forum.doozan.com/read.php?3,6965,11178#msg-11178 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11178#msg-11178 moonman uBoot Wed, 16 Jan 2013 20:39:09 -0600 https://forum.doozan.com/read.php?3,6965,11171#msg-11171 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11171#msg-11171 -------------------------------------------------------
> I might have found an issue with this uBoot:
> Either there's something wrong with the kernel
> patch or uBoot doesn't pass proper arcNumber to
> the kernel on some devices. There's was a post in
> this where somebody could boot the kernel and the
> arcNumber wasn't what he set it to.
> In my case (and others over at archlinuxarm
> reported similar problems) Pogoplug E02 gets
> recognised as SheevaPlug Reference Board even
> though arcNumber is set properly
>
> 
> dmesg | grep Machine
> [    0.000000] Machine: Marvell SheevaPlug
> Reference Board
>
>
> 
> fw_printenv | grep arcNumber
> arcNumber=3542
>
>
> On my GoFlex Home, however everything is fine:
>
> 
> dmesg | grep Machine
> [    0.000000] Machine: Seagate GoFlex Home
>
>
> 
> fw_printenv | grep arcNumber
> arcNumber=3338
>
>
> I've noticed that right after upgrading uBoot a
> while ago LED was orange as though arcNumber was
> not set properly, even though with the older uBoot
> and the same kernel LED was green. I didn't really
> pay attention at the time though.
>
> Seeing how there are 2 different uBoot images for
> GoFlex and Pogoplug maybe something was forgotten
> in the Pogoplug version?

Yes. Davy was aware of this, as I recall, and had a patched uBoot version. The work around right now for Pogo E02 is to also set the machid to the appropriate number. I've posted this somewhere in this forum.

Addendum:

Try this: fw_setenv machid dd6]]> bodhi uBoot Wed, 16 Jan 2013 08:18:17 -0600 https://forum.doozan.com/read.php?3,6965,11170#msg-11170 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11170#msg-11170 Either there's something wrong with the kernel patch or uBoot doesn't pass proper arcNumber to the kernel on some devices. There's was a post in this where somebody could boot the kernel and the arcNumber wasn't what he set it to.
In my case (and others over at archlinuxarm reported similar problems) Pogoplug E02 gets recognised as SheevaPlug Reference Board even though arcNumber is set properly 

dmesg | grep Machine
[    0.000000] Machine: Marvell SheevaPlug Reference Board

fw_printenv | grep arcNumber
arcNumber=3542

On my GoFlex Home, however everything is fine: 

dmesg | grep Machine
[    0.000000] Machine: Seagate GoFlex Home

fw_printenv | grep arcNumber
arcNumber=3338

I've noticed that right after upgrading uBoot a while ago LED was orange as though arcNumber was not set properly, even though with the older uBoot and the same kernel LED was green. I didn't really pay attention at the time though.

Seeing how there are 2 different uBoot images for GoFlex and Pogoplug maybe something was forgotten in the Pogoplug version?]]> moonman uBoot Wed, 16 Jan 2013 06:22:50 -0600 https://forum.doozan.com/read.php?3,6965,11169#msg-11169 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11169#msg-11169 -------------------------------------------------------
> The Arch GoFlex instructions don't say to skip the
> uboot check anywhere that I've seen. Could you
> post a link to where you saw that bit?

He probably meant this: http://archlinuxarm.org/forum/viewtopic.php?f=18&t=3355]]> moonman uBoot Wed, 16 Jan 2013 06:14:54 -0600 https://forum.doozan.com/read.php?3,6965,11025#msg-11025 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11025#msg-11025
Davy, if you're respinning the uboot images, would you be up for doing some with Device Tree support enabled for testing?]]> Kurlon uBoot Mon, 31 Dec 2012 08:24:49 -0600 https://forum.doozan.com/read.php?3,6965,11024#msg-11024 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11024#msg-11024
Linux version 3.6.10-1-ARCH (nobody@panda2) (gcc version 4.7.2 (GCC)
#1 PREEMPT Wed Dec 12 15:26:33 UTC 2012

http://tafb.yi.org

-Jamie M.]]> toysareforboys uBoot Mon, 31 Dec 2012 02:34:10 -0600 https://forum.doozan.com/read.php?3,6965,11023#msg-11023 Re: Newer uBoot as workaround to 3.2 kernel problem? https://forum.doozan.com/read.php?3,6965,11023#msg-11023 -------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > @Ron,
> >
> > It's unusual that your prompt is "ubit0-6:".
> Did
> > you run installation script from Pogoplug stock
> OS
> > ? how did you begin? Booting without USB, loged
> in
> > with SSH? ....
> >
> > Also, why did you use the option
> > "--no-uboot-check"? what happened before that
> > caused you've decided to run the installation
> with
> > this option? Normally, this option is not
> needed.
> --------
> My Seagate GoFlex Home is freshly done from these
> instructions, installing ubit 0.6, etc. etc:
> http://archlinuxarm.org/platforms/armv5/seagate-go
> flex-home#qt-platform_tabs-ui-tabs3
>
> To install the new uboot script, it said you had
> to use --no-uboot-check
>
> -Jamie M.

Ah! you don't really need to install uBit. Installing uBoot will make it a little more straight forward, and works with both Debian and Arch (However, uBit should work, too). But not too many people run that to install Debian. We usually just run the install_uboot_mtd right from the stock Pogo OS.

Can you try to boot back to stock Pogo and run uBoot installation script from there. These errors should not happen (it indicates that the sed and head commands could not be found in the OS where you run installation): 

./install_uboot_mtd0.sh: line 342: head: not found
./install_uboot_mtd0.sh: line 342: sed: not found
]]> bodhi uBoot Mon, 31 Dec 2012 02:29:36 -0600