Printre noile caracteristici interesante ale familiei MSP430F5xx este includerea unui BSL (Boot Strap Loader) pe suport Flash pentru programarea dispozitivului.
Noul BSL 5xx este similar cu BSL-urile anterioare pe suport ROM permiţând unei gazde externe să trimită o serie de comenzi generice către dispozitiv. Aceste comenzi pot fi utilizate pentru a realiza diferite acţiuni cum este citirea/scrierea din memorie, ştergerea dispozitivului, executarea programului şi calcule CRC. În timp ce BSL-ul TI programat din fabrică este similar cu BSL-ul anterior pe suport ROM, realitatea este că acesta este stocat pe suport flash şi deschide posibilitatea ca un utilizator să-şi creeze un BSL particularizat care îndeplineşte mai bine nevoile acestuia. Pentru a facilita acest lucru, noul BSL poate fi utilizat pe bucăţi sau suprascris în total pentru a permite programarea firmware a câmpului particularizat.
Posibilităţile de particularizare nu sunt limitate la o simplă execuţie de program (cum este modificarea interfeţei de comunicaţie sau de comenzi). Mai degrabă întregul ciclu de viaţă al BSL-ului poate fi particularizat, inclusiv criteriul de pornire al BSL. În timpul pornirii fiecărui dispozitiv, este apelată o funcţie de invocare BSL. Este responsabilitatea acestei funcţii să determine dacă în continuare trebuie pornit BSL sau codul aplicaţiei Utilizatorului. În UART BSL-ul programat de TI, această funcţie determină pur şi simplu dacă a fost dată o anumită secvenţă de comutare pin “invocare BSL”. Totuşi, această funcţie ar putea fi la fel de uşor particularizată. Fireşte, pentru USB BSL aceasta a fost modificată astfel încât USB BSL este invocat fie la apăsare de buton sau când un dispozitiv gol este alimentat prin USB. Această flexibilitate permite MSP430-urilor cu USB goale să fie programate prin interfaţa USB existentă la producţie. Totuşi multe alte criterii ar putea fi de asemenea utilizate.
De exemplu, robusteţea aplicaţiei ar putea fi îmbunătăţită prin punerea acestei funcţii să ruleze un CRC peste întregul Flash de Aplicaţie. Dacă acest CRC nu se potriveşte unei valori cunoscute, acest lucru poate fi folosit ca o indicaţie că BSL-ul trebuie să fie invocat pentru a continua sau a reporni programarea firmware.
BSL-ul furnizat de TI a fost scris cu intenţia ca acesta să fie reutilizat şi particularizat. Din acest motiv a fost scris într-un mod modular care decuplează “motorul” intern BSL de modul de comunicaţie. Motorul BSL are o interfaţă de 3 funcţii la software-ul care gestionează comunicaţia fizică. În acest fel, motorul iniţializează pur şi simplu interfaţa, îi spune să recepţioneze un pachet de date şi mai târziu trimite un pachet de date. Acest lucru permite unui BSL particularizat să fie uşor scris prin înlocuirea codului de comunicaţie. Dacă BSL-ul UART standard furnizat de TI nu este suficient, codul furnizat poate fi suprascris pentru a permite o comunicaţie prin I2C, SPI, RF, USB sau orice altă interfaţă/protocol imaginabile. Chiar şi ceva trivial ca o schimbare de pin pe port (prin funcţia de mapare a portului 5xx sau un redefinire a portului Timer) ar putea fi realizată uşor pentru a permite unui sistem de upgrade de câmp să se potrivească mai convenabil într-o structură specifică.
Intern, “motorul” BSL a fost de asemenea scris într-un mod care permite reutilizarea şi modificarea codului. Există două nivele în acest motor: primul se ocupă cu decodarea comenzilor pentru a decide ce acţiuni trebuie luate, iar al doilea strat se ocupă direct cu scrierea şi citirea în memoria fizică MSP430. Este stratul inferior, acela care acţionează ca gatekeeper la memoria MSP430 prin apeluri de funcţii relativ generice (writeMemory, readMemory etc.). Acest gatekeeper încorporează de asemenea majoritatea funcţiilor de securitate proiectate pentru a proteja IP-ul dintr-un dispozitiv. Acesta este de exemplu nivelul l, care recepţionează parola dispozitivului şi şterge dispozitivul dacă parola este incorectă. Dacă parola este furnizată corect, acest nivel deschide dispozitivul şi permite citiri/scrieri subsecvente în memorie. Acest strat a fost menţinut relativ generic astfel încât funcţiile de securitate ample puse în această secţiune să fie de asemenea incluse în orice BSL particularizat, excluzând posibilitatea introducerii unor breşe de securitate printr-o rescriere totală (stare BSL defectabilă, profilare de parolă etc.). Particularizarea acestui strat ar fi normal limitată la înlăturarea funcţiilor de securitate mai riguroase, cum este ştergerea în masă a dispozitivului la parolă incorectă sau suprascrierea totală a RAM-ului pe pornirea BSL.
Primul nivel al “motorului” BSL se ocupă numai cu interpretarea comenzilor recepţionate şi apelarea nivelului de scriere/citire de memorie al nivelului inferior. În TI BSL standard acest nivel acceptă comenzi cum sunt: scriere/citire memorie, calculare CRC şi ştergere dispozitiv. Totuşi, nu există nimic care să prevină ca mai multe comenzi specifice aplicaţiei să fie încorporate. De exemplu ar putea fi adăugată o comandă pentru recepţionarea de octeţi încriptaţi. Această comandă ar indica faptul că un pachet de date recepţionat a fost încriptat şi necesită să fie decriptat (prin cheie internă BSL) înainte de a fi scris în memoria dispozitivului.
Adăugarea unei astfel de comenzi însemnă că dispozitivul IP poate rămâne securizat, chiar dacă a fost dat prin reţea unui client pentru un upgrade.
În cele din urmă, dacă BSL-ul nu va fi utilizat deloc într-o aplicaţie finală, acesta poate fi şters.
Ştergerea BSL oferă două avantaje distincte. În primul rând, există siguranţa că dispozitivul este 100% impenetrabil la orice atac de securitate bazat pe BSL, deoarece BSL-ul este total înlăturat din dispozitiv. În al doilea rând, când BSL-ul este înlăturat acest eliberează un surplus de 2k de flash pentru a fi utilizaţi în codul Aplicaţiei. Aceşti 2k sunt practic “gratis”. În plus, spaţiul memoriei ar putea fi utilizat pentru cod de aplicaţii non-BSL care ar putea profita de proprietăţile speciale ale memoriei BSL de 2k: protecţia la ştergere şi scriere/citire. Această zonă poate stoca 2k de “nucleu” sau firmware “nemodificabil” separat de aplicaţia principală. Aceasta poate fi o simplă bibliotecă de funcţii sau o aplicaţie mai elaborată. Interacţiunea dintre cele două bucăţi de firmware poate fi realizată prin utilizarea “Zonei-Z BSL” care acţionează ca o poartă pentru salturi controlate între BSL-ul securizat şi codul extern de aplicaţie.
Mai multe informaţii şi exemple despre cum să se scrie un BSL particularizat care încorporează caracteristicile discutate poate fi găsit în raportul aplicaţiei “Crearea unui BSL pe Bază de Flash Particularizat” (SLAA450) în pagina web a TI la: http://focus.ti.com/lit/an/slaa450/slaa450.pdf
Contact:
Irina Marin / ECAS ELECTRO
Tel.: 021 204 8100 begin_of_the_skype_highlighting 021 204 8100 end_of_the_skype_highlighting begin_of_the_skype_highlighting 021 204 8100 end_of_the_skype_highlighting begin_of_the_skype_highlighting 021 204 8100 end_of_the_skype_highlighting
Fax: 021 204 8130
www.ecas.ro
Gabriela Petrache / TI / Suport Clienţi România
eecsc@ti.com