Nachrichten

1

Software / Re: boop 0.9 - mit interrupts

20. Sep 2007, 23:01

achtung: das klappt nur wenn boop_rom.bin in das flash geschrieben wird ...

damit dass auch im ram geht, muessen die vektoren noch an den ram anfang kopiert werden (memap natuerlich auch nicht vergessen!). dazu mach ich grob sowas im startup.s:

Code: [Auswählen]


copy_exception_vectors:

        mov r0, #sram_addr
        ldr r1, =exception_vectors
        ldmia r1!, {r2-r9}
        stmia r0!, {r2-r9}
        ldmia r1!, {r2-r8}
        stmia r0!, {r2-r8}


wobei sram_addr eben 0x40000000 und exception_vectors halt der anfang der vektoren ist. wenn du den ldr auf de pc vom VICVectAddr relativ (-0xff0) machst genuegen wahrscheinlich am schluss auch 6 bytes.

cheers,

frank

2

Sonstiges / Re: Logo-Contest

17. Sep 2007, 20:58

hi,

habe vor kurzem mal ein dirty tool gehacked mit dem man 24bit rgb bitmaps (und nur diese) nach binaer bzw in ein header file (einfaches char array) wandeln kann, so dass man den kram einfach nur zeilenweise ins ram des displays schieben muss. ausserdem erzeugt das noch ein weiteres bmp, das ungefaehr den 'betty look' wiederspiegeln sollte.

evtl hilft euch das ja beim logo contest!

hier mal ein (wahrscheinlich eher langweiliges) bsp von mir:


und


sourcen und ne kurze anleitung wie immer auf meiner betty wiki seite:

http://hackdaworld.org/cgi-bin/awki.cgi/BettyTV

irgendwo in dem 'alternative firmware' kapitel.

das ding auf andere bildformate umzuwandeln sollte ja trivial sein. ich hatte nur schonmal eine kleine api fuer bmp (die ihr im uebrigen dazu braucht) geschrieben ...

wenn es mal ein cooles logo gibt, wuerde ich das evtl auch gern als .h bzw binaer haben.

viel spass,

frank

3

Hardware / Re: hackdabetty

04. Sep 2007, 01:18

deswegen ist es ja so schade, dass er das hier ohne den uart0_send bei mir nicht ordentlich macht (denke aber das prob dafuer gerade erkannt zu haben und hoffe das weglassen zu koennen).

was ein tcflush und ordentliches warten auf chip erase bewirkt (kann nun die byte replies lassen!) ...

hackbard@staubsauger:~/projects/arm/betty$ time sudo ./lpcload -d /dev/ttyS0 -f fwflash.hex -b -w hacked.bin
boot loader init ...
write firmware to ram ...
unlock go command ...
go ...
flushing lpc tx buffer: 30 f7
writing firmware to flash ...
D'OH ...ffff0

real    1m49.532s
user    0m0.132s
sys     0m0.192s
hackbard@staubsauger:~/projects/arm/betty$

das einzige was fwflash wie gesagt macht ist keine 0xffff words schreiben und lpcload (uebertraget immer 16 byte grosse bloecke) sendet erst garkeine schreibkommandos wenn alle davon den wert 0xff haben.

ich glaube ich verzichte auf sektor support, da ich die alternativ fw eh erstmal immer nur ins ram laden werde zum testen.



gru3,

frank

4

Hardware / Re: hackdabetty

04. Sep 2007, 00:00

Die Tricks:
- Nicht das Brennen ist der Engpass sondern die serielle Schnittstelle -> Also nicht unnötig Daten übertragen.

deswegen ist es ja so schade, dass er das hier ohne den uart0_send bei mir nicht ordentlich macht (denke aber das prob dafuer gerade erkannt zu haben und hoffe das weglassen zu koennen).

- Ein kleines Tool wird über ISP-Bootloader mit 38400 Bit/s geladen.
- Das Tool setzt dann die typische Betty PLL-Frequenz und läd den Rest des Tool mit 115200 Bit/s nach.

gut, das mache ich ja genau so ...

- Vor dem Flashen lasse ich vom Tool die SHA-1 Hashwerte der 19 Sektoren ermitteln und zum PC schicken (geht schnell - nur wenig Daten über RS232).
- Von Quellfile werden am PC auch die SHA-1 Hashwerte der 19 Sektoren ermittelt.
- Dann werden nur die Sektoren mit unterschiedlichem Hashwert gelöscht und programmiert (das ist bei AGB-Patch nur ein Sektor - deshalb nur 35 Sekunden Gesamtzeit).

