Newer uBoot as workaround to 3.2 kernel problem?

@davygravy

i've flashed your uboot, and sata boot with kernel 3.2 worked fine.
the second sata slot i must try in the evening....

thanks a lot...

major_tom007

@ Major_Tom007:

I've found a minor problem (the arcNumber hook was smashed, fixed that)...and rerolled it...

new version is posted above...

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

• davy's Github Repo's rescue-dg

@davy

i've flashed your latest uboot for the goflex, but i had to go back.
with the latest uboot the goflex didn't boot from the sata port.
the serial log wrote: couldn't find /dev/sda1 .....
the the maschine hung.
i think there could be a bug.

cya
major

That's odd. The only code that was changed between those two had no connection w/ SATA. Mine is booting reliably from both SATA ports. Reproducible and persistently.

Until I can see actual output from your serial, I think it may be some environmental variable in your boot command sequence that is either wrong or not specific enough.

What is the label of your SATA rootfs partition? (I suspect that's the missing component for you.)

If you try this again, _please_ post actual bootcommands, bootargs and the works, along with exact output, copied straight from your serial connection window. Without that kind of detail it is guesswork as to why it didn't work for you.

==========================================
EDIT I think your problem may have been here. http://forum.doozan.com/read.php?2,7522,7522#msg-7522 It is notable that you make no mention of a label on your SATA rootfs partition.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 04/22/2012 07:12AM by davygravy.

Hi,

now it works. had a lot of troubles...
first of them was, that i forgot to change the arcnumber on my testmaschine.
then i screwd up the installation.
so i made a new clean system, and now it works fine.
solong.
Many Thanx for your good job!

major

Dave,

I have 5 Dockstars, and I've had zero problems with any. I even run FreeBSD one. I also have a new,
in-the-box Goflex Net.

After reading Goflex posts regarding "bad flash", SATA boots from either connector, Linux 3.2 kernels,
L2 cache, the right archnumber, eSATA vs.Sheeva as a default, etc., my head hurts.

Does this U-boot include all of the above in a single binary that I can install on my Goflex Net? Or, should
I put my Goflex Net back in the box, and wait until more dust settles? Or, trade my Gofex Net for another
painless Dockstar?

Thanks!

Richard

Is there a procedure for upgrading to the new (davygravy's) u-boot from an already working debian wheezy running on a Seagate Dockstar?

Yes, top post of thread...

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

• davy's Github Repo's rescue-dg

Hi there!

Thank you for this great peace of work!

I want to flash this new UBOOT Modification and the rescue system v2 from Jeff from this thread: http://forum.doozan.com/read.php?4,3896 ...

I want to be completely sure about the procedure before I am going to flash it.

I have one Dockstar with Debian Squeeze (Kernel "Linux soprano 3.1.10-dockstar-shyd" ) and a Dockstar (previously also Debian Squeeze) with latest ArchlinuxArm running...

On both Dockstars I havent touch the PogoPlug Software and for troubleshoot if something is going wrong with the dockstar the PogoPlug Software isn't good enough... So I read about the RescueSystem v2 and I want to flash it on both Dockstars.

Now that I saw that you are providing a much better and up-to-date uBoot I also want to flash it.

So for flashing this I have some questions before I proceed.


1.) What do I need to flash FIRST? At The RescueSystem v2 Thread (http://forum.doozan.com/read.php?4,3896) doozan wrote that before flashing the RescueSystem v2 it's necessary to update uBoot?! So, what is the correct order. First flash the uBoot from this thread and then the Rescue System v2 ( http://forum.doozan.com/read.php?4,3896 ) or first flash the RescueSystem v2 and then your uBoot version!?

2.) Will this uBoot run both my Dockstars with Debian and Archlinux without Problems. System PartitionLabels are "rootfs"

3.) Does this boot also from ext2 and ext3 and ext4 partitions?

4.) I have the PoGoPlug Original Flash Backups so am I able to reflash them again to get the Dockstars into the ORIGNAL retail state?

5.) Will this whole Procedure also apply to a GoFlex Net with ArchlinuxArm installed?!

Thanks for answering my questions in advance. I need to be really sure about this.

Again thank you and greetings from Germany!

Ron

@davy

I have been lurking here on Jeff's site since right the Dockstar was released. I never felt the need to login or post anything until now. But I created an account here just now to thank you for your new uboot. So. . .

THANKS!

