XMOS xCORE

[prasimix]

Za bootloader i ostale stvari koje su vezane za in-field nadogradnju, u sustini opet ista prica, mozes da odvojis neko jezgro samo to da radi, izaberi interfejs, obcian seriski RX/TX (mozda zgodnije za WiFi/BTLE extenziju) ili USB/LAN, osmisi neki protokol ili mozda to sve vec ima gotovo kako se to sve moze odraditi.

Ja samo znam da kod ozbiljnih masina koje imaju te opcije da moze da se upgrejduje firmware obicno imaju dve posebne FLASH memorije, jedna radna i tu se sve snima i jedna za Backup koja moze da se vrati u slucaju da predhodni updejt nije bio dobar (kombinacijom nekih tastera/jumpera pri boot itd).
Ako se to "kolo" funkcionalno dobro osmisli i zatvori, onda mozes da se oslonis na SW procedure za upgrejd firmwera i korisniku nije potreban specialan programator da to odradi.

Povoljnije je da se stavi jos jedna FLASH memorija za Backup i da se osmisli robustan sistem za upgrejd sa zastitom od "brikovanja/zakljucavanja" sprave od strane korisnika nego komplikovati sa programatorima i cime vec. Ovo sa dve memorije nije nista novo, to se odavno koristi u PC svetu na maticnim plocama, setite se "Dual BIOS" maticnih ploca, to je bas to a vidjao sam i na industriskim Embeded resenjima nevezano za PC.

I naravno postoji kombinacija sa FLASH memorijom ali druga da bude FRAM jer ce vam on trebati pa trebati : ), i tu da se malo manipulise memoriskim prostorom, raspodeli se tamo-vamo sa sve Backup prostorom, "vecim" u Flash i "manjim" u FRAM i tu se cuvaju SVE adrese, vrednosti, firmware i najbitnije korisnicka podesavanja tj parametre koja su korisniku najbitnija, ovo ostalo ga u sustini ne interesuje, njega interesuje da mu ostanu sva podesavanja pre ili posle ili kad god nakon updejta firmwera i to da ima ceo set podesavanja backupovanih pod nekim imenom, MyConf1, MyConf2 i tako dalje.

Dakle potpuno isti princip se "mazne" sa PC platforme i maticne ploce, oni imaju SRAM sa baterijom i FLASH, ovde kod nas sa MCU imamo FRAM i FLASH i ne treba vam vise nista od toga, osim SRAM ako krenete u graficke vode, mada realno, u onaj PCI slot na XMOS StarterKit moze da se ubode i citava PC graficka kartica i to da biras od 20E do stotine Eur za graficke od 4-6-8-10GB DDR4/5 RAM memorije, imaju 2 DVI i 4 HDMI izlaza, imaju snage za "kalkulaciju" da se smrznes, kakav crni FFT, to moze da radi hiljade ili milione FFT-ova u realnom vremenu, to je tako surova procesorska snaga spakovana za graficke potrebe da je to nenormalno, i sto je je najludje to moze da se iskoristi za sve i svasta i koriste ljudi za sve i svasta!!!

---

Poenta je ako se dobro osmisli sistem i sastavi iz jedne ili vise "pametnih kockica" i sav ostali HW samo da se svede na buffere i opto izolatore, bez ikakve specificne externe logike sa expanderima, shift registrima ili slicno, i ako su sve te kockice spojene na red u recimo JTAG lanac onda je ceo sistem prakticno in-field programibilan i rekonfigurabilan do najsitnijeg detalje logike koja mozda sad postoji ili koja ce tek biti implementirana i sa XMOS resenjem to je skor rekonfugurabilno kao sa FPGA varijantom, naravno sa nekim ogranicenjima, ali generalno za taj nivo integracije trenutno nema bolje resenje a da nije CPLD ili FPGA.

