Newer uBoot as workaround to 3.2 kernel problem?

@davygravy, you should NOT change anything in the pogo.kwb header. If you take a look for differences between jeff & ecc dockstar.kwb patches you'll find it in the same way that there are differences between my patch & jeff patch.

It could be a good idea keep the files the closest to the mainline u-boot, and submitting new machine's support without many arrangements. Then you can submit 'a-la-jeff' patches for dockstar & pogoplugs (and maybe goflex). In this way your new u-boot will be:

- u-boot 2011.12 sources
- l2_disable_cache.patch
- pogo_e02_support.patch ( and other machine definitions not supported in current u-boot, like i-connect ...)
- dockstar-a-la-doozan.patch, pogo_e02-a-la-doozan.patch, goflex-a-la-doozan.patch....

This is the best way that I've found to keep changes tracked and to submmit new machines support in the u-boot's standard way.

With all those machines mainlined ( and the kirkwood related l2_disable.cache.patch applied) keep compatibility with jeff's way of doing things is simplier, and it consists on a patch per machine, that configures the "include/configs/$machine.h" to keep backward compatibility.



Edited 1 time(s). Last edit at 02/23/2012 06:33AM by pazos.

good to hear from you, pazos!

You did a nice job on that patch!

pazos Wrote:
-------------------------------------------------------
> @davygravy, you should NOT change anything in the
> pogo.kwb header. If you take a look for
> differences between jeff & ecc dockstar.kwb
> patches you'll find it in the same way that there
> are differences between my patch & jeff patch.


Yes, I'd figured that was true. Back on Saturday last weekend I started picking through Jeff's patch and your patch, first diffing the two, part by part. Later, I actually printed out the kwb portion of the Jeff's patch and your patch on paper, and when line-by-line to make absolutely sure I saw everything that was different, and so I understood where it was in the code.


As far as I can see, there were only two changes that needed to be made to your patch so that it matched Jeff's kwb values exactly. [ note that the code below is a diff of two patches... ;) ]

davygravy@bitbaker64:~$ diff -uNr Downloads/pogo_e02.patch  pogo_e02-davyrevision.patch 
--- Downloads/pogo_e02.patch	2012-02-23 19:53:08.050981859 -0600
+++ pogo_e02-davyrevision.patch	2012-02-20 21:14:22.876924304 -0600
@@ -168,7 +168,7 @@
 +DATA 0xFFD01428 0x00085520	# DDR2 ODT Read Timing (default values)
 +DATA 0xFFD0147C 0x00008552	# DDR2 ODT Write Timing (default values)
 +
-+DATA 0xFFD01500 0x00000000	# CS[0]n Base address to 0x0
++#DATA 0xFFD01500 0x00000000	# CS[0]n Base address to 0x0
 +DATA 0xFFD01504 0x0FFFFFF1	# CS[0]n Size
 +# bit0:    1,  Window enabled
 +# bit1:    0,  Write Protect disabled
@@ -177,7 +177,7 @@
 +# bit31-24: 0x0F, Size (i.e. 256MB)
 +
 +DATA 0xFFD01508 0x10000000	# CS[1]n Base address to 256Mb
-+DATA 0xFFD0150C 0x0FFFFFF5	# CS[1]n Size 256Mb Window enabled for CS1
++DATA 0xFFD0150C 0x00000000	# CS[2]n Size, window disabled
 +
 +DATA 0xFFD01514 0x00000000	# CS[2]n Size, window disabled
 +DATA 0xFFD0151C 0x00000000	# CS[3]n Size, window disabled

> It could be a good idea keep the files the closest
> to the mainline u-boot, and submitting new
> machine's support without many arrangements. Then
> you can submit 'a-la-jeff' patches for dockstar &
> pogoplugs (and maybe goflex). In this way your new
> u-boot will be:
>
> - u-boot 2011.12 sources
> - l2_disable_cache.patch
> - pogo_e02_support.patch ( and other machine
> definitions not supported in current u-boot, like
> i-connect ...)
> - dockstar-a-la-doozan.patch,
> pogo_e02-a-la-doozan.patch,
> goflex-a-la-doozan.patch....
>