Like you, I have previously messed around several times with compiling uboot. Unfortunately, however, I never could get them to chain load like Openwrt's or Jeff's. Due to the lack of a JTAG cable I was afraid to flash them. So, for the past couple of years I reluctantly used Jeff's (for the Dockstar) or Peaslakers (for the GoFlex).

Both worked fine (at the time), but they both had two major annoyances:

1) No way to easily edit/backup/restore the environment variables. Only a single_line_at_a_time. What a nightmare!

2) My personal annoyance with things like "Marvell-Dockstar/Pogoplug by Jeff Doozan" or "UBIT v0.6 by peaslaker."

While I, like everyone else using these devices, very much appreciate the effort that both Jeff and Peter have put into u-boot on these devices, I don't enjoy distracting self promotion in my boot loader. It just seems too amateurish and ostentatious.
This is not some proprietary software. You don't see a message in the Kernel such as "Linux - by Linus Torvolds." I have the feeling he would be very offended by that. Countless unnamed people contribute to Linux. Nor do you often see things such as "PEANUX v0.6 - a new fork of Linux by ___" in your average mainstream open source project. But thanks for the efforts guys! I think we can remember your names by now! Thank you even more davy, for leaving that crap out of yours.

Anyway. Now that we are past that rant let me say thanks again to you davy for your efforts. I had already given up on my recent Dockstar kernel build, and my latest Debian kernel update, until I came upon your post. I had built my own kernel since the latest Debian one did not boot. Then mine did not boot either. . . I just bought another GoFlex Net before I saw your post. But then somehow I bricked it with a bad mtd0 write while trying to load Openwrt uboot. So I finally got a Bus Pirate JTAG. The Bus Pirate is very slow, but it is cheap and uses USB. I recovered the uboot with the JTAG (these devices are basically unbrickable if you have JTAG). I loaded UBIT on that one and then I came upon your post. I TFTP'd your uboot to my Dockstar (I have JTAG now - so I'm not as paranoid) and it worked PERFECTLY without even touching the old Uboot environment!

I was not so lucky, however, with the GoFlex. Peaslaker's uboot (UBIT :() stores its environment at 0x60000. So my old environment was lost and the device did not boot. Fortunately I had done a fw_printenv beforehand to a file. So I was able to get it quickly going again. Both devices are now booting the latest Debian kernels, and now the Goflex has the following:

Linux DS03 3.2.11 #1 Thu Mar 15 23:31:05 GMT 2012 armv5tel

So my recent natively compiled kernel works! (It only took a day or so on the GoFlex. . .) I am very happy! Thanks again!

I am very happy that I can now boot a recent kernel. But others reading this thread need to be aware that flashing uboot, even if the flash is successful, can be risky if you are unfamiliar with the uboot environment and how to manipulate the variables. Make certain to do a fw_printenv > uboot_environment. It is safe as long as you are using a Doozan uboot with the environment at 0xc0000. But otherwise you may need to reset some variables. It would be wise to do a full backup of mtd0 before proceeding and make sure you have netconsole or a serial terminal so you can edit the uboot variables.

If you are hesitant to replace u-boot, but want to use a more recent kernel, there is also another option. Sheeva with Linux has the very latest kernels (the latest stable version - which is even more recent than the Debian kernel) for the Dockstar/GoFlex/Pogo devices. They even have an install script to update the kernel and the modules (but no Initrd, unfortunately. You will need to make that on your own.). The Sheeva with Linux kernels have the VM support disabled, so they will boot using an older uboot.

If you wish to keep your existing uboot and roll your own kernel then simply use the existing Debian kernel config and change this line:

CONFIG_ARM_PATCH_PHYS_VIRT=y

to

# CONFIG_ARM_PATCH_PHYS_VIRT is not set

An easier option to configure your own custom built kernel for an older uboot would be to simply use the
latest Sheeva with Linux kernel config

The best option for using a newer kernel is to use a current u-boot such as davy's with a current kernel such as Debian's. I am now using davy's Dockstar and GoFlex Net u-boot's with the latest kernels and they work flawlessly.

But we still need an easy way to manipulate/save/restore the uboot environment variables. Unfortunately fw_printenv will only print or save the environment to a text file. If you have a lot of environment variables like we need to boot from USB or SATA it can be a lot of work to restore the environment from the command line.

I have been experimenting with a process to save/restore the full uboot environment. It should be possible to save the NAND flash memory at 0xc0000 (or 0x60000) as a binary file and then use that file to restore the uboot environment when needed. I used the following command to save the binary file:

