Screen Issues and more-linux Ti Nspire CX revision Y

→ **MyCalcs** profile · de **SuperXX** » 01 Oct 2021, 12:16

Does it behave the same on hardware?

Yes and now that I tested also no.

Let me explain.

Last times you saw when I was testing in Firebird-emu, I was using the .dtb you sent earlier for the ti nspire Cx II which gives all of that you see and in real hardware it happens all the same.

But I went back to the archive.zip here: https://github.com/tangrs/nspire-linux-loader2/issues/7#issuecomment-840887756 and put again the nspire-cx.dtb.tns on my calculator and using the:

Code: Tout sélectionner: cmdline root=/dev/ram debug console=tty0

and it gives the same lines with a twist, now half of the screen shuts off and starts refreshing the image. It´s better to understand if I send a video as an attachment of course, so you can see it of course.

I assume you dumped boot1 and manuf from your calc and used that to set up firebird?

Correct, that was what I did.

Can you set up a new flash image without specifying a manuf (HW-W as subtype) and try with that?

For this and because it was a HW-W calculator in theory I tested with this .dtb: https://tiplanet.org/nspire-linux-builds/devicetree/nspire-cx.dtb and I used this config for the flash image, everything the same except for manuf

And yes the same thing happens

Note I also used the:

Code: Tout sélectionner: cmdline root=/dev/ram debug console=tty0

So yeah, you are probably right, it´s not an Hardware problem.

