hackdabetty

[Colibri]

Code: [Auswählen]


BOOL CmdPrgFlash(DWORD DstAddress, int WordLen, BYTE *SrcBuffer)
{

int i;
int k;
BOOL Error;
DWORD dwPrgAddress;
WORD wPrgData;
int Retries;
DWORD Address;
int FlashNr;
DWORD FlashBase;
DWORD wData;

if(DstAddress < FLASH_1_ADDRESS)
{
return false;//Error
}

FlashNr = (DstAddress < FLASH_2_ADDRESS) ? 1 : 2;
FlashBase = (FlashNr == 1) ? FLASH_1_ADDRESS : FLASH_2_ADDRESS;

for(i=0; i<WordLen; i++)
{
dwPrgAddress = DstAddress + (i * 2);
wPrgData = GetWord(&SrcBuffer[i * 2], true);//LSB first

Retries = 3;
do
{
Error = false;

Address = 0x555 << 1;
Address |= FlashBase;
wData = 0xAA;
((WORD*)Address)[0] = wData;

Address = 0x2AA << 1;
Address |= FlashBase;
wData = 0x55;
((WORD*)Address)[0] = wData;

Address = 0x555 << 1;
Address |= FlashBase;
wData = 0xA0;
((WORD*)Address)[0] = wData;

Address = dwPrgAddress;
Address |= FlashBase;
wData = wPrgData;
((WORD*)Address)[0] = wData;

BOOL DataOk;
DataOk = false;

for(k=0; (k<1000) & !DataOk ; k++)
{
if( (((WORD*)Address)[0] & 0x80) == (wData & 0x80) )
{
DataOk = true;
}
}
if(!DataOk)
{
Error = true;
}

Address = 0 << 1;
Address |= FlashBase;
wData = 0xF0;//Reset
((WORD*)Address)[0] = wData;
}while(Error & (Retries-- > 0));
}


return true;//OK
}



Ich verwende zu flashen obige Routine.

Ich habe gerade mitgestoppt:
- Ausgangssituation Flash1 von Betty-Dumps.zip ist auf der Betty
- Zeit start
- Power on der Betty
- Flash1 mit gepatchten AGB-Text flashen (incl. CRC korrektur). Flash2 ist deaktiviert.
- Flashen beendet
- Zeit stop

Hat ca. 35 Sekunden (nicht Minuten) gedauert.

Die Tricks:
- Nicht das Brennen ist der Engpass sondern die serielle Schnittstelle -> Also nicht unnötig Daten übertragen.
- 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.
- 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).

Colibri

[kackhart]

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

[kackhart]

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

[netguy]

uebrigens,

bei 0x8002309C ist eine routine, die die sc infos ausgibt. fuer jedes feld wird R1 und R0 geladen, dann 0x800359AC aufgerufen, dort findet wohl dann das auslesen der einzelnen felder aus dem sc chip statt. der aufruf nach 0x80034D64 is lediglich fuer die ausgabe der strings ueber einen bios callback da (callback kommando 0x26C in R12).

die font sektion ist in etwa so strukturiert (basis ist 80010000, ich gebe ab hier nur die offsets an):

0x04 -> anzahl der fonts (3)
0x10 -> wahrscheinlich pruefsumme
0x28 -> info-struktur ueber die fonts, array mit 3 tabellen:
0. font typ?
1. start-adresse der fon-bitmaps
2. adresse der character map, die auf entsprechende eintraege in der indextabelle verweist
3. tabbelle der zeichenbreiten
4. tabelle der inizies zu den einzelnen zeichen
5. weitere hints, wir startzeile des zeichens
6. immer 0x0

fuer die waves ab basis 0x800B0000:

0x04 -> anzahl der waves
0x2C wave info, array mit 9 tabellen zu je drei eintraegen:
0. typ des waves? immer 0x1F40
1. laenge des waves
2. startadresse des waves im flash

gruss,

chris

[eme]

@ kackhart ?
hast du das foto der tastaturbelegung (http://hackdaworld.org/pics/betty/betty_buttons.jpg) auch in groß?