Goto page 1, 2 Next
Sebastian BiaĹy
Guest
Thu Mar 18, 2010 1:52 am
Witam.
Czy jest gdzies gotowiec pozwalający flashować pamięc procesora SAM7 z
karty SD?
Wyobrazam sobie to tak, ze procesor wstaje w bootloaderze, sprawdza
karte SD, odczytuje checksum pliku do flashowania, liczy checksum
wlasnego flasha i jesli sa rózne to automatycznie programuje po czym
skacze już normalnie do kodu. W ten sposob mogę wymieniac kod w
procesorze po prostu zmieniając plik na karcie SD.
Widzial ktoś takie coś gotowe?
Oczywiscie ideałem było by gdyby wspierało asymetryczne szyfrowanie, ale
powiedzmy, że mając sam bootloader mogę się pokusić o dopisanie tego
ficzera. Na razie z chęcią obejrzałbym sobie kod takiej zabawki, wole
wziąśc coś działającego niz pisać od zera.
Piotr
Guest
Thu Mar 18, 2010 9:30 am
On 18.03.2010 01:52, Sebastian Biały wrote:
Quote:
Widzial ktoś takie coś gotowe?
IMHO, powinieneś pójść z stronę U-Boot'a. Jeśli jest on przeportowany na
Twoją platformę to 80% pracy masz już za sobą. Jedyne co będziesz musiał
zrobić to ew. napisać "driver" do karty SD no i skrypt, który by
dokonywał takiego flashowania przy starcie.
--
Piotr Piwko
http://www.embedded-engineering.pl/
Sebastian BiaĹy
Guest
Thu Mar 18, 2010 7:07 pm
Piotr wrote:
Quote:
IMHO, powinieneś pójść z stronę U-Boot'a.
Jest _ogromny_. Nie wiem czy jest to wlasciwe rozwiązanie na pare kB w
SAM7. masz może doświadczenia z nim? Bo ja widze, że on jest np.
interaktywny (co mi nie jest potrzebne).
Adam Dybkowski
Guest
Thu Mar 18, 2010 11:48 pm
W dniu 2010-03-18 19:07, Sebastian Biały pisze:
Quote:
IMHO, powinieneś pójść z stronę U-Boot'a.
Jest _ogromny_. Nie wiem czy jest to wlasciwe rozwiązanie na pare kB w
SAM7. masz może doświadczenia z nim? Bo ja widze, że on jest np.
interaktywny (co mi nie jest potrzebne).
No to łyknij z sieci gotowe funkcje do odczytu SD i FAT32 (np.
bibliotekę PHAT z Nut/OS), do tego funkcje programowania SAM'ów (np. z
OpenOCD) i już. Poskładasz gotowe klocki w jeden dzień i będziesz miał
ulubiony bootloader.
BTW: Tyle że w AT91SAM7 nie ma takiego wsparcia dla własnych
bootloaderów, jakie jest np. w AVRach. "Bootloader" w tym przypadku to
zwykły kawałek softu, który leży sobie na początku Flasha. A cały
normalny program musisz linkować odpowiednio dalej (np. od 32KB).
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Piotr
Guest
Fri Mar 19, 2010 8:27 am
On 18.03.2010 19:07, Sebastian Biały wrote:
Quote:
Piotr wrote:
IMHO, powinieneś pójść z stronę U-Boot'a.
Jest _ogromny_. Nie wiem czy jest to wlasciwe rozwiązanie na pare kB w
SAM7. masz może doświadczenia z nim? Bo ja widze, że on jest np.
interaktywny (co mi nie jest potrzebne).
Nie musi być wcale interaktywny. Wszystko zależy od konfiguracji. Co do
"wielkości" samego projektu, to owszem jest on duży, ale tylko i
wyłącznie dlatego, że wspiera bardzo wiele architektur/platform. Ciebie
będzie interesowało dosłownie kilka plików. Jeśli U-Boot jest
przeportowany na Twoją platformę (sprawdź na stronie) to pozostaje Ci
tylko napisać funkcję do odczytu danych z karty SD do pamięci RAM.
Osobiście stosuję i modyfikuję tego bootloader'a praktycznie we
wszystkich moich projektach.
BTW. Co to za platforma?
--
Piotr Piwko
http://www.embedded-engineering.pl/
Sebastian BiaĹy
Guest
Fri Mar 19, 2010 9:15 am
Adam Dybkowski wrote:
Quote:
No to łyknij z sieci gotowe funkcje do odczytu SD i FAT32
Zrobie to w ostateczności ;)
Quote:
BTW: Tyle że w AT91SAM7 nie ma takiego wsparcia dla własnych
bootloaderów, jakie jest np. w AVRach. "Bootloader" w tym przypadku to
zwykły kawałek softu, który leży sobie na początku Flasha. A cały
normalny program musisz linkować odpowiednio dalej (np. od 32KB).
To nie ma znaczenia gdzie będzie fizycznie flash ładowany, byle by można
potem zmienić wektory przerwań.
Sebastian BiaĹy
Guest
Fri Mar 19, 2010 9:17 am
Piotr wrote:
Quote:
Nie musi być wcale interaktywny. Wszystko zależy od konfiguracji.
Zadaje sobie sprawę, ale jesli w kodzie sterownika do rzeczy X znajduje
PRINTFy to ostroznei musze podchodzić do reszty, kod "uniwersalny"
niekoniecznie jest dla mnie najlepszymrozwiązaniem, to mały procesor.
Quote:
BTW. Co to za platforma?
SAM7 ;)
A konkretnie ARM7 od Atmela.
Lukasz Sczygiel
Guest
Fri Mar 19, 2010 9:19 am
Quote:
W dniu 2010-03-18 19:07, Sebastian Bia�y pisze:
IMHO, powiniene� pój�� z stron� U-Boot'a.
Jest _ogromny_. Nie wiem czy jest to wlasciwe rozwi�zanie na pare kB w
SAM7. masz moşe do�wiadczenia z nim? Bo ja widze, şe on jest np.
interaktywny (co mi nie jest potrzebne).
No to �yknij z sieci gotowe funkcje do odczytu SD i FAT32 (np.
bibliotek� PHAT z Nut/OS), do tego funkcje programowania SAM'ów (np. z
OpenOCD) i juş. Posk�adasz gotowe klocki w jeden dzie� i b�dziesz mia�
ulubiony bootloader.
Jesli mogę się wciąć:
Nie jest konieczne implementowanie pełnego wsparcia dla fat-u.
Wystarczy karte SD odpowiednio przygotowac aby w trakcie odczytu po prostu
czytac ciagle sektory.
Czyli np. Formatujemy karte, zakladamy na niej dummy file o rozmiarze jaki nam
potrzeba, sprawdzamy od jakiego sektora sie zaczyna i czy jest to plik ciagly.
Potem starczy sobie poczatkowy sektor wrzucic do bootloadera i niech czyta
sekwencyjnie.
Pewnym problemem moze byc uaktualnianie dummy file (bo trzeba rewritowac plik a
nie go zamienic) ale raczej nie bedzie to az tak problematyczne.
Pomysl wymyslilem sam chyba opierajac sie o jakies natchnienie z starych ksiazek
o c64. Nie implementowalem wiec nie wiem jakie jeszcze babole moga sie natrafic.
Ale planuje tak zmontowac rejestrator temperatur wiec jak wiecie ze nie zadziala
to mozecie wczesniej ostrzec :)
--
Lukasz Sczygiel
--
Wysłano z serwisu OnetNiusy:
http://niusy.onet.pl
Sebastian Biały
Guest
Fri Mar 19, 2010 9:34 am
Lukasz Sczygiel wrote:
Quote:
Nie jest konieczne implementowanie pełnego wsparcia dla fat-u.
Wystarczy karte SD odpowiednio przygotowac aby w trakcie odczytu po prostu
czytac ciagle sektory.
Odpada. Osobą wrzucającą plik na SD będzie "bylekto". Musi dać się to
zrobić po protu kopiując plik. Dorobienie FATu nie jest problemem, są
dziesiatki implementacji. ja pytam ogotowca, w ostateczności napiszę sam.
cepu69
Guest
Fri Mar 19, 2010 2:30 pm
Witam,
Sebastian Biały wrote:
Quote:
Witam.
Czy jest gdzies gotowiec pozwalający flashować pamięc procesora SAM7 z
karty SD?
Wyobrazam sobie to tak, ze procesor wstaje w bootloaderze, sprawdza
karte SD, odczytuje checksum pliku do flashowania, liczy checksum
wlasnego flasha i jesli sa rózne to automatycznie programuje po czym
skacze już normalnie do kodu. W ten sposob mogę wymieniac kod w
procesorze po prostu zmieniając plik na karcie SD.
Widzial ktoś takie coś gotowe?
A ja standartowo polecam eCos'a :http://ecos.sourceware.org/
System posiada BSP na Atmel AT91SAM7S (evalboard - AT91SAM7S-EK).
I teraz sa dwie drogi -
1.Uzyc istniejacego lodear czyli RedBot'a czego po przedstawionych
wymaganiach nie chcialbys robic
2.Wykorzystac OS w wersji minimalnej - system zgodnie z nazwa jest mocno
konfigurowalny czyli wylaczyc kernel (scheduler), dodac odpowiednie drivery
wbudowany flash, spi oraz mmc???? (eCos posiad tylko driver do kart MMC na
SPI) oraz system plikow FAT a nastepnie napisac prosta w miare aplikacje
jak wynika z wymagan.
Sebastian Biały
Guest
Sat Mar 20, 2010 9:56 pm
cepu69 wrote:
Quote:
A ja standartowo polecam eCos'a :http://ecos.sourceware.org/
No własnie po zabawie z FreeRTOSem czas na nastepnego

