OCD Commander, Wiggler i ARM7

Heh bo widzisz sprawa jest o tyle skomplikowanana ze zeby sciagnac cokolwiek z flasha musisz napisac program ktory zaladujesz do ramu i uruchomisz z poziomu OCD . Chetnie pomoge pisz na priv

Zaraz, zaraz ... Dlaczego od razu na priv ? :-)

Piszcie na grupe. Chetnie poczytam.

Dnia Sun, 19 Mar 2006 20:59:19 +0100, ::WiReFree:: napisał(a):

Bu. To w takim razie jeszcze trochę potrwa, bo jestem w połowie manuala do ARM7TDMI ;)

Dzięki! Może znasz w sieci jakieś miejsce z przykładowym kodem? ARMBOOT?

Pozdrawiam Marcin Stanisz

boot loader uboot i eldk z kroskompilatorami a z tym zgraniem zawartosci flasha to moze byc powazna sprawa za pomoca OCD nie da sie raczej tego zrobic ale mozesz napisac aplikacje ktora OCD wgra do RAM'u i uruchomi a ta aplikacja odczyta zawartosc flash'a i wysle np po tftp

:)

Dnia Mon, 20 Mar 2006 11:14:25 +0100, ::WiReFree:: napisał(a):

Dziękuję, obejrzę. Widzę, że szedłem w dobrym kierunku, a armboot został spaczowany dla mojego procka.

RS232 wystarczy :)

Pozdrawiam Marcin Stanisz

Witam, W open OCD (odpowiednik OCD Commandera tyle ze open source'owy) jest opcja "dump_binary <file> <address> <size>" Nigdy tego co prawda nie probowalem, bo zawsze wgrywalem program do procka, ale wyglada na to, ze tym sposobem mozna zgrac zawartosc pamieci do pliku. Nie wiem jednak jak jest gdy pamiec jest zabezpieczona przed odczytem, itp...

Dnia Mon, 20 Mar 2006 16:39:40 +0100, Jack Houseman napisał(a):

Nawet się pod Cygwinem skompilował, coś ściągnął, to coś zaczyna się nawet sensownie od jakby inicjalizacji wektorów:

Disassembly of section .data:

Na razie jednak po wgraniu do RAM i próbie odpalenia (resume) od adresu

Dziękuję i pozdrawiam Marcin Stanisz

Marcin Stanisz napisał(a):

Poczytaj listę instrukcji ARMa albo nawet jakiś samouczek to się nieco rozjaśni. Otóż instrukcja umieszczona pod adresem 0, wykonywana po resecie, nakazuje załadowanie do PC wartości 32-bitowej spod adresu (PC+24) czyli spod 0x20 (co zasugerował poprawnie disasembler). Czyli wykona się skok do 0x1000 i tam musi leżeć dalszy program.

Dnia Tue, 21 Mar 2006 08:22:17 +0100, Adam Dybkowski napisał(a):

Dzięki, Adam :)

Czytam równolegle to opasłe tomisko pt. ARM Architecture Manual, ale dobrze się przy nim zasypia ;)

Co mnie jeszcze zaniepokoiło w ściągniętym obrazie to to, że nie widać w nim żadnych tekstów (a na porcie szeregowym wypisuje ich niemało, ma też serwer WWW wbudowany). Pewnie obraz jest spakowany... W pierwszym poście się rypnąłem z wielkościami pamięci: w słowach ma 512K FLASH-a i 2M SDRAM.

Pozdrawiam Marcin Stanisz

Jak sie zacznie zabawe z ARM'ami to ilosc informacji jakie nalezy przeczytac zaczyna przyrastac w tempie wykladniczym :-) I wszystko "a must have".

Dnia Mon, 20 Mar 2006 16:39:40 +0100, Jack Houseman napisał(a):

A nie masz problemów z zapisem do RAM? U mnie RAM zaczyna się pod adresem

error: access caused data abort, system possibly corrupted

I oczywiście nie zmienia wartości... Jak wygląda twój plik konfiguracyjny do OpenOCD (ja mam standardowy do Wigglera)? Dokumentacja jest w powijakach, ale zanim zapytam autora wolę spytać was, czy nie robię jakiejś głupoty :)

Pozdrawiam Marcin Stanisz

Jesli o mnie chodzi, to nie uzywalem dotad komend bezposredniego zapisu/odczytu z pamieci. Zawsze korzystalem z OOCD tylko do debugowania, z czego najchetniej to opcja z programem wgrywanym do flasha (najstabilniej sie zachowuje - przy opcji RAM GDB potrafilo mi sie wykrzaczac). Przy LPC wrzutka programu do flasha z linii polecen (za pomoca bootloadera) trwa kilka sekund (dla malych programow), wiec nie odczuwam potrzeby koniecznego wrzucania programu przez jtaga. Zwlaszcza, ze on jest wciaz w wersji rozwojowej i o ile blad w debugowaniu grozi mi najwyzej utrata lacznosci z targetem, to np. przy wgrywaniu flasha mogloby sie to skonczyc np. skasowaniem boot loadera. Moja konfiguracja tez jest standardowa dla Wigglera. Jednak samo wgrywanie programu do RAM'u musi jakos dzialac, bo robilem kilka prob z uruchamianiem programow w RAM'ie i dzialaly :-)

