OT(?) nebezpecie casovania procesorovymi cyklami u SoC ako su ARMoidy, bolo (davnejsie): ARM- interrupt/event

[Jan Waclawek]

Na uvod sa ospravedlnujem za nepiatkovu temu.

Mozno sa pamatate, ze sme v aprili (dubnu) diskutovali o pomerne
prekvapivom jave v istom ARMoide, ked dlzka pulzu odcasovana NOPmi
nesedela s poctom NOPov (bol tam taky zvlastny skok) - vlakno za
http://list.hw.cz/pipermail/hw-list/2013-April/438309.html (je to dlhe,
ale ti, ktorych to zaujima, si mozno spomenu, o co presne islo). 

Teraz sa vo fore ST objavil prispevok, ktory upozornil na iny jav: pri
sucasnom zapise DMA jednotky aj procesora na "to iste miesto" (pricom
definicia "toho isteho miesta" nie je trivialna, vlastne ide o to, ze
nastane nejaky konflikt kvoli ktoremu musi procesor pockat) sa moze nejaky
softwarovo nopmi odcasovany pulz necakane skratit. Dovod spociva v
oneskoreni nabeznej hrany pulzu: ak DMA jednotka obsadzuje zbernicu,
zapis, ktory procesor urobi, zostane vo write bufferi procesora (a
prebehne neskor, ked sa zbernica uvolni), ale procesor bezi (vykonava tie
NOPy) bez prestavky dalej. 

V danom konkretnom pripade pomohla barierova instrukcia DSB za instrukciou
zapisu (DSB brani procesoru, aby vykonal dalsiu instrukciu, kym je write
buffer plny), ale pri niektorych zlozitejsich pripadoch ak je v
zberniciach viac buffrov na ktore uz procesor "nevidi", to nemusi stacit,
a moze byt nevyhnutne urobit spatne citanie.

(necham plne vychutnat link z toho dementneho ST fora - kolegovia z ST,
kedy sa prihovorite aby uz konecne vyrazili toho, co je za ten paskvil
zodpovedny?):

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fWhy%20is%20DMA%20reducing%20my%20pulse%20width&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FAllItems.aspx&currentviews=58


wek