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

[jdless]

Yes That worked fine. I thought that installer-file is enough..
I did noticed that startup-folder works in ptt-mode, not first time entering but after one reset
I have messed up with older versions and I'm not sure which version it is now..

[critor]

I did noticed that startup-folder works in ptt-mode, not first time entering but after one reset

Indeed.
Because Ndless is using absolute pathes, and thus totally ignores the filesystem virtual root which is modified in exam mode.

It wasn't designed this way on purpose (to be able to tinker with the exam mode) - it's just that when the startup was introduced with Ndless 3.1, there were much less regulations which had adopted the exam mode.

[critor]

ControlX 4.4.3 is now online :
archives_voir.php?id=652778

There's been a 2 weeks private beta, and I haven't been reported any problem.

New huge improvements :

• in theory, can launch all existing TI-Nspire CX and TI-Nspire CM OSes, even OSes older than 4.0.1, whether they are CAS or non-CAS, and whether they are signed with the production or development keys
• can be installed on TI-Nspire CM too (the tutorial needs to be updated)

In pratice, the Boot2 4.0.3 injected payload size is limited, and support hasn't been enabled for all OSes in the prebuilt binary.
In fact, 6 different payloads are included :

• a TI-Nspire CX CAS production payload (the biggest one)
• a TI-Nspire CX production payload
• a TI-Nspire CX CAS development payload
• a TI-Nspire CX development payload
• a TI-Nspire CM CAS production payload
• a TI-Nspire CM production payload

ControlX chooses the payload based on new 7/8/9 setup options in its menu :


Option 7 is to switch your TI-Nspire family : CX or CM.
Option 8 is to switch your TI-Nspire type : CAS or non-CAS
Option 9 is to switch the Boot2 validation keys : production or development.
Those options don't reflash anything and just patch things in the RAM Boot2 image. They'll be cancelled by any reset. So they're unlikely to brick anything.
Which means that if you really want to install an OS targeting a different model, you'll have to set the needed switch(es) as default boot options by holding .
Default boot options can be reset by pressing while holding .

The above screen is for a CX CAS.
To install a TI-Nspire CM non-CAS OS on it for example, you'd have to hold and then and reset.
Your simulated model will be shown on the last line anyway.

Here is the list of supported OSes in the prebuilt image :

• CX 3.0.0.0, 3.0.0.1045 & 3.0.0.1503 (development OSes - one of them has a nice theme editor)
• CM 3.1.0.0, 3.1.0.236 (development OSes)
• CM CAS 3.1.0.157 (development OSes)
• CX, CX CAS, CM & CM CAS 3.1.0.392
• CX & CX CAS 3.2.0.776, 3.2.0.1030 & 3.2.0.1180 (development OSes)
• CX, CX CAS, CM & CM CAS 3.2.0.1212 & 3.2.0.1219
• CX & CX CAS 3.2.4
• CX CAS 3.3.0.218 (development OS with arabic language)
• CX CAS 3.3.0.538 (OS with arabic language)
• CX CAS 3.6.0.427 & 3.6.0.521 (development OSes)
• CX & CX CAS 3.6.0.546 & 3.6.0.550
• CX & CX CAS 4.4.0.532

If you need support for other 3.9-4.3 OSes, you'll have to rebuild ControlX.
But you should just use OS 4.4 if you need a recent OS, shouldn't you ?

Some rare limitations :

• TI-Nspire CM : OSes 4.0.0+ need 64MiB SDRAM and aren't going to boot on 32MiB SDRAM models (TI-Nspire CX prototypes and TI-Nspire CM)
• TI-Nspire CM : on a TI-Nspire CM or TI-Nspire CM CAS, Ndless installation is likely to fail with CX OSes 3.6 and 3.9.1 - not enough free SDRAM left...
  (hint : you should try to use old Ndless releases with a smaller ndless_resources file, and to shrink your OS with nTnoc)
