Omnimaga
Calculator Community => Other Calculators => Topic started by: critor on February 22, 2011, 09:39:31 pm
-
I've purchased 2 identical basic TI-Nspire prototypes.
They are very rare. Have a look there:
http://ti.bank.free.fr/index.php?mod=galerie&action=img&id_gal=9&id_img=129
They come with the oldest 1.1 OS/boot1/boot2/diags I've ever seen:
* OS 1.1.7320
* Boot1 1.1.7314
* Boot2 1.1.7314
* Diags 1.1.7387
They are detected as standard "TI-Nspire handheld" by Windows, but...
- None of the TI-Nspire Computer Link versions is listing them... Not even the 1.0 version, not even by updating/downdating the driver, not even by using the Computer Link 1.0 driver...
- The "Send OS" menu item is disabled.
- Unlike my other prototypes, they cannot exchange data with commercial TI-Nspire BAS/CAS, prototype TI-Nspire CAS/CAS+, and not even between themselves! The "Send" menu item simply returns immediatly, doing nothing.
If I'm guessing right, the USB link protocol had not been implemented yet in the 1.1.7320 OS. Seems it is going to be hard to dump anything without USB linking...
Any idea?
-
Sounds like you might have to go to the hardware level.
Open the calculator and compare with a production calculator, and if you are
lucky you might find a JTAG interface on those older calcs. Then you can dump the OS.
They got the OS on there somehow ....
I saw an article where one person had to open an Hp Ipaq for example and soldered to the JTAG connections - usually 3 or 4 wires.
He had to do it because he bricked it, and reflashed his boot loader.
-
Interesting, but it really sucks there are prototypes that looks so much like real calcs...
-
I might have found a way to dump the 1.7 OS/Boot2/Diags (but not the 1.7 Boot1 yet).
In that very old diags software, the "additional functions" menu has more options.
It has a "NAND Flash read" option, which lets you input a nandflash address and then shows the Flash content.
You can move in the flash by using arrow keys.
Have a look at the start of the boot2:
(http://i73.servimg.com/u/f73/13/23/13/53/th/camdum10.jpg) (http://www.servimg.com/image_preview.php?i=1217&u=13231353)
Then the idea would be to stuck an arrow key and use a webcam for hours...
I'll have to dump:
* 00004200-0015A800 for the boot2
* 0016B000-00210000 for the diags
* the OS which seems to start at 00221040
I can take the time to do it but once done, I'll probably need some help with the video files... Does anybody have an OCR software that could then generate the hex data from the videos?
Or an easier idea?
Thanks.
-
I have Adobe Acrobat - it works for OCR.
If all you have is hexadecimal digits [0-9A-F] it should work.
I have had problems having it distinguish small "L" from ones "1", and zeroes from capital "O" in other cases.
Look alike characters tend to be confusing to the OCR.
It gets worse when the Font size gets smaller.
-
Didn't someone(Benjamin Moody?) do something similar to Dump the TI-81? Maybe he could give you some advice on the setup he used.
-
Yeah that's what he did if I remember. Apparently the digital camera needs good lightning, though, and a good memory card+power source, because it had to film during one hour or so.
-
The nand reader seem to freeze randomly.
(after severall minutes with the down-arrow key stuck)
It means more work for me, but it's still possible.
(although I might lose my nerves when I'm going to film the OS... I've filmed 66% of the boot2 up to now)
But the other problem,is that it means more workk for the OCR too, as each video segment will have to be calibrated separately.
-
The nand reader seem to freeze randomly.
(after severall minutes with the down-arrow key stuck)
I checked out this routine in DIAGS 1.1.9266 (it's still there, just not called from anywhere, so I can test it in nspire_emu by hex-editing) and it has a bug - it uses another 72 bytes of stack memory every time you move up or down. Since the stack is only 32kB, this means after about 70 flash pages (420 movements) it will corrupt the heap :(
If you want to save a little time (and a lot of wear on the keypad connector) by not having to reboot, just leave the reader (by pressing esc - going back to the address entry screen with enter does not free the memory) whenever you've gone far enough that it's about to freeze.
-
That's a silly bug...
-
Does it accept a Ti-84+ keypad ?
And if so - see if there are undocumented calls for this prototype .
-
Does it accept a Ti-84+ keypad ?
And if so - see if there are undocumented calls for this prototype .
It does accept a TI-84+ keypad.
It's running a 2.42 TI-84+ system.
I've dumped it, and it is different from the 2.42 system included in production OS 1.1. According to my hex reader, there are many differences, and many of them are in the OS area.
I have an unrelated question.
According to the above tests, it seems that prototype cannot exchange data through USB.
Where is the USB linking code?
In the OS? In the Boot2? In both of them?
I'm just wondering if I could remove the OS, then send a more recent compatible OS (which I don't have for now) and use it to dump Boot1, Boot2 & diags.
But if this 1.1.7xxx boot2 has no USB linking support, then the calculator will be totally unusable.
-
According to the above tests, it seems that prototype cannot exchange data through USB.
Where is the USB linking code?
In the OS? In the Boot2? In both of them?
Both of them. But judging from the picture you posted, this boot2 is noticeably smaller than the later versions (0x1742EC bytes uncompressed, compared to 0x199B58 bytes for 1.1.8310) so most likely the linking code is not present in it.
-
I'm just wondering if I could remove the OS, then send a more recent compatible OS (which I don't have for now) and use it to dump Boot1, Boot2 & diags.
But if this 1.1.7xxx boot2 has no USB linking support, then the calculator will be totally unusable.
You still have the option of upgrading the later developer boot2 through RS232
-
I'm just wondering if I could remove the OS, then send a more recent compatible OS (which I don't have for now) and use it to dump Boot1, Boot2 & diags.
But if this 1.1.7xxx boot2 has no USB linking support, then the calculator will be totally unusable.
You still have the option of upgrading the later developer boot2 through RS232
Did you manage to build an adapter?
-
No, but I have collected pieces to make one.
The connector itself will have to be homemade -
a trimmed perferated circuit board where the wires are fastened that make contact with the nspire contacts.
Then a heavy duty rubber band straps it down to those contacts, and keeps the cover from sliding
down at the same time. A solder contact seems too unreliable and can damage those contacts.
They probably flashed boot1 onto those calculators, and then boot2,diags, and the OS through RS232.
-
I'm not really good at soldering but didn't damage the contacts, and I don't have any reliability issues. But having those wires hanging even when the adapter is not needed is annoying...
-
Ok guys. I've filmed the 1.1.7xxx diags code yesterday. It took me 90 minutes, with the finger on the down arrow, and exiting/restarting the NAND reader every 5-6 minutes as there is a bug (see above).
That diagnostics version is quite interesting, as it has a NAND reader and a NAND writer too. So you can read and modify anything in NAND, yes anything (like the downgrade protection for example).
It's very important to dump it, as we might be able to flash it on TI-Nspire CAS+ calculators for example and understand more about those older and strange prototypes running the 1.0 OS.
The range is 16B000-20FFFF.
But some some areas are filled with 0xFF bytes:
1CED0B-1FF7FF
200C90-20FFFF
So it seems we only have to dump:
16B000-1CED0A
1FF800-200C8F
Could some of you try to OCR the video with the appropriate tools?
I still have to dump the boot2 (it'll probably take me 3 hours) and the OS (...).
But I'd like to get some comments with the OCR first, before filming again.
Here are the files:
http://xandrean.free.fr/ns-1.1.7xxx-cam/
Thank you very much for helping.
-
I will see what I can do.....
The Datalight shell has utilities for dumping and flashing, but you have to go through RS232.
Start the shell on the emulator and execute the 2 commands:
<pre>
REL:A:\documents\ndless\>FlashFXDump /?
FlashFX Image Dump Utility
Datalight FlashFX Pro v3.00 Build 1358
Nucleus Edition for ARM9
</pre>
and
<pre>
REL:A:\documents\ndless\>FlashFXImage /?
FlashFX Image Flashing Tool
Datalight FlashFX Pro v3.00 Build 1358
Nucleus Edition for ARM9
...
...
...
</pre>
The first one you can dump Nor/Nand
The second one read/write only the nand.
One more reason to build an RS232 adapter ???
Its possible to trace these utilities and Build Ndless programs from them and get around not using RS232 ;)
-
I had an Idea regarding a dock connector. You Solder the pins to a pin header, and embed that into the spring-loaded plastic cover, and glue it down. You can still put on the slide case, so nothing's exposed during normal use.
-
bsl: How do you launch the Datalight command shell? I looked, but I never found any way to call it, besides running an Ndless program of course (which can't be done without USB)
-
I used an Ndless program here.
I think there is a key combination to launch it, but haven't found it - there is FlashFX strings in the boot code.
I also could not find it on OS2 with a simple binary search to patch that small Ndless program.
EDIT: I will add its Goplat's , charming, impresssive 16 byte program posted on another forum. :)
-
But having those wires hanging even when the adapter is not needed is annoying...
Its exactly why I want to keep the calculator portable.
I can connect it to other Nspires I have like a CAS+ , without having to solder more wires.
Finding a Wifi cradle online for parts is ideal for making an RS232 adapter - you already have a convenient
contact to the calculator. If the RS232 conversion circuit is already there , you need only solder
a cable with 3-4 wires with a DB9 on one end for the computer.
-
But Wifi cradles cost quite much, don't they?
-
I managed to get the old 1.1.7xxx boot log through RS232.
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: 17816
Clocks: CPU = 90MHz AHB = 45MHz APB = 22MHz
Available system memory: 37292
PM is turning the device OFF
PM has turned the device ON
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 (339 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...
100%
ðxâ À~ÃÏàzó=~ÃCÀžOæâž'˜óñž?OhÌšžOx3Ï~h4€LÀ
Beginning system initialization.
Preparing file system. This takes a while...
POSIX layer initialized.
POSIX devices initialized.
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.
POSIX file system initialized.
File system ready.
* P3 mode battery door detection
System build date: Feb 26 2007, 10:28:12
Available memory: 25556776 bytes
Purging temporary files...
Launching system...
-
In order to dump what's in the TI-XXXXXXXXXXX (oldest OS 1.1 based TI-Nspire prototype), I've made some flashing in RS232.
(it's not a problem, as I have 3 of them)
Remember the included OS doesn't seem to have an implemented USB linking protocol (device detected like all other TI-Nspire & TI-Nspire CAS prototype and production calculators, but not listed by TI-Nspire Computer Link).
Here are some pictures if you're messed up with all prototypes I've got:
http://ti.bank.free.fr/index.php?mod=galerie&action=img&id_gal=9&id_img=130
1) remove the 1.1.7320 OS
The 1.1.7314 boot2 "install OS" screen doesn't seem to provide any better USB linking protocol.
2) flash the newer 1.1.9227 OS (Ndlessable) in RS232
Failed...
See what I get:
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.
Setting Console Log Level = 0
RET - SC: TI_CN_Nspire_SC_Init called
NavNet Ready.
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.
Error saving pre-load file.
BOOT2 Error: install failed
I tried to flash every developer tno file I've got: 1.1.8008, 1.1.8410, 1.1.9227.
Exactly the same error each time.
I even removed everything from the file system using the maintenance menu: no difference...
3) flash the newer 1.1.8007 boot2 (USB support) in RS232
ok
So there doesn't seem to be a problem with my serial interfacing.
I don't understand why I couldn't flash an OS...
4) flash the newer 1.1.9227 OS (Ndlessable) through USB
ok
No problem at all, which does confirm there's a problem with USB in 1.1.7314 boot2.
5) ndless the 1.1.9227 OS
ok
5) dump 1.1.7314 boot1 and 1.1.7387 diagnostics
ok
I still need to dump the 1.1.7314 boot2 and the 1.1.7320 OS from my other TI-XXXXXXXXXXX prototype.
I've tried to reflash an OS in RS232 with the installed 1.1.8007 boot2.
I've also tried after flashing all other developer boot2 files I have: the 1.1.8310 and 1.1.9170.
Same error...
What am I doing wrong?
Flashing an OS in RS232 seemed to "virtually" work in the early Goplat's emulator releases, as OSes were installed this way...
If I could flash the 1.1.9227 ndlessable OS on the other prototype in RS232, then i could dump the 1.1.7314 boot2.
Thanks for any advice.
-
Thanks for saving me the trouble on those video files.
I learned something about Video Text Recognition
which seems to be more of an art than a science .
-
Thanks for saving me the trouble on those video files.
I learned something about Video Text Recognition
which seems to be more of an art than a science .
Thanks for all your hard work, bsl.
But we're not done yet...
I could take a video of the boot2 and the OS! :P
Note that even if I manage to dump the boot2 by flashing an Ndlessable OS using the 1.1.7314 boot2, I can't see any way of dumping the OS...
By the way, any idea about that RS232 OS flashing problem ?
-
It will be a custom video software setup, since I only
need to recognize 16 characters, and the video frames are
consistent from frame to frame.
The flashing problem - I am not sure.
See if you can get the shell --
Reboot the system - as its rebooting type "+++" . [This did not work with the CAS+]
If Datalight stays with the Hayes modem standard this could get you the shell ?
-
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)
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];
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.
-
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)
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)
-
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 ?
Hex-edit the .tno file you're trying to send. In the header, change "TI-Nspire.tno" to "TI-Nspire.tnc". (This header has no signature protection :D)
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)
Maybe they got the size check wrong so a full 640kB isn't allowed. (Note that the last 64kB of the space reserved for diags is actually used for storing test results, so the actual image will never be larger than 576kB.) Try truncating it to just the size of the actual image (for a development-signed diags, the last few bytes are 24 57 c3 c6 90 ff f0).
-
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) {
-
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 ?
Hex-edit the .tno file you're trying to send. In the header, change "TI-Nspire.tno" to "TI-Nspire.tnc". (This header has no signature protection :D)
Very interesting! :)
So again, I tried to flash the ndlessable 1.1.9227 OS in RS232 with boot2 1.1.7314.
My goal is to dump this boot2.
This time I don't get this error... but it still doesn't work.
Strangely, after the OS is verified, the calculator just turns off (doesn't install the OS) and I'm not getting any error...
I tried 2 times, the 2nd time with brand new batteries but I got the same problem.
Have a look at the log:
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: 17816
Clocks: CPU = 90MHz AHB = 45MHz APB = 22MHz
Available system memory: 37292
PM is turning the device OFF
PM has turned the device ON
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 (339 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.tnc"
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (11)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (13)
TI_OS_INSTALL_INSTALLING_RESOURCES (15)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (17)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (19)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (21)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (23)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (25)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (27)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (29)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (31)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (33)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (35)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (37)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (39)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (41)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (43)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (45)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (47)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (49)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (51)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (53)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (55)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (57)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (59)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (61)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (63)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (65)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (67)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (69)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (71)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (73)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (75)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (77)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (79)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (81)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (83)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (85)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (87)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (89)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (91)
TI_OS_INSTALL_VERIFYING_IMAGE incremental update (93)
TI_OS_INSTALL_VERIFYING_RESOURCE (95)
TI_OS_INSTALL_VERIFICATION_COMPLETE (99)
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
PM has turned the device ON
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 (340 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.
What's your guess?
Should I test the modified OS file on another calculator with a different boot2?
(the unmodified OS file was installed successfully through RS232 on a calculator running the 1.1.9170 boot2)
Thanks for helping me. Your posts are very instructive! :)
-
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.
-
Using boot2 1.1.9170, I've tried to run a test image over the 1.1.7320 OS.
I've tried OSes 1.1.8008, 1.1.8410, and 1.1.9227.
(I've sent the original tno files, without adding any header)
It didn't work.
I'm getting the same error each time:
Keypad request, preparing to load a test image.
Checking battery level.
Battery level is OK.
Begin XMODEM file transfer.
§§File transfer complete. Saving file.
File saved. Loading temp image...
21% Error loading temp image.
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%...
Something I've missed again?
-
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.
-
It might become necessary to rewrite the Ndless loader
assuming you get the test image working.
There is a reboot in the Ndless installation which might mean
loosing the test image.
The loader would be rewritten to hexdump the nand to RS232
and would not install Ndless - just using the exploit to dump the nand.
-
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.
-
It will be interesting to look at OS 1.1.7320 .
Without USB support, it would be unusual to see
that it would not support more shell/RS232 utilities,
then what we have been seeing.
If we are really lucky debugging information on those old OS's
-
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.
(http://i63.servimg.com/u/f63/13/23/13/53/img_6112.jpg)
Seems exploit1 is not working correctly on this oldest boot2... (or in RS232).
Any idea?
-
In OS 1.1.7320, the NavNet code is present, but appears to be unused. (TI_NN_Init is at address 10291578, and is not called from anywhere)
The growth in size from 1.1.7320 to 1.1.8008 was due to added flash apps in the TI-84+ emulator.
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.
-
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?
-
I don't know. I haven't yet tested exploiting the bug over rs232 in nspire_emu.
-
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.
(http://i63.servimg.com/u/f63/13/23/13/53/img_6113.jpg)
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...)
-
I think we should forget about creating files on the calc, and instead just send the contents of boot2 out over the RS232, since you already have that set up. I'll email you a file when I finish writing and testing it.
Is it ok for it to just output raw binary or will your terminal program not be able to log that properly?
-
I should be able to handle raw binary I think.
Thanks.
-
After you dump boot2 , see if you can reflash boot2_1.1.7314 and OS1.1.7320 back on
as an integrity check.
-
Goplat, thank you for your file.
Unfortunately, I've tried it something like 10 times and I allways get this:
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: 26008
Clocks: CPU = 90MHz AHB = 45MHz APB = 22MHz
Available system memory: 37292
PM is turning the device OFF
PM has turned the device ON
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 (340 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.
Error saving pre-load file.
BOOT2 Error: install failed
Note I was randomly getting this with exploit1 (even when targetting the right address), but with this exploit2 it seems to happen each time...
-
Did you remember the 32-byte header?
You could also try sending it as a temp image (headerless)...
-
Did you remember the 32-byte header?
You could also try sending it as a temp image (headerless)...
Sorry, I completly forgot that! :P
Going to try again.
-
Actually, sending it as a temp image doesn't work, sorry (just tested in nspire_emu)
-
Can this procedure also work for other unknown boot2's like the CAS+ ?
First you have to hunt for valid points then write the exploit.
-
Can this procedure also work for other unknown boot2's like the CAS+ ?
First you have to hunt for valid points then write the exploit.
Maybe, but it won't work through USB with TI-Nspire Computer Link 1.0 "as is".
The PC-side TNC format checking will fail.
It might work through RS232, as there is no file checking prior to sending.
Goplat, could I have an "exploit2" version which would wait some seconds prior to sending?
I'm under Windows, and I unless you've got a better idea, I have to use 2 terminal softwares (disconnect/reconnect):
- HyperTerminal Private Edition which supports Xmodem transfers
- DockLight which supports ascii & hex file logs
Edit: thanks!
I was just missing the first 512 bytes (wasn't quick enough to switch terminals).
Apparently, there aren't many good terminal softwares for Windows.
Linux would have been much easier I suppose with the "cat" command :P
Edit2: dumped.
All my basic & CAS Nspire prototypes are now fully dumped.
Now, back to the CAS+! :P
-
There are a lot more capable terminal programs written for MsDOS back then, because of the
direct hardware access that Window$ doesn't give you. Here is a link to some of them:
http://www.eunet.bg/simtel.net/msdos/commprog.html
-
The 1.1.73xx boot1/boot2/OS/diags are the only developer versions which have visible differences with the newer 1.1 developer and production versions.
They seem to be an intermediate between TI-Nspire CAS+ and basic/CAS TI-Nspire.
You can find lots of screen captures and photos of the matching prototype below:
http://tibank.forumactif.com/t6809-les-secrets-des-ti-xxxxxxxxxxx
http://ti.bank.free.fr/index.php?mod=galerie&action=img&id_gal=9&id_img=130
(with comments in french)
A very big thanks to everybody.
Omnimaga is great!
-
I'm glad you like the site. Also thanks a lot for your work in finding these prototypes, trying to hack them and all the other discoveries you made. I unfortunately cannot help much, though, since I know nothing about hardware stuff.