Have a TI-Nspire CX loaded with the TI-Nspire CX CAS OS?

[Lionel Debroux]

Well, OSLauncher was released, and it's a superset of what was indicated by the animated screenshot showcasing RunOS
But indeed, the important part of the source code (five C statements) is intentionally scarcely commented, and OSLauncher does not deal with hot-patching the OS before launching it (in a way similar to what tiosmod+amspatch does on the computer side).

[Illumio]

So we just need to keep the way of installing the CAS OS, when it's figured out, on the down low.  That shouldn't be too hard to do.  We just need it to be a select few who know (mainly people on this form and TICalc), right?

[DJ Omnimaga]

Basically direct instructions on how to run a CAS on a non-CAS just need to not be easy to figure out or find on public forums, otherwise the owners of that forum could get in legal troubles.

[Lionel Debroux]

The "install the CAS OS" words usually refer to permanent install, as opposed to hot-launching ala RunOS/OSLauncher.
And if it were easy enough to do, it would probably have been done in the two past years ("plop from inside" was showcased on December 30th, 2009)

The most obvious solution, for achieving permanent install, is factoring the public RSA signing keys used by TI (especially that of the boot2) to deduce the private key. But factoring the Nspire's RSA keys (1024-bit keys on the Clickpad & Touchpad, 2048-bit keys on the CX) is several million times harder than factoring the TI-68k & TI-Z80 512-bit RSA signing keys. This shifts the factorization problem from
something a single quad-core computer can do in less than a month (512-bit RSA key)
to
something which even the leading-edge researchers of the domain, equipped with academic resources amounting to hundreds of computers for years, haven't done yet and are unlikely to do before years (1024-bit RSA key)

This is assuming that
1) the only algorithm which is not hopeless for the task, named Number Field Sieve, is used for the factoring work;
2) the closed-source implementations made by these researchers are used; to date, two years after the factorization of RSA-768, the open-source implementations are not able to replicate it, because there have bottlenecks on basically all five steps of the factorization, which the leading-edge programs have eliminated by now.

IOW, the solution of factoring the RSA signing keys is completely ruled out - it would be like winning at multiple (or even many, in case the hopeless trial factoring is used) lotteries

[DJ Omnimaga]

Also if we managed to factor 0.1% of the 2048 bit keys, TI would immediately switch to 4096 bit keys.

[willrandship]

But they can't change the hardware ones. ie boot 1, which means the boot 2 will always be constant. We'll just see another calc model.

[Illumio]

Woop!  Ndless 3.1 Beta is released!  So what to do now with this topic?

[Lionel Debroux]

There's nothing new
OSLauncher has not been demonstrated on the CX (CAS), AFAWCT. It may be more, or less, reliable than on Clickpad / Touchpad Nspires... we don't know

For updated versions, the structure of the core of OSLauncher (few C statements, posted below) shouldn't change. But the code needs work in at least two directions:
* porting from the Ndless 1.7/2.0 API to the Ndless 3.1 API: replacing show_dialog_box2 with the appropriate equivalent. That should be trivial;
* adapting to the CX hardware. For one thing, one of the C statements I posted below will have to change; maybe it's enough. The thing is, I'd rather someone else - specifically, someone with more than one CX calculator - do the testing

[EDIT: add note about CX porting work, make a bullet list.]

[compu]

OSLauncher does not permanently install the CAS OS, it merely hot-launches it (and often fails to, for some reason nobody has bothered to investigate). The Press To Test (PTT) mode triggers a reboot and therefore undoes the effect of OSLauncher anyway, so you wouldn't have to do anything yourself, for your calculator to be usable in standardized tests

I have done some tests with OSLauncher and I found out that it freezes when you touch the touchpad while launching or start OSLauncher with the touchpad-click instead of enter.
When an OS is launched with the enter-key, I have never experienced any problems. Maybe this helps you to find the bug

[Lionel Debroux]