Evo što sam do sada pronašao na temu uploada programa. Postoje dva alata koji dolaze u sklopu njihova xTIMEcomposer Studio IDE: xburn i xflash. Oba su komandno-linijska, a koristi ih i IDE. Mislim da su oni relevantni za upload, a ne xrun spomenut u postu #1 koji se koristi za load i pokretanje programa u radnoj memoriji (valjda ).
xburn se koristi za programiranje tzv. OTP (one-time-programming) memorije koje ima 8k po hardverskoj jezgri (tile) i gdje se stavljaju stvari poput serial no, kriptografskog ključa s kojim će se dekriptirati program prilikom učitavanja iz flasha, i slične IP (intellectual property) stvari.
xflash se koristi za uploade, kažem u množini, jer XMOS je to dosta dobro razradio. Prvo, flash se može podjeliti na boot i data particiju (vidi sliku dolje).



Početak boot particije sadrži Flash loader (tu je programski kôd koji selektira koji će se firmver pokrenuti) i tzv. Factory image koji ima id=0 i nakon kojeg može slijediti n drugih firmvera (na slici Upgrade image 1, 2, 3...). Data particija je po defaultu 0, tj. ako se drugačije ne kaže xflash-u onda će on sav prostor na flashu rezervirati za Factory image i n "upgrade" firmvera. Obratite pažnju na to da je Flash loader i Factory image hw zaključan (da se ne mogu pobrisati). Jako zgodno. Ako ima više firmvera loader će pokrenuti onaj s najvećim id (taj broj mora biti jedinstven/unique). Ovo bi sve trebalo vrijediti bez obzira da li se radi o internom (F verzija MCU) ili eksternom. Eksternih čipova može biti više, eto doznao sam da postoji i FRAM, hvala ti na informaciji. Izgleda kao bitno poboljšanje u usporedbi s flash i eeprom. Cijena mu nije mala, ali i to će vremenom doći na svoje.
Na tome priča ne završava. XMOS ima i flashlib koji omogućuje xflash funkcionalnost u run-time (što uključuje i pisanje u flash!). Navodim nekoliko povezanih stvari:

• Primjer korištenja flashlib (malo je vremešan, prije 6 godina)[/url]
  
• Primjer za custom flash bootloader
  
• qSPI flash lib
  
• Podrška custom memorije (PDF), odnosno noviji dokument o definiranju/dodavanju nove (nepodržane) flash memorije (PDF)
  
• Jedna od mogućnosti sada mislim da je i korištenje USB-diska/sticka na kojem se može snimiti firmver za upload. U tom slučaju dobro bi poslužila app nota 00125
  
• Design and manufacture systems with flash memory (web stranica i PDF nisu identični)
  

Mogućnosti izgleda da ima mnogo, ono što ne ohrabruje je dosta konfuznih ljudi na njihovom forumu koji su zapeli na priči o firmver uploadu i pokretanju.

XMOS dozvoljava pokretanje programa iz više izvora što se u slučaju izabranog MCU definira sa stanjima na pinovima X0D04, X0D05 i X0D06:


Može se koristiti QSPI master, običan SPI u master i slave režimu ili boot preko xCONNECT linka. Ako ovo dobro tumačim, prvo se pokreće Tile 0 (hardverska jezgra) i onda preko xlink0 Tile 1.

VAŽNO: pinovi za QSPI i SPI su "hardcoded" u ROMu i ako se žele koristiti drugi pinovi mora se ubaciti program u OTP memoriju u kojem će se definirati novi pinovi.
VAŽNO2: MCU očekuje da bitovi u byteu stižu od LSB prema MSB, pa u slučaju korištenja programera koji upisuje sekvencu od MSB prema LSB, bitove u ".hex" fajlu treba prvo obrnuti. To što vrijedi kod običnog SPI flasha za bitove, kod QSPI vrijedi za niblove (jer je QSPI 4-bitni).

Pored u prethodnoj tablici navedenih načina startanja programa (boot) moguće je to napraviti i iz OTP memorije. To će se dogoditi ako je bit 5 (security boot) tzv. security registra postavljen na 1.