I should also point out that my calculator uses the same Boot2 that I used in Firebird-emu (https://tiplanet.org/forum/archives_voir.php?id=1362033) but with nLoader flashed, I´m not using nLoader in Firevird-emu

Which version of Firebird are you using?

Version 1.5

You could also try to boot linux with the JIT disabled, by entering "t-" and "c" as debugger commands before running the script.

Like this?

Code: Tout sélectionner: kernel linux/zImage.tns dtb linux/nspire.dtb.tns initrd linux/initrd.tns cmdline root=/dev/ram debug t- c boot

If it is like this, it seems that the right green vertical bar is no longer there:

→ **MyCalcs** profile · de **Vogtinator** » 02 Oct 2021, 14:56

SuperXX a écrit:
Does it behave the same on hardware?

Yes and now that I tested also no.

Let me explain.

Last times you saw when I was testing in Firebird-emu, I was using the .dtb you sent earlier for the ti nspire Cx II which gives all of that you see and in real hardware it happens all the same.

But I went back to the archive.zip here: https://github.com/tangrs/nspire-linux-loader2/issues/7#issuecomment-840887756 and put again the nspire-cx.dtb.tns on my calculator and using the:

Code: Tout sélectionner
cmdline root=/dev/ram debug console=tty0

and it gives the same lines with a twist, now half of the screen shuts off and starts refreshing the image. It´s better to understand if I send a video as an attachment of course, so you can see it of course.

It looks like the LCD timing is misconfigured (only a part is refreshing properly), which is actually promising! It means that the kernel reconfigured the LCD and probably tries to display something.

I created a panel configuration which results in Linux writing the same timings as the OS (minus the oddity that the OS uses 320x320px for some reason). Please try those with the same ll2 script:

dtb.tns: DTB with cx-w display; (4.33 Kio) Téléchargé 198 fois

zImage.tns: zImage with cx-w display; (2.6 Mio) Téléchargé 203 fois

If it goes well, you should see text, but unfortunately it'll be mirrored vertically which Linux doesn't support currently because only software rotation is supported. That could be worked around by using the lcd_compat mode again though.

I assume you dumped boot1 and manuf from your calc and used that to set up firebird?

Correct, that was what I did.

Can you set up a new flash image without specifying a manuf (HW-W as subtype) and try with that?

For this and because it was a HW-W calculator in theory I tested with this .dtb: https://tiplanet.org/nspire-linux-builds/devicetree/nspire-cx.dtb and I used this config for the flash image, everything the same except for manuf

And yes the same thing happens

Note I also used the:

Code: Tout sélectionner
cmdline root=/dev/ram debug console=tty0

So yeah, you are probably right, it´s not an Hardware problem.

I should also point out that my calculator uses the same Boot2 that I used in Firebird-emu (https://tiplanet.org/forum/archives_voir.php?id=1362033) but with nLoader flashed, I´m not using nLoader in Firevird-emu

Which version of Firebird are you using?

Version 1.5

Ok, so I can't explain the failures there yet. Here with FB 1.5 on Windows (well, I tried running it with wine this time) Linux boots fine with the generated HW-W manuf.

You could also try to boot linux with the JIT disabled, by entering "t-" and "c" as debugger commands before running the script.

Like this?
Code: Tout sélectionner
kernel linux/zImage.tns dtb linux/nspire.dtb.tns initrd linux/initrd.tns cmdline root=/dev/ram debug t- c boot

Those are commands for the Firebird debug console. Before running the ll2 script, click Tools -> Enter Debugger and run those commands.

If it is like this, it seems that the right green vertical bar is no longer there:

Weird, but not unexpected. The exact contents of the framebuffer while the kernel is "doing stuff" in that RAM area are practically random.

→ **MyCalcs** profile · de **SuperXX** » 02 Oct 2021, 19:17

It looks like the LCD timing is misconfigured (only a part is refreshing properly), which is actually promising! It means that the kernel reconfigured the LCD and probably tries to display something.

I created a panel configuration which results in Linux writing the same timings as the OS (minus the oddity that the OS uses 320x320px for some reason). Please try those with the same ll2 script:
dtb.tns
DTB with cx-w display
(4.33 KiB) Downloaded 1 time
zImage.tns
zImage with cx-w display
(2.6 MiB) Downloaded 1 time

If it goes well, you should see text, but unfortunately it'll be mirrored vertically which Linux doesn't support currently because only software rotation is supported. That could be worked around by using the lcd_compat mode again though.

I can say it´s working, but I think it´s giving the same error it gave for the CX II, but I´ll check the initrd or try to boot from USB later.

Just to note, brief moments before starting to appear the text on screen, this glitchy screen appears for brief seconds.

Those are commands for the Firebird debug console. Before running the ll2 script, click Tools -> Enter Debugger and run those commands.

Ok, so here is the output, which is really smaller then I would excpect.

Code: Tout sélectionner: Warning (10330c7c): Data abort: address=514d782b status=01 instruction at 10330c7c Warning (c049b070): Undefined instruction at c049b070 Warning (c005b2f0): Data abort: address=00000000 status=05 instruction at c005b2f0

Edit:With the same initrd as the CXII it´s working the same way as CXII but no luck for the start_USB.ll2, it happens the same thing as CXII

→ **MyCalcs** profile · de **Vogtinator** » 03 Oct 2021, 17:48

I can say it´s working, but I think it´s giving the same error it gave for the CX II, but I´ll check the initrd or try to boot from USB later.

Yep, it's working!

The error is XZ decompressor ran out of memory which means that the initrd is either too big, broken or somehow it's not seeing all of RAM.

Edit:With the same initrd as the CXII it´s working the same way as CXII but no luck for the start_USB.ll2, it happens the same thing as CXII

Yeah, that kernel is stil built with my local config mostly for the CX II. The USB driver needed for the CX isn't actually enabled there yet, here's a build with that included:

zImage.tns: zImage with CX W LCD and chipidea usb; (2.62 Mio) Téléchargé 197 fois

If it still doesn't work, you can use the initrd to debug USB though by collecting logs, lsusb info and trying to mount manually.

→ **MyCalcs** profile · de **SuperXX** » 04 Oct 2021, 12:39

Yep, it's working!

The error is XZ decompressor ran out of memory which means that the initrd is either too big, broken or somehow it's not seeing all of RAM.

Ok, I´ve just verified the Available Internal Storage Space available in my calculator and it´s "11.1MB", which wouldn´t work with this 12MB initrd, because it would need to decompress the file during boot when it doesn´t have the space to do it, so ok.

Yeah, that kernel is stil built with my local config mostly for the CX II. The USB driver needed for the CX isn't actually enabled there yet, here's a build with that included:
zImage.tns
zImage with CX W LCD and chipidea usb
(2.62 MiB) Downloaded 4 times
If it still doesn't work, you can use the initrd to debug USB though by collecting logs, lsusb info and trying to mount manually.

It worked, the errors that I´m getting seem to be on Arch Linux side now:

Code: Tout sélectionner: [ok]Stop Network Name Resolution Starting Network Name Resolution [FAILED]Failed to start Network Name Resolution See 'Systemctl Status SystemResolved Service' for details

Maybe some Googling will solve this, but it´s to proof that it can now boot from USB successfully.

Here is the Arch Linux image btw

http://os.archlinuxarm.org/os/ArchLinuxARM-kirkwood-latest.tar.gz

Additional Question about the initrd:
I forgot to ask when I originally posted this, do you know how can I make my own initrd?

For example I con download the BusyBox initrd here: https://tiplanet.org/nspire-linux-builds/initrd.tns, which from what I understand is the linux filesystem. So, since I can´t just run a USB Drive for the CXII for reasons you already mentioned, how could I make my own initrd? I tried grabbing a .tar.gz image, this one: https://tiplanet.org/nspire-linux-builds/xconfig-latest.tar.xz and changed the .tar.gz extension to .tns, but it didn´t work because it gave this error:

Code: Tout sélectionner: No filesystem could mount root, tried ext3 ext2 ext4

Can you teach me in how I can make for example this image https://tiplanet.org/nspire-linux-builds/xconfig-latest.tar.xz into an initrd to boot in the CXII?

→ **MyCalcs** profile · de **Vogtinator** » 06 Oct 2021, 20:47

SuperXX a écrit:
Yep, it's working!

The error is XZ decompressor ran out of memory which means that the initrd is either too big, broken or somehow it's not seeing all of RAM.

Ok, I´ve just verified the Available Internal Storage Space available in my calculator and it´s "11.1MB", which wouldn´t work with this 12MB initrd, because it would need to decompress the file during boot when it doesn´t have the space to do it, so ok.

"Internal Storage" is the flash, which isn't the limiting factor here. The issue is that RAM needs to hold (at least temporarily) both the whole compressed initrd and the whole uncompressed initrd in RAM. That's most likely way over the ~50MiB limit. Additionally, the compressed initrd is loaded while the OS is still running, so that's also restricted to ~10MiB.

Yeah, that kernel is stil built with my local config mostly for the CX II. The USB driver needed for the CX isn't actually enabled there yet, here's a build with that included:
zImage.tns
zImage with CX W LCD and chipidea usb
(2.62 MiB) Downloaded 4 times
If it still doesn't work, you can use the initrd to debug USB though by collecting logs, lsusb info and trying to mount manually.

It worked, the errors that I´m getting seem to be on Arch Linux side now:

Code: Tout sélectionner
[ok]Stop Network Name Resolution Starting Network Name Resolution [FAILED]Failed to start Network Name Resolution See 'Systemctl Status SystemResolved Service' for details

Maybe some Googling will solve this, but it´s to proof that it can now boot from USB successfully.

Great! How long did it take to boot?

It's probably missing some more kernel features to work, or ran out of memory...

Here is the Arch Linux image btw

http://os.archlinuxarm.org/os/ArchLinuxARM-kirkwood-latest.tar.gz

Additional Question about the initrd:
I forgot to ask when I originally posted this, do you know how can I make my own initrd?

For example I con download the BusyBox initrd here: https://tiplanet.org/nspire-linux-builds/initrd.tns, which from what I understand is the linux filesystem. So, since I can´t just run a USB Drive for the CXII for reasons you already mentioned, how could I make my own initrd? I tried grabbing a .tar.gz image, this one: https://tiplanet.org/nspire-linux-builds/xconfig-latest.tar.xz and changed the .tar.gz extension to .tns, but it didn´t work because it gave this error:
Code: Tout sélectionner
No filesystem could mount root, tried ext3 ext2 ext4

Can you teach me in how I can make for example this image https://tiplanet.org/nspire-linux-builds/xconfig-latest.tar.xz into an initrd to boot in the CXII?

An initrd is a compressed filesystem image, e.g. using ext4 or squashfs. There are various tutorials on the internet how to create a filesystem image and compress it, the harder part is providing the content. You won't be able to fit more than ~30MiB inside and still have a usable system, so using anything like "xconfig" won't work.

→ **MyCalcs** profile · de **SuperXX** » 07 Oct 2021, 21:53

Vogtinator a écrit:
SuperXX a écrit:
Yep, it's working!

The error is XZ decompressor ran out of memory which means that the initrd is either too big, broken or somehow it's not seeing all of RAM.

Ok, I´ve just verified the Available Internal Storage Space available in my calculator and it´s "11.1MB", which wouldn´t work with this 12MB initrd, because it would need to decompress the file during boot when it doesn´t have the space to do it, so ok.

"Internal Storage" is the flash, which isn't the limiting factor here. The issue is that RAM needs to hold (at least temporarily) both the whole compressed initrd and the whole uncompressed initrd in RAM. That's most likely way over the ~50MiB limit. Additionally, the compressed initrd is loaded while the OS is still running, so that's also restricted to ~10MiB.

OK, it may be necessary to only run a initrd after cold booting the calculator. Now I only have 10,8MB of internal storage and it worked, which complements what you were saying here.

Great! How long did it take to boot?

It's probably missing some more kernel features to work, or ran out of memory...

It took around 23 minutes to get in that stage, with the ethernet, mouse and External Drive Connected. Now, with some of my tests I realised that the mouse gives around a 15 minutes (which by itself is practically the time that omnimaga post guy waits for the calculator to fully boot into arch) of penalty for the calculator to get in that stage. Also, it is interesting that my mouse has a LED and my calculator seems to use it as a memory usage indicator, like the LED in my PC that indicates the SSD is in use. I´ll attach a small video with that.

But now, when I was counting the time it takes the calculator to get there. It was finally able to get pass that, which was really surprising with all the tries I have tried. And I tried life 6 times before this try. And after a total of 32 minutes booting, the calculator shut down because it ran out of battery (it was 25% when I started, my bad)

An initrd is a compressed filesystem image, e.g. using ext4 or squashfs. There are various tutorials on the internet how to create a filesystem image and compress it, the harder part is providing the content. You won't be able to fit more than ~30MiB inside and still have a usable system, so using anything like "xconfig" won't work.

Ok ok. I searched what you said and came to this article https://unix.stackexchange.com/questions/503211/how-can-an-image-file-be-created-for-a-directory and tried to mess around with the smallconfig build (https://tiplanet.org/nspire-linux-builds/smallconfig-latest.tar.xz). But uncompressed it has like 50MB which will probably not work, not even in the CXII. The uncompressed smallconfig image is really big and as you explained, it wouldn´t have space to uncompress not even in the TI Nspire CXII´s 64MB of RAM! Maybe some compression, but I don´t know.

→ **MyCalcs** profile · de **Vogtinator** » 28 Oct 2021, 21:11

Also, it is interesting that my mouse has a LED and my calculator seems to use it as a memory usage indicator, like the LED in my PC that indicates the SSD is in use. I´ll attach a small video with that.

Fun! Normally LED triggers are defined in the device tree, but apparently there's some more logic outside of that.

Good news: Meanwhile I was able to get USB host support on CX II working! It only took a regulator-always-on to force the 5V supply on and removing GMIR_INT_POLARITY (same hack as for the gadget driver) to fix severe performance issues (was ~100KiB/s depending on USB drive). I'm using an externally powered hub here and was able to boot from a USB drive just fine, now with ~7MiB/s read speed reported by hdparm.

The fixes aren't in git yet because for some reason either git or GitHub aren't smart enough to notice that only the diff on top of mainline needs to be transmitted, and not the whole diff between kernel versions...

Due to missing role switch support Vbus is always on, so I recommend to not connect the calc to a PC while Linux is running. It works best when the USB device(s) is/are already connected to the calculator before starting linuxloader anyway, which avoids the Vbus conflict.

zImage.tns: zImage with usb host support; (2.65 Mio) Téléchargé 203 fois

dtb.tns: DTB with USB host support (DO NOT ATTACH TO A PC); (4.49 Kio) Téléchargé 271 fois

→ **MyCalcs** profile · de **Bisam** » 29 Oct 2021, 17:53

Also, it is interesting that my mouse has a LED and my calculator seems to use it as a memory usage indicator [...]

I think it's more likely indicating changes of power consumption : the more the calc needs power, the less the LED is lit, isn't it ?

→ **MyCalcs** profile · de **Vogtinator** » 31 Oct 2021, 11:16

Bisam a écrit:
Also, it is interesting that my mouse has a LED and my calculator seems to use it as a memory usage indicator [...]

I think it's more likely indicating changes of power consumption : the more the calc needs power, the less the LED is lit, isn't it ?

Unlikely. The voltage would need to drop significantly to turn the LED off fully, which would definitely cause the calculator to crash.