Although boot2.img is sent on RS232 as-is, OSes must be sent with a 32-byte header. The first 24 bytes, as far as I know, are unused. Bytes 24-27 are the size of the data to write to /tmp/manifest_img (nspire_emu always just set this to 0, and it worked, so I guess it's not important. Probably something left over from the CAS+.), and bytes 28-31 are the size of the data to write to /tmp/TI-Nspire.tnc. (Note: these sizes are big-endian)

Quote from: nspire_emu v0.01 source code, exec_hack() function (run in place of the xmodem receive function)

printf("Loading OS from %s\n", os_filename);
FILE *f = fopen(os_filename, "rb");
if (f) {
        u8 *mem = ram_ptr(arm.reg[0]);
        u32 size = fread(mem + 32, 1, arm.reg[1], f);
        memset(mem, 0, 28);
        mem[28] = size >> 24;
        mem[29] = size >> 16;
        mem[30] = size >> 8;
        mem[31] = size;
        fclose(f);
        arm.reg[0] = 0;
} else {
        perror(os_filename);
        arm.reg[0] = 1;
}
arm.reg[15] = arm.reg[14];

I've tried flashing an OS through RS232 on a "normal" Nspire and it worked - thanks!


Ok, I still have 3 prototypes running boot2 1.1.7314 and OS 1.1.7320.


I've just taken one of them:

1) remove the 1.1.7320 OS

ok

2) send the 1.1.9227 ndlessable OS in RS232 with its header

failed...

Boot Loader Stage 1 (1.1.7314)
Build: 2007/2/23, 20:43:36
Copyright (c) 2006, 2007 Texas Instruments Incorporated
Using developer keys

Last boot progress: 32
Clocks:  CPU = 90MHz   AHB = 45MHz   APB = 22MHz

Available system memory: 37292
SDRAM memory test:   Pass
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A
Boot option: Normal

Loading DIAGS software...

Error reading/validating DIAGS image

Error loading DIAGS. Switching to BOOT2.

Loading BOOT2 software...

99%
BOOT1: loading complete (331 ticks), launching image.



Boot Loader Stage 2 (1.1.7314)
Build: 2007/2/23, 20:48:12
Copyright (c) 2006, 2007 Texas Instruments Incorporated
Using developer keys

Clocks:  CPU = 90MHz   AHB = 45MHz   APB = 22MHz


Initializing graphics subsystem.
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A
Boot option: Normal


Initializing filesystem.
Datalight Reliance v2.10.1150
Copyright (c) 2003-2006 Datalight, Inc.
Datalight FlashFX Pro v3.00 Build 1358
Nucleus Edition for ARM9
Copyright (c) 1993-2006 Datalight, Inc.
Patents: US#5860082, US#6260156.
Filesystem ready.

Loading Operating System...

Error loading OS image. Removing OS remnants.
Deleting file [/phoenix/manuf.dat]
Removing directory [/phoenix/install/]

Waiting for OS download.
Starting Connectivity services.
Initializing USB subsystem...Done.
Initializing interim USB loader...Done.
USB Download is enabled.
Press <Enter> to download through the serial port.
Checking battery level.
Battery level is OK.
Begin XMODEM file transfer.
File transfer complete. Saving pre-load file.
File saved. Installing new Operating System...
TI_OS_INSTALL_PRECHECK (5)
TI_OS_INSTALL_VERIFYING_IMAGE (10)
IMAGE: verifying file "/tmp/TI-Nspire.tno"
IMAGE: file length is 0
TI_OS_INSTALL_VERIFYING_RESOURCE (95)
Deleting file [/tmp/TI-Nspire.tnc]
TI_OS_INSTALL_FAILED
  TI_OS_INSTALL_IMAGE_INVALID



Boot Loader Stage 1 (1.1.7314)
Build: 2007/2/23, 20:43:36
Copyright (c) 2006, 2007 Texas Instruments Incorporated
Using developer keys

Last boot progress: 35
Clocks:  CPU = 90MHz   AHB = 45MHz   APB = 22MHz

