Forum TI-Planet.org

critor a écrit:

geekpersonman a écrit:And also, according to this page: https://hackspire.org/index.php/OS_upgrade_files
couldn't you just check (8080 - 8 : The first 4 bytes are the OS base address: address to which the OS will be copied by boot 2(0x10000000). ) for OS information?

In which tool ?

In controlX to detect the OS and load patches automatically

.

Sorry, I should clarify.
There appears to be an issue with the separate cas patcher that that either incorrectly patches or does not patch the regression functions and causes it to reboot.

A separate issue I have found seems to be related to Nswitch OS where it upgrades the os in such a way that the strings in the catalog do not get changed between 4.4 CX and 4.4 CAS but does not crash the OS, which does not happen when installing from the computer.

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.

Lastly, although I did not mention this before, the 4.4 external cas patch appears to crash or cause the CX OS to become unresponsive (for me at least) which makes sense, but it would be nice if it didn't load the patches when it detected a CX OS so you do not have to constantly move it in and out of the startup folder in ndless when you want to change the OS.

geekpersonman a écrit:Sorry, I should clarify.
There appears to be an issue with the separate cas patcher that that either incorrectly patches or does not patch the regression functions and causes it to reboot.

Ok, I undestand the 4.4 external CAS patcher is not perfect. Thanks for the report.

geekpersonman a écrit:A separate issue I have found seems to be related to Nswitch OS where it upgrades the os in such a way that the strings in the catalog do not get changed between 4.4 CX and 4.4 CAS but does not crash the OS, which does not happen when installing from the computer.

Yes, I've understood why. Thanks for the bug report - I'll try to fix it as soon as possible.

geekpersonman a écrit: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.

geekpersonman a écrit:Lastly, although I did not mention this before, the 4.4 external cas patch appears to crash or cause the CX OS to become unresponsive (for me at least) which makes sense, but it would be nice if it didn't load the patches when it detected a CX OS so you do not have to constantly move it in and out of the startup folder in ndless when you want to change the OS.

Yes, it would be nice if some OS version check could be added to the external CAS patcher.
If your calculator is using hardware revision A-R, you may install and use the 3.6 CAS OS.
It doesn't need an external CAS patcher and thus is directly going to be fully working.

critor a écrit:

geekpersonman a écrit: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?

critor a écrit:

geekpersonman a écrit:Lastly, although I did not mention this before, the 4.4 external cas patch appears to crash or cause the CX OS to become unresponsive (for me at least) which makes sense, but it would be nice if it didn't load the patches when it detected a CX OS so you do not have to constantly move it in and out of the startup folder in ndless when you want to change the OS.

Yes, it would be nice if some OS version check could be added to the external CAS patcher.
If your calculator is using hardware revision A-R, you may install and use the 3.6 CAS OS.
It doesn't need an external CAS patcher and thus is directly going to be fully working.

I have a HW-T, but tried anyway loading 3.6 by buying a usb battery bank, but i was too paranoid about it somehow breaking and switched to 4.4 when I found out a patcher had come out for it. :/

.

geekpersonman a écrit:

critor a écrit:

geekpersonman a écrit: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...

critor a écrit:

geekpersonman a écrit:

critor a écrit:

geekpersonman a écrit: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...

I figured out why it couldn't find some patches!

objdump disassembles "r10" register as its alternate name "sl"
so my code wasn't seeing things like ldr sl, #900a0000

Great news, when can we expect update fixing it?

geekpersonman a écrit:Great news, when can we expect update fixing it?

now
on the same github link

BUT i havent added the detection of the right OS yet
I'll do it soon

can anyone write me some code which turns the entire screen red and then uses arm timer to wait 2 seconds

critor?