AM3359 sitara (beaglebone) a XIP boot

Josef Štengl ok1ced na nagano.cz
Pondělí Srpen 26 15:39:28 CEST 2013


Ahoj,

pokud jsem dobře pochopil tak je to Cortex-A8. A to jsem osobně viděl 
jen na obrázku. A jelikož neznám MMU jednotku, tak budu věštit z čajové 
sedliny. Pravděpodobně budu naprosto mimo. Ani nevím jestli provozujete 
na kosti pro honícího psa nějaký OS (pokud si nenapíšu nějakou parodii, 
tak nejí šance abych měl procesorový čas ho použít :-).

Předpokládám tuto spuštění prográmku z adresy 0, inicializace GPMC a 
skok na GPMC oblast - to znamená žádné realokování paměti.

Jen mě tak napadá:

Je oblast GPMC oblast nastavena jako executable (MMU a linker script)?
Načítá to data? Jendou jsem měl problém s EMIFem, že se to jen tvářilo, 
že to načítá - právě chybná konfigurace paměti (na Cortex-R je to v MPU, 
nemá MMU jako A tak hádám. Měl jsem to o bit posunuté a konfigurace 
samotného EMIFu byla stejná).

Pro čtení. Nekvalifikovaný odhad je že z hlediska procesoru to bude 
jeden čtecí cyklus a z hlediska GPMC 1 x 2 (to jest dva čtecí 16 bit 
GPMC cykly v jednom čtecím 64 bit cyklu AXI zběrnice). Domnívám se tak 
proto, protože AXI sběrnice (periférní sběrnice ARMu pro řady cortex-R a 
A) je interně 64 bitová a i při čtení 32bit z 16 bit EMIFu (cortex-R) je 
čtení pořád jedna instrukce (a příslušný počet wait stavů)) a jeden 
cyklus. Když se čte/zapisuje méně než 64 bitů, za sebou, tak časově 
nenásledují po sobě jak by jeden naiva očekával, ale je mezi nimi časová 
mezera - menší než samotné čtení, ale je tam a poměrně se mění se šířkou 
dat. Ale možná je to specifikum jednoho procesoru, se kterým momentálně 
pracuji.

Mimochodem, když když danou oblast paměti přečtete v debugeru jako 
oblast kódu (disassembovaný kód), tak by mělo být jasně vidět, jestli 
obsahuje instrukce, jak očekáváte - samozřejmě přečíst po inicializaci 
GPMC. Prakticky by to mělo jít odladit, nebo se (jako obvykle) mýlím?

ced

Dne 26.8.2013 11:39, David Belohrad napsal(a):
> Zdravim,
>
> resime tady s kolegou takovy zajimavy problem s armem. Mame beaglebone a
> snazime se jej presvedcit, aby bootoval executable-in place. Na GPMC
> sbernici mame pripojene FPGA, kterym jej zkousime krmit bootloaderem
> prekompilovanym na adresu 0x08000000 (kde zacina GPMC).
>
> Mame boot piny nastavene tak, aby bootoval pres XIP s pouzitim wait
> signalu.
>
> Pri bootu se opravdu inicializuje GPMC, a procesor zacne cist
> neco (program?) pres GPMC. My mu strkame ten bootloader. Ale at delame co delame, ten
> bootloader se evidentne neprovadi. Spis to vypada, jako kdyby XIP boot
> jenom 'kopiroval' data z nekama nekam, protoze adresy se inkrementuji
> (temer) linearne. Jeden by ocekaval, ze (pokud nemame instrukcni cache)
> se bude vzdycky nacitat z adresy, na kterou se skace.
>
> Dokonce jsme zkouseli i jednoduchy assembler:
>
> .text
>
> lab: nop
>       nop
>       nop
>       nop
>       nop
>       nop
>       b lab
>
>
> a chteli jsme videt, zdali se GPMC chova tak, ze tam ten branch
> uvidime. Uplne nas to ignoruje. Prehazovali jsme poradi ctenych byte na
> little/big endian a nic.
>
>
> Ja osobne mam jeste jedno 'nejasno' v te veci. Ten arm je 32bitovy, ma
> 32bitove instrukce. XIP pres GPMC je 16bitovy, cekal bych tedy, ze se
> vzdy bude nacitat jedna instrukce dvema ctecimi cykly. je to tak?
>
>
> za kazdou radu predem dik
>
> d.
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>


Další informace o konferenci Hw-list