Zastanawiam się
nad ecos-em jako bazą do mojej apliakcji. Jęlsi faktycznie da się go
okroić do samych driverow to może to być bardzo intertesujące.
Adam Dybkowski
Guest
Sun Mar 21, 2010 2:12 am
W dniu 2010-03-19 09:15, Sebastian Biały pisze:
Quote:
BTW: Tyle że w AT91SAM7 nie ma takiego wsparcia dla własnych
bootloaderów, jakie jest np. w AVRach. "Bootloader" w tym przypadku to
zwykły kawałek softu, który leży sobie na początku Flasha. A cały
normalny program musisz linkować odpowiednio dalej (np. od 32KB).
To nie ma znaczenia gdzie będzie fizycznie flash ładowany, byle by można
potem zmienić wektory przerwań.
Z tym nie ma problemu. W kodzie bootloadera wstawiasz standardowy skok
przez wektor ładowany z rejestru kontrolera przerwań:
0x18: ldr pc, [pc, #-3872] ; fffff100
0x1c: ldr pc, [pc, #-3872] ; fffff104
A potem konfigurujesz konkretny adres przerwania IRQ i FIQ w kontrolerze
przerwań. Po starcie właściwego systemu możesz zmienić adres i już.
Można też dla uproszczenia nie korzystać w bootloaderze w ogóle z
przerwań (nie jest to problemem przy prostym dostępie do UARTu i karty
SD) a na początku bootloadera wstawić na stałe rozkazy skoków o 32KB do
przodu - jeżeli przyjmiesz tyle miejsca na swój bootloader. Potem w
kodzie docelowej aplikacji zajmiesz się przerwaniami jak chcesz.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
cepu69
Guest
Mon Mar 22, 2010 3:20 pm
Sebastian Biały wrote:
Quote:
cepu69 wrote:
A ja standartowo polecam eCos'a :http://ecos.sourceware.org/
No własnie po zabawie z FreeRTOSem czas na nastepnego

Zastanawiam się
nad ecos-em jako bazą do mojej apliakcji. Jęlsi faktycznie da się go
okroić do samych driverow to może to być bardzo intertesujące.
Tak ale np. wsparcie dla FAT-a wymaga : dynamicznej alokacji pamieci itd.
Zalaczam plik konfiguracyjny (opis uzytych komponetow) bez kernela, z
dolaczonymi m.in. pakietami LIBC, FAT, MMC.
Adam Dybkowski
Guest
Wed Apr 07, 2010 11:34 pm
W dniu 2010-04-08 00:37, voland pisze:
Quote:
at91sam7s128. Generalnie juz napisalem se taki bootloader i wyglada na
to ze dziala. flashuje se binarke do pamieci pod adres 0x109000, i
sciągam potem pamieć na twardy dysk i zawartość się zgadza, ale mam
inny problem mianowicie nie wiem jak skonfigurowac linker dla programu
który ma być wgrany pod ten adres, niby skonfigurowalem coś w pliku
flash.lds czyli zmieniłem adres pamieci flash i jej wielkość, wygląda
to mniej więcej tak:
MEMORY
{
sram (W!RX) : ORIGIN = 0x200000, LENGTH = 0x8000
flash (RX) : ORIGIN = 0x109000, LENGTH = 0x17000
}
No i jak kompiluje ten program z parametrem optymalizacji -s0 to niby
działa ale kiedy próbuje skompilować to zoptymalizowane to już się
wysypuje.
Jeszcze raz napisz, tyle że jaśniej. Ustawienia linkera (w szczególności
mapa obszarów pamięci) nie wpływają na proces kompilacji przecież, są
używane dopiero podczas konsolidacji. Więc nie może się po prostu
wysypywać (napisz jaki błąd dokładnie wystąpił?) kompilacja z powodu
przestawienia adresu obszaru Flasha.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
voland
Guest
Thu Apr 08, 2010 12:37 am
On 21 Mar, 03:12, Adam Dybkowski <adybkow...@45wp.pl> wrote:
Quote:
W dniu 2010-03-19 09:15, Sebastian Biały pisze:
BTW: Tyle że w AT91SAM7 nie ma takiego wsparcia dla własnych
bootloaderów, jakie jest np. w AVRach. "Bootloader" w tym przypadku to
zwykły kawałek softu, który leży sobie na początku Flasha. A cały
normalny program musisz linkować odpowiednio dalej (np. od 32KB).
To nie ma znaczenia gdzie będzie fizycznie flash ładowany, byle by można
potem zmienić wektory przerwań.
Z tym nie ma problemu. W kodzie bootloadera wstawiasz standardowy skok
przez wektor ładowany z rejestru kontrolera przerwań:
0x18: ldr pc, [pc, #-3872] ; fffff100
0x1c: ldr pc, [pc, #-3872] ; fffff104
A potem konfigurujesz konkretny adres przerwania IRQ i FIQ w kontrolerze
przerwań. Po starcie właściwego systemu możesz zmienić adres i już.
Można też dla uproszczenia nie korzystać w bootloaderze w ogóle z
przerwań (nie jest to problemem przy prostym dostępie do UARTu i karty
SD) a na początku bootloadera wstawić na stałe rozkazy skoków o 32KB do
przodu - jeżeli przyjmiesz tyle miejsca na swój bootloader. Potem w
kodzie docelowej aplikacji zajmiesz się przerwaniami jak chcesz.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Przypadkiem sie natknąłem na ten wątek bo mam podobne problemy też z
at91sam7s128. Generalnie juz napisalem se taki bootloader i wyglada na
to ze dziala. flashuje se binarke do pamieci pod adres 0x109000, i
sciągam potem pamieć na twardy dysk i zawartość się zgadza, ale mam
inny problem mianowicie nie wiem jak skonfigurowac linker dla programu
który ma być wgrany pod ten adres, niby skonfigurowalem coś w pliku
flash.lds czyli zmieniłem adres pamieci flash i jej wielkość, wygląda
to mniej więcej tak:
MEMORY
{
sram (W!RX) : ORIGIN = 0x200000, LENGTH = 0x8000
flash (RX) : ORIGIN = 0x109000, LENGTH = 0x17000
}
No i jak kompiluje ten program z parametrem optymalizacji -s0 to niby
działa ale kiedy próbuje skompilować to zoptymalizowane to już się
wysypuje.
Goto page 1, 2 Next