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

Hi ebbes,

> Sorry, I don't quite understand what's exactly
> going on: Does your drive work in external drive
> but not when plugged in directly or does it work
> either way?

I did the reversed test. The drive inside the 2.5" enclosure works fine with ide reset. So I took it out and plug it in the SATA slot, and ide reset failed.

This also proved that SATA I and SATA II drives behave the same way in that it failed if we plug it in the SATA slot. (My Seagate GoFlex drive is SATA I, and the drive in the enclosure is SATA II).

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

Okay, so this is definitely some kind of power issue. My drive and markweng's drive are actually the same model (except for revision) and your drive is obviously the same (is it spinning at all? Could you start uboot and plug it into SATA port once you reach the u-boot prompt?).
I don't think that timings are wrong, somehow the initialization sequence is wrong. The question is: do other/more commands need to be sent or is there some register that has to be written to in order to spin the drives up?

EDIT: Ahhh, I'm so curious, I think I'll import a Pogoplug V4. There's never too many Linux boxes to own. You probably can't imagine how difficult it is to get a Pogoplug in Germany... Nothing on ebay (except for Pogoplug Pro which have no recent kernel option) and the other options are clearly overpriced.



Edited 1 time(s). Last edit at 03/08/2014 05:13PM by ebbes.

I agreed. It seems to be a power issue, because leaving it in the slot while booting UART, it does not spin at all.

And I also did try (once), to plug the GoFlex drive in while at U-Boot prompt, and it hung. I had to recycle the power. I'm gonna try the bare SATA II drive to see if it behaves differently.

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

Okay, gonna be fun digging in the driver. Somehow sata power has to be enabled...

See my last post's edit (your post was not yet there when I started editing :D).

I will have a look at the nsa320 once I get my power supply for it out storage, and for the nsa325, I have to give a rest until we can figure out how to get a test uboot running.

Could somebody who has the NSA325 post a complete U-Boot boot log? I could help trying to find more info on the SoC to see if there are different ways to run U-Boot. For example, the SoC for iConnect is 88F6281_A0:

U-Boot 2013.10 (Feb 21 2014 - 20:02:23)-tld-2
Iomega iConnect

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  512 MiB

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

I can tell you it is an 88F6283

I have pulled up my NSA320, and it seems to be mostly working with the changes I pulled in.

U-Boot 2013.10-g268e791 (Mar 07 2014 - 14:24:23)
ZyXEL NSA320 2-Bay Power Media Server

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  128 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Warning: failed to set MAC address

MV88E1318 PHY initialized on egiga0

USB is powered on.



Edited 1 time(s). Last edit at 03/12/2014 03:34PM by WarheadsSE.

So You managed to enable USB power without touching the common USB code? That's nice! Then CONFIG_USB_POWER and the function usb_power_on() can be removed - they are unused, and not needed anymore.

Will do.

EDIT: done.



Edited 1 time(s). Last edit at 03/12/2014 04:37PM by WarheadsSE.

At this point, I need to put in a sane default environment, and check why it is not seeing the existing environment as valid.

Otherwise, as far as I can tell NSA325 & NSA320 are good. I don't have a 310 to try.

Cool!
Reminder: t's more convenient to *not* saveenv in UBoot until after you can boot with that default envs.

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

We have discussed this env thing already - the start offset has been moved, so You have to either define it back to the address that factory u-boot uses, or copy the original env content in nand to the new location.
I guess the values that matched factory would be:

#define CONFIG_ENV_ADDR 0x100000
#define CONFIG_ENV_OFFSET 0x100000 /* env starts here */

instead of the current

#define CONFIG_ENV_ADDR 0x120000
#define CONFIG_ENV_OFFSET 0x120000 /* env starts here */

Right, I forgot about that move.

I can copy default env from any of the other pre-configured ones we already have in this project, of course

Just don't forget to salvage ethaddr.

PlanetEater Wrote:
-------------------------------------------------------
> Just don't forget to salvage ethaddr.