• TI-Nspire CM : on TI-Nspire CM or TI-Nspire CM CAS, uninstallation is dangerous and is likely to brick your calculator if done improperly
  (without ControlX, OSes older than 4.0.1 aren't going to boot properly - and OSes 4.0.0 and newer won't boot on this hardware - and there's the minOS downgrade limit too...)
  By doing things improperly, you can easily put your calculator in which no OS can be installed.
  My hint : once installed, do *never* uninstall/erase ControlX or nBoot.
• CAS/non-CAS switching : although OSes targeting a different model type are going to boot (non-CAS OS on CAS model or CAS OS on non-CAS model), with versions 3.9.0 and newer any attempt to calculate anything is going to reboot the calculator
  (you need additional non-boot patches which aren't going to be included in ControlX, mainly because I already don't have enough space for boot patches)
• CAS/non-CAS switching : If you install an OS targeting a different model type, the way ControlX currently works, it's going to be launched unpatched once, the 1st complete reboot after sending the OS.
  In that case, versions 4.0.2 and newer are going to uninstall themselves.
  Hint : With versions 4.0.2 and newer, you need to press reset as soon as the 1st reboot after sending the OS is complete, thus after the loading bar reaches 100% immediatly when the screen display turns dark/grey. This won't be needed again until you install another OS.
• downgrading : although it can boot them, Boot2 4.0.3 is not going to accept installation of OSes older than 3.6
  (you'd need to flash a Boot2 3.2.4 image somewhere for this, but I'm working on a much easier way)
• downgrading : ControlX is not fixing hardware limitations :
  
  • OSes 3.9.0 and older aren't going to work properly on CX hardware revision S and newer
  • OSes 3.2.0 and older aren't going to work on CX hardware revision J and newer

Have fun !

[critor]

Ok, downgrading to an OS version older than 3.6 was quite hard.

You needed to :
- reset the minOS field
- flash a Boot2 version older than 3.6 and different than 3.1 (bad support in ControlX) somewhere - for exemple 3.2.4
(and to not overwrite your 4.0.3 Boot2)
- use the maintenance menu to remove the current OS
- manually run the old Boot2 image from ControlX
- then send the OS version older than 3.6

This is because since version 3.6, OS install files include a manifest subfile.
Boot2 3.6+ don't check this when loading OSes, but it's mandatory for installation.
So you needed an old Boot2 image just for the installation.



But forget it.
I promised a much easier way - here it comes : nSwitchOS
archives_voir.php?id=877138

It's an Ndless program which will install any provided OS image - it doesn't check the manifest or anything else.
But the Boot2 is still going to perform its regular (non-install) checks on the next boot, and remove the OS if it doesn't like it.
So depending upon the OS you choose to install this way, you'll still need the Nlaunch CXM or nBoot+ControlX boot helper.

[parrotgeek1]

.

[critor]

Thanks for the typo.
No problem, I hope you've passed your exams.

I'm currently still working on something big, a partial workaround the official splash screen nBoot corruption, and then yes I think I'll release it to Github.

[critor]

Next ControlX 4.4.4 image drops the built-in splash screen and does its best to fix the official splash screen :

So, for those who are fearing something, you'll be spotted less easily.

As a side effect, ControlX 4.4.4 image is going to be much smaller...

In fact, in Manuf the splash screen compressed data is ~75.5KiB.
But nBoot installation does overwrite a tiny part, 384B, which is enough to corrupt the data and make the Boot1+Boot2 ignore it.

ControlX 4.4.4 now includes a backup of those 384B for each known official splash screen :
- CX prototypes
- CM prototypes
- CM, and CX up to 2015
- CX since 2015

Based on the compressed data size, ControlX 4.4.4 selects the missing 384B sized piece, injects it, then uncompresses the splash screen data, and moves the permanent element #1 raw data to the screen buffer.
See https://hackspire.org/index.php/NAND_Memory_Layout starting from Manuf offset 0x894.

[parrotgeek1]

Next ControlX 4.4.4 image drops the built-in splash screen and does its best to fix the official splash screen :

So, for those who are fearing something, you'll be spotted less easily.

As a side effect, ControlX 4.4.4 image is going to be much smaller...

In fact, in Manuf the splash screen compressed data is ~75.5KiB.
But nBoot installation does overwrite a tiny part, 384B, which is enough to corrupt the data and make the Boot1+Boot2 ignore it.

ControlX 4.4.4 now includes a backup of those 384B for each known official splash screen :
- CX prototypes
- CM prototypes
- CM, and CX up to 2015
- CX since 2015

Based on the compressed data size, ControlX 4.4.4 selects the missing 384B sized piece, injects it, then uncompresses the splash screen data, and moves the permanent element #1 raw data to the screen buffer.
See https://hackspire.org/index.php/NAND_Memory_Layout starting from Manuf offset 0x894.

to get rid of "preparing file system, please wait and "loading operating system", write 118b6fdc E3A00001

edit: I think i posted that before sorry

[critor]

Thanks.

For the moment, while there is no 'silent' mode in ControlX, I don't think it's useful getting rid of TI black and white strings ("preparing file system, please wait", "loading operating system", "Operating System not found. Install OS now.").

I think it'd be more useful to check if something can be done regarding the progress bar.

If it helps, in the ControlX context, I have :
- the patched splash elements compressed data (starting at offset 0x930 in Manuf)
- the raw splash elements compressed data

So I don't only have background #1, I also have the blue progress bar and the different error icons.

So we can provide all this to the Boot2, assuming we figure out how to.

[parrotgeek1]

Thanks.

For the moment, while there is no 'silent' mode in ControlX, I don't think it's useful getting rid of TI black and white strings ("preparing file system, please wait", "loading operating system", "Operating System not found. Install OS now.").

I think it'd be more useful to check if something can be done regarding the progress bar.

If it helps, in the ControlX context, I have :
- the patched splash elements compressed data (starting at offset 0x930)
- the raw splash elements compressed data

So I don't only have background #1, I also have the blue progress bar and the different error icons.

So we can provide all this to the Boot2, assuming we figure out how to.

In boot1, progress_callback is a void function with 1 argument (an int) that is the number of pixels of the bar to draw. if you make your own void my_progress_callback(int pixels) which draws the manuf bar, you can pass &my_progress_callback to read_nand.

I'm still figuring out boot2.

P.S. I really think you should disable that text. It looks really bad on a red background to have the white stripe.