Newer uBoot as workaround to 3.2 kernel problem?

The first line in the first post gives you thelink to the script. This is the lates uBoot.

restamp Wrote:
-------------------------------------------------------
> 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.

Thanks for your help, moonman and bodhi. Based on your reports and suggestions, I used Jeff's install script and it worked like a champ. (I suppose I ought rightly tip my hat to davygravy and Jeff at this point, too!)

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,

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

Kurlon Wrote:
-------------------------------------------------------
> 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 ?

For some reason my uBoot got corrupted and wasn't booting properly. Ran Jeff's uBoot updater script and as expected showed an invalid MD5SUM, so ran the script with no-uboot-check and it installed the latest uBoot without any issues.

Everything back to normal now! :)

Hi guys,

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

---
Standart ist der Standardfehler

chessplayer,

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
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/10/2013 05:43PM by bodhi.

What is the latest version of u-boot for a Seagate Dockstar and GoFLEX NET? Where can I download them?

http://projects.doozan.com/uboot/

Thank you. But, that doesn't seem to support SATA on a GoFLEX NET device, or does it?

habibie Wrote:
-------------------------------------------------------
> 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
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thank you.

Hello All,
(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.

That's not your uboot. It's your kernel and it looks like a squeeze kernel since a 2.6 version, not shyd's 3.1.10. The uboot is the hardware boot loader. If the script says you have the latest uboot, then you have the latest uboot. It checks by copying it off nand and doing an md5sum. Based off your md5sum, you have this uboot which is the latest for the Dockstar. It's what I'm running.

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.



Edited 2 time(s). Last edit at 01/23/2014 06:04PM by kraqh3d.

Thank your for your reply.
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

and, my key dont boot :(
but is probably my key...

Hi All,

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

With the PogoE02, the only way to recover from this is JTAG.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

This shit bricked my goflex home. I followed the instructions to a tee, and double checked everything. Stupid shit.

santiago Wrote:
-------------------------------------------------------
> 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.

Hey George, how are you doing today...

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.