Available system memory: 37292
PM is turning the device OFF
Stupid bug... TI messed up with /tmp/TI-Nspire.tno and /tmp/TI-Nspire.tnc.
I suppose the send OS is stored to /tmp/TI-Nspire.tnc.
But the boot2 does check /tmp/TI-Nspire.tno, and complains that the file length is 0 (as it doesn't exist).
But guess what... as the check did fail, it then removes /tmp/TI-Nspire.tnc!!!

Any idea to bypass this problem ?


So now, I have only 2 prototypes running boot2 1.1.7314 and OS 1.1.7320 left.
By using such "destructive" methods, I can only fail 1 more time...

Edit: Here's a possibility to recover the OS. Use Home-Enter-X to send a "temp image" (a .tno/.tnc file, without the 32 byte header) - it will run the sent OS without installing it. It will have to be compatible with the installed OS, though, in terms of filesystem contents. I tried using a modified nspire_emu to run 1.1.9227 on top of a 1.1.8008 installation; there were some messed-up text messages but other than that it seemed to work fine. If you could run a USB-capable OS on top of a 1.1.7320 installation, then you could probably just dump the old OS with TiLP.

Going to try that.

Doesn't seem dangerous!


By the way... any info on the RS232 diags image?
Sending my 640Kb images through RS232 just doesn't work...
(no error message: the Nspire just turns off, and Esc+Menu+G doesn't trigger anything)

I was able to run that diags with the DiagsLauncher program.
Runs on the emulator, should run on the calc without signature checking.
Subtract 8 more bytes from that program I sent for the larger diags proto header.


EDIT: change one line to look like:
if (fread((void *)0x117FFFB4 , 1, DIAGS_SIZE, ifile) != DIAGS_SIZE) {


It worked with boot2 1.1.8008 in nspire_emu... I guess 1.1.7314 probably has yet another bug. (With all these boot2 bugs, it's a wonder TI managed to ever get the OS on these calcs in the first place.) An alternative would be to try to use our exploit (modified to dump boot2 to rs232 instead of to a file) but you know how finicky that can be.

The message "Initializing interim USB loader...Done." is intriguing - the current boot2 still has unused vestiges of this "interim USB loader".

I'd like to help more, but I have school work to deal with right now. Maybe tomorrow.

It allways stops at 21%...

Strangely, I've tried my modified 1.1.9227 OS (with the added header), and I got the same error, but at 97%...

You can prepend almost whatever you want at the beginning of the file - boot2 searches for the first 0x1A byte and starts working from there, so as long as you don't add a 0x1A byte, it shouldn't affect things. Maybe there's an xmodem issue that's truncating the file? Try some different amounts of padding, like try to make the file a multiple of 0x400 bytes (the maximum xmodem packet size) or something.

Edit: it also tolerates padding at the end; 0x400 extra null bytes at the end should fix any xmodem truncation issues.

I had RS232 transfer problems with the 1.1.9170 boot2 (several "retry" requests, and as you could see the file was bad...)
Strangely, without modifying anything to the interface, those errors didn't happen again after downgrading the boot2 to 1.1.8007 or 1.1.8310.

With 1.1.8007 boot2, I couldn't launch any developer OS as a test image (1.1.8008, 1.1.8410, 1.1.9227).
The calculator just turned off after reading/verifying the image up to 100%

With 1.1.8310 boot2, I could launch the 1.1.8008 OS as a test image.


After using TI-Nspire Computer Link modified code, OS 1.1.7320 has just been dumped.
Thank you all for your great help.



We are only missing boot2 1.1.7314 now.

Ok. We're still missing Boot2 1.1.7314.


Let's sum up what's left for dumping:
- a TI-Nspire with Boot2 1.1.7314 and with OS 1.1.7320.
- a TI-Nspire with Boot2 1.1.7314 and without any OS.

According to previous tests, it seems it's not possible to install a newer OS without updating the Boot2.
(no full USB support in this Boot2, and seems OSes can't be installed through RS232 because of some bugs)


I've tried "exploit1" for 1.1 boot2, by sending special TNC files (adding them the header needed for RS232) targetting various addresses.

With newer 1.1 boot2, most of the time the calculator just freezed. The rest of the time, it displayed some artifacts, or rebooted. And when the right address was targetted, it displayed what we wanted.

With this oldest boot2, on the 1st try (targetting address 0x11b00000) I got a strange garbage I've never seen on the screen. I was just thinking "why not?...".

But then I targetted:
0x11b08000
0x11b10000
0x11b18000
0x11b20000
0x11b28000
0x11b30000

I allways got exactly the same garbage on the screen.

Knowing that this boot2 is smaller than newer boot2, I targetted the minimum and maximum address:
0x11a00000
0x11cf8000

Again, the same garbage on the screen.




Seems exploit1 is not working correctly on this oldest boot2... (or in RS232).
Any idea?

Quote from: critor on March 20, 2011, 01:25:45 pm

Seems exploit1 is not working correctly on this oldest boot2... (or in RS232).
Any idea?

The right address is going to be a lot lower if you're using rs232. For 1.1.8007 it would be around 11a00000. Since 1.1.7314 is about 150kB smaller when uncompressed, I would try 119d8000.

While I go on getting this pattern on the screen, does it mean I'm still "too high" to your advice?

Quote from: critor on March 20, 2011, 01:25:45 pm

Seems exploit1 is not working correctly on this oldest boot2... (or in RS232).
Any idea?

The right address is going to be a lot lower if you're using rs232. For 1.1.8007 it would be around 11a00000. Since 1.1.7314 is about 150kB smaller when uncompressed, I would try 119d8000.

Thank you very very much Goplat, you're very accurate!
"Exploit1" worked by targetting 0x119e0000 on my OSless Nspire with boot2 1.1.7314.




Now we should have all addresses needed for "exploit2".
Do they seem correct to you?

But there seems to be a little problem...
If you remember my previous experiences with "exploit2", in some situations it seemed to work (got the progress bar and could reboot by pressing on), but the files weren't created in the filesystem...

And I can't check if the files were created correctly without upgrading boot2...
(no USB and no OS untill that...)