Reflashing original uboot? (solved)

O.K. My situation is as follows: I installed Jeff's uboot for boot Debian in USB. It works fine. Then I tried to installed Openwrt without Serial cable and failed. In the process I damaged the original Pogolinux firmware, even though Jeff's uboot still works and I can boot into USB Debian. I bought a CA-42 cable and connected to the serial port, Openwrt installed successfully. However, I tried to reinstall the original Dockstar firmware a few times according to http://plugapps.com/index.php5?title=Hardware:_Seagate_DockStar_Reflashing but always failed. It was stated somewhere that in order to use the reflashing procedure, I will need to have the original uboot. My questions are:
1. Since pogoplug linux does not working anymore, if and how I can use Debian in usb or using Openwrt to flash mtd0 according that described at the end of http://jeff.doozan.com/debian/uboot/.
2. I guess I can use my serial cable to put the original uboot in mtd0, i.e., start from memory address 0, is this correct?
3. If for some reason, the original uboot does not installed correctly, will I still be able to use the serial cable to flash again?
Home somebody can help. Thanks in advance

It is solved see next posting.



Edited 1 time(s). Last edit at 01/04/2011 12:53AM by twinclouds.

O.K. I solve the problem and would like to share the findings.
I restored original uboot from USB debian Linux to mtd0. Then I was able to reflash the pogoplug firmware. Then I reinstalled Jeff's mtd0 uboot. It is like new now.
Two things worth mentioning:
1. Restore uboot can be done from USB debian linux as long as the necessary software are installed.
2. It was confirmed that the reflashing technique only works with the original uboot. For some reason Jeff's mtd0 uboot will not work for reflashing.
I still don't know if a bad uboot install will impact serial connection or not but it is not important anymore.

Just curious: Are you saying that running Jeff's uBoot script, install_uboot_mtd0.sh, from an active booted Linux,won't work unless the original uBoot is first reinstalled? If so, how does it fail? I'm wondering if the problem you experienced wasn't a uBoot problem per se, but rather a problem with an altered uBoot environment. Jeff's uBoot script, I believe, doesn't reset the uBoot environment when it finds his uBoot already installed. However, by altering the script, the default environment could be restored.

As far as installing uBoots, if a uBoot does not install correctly, i.e., it is not sane enough to come up to at least its prompt, then at that point your only recourse is to plug a JTAG device into the Dockstar. That's why Jeff cautions against booting until you have fixed things if a uBoot install is unsuccessful -- at that point the running OS is your only hope, short of a JTAG, of restoring the ability to successfully bootstrap the device. And that's why playing with updating uBoots, and to some extent the uBoot environment, is inherently risky -- making the wrong mistake can brick your device.

restamp Wrote:
-------------------------------------------------------
> Just curious: Are you saying that running Jeff's
> uBoot script, install_uboot_mtd0.sh, from an
> active booted Linux,won't work unless the original
> uBoot is first reinstalled? If so, how does it
> fail? I'm wondering if the problem you
> experienced wasn't a uBoot problem per se, but
> rather a problem with an altered uBoot
> environment. Jeff's uBoot script, I believe,
> doesn't reset the uBoot environment when it finds
> his uBoot already installed. However, by altering
> the script, the default environment could be
> restored.
No. What I was saying was if you use Jeff's mtd0-uboot, you cannot reflashing the original Dockstar firmware with pogolinux using the procedures described in http://plugapps.com/index.php5?title=Hardware:_Seagate_DockStar_Reflashing. You can only do that from the original uboot. You can load/reload original uboot or Jeff's uboots from Debian Linux as long as you have the mtd utilities installed in Debian.
>
> As far as installing uBoots, if a uBoot does not
> install correctly, i.e., it is not sane enough to
> come up to at least its prompt, then at that point
> your only recourse is to plug a JTAG device into
> the Dockstar. That's why Jeff cautions against
> booting until you have fixed things if a uBoot
> install is unsuccessful -- at that point the
> running OS is your only hope, short of a JTAG, of
> restoring the ability to successfully bootstrap
> the device. And that's why playing with updating
> uBoots, and to some extent the uBoot environment,
> is inherently risky -- making the wrong mistake
> can brick your device.
My question was if JTAG procedure is the same as using a serial cable (CA-42) or I need something additional. I am not that familiar with hardware debugging so sorry for my ignorance.

