i.MX6 SDMA - assembler/disassembler

11.7.2015 05:53 | Přečteno: 1392× | Vývoj software | | poslední úprava: 11.7.2015 05:53

V tomto zápisku popíši, proč a jak jsem vytvořil assembler/disassembler jednoduchého jazyka symbolických instrukcí, určeného pro zápis a úpravu SDMA skriptů na platformě i.MX6. Vytvořený nástroj byl naprogramován v jazyce uclang, ale tento zápisek nepojednává o tomto jazyce, ale spíše o tom, co je někdy potřeba udělat kvůli čtyřbitovému posunu.

Platforma i.MX6 a SDMA přenosy

Na platformě i.MX6 slouží SDMA jako náhrada za standardní DMA přenosy, které by jinak musely být natvrdo realizované v HW, nebo vypálené v jednoúčelovém čipu.

SDMA je realizováno pomocí jednoduchého RISC procesoru, který zpracovává instrukční sadu specializovanou pro datové přenosy, a má přístup k privátnímu adresovému prostoru a k rozhraní některých periferních zařízení. Tento procesor běží paralelně s hlavním ARM procesorem a prostřednictvím speciálních instrukcí může přistupovat k paměťovému prostoru a přerušením hlavního procesoru. Standardní DMA funkce jsou výrobcem implementovány jako SDMA skripty (takto je nazývá výrobce), které jsou reprezentovány binárním kódem, nahrávaným do programové paměti SDMA procesoru prostřednictvím DMA ovladače v jádře.

Výrobce s jádrem distribuuje binární blob, který je při startu systému nahrán do programové paměti SDMA procesoru. Tento blob obsahuje mimo jiné i SDMA skript pro čtení vzorků z AC97 audio dekodéru.

Problém s AC97 dekodérem

Při testování dekodéru AC97 vyšlo najevo, že při určité konfiguraci jsou výstupní 16 bitové vzorky posunuty o 4 bity vlevo. Tomu odpovídá i errata procesoru, konkrétně chyba ERR003778. V odkazovaném dokumentu je v kolonce "Proposed solution" uvedeno "No fix scheduled".

Mým úkolem bylo vyřešit problém s nežádoucím posunem audio vzorků, a protože errata sama doporučuje řešení úpravou SDMA skriptů rozhodl jsem se tuto možnost ověřit. V rámci internetového průzkumu jsem objevil blog, který velice srozumitelně popisuje problematiku SDMA na i.MX6. Autor tohoto blogu dokonce vytvořil assembler umožňující kompilaci jazyka symbolických adres do binárního kódu spustitelného SDMA procesorem, a také popsal postup umožňující zavedení takového binárního kódu v rámci startu systému.

Postup řešení problému

Po prostudování zdrojových souborů jádra, týkajících se SDMA a zavádění výše zmíněného binárního blobu, jsem usoudil, že bude nutné upravit tento blob tak, aby mohl být načten jádrem beze změny kódu jádra. Blob se skládá ze tří základních částí:

• Hlavička popisující obsah blobu.
• Adresy začátku jednotlivých skriptů v RAM.
• Binární obraz RAM.

Bylo by obtížné z blobu "ručně" extrahovat jeden SDMA skript, tento upravit (stále v binární podobě) a následně jej vlepit zpět do blobu s tím, že by se musely posunout počáteční adresy všech skriptů za ním. Usoudil jsem, že bude snadnější vytvořit program, který bude schopný blob "rozbalit" do adresáře obsahující jednotlivé skripty jako soubory, a po provedené úpravě vygenerovat nový blob, včetně správných počátečních adres skriptů.

Takto vygenerované skripty by byly stále v jejich binární podobě, a jejich úprava by byla stále značně komplikovaná. Rozhodl jsem se vytvořit assembler/disassembler, který by mi umožnil SDMA skript snadno upravit.

Disassembler/assembler SDMA skriptů

Vycházel jsem z assembleru, vytvořeného autorem výše uvedeného blogu, který mě ušetřil studování né příliš přehledné dokumentace týkající se instrukcí SDMA procesoru. Po bližším přičichnutí k problému vyplynula nutnost zpracovávat všechny SDMA skripty obsažené v binárním blobu najednou, a to hlavně z důvodu použití instrukcí skoku na absolutní adresu paměti v rámci jednotlivých skriptů. Z použití absolutních skoků vyplývá, že při změně velikosti jednoho SDMA skriptu se posunou cílové adresy všech absolutních skoků ve skriptech nacházejících se za upraveným skriptem.

Znalosti získané při implementaci assembleru jsem využil při implementaci disassembleru, který z binární reprezentace SDMA skriptu generuje řetězec jazyka symbolických instrukcí.

Úprava binárního blobu

Nástroj naprogramovaný za účelem úpravy binárního blobu umožňuje provést následující operace:

• Vytisknout informace o binárním blobu.
• Rozbalit binární blob do adresáře, který bude obsahovat textové soubory reprezentující SDMA skripty.
• Vytvořit nový binární blob na základě původního binárního blobu a upravených textových souborů reprezentujících SDMA skripty.

