Kirkwood U-boot - Getting all supported Kirkwoods on-board

I've pushed new commit to GitHub: adding Netgear Stora box, cleanup iConect directories, and removing extraversion from headers file.

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

I will start in on the NSA3xx series.

I created a (working/tested) patch for uboot-2014.01 for nsa310. If you want to include I can upload it here.

Pras

@PlanetEater & Pras et al,

Certainly everybody is welcomed to contribute :) So you could upload your patches here for information. However, we should do it a little more methodical. Let's wait for WarheadsSE to get the NSA3xx up and running, before we'll try to improve. And anybody looking at the GitHub Kirkwood patches, if you see anything we can improve then please post.

Importan Note: things such as setting u-Boot default envs for a device will need to be tested by wiping out the NAND envs checksum or the entire sector first. So it's best to be done by someone who has the device and a recovery plan.

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

Key words: "and a recovery plan"

@Pras - Please feel free to fork & PR the repo!

Hello,

this is a cool idea. I initially updated my GoFlex Net to Bodhi's u-boot binary to be finally able to boot kernels without attaching device tree blobs.
However, I'd like to suggest one improvement: Add "#define CONFIG_CMD_BOOTZ" to the board's configuration to enable bootz command. This makes it possible to boot zImage files (i.e. files without 64-byte kirkwood-header) as they are shipped in Arch Linux ARM's linux-kirkwood-dt package (or the custom kirkwood kernel I use) removing the need to call mkimage after every kernel update.
In fact, I just compiled u-boot for goflexnet with bootz enabled and successfully booted a device-tree enabled kernel using bootz 0x800000 - 0x1c00000, so it seems to work just fine.
(By the way: which toolchain do you recommend? As I was not sure whether Arch Linux ARM's arm-unknown-linux-gnueabi would produce working binaries, I used CodeSourcery's 2013.11-33 release. Problem is that tftp loading and running didn't work, but it works just fine once flashed (afaik re-running u-boot is only supported on certain architectures and kirkwood is not one of them?))
Long story short: I suggest to enable CONFIG_CMD_BOOTZ in all kirkwood configs. (If you want to, I can create a pull request on GitHub)

ebbes,

Thanks for the suggestion! it's a little nice feature to have. I'll take a look.

> re-running u-boot is only supported on
> certain architectures and kirkwood is not one of
> them?

Actually, U-Boot does not support this (people have been doing this as an undocumented feature). It would work if the image is almost the same (code, data allocation,…). But it was designed to run at initial state only (power up or reset).

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



Edited 1 time(s). Last edit at 03/02/2014 04:25PM by bodhi.

Hi ebbes,

> In fact, I just compiled u-boot for goflexnet with
> bootz enabled and successfully booted a
> device-tree enabled kernel using bootz 0x800000 -
> 0x1c00000, so it seems to work just fine.

You are running Arch and the DTB was loaded at 0x1c00000 ?

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

bodhi Wrote:
-------------------------------------------------------
> Actually, U-Boot does not support this (people
> have been doing this as an undocumented feature).
> It would work if the image is almost the same
> (code, data allocation,…). But it was designed
> to run at initial state only (power up or reset).

I know. But as far as I read reexecuting u-boot is supported on blackfin cpus.

> You are running Arch and the DTB was loaded at 0x1c00000 ?
Yes. However, I'm using a custom compiled kernel and specified all load addresses manually.

By the way: I've done some tests on my Pogoplug Mobile. After modifying some patches I found online (that did not make it into uboot mainline because they aren't very clean), I got SD card booting to work:

U-Boot 2014.01 (Mar 03 2014 - 15:48:00)
Pogoplug v4/Mobile

SoC:   Kirkwood 88F6281_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  128 MiB
MMC:   mvsdio: 0
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Hit any key to stop autoboot:  0 
Pogov4> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootdelay=1
Pogov4> mmc init; ext2load mmc 0:1 0x00800000 /boot/uImage
mmc - MMC sub system

Usage:
mmc read addr blk# cnt
mmc write addr blk# cnt
mmc erase blk# cnt
mmc rescan
mmc part - lists available partition on current mmc device
mmc dev [dev] [part] - show or set current mmc device [partition]
mmc list - lists available devices
mmc setdsr - set DSR register value

3930736 bytes read in 1355 ms (2.8 MiB/s)
Pogov4> bootz 0x800040
Kernel image @ 0x800040 [ 0x000000 - 0x3bfa30 ]
Using machid 0xf78 from environment

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0

bootz was only used for demonstration purposes, bootm 0x800000 would have worked, too.
And yes, the kernel successfully boots.

However, those patches need some more cleanup (I removed some timing selection based on cpu model, but since Pogoplug v4 should be the only device to use these patches, that should be fine) as they produce some compiler warnings during compilation.
Another "issue": davygravy's uboot for Pogoplug v4 needed mmc init command to initialize mmc subsystem. In this build, it is enabled by default. Caling mmc init will display mmc command usage instruction (see above), but will do no harm, so this might simply be ignored.
However, SATA does not work as I don't own a v4 and don't plan to solder the needed SATA components onto my Pogoplug Mobile, so therefore I did not look into this.

I do have a V4, and I will hopefully be testing this. So, any PR you make would be appreciated.

Okay,
I cleaned the SD/MMC bits up (no more compiler warnings) and it still works on my Pogoplug Mobile (even when flashed). Currently working cool features are:

• ext4
• device tree support
• bootz command
• sd card booting
• usb booting (On V4, only top port should work as the rear ports are connected through PCIe)

Netconsole should hopefully work, will test this later.
Ubifs/Nand should work as I didn't change anything, but I'm not able to test unless someone provides me a nice test command (I don't have anything useful in my environment... And I don't even know if my Nand contains anything at all)
I will do some more testing and push the code to my Github repo (along with precompiled binaries) in the next days (when I have more time).
Even if I can't get sata to work: the current feature set would still be an improvement over davygravy's current Pogoplug v4 binary.

Hi guys,

in case you were wondering: yes, I am still alive ... Also, I am hoping to be able to play around with my Kirkwood machines a little again in the next few weeks (and maybe stay online, at least intermittently, even after that). Which is why I would like to ask two things:

a) What is the current status concerning consolidation? Especially, what about the NSA3xx? According to the current README (as of March, 04, 2014), they are not yet supported.

b) Can I maybe help with testing? Surely, helping in development is beyond me, but I do have quite a few boxes, although I do get the impression that between the active members of this HIGHLY RECOMMENDABLE initiative, you have all of those as well. Anyway, here is the list:

Dockstar
GoFlexNet
GoFlexHome
Pogo E02
Pogo Mobile (= V4?)
NSA320
NSA325 (possibly not working; has been dormant since August 2013 ...)

Please let me know if there is something you would want me to do in this context and I will try to live up to the task.

And, one final question: suppose I wanted to have a uBoot for all those machines, which one would you have me use as of now?

As always: thanks for all your efforts!

Cheers,

chessplayer

---
Standart ist der Standardfehler

@chessplayer
I have the 320's on my plate to bring to 2013.10, and once we have all this consolidated, I expected we will bring them to 2014.1, and possible mainline'd.

Ok, thanks. I guess you will be announcing here when this is done. Until then, I will keep myself occupied with updating kernels ...

---
Standart ist der Standardfehler

chessplayer Wrote:
-------------------------------------------------------
> Ok, thanks. I guess you will be announcing here
> when this is done. Until then, I will keep myself
> occupied with updating kernels ...

If You are desperate: https://github.com/PlanetEater/uboot-nsa320/releases/tag/v2014.01

This is for the NSA320 only.

chessplayer,

Welcome back :)

> And, one final question: suppose I wanted to have
> a uBoot for all those machines, which one would
> you have me use as of now?

If you can't wait and/or want to try out the new features. You could use ones I've uploaded here: http://forum.doozan.com/read.php?3,12381. Or clone the Git and build your own images.

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

I have pulled the changes for the nsa320 from the your repo @PlanetEater

I will base the 325 off that, and *attempt* the 310, but does anyone have one of these??

( I am also moving the board from board/Marvell to board/zyxel)

Cool!
I suggest having a look at boards.cfg. When I started, I rebased the original repo I forked on top of upstream version 2014.01-rc2, and noticed that the format of this file completely changed - I think that the one in my repo won't work for 2013.10.

Yeah, I just added appropriate lines for 2013.10 across all nsa3xx's

Another warning: for some reason, the environment location was defined to be one eraseblock away compared to the factory u-boot setup, and I left it that way. The correspondig lines from my /etc/fw_env.config:

# MTD device name       Device offset   Env. size       Flash sector size

# zyxel nsa320, stock u-boot
##/dev/mtd1                0x00000         0x20000         0x20000
# zyxel nsa320, new u-boot
/dev/mtd1                0x20000         0x20000         0x20000

Okay, so you're putting the new uboot's env @ stock+1 block, and there is plenty of storage for that?

Well, not me, the original author of the code.
IIRC the uboot-env partition size is 4 eraseblocks, and the environment itself uses up only one.

Well the 325 has a completely matching NAND partition layout. I wonder if there is room to move the stock u-boot too..

Very likely yes. I guess that was the point of this moving of the start address at the first place - to have a backup of the original environment, which You automagically get back if You need to reflash the stock version.

Oh, if You mean the whole stock u-boot itself, not just the env, I'm not sure of that...

WarheadsSE Wrote:
-------------------------------------------------------
> Well the 325 has a completely matching NAND
> partition layout. I wonder if there is room to
> move the stock u-boot too..

I'd suggest we move the envs to 0xC0000 to be consistent with other Kirkwood uBoots
(Of course only if you could do this in the current mtds settings, other wise it's OK)

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



Edited 1 time(s). Last edit at 03/04/2014 05:05PM by bodhi.

Have I ever mentioned how much I dislike ZyXEL's EE's for hooking up the MCU directly to the power supply, and dangling it off the PHY LED[2] in tristate?
...
The NSA325 does support kwboot. However, that #$%^*%^*R MCU screws up the process.

WarheadsSE,

Ah! thanks for that info. I'm wondering could it be that the quirky boxes like Pogo V4/Mobile suffer similar problem? For the Pogo V4/Mobile, to use kwboot you must repeatedly control-C and rerun many many times (varied from 3 to 25 times last time I counted) before the handshake works :)

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

ebbes,

> I will do some more testing and push the code to
> my Github repo (along with precompiled binaries)
> in the next days (when I have more time).
> Even if I can't get sata to work: the current
> feature set would still be an improvement over
> davygravy's current Pogoplug v4 binary.

When you've done, and if you'd like, please do a PR on the branch 2013.10-kirkwood.
Thanks.

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