AM335x inicializace, rychlost

Josef Štengl ok1ced na nagano.cz
Pondělí Únor 23 18:59:17 CET 2015 

Ano. Ale proč to dlouho trvá - přístup, nebo je nízká frequence?

Nemáte přístupný pin, kde je možno exportovat nějakou interní sběrnici (GIO port nemá cenu, pokud nevíte kolik vám to 
sežere cyklů; no bude to do 100 :-). Mě ji HW boys nevyvedli, prý to nebylo potřeba a z bga se dost obtížně vyvádí drátek 
a pak jsem docela s obtížemi hledal proč a kdy nefunguje PLL. No bylo to oscilátorem - osadili 50 a erratě bylo že max 20.

Ale k věci, když se ptáte. MPU (součást MMU v A - R ko má jen MPU) může mít podstatný vliv na výkon. Jestli si dobře 
pamatuji ... tak v dokumentu ARM DDI 0406C v kapitole B5 (začíná na straně B5-1753) je popis Protected Memory System 
Architecture (PSMA), který s tím souvisí. Nastavuje se Přístup (read, write, execute), enkódování - dokáže zkrátit dobu 
přístupu k některým perifériím až o 60%, pokud vám nebude vadit, že po zbývající dobu není zrovna konzistentní stav mezi 
zapsaným a skutečným (trochu prekérka, pokud GIO bránou povolujete CS a blízko začínáte komunikovat s jinou periférií, 
která předpokládá, že je to povoleno) a takové prkotiny jako povolení cache pro daný rozsah, zarovnání paměti a další věci 
u kterých si nejsem jist co znamenají, protože nemám HW který to podporuje (například D-cache :-).
Dost zajímavá je kapitola 5.3.

Registry, kterými se to nastavuje bych hledal v sekci coprocescors (to jsou ty periférie přístupné pře mrs a msr insrukce).

Přeji příjemnou zábavu a pevné nervy. Defaultní nastavení by ale mělo chodit skoro ideálně - pokud errata a zabuggovana 
paralelní brána neříká jinak.

Další věc, při initu CPU se na začátku nastavuje, kolik cyklů je potřeba pro přístup do paměti (sram, flash). Bývá to 
nastaveno na max hodnotu - křemík nezná takt a cache zakázány - ale to asi máte povoleno. A jestli se má pro flash 
používat cache - tedy v mém případě je to je 2 (nebo 4?) wordy dlouhý buffer, pro vás to bude asi jinak. Možná to bude 
nastavitelné i pro jednotlivé cache.


Pozor: skok trvá 1 nebo 7 cyklů. Podle toho, jestli to odhadovač (.. nebo jak se tomu správně nadává) správě odhadne skok. 
U vás možná jinak, máte delší pipelajnu.