Well, I've never attached a JTAG to a Dockstar, so I cannot speak definitively, but I have used the JTAG on a SheevaPlug to reload it. The JTAG interface is a completely different interface from the serial console. There is a command language interface to the JTAG to do things like reflashing the NAND memory or stepping through the processor, but it is fairly low level. Typically, the JTAG is controlled by a program, such as OpenOCD.

The SheevaPlug comes with its own built-in JTAG. In fact, its USB interface serves up both its JTAG interface and its console. The Dockstar does not have a built-in JTAG, so you'll have to provide your own. Old JTAGs typically use a parallel interface to talk to the client machine that runs OpenOCD. Newer JTAG boards use a USB interface. Both connect to the Dockstar via a header -- I think the same header that your CA-42 connects to, although the JTAG uses different pins.

Some time ago, someone here posted the following JTAG unit as one that would work with the DockStar:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270528612875

If you still own a PC with a parallel port, it might not be a bad device to acquire.
Also the following thread might be useful:

http://www.plugapps.com/forum/viewtopic.php?f=18&t=195

That's the gist of what I know about JTAGs for the Dockstar. Hope it helps.

restamp:
I don't think I need it right now and hope I never need it. In any case, thanks for your explanation.

And, with luck, you'll never need it. In our environment, the JTAG is really only useful in two specific situations:

1. When something has so thoroughly bricked the device that even the uBoot will not run.
2. When you want to easily get your device back to a known state.

If you have a bootable and sane uBoot on the device, especially one capable of booting from external media, you can typically use it or other mechanisms it provides to restore your device to working order.

Thanks. Let me state my question a little differently: Hypothetically, if I erased mtd0, will Dockstar still be able to communicate with PuTTY through the CA-42 serial cable?

If mtd0 points to the part of the NAND containing the uBoot -- i.e, the first 1Mb or so of NAND -- which it does on Jeff's device mapping for the Dockstar (but does not, for instance, on my SheevaPlug), then no, I don't think the CA-42 cable could be used by itself to restore a Dockstar device after mtd0 has been erased.

Think of the uBoot as analogous to a PC's BIOS. By default, the uBoot uses the serial port to communicate with the outside world, but it has to be booted up and running to do so. (By contrast, a PC's BIOS normally communicates via the keyboard and monitor.) If the uBoot code is itself erased from the NAND, there is nothing sane to run; no program to initialize the serial port and talk to it. And nothing to load and invoke a Unix kernel either. On power-up the Marvell processor would dispatch to address zero, or wherever it expects to find the uBoot, and it would immediately crash. The device would be profoundly bricked, requiring a JTAG to repair. It would be as if you upgraded the BIOS on your PC with a file containing all ones: Even if the OS on the hard drive were still present and intact, the machine could no longer be booted.

The CA-42 cable basically serves three purposes:

1. To talk to and display the progress of the uBoot during the initial boot sequence.
2. To display the progress of the boot after the uBoot loads and turns control over to a Unix kernel.
3. To serve as the device's console, allowing logins, after Unix has been booted.

The first instance above is quite powerful: If the uBoot itself is sane, you can interrupt it and recover from almost any problem by changing the uBoot's environment. But, if the uBoot itself is not sane -- at least if it's not sane at the time the hardware is booted -- you're hosed.

Is that any clearer?

BTW, has anyone else noticed that this board changes the word 'brick-ed' (w/o the hyphen) to 'broken'?



Edited 1 time(s). Last edit at 01/07/2011 12:30AM by restamp.

Thanks for your explanation. I think I understand now. The conclusion, don't mess up uboot :-).

iam ,meting with the fallowing error my board stop at enable 2t how can i reflash uboot to solve the problem

| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
** MARVELL BOARD: DB-MV78200-A-BP LE

U-Boot 1.1.4 (Oct 26 2010 - 15:59:57) Marvell version: 3.3.30

U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006D4880

Soc: MV78200 A1 (DDR2)
CPU running @ 1000Mhz L2 running @ 500Mhz
SysClock = 400Mhz , TClock = 200Mhz

Enable 2T


please help me to reflash orginal u-boot

check
http://wiki.scottn.us/goflex:start
see "serial recovery"

Hi,

I am also in same boat. Where did you got original mtd images i.e. mtd0-uboot, mtd1-uimage, mtd2-rootfs?
I need those as well to reflash my dockstar. Can you be able to share those?

Thanks