[removed]

[parrotgeek1]

With reliable code execution, you can change the contents of the virtual memory translation table to map the boot1, if it's not mapped at the suitable place (0 or A4000000, back in the day) when the boot1.5 executes.

That is the problem. Nothing is mapped there.

How do I map it? I looked at some code in ControlX to map the second 32MB of RAM, but I don't understand how it works.

[critor]

Polydumper includes some asm code to map Boot1 at 0x00100000 :
archives_voir.php?id=3829

Code: Select all

asm("ldr r1,=0x00000C12");
asm("mrc p15,0,r0,c2,c0,0");
asm("str r1,[r0,#4]");
asm("ldr r0,=0x00100000");
asm("mcr p15,0,r0,c8,c7,1");

[parrotgeek1]

Polydumper includes some asm code to map Boot1 at 0x00100000 :
archives_voir.php?id=3829

Code: Select all

asm("ldr r1,=0x00000C12");
asm("mrc p15,0,r0,c2,c0,0");
asm("str r1,[r0,#4]");
asm("ldr r0,=0x00100000");
asm("mcr p15,0,r0,c8,c7,1");

Warning at PC=111E43A0: Unknown coprocessor instruction MCR EE080F37

[critor]

The real hardware won't bother.

[parrotgeek1]

The real hardware won't bother.

something else is wrong

Code: Select all

Warning at PC=111E43A0: Unknown coprocessor instruction MCR EE080F37
Error at PC=00020000: Bad PC: 00020000

   Backtrace:
Frame     PrvFrame Self     Return   Start
11229444: 00000000 00000000 1132CCC0 00008800
debug> c
Reset



Boot Loader Stage 1 (3.00.99)

etc
It didn't actually map the boot1 to 0x00000000 anyway ("d 100" just shows zeros)

I changed it to ldr r0,=0x00000000, which should work...right?

[critor]

Yes the code was mapping to 0x00100000 .

[parrotgeek1]

Yes the code was mapping to 0x00100000 .

"I changed it to ldr r0,=0x00000000, which should work...right?"

it didn't work when it was 0x00100000 either, though.

Can you just PM me?

[critor]

I don't think it'll work on nspire_emu anyway - something is not implemented if I remember well. Boot1 dumpers don't work on nspire_emu for example.

Maybe it'll work on firebird, but I'm not sure.
It should work on a real calculator.

[parrotgeek1]

I don't think it'll work on nspire_emu anyway - something is not implemented if I remember well. Boot1 dumpers don't work on nspire_emu for example.

Maybe it'll work on firebird, but I'm not sure.
It should work on a real calculator.

I need a method that works on nspire_emu or firebird because my CX was stolen last year (remember?)

Boot1.5 successfully *unmaps* the boot1 from 0x00000000, so there has to be a way to put it back again.

[critor]

I know.
I perfectly understand that's it's going to be hard (and hazardous) to develop a boot loader without an emulator.

To begin with, are you using nspire_emu or firebird ?