AKiTiO MyCloud Mini

[ykmag]

You are actualy noy using stock uBoot, the SoC will first read from the SATA, ther it finds uBoot and starts of there, very nice indeed. Nothing touched on the original device, and easy to backup image on disk.

[docbee]

Brilliant, that makes perfect sense! I did not know there "is a life before U-Boot"
Will try and report. 1000 thanks for the coaching!

[docbee]

Things worked well, alarm gets booted from SATA just fine

Unfortunately, kernel modules on rootfs do not match kernel in uImage so no luck with loading modules. Now I am looking for kernel sources (patched for dc01 or with necessary patch files) and a .config file. I had a look at the open source things from silverstone, but I dont know if the kernel sources there are the most recent avail and I am missing a .config file to get it compiled. Any hint would be highly welcome.

[docbee]

After having a farst start with your help, I am stuck at finding a uImage and a rootfs which fit together. I have a kernel "2.6.31.14_SMP_7821" up and running on the DC01 fine, but I cannot get a grip to a good populated "/lib/modules/2.6.31.14_SMP_7821" tree, which provides all the modules needed to get the system into full function. Could someone please provide a pointer where to download the "2.6.31.14_SMP_7821" module tree. If you have other matching pairs of uImage and rootfs, I will give it a try as well. Thanks.

[hippo]

the README in DC01 source tarball say:
the linux kernel configuration file is under linux-kernel/arch/arm/config/
ox7821_AP_nand_defconfig is the single drive 7821 with NAND support kernel config.
ox7821_defconfig is the single drive 7821 without NAND support kernel config.
choice one of above to be config, then make modules && make modules_install.

[docbee]

Fianlly, I have the 2.6.31.14 kernel sources from silverstone compiling fine. Great step forward, to have working kernel sources, plus a working config and I can populate a SSD with the uImage and all works fine so far. I even managed to put debian squeeze onto it, using the modules and kernel generated from alarm.

To make it a perfect solution, some things still remain open:
- it only shows 128MB of RAM, could someone please point me to a stage and uboot file that is able to start the dc01 in full 256MB mode?
- I don't have control to the front led. I tried with "proled" but no luck. Anyone who solved this on the 2.6.31.14 as shipped from silverstone? Do I need to apply a kernel source patch? I can't see /sys/class/led things as in other arm ports.
- Same with reset and power button on the back, would be great to have an option to poll these gpio lines from user space. Did anyone master this?
- I am just experimenting to read the uboot-env from NAND when linux has been started from SSD. This would allow to read the MAC and to transport it in a clever way into the running linux dristro, where mtd-tools will be able to grap data from it. I try to give MTD partitions as boot parameters, so that MTD devices do show up in user space. Did anyone already tried this?

[docbee]

Problem with getting the original MAC is solved. Simply compile MTD support into the kernel and you get two mtd devices. mtd2 contains lot of positions where the original MAC can be found by directly reading from the NAND via nanddump (not very elegantly, but it works).

Here is my c program "dc01mac" that reads the MAC from the byte stream generated by nanddump and calls "macchanger", a small utility available in the web, for setting the MAC.

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

#define TRYLENGTH       100

int try_mac (unsigned char *str)
{
  char buf[256];
  unsigned char *p, *q;
  int i;

  for (i=0, p=str; i < TRYLENGTH; ++i, ++p)
  {
    if (isxdigit (p[0]) && isxdigit (p[1]) &&
        (p[2] == ':') && isxdigit (p[3]) && isxdigit (p[4]) &&
        (p[5] == ':') && isxdigit (p[6]) && isxdigit (p[7]) &&
        (p[8] == ':') && isxdigit (p[9]) && isxdigit (p[10]) &&
        (p[11] == ':') && isxdigit (p[12]) && isxdigit (p[13]) &&
        (p[14] == ':') && isxdigit (p[15]) && isxdigit (p[16]))
    {
      sprintf (buf, "/usr/local/bin/macchanger -m %c%c:%c%c:%c%c:%c%c:%c%c:%c%c eth0",
        toupper (p[0]), toupper (p[1]), toupper (p[3]), toupper (p[4]),
        toupper (p[6]), toupper (p[7]), toupper (p[9]), toupper (p[10]),
        toupper (p[12]), toupper (p[13]), toupper (p[15]), toupper (p[16]));
      system (buf);
      exit (0);
    }
  }
}

int main (int argc, char *argv[])
{
  char pattern[] = { "Eth" };
  unsigned char buf[4096 + 200], *p;
  unsigned char c;
  int i, len, patlen;

  patlen = 3;
  for (len=4096; len; )
  {
    len = read (0, buf, 4096);
    for (p=buf, i=len-patlen; i>0; ++p, --i)
      if (strncmp (p, pattern, patlen) == 0)
        try_mac (p);
  }
  return 0;
}

In my debian install I do call this directly before dhclient starts asking the router for a mac-based IP address. Receving the MAC from NAND is only executed on the first run. Script is located in "/etc/dhcp/dhclient-enter-hooks.d/".

Code: Select all

#!/bin/sh
if [ -f "/var/run/macset" ]
then
  echo -n ""
else
 /usr/sbin/nanddump /dev/mtd2 2>/dev/null | /home/meteohub/dc01mac >/var/run/mac
set
 cat /var/run/macset
fi

Problem with LEDs and RAM size still not solved for me.

Regarding the LEDs I did find the "proled" script that directly pokes into memory to get some GPIO lines toggled that affect the LED, but the used memory positions from pogoplug v3 don't match with dc01. The other way to get LEDs accessible the gentlemen way via a kernel module oxnas-led did also bring me to a stop, as I can't find module sources for it and the compiled 2.6.31.6 module is not compatible to my kernel compilation.

Any hint would be highly welcome.

[WarheadsSE]

You'll need to find the GPIO lines used, period. Then Proled can be adjusted. The module or "gentlemen way" is just designed to turn it off on the V3's.

[docbee]

I would love to do that. Looking into the open source material from silverstone I see that the SOC provides gpioa 0-31 and gpiob 0-17. In the example they also did publish (don't know is that matches the dc01) gpiob 14-17 are named with LED and gpiob 10-11 are somehow related to buttons.

Lets say gpiob14 is the line controling the LED (I guess in real world it must be two as the LED has two colors). How do I translate "set gpio14 to high" into the devmen2 calls as lined out below in the pogoplug proled example snippet?

Code: Select all

/sbin/devmem2 0x44100014 w 0x00030000 > /dev/null
/sbin/devmem2 0x44100018 w 0x00020000 > /dev/null

According to the documentation register "0x44100014" is named "output clear" and "0x44100018" is named "output set", both for gpiob only. But how relate "0x00030000" and "0x00020000" to that? bit mask for gpio lines? Does "0x00030000" resets gpiob16 and gpiob17, while "0x00020000" sets gpiob17? Sorry for asking for help again.

[docbee]

One step further... This code snippet reports if reset button is pressed on DC01.

Code: Select all

/sbin/devmem2 0x44000000 | grep Value | awk '{if (and (strtonum ($6), 0x02000000) > 0) print "0"; else print "1"}'

When I do understand gpio enumeration correctly the reset button is connect to gpioa25.