It may indeed mean something... but actions on the touchpad (or anywhere else) shouldn't matter, because the core of OSLauncher runs with interrupts disabled (it's the first of the few C statements I mentioned above), so I'm confused as well...

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// Killing all interrupts is necessary (exercise for the reader: why ?)     *((uint32_t *)0xDC00000C) = 0xFFFFFFFF;     __builtin_memset((void *)0x10000000, 0, 0x02000000);     // Useful ?     __builtin_memcpy((void *)0x10000000, dest, ziphdr.usize);     // Useful ?     __builtin_memcpy((void *)0x00000000, (void *)0x10000000, 0x40);     // This is also necessary (exercise for the reader: why ?)     *((uint32_t *)0xC000001C) &= ~((1 << 0) | (1 << 11));     // Launch the OS.     asm volatile(     ".arm \n"     "mov lr, pc\n"     "ldr pc, =0x10000000\n"     );

[Illumio]

So I guess the only answer for now is that only time will tell.

[Jim Bauwens]

Even though I don't know that much, I'll try do your exercises
 

Code: Select All | Copy To Clipboard

1 2 3 4

// Killing all interrupts is necessary (exercise for the reader: why ?) *((uint32_t *)0xDC00000C) = 0xFFFFFFFF;

To make that the new OS doesn't receive signals it doesn't need, and don't its the only thing that runs?

Code: Select All | Copy To Clipboard

1 2 3

// This is also necessary (exercise for the reader: why ?) *((uint32_t *)0xC000001C) &= ~((1 << 0) | (1 << 11));

I think you reset the LCD to some initial parameters (LCD controller enable and LCD power enable?), so that the new OS can initialize everything how it wants?


I think I should learn some ARM asm and everything that goes with it

[Lionel Debroux]

Jim: 1/2 mark, as mentioned on IRC

For OSLauncher updates, see also http://www.omnimaga.org/index.php?topic=7787.msg226486#msg226486 and below

[olivermadsen]

The message i get from trying to use a regular touchpad nSpire with CAS commands is a message bow that tells me to buy a CAS. The CAS for regular nspire might not actually be good and my lead to the downfall of the nspire for things like the ACT because CAS calculators are not allowed to be used on it and if an OS included CAS functions, they might disallow all nSpires for the test. Take one for high school TI-nspire users out there and buy a CAS if you want it's features.

[Lionel Debroux]

The message i get from trying to use a regular touchpad nSpire with CAS commands is a message bow that tells me to buy a CAS

Which is natural if the Nspire is running the non-CAS OS

The CAS for regular nspire might not actually be good and my lead to the downfall of the nspire for things like the ACT because CAS calculators are not allowed to be used on it and if an OS included CAS functions, they might disallow all nSpires for the test.

Simply put, this is a completely irrational fear
Not least because the Nspire has a PTT mode much more efficient than of the 84+(SE).


People who live in the many countries possessing restrictions such as "CAS forbidden" in standardized tests - no matter how utterly disconnected from real-world usage, and therefore stupid, they are - may want to campaign against that kind of brain-damage, and the incompetents supposed to regulate standardized tests.
In France, where I live, CAS functionality is allowed, and the non-CAS Nspire, whose math functionality is roughly equivalent to that of the cheaper, more programmable and highly popular 83+(SE)/84+(SE), is hard to find in stores. People stick to the programmable and once popular TI-68k series... or buy the overpriced CAS Nspires and help the profit margin of TI and distributors.
Indeed, CAS Nspires are sold at higher price tags than the non-CAS Nspires, though the CAS models cost less to manufacture (no interchangeable keyboards), and their OS had lower development costs (they had to do the CAS version anyway; the non-CAS OS required extra development effort for replacing functions with stubs which tell people to buy a CAS, and also for building the slow, incomplete and buggy 84+ emulator. On the CX series, the keyboard is not interchangeable, but the unjustified extra price tag of the CAS OS remains.