Ich bin gerade dabei den gcc an einen 68332, also CPU32, anzupassen. Leider stuerzt mir bereits mein _start ab. Das hier funktioniert: void _start(void) { /* Hier habe ich unwichtes geloescht */ INTERN.qsm.qpdr |= 0x10; /* Schaltet die LED ein */ while(1); } Obiger Code schaltet eine LED am Prozessor ein und bleibt dann stehen. Also genau was man erwartet. Im folgenden haengt sich der Prozessor aber beim aufruf von aaa() gnadenlos weg: void aaa(void); void _start(void) { aaa(); } void aaa(void) { INTERN.qsm.qpdr |= 0x10; /* Schaltet die LED ein */ while(1); } ;Das ende von _start mit dem Aufruf von aaa() 220196: 6104 bsrs 22019c <aaa> 220198: 4e5e unlk %fp 22019a: 4e75 rts ;Die aaa() Funktion 0022019c <aaa>: 22019c: 4e56 0000 linkw %fp,#0 2201a0: 227c 00ff fa00 moveal #16775680,%a1 2201a6: 207c 00ff fa00 moveal #16775680,%a0 ;Einschalten der led 2201ac: 1028 0215 moveb %a0@(533),%d0 2201b0: 0000 0010 orib #16,%d0 2201b4: 1340 0215 moveb %d0,%a1@(533) ;while(1) 002201b8 <.L4>: 2201b8: 60fe bras 2201b8 <.L4> 2201ba: 4e71 nop Kann mir einer sagen was da schief geht? Olaf
Ich denke schon das der Stack richtig initialisiert ist. asm("movel #0x40000,%sp" ); Aber so wie ich das sehe sollte das doch erstmal vollkommen egal sein. Ich springe ja nur eine Funktion an aus der ich niemals wiederkomme. Zumindest meine LED sollte er doch mal einschalten. Ich habe auch schon mit verschiedenen Werten fuer den Stack experementiert und auch mal die Initialisierung weggelassen. Keinen Unterschied. Dazu muss man wissen das das System ein Flashrom hat wo sich ein Loader drinbefindet der ueber die RS232 meinen Code entgegenimmt und ihn dann in einen anderen Block des FLash brennt und startet. Grundsaetzlich sollte also erstmal ein lauffaehiges System sichergestellt sein wenn mein Code laeuft zumindest fuer derart minimale Sachen. Falls von Interesse, so sieht der Speicheraufbau aus: http://www.mct.de/product/mega332/man.html#A2.1 Ich kann mir mit dem Loader auch einen Hexdump des Flashroms anschauen und was ich da sehe entspricht dem was mir objdump anzeigt. Olaf
Ich springe ja nur eine Funktion an aus der ich niemals wiederkomme. Schon der Aufruf will die Rückkehradresse in den Stack schreiben. Wenn da kein Speicher ist, gibt es stattdessen einen Bus-Trap. (Vector 5 ?) Der wird vom Betriebssystem abgefangen.
> Schon der Aufruf will die Rückkehradresse in den Stack schreiben.
Der Einwand ist natuerlich, aeh..wie soll ich sagen, gut. :-)
Aber nehmen wir mal an ich waere wirklich nicht in der Lage den Stack
richtig zu initialisieren, dann sollte doch mein Programm wenigstens
dann laufen wenn ich ihn garnicht initialisiere. Einfach deshalb weil
mein Programm vom Loader gestartet wird und der seinen Stack auf
irgendwas stehen haben wird. Ausser natuerlich dieses Programm wuerde
vor dem starten meines Programms den Stack nochmal extra irgendwo ins
Nirvana initialisieren.
Sieht denn der Maschinencode nach Meinung der 68k Programmierer gut aus
wenn man unterstellt das der Stack richtig ist? Dann wuesste ich das ich
wenigstens in der Richtung weiterforschen muss. Ich hab zwar mal 68k in
Assembler programmiert, aber das war auf einem 68008 vor zwanzig Jahren
und die Mnemonics sahen auch irgendwie anders aus wenn ich mich recht
erinnere. Ich wuerde also einen dummen Fehler meinerseits nicht
ausschliesen wollen....
Mir faellt gerade ein, ich muss mal probieren was passiert wenn ich
im laufenden Teil des Programmes irgendwas auf den Stack pushe. Das
koennte immerhin mal testen ob der Stack einen Buserror verursacht.
Olaf
%sp mag der Stackpointer sein. War im 68040 register a7. %fp mag der Framepointer sein. Was im 68040 register a5. Versuch mal asm("movel #0x3fff8,%sp" ); asm("movel #0x40000,%fp" ); LINK An,#Offset An->-(A7) Framepointer in Stack retten A7-> An neuen Framepointer aufsetzen A7+#Offset -> A7 Offset sollte negativ sein, -1 ... -32768 Gegenstück zu UNLK UNLK An Stackpointer und Framepointer zurückholen An -> A7 (A7)+ -> An Gegenstück zu LINK
Ich habs jetzt... Ein push: asm("movl %d0,-(%sp)"); Hat mein System gnadenlos ins Nirvana geschickt. Es war wohl ein Fehler anzunehmen das der loader der mein Programm startet auch bereits meinem System eine minimale Basisinitialisierung verpasst. Ich hatte kein Ram da wo es sein sollte weil der die ChipsSelect fuer das Ram wohl nicht programmiert. Ich habs jetzt nachgeholt und alles sieht gut aus. Olaf
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.