Patch boot2 1.0.526 to work on CAS+ EVT!

[critor]

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

Thanks.
I think a simple fix can be :

Code: Tout sélectionner

telnet 172.16.xxx.xxy 10001 > phoenix.dump

Let's see if he replies for the moment.
And you may reply to the post too.

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.

Ah, thanks for noticing and sharing this.
I just supposed the Boot2 and OS weren't outputting anything to the serial port for some reason.

Here's my TI-Nspire Viewscreen bootlog :

Boot Loader Stage 1 (1.0.439)
Build: 2006/6/30, 5:44:11
Copyright (c) 2006 Texas Instruments Incorporated

Last boot progress: 34812

ViewScreen Adapter
System clock: 78 MHZ
SDRAM memory test: Pass
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Checking for NAND: NAND Flash ID: ST Micro NAND256W3A

Loading DIAGS software...

Error reading/validating DIAGS image

Loading BOOT2 software...

100%

BOOT1: loading complete (328 ticks), launching image.

Let's forget about the special (U-Boot) TI-Phoenix 1 P1-EVT1.
For both available CAS+ dumping methods, we begin by dumping the OS (through USB-telnet or RS232-datalight), and then we taylor some exploits (based on datalight or Ndless+) to dump the Boot1/Boot2/Diags.

So indeed a software dumping method, if possible, would be completely different for the TI-Nspire Viewscreen...

[critor]

Thanks for you modified how-to.
I've now got a patched uncompressed production Boot2 5.0.526 which is launched correctly by development Boot1 1.0.1.0.334T/1.0.1.0.347T.

Note that I did substract 1 and not 3 on your 2nd step.

Here's the patched image, since I doubt TI is going to bother about an unreleased model more than 10 years later :

tinspirecasp_boot2_1.0.526.raw.patched.tns

(1.34 Mio) Téléchargé 148 fois

So flashing this through RS232 on your EVT/DVT CAS+ running a development Boot1 1.0.1.0.3xxT is going to make it accept production OSes, and thus make it upgradeable to the latest 1.0.554 OS.

Don't use it with more recent 1.0.4xx/1.0.5xx development/production Boot1.

[critor]

Unfortunately, it seems we won't be able to upgrade the oldest prototypes booting on U-Boot like the TI-Phoenix 1 P1-EVT1 this way.

U-Boot doesn't expect a TI-Certificate code just raw code, which could have been very easy.

Warning at PC=110A3700: Bad read_byte: 0480000b
Warning at PC=110A3700: Bad write_byte: 0480000b 00


U-Boot 1.1.2 (Jan 23 2006 - 11:21:34)

U-Boot code: 11080000 -> 110E3094 BSS: -> 110EF750
RAM Configuration:
Bank #0: 10000000 32 MB
Warning at PC=110A49D8: Bad write_half: 0000aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 00005554 0055
Warning at PC=110A49D8: Bad write_half: 0000aaaa 0090
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 0c005554 0055
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 0090
Warning at PC=110A49D8: Bad read_half: 0c000000
Flash: 0 kB
NAND:32 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0

NAND read: device 0 offset 16384, size 1425408 ... 1425408 bytes read: OK
## Starting application at 0x10C00000 ...
Error at PC=119ED000: Out of jump table space
Backtrace:
Frame PrvFrame Self Return Start
11057C28: 11057EC0 11057C2C 1108A500 1108AC64
11057EC0: 11057EE8 11057EC4 11089794 1108A280
11057EE8: 11057F70 11057EEC 1108164C 11089700
11057F70: 00000000 11057F74 00000268 110813DC
debug>

But the Boot2 raw code is loaded and run in RAM at 0x10C00000, which is different from the 0x11800000 from more recent TI-Certificate based Boot2 images.

[critor]

@parrotgeek1
Do you think the reverse is possible, making a 1.0.1.0.3xx development TI-Certificate image, launchable by more recent 1.0.4xx/1.0.5xx development Boot1 images ?

Because the only Diags image we've ever been able to dump is the 1.0.1.0.347T, and it can only be launched on old/rare prototypes with a 1.0.1.0.3xxT Boot1 image - so it's quite useless in its current form :
archives_voir.php?id=8983

Thanks.

[parrotgeek1]

@parrotgeek1
Do you think the reverse is possible, making a 1.0.1.0.3xx development TI-Certificate image, launchable by more recent 1.0.4xx/1.0.5xx development Boot1 images ?

Because the only Diags image we've ever been able to dump is the 1.0.1.0.347T, and it can only be launched on old/rare prototypes with a 1.0.1.0.3xxT Boot1 image - so it's quite useless in its current form :
archives_voir.php?id=8983

Thanks.

no, it's not possible, there is no signature at all.

EDIT: please also send cbble204 a private message. It will have an email notification and thus a response will be more likely.

[parrotgeek1]

