Omnimaga
Calculator Community => Other Calculators => Topic started by: critor on March 31, 2011, 05:37:46 am
-
Hi!
Just got another unknown TI-Nspire CAS prototype.
It's got the "TI-XXXXXXXXXXX" label, which had never been reported on the Internet up to now.
Could you help me saving the included OS/Boot1/Boot2?
It's running the oldest 1.1 Nspire OS we've ever heard off: 1.1.6925 CAS built on 2007-02-07.
Boot1 & Boot2 versions are 1.1.6818.
There is no included diagnostic software.
And of course, like the 1.1.7320 basic OS, no "full" USB support.
So I cannot use TI-Nspire Computer Link to access the filesystem, and I cannot exchange data with another TI-Nspire, and the "Send OS" menu is disabled anyway.
With the 1.1.73xx prototype, the main difference was that I had severall of them.
So I could:
- remove the OS on one of them to use the boot2 exploit at the "install OS" screen and dump boot1/boot2/diags
- flash a more recent boot2 on another one, as the older 1.1.73xx boot2 didn't want to run the more recent developer OSes I had as a test image
This time, I've only got 1 prototype of that kind, and that's the main poblem.
So if I remove the OS or update the boot2, it will be lost and probably forever.
I'm going to try:
- to get the full boot log through my RS232 adapter
- to run the more recent 1.1.8408/1.2.2344 developer CAS OSes as a test image through my RS232 adapter, but according to my previous experience with the 1.1.73xx pototype, I'm very doubtfull it will work...
Here's the 1st photo in the world for you:
(http://i63.servimg.com/u/f63/13/23/13/53/casxxx10.jpg)
Goplat, Bsl, everybody... if you have any idea which could help me fully dump the OS/Boot1/Boot2, please share it.
-
Hi!
Just got another unknown TI-Nspire CAS prototype.
It's got the "TI-XXXXXXXXXXX" label, which had never been reported on the Internet up to now.
Could you help me saving the included OS/Boot1/Boot2?
It's running the oldest 1.1 Nspire OS we've ever heard off: 1.1.6925 CAS built on 2007-02-07.
Boot1 & Boot2 versions are 1.1.6818.
There is no included diagnostic software.
And of course, like the 1.1.7320 basic OS, no "full" USB support.
So I cannot use TI-Nspire Computer Link to access the filesystem, and I cannot exchange data with another TI-Nspire, and the "Send OS" menu is disabled anyway.
With the 1.1.73xx prototype, the main difference was that I had severall of them.
So I could:
- remove the OS on one of them to use the boot2 exploit at the "install OS" screen and dump boot1/boot2/diags
- flash a more recent boot2 on another one, as the older 1.1.73xx boot2 didn't want to run the more recent developer OSes I had as a test image
This time, I've only got 1 prototype of that kind, and that's the main poblem.
So if I remove the OS or update the boot2, it will be lost and probably forever.
I'm going to try:
- to get the full boot log through my RS232 adapter
- to run the more recent 1.1.8408/1.2.2344 developer CAS OSes as a test image through my RS232 adapter, but according to my previous experience with the 1.1.73xx pototype, I'm very doubtfull it will work...
Here's the 1st photo in the world for you:
(http://i63.servimg.com/u/f63/13/23/13/53/casxxx10.jpg)
Actually, I have seen a TI-XXXXXXXXXXX online before.
Right here. (http://www.datamath.org/Graphing/NSpire_P.htm)
-
Actually, I have seen a TI-XXXXXXXXXXX online before.
Right here. (http://www.datamath.org/Graphing/NSpire_P.htm)
Of course I know. The 1.1.73xx we've dumped in my other topic was a TI-XXXXXXXXXXX.
But it was a basic Nspire prototype.
This one is a CAS Nspire prototype, which was clearly stated in my 1st sentence.
Sorry if my 2nd sentence seemed ambiguous to you.
So I'm correcting: "it's a CAS TI-XXXXXXXXXXX, which had never been reported on the Internet up to now".
That's interesting because previous prototypes were labelled "TI-Nspire CAS+".
So we thought the "TI-XXXXXXXXXXX" as reported on datamath.org was because they had not yet chosen a name for the basic version of the Nspire.
But finally, seems not as there have been CAS TI-XXXXXXXXXXX.
Why did they remove the "Nspire" name and then add it again?...
Anyway, here's the boot log:
Boot Loader Stage 1 (1.1.6818)
Build: 2007/2/4, 23:19:48
Copyright (c) 2006, 2007 Texas Instruments Incorporated
Using developer keys
Last boot progress: 17368
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 (560 ticks), launching image.
Boot Loader Stage 2 (1.1.6818)
Build: 2007/2/4, 23:24:42
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 USB and networking.
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%
žaòž aOž
x O†ò†y ˜þ
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.
System build date: Feb 7 2007, 23:36:02
Available memory: 23186488 bytes
Purging temporary files...
Launching system...
I've just had an idea...
Goplat, do you think the boot2 1.1 exploit1 can work by trying to load it as a test image through RS232?...
Any idea of the address I should target in that case?
-
BOOT1: loading complete (560 ticks), launching image.
I wonder why it takes so long? (Recall that the 1.1.73xx prototype took only 339 ticks to load BOOT2.) Maybe TI accidentally put in a production version of DIAGS, so it takes time to read but ends up getting skipped. ;) Either that or they optimized some code between this version and 1.1.7314.
Initializing USB and networking.
Interesting, this message isn't in later versions of boot2 (they initialize USB later on, and only if the OS fails to load).
Goplat, do you think the boot2 1.1 exploit1 can work by trying to load it as a test image through RS232?...
Any idea of the address I should target in that case?
Let's take that discussion to email.
-
Interesting, I wonder how many kind of prototypes there is in total...
-
Interesting, I wonder how many kind of prototypes there is in total...
I'm wondering why I couldn't find up to now any prototype with a software build date or a hardware manufacturing date between october 2006 and february 2007.
4 months...
-
What's with the random chars in the middle?
-
What's with the random chars in the middle?
It happens when the OS does start.
You can check other 1.1 bootlogs: they are present too, but are completly different.
-
I wonder if they mean anything....
-
I wonder if they mean anything....
My guess is it's just a side effect of the bus speed getting changed (Boot2 uses 45MHz AHB and 22.5MHz APB, but reduces it to 15MHz AHB and 7.5MHz APB just before starting the OS). It never happens in nspire_emu, only on real hardware.
-
Does the examples document mention "CAS+" also ?
Also when you get to the point of dumping- dump the diags too, even though
it appears not there.
-
The example not only mentions CAS+, but seems to refer to the CAS+ menu.
I've got a dump file of the OS for now.
I've launched the 1.1.8408 OS as a test image, and used it to get the installed /phoenix/install/ti-nspire.tnc file through USB.
But I'm not sure it's good.
The header seems strange, as it is including null version strings:
TI-Nspire.tnc 0.0.0 2619082 0
__RES__ 0.0.0 0 759637
PK
½G6¾µ\·ìò'ìò'
wTI-Nspire.imgSDb¤Zsåcd`ia``PbpbF&‹�UH(ÙŒ¬ .«(�p—{ªÌZ˜PlÙôvH C
XZ‚á?£<†^ˆ8#X«^µ +„PÌPÚUT
É·ÊEÉ·ÊEÉ·ÊE€'òa€JTI-Nspire €0C€0E€â€.0.0.0€.0.0.0
Moreover, it doesn't work with Goplat's emulator:
Loading Operating System...
100%
BOOT2: loading complete (428 ticks), launching image.
Error at PC=101675BC: Bad or unimplemented control register value: 5127f
Backtrace:
Frame PrvFrame Self Return Start
11A04148: 11A04158 11A0414C 118026E8 11801DAC
11A04158: 11A04320 11A0415C 11801180 118026D8
11A04320: 11A04350 11A04324 1184F728 11800D7C
11A04350: 11A04370 11A04354 1181E288 1184F6E0
11A04370: 11A04374 11A04374 00000000 1181E270
debug>
Any idea?
-
BOOT2: loading complete (428 ticks), launching image.
Error at PC=101675BC: Bad or unimplemented control register value: 5127f
If the OS validates fully and then doesn't work, it's probably my fault.
Does it work any differently in nspire_emu 0.51 (http://www.omnimaga.org/index.php?action=dlattach;topic=6763.0;attach=6485), which implemented support for the 0x100 and 0x200 bits in the control register?
-
BOOT2: loading complete (428 ticks), launching image.
Error at PC=101675BC: Bad or unimplemented control register value: 5127f
If the OS validates fully and then doesn't work, it's probably my fault.
Does it work any differently in nspire_emu 0.51 (http://www.omnimaga.org/index.php?action=dlattach;topic=6763.0;attach=6485), which implemented support for the 0x100 and 0x200 bits in the control register?
Seems it's time for mu to update your emulator ;)
I'm checking...
Edit: it's booting perfectly with the 0.51.
It was my fault for using an older version. Your emulator is great :)
-
In fact, I've posted too fast (no your emulator is great, this hasn't changed - I'm not forgetting it did emulate perfectly all other 1.1.7320 and above prototype OSes without changing anything!).
I get the home screen (which I didn't get with my previous emulator version), but I've got problems later.
For exemple, I get a warning when typing enter to exit the about window:
usb reset
Warning at PC=100BC918: Bad read_word: fffbc410
debug>(tried 2 times)
What do you think about it Goplat?
Emulation which is not yet exactly 100% accurate?
Or a difference on the hardware?
Unfortunately, I cannot test the file on true hardware.
The "0.0.0" in the header is blocked by the downgrade protection.
-
Warning at PC=100BC918: Bad read_word: fffbc410
I noticed this too. If you just continue ("c") in order to ignore the bad memory accesses, it works. I suspect it's more code left over from the CAS+, trying to access now-nonexistent peripherals.
Some day I need to make nspire_emu customizable in how it handles error conditions like this (ignore vs. print message vs. break into debugger)
-
I suspect it's more code left over from the CAS+, trying to access now-nonexistent peripherals.
Do you think such code could be usefull in our attempts to dump/flash the CAS+?
Anyway, look what I got:
(http://i63.servimg.com/u/f63/13/23/13/53/010.gif)
(same screen on true hardware)
Seems it's a quite early OS...
-
Do you think such code code be usefull in our attempts to dump/flash the CAS+?
Knowing how to access the rs232 port could be quite useful, but since the code that deals with that is all in one place they wouldn't have accidentally left any of that unchanged.
I looked at this particular bit of obsolete code - the FFFBC410 register, if it existed, would have just been a 32768Hz timer. (The code that replaced it in later versions of the OS calls TMT_Retrieve_Clock instead).
-
Boot1 & Boot2 1.1.6818 (built on 4th february 2007) are now dumped.
We're getting closer and closer to the CAS+.
Goplat, you were right.
Boot2 1.1.6818 is bigger, much bigger!
1.29Mb for the image, and then 1.85Mb when decompressed!!!
On the emulator, the boot1 does not work at all.
It's not a warning, but an error this time. I cannot continue...
Error at PC=0000A624: NAND flash: read nonexistent page 7fffff
Backtrace:
Frame PrvFrame Self Return Start
A400A568: A400A588 A400A56C 0000A75C 0000A5E0
A400A588: A400A7D8 A400A58C 0000AF38 0000A71C
A400A7D8: A400AA18 A400A7DC 0000D348 0000AEEC
A400AA18: A400AA90 A400AA1C 00000DD4 0000D304
A400AA90: A400AAA8 A400AA94 00004578 000009C8
A400AAA8: A400AAAC A400AAAC 00000000 00004550
debug>
With the boot2, I get this while trying to install a factory OS image:
IMAGE: verifying file "/tmp/TI-Nspire.tnc"
Error at PC=1184DB24: NAND flash: read nonexistent page 7fffff
Backtrace:
Frame PrvFrame Self Return Start
11A2F3A0: 11A2F3C0 11A2F3A4 1184DC5C 1184DAE0
11A2F3C0: 11A2F610 11A2F3C4 1184E438 1184DC1C
11A2F610: 11A2F850 11A2F614 1197AE80 1184E3EC
11A2F850: 11A2F8F0 11A2F854 1197F9D8 1197AE3C
11A2F8F0: 11A31BB8 11A2F8F4 1197F520 1197F9C4
11A31BB8: 11A324A0 11A31BBC 118011C4 1197E9D8
11A324A0: 11A324E8 11A324A4 1188BD30 118008A0
11A324E8: 11A32500 11A324EC 1182FCF4 1188BC94
11A32500: 11A32504 11A32504 00000000 1182FCCC
debug>
If no factory OS image is present, I get this:
Waiting for OS download.
Starting Connectivity services.
Initializing USB subsystem...Warning at PC=11877D28: Bad write_byte: e59ff018 00
debug> c
Warning at PC=11877D28: Bad write_byte: e59ff019 80
debug> c
Warning at PC=11877D28: Bad write_half: e59ff028 0040
debug> c
Warning at PC=11877D28: Bad write_byte: e59ff01a 00
debug> c
Warning at PC=11877D28: Bad write_word: e59ff02c 00000000
debug> c
Warning at PC=11877D28: Bad write_byte: e59ff030 00
debug> c
Warning at PC=1187A39C: Bad read_byte: e59ff018
debug> c
Warning at PC=1187A39C: Bad read_byte: e59ff019
debug> c
Warning at PC=1187A39C: Bad read_word: e59ff030
debug> c
Warning at PC=1187A39C: Bad read_byte: e59ff019
debug> c
Warning at PC=1187A400: Bad read_byte: e59ff018
debug> c
Warning at PC=1187A400: Bad read_word: e59ff088
debug> c
Warning at PC=1187A430: Bad read_word: e59ff090
debug> c
Warning at PC=1187A448: Bad read_byte: e59ff01a
debug> c
Warning at PC=1187A4C0: Bad read_byte: e59ff01a
debug> c
Warning at PC=1187A504: Bad read_half: e59ff028
debug> c
Warning at PC=1187A504: Bad read_byte: e59ff018
debug> c
Warning at PC=1187A504: Bad read_byte: e59ff018
debug> c
Warning at PC=1187A504: Bad read_byte: e59ff01a
debug> c
Warning at PC=1187A504: Bad read_byte: e59ff019
debug> c
Warning at PC=1187A588: Bad read_byte: e59ff019
debug> c
Warning at PC=1187A5B4: Bad read_word: e59ff098
debug>
Hope you'll find those errors very interesting ;)
Thank you all for your support.
-
This is looking more CAS+ like:
1199a7f4: /tmp/manifest_img
1199a80c: /tmp/TI-Nspire.tnc
-
This is looking more CAS+ like:
1199a7f4: /tmp/manifest_img
1199a80c: /tmp/TI-Nspire.tnc
Where is that?
Boot2? OS?
Does it seems to be used somewhere?
-
boot2, hint:boot2launcher code
Start the emulator with a /d
then :
debug> d 1199a7f4
if you are booting with boot1:
k 11800000 +x
then continue, following a dump at that address
-
Those filenames are still there even in boot2 1.4. When sending an OS by RS232, you send both a manifest_img (with size given in header bytes 18-1B) and a TI-Nspire.tnc (with size given in header bytes 1C-1F). But since making manifest_img 0 bytes long works fine, it's probably vestigial.
-
Then, why is this boot2 so big?
Unoptimized code?
Unused/useless code?
Unused CAS+ code remnants?
By the way, I made a little error.
The boot2 1.1.6818 image size is "only" 1.27Mo, but that's still 206Kb more than the 1.1.7313 boot2.
The uncompressed size is still 1.85Mb, 408 Kb more than the 1.1.7313 boot2.
And by the way, all later boot2 versions are smaller.
What's inside this one?...
-
Then, why is this boot2 so big?
Unoptimized code?
You got it. Most of the C code in boot1 and boot2, and some in the OS, seems to have been compiled without optimizations in these versions.
Here's a little example, the CSC_Place_On_List function. In boot1 1.1.6914:
00002edc: e1a0c00d mov r12,sp
00002ee0: e92dd800 stmdb sp!,{r11-r12,lr-pc}
00002ee4: e24cb004 sub r11,r12,00000004
00002ee8: e24dd008 sub sp,sp,00000008
00002eec: e50b0010 str r0,[r11 - 010]
00002ef0: e50b1014 str r1,[r11 - 014]
00002ef4: e51b3010 ldr r3,[r11 - 010]
00002ef8: e5933000 ldr r3,[r3]
00002efc: e3530000 cmp r3,00000000
00002f00: 0a000011 beq 00002f4c
00002f04: e51b2014 ldr r2,[r11 - 014]
00002f08: e51b3010 ldr r3,[r11 - 010]
00002f0c: e5933000 ldr r3,[r3]
00002f10: e5933000 ldr r3,[r3]
00002f14: e5823000 str r3,[r2]
00002f18: e51b3014 ldr r3,[r11 - 014]
00002f1c: e5932000 ldr r2,[r3]
00002f20: e51b3014 ldr r3,[r11 - 014]
00002f24: e5823004 str r3,[r2 + 004]
00002f28: e51b2014 ldr r2,[r11 - 014]
00002f2c: e51b3010 ldr r3,[r11 - 010]
00002f30: e5933000 ldr r3,[r3]
00002f34: e5823004 str r3,[r2 + 004]
00002f38: e51b3014 ldr r3,[r11 - 014]
00002f3c: e5932004 ldr r2,[r3 + 004]
00002f40: e51b3014 ldr r3,[r11 - 014]
00002f44: e5823000 str r3,[r2]
00002f48: ea000008 b 00002f70
00002f4c: e51b2010 ldr r2,[r11 - 010]
00002f50: e51b3014 ldr r3,[r11 - 014]
00002f54: e5823000 str r3,[r2]
00002f58: e51b2014 ldr r2,[r11 - 014]
00002f5c: e51b3014 ldr r3,[r11 - 014]
00002f60: e5823000 str r3,[r2]
00002f64: e51b2014 ldr r2,[r11 - 014]
00002f68: e51b3014 ldr r3,[r11 - 014]
00002f6c: e5823004 str r3,[r2 + 004]
00002f70: e24bd00c sub sp,r11,0000000c
00002f74: e89da800 ldmia sp,{r11,sp,pc}
The same function in boot1 1.1.8916:
000029c4: e5903000 ldr r3,[r0]
000029c8: e3530000 cmp r3,00000000
000029cc: 15933000 ldrne r3,[r3]
000029d0: 05801000 streq r1,[r0]
000029d4: 15831004 strne r1,[r3 + 004]
000029d8: 15813000 strne r3,[r1]
000029dc: 15902000 ldrne r2,[r0]
000029e0: 05811004 streq r1,[r1 + 004]
000029e4: 15821000 strne r1,[r2]
000029e8: 15812004 strne r2,[r1 + 004]
000029ec: 05811000 streq r1,[r1]
000029f0: e12fff1e bx lr
-
Oh thank you for checking so fast :)
By the way, what do you think about that "page 7fffff" error?
-
Oh thank you for checking so fast :)
By the way, what do you think about that "page 7fffff" error?
It's a bug in TI's code for reading the "bootdata" (http://hackspire.unsads.com/wiki/index.php/Memory_layout#NAND_Flash). If it can't find it, it tries to read from offset FFFFFFFF, because they didn't do the error checking quite right. This was fixed in later versions.
Presumably the effect on real hardware would be that either the read fails, or it reads the last actual page of flash. Either way, the code won't get a valid bootdata structure, so the end result is it just uses the default.
-
Oh thank you for checking so fast :)
By the way, what do you think about that "page 7fffff" error?
It's a bug in TI's code for reading the "bootdata" (http://hackspire.unsads.com/wiki/index.php/Memory_layout#NAND_Flash). If it can't find it, it tries to read from offset FFFFFFFF, because they didn't do the error checking quite right. This was fixed in later versions.
Presumably the effect on real hardware would be that either the read fails, or it reads the last actual page of flash. Either way, the code won't get a valid bootdata structure, so the end result is it just uses the default.
Does this mean the "downgrade protection" (included in bootdata) won't work on this model if I don't update the boot2 ?
-
Does this mean the "downgrade protection" (included in bootdata) won't work on this model if I don't update the boot2 ?
No, the downgrade protection will still work. The bug only affects the case where bootdata has never been written.