Čítanie sériového čísla na SoC Allwinner pod Linuxom

23.12.2013 09:43 | Přečteno: 2818× | Hardware | | poslední úprava: 24.12.2013 09:44

Dnešný mikroblog je určený tím, ktorí by potrebovali čítať sériové číslo na týchto SoC, alebo tým ktorých zaujíma ako sa vôbec sériové číslo SoC číta / zapisuje.

Sériové číslo (alebo presnejšie povedané root kľúč 0-3) je na SoC allwinner zapísané v eFUSE pamäti namapovanej do fyzickej pamäte pod základnou adresou 0x01c23800. Podľa dokumentácie je do tejto pamäte možné zapísať prakticky ľubovoľných 128 bitov dát. K zápisu je však potrebné fyzicky odpojiť pin EFUSE_VDDQ od GND a pripojiť ho na určité napätie (detaily nepoznám). Na čítanie nie je potrebná žiadna modifikácia hardvéru a root kľúče 0-3 by mali byť zapísané priamo výrobcom (niekedy sú v tejto pamäti zapísané samé nuly).

Štruktúra

Názov registra	Offset	Veľkosť
SID_KEY0	0x00	4 B
SID_KEY1	0x04	4 B
SID_KEY2	0x08	4 B
SID_KEY3	0x0c	4 B
SID_WRITE_DATA	0x40	4 B
SID_WRITE_CTRL	0x44	4 B

Pre nás zaujímavú časť môžme zapísať nasledujúcou štruktúrou v C:

typedef struct DeviceSID {
	uint32_t key0;
	uint32_t key1;
	uint32_t key2;
	uint32_t key3;
} DeviceSID;

Čítanie

Zariadenia sú priamo mapované vo fyzickej pamäti. V užívateľskom priestore nie je možné pristupovať do fyzickej pamäte pretože všetky adresy sú virtuálne. Prístup do fyzickej pamäte sa dá zabezpečiť len namapovaním časti fyzickej pamäte do virtuálnej pamäte užívateľského procesu volaním mmap. Offset musí byť zarovnaný na veľkosť stránky čo je v tomto pípade 4096B (2¹²). Počiatočnú adresu môžme zistiť buď v referenčnej dokumentácii alebo hrabnutím do zdrojových kódov kernelu. Pre nás zaujímavou konštantou je SW_PA_SID_IO_BASE (0x01c23800).

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/mman.h>

#define IO_BASE_ADDRESS  0x01c00000
#define SID_BASE_ADDRESS 0x01c23800
#define IO_SIZE          0x00300000
#define SID_MMAP_START   ((SID_BASE_ADDRESS >> 12) << 12)

typedef struct DeviceSID {
  uint32_t key0;
  uint32_t key1;
  uint32_t key2;
  uint32_t key3;
} DeviceSID;

int main(int argc, char *argv[])
{
  int fd;
  // prístup do fyzickej pamäte z userspace je možný cez /dev/mem
  if ((fd = open("/dev/mem", O_RDONLY | O_SYNC)) == -1) {
    return -1;
  }
  // volatile nie je nutné, ideme čítať statické dáta
  void *io = mmap(0, 4096, PROT_READ, MAP_PRIVATE, fd, SID_MMAP_START);
  if (io == MAP_FAILED) {
    close(fd);
    return -2;
  }

  // prečítaníe SID
  DeviceSID serial;
  serial = *(DeviceSID *)(io + (SID_BASE_ADDRESS - SID_MMAP_START));

  // upratovanie
  if (munmap(io, sizeof(DeviceSID)) == -1) {
    close(fd);
    return -3;
  }
  close(fd);

  printf("%04x-%04x-%04x-%04x\n", serial.key0, serial.key1, serial.key2, serial.key3);
  return 0;
}

V príklade sa mapuje celá stránka veľkosti 4kB. Ak by som modifikoval main funkciu nasledovne:

  // ...
  void *sid = mmap(0, sizeof(DeviceSID), PROT_READ, MAP_PRIVATE, fd, SID_BASE_ADDRESS);
  if (sid == MAP_FAILED) {
    close(fd);
    return -2;
  }

  DeviceSID serial;
  serial = *(DeviceSID *)(sid);
  // ...