ok, sektor support muss bei mir sicher noch rein! zieht man mal 10 sec fuer ram write und crc ab, bleiben 25 sec. grob gepeilt (auf wohl sektoren ja unterschiedlich gross sind) brauchst du dann fuer den kompletten flash (btw, du koenntest noch checken ob data 0xffff ist und einfach abbrechen. habe gerade ausprobiert, so 15 bis 17 der while(1) durchlaeufe braucht hier ein word write) grob 8 min. da ich ja quasi doppelt daten via uart sende koennte ich 16 min verkraften, fehlen noch knapp 10.

und da faellt mir gerade ein, fuer den hash liest du ja auch noch den sektor aus, dafuer muesste man auch noch zeit abziehen .

ich muss wohl noch ein wenig lernen!

danke fuer input!

gru3,

frank

5

Hardware / Re: hackdabetty

03. Sep 2007, 21:27

hi colibri,

du darfst das da oben nicht falsch verstehen. wir hiengen alle drei im #bettyhacks chat ab bis einer deinen post bemerkte. wir haben uns alle draufgestuerzt un jeder hat wohl ohne wissen dass der andere nach mehr info fragt replied . also zumindest ich haette mir meinen beitrag gespart, haette ich von den vorherigen zweien gewusst.

das mit dem flash habe ich mir dann auch gedacht (andere vermuteten auch irgendwas a la gurkensalat). ich habe mich dann nach deinem post auch dran gemacht die fw zu patchen.



allerdings wusste ich natuerlich nichts von dem speicherlayout und der crc. zudem dauert bei meinem tool ein kompletter flashwrite so schaetzungsweise 20-30 min.

die neue und alte crc hatte durch den bootloader herausgefunden:

BIOS 000233E0 6D6D3572 - should be 81D8E589

ich musste also mind. 3 mal schreiben und 2mal editieren. (drum muss ich dieses bild jetzt einfach zeigen auch wenn es ja nun ein alter schuh ist :p)

wegen dem flash schreiben haette ich deswegen auch gleich noch eine frage. ich denke mal bei dir geht das bestimmt wieder viel viel schneller, oder? ich wuerde das hier zumindest gern etwas beschleunigen.

ich schreibe ein word mit

Code: [Auswählen]


int flash_write(u32 addr,u16 data) {

        u16 check;

        if(data==0xffff)
                return 0;

        *((unsigned volatile short *)addr)=0xa0;
        *((unsigned volatile short *)addr)=data;
        while(1) {
                check=*((unsigned short *)addr);
                if((data&0x80)==(check&0x80))
                        break;
        }
        if(data!=check)
                return -1;

        return 0;
}


in einer anderen routine receive ich immer jeweils 2 byte ueber uart und schreibe die dann mit der oberen fkt. weil das teilweise nicht funktionierte habe ich zur kontrolle die erhaltenen bytes einfach mal wieder zurueckgeschickt an den host. dann ging es ploetzlich reibungslos. daher vermute ich ein timing problem. ich dachte egtl dass man mit  dem "if((data&0x80)==(check&0x80)) break;" teil egtl genuegend lange vor dem naechsten write wartet. hast du ne idee? bzw allgemein tips waeren toll .

auf alle faelle nochmal danke fuer die infos im wiki!

gru3,

frank

ps: nichts desto trotz waere es fuer die alternativ fw wichtig zu wissen wie man das lcd anspricht! ein glueck will sich netguy darum kuemmern!

6

Hardware / Re: hackdabetty

03. Sep 2007, 00:32

schoen! aber ...

./colibri -vvv



gru3,

frank

7

Hardware / Re: hackdabetty

02. Sep 2007, 14:42

seltsam ist, auch wenn der main code als erstes kommt - funktionen kann ich nicht verwenden. evtl nimmt er da direkte spruenge und dann landet der pc irgendwo. ist aber nur eine vermutung.

ps: den flash an bank0 habe ich mal ausgelesen, so vertrauenswuerdig schaut das allerdings bei mir nicht aus. 

