Forum TI-Planet.org

How to patch boot2 1.0.526 to work on CAS+ EVT with 1.0.1.0.xxxT boot1 (CONVERTS THEM INTO PRODUCTION CAS+!)
If only it had happened years ago...oh well

1) use nsbar to decompress 1.0.526 boot2 to another file
- the old boot2 is not compatible with DVT/PVT compression algorithm

2) run "imgmanip listfields" on the decompressed file. In the output, look for the first field AFTER 8070. take its offset, convert it to decimal, and subtract 1 from it. write down this number.

3) open nsbar decompressed boot2 in a hex editor

4) at the very beginning of the file change the 4 bytes after 80 0F to all 00
- the old boot2 needs the size of field 8000 to be 0, even though that's "wrong"

5) find 80 13 35 30 43 and change it to 80 12 31 30. yes, delete a byte.
- changing the calculator model ID from "50C" to "10" and adjusting the field size

6) go to the offset you wrote down in step 2. select the rest of the file, starting at this offset, and delete it.
- removing the unsupported signing certificate fields

7) at the new end of the file, add 02 F0 FF F0
- these 2 empty fields need to be there for some reason

8) save, and it will work! flash with rs232. it was tested with boot1 1.0.1.0.334T and 1.0.1.0.347T and works on both

That's a very interesting tutorial, thank you !
Upgrading your EVT2 CAS+ into PVT ones is a huge achievement !

I think there remain some problems with your how-to.
You're telling us to note an offset which nsbar calculates in the compressed image, and then to work on the decompressed image...

By following slightly different instructions and only working on the compressed Boot2 1.0.526 image, I've managed to get the following file :


And that's great, in the emulator it works with EVT Boot1 1.0.1.0.347T :

Code: Select all

Boot Loader Stage 1 (1.0.1.0.347T)
Build: 2006/5/10, 5:48:47
Copyright (c) 2006 Texas Instruments Incorporated

Warning at PC=00009DEC: Bad write_byte: 0003e869 00
System clock:        78 MHZ
SDRAM memory test:
Data   (ticks=0)
Addr   (ticks=0)
Fill   (ticks=3)
Test   (ticks=7)
Pass (ticks=10)
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A

Loading BOOT2 software...

99%
BOOT1: loading complete, launching image.



Boot Loader Stage 2 (1.0.526)
Build: 2006/8/11, 6:29:51
Copyright (c) 2006 Texas Instruments Incorporated
Using production keys



Initializing graphics subsystem.
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A
Initializing USB and networking.


Initializing filesystem.
Datalight Reliance v2.00.0451
Copyright (c) 2003 - 2005 Datalight, Inc.
Registered to #9DE08703
FlashFX sample project for the OMAP5912 OSK running Nucleus
Datalight FlashFX Pro v2.0 Build 966
Nucleus Edition for ARM9
Copyright (c) 1993-2005 Datalight, Inc.
Patents: US#5860082, US#6260156.
Detected FfxDelay() parameters: Count=93387 MicroSec=8192 Shift=13
FFX: NAND chip manufacturer: ST Micro (20) chip NAND256R3A (35)
Filesystem ready.

-- Bad Block list --
-- Bad Block list end --

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.
USB Download is enabled.
Press <Enter> to download through the serial port.
phoenix dhcp server w/ VOODOO  built 12-Jul-2006 (start at 510)


phoenix enum server  built 12-Jul-2006


phoenix dhcp hook fwd w/ VOODOO  built 12-Jul-2006 (start at 510)


phoenix file mgt server  built 12-Jul-2006 (start at 610)

pn-srv2-636: pol_init = -1

It means CAS+ EVT2 Boot1 don't check for the Boot2 signature, that's a great discovery - congrats !

Unfortunately, it doesn't work with the older 1.0.1.0.334T Boot1 - it's crashing in the emulator :

Code: Select all

Warning at PC=000079E0: Bad write_word: fffecb10 ffffffff
Warning at PC=000079E0: Bad write_word: fffecb14 ffffffff



Boot Loader Stage 1
Build: Feb 27 2006, 18:04:35
Copyright (c) 2006 Texas Instruments Incorporated

System clock:        78 MHZ
SDRAM memory test:
Data   (ticks=0)
Addr   (ticks=0)
Fill   (ticks=3)
Test   (ticks=7)
Pass (ticks=10)
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A

Launching BOOT2 software...

100%
BOOT1 complete.
Error at PC=1183A830: T-type memory access not implemented
        Backtrace:
Frame     PrvFrame Self     Return   Start
200098C8: 200098E8 200098CC 000004E8 00001520
200098E8: 20009900 200098EC 00005F24 00000274
20009900: 20009904 20009904 00000000 00005EFC
debug>

Would be great if it could work with the older U-Boot based Boot1 used in EVT1 prototypes (TI-Phoenix 1) :
archives_voir.php?id=11548

Unfortunately, I don't own any EVT CAS+ prototype.
Some are in the hands of http://www.datamath.org and others in the hands of http://www.cncalc.org members.
And I would fear trying on prototypes I don't own (especially when it implies replacing the OS).
I know in theory you would still be able to reflash the original Boot2, but on such early prototypes the flashing code may still have fatal bugs...
And even if it doesn't brick anything, we can't be sure it would then be possible to reflash the original 'collector' OS.

parrotgeek1 wrote:Also a development boot1/boot2 1.0.526 are listed on ti-planet but not uploaded. can you upload them?

I apparently fogot to upload them, thanks.
DVT 1.0.526 Boot1/Boot2 images :
archives_voir.php?id=944764
archives_voir.php?id=944773
You may have fun diffing them with the PVT ones.

parrotgeek1 wrote:do you have a dump of boot1/boot2 1.0.1.0.290T? can I have them to test this?

Sorry, I don't.
I could never put my hands on this prototype.
I've just newsed about it : viewtopic.php?t=17908#p196266
It comes from cncalc.org : https://www.cncalc.org/forum.php?mod=vi ... 919&page=1
As far as I know the owner didn't try the dumping process, which is quite hard compared to the way we dump Nspire things.

I meant to use the output of "imgmanip listfields" on the image *after* you decompress it. That way, it works on 334T. I'll edit the post. I am very bad at writing tutorials.

I already tried to get it to work with the Phoenix version but the problem is that u-boot hard codes the load address as 0x10C00000. But in-between .347T and .491 they changed it to 0x11800000 like in the production Nspire.

No, you're not bad - it's normal for a tutorial to not be immediately perfect.
I'm going to check if it works better with your edits.

critor wrote:No, you're not bad - it's normal for a tutorial to not be immediately perfect.
I'm going to check if it works better with your edits.

I already edited it.

(sorry for double post)

cbble204 appears to still be active on cncalc this year. You could try to send them a private message with dumping instructions. After the dump this tutorial would be very useful to them because they were not expecting to buy an EVT and could then use it as a normal calculator

Ok. I need to remember how we managed to dump EVT CAS+ calculators - I'm going to check my old posts about this.
I think it was quite different than on DVT/PVT CAS+ calculators (just a telnet through USB).

critor wrote:Ok. I need to remember how we managed to dump EVT CAS+ calculators - I'm going to check my old posts about this.
I think it was quite different than on DVT/PVT CAS+ calculators (just a telnet through USB).

Speaking of dumping, I was trying to figure out how you could dump the boot1/boot2 of the viewscreen. I'm not sure if it's possible without a nand reader. Because you can't send a test boot2 image that doesn't overwrite the boot2 that already exists...

I've made a specific OS dumping post on cncalc.org based on the informations I could gather :
http://www.cncalc.org/forum.php?mod=red ... uid=103656

It's the 'easy' CAS+ DHCP/USB/telnet dumping process, assuming his prototype is behaving like the EVT2/DVT we already dumped.

The other way for prototypes which don't start a DHCP server, like the TI-Phoenix 1 P1-EVT1, is to exploit their datalight shell through a serial interface.

parrotgeek1 wrote:Speaking of dumping, I was trying to figure out how you could dump the boot1/boot2 of the viewscreen. I'm not sure if it's possible without a nand reader. Because you can't send a test boot2 image that doesn't overwrite the boot2 that already exists...

I still have the TI-Nspire ViewScreen panel which is clearly based on the CAS+ hardware, and we still couldn't dump anything from it, neither the OS nor the Boot1/Boot2.
It's mainly because its using the USB to communicate with the calculator.
So its USB communication is totally different, and the easy dumping process above doesn't apply.
No Datalight shell in the bootlog either, so we can't use the harder TI-Phoenix1 dumping process either.
If you have an idea and need me to test things, just post about it.

I think that your dumping instructions might not work. The fget command outputs the contents of the file into the telnet, it doesn't copy it to the computer. Therefore you need a way to redirect the telnet output into a file

The viewscreen doesn't even have an OS. The boot2 is the "OS". In boot1 1.0.491, when the calculator detects it is a viewscreen, boot1 fills the progress bar to 100% instead of 50% when it loads the boot2. This would give the appearance of an OS when there's actually just a boot2.