kernel by pri pokuse o mmap vrátil errno EINVAL.

To by bolo z dnešného malého problému s A13 hádam všetko, nabudúce skúsim niečo záživnejšie ako je hardvérové dekódovanie videa na A13 (mimochodom v cene A13 + napájacieho obvodu je aj poplatok za h.264, celé to stojí 5.35€ / kus pri fakt veľkej objednávke).

       

Komentáře

[disorder]

chcelo by to podporu dekodovania v xbmc na nejakej distribucii out of the box

[mirec]

No ono to nie je s oficiálnymi drivermi žiadna sláva. Síce to dokáže dekódovať kadečo, ale linuxové knižnice sú totálne odfláknuté a ani najobyčajnejšie h.264 nedokáže prehrať bez --weightp 0 pri enkódovaní h.264. Open source implementácia knižníc je na tom čo sa týka podpory h.264 lepšie ale dekóduje zatiaľ málo formátov.

[disorder]

nie, proprietarne kniznice funguju

http://linux-sunxi.org/CedarXVideoRenderingChart

[disorder]

aha, tak iba niektore. ja sam som to neskusal, kedze sa mi s tym nechce babrat, na androide to dekoduje, ale xbmc na to potrebuje iny video prehravac (neviem ci sa nieco odvtedy zmenilo)

[ovoce]

ani najobyčajnejšie h.264 nedokáže prehrať bez --weightp 0 pri enkódovaní h.264

Hehe... náhodou touhle funkcí se ta krabička vyrovnává kvalitě AppleTV nebo iTV nebo jak se ta jejich pytlovina jmenuje. :)

[Luboš Doležel (Doli)]

V príklade mapujem celý I/O priestor pretože kernel nedovolí mapovanie kdekoľvek.

Nestačilo by mapovat jednu stránku (4096 bajtů)?

[mirec]

Skúšal som mapovať časť I/O, ale žiaden offset v I/O mi mmap neakceptoval (EINVAL).

[andree]

Ide o to ze aj offset, aj velkost musia vascsinou byt zarovnane na PAGESIZE...

Druha vec je ze pouzivat na toto /dev/mem je velmi nebezpecne (a /dev/mem ma na niektorych platformach dost obmedzenia, takze je lepsie radsej ani nebrat ho do uvahy, mozno mimo debug kernelu). Radsej by som siel cestou pouzitia UIO.

[mirec]

Jej UIO je pekné. To si musím vyskúšať. Pôvodne som chcel hodiť do kernelu dtsi pre moju dosku, ale toto vyzerá o dosť pohodlnejšie.

[Kvakor]

Novější jádra mají volbu Filter access to /dev/mem (CONFIG_STRICT_DEVMEM), co omezuje přístup jinam než do mapované paměti periférií a (u PC) paměti BIOSu. Je tedy možné, že na ne-PC platformách, kde není v dispozici mapa paměti ani enumerace zařízení, nebude /dev/mem k přístupu k MMIO použiutelné.

[mirec]

Po zarovnaní na 4kB skutočne ide, neviem prečo sa mi zdalo 0x01c23800 zarovnané. Dik za upozornenie.

[BFU]

Stacilo by pouzit 'devmem' nebo 'devmem2' , coz je commandlinovy tool, ktery univerzalne operuje s /dev/mem , syntax je neco jako "devmem 0xaddr" .

[David Jaša]

Nechce se ti v únoru do Brna? Hans bude den před devconfem pořádat hackfest zaměřený na oficiální podporu A10/A13/A20 ve Fedoře což nicméně v praxi znamená hackování na jádře a u-bootu.

[BFU]

A opet to bude zamerene na neprispivani do upstreamu a haxovani obskurnich starych verzi, ostatne jako vzdy? Co se podpory pro AW tyce, tak ta "komunita" kolem toho mi prijde jako separatisticka a skodliva.