das alles hat sich jetzt dank netguy und dem tip von colibri mit dem bank init geaendert. man kann seine firmware mit hilfe von lpcload und fwflash nun in den flash an bank0 schreiben. die beispiel firmware betty.c laeuft super vom flash und announced sich stolz ueber uart nach eingabe eines beliebigen buchstabens mit 115200 baud.

gru3

frank

8

Software / Re: Betty-Heaven.exe / Betty-Dumps.zip

14. Aug 2007, 21:45

hi,

Wenn Du folgendes einfügst, sollte es funktionieren

Code: [Auswählen]

//Flash1 auf 16 bit einstellen (ist vom ISP-BootLoader noch auf 32 bit eingestellt)
BCFG0 = 0x1000FBEF;

danke, so funktioniert es. ich dachte das wuerde durch die BOOT[1:0] pins schon so gesetzt werden. tatsaechlich hatte ich das sogar schon probiert, allerdings durch BCFG0|=(1<<28), was wohl keine gute idee war, da er (so vermute ich) dabei wohl bei manchen bits unsinn liest (und dann setzt).

danke,

frank

9

Software / Re: Betty-Heaven.exe / Betty-Dumps.zip

14. Aug 2007, 18:07

hi colibri,

leider ist in den zip files kein source dabei. daher eine frage, hast du eine idee was beim fwbc code

-> http://www.hackdaworld.org/cgi-bin/gitweb.cgi?p=my-code/arm.git;a=blob;f=betty/fwbc.c;

schief laeuft?

hier mal ein auszug aus meinem dump:

00000000  f0 20 00 00 f0 20 00 00  f0 20 00 00 f0 20 00 00 
00000010  f0 24 00 00 00 00 00 00  ff f0 00 00 f0 14 00 00 
00000020  4f 42 00 00 32 64 00 00  00 54 00 00 00 48 00 00 

in 4 byte abstaenden bekomme ich die ersten 2 bytes genauso raus wie du (modulo endianness). die letzten 2 byte sind immer '00 00'.

gru3,

frank

10

Hardware / Re: hackdabetty

09. Aug 2007, 01:52

sach mal mit Flaschmagic kann ich wunderbar die Datei übertragen alerdinks finde ich die passende startadresse nicht kanste mir da mal helfen

0x40000200

das ist natuerlich nicht ganz richtig und erklaert evtl auch einige meiner probleme die ich hatte. wenn dein arm code nicht mit der main funktion beginnt hast du natuerlich einen anderen entry point. komischerweise erzeugt objcopy beim konvertieren nach intel hex keine '03' oder '05' record types. wenn ich die mal bekomme pass ich lpcload dementsprechend an, ist nicht schwer. ich weiss nicht was ich falsch mache, koennte mir aber gut vorstellen dass man objcopy anderst verwenden muss! alternativ koennte man die fw mit objdump -S nach der main funktion parsen und den addr-wert auf 0x40000200 addieren.

seltsam ist, auch wenn der main code als erstes kommt - funktionen kann ich nicht verwenden. evtl nimmt er da direkte spruenge und dann landet der pc irgendwo. ist aber nur eine vermutung.

naja, bis das geklaert ist hacke ich alles einfach nur in einer main funktion .

gru3,

frank

ps: den flash an bank0 habe ich mal ausgelesen, so vertrauenswuerdig schaut das allerdings bei mir nicht aus. anleitung und tools auf meiner wiki seite. 

11

Hardware / Re: hackdabetty

08. Aug 2007, 18:11

noch nen Nachtrag ich komme mittlerweile ziemlich weit allerdings meckert es beim auslesen.

wie oben gesagt, minicom kurz starten und beenden hat da bei mir geholfen. allerdings habe ich den init des seriellen ports jetzt glaube ich gefixed. also bei mir geht es zumindest ohne. ka ob das in deiner version schon geaendert ist.

sach mal mit Flaschmagic kann ich wunderbar die Datei übertragen alerdinks finde ich die passende startadresse nicht kanste mir da mal helfen

0x40000200

nachtrag:
0x23 transmitten funzt mit der jetzigen fwbc firmware auch. aber alles noch sehr seltsam. werde mich nun mal dran versuchen den flash auszulesen ...

gru3

frank

12

Hardware / Re: hackdabetty

06. Aug 2007, 19:37

hi theborg!

EDIT: habs

hast evtl schon eine idee was ich bei dem fwbc verbockt habe, dass da nur muell vom uart kommt?

muell = À€øø€€ø€xü€x€ usw.

