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

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.