nanddump -s 0xc0000 -l 0x20000 -f uboot.env.bin /dev/mtd0

I then outputted the binary file to the console and it showed the FULL uboot environment, and a lot of empty space.

The big question now is if that file can be restored without issues. . . I am first going to put it on my TFTP server and then try to restore it from the uboot console. Wish me luck! I have my BusPirate handy in case of problems.

Okay. The above nanddump command line is wrong. The sizes did not match. You must omit the oob data and skip any bad blocks:

nanddump -b -o -s 0xc0000 -l 0x20000 -f uboot.env.bin /dev/mtd0

is the correct command to backup the environment as a binary.

Do NOT try to restore the file with nand write.e ! It does not work and resets the environment if you try to restore the file with nand write.e !

Fortunately it does not affect the uboot binary. . .

Anyway, it is not needed! The new Uboot that davy uses has new commands to export/import the environment:

GoFlexNet> help env import
env - environment handling commands

Usage:
env default -f - reset default environment
env edit name - edit environment variable
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t | -b | -c] addr [size] - import environment
env print [name ...] - print environment
env run var [...] - run commands in an environment variable
env save - save environment
env set [-f] name [arg ...]

It also sorts the environment variables alphabetically!

Way to go davy!

I did not see those commands in the earlier uboot, but maybe they are there (edit: No, they are not there). If they are, and you use a uboot with a different environment address, then you can use "env export" to do the backup of the environment when updating the uboot.

The following uboot commands will restore the environment from the file created above:

mw 0x800000 0xffff 0x40000
tftpboot 0x800000 uboot.env.bin
env import -t 0x800000 0x20000

Now your saved environment is restored (and sorted!). Make sure you save it again. . . just to be certain, before you reset:

saveenv

The "env import" has the -t option to import a text file. It is also able to use the text file created with fw_printenv. After I restored the environment from the binary file I created above I noticed that the first four bytes of the arcNumber variable were corrupted. Fortunately it still booted since the "machid" variable was also present (good reason to have both!).
So we are now able to easily restore the config from the fw_printenv output and that should be used if possible. If you do not, however, have that capability the binary backup also (mostly) works.

Now with the environment saved and easily restored I can (edit: and did!) easily update my other GoFlex Net's with davy's uboot while keeping my existing uboot environment (even though it was stored at a different memory address (0x60000)!

Have fun with your new kernels!



Edited 4 time(s). Last edit at 04/27/2012 03:32PM by gnexus.

gnexus Wrote:
-------------------------------------------------------
>
> 2) My personal annoyance with things like
> "Marvell-Dockstar/Pogoplug by Jeff Doozan" or
> "UBIT v0.6 by peaslaker."

:-) How many times a day do you see your boot loader output?

@ bodhi

A LOT a year or so when I was trying to get the uboot parameters correct for my USB and SATA partitions!

Not so much now. . . ;)

I know it's a stupid thing to bring up. It probably is only a distraction to just me, and of course you usually never see the bootloader anyway. . . But, for me personally, it was always a distraction (actually even the "Dockstar>" bit is distracting, I would rather see the hostname). Probably part of that was because I never could get my own compiled U-boot to work by chainloading it (I did not have JTAG then.). I also wanted a newer uboot to get the newer features. That nagged me. . .

I wanted to compile my own uboot due to all the complexity of the bootloader variables. But I did not have JTAG and could not figure out how to get the relocation to work like in Jeff's (is that due to TEXT BASE or the environment address?). Back then there was no good way to to easily save/restore/sort the environment except to simply compile it in. Now that there is an easy way to save/restore/sort the environment in the latest version I will likely never see the uboot prompt again.

But still, putting your name on the uboot screen would be considered unprofessional by most open source developers. You don't see Rudolph Denx putting his name there, and he created it. To each his own, however. I still greatly appreciate Jeff and Peter's patches, and this site. Thanks guys



Edited 1 time(s). Last edit at 04/28/2012 12:18PM by gnexus.

I've installed first the RescueSystem v2 and then your uBoot version... All working propperly.. Thanks again for your nice work!

Its great to see how a great community can push such a device forward!! :)

Thank you, thank you! Your new uboot procedure works with my GoFlex Net.

With a USB stick and no SATA drive, it boots from the USB stick.
With no USB stick and one SATA drive, it boots from the SATA in either slot.
With no USB stick and two SATA drives, it boots from the right-slot SATA.