[David Jaša]

RTFA:

Supporting Allwinnner SoCs ootb will require kernel and u-boot support. Kernel support is landing upstream and we will add patches to the Fedora kernel for 1-2 kernel releases to supplement this. u-boot support currently lives in a u-boot fork upstream, this fork is tracking / merging u-boot upstream and does intent to get sunxi support merged into the official u-boot packages, but there is no timeline for this atm. For u-boot we will create a separate u-boot-sunxi package, which can be dropped once u-boot support has been merged into u-boot upstream.

[David Jaša]

Takový dodatek: tipuju, že celá ta fedoří fíčura vznikla právě proto, že používat silně opatchované archaické verze jádra je čím dál tím víc na hovno a Hans coby autor fedořího remixu pro arm to má z první ruky.

[BFU]

Jaky je vztah AW "komunity" a upstreamu vim. Neprispivaji (coz mimo jine Vas prispevek potvrzuje).

Schvalne jsem si ted projel U-Boot ML a neni tam od nich za posledni rok jediny patch.

O pushovani supportu pro AW do Linuxoveho jadra se stara _jeden_ clovek, zbytek si patla svoji obskurni 3.4.x .

Vynechal jsem neco ?

btw. "u-boot fork upstream" je naprosto nesmyslny konstrukt, bud je to fork nebo je to upstream, ale kombinace techto dvou slov je nesmysl.

[David Jaša]

Přijde mi, že se tady plete pár pojmů - jednak ta fedoří změna vypadá na zapracovávání věcí z linux-sunxi.org, které se do upstreamu jedna po druhé dostávají, a druhak fork podle popisu vypadá na fork v git(hub)ovském smyslu - prostě samostatný strom s patchi navíc, ne fork v pravém slova smyslu, třeťak :) 'AW "komunita"' je podobný nesmysl jako "fork upstream", existuje firma AW a komunita linux-sunxi.

[BFU]

> Přijde mi, že se tady plete pár pojmů - jednak ta fedoří změna vypadá na zapracovávání věcí z linux-sunxi.org

To ovsem nema s upstreamem nic spolecneho, takze to lze ignorovat.

> které se do upstreamu jedna po druhé dostávají

A dela to presne jeden clovek, cili naprosta minorita zbytku, ktery urputne tvrdi, ze na upstream kasle. Na U-Boot kaslou uplne.

> a druhak fork podle popisu vypadá na fork v git(hub)ovském smyslu - prostě samostatný strom s patchi navíc, ne fork v pravém slova smyslu

Ja vim ze si ta "komunita" drzi strom s patchema, problem je jejich pristup, ze prispivat do hlavni rady je zbytecne.

> třeťak :) 'AW "komunita"' je podobný nesmysl jako "fork upstream", existuje firma AW a komunita linux-sunxi.

OK

[David Jaša]

> Přijde mi, že se tady plete pár pojmů - jednak ta fedoří změna vypadá na zapracovávání věcí z linux-sunxi.org

To ovsem nema s upstreamem nic spolecneho, takze to lze ignorovat.

> které se do upstreamu jedna po druhé dostávají

A dela to presne jeden clovek, cili naprosta minorita zbytku, ktery urputne tvrdi, ze na upstream kasle.

Stále mi přijde, že si nerozumíme: zrovna Hans má nějakou historii přispívání do hlavní řady kernelu a i nějakou historii dotahování věcí do funkčního stavu, takže když píše, že cílem je postupně dostat hw podporu AW zařízení do hlavní řady, tak mu věřím, že to dřív nebo později zvládne. Ten "fork" pak beru jako cestu, aby nalákal další vývojáře k přispívání, aby celá věc šla rychleji (= aby na začleňování věcí do hlavní řady dělalo víc lidí než Maxime a spol.).

[mirec]

Rád by som, ale pracovne som maximálne vyťažený, nemôžem si dovoliť. V každom prípade rýpanie do u-bootu ma ešte len čaká. Bootovanie z SD karty je v pohode, ale bootovať kernel z NAND som ešte neskúšal.