[Tuto] [EN/FR] Install/Installer nBoot + ControlX (+Linux)

[parrotgeek1]

.

[Bisam]

First one has already been tested : it's just the language pre-setting.

Second one : no idea.

[parrotgeek1]

.

[geekpersonman]

I'm pleased I finally could help in something... even if it was finding a bug.

[Edit] I added my Manuf

manuf.img.tns

and my BootD

bootd.img.tns

dumps.

I dumped my own manuf and BootD from a HW-E (06/12, figured it should be close enough) and found the same differences in the manufs that parrotgeek found, but comparing the BootDs they were very different...

diffbootd.txt

goodbootd.img.tns

[geekpersonman]

Third, I was suggesting a feature where ControlX is manually programed with the flash address where the upgrade files tell the calculator to write the OS and check there to find details about the operating system and then based on that select the 7/8/9 options for you, a feature that does not appear to be included in the public 4.4.5 beta.

Quite hard / impossible.
ControlX is running in the Boot1 context, and thus has no filesystem access.
So it has no way to check the /phoenix/install/TI-Nspire.tnc file header - it only has raw access to the filesystem partition.
The filesystem drivers will be loaded later, in the Boot2 context.

So could a piece of software be launched by controlX in to the boot2 context for the purpose of getting this info, put it in a specific memory address, then hand back control to controlX to load the patches?

The 7/8/9 choice is not only used to patch the OS, but also to patch the Boot2, since the Boot2 is going to reject/erase any OS you're not supposed to be using.
So removing the 7/8/9 choice is far from being trivial.

I'd even say it can't be removed, as I can't see how it could work when your calculator has no OS.

Also, the filesystem OS image is compressed and encrypted.
So checking the value at offset 0x20 is going to require probably too huge code...

well if Boot2 can detect the OS, and we can control Boot2, then why not patch it so when it detects a incompatible os instead of deleting it simply go back to controlX with what OS it actually is?

[parrotgeek1]

.

[Bisam]

@parrotgeek1 and geeokpersonman : Would it be possible that you DON'T quote the entire message that is just before yours ?
This is both useless and painful for the server, especially when it leads to nested quotes (a quote in a quote in a quote...) !

[critor]

well if Boot2 can detect the OS, and we can control Boot2, then why not patch it so when it detects a incompatible os instead of deleting it simply go back to controlX with what OS it actually is?

Still very complicated.
Not only because of the new Boot2 patch...
But also because ControlX will need to implement some post-Boot2 behaviour too...

And also dangerous, as you'll end up with a reboot-loop with an OS which is supported neither by the Boot2 nor by ControlX.

Also, Boot2 will have overwritten ControlX in the meantime, since it loads the OS at the very start of the SDRAM.
So extracting ControlX from Flash again is going to require an even huger Boot2 payload, which probably won't fit.


I think it'll be less complicated/dangerous/impossible to code some minimalist FlashFX filesystem reader, just to find the /phoenix/install/TI-Nspire.tnc file data in the raw filesystem partition, and read its header.

[parrotgeek1]

.

[critor]

nboot-ips.zip

Attached is an answer to a feature request by StarTrekVoyager.


You've got :

• IPS patches to install nBoot (v1 or v2) in any Manuf image
• nBooted Manuf images with all 4 official boot splashes
• images to help you selecting your boot splash

Edit : don't try on real hardware. The emulator confirms there's a problem.
Edit 2 : File updated.

This is a very early attempt - be wise and test on emulator first.
You just need to flash the selected Manuf image with BtMg/nsNandMgr.

For the moment, I can see no way to have a reliable nBoot-compatible on-calc splash flasher.
The problem is not only that nBoot does partially overwrite the splash data (there is a field for the splash data size which could be checked),
but also that nBoot does overwrite several bytes in the splash setup (positions and sizes of the different graphics elements), and not the same bytes in both nBoot versions.

3rd party boot splashes are still out of question.
The problem is that nBoot does partially overwrite the splash data.
ControlX fixes this, but it can only fix boot splashes it knows about : it includes the overwritten data for all 4 official boot splashes.
So 3rd party boot splashes respecting the official format are just not possible.