Unfortunately, it seems we won't be able to upgrade the oldest prototypes booting on U-Boot like the TI-Phoenix 1 P1-EVT1 this way.

U-Boot doesn't expect a TI-Certificate code just raw code, which could have been very easy.
But the Boot2 raw code is loaded and run in RAM at 0x10C00000, which is different from the 0x11800000 from more recent TI-Certificate based Boot2 images.

try this in u-boot

setenv bootcmd nand read 11800000 4000 <size-of-uncompressed-boot2-in-hex>; go 11800000

saveenv

reset

note: this will NOT work in an emulator, it doesn't emulate the NOR flash

-------


I added 526 dev boot2 build date to wiki

[critor]

try this in u-boot

setenv bootcmd nand read 11800000 4000 <size-of-uncompressed-boot2-in-hex>; go 11800000

saveenv

reset

note: this will NOT work in an emulator, it doesn't emulate the NOR flash

Indeed, saveenv doesn't work, and we can't even be sure it'll work on hardware.

Code: Tout sélectionner

Warning at PC=110A3700: Bad read_byte: 0480000b
Warning at PC=110A3700: Bad write_byte: 0480000b 00


U-Boot 1.1.2 (Jan 23 2006 - 11:21:34)

U-Boot code: 11080000 -> 110E3094  BSS: -> 110EF750
RAM Configuration:
Bank #0: 10000000 32 MB
Warning at PC=110A49D8: Bad write_half: 0000aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 00005554 0055
Warning at PC=110A49D8: Bad write_half: 0000aaaa 0090
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 0c005554 0055
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 0090
Warning at PC=110A49D8: Bad read_half: 0c000000
Flash:  0 kB
NAND:32 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
Phoenix Demo# saveenv
Saving Environment to Flash...
Error: start and/or end address not on sector boundary
Phoenix Demo#

But your commands do work separately :

Code: Tout sélectionner

Warning at PC=110A3700: Bad read_byte: 0480000b
Warning at PC=110A3700: Bad write_byte: 0480000b 00


U-Boot 1.1.2 (Jan 23 2006 - 11:21:34)

U-Boot code: 11080000 -> 110E3094  BSS: -> 110EF750
RAM Configuration:
Bank #0: 10000000 32 MB
Warning at PC=110A49D8: Bad write_half: 0000aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 00005554 0055
Warning at PC=110A49D8: Bad write_half: 0000aaaa 0090
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 00aa
Warning at PC=110A49D8: Bad write_half: 0c005554 0055
Warning at PC=110A49D8: Bad write_half: 0c00aaaa 0090
Warning at PC=110A49D8: Bad read_half: 0c000000
Flash:  0 kB
NAND:32 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
Phoenix Demo# nand read 11800000 4000 157620

NAND read: device 0 offset 16384, size 1406496 ...  1406496 bytes read: OK
Phoenix Demo# go 11800000
## Starting application at 0x11800000 ...



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=93047 MicroSec=8192 Shift=13
FFX: NAND chip manufacturer: ST Micro (20) chip NAND256R3A (35)
FFX: BBM low level format type is 0
FlashFX: Formatting... One moment please
100%
FlashFX: Format complete
relFs_Format v2.00.0451
Copyright (c) 2003 - 2005 Datalight, Inc.
Writing file system...100%
Block size: 512
Total blocks: 57008
Used blocks: 63
Free blocks: 56945
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 3949)


phoenix enum server  built 12-Jul-2006


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


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

../connectivity/src/pn-net/pn-policy.c-459: missing directory ``/documents'', bugz 15239
pn-srv2-636: pol_init = -1

I added 526 dev boot2 build date to wiki

Thanks for helping !

[parrotgeek1]

Indeed, saveenv doesn't work, and we can't even be sure it'll work on hardware.

I am 99% sure it will work. If you disassemble the code for it it uses commands to write to the SST 39VF400A NOR chip. So as long as the write enable lines for the chip are connected, it will work. This means it's also possible to replace boot1 but I don't want to do that because it's too risky. I am writing instructions about how to use Kermit and the loadb command to send the BOOT2 through serial, then flash it.

-------------

Do you have a dump of the manuf of any EVT/DVT/PVT CAS+? I want to analyze them and create a page like "NAND memory layout" on hackspire, but specific to CAS+.

Edit 2: there is now a modded version of nsbar which does the dvt -> evt conversion of boot2 automatically

[parrotgeek1]

I found this interesting piece of information online


Only booting from external flash on CS3 is supported on OMAP5912. All other boot options are not available. As a result of this, MPU_BOOT is a don’t care.
GPIO13 is used to select between full and fast boot. Set GPIO13 high to program external flash on CS3 using the USB port. Set GPIO13 low to boot from external flash on CS3.

Also see http://elinux.org/Flash_Recovery_Utility

[parrotgeek1]

I have discovered that the viewscreen has the product ID "0D" instead of "0C". This makes dumping even harder; it would need either nand reader or a boot1 exploit.