Right! either document that in the installation steps, do it the script, or generate a local ethaddr automatically for booting temporarily.

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

I might have a NSA310 owning Volunteer to test on.

ebbes, I would send you my spare V4, but shipping it to Germany from USA in a padded envelope would still cost 4x the actual price of the device... :-!
Thanks for your efforts on this so far, I will try it shortly using external power.

Today I finally got my Pogoplug V4 and after soldering a uart connector, I can reproduce the problem. I can confirm that the hard drive does not spin at all while it's working when using external power.
I don't know what's the problem yet, but now I will try to find and fix the problem. I'll begin in the next few days...

EDIT: okay, I lied about beginning in the next few days. I already started :D
First thing is: I looked in the wrong place. Original U-Boot starts SATA power during initialization, not when calling ide_init. However, another function is very promising:

/*******************************************************************************
* mvHddPowerCtrl - 
*
* DESCRIPTION:
*       This function set HDD power on/off acording to env or wait for button push
* INPUT:
*	None
* OUTPUT:
*	None
* RETURN:
*       None
*
*******************************************************************************/
static void mvHddPowerCtrl(void)

It uses hddPowerCtrl=no from environment, so I'll further examine this.



Edited 1 time(s). Last edit at 03/18/2014 11:24AM by ebbes.

ebbes,

We might have to reset the SATA PHY. My theory is that is was set (in error) to a Shutdown state, thus need to be brought up to Operational by U-Boot.

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

It turns out that it really isn't mvHddPowerCtrl that turns on the HDD... Even converting it to a dummy would still spin up the HDD.

bodhi Wrote:
-------------------------------------------------------
> ebbes,
>
> We might have to reset the SATA PHY. My theory is
> that is was set (in error) to a Shutdown state,
> thus need to be brought up to Operational by
> U-Boot.
Might be... but I don't really think so since the HDD spins up before any SATA initialization routines are called when using original U-Boot.

I just had a look at the PCB. It seems like SATA power pin 11 is shorted to GND (via 0-Ohm-resistor) which disables staggered spin-up, so this is not the problem. However, one of the three +5V power pins seems to have a resistance of about 50 Ohm against the other two 5-Volt pins. Maybe this indicates that 5-Volt power has to be somehow enabled? When powering my HDD using a simple self-made adapter (GND to USB GND, +5V to USB +5V), the HDD spins up immediately on connection. The Pogoplug Power connector only seems to connect GND and +5V, no 3.3V or 12V. Since all GND pins are shorted to GND (thus staggered spin-up should be disabled), the only remaining option is lack of +5V power for the HDD to spin up. So I assume there really is something missing to enable +5V, it shouldn't be about any SATA PHY status.
Maybe I should try shorting all 3 +5V pins...

EDIT: okay, my assumption was only partially correct: when using original U-Boot, the +5V pins have +5V potential against GND, as it should be. When using patched mainline U-Boot, those pins have less than +1V potential against GND. So I guess our problem is in fact that SATA power has to be enabled somehow. At least I know what I have to search in the code now.

EDIT²: Fact: SATA power is linked with USB power. EDIT³: Nope. Don't know what I did wrong, but this is not the case.

EDIT⁴: The call to mvCtrlEnvInit in mv_main.c:275 enables SATA power. Without this call, my HDD won't spin up. mvCtrlEnvInit is defined in mvCtrlEnvLib.c:132. So this is where the magic happens, I just have to find out WHAT this does exactly.

EDIT⁵: Okay, the magic really seems to be

MV_REG_WRITE(MPP_CONTROL_REG2, mvBoardMppGet(2));
/* MPP_CONTROL_REG2 is 0x10008 */

if this is called in mv_main.c (I added a while (1) udelay(1000); so this is actually the last [real] command executed!), the HDD will spin up. If this call is missing, the HDD won't spin up.



Edited 5 time(s). Last edit at 03/19/2014 08:07AM by ebbes.