Dne 23.2.2015 v 15:33 Jaroslav Buchta napsal(a):
> No evidentne trvaji podezreje dlouho - doufam, ze jsem stale jeste jen neprisel na to, co dalsiho inicializovat - jeste
> jsem nezkoumal jadro, neni potreba neco v nem nastavit?
> Preruseni je zakazano, zadne DMA, nic by nemelo procesor rusit v provadeni tech osmi instrukci. Kdyz pridam zas to x++,
> pribudou instrukce ldr, add, str a cas se celkem umerne prodlouzi, takze skutecne to vykonava dlouho jednotlive instrukce.
> Neni nejak omezeno, ze plnou rychlosti to bezi jen s MMU, treba?
> Taky je mi divne, ze i kdyz povolim cache (I i D) tak zalezi na tom, s jakou pameti se pracuje - pri trosce dobre vule by
> se melo vse odehravat jen v cache, ne?
> Takhle je to proste cca stejne vykonne, jako CM4 na 190 MHz coz mi neprijde mozne. Ta interni SRAM u jadra by snad mela
> fungovat na plne rychlosti a instrukce ldr, str by mely trvat 2-3 cykly, skok taky, add 1 cykl, proste mi to nevychazi cca 6x
>
> Dne 23. 2. 2015 v 12:52 Josef Štengl napsal(a):
>> Jediné, co mě napadá (cortex A neznám) je použít PMU (performance monitor unit) a změřit si, jak dlouho trvají
>> jednotlivé úseky kódu/instrukce v CPU cyklech. Dobré je vědět, jak dlouho trvá povolení/zakázání int (v nejjednodušší
>> formě).
>>
>> Bude z toho jasno, jestli je to PLL nebo chybně nastavená sběrnice („to je přece dobře“ se mi již několikrát vymstilo :-()
>>
>> ced
>>
>>
>> Dne 23.2.2015 v 11:37 Jaroslav Buchta napsal(a):
>>> Jeste jsem zkusil prehodit zasobnik do SRAM u jadra, to se tak o 50% zrychlilo, predtim byla data v L3 OCMC coz je mimo
>>> jadro a bezi asi na 200 MHz Program tam zustal ale to by snad mela resit instrukcni cache (ma vliv).
>>> 5M iteraci tohoto cyklu:
>>>
>>> 0x40304B28    mov    r3, #0
>>> 0x40304B2C    str    r3, [r11, #-24]
>>> 0x40304B30    b    0x40304b40 <main+180>
>>> 0x40304B34    ldr    r3, [r11, #-24]
>>> 0x40304B38    add    r3, r3, #1
>>> 0x40304B3C    str    r3, [r11, #-24]
>>> 0x40304B40    ldr    r2, [r11, #-24]
>>> 0x40304B44    movw    r3, #19263    ; 0x4b3f
>>> 0x40304B48    movt    r3, #76    ; 0x4c
>>> 0x40304B4C    cmp    r2, r3
>>> 0x40304B50    ble    0x40304b34 <main+168>
>>>
>>> trva nyni asi 1s, coz mi prijde zalostne. Inicializoval jsem uz vsechny PLL bez efektu. Hrubym odhadem muze jedna iterace
>>> trvat tak 20 internich cyklu? Pri frekvenci jadra 600MHz bych cekal za sekundu tedy 8x vetsi vykon.
>>> V cem muze byt problem???
>>>
>>> Dne 23. 2. 2015 v 8:32 Jaroslav Buchta napsal(a):
>>>> Normalne, na zasobniku, vse v interni SRAM
>>>> Takto vypada disassemblovany kod - IMHO presny preklad bez
>>>> optimalizace, leze jen do interni pameti:
>>>>
>>>> 0x403046B0    mov    r3, #0
>>>> 0x403046B4    str    r3, [r11, #-24]
>>>> 0x403046B8    b    0x403046d4 <main+176>
>>>> 0x403046BC    ldr    r3, [r11, #-28]
>>>> 0x403046C0    add    r3, r3, #1
>>>> 0x403046C4    str    r3, [r11, #-28]
>>>> 0x403046C8    ldr    r3, [r11, #-24]
>>>> 0x403046CC    add    r3, r3, #1
>>>> 0x403046D0    str    r3, [r11, #-24]
>>>> 0x403046D4    ldr    r2, [r11, #-24]
>>>> 0x403046D8    movw    r3, #41247    ; 0xa11f
>>>> 0x403046DC    movt    r3, #7
>>>> 0x403046E0    cmp    r2, r3
>>>> 0x403046E4    ble    0x403046bc <main+152>
>>>>
>>>>
>>>> Dne 23. 2. 2015 v 8:16 Jan Waclawek napsal(a):
>>>>>>      volatile int idx;
>>>>>>      volatile int x;
>>>>>
>>>>>>          for (idx=0; idx<500000; idx++)
>>>>>>          {
>>>>>>              x++;
>>>>>>          }
>>>>> Bez toho aby som sa pokusal pochopit ten SoC, kde su alokovane tieto dve
>>>>> premenne?
>>>>>
>>>>> wek
>>>>>
>>>>> _______________________________________________
>>>>> HW-list mailing list  -  sponsored by www.HW.cz
>>>>> Hw-list na list.hw.cz
>>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>>
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> http://www.avast.com
>>>>
>>>> _______________________________________________
>>>> HW-list mailing list  -  sponsored by www.HW.cz
>>>> Hw-list na list.hw.cz
>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> http://www.avast.com
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
> _______________________________________________
> 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