Yes, I agree absolutely. It also makes the patches a little easier to understand (in regards to what they apply to).


> This is the best way that I've found to keep
> changes tracked and to submmit new machines
> support in the u-boot's standard way.
>
> With all those machines mainlined ( and the
> kirkwood related l2_disable.cache.patch applied)
> keep compatibility with jeff's way of doing things
> is simplier, and it consists on a patch per
> machine, that configures the
> "include/configs/$machine.h" to keep backward
> compatibility.

I'm going to have a bit of time during the coming weeks... I can put some time into the E02 and GoFlexNet board support submissions.

The GoFlex would of course live in board/Seagate/goflex_net and include/configs/goflex_net.h.

With the V1, E02, V4-series all floating around out there in the embedded device enthusiast community, it seems like it would make sense to make a home of all of them in board/CloudEngines/pogoplug_<version>/ , instead of throwing them in with the board/Marvell/*plug lot. Does that make sense?

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

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 02/23/2012 08:56PM by davygravy.

@davy,

Would it also work for the Pogo V4 series? that would be great!

@davygravy: it does make sense, since dockstar files are under board/Seagate, but this is a minor fix that involves boards.cfg

PD: Your configuration (from include/configs/dockstar.cfg) seems to work out-of-the-box applied to an iconnect wireless station, With new u-boot tested in RAM before flashing it into nand. It works like a charm with jeff's enviroment settings and can handle everything mentioned above (including booting original firmware (via the stock bootloader and a rescue enviroment saved on some nand address space))

@bodhi: pogo_v4 u-boot is build from cloudengines sources, not from denx repositories, this version is old (3.1.4) and l2_cache_disable patch does not apply cleanly to u-boot sources, but it doesn't matter cause the people behind archlinuxarm repported that their u-boot can boot newer kernels +3.2 without any patches applied. Under the hood pogov4 have an armada-based SoC instead of a Kirkwood SoC. I don't know if there are any changes between arquitectures in u-boot sources..

pazos Wrote:
-------------------------------------------------------
> @davygravy: it does make sense, since dockstar
> files are under board/Seagate, but this is a minor
> fix that involves boards.cfg
>
kk, thanks.

> PD: Your configuration (from
> include/configs/dockstar.cfg) seems to work
> out-of-the-box applied to an iconnect wireless
> station, With new u-boot tested in RAM before
> flashing it into nand. It works like a charm with
> jeff's enviroment settings and can handle
> everything mentioned above (including booting
> original firmware (via the stock bootloader and a
> rescue enviroment saved on some nand address
> space))
>

I should have a GoFlexNet within a day or two and can tinker w/ support for that. The amount of work should be light, and I'll follow what you led w/ on the pogo_e02_support.patch, with goflexnet-a-la-doozan.patch and keep L2cache_disable.patch separated out from it.

I've updated the u-boot on my Pogoplug V1 (a.k.a. pogoplug E01) with the new dockstar u-boot, and as Jeff suggested, it works perfectly, as far as I can tell.

> @bodhi: pogo_v4 u-boot is build from cloudengines
> sources, not from denx repositories, this version
> is old (3.1.4) and l2_cache_disable patch does
> not apply cleanly to u-boot sources, but it
> doesn't matter cause the people behind
> archlinuxarm repported that their u-boot can boot
> newer kernels +3.2 without any patches applied.
> Under the hood pogov4 have an armada-based SoC
> instead of a Kirkwood SoC. I don't know if there
> are any changes between arquitectures in u-boot
> sources..

@ pazos : are you sure it is not Kirkwood? This page seems to indicate Kirwood... http://archlinuxarm.org/platforms/armv5/pogoplug-series-4

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

• davy's Github Repo's rescue-dg

I want to make sure I understand what is being said in this thread. I have a pogoplug e02. If I install debian according to the doozan method and then upgrade debian to wheezy will my pogoplug stop booting?

mcrump001 Wrote:
-------------------------------------------------------
> I want to make sure I understand what is being
> said in this thread. I have a pogoplug e02. If I
> install debian according to the doozan method and
> then upgrade debian to wheezy will my pogoplug
> stop booting?


Yes.


The reason is listed at the top of the thread... page one... yes, either latent u-boot bug or kernel regression... doesn't matter which... with the stock Debian kernel (version 3.2 or higher) it will not boot, in the vast majority of cases.


This is particularly bothersome if one considers the fact that in the near future, Wheezy will become Stable... (and Squeeze OldStable...). At this point, anyone debootstrapping an install in Wheezy will get the default 3.2 (or 3.3?) kernel, and if they have the current (ie. Jeff's excellent original) u-boot, it will almost certainly _not boot_.

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

• davy's Github Repo's rescue-dg

Just an FYI for anyone tinkering with git u-boot sources in and around Feb 2012...
http://lists.denx.de/pipermail/u-boot/2012-February/117972.html

really stinks... it caused me to have to have to JTAG my PogoE02 on an otherwise perfectly good u-boot.

Still not sure if CONFIG_MTD_ECC_SOFT is going to be needed from here on out (like maybe March 2012), in the config.

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

Fixed now in git (nand-custodial fork).
http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=commitdiff;h=1f7b1743d389fec616e9021012a03847f490cd18;hp=54e96680cb96fb7a4b8f43fd949c62054004d3e5

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/03/2012 11:34AM by davygravy.

@ pazos : I've now just about finished the patches for submitting to u-boot mainline - just one or two minor things to double-check ... I don't think they'll make it in for March 2012 stable release... merge window was closed a long time ago ..http://www.denx.de/wiki/U-Boot/ReleaseCycle That would put it in stable for the June 2012 release.


Everything is split up:

1. pogoplug_e02_support.patch (which will itself be split into file-by-file patches for submission; roughly 7 files are modified or created)



2. doozanized_u-boot_config_pogoplug_e02.patch (patches the mainline u-boot pogoplug_e02.h config file to have specific doozan-ish env values, plus some non-standard capabilities) - this will only be used if someone wants to build a drop-in replacement for Jeff's Uboot setup ... it maintains the footprint and feature set that he established



The Michael Walle Kirkwood-Level2Cache-disable.patch is already in git. Since it was not in git by the end of the last merge window, my guess is that it will _not_ make it into the March stable issue.

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

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 02/29/2012 07:21PM by davygravy.

I have checked the "prospective" vanilla/mainline u-boot image based on my basic patches... it will boot the debian installer at Martin Michlmayer's site[ http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html ] , as long as one first sets a single parameter:

setenv machid 831
saveenv

As Pogoplug E02 is not officially supported in the Linux kernel, we'll just call/mark it as Marvell Sheeva Reference Board Board...

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

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 02/29/2012 10:49PM by davygravy.

@davy

Would it be possible to get a binary of you new uboot that will work on the pogoplug-e02? I am new to the pogoplug but a daily user of linux. So some direction in flashing would be helpful. I have flashed my pogoplug-e02 using the archlinux arm instructions so if it's the same procedure just say so.

I appreciate the work you've done in setting up a build environment and would prefer not to have to do that myself. If you can't provide a binary of the new uboot then some instruction on setting up my own build environment and a list of the necessary patches would be greatly appreciated.

Best Regards

Hi!

Is the 3.2 problematic finally resolved? Would it be possible to make the corresponding binary available for download?

Thanks

I also installed the Wheezy kernel and now have the same issues on my pink PP

Please could someone help me with a new uboot binary if there is a working one ?


If not, is there any guide how to downgrade the kernel ?

Thanks

I'm putting up directions right now... these should be finalized and tested a few times by March 13. See the first post of the thread for a preview...

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

• davy's Github Repo's rescue-dg

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

davygravy Wrote:
-------------------------------------------------------

> Our criteria were simple:
> [*] make it boot 3.2 kernels and higher

Will it boot kernels less than 3.2, like say 2.6.38?

Thanks for your work. I'll give it a try once I understand that it can boot the ArmedSlack 13.37 kerenel (2.6.38.4).

Yes, good question. I'll clarify that in the post.

I guess that I should have foreseen that.

===============================
Now reads:
davygravy Wrote:
-------------------------------------------------------

Quote
davygravy
make it boot 3.2 kernels and higher, with
default (non-expert) config settings, as well as
the pre-3.2 stock Debian kernels,

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/12/2012 08:23PM by davygravy.

davygravy; as far as I can see vanilla u-boot from iconnect its not affected by this bug and is able to boot newer kernel than 3.2. I think that this error are only on newer uboots (the iconnect has 1.1.4 as the unbuggy pogoplug 4)... I've build a new u-boot for myself (I flashed openwrt's u-boot before) and it works as expected. I can submit you my patch but I think nobody will wants it (archlinux installer without touching the nand seems to be preferred)

Kk, thanks. No changes needed is the best solution then.

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

• davy's Github Repo's rescue-dg

Thanks a lot for posting your fix davygravy! Works absolutely flawlessy with my Dockstar.

Your explanation how to install was easy to follow, the thing which gave me the most headaches was the fact that I had to update via netconsole since I don't have a serial connection.
After hours of fiddling around it turned out that the problem was "nc" as described by Jeff in his tutorial. NC didn't allow my to interrupt the uBoot automatic boot process since it didn't accept my keystrokes as input so that I could abort the boot process. At the end I found a post somewhere in this forum pointing to "socat". socat offers much more options than NC, you can run it in a single command line and it keystrokes are properly send to uBoot. After I switched to socat everything was really easy.

That's great, Joschi75. I'm glad to hear that it worked for you.

Concerning nc vs. socat, there are a lot of options for using each of them...

I just recently tried socat, and it works fine. Over the years, nc has worked well for me, in both Ubuntu/Debian Linux, and with Mac OS X Leopard/SnowLeopard. I use either of these:

nc -klu 6666
nc -up 6666 192.168.xxx.yyy 6666

where 192.168.xxx.yyy is the ipaddr of your Kirkwood device/Pogo/Dockstar/GoFlexNet.

Of course, for socat:

socat STDIO UDP-LISTEN:6666

Of course, YMMV. I don't use Windows very much at all. So I can only comment on *nix-ish OS's.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/13/2012 05:43PM by davygravy.

Thanks davygravy.

Actually I was also using NC on Ubuntu (the traditional nc package) and also my command line did look exactly how you have stated, nevertheless I din't work out. I have no clue why, it was more or less a vanilla ubuntu installation I did setup a few days ago.Maybe something else is wrong in my environment but since socat did work flawlessly I don't think so.

I also tried this package on Windows level (http://svolli.org/software/asuc/) which is as far as I can see based on NC. While it was working in theory the key input was waaaay slow (it took ~15 minutes until a command that I entered to the uBoot prompt was really sent to my dockstar).

Thanks !

Works fine for me !

Great work !

Just wanted to say thanks -- the new u-boot works great.

On my Ubuntu machine, nc -l -u -p 6666 (with nc.traditional) is enough to give me read/write on the boot console; didn't seem to need to launch a second process.

Also this doesn't seem to be acknowledged, but I seem to be able to boot from ext3 as a root partition as well.

gz Wrote:
-------------------------------------------------------
> Just wanted to say thanks -- the new u-boot works
> great.
glad it was helpful
> On my Ubuntu machine, nc -l -u -p 6666 (with
> nc.traditional) is enough to give me read/write on
> the boot console; didn't seem to need to launch a
> second process.
that sounds right...
> Also this doesn't seem to be acknowledged, but I
> seem to be able to boot from ext3 as a root
> partition as well.
do you have some env var in your uboot env like:

usb_rootfstype=ext2

?

I think the default installation that Jeff set up has it defined as ext2, IIRC.

I simply deleted mine - it is no longer defined. IIRC, if it is defined as ext2, then it will boot _only_ usb root fs's of ext2, not ext3.

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

• davy's Github Repo's rescue-dg

I set mine to usb_rootfstype=ext3 to get it to work (which it does apparently).

So good news for anyone who was previously doing that separate /boot partition to use ext3 as rootfs; don't need to do that anymore.

davygravy Wrote:
-------------------------------------------------------
> 2. doozanized_u-boot_config_pogoplug_e02.patch
> (patches the mainline u-boot pogoplug_e02.h config
> file to have specific doozan-ish env values, plus
> some non-standard capabilities) - this will only
> be used if someone wants to build a drop-in
> replacement for Jeff's Uboot setup ... it
> maintains the footprint and feature set that he
> established

Hi Dave,

I've seen your work on the Denx mailing lists in getting the Pogoplug E02 support patches ready for the mainline.

I'm interested in trying to build a doozan-like u-boot replacement for my D-Link DNS325 (yet another kirkwood NAS).

The basic board support patches were added to the u-boot nand tree last month, so I'm interested in seeing your patches for "doozanizing" to see if I can modify them for the DNS325.

Are those patches available anywhere?

If I can modify the "doozanizing" patches for the DNS325, and I build with the codesourcery-2009q3 compiler, then should I be able to build a u-boot that will can be loaded by the existing D-Link u-boot and run from RAM for testing?

telzey Wrote:
" doozanized"

Well, a new view is thus coined... "to doozanize" ... sorry about that Jeff... ;) I guess we've been taking poetic (or prosaic) license w/ your surname. @ Jeff Doozan: please take it as a compliment : doozanize= to make full of good new features, to improve upon a basic framework, enhancing something's usability...

telzey, once something is in mainline, you only (probably) need to augment include/configs/<board_name>.h ... ie. you only have to add env variables and some extra features to the config file. Of course, I don't know anything about the GPIO on the dsn-325, so that is another question (leds & such)...

Jeff's directions for the original patch for the Dockstar is here: http://jeff.doozan.com/debian/uboot/build_uboot.htm
...this is full of good reading & playing...

IIRC, the general.patch creates the files needed to support the machine in u-boot, and then the mach-dockstar.patch defines capabillities & env vars in uboot environment. Some of the settings in the file are deprecated and no longer are available... or have been generalized to the kirkwood platform.

http://jeff.doozan.com/debian/uboot/patches/general.patch
http://jeff.doozan.com/debian/uboot/patches/mach-dockstar.patch

hth, davy

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

• davy's Github Repo's rescue-dg

Yes, I've already looked at Jeff's excellent directions. They contain a LOT of really useful information.

Jamie Lentin and Stefan Herbrechtsmeier have already done all of the heavy lifting by providing both u-boot and kernel patches for the DNS325, as well as registering a new machine ID.

My task is simply to find out what I need to change in the default u-boot config to get the extra features, and more importantly, how to get it to run from RAM so that I can test it without having to solder a JTAG connector onto the motherboard.

I can always try the boot-over-serial method if neccessary, but I've read that that might not work on all retail devices.

Since you've already created updated patches for the 2011.12 u-boot release, I was hoping to use those for comparison.

I've grabbed your dockstar-uboot2011.12_DG.patch from earlier in the thread, but was wondering if you'd changed anything in it since then.

Do you have any tips for getting a new u-boot to successfully run when loaded from within another u-boot?

I can certainly see from earlier in the thread that you had some fun getting that working!

It seems hit or miss. :^/

Inconsistent at best... I'm not sure the latest ones I've rolled will do that completely consistenly, but I can tell you that my replacements do seem to "chain" with the original u-boot, so that the native PogoPlug u-boot will load, execute and then in turn load and run the Pogoplug software.

Somewhere back in the thread I commented about what did seem to work more frequently, and what didn't. None of those patches are completely polished/finished... I'll wait to do that w/ the 2012.06 source.

BTW, now working on the GoFlexNet u-boot.

hth,

davy

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/18/2012 09:43PM by davygravy.

Thanks, I guess that I'll have fun experimenting ;-)

One thing that came up last month on the CodeSourcery mailing list was one guy having problems with his application when using a newer compiler than 2009q3, which seems to have been a problem here as well.

Here's his solution which may have no relation to the issues here ...

> Stepping through the disassembly for the simpler serial port application
> revealed the need for an additional compiler flag:
>
> -fno-zero-initialized-in-bss
>
> Adding this flag resolved the "regressions" in both the serial port and
> the USB applications when compiled with 2011.09. This flag was not
> required for 2009q3, which apparently was more lenient. Older compiler
> versions were not tested.