It's difficult to argue with success.

However, I do note the following anomaly booting ArchLinuxARM:

With a USB stick and one SATA drive, it boots from the SATA in either slot. -- OOPS!
With a USB stick and two SATA drives, it boots from the USB stick.

With my Dockstars, I always carry an emergency USB stick to boot from for repairing a failed/
failing disk drive. I though that the GoFlex Net would boot from the USB stick regardless of
whether a SATA drive was present. Apparently not.

For now, I'll carry a spare SATA drive for GoFlex Net emergencies. However, my (yet to be
received) GoFlex Home has only one SATA, and my two SATA drive solution won't work for
emergencies. How are people handling SATA disk problems on their GoFlex Home?

@ davygravy

On my GoFlex I noticed that my MAC address had changed and was not the same as on the base of the device. I don't know where this MAC came from:

02:50:43:d9:f4:xx

The OIU (first half of MAC - not IEEE registered) is the same as the Dockstar. It is not the GoFlex (00:10:75:xx:xx:xx).

I can only assume that MAC came from the compiled U-boot defaults. That was reset before I reloaded the environment.

If that is the MAC of your Dockstar, davy, you might want to remove it (or change it) from the compiled environment ;)
But then again everybody probably knows it by now! So it might be better to change your own MAC instead if that's the case

It might not be a GoFlex MAC, but at least there is a MAC if you reset :) Might be a very bad thing not to have one!

As an interesting sidenote to this, there was a very long discussion on the Uboot Mailing List about coded-in MAC's.

gnexus Wrote:
-------------------------------------------------------
> @ davygravy
>
> On my GoFlex I noticed that my MAC address had
> changed and was not the same as on the base of the
> device. I don't know where this MAC came from:
>
> 02:50:43:d9:f4:xx
>
> The OIU (first half of MAC - not IEEE registered)
> is the same as the Dockstar. It is not the GoFlex
> (00:10:75:xx:xx:xx).

I want to look at code and see what is up. AFAICR, I didn't hard code in the MAC/hw address, but I'll double check. EDIT: just checked - it isn't in the code . And as far as I can see, that isn't a Dockstar... here's why...

Let's think this out --- Dockstar and GoFlex are both made by Seagate, so why would the first 6 hex digits differ? Both of my Dockstars have MAC addys 00:10:75... as well as my GoFlex units.

It isn't Cloud Engines (00-25-31) either.

>
> I can only assume that MAC came from the compiled
> U-boot defaults. That was reset before I reloaded
> the environment.

Not mine, as far as I can tell. I'll to a HexEditor string search for 02:50:43:d9:f4 and post back later.
EDIT : I used Bless Hex Editor and performed searches on that sequence you showed above, with and without colons, as text, hexadecimal and other bases... I couldn't find any occurences of that string/pattern (or substrings of it) in any of my U-Boot.*kwb's . You are welcome to check for yourself, though.

Not sure where it is coming from on your side, but I'm going to add in a recommendation to either print out or dump out contents of uboot env var values, and to double check the MAC addies. I haven't seen this happen on any of my machines (Pogos V1/2, Dockstars, GoFlex Net/Home, Zyxel). I'll keep watching, though.


> If that is the MAC of your Dockstar, davy, you
> might want to remove it (or change it) from the
> compiled environment ;)
> But then again everybody probably knows it by now!
> So it might be better to change your own MAC
> instead if that's the case

I guess I'm safe... not mine.

>
> It might not be a GoFlex MAC, but at least there
> is a MAC if you reset :) Might be a very
> bad thing not to have one!

To be honest, on the GoFlex's could probably benefit from having a default address with the proper OIU set to something Manufacturer-Specific (ie, with the first 6 hex digits correct), and some random-ish value for the remaining 6, with the caveat/direction/reminder to restore the original value. The GoFlex's are in a more difficult situation in that:

1. the standard Debian kernels that will boot them don't have any machine alternate type that uses the correct delay in <machine-type>-setup.c, so they all display the "Too many bad blocks" NAND error, thus disabling NAND access once booted into a standard Debian kernel
2. not having NAND access (due to problem #1) prevents one from setting netconsole on [for which serverip, ipaddr and ethaddr are all required], thus you are locked out of changing U-Boot env var values to fix the situation... if you don't have a Serial Adapter, you possibly very Severely Out of Luck.

I just finished putting a few added features on U-Boot for Zyxel NSA320 support tarball, and I did hard code in a MAC address for that, but with directions (specific and impossible-to-miss) on how and why to put back the correct value. I also preset ipaddr, serverip, ethaddr and the needed env vars to make netconsole the default. But this is a very different situation - none of the mainline kernels can boot it - it needs a bit a special sauce for the ethernet, among other things.

>
> As an interesting sidenote to this, there was a very long discussion on the
> http://lists.denx.de/pipermail/u-boot/2011-November/108812.html
> Uboot Mailing List about coded-in MAC's.

Yes, I've followed that discussion started by Michael Walle (who incidentally is the one who posted the patch that fixes the L2 cache bug in Kirkwood). Denk etal are very stringent about not allowing hard-coded MAC addresses in their source code - probably for (of course) security reasons, and liability (??).

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

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 04/30/2012 03:03PM by davygravy.

arbie2 Wrote:
-------------------------------------------------------
> Thank you, thank you! Your new uboot procedure
> works with my GoFlex Net.
>

You are welcome! ...and thanks for feedback.

> With a USB stick and no SATA drive, it boots from
> the USB stick.
> With no USB stick and one SATA drive, it boots
> from the SATA in either slot.
> With no USB stick and two SATA drives, it boots
> from the right-slot SATA.
>
> It's difficult to argue with success.
>
> However, I do note the following anomaly booting
> ArchLinuxARM:
>
> With a USB stick and one SATA drive, it boots from
> the SATA in either slot. -- OOPS!

Can you post back some more details? Maybe output from command line? Or maybe the env var values?
(ahhhhaa... are you using UBIT? I've not done anything to make stuff compatible w/ that, nor do I have plans for it...)
I've only tested it w/ Debian, and I don't know what U-Boot env vars values are for ALARM.

> With a USB stick and two SATA drives, it boots
> from the USB stick.
>
> With my Dockstars, I always carry an emergency USB
> stick to boot from for repairing a failed/
> failing disk drive. I though that the GoFlex Net
> would boot from the USB stick regardless of
> whether a SATA drive was present. Apparently
> not.
>
> For now, I'll carry a spare SATA drive for GoFlex
> Net emergencies. However, my (yet to be
> received) GoFlex Home has only one SATA, and my
> two SATA drive solution won't work for
> emergencies. How are people handling SATA disk
> problems on their GoFlex Home?


I'm using the same GoFlex Net U-Boot in my GoFlex Home, and it works great in it, from all I can tell.

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

• davy's Github Repo's rescue-dg

Is it possible to install the new uBoot from within debian / pogoplug system like its done with Jeff's script?

In my opinion, it is safest to replace it from within U-Boot, from either serial console or netconsole.

I've not tried it from the Linux side, but I suppose you could do it using the same commands/binaries that are present in Jeff's script.

Varkey, are you interested in putting together a script to update uboot? Jeff and I have talked about it... but I'm snowed under with some family health issues right now... maybe by late June or July...

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

• davy's Github Repo's rescue-dg

I was able to modify Jeff's uboot script slightly and install the GoFlex Home uBoot within the OS.

All the device checking mechanisms seems to be already there and I guess it just needs minor modifications to install the newer uBoot.

@davygravy : I've created a mirror of the uboot files along with your updated uboot. Jeff's script as such didn't need any moidifcations, just had to upload the newer files and name it appropriately.

http://uboot.varkey.in/install_uboot_mtd0.sh

I tested on a out of the box GoFlex Home and it worked fine, although it didn't preserve the ethernet mac. it seems to be an issue only with the GoFlex Home as it doesn't use the Pogoplug OS like the other devices.

I thank you so much for trying that. When you say it didn't preserve it do you mean that it would have to be restored from the env that is nanddumped just before flashing? Or ?


Also, what about upgrading U-Boot on a Debian system? Or other (e.g. ArchLinuxARM)? I'm assuming that this script just handles new installs...or does it also work with upgrades?

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

• davy's Github Repo's rescue-dg

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

When you've got 'finished' versions of your uboot images, I can host them here and let them deprecate my binaries. That way they should just automatically work with all the existing scripts and instructions floating around out there.

I'm mulling that over right now... I've been using them successfully for about 3 months now... although I thought differently back in February, no really significant features that would affect Kirkwood greatly have made it into mainline. As such, I think they are ready to go.

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

• davy's Github Repo's rescue-dg

Quote
davygravy
I thank you so much for trying that. When you say it didn't preserve it do you mean that it would have to be restored from the env that is nanddumped just before flashing? Or ?

I mean, it didn't set the ethaddr env variable automatically.

Quote
davygravy
Also, what about upgrading U-Boot on a Debian system? Or other (e.g. ArchLinuxARM)? I'm assuming that this script just handles new installs...or does it also work with upgrades?

I just did what Jeff said, and the script automatically worked. It should work from debian as well.

davygravy Wrote:
-------------------------------------------------------
> I'm mulling that over right now... I've been using
> them successfully for about 3 months now...
> although I thought differently back in February,
> no really significant features that would affect
> Kirkwood greatly have made it into mainline. As
> such, I think they are ready to go.


I second that opinion: the "new" u-boot is good to go!

I've also been testing Linux kernels. In my opinion kernel 3.3.3 is the most stable: in kernel 3.3.4 (and onwards) fundamemtal chages have been made to ppp, tcp, skbuff and socket which in my opnion have broken tcp/ip on the Dockstar armel platform.

I use my Dockstar to connect to the internet using kernel mode PPTP (accel-pptp) and since kernels 3.3.4 and 3.4.0-rc1, am unable to do so in an efficient manner.

Robert Mugabe Wrote:
-------------------------------------------------------
> davygravy Wrote:
> --------------------------------------------------
> -----
> > I'm mulling that over right now... I've been
> using
> > them successfully for about 3 months now...
> > although I thought differently back in
> February,
> > no really significant features that would
> affect
> > Kirkwood greatly have made it into mainline.
> As
> > such, I think they are ready to go.
>
>
> I second that opinion: the "new" u-boot is good to
> go!

thanks @ you RobertMugabe for your help in understanding the problem back in Jan/Feb of this year

> I've also been testing Linux kernels. In my
> opinion kernel 3.3.3 is the most stable: in kernel
> 3.3.4 (and onwards) fundamemtal chages have been
> made to ppp, tcp, skbuff and socket which in my
> opnion have broken tcp/ip on the Dockstar armel
> platform.

This is really good to know - I'm wondering if they'll have it ironed out by 3.4. I haven't had a chance to try 3.4-rcN (N>4) yet...

> I use my Dockstar to connect to the internet using
> kernel mode PPTP (accel-pptp) and since kernels
> 3.3.4 and 3.4.0-rc1, am unable to do so in an
> efficient manner.
That stinks. I hope they don't throw us another "upgrade" to behavior in the kernel.

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

• davy's Github Repo's rescue-dg

Jeff Wrote:
-------------------------------------------------------
> When you've got 'finished' versions of your uboot
> images, I can host them here and let them
> deprecate my binaries. That way they should just
> automatically work with all the existing scripts
> and instructions floating around out there.

Thanks Jeff, that would be the best IMO.

OK, finalized: L2Cache off during decompress so that default 3.2 kernels boot correctly, EFI partitions recognized for drives bigger than 2TB, SATA channel/recognition fix for GoFlex's and NSA320. The Pogoplug Pink/E02/V2 has a minor fix in it so that the arcNumber is properly passed (I'd borked something previously).

• http://dl.dropbox.com/u/1015928/Kirkwood/uboot/uboot.dockstar-L2Coff-EFIon.kwb.tar.gz
• http://dl.dropbox.com/u/1015928/Kirkwood/uboot/uboot.goflexNetHome-IDEfixed-L2Coff-EFIon.kwb.tar.gz
• http://dl.dropbox.com/u/1015928/Kirkwood/uboot/uboot.pogoplugE02-arcNumfixed-L2Coff-EFIon.kwb.tar.gz
• http://dl.dropbox.com/u/1015928/Kirkwood/uboot/uboot.zyxel_nsa320-IDEfixed-L2Coff-EFIon.kwb.tar.gz

Note: I spent a chunk of time trying to get the LED to work on the Pogoplug V2/Pink, just as it did in the stock CloudEngines UBoot. I tried to use Jeff's LED code, but to my amazement and surprise, it never did work (for me at least) even on his original 10-23-2010 version - when I burned it into NAND for a try, it stayed off the entire time that U-Boot was loaded and executing. Go figure. Once the kernel gets into the booting process, the LED does work as it should on the PogoE02.

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

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 05/28/2012 07:51PM by davygravy.