Don't want to do an EDIT⁶. And this post is possibly interesting. At least I think so.

U-Boot 2014.01-pogoplugv4-dirty (Mar 19 2014 - 15:01:20)
Pogoplug v4/Mobile

SoC:   Kirkwood 88F6281_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  128 MiB
MMC:   kwsdio: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Warning: failed to set MAC address

Hit any key to stop autoboot:  0 
Pogov4> ide 
ide - IDE sub-system

Usage:
ide reset - reset IDE controller
ide info  - show available IDE devices
ide device [dev] - show or set current device
ide part [dev] - print partition table of one or all IDE devices
ide read  addr blk# cnt
ide write addr blk# cnt - read/write `cnt' blocks starting at block `blk#'
    to/from memory address `addr'
Pogov4> ide reset

Reset IDE: Bus 0: OK Bus 1: not available  
  Device 0: Model: SAMSUNG HN-M101MBB Firm: 2AR10001 Ser#: S2R8J1KBB00967
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
Pogov4>

HDD is directly plugged into Pogoplug, so no external power.
My findings from above did the trick: The macro I mentioned:

MV_REG_WRITE(MPP_CONTROL_REG2, mvBoardMppGet(2));
is fully expanded to
*(volatile unsigned int*)(0xf1010008) = (unsigned int)0x00551100;

However, kirkwood_mpp_conf(kwmpp_config, NULL); will override this and stop SATA power again, so I disabled it for now. Don't know about the effects yet. But at least I know exactly where I have to dig. And once I found the problem, it should be easy to convert this ugly pointer arithmetics into a nice u-boot writel() call.

EDIT:
Some background information.
0xf1010008 is KW_MPP_BASE + 2 * 0x4, which means the second register for multi-purpose-pin (MPP) configuration. Each of these registers controls 8 MPPs. In that case, we have to control MPP_16_23, i.e. MPPs 16 to 23.
0x00551100 is a MPP configuration vector. The least significant 4 bit (the last 0) controls MPP 16 and sets it to GPIO mode. The most significant 4 bit (the first 0 after 0x) controls MPP 23 and sets it to GPIO mode.
In binary, this vector is 0b 0000 0000 0101 0101 0001 0001 0000 0000 (groups of 4 to make it easier to read), this might help understand this 4-bit thing.
So what was done by that Cloud Engines U-Boot is:

• Set MPP 16, 17, 22, 23 to GPIO mode (0x0)
• Set MPP 18 to NF_IO0 mode (0x1)
• Set MPP 19 to NF_IO1 mode (0x1)
• Set MPP 20 to SATA1_ACTn mode (0x5)
• Set MPP 21 to SATA0_ACTn mode (0x5)

The last two lines look very promising.
In mainline U-Boot, this MPP configuration is done through kirkwood_mpp_conf(kwmpp_config, NULL); which would override SATA power (i had enabled using writel) when executed. This indicates that the relevant pins were misconfigured. And it turns out this was the case: The clean patch that enables SATA power properly is in fact really short.

diff --git a/board/cloudengines/pogo_v4/pogo_v4.c b/board/cloudengines/pogo_v4/pogo_
index 25f4ae3..1c99562 100644
--- a/board/cloudengines/pogo_v4/pogo_v4.c
+++ b/board/cloudengines/pogo_v4/pogo_v4.c
@@ -74,8 +74,8 @@ int board_early_init_f(void)
                MPP17_SD_D3,
                MPP18_NF_IO0,
                MPP19_NF_IO1,
-               MPP20_GPIO,
-               MPP21_GPIO,
+               MPP20_SATA1_ACTn,
+               MPP21_SATA0_ACTn,
                MPP22_GPIO,
                MPP23_GPIO,
                MPP24_GPIO,

I think that should solve the SATA power problem once and for all.

EDIT²: See my GitHub repo for complete sources. I also attached a compiled uboot for booting via UART (with kwboot tool patching it on-the-fly) or flashing to NAND (don't do this unless you're absolutely sure you know what you're doing and how to recover). Filename: uboot.mtd0.kwb. However, see next part of post for version with different MMC clock frequency.

sha1: c425285b3cb55607e51e1522a64887bcd137bbb8
md5:  d5df1e7ab90b59c5b8e32e9ae1251ece

EDIT³: I had some MMC problems with my V4 (One SD card worked fine in Pogoplug Mobile, but failed in V4; U-Boot was the same build), so I adjusted the MMC base clock. In last build, it was 166 MHz. It seems like 200 MHz is more reliable (this SD card works perfectly now). Please test both builds if you have any SD cards at hand. Another option is 100 MHz (which also seems to work), but I did no further tests with this frequency.
Build with 200 MHz is called uboot.mtd0_200MHz.kwb (U-Boot 2014.01-pogoplugv4 (Mar 19 2014 - 21:05:42) and has those hashes:

sha1: 64a1500259214f4c0f7989fcbe1479299e26519f
md5:  b96574b1ee60d525be7e3c8bceeb6fda

I pushed those patches to GitHub already.



Edited 4 time(s). Last edit at 03/19/2014 03:17PM by ebbes.

Great works, ebbes! You've just made the Pogo V4 much more interesting for a lot of people :)

Who would have thought that the solution was in plain sight alll along:)

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

bodhi Wrote:
-------------------------------------------------------
> Great works, ebbes! You've just made the Pogo V4
> much more interesting for a lot of people :)
>
> Who would have thought that the solution was in
> plain sight alll along:)

Yeah, I was surprised that it's so simple to fix. I hope that these patches work flawlessly for everyone so that there is a single U-Boot that works for all use cases. At least for my Mobile and V4, everything seems to work just fine (I'm using the build patched for 200 MHz MMC clock).

I think our (my) mistake was making the wrong assumption that the 6192 is the same as the 6281 chip in this regard :) If you look at the GoFlex Net/Home patches, there is no need to trigger the GPIO to turn on SATA power. It must have been an oversight by Marvell, so they had to turn it on by U-Boot. Or perhaps it was by design so to save energy? who knows.

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

I rather think this is by PCB design. GoFlex Net seems to have SATA directly powered. 6281 does also have SATA ACTn GPP modes.

Interesting! Time to try my pogo v4.

-syong

By the way: does anyone know how to boot stock Pogo software with a recent U-Boot? I tried it, but it always fails (i.e. no further output) after Uncompressing Linux... booting the kernel.

It might not like `mainlineLinux=yes`, but I can't say for sure.

I actually set mainlineLinux=no, but I doubt it has any effect: there is no reference at all to this env variable. However, in original U-Boot, there are some references:

static void setup_ce_tag (void)
{
	unsigned int cpu = 0;
#if defined(MV78200) && defined(DUAL_OS_SHARED_MEM_78200)
	cpu = whoAmI();
#endif
	params[cpu]->hdr.tag = ATAG_CE_UBOOT;
	params[cpu]->hdr.size = tag_size (tag_ce_uboot);

        params[cpu]->u.ce_uboot.ce_tagkey  = 0x5843453A;
        params[cpu]->u.ce_uboot.ce_size    = sizeof(struct tag_ce_uboot);
        strncpy(params[cpu]->u.ce_uboot.ce_boardid, CE_BOARDID, sizeof(params[cpu]->u.ce_uboot.ce_boardid));

	params[cpu] = tag_next (params[cpu]);
}

So I guess Pogoplug's kernel needs some special information (CE_BOARDID etc) that mainline U-Boot does not provide. I think I'll have a look into that.

EDIT: Nope, doesn't work. This ATAG isn't even parsed by Pogoplug kernel (if the kernel sources really match the compiled binary...). However, struct tag_mv_uboot might be interesting, altough there are no extremely important information in it. Maybe tag_serialnr or tag_revision might be needed? I'll dig into this tomorrow.



Edited 1 time(s). Last edit at 03/21/2014 01:42PM by ebbes.