Příklad informací vytištěných z původního binárního blobu:

HEADER:
m_magic:              1095582803
m_version_major:      1
m_version_minor:      1
m_script_addrs_start: 28
m_num_script_addrs:   38
m_ram_code_start:     180
m_ram_code_size:      1658

ADDRESSES:
[-1,0,642,683,747,891,960,1032,1100,1134,6144,6242,6331,6678,6762,6918]

Z výpisu vyplývá, že v binárním blobu je obsaženo 38 počátečních adres skriptů. Většina z nich je ve skutečnosti slepá (nastavená na -1), což indikuje, že se daný skript v tomto binárním blobu nenachází. Vypsány jsou pouze unikátní adresy, opakující startovací adresy se již nevypisují. Identifikace a jména těchto 38 skriptů je možné dohledat v dokumentaci výrobce, nebo ve zdrojových souborech SDMA ovladačů v jádře. Nás zajímá skript, který se jmenuje ssish_2_mcu_addr, který je 37. skriptem v blobu.

Problém s absolutními adresami

Problém s absolutními adresami ve skriptech je vyřešen ve fázi disassemblování binárních souborů, generováním návěstí (labels), pro ty absolutní skoky, které se odkazují do kódu aktuálně zpracovávaného skriptu. V případě, že je cíl skoku mimo skript, jedná se s největší pravděpodobností o "volání" nějaké rutiny. Tyto rutiny mají pevně danou adresu, a nacházejí se někde na začátku obrazu RAM paměti. V případě "volání" rutiny je absolutní adresa skoku zachována.

V rámci generování binárního kódu z jazyka symbolických instrukcí jsou cílové adresy absolutních skoků spočítány z počáteční adresy skriptu a offsetu k cílovému návěstí. Protože se vždy překládají všechny skripty, seřazené podle jejich umístění v RAM, jsou takto aktualizovány i cílové adresy absolutních skoků umístěných za upraveným skriptem.

Oprava problému s AC97

Oprava problému s hodnotami posunutými o 4 bity se použitím vytvořeného nástroje zredukovala na následující úpravu kódu v jazyce symbolických adres:

      stf      r2, MD_SZ32
      ld       r2, (r6, 4)
      stf      r2, MD_SZ32
  exit_14:
      jmp      label_15
  labelr_2:
      lsr1     r0
      lsr1     r0
      loop     exit_16, 0
      ld       r2, (r6, 0)
+     asr1     r2
+     asr1     r2
+     asr1     r2
+     asr1     r2
      stf      r2, MD_SZ16
      ld       r2, (r6, 4)
+     asr1     r2
+     asr1     r2
+     asr1     r2
+     asr1     r2
      stf      r2, MD_SZ16
  exit_16:
      jmp      label_17
  labelr_4:
      lsr1     r0
      loop     exit_18, 0
      ld       r2, (r6, 0)
      stf      r2, MD_SZ8
      ld       r2, (r6, 4)
      stf      r2, MD_SZ8

Do smyčky, která kopíruje data z dekodéru AC97 do paměti, byly přidány instrukce asr1 r2 rotující hodnotu uloženou v registru r2 o jeden bit doprava. Tato instrukce musí být pro každé kopírované slovo zopakována čtyřikrát, protože instrukční sada SDMA procesoru neobsahuje instrukci pro rotaci registru o libovolný počet bitů.

Po vytvoření binárního blobu, jeho umístění do jádra, a následné kompilaci, se už problém s dekodérem AC97 neprojevil, ale co je mnohem důležitější, nerozbily se žádné jiné funkce systému, závislé na DMA přenosech.

Na závěr

Určitě existuje nějaký assembler přímo od výrobce i.MX6, ale zřejmě není příliš snadné dostat se přímo k zdrojovým kódům (v jazyce symbolických instrukcí) jednotlivých SDMA skriptů, které se ve formě blobu načítají jádrem. To by minimálně obnášelo nějaké delší vyjednávání a podpis NDA.

Zdrojové kódy popisovaného assembleru/disassembleru je možné nalézt zde. V rámci odkazovaného adresáře je skript main.ucl hlavním spustitelným skriptem, zatímco ostatní skripty nacházející se v adresáři jsou používány jako moduly.

       

Komentáře

[vlastikroot]

Ja delam na i.MX5 a mam problem s grafikou, s VSYNC synchronizaci Qt/QML aplikace (prez EGLFS, bez X). Neni SDMA nejak v tom zapleteno? Zaboha nemuzu prijit na to, jak a cim se kopiruji snimky z GPU3D do framebufferu IPUv3. OpenGL driver je blob. Potreboval jsem podporu HW rotace displaye, tak jsem ji dodelal do toho IPUv3 driveru, ale nedari se mi to sesynchronizovat.

[zuzanak]

Můžu s určitou mírou jistoty mluvit jen o i.MX6 a podle ref. manuálu a jmen SDMA skriptů si myslím, že s přesunem snímku mezi GPU3D a IPUv3 SDMA skripty nesouvisí.

Jinak rotaci v IPUv3 jsem implementoval taky, a neobešlo se to bez patchů do jádra. Při alokaci paměti pro FB alokuji jeden blok paměti navíc. Do nového (rotačního) bloku paměti provádím rotace z původního bloku paměti. Synchronizuji to brutálně v user-space programu, který k tomu používá ioctl MXCFB_WAIT_FOR_VSYNC a double buffering na rotačním bufferu pomocí funkce mxcfb_pan_display, kterou měním offset zobrazovaného FB.

Co se týče OpenGL na i.MX6 v X11, tak tam jsem nabyl dojmu, že to není možné nakonfigurovat tak, aby vsync byl 60Hz, pravděpodobně něco ve zmiňované blobové OpenGL implementaci. Zajímavé je že při použití directfb to problém nebyl.

[vlastikroot]

Wait for sync jsem zkousel, ale to mi blokuje thread. Jak spoustis tu rotaci v IPUv3? Mam taky alokovany vstupni a vystupni buffer, ale nevim jak to nastavit, aby se po syncu displaye pustila ta rotace. Ted to poustim prasacky interruptem - to jsem okoukal z V4L driveru. Docela by se mi hodilo nahlidnout do tveho reseni.

Wait for sync je pro me nevhodny, zkousel jsem to, potrebuju aby thread bezel.

[zuzanak]

Rotaci spouštím pomocí ioctl IPU_QUEUE_TASK ovladače FB, volám jej po čekání na vsync. Protože jsem pouze autorem řešení, ale už ne jeho vlastníkem, dám vědět v pondělí, zda to budu moci zveřejnit. Já osobně s tím nemám žádný problém.

Patch do jádra se aplikuje na linux-3.0.35 a v něm na soubory:

• linux-3.0.35/drivers/video/mxc/mxc_ipuv3_fb.c
• linux-3.0.35/include/linux/mxcfb.h

To jen pro info, zda to vůbec budeš moci nějak použít.

K tomu mám program, který když je spuštěný tak rotuje celý FB nezávisle na tom kdo do něj kreslí. Blokování vlákna čekáním na vsync mi nevadí, protože celý proces dělá jen rotaci.

[vlastikroot]

To info mi staci, dekuji za pomoc Mam jadro 2.6.35. Ja prave rotaci poustim uvnitr driveru, aby se framebuffer choval stejne jako bez rotace. Uz jsem si udelal i LD_PRELOAD jako hook do OpenGL knihovny na swapBuffers, jen nevim, jak donutit OpenGL kreslit do druheho bufferu (abych mel input double buffer). Kdyz buffer prepnu pomoci toho mxcfb_pan_display pred spustenim OpenGL aplikace, tak pouziva novy buffer, ale kdyz to delam v tom hooku, tak to nema vliv (takze predpokladam ze to adresu/offset zjistuje pri startu a pak uz ne). Cekal bych, ze tam bude nejaky parametr kterym se double buffering zapne, nebo tak neco.

[Roman Došek]

Člověče musím obdivovat tvoji vynalézavost při řešení problémů. Kdybych na něco podobného narazil já, pravděpodobně bych zkusil cestu spíš cestu s NDA a podporoou Freescalu než psaním vlastního assembleru/disassembleru.

Na druhou stranu, každé moje setkání s Freescalama mě utvrzuje ve vůli se jim příště vyhnout. Zastaralé out-of-tree patche pro podporu procesorů, binární bloby nutné pro grafiku, mizerná dokumentace, ... Celkem by mě zajímal tvůj pohled na tuhle problematiku, je vůbec dneska kam sáhnout jinam? Na menší projekty se na multimediální procesory od Qualcommu nebo MediaTeku nedá vůbec sáhnout, NXP sfúzovalo s Freescalem, Ti se z trhu stáhnul... Mám dobré zkušenosti s Tegrama, ale cenově se to pohybuje úplně jinde..

[zuzanak]

Nabyl jsem při čtení diskuzí s podporou Freescalu dojem, že by komunikace s nimi mohl být běh na delší trať. Kdyby se řešení reverzním inženýrstvím protahovalo, asi by jsem je musel kontaktovat, a zkusit z nich dostat nějaké užitečné informace/nástroje.

Binárních blobů všeho druhu tam mají hodně, a to se nám taky moc nelíbí. Co se týče dokumentace, tak v dokumentaci k i.MX6 (5789 stránek) jsem našel zatím vše co jsem hledal, a připadala mi srozumitelná podobně jako dokumentace třeba od TI.

Kam sáhnout ti bohužel neporadím, já pracuji s tím co dostanu do ruky, a nemám moc žádný přehled co se ostatních výrobců týče. Vím jen, že Tegra byla alternativou k i.MX6, ale nějak (asi kvůli ceně) z toho sešlo. V minulosti jsem dělal s TI, ale to byly jen jednoduché mikroprocesory u kterých žádný problém nebyl.

[RM]

Pěkné, díky za zajímavý zápisek a odkaz. (Trochu se opakuju, ale co.)

[zuzanak]

Klidně se opakuj, pochvalou mě neurazíš.