Tak wiec chyba bedziesz musial spytac autora, ktory zreszta jest dosc chetny do pomocy :-)

Dnia Sun, 19 Mar 2006 19:51:32 +0100, Marcin Stanisz napisał(a): <ciach>

Mały updejt poświąteczny - udało się:

1. Uruchomić wgrywanie do RAM za pomocą OpenOCD,
2. Znaleźć binarną wersję armtool dla Win i też udaje że działa ;)
3. Skompilować bez błędów armboota.

Nie udało się:

1. Armtool pokazuje IDCODE na zmianę 00000000 lub FFFFFFFF, więc jakiś problem jest,
2. Armboot skompilowany GNUARM (gcc w wersji 4.0.2) nie działa po wgraniu do routera :(

Pozdrawiam Marcin Stanisz

Marcin Stanisz napisał(a):

Ściągnij źródła armtool i skompiluj pod cygwin'em. Po odpowiednim dopasowaniu kabelka do standardu armtool'a (a jeszcze lepiej zmianie źródeł pod schemat kabelka) powinno zadziałać. Musisz oczywiście przyznać też prawa do pisania po portach I/O wpisując magiczną komendę:

ioperm -i

Dnia Tue, 18 Apr 2006 22:26:15 +0200, Adam Dybkowski napisał(a):

Próbowałem, ale na razie bez powodzenia. Na razie Open OCD sprawuje się dobrze. Dzięki za zwrócenie uwagi na konfigurację kabelka - przyjąłem, że to będzie wiggler i już.

Się wie :)

Kolejny sukces: udało mi się napisać prościutki program w asm, który wysyła znaki przez UART :) (Oczywiście UART mi wcześniej firmware zainicjowało, a ja tylko znaki do bufora pcham.) Chyba blog założę ;) Szkoda, że nie można się ulubionemu zajęciu przez sen oddawać, byłoby przyjemne z pożytecznym...

Dobranoc Marcin Stanisz

Marcin Stanisz napisał(a):

A dokładniej? Nie kompiluje się czy nie działa armtool?

Obejrzyj źródła FreeRTOS - jest tam port na 7TDMI i dużo może się z tego przydać. Obsługa przerwań, wyjątków, cały system wieloprocesowy itp.

Dnia Wed, 19 Apr 2006 22:22:22 +0200, Adam Dybkowski napisał(a):

Ściągnąłem źródła z Midori, próbowałem skompilować, posypało błędami (zależności od libjtag, brak Makefile w katalogu nadrzędnym (!!), parę innych), więc na szybko dałem sobie spokój i poszukałem wersji skompilowanej. Teraz znalazłem stronę

Jasne. Moim celem było sprawdzenie, czy Open OCD w ogóle coś zapisuje do RAM, czy tylko udaje (ponieważ armboot się nie uruchamiał).

Ten "program" do wysyłania znaków przez UART jest tak duży, że przytoczę go w całości dla potomności (proszę nie komentować oczywistych niedorzeczności w postaci skoku do main, było późno :)):

.text .align 2 .global _start _start: bal main main: ldr r1,=0x90000000 ;@ adres rejestru UDR ldr r2,=0x21 @;wyslij ! str r2, [r1] loop: ldr r4,=100000

ldr r1,=0x90000000 ldr r2,=0x22 @;wyslij " str r2, [r1]

ldr r4,=100000

ldr r1,=0x90000000 ldr r2,=0x23 @;wyslij # str r2, [r1]

bal loop

.align 2

.bss

Marcin Stanisz

Dnia Mon, 17 Apr 2006 21:16:00 +0200, Marcin Stanisz napisał(a):

He, he (na razie próbka uruchomiona z RAM-u, pomija wszystkie inicjalizacje i ma źle skonfigurowany FLASH; problemem była w założeniu funkcja kopiująca Armboota z FLASH do RAM - nadpisywał sam siebie):

ARMboot 1.1.1 (Apr 17 2006 - 23:07:36)

ARMboot code: 00000000 -> 000135c0 DRAM Configuration: Bank #0: 00000000 8 MB Flash: 2 MB

Pozdrawiam Marcin Stanisz

Dnia Wed, 19 Apr 2006 22:22:22 +0200, Adam Dybkowski napisał(a):

No więc tak. Działam pod cygwinem. Nie ma on dwóch plików nagłówkowych, wymaganych przez pp_dev.c z pakietu libjtag (linux/ppdev.h i linux/ioctl.h). Drugi z nich jest w sys, pierwszy ściągnąłem z Internetu.

Dało to tyle, że podczas kompilacji o ppdev.h już się nie upomina, ale krzyczy parse error przy każdym wywołaniu ioctl().

Szukanie na razie dało tyle:

1. Cygwin nie obsługuje parport,
2. Są tacy, którzy skompilowali armtool "so wie so",
3. Ale ja nie wiem jak :)

Dałem sobie spokój :) I tak moją największą obawą jest uszkodzenie bootloadera we flashu - zastosowanej kości flash nie zaprogramuję inaczej.

Pozdrawiam Marcin Stanisz