wenn man von dem 10mhz quarz ausgeht sollte die baudrate mit 65 als divisor doch 9k6 baud sein ...

mfg, frank

13

Hardware / Re: hackdabetty

06. Aug 2007, 19:20

Du arbeitest mit dem Max232? Ist der nicht nur für 5V ausgelegt?

die 3v(?) von tx genuegen anscheinend. rx scheint auch 5v auszuhalten. an vcc des max232 selbst lege ich 5v an. gnd von der 5v spannungsquelle und vom arm muss man natuerlich kurz schliessen.

14

Hardware / Re: hackdabetty

06. Aug 2007, 17:42

hi

Hab deine Datei lpcload.c eben mal unter Cygwin compiliert und die Exe ausgeführt - allerdings bekomm ich

Code: [Auswählen]

boot loader init ...
  >> ? | 3f | (1)
txrx read: bad return byte '3f'
zurückgeliefert. Liegt es daran, dass mein TTL-Wandler ab und zu mal rumspinnt oder liegt es einfach daran, dass das Programm unter Windows garnicht gehen KANN?

komisch. er scheint das '?' zu echo'en. das sollte er nicht tun. er muesste mit "Synchronized" antworten. kann es sein, dass du eint1 nicht mit gnd verbunden hast?

tx und rx an max232, gnd von max232 an gnd und eint1 vom arm, dann batterien rein. danach das lpcload starten. sollte dann sowas kommen:

Code: [Auswählen]


$ sudo ./lpcload -d /dev/ttyS0 -f fwbc.hex -v
boot loader init ...
  >> ? | 3f | (1)
  << Synchronized.. | 53 79 6e 63 68 72 6f 6e 69 7a 65 64 0d 0a | (14)
  >> Synchronized.. | 53 79 6e 63 68 72 6f 6e 69 7a 65 64 0d 0a | (14)
  << OK.. | 4f 4b 0d 0a | (4)
  >> 10000.. | 31 30 30 30 30 0d 0a | (7)
  << OK.. | 4f 4b 0d 0a | (4)
write firmware to ram ...
writing 0x10 bytes to 0x40000200
  >> W 1073742336 16.. | 57 20 31 30 37 33 37 34 32 33 33 36 20 31 36 0d 0a | (17)
  << 0.. | 30 0d 0a | (3)
  >> ##<"@.. | 23 23 3c 22 40 0d 0a | (7)
  >> #X0#8.. | 23 58 30 23 38 0d 0a | (7)
  >> #+>D$.. | 23 2b 3e 44 24 0d 0a | (7)
  >> #L$SB.. | 23 4c 24 53 42 0d 0a | (7)
  >> #!-!-.. | 23 21 2d 21 2d 0d 0a | (7)
  >> !X@  .. | 21 58 40 20 20 0d 0a | (7)
  >> 2081.. | 32 30 38 31 0d 0a | (6)
usw ...


ausserdem natuerlich schauen das lpcload aktuell ist. wurde ja gestern noch gefixed (fast, aber wenigstens sowas wie hier solltest du sehen*). ob windoes probleme macht kann ich leider nicht sagen ...

*) wer schon weiter gekommen ist und spaeter probleme beim daten schreiben bekommt, moege die note in meinem wiki beachten:

note: funnily enough (sometimes) the tool just works properly after having started minicom ... (maybe some serial port config issue, dunno!)

dann geht es aber! ja ich weiss, alles sehr unsauber. war aber nie fuer enduser gedacht.

gru3

frank

15

Hardware / Re: hackdabetty

06. Aug 2007, 14:42

3 Dateien davon sind fast lehr nur das Programm zum Flaschen läuft ich werde mir mal von NXP nen testcode runter laden und versuchen den zu flaschen.

also in den flash schreiben kann der bootloader nicht. du kannst eine firmware in den ram hauen, diese kann dann den flash schreiben oder lesen. steht auch in der doku.

wenn ihr windows habt, solltet ihr einfach mal diesen keil kram ausprobieren. damit sollte das egtl funktionieren. selbst fuer linux gibt es wie gesagt auch schon schoenere tools die man wahrscheinlich nur minimal umhacken muss (part id hinzufuegen). ich bin mir sicher, die keil software hat bestimmt auch schon firmware dabei, die dann den code ins flash schreiben kann.

wie oben schon gesagt, die leeren files werden hoffentlich bald voller.

gru3,

frank