A quick update: the IRQ controller driver for classic models has just been mainlined.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=397e7b515785cad6e10b29f3001fd80c3f519bb8

There's no defconfig right now for the newer kernels. I usually just do a make allnoconfig and manually select the drivers I need.

Here's a quick list of options you should have

CONFIG_BLK_DEV_INITRD=y
CONFIG_ARCH_NSPIRE=y
CONFIG_AEABI=y
CONFIG_BLK_DEV_RAM=y
CONFIG_KEYBOARD_NSPIRE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_FB=y
CONFIG_FB_ARMCLCD=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_TMPFS=y


Thanks everyone for your help!

It seems the only model I have to worry about are the non-removable Clickpad CAS keyboards.

Could somebody please help me figure out why I cannot use the larger rootfs files. I don't want to have to make an entire thread for it.

The larger rootfs is meant to be loaded onto a USB drive and booted from there. There's not enough RAM for it to work as an initrd.

Question: If the HP Prime is eventually hackable ("HelPless" or "HPless" instead of "Ndless"?), do you have any plan to port this to that calc since it has a similar processor?

I don't have plans to get a HP Prime but it does sound interesting. If there's documentation, I'm happy to give it a shot.

Just a heads up that minimal kernel support for Nspire CX has been merged into mainline today. For devs, this means you can clone Linus's repo and build a Nspire CX kernel We'll also be seeing more patches for the Nspire come up over the next week or so.

Unfortunately, the last patch required for the classic models missed the merge window so we probably won't see mainline support for the classic models until next round

Hi,

Just dropping in to say that this project is not dead! Despite the lack of visible activity, progress is being made. This post will hopefully bring everyone up to date about what's been happening.

Right now, here are some of the things that has happened or is happening now.

• Getting TI-Nspire support into mainline
• Rewriting the TI-Nspire port to use device trees
• Added support for device tree loading in linuxloader2
• Debugging a very annoying and well hidden bootloader bug which has stumped us for weeks (shout outs to Vogtinator)
• PTT LEDs finally unlocked

Mainline

We're in the process of getting TI-Nspire support into the mainline kernel. If this is successful, it'll make maintaining the kernel much easier and also have better code.

To start off with, we're just submitting the absolute basic platform code needed to boot Linux. It doesn't have support for any other hardware than the interrupt controller, timer, clock and keypad.
Once the base kernel is mainlined, we'll begin porting hardware support in again.

Device tree rewrite

Part of getting TI-Nspire support into the mainline kernel involved switching to using device trees. This means we can effectively use a file to describe our hardware configuration and we don't have to keep chucking code at the kernel for every new hardware supported which is always nice.

Unfortunately, it was easier to just begin writing the whole platform from scratch than fix up our old code. This was exactly what we did.

The old code was left as-is which is why you're not seeing any new updates in nightly builds.

Device tree support in linuxloader2

Obviously, to boot the newer, device tree kernels, the bootloader needed to be updated to support loading device tree blobs. It turned out adding support for it was a lot easier than originally anticipated. The first version did not have support for initrds and command line in DT kernels.

Support for it quickly improved and, thanks largely to Vogtinator's contributions, we had a initrd loading and command line loading working. There was a little confusion with 'initrds' and 'ramdisks' which caused the initial version with support for initrds to not work properly. This was due to my bad variable naming in the bootloader code which did not clearly differentiate between the two.

Just when we thought we had a good bootloader going, Vogtinator and I started noticing random things happening in the kernel. Drivers weren't being loaded properly, the LCD driver would work about fifty percent of the time. At the time I suspected something was broken in the kernel and a race condition was occurring. We were lucky to even make it to a shell. For the next couple of weeks, we were pulling hairs out trying to work out what was wrong (at least I was ). Every now and then, someone would come up with a 'fix' that'd work for about an hour and break again. Other times, we'd blame the device tree handling code. Sure, we looked at the bootloader, Vogtinator shuffled some things around but the same things kept happening.

I assumed that if the device tree handling code was truly broken, there would surely be a kernel patch fixing it very soon so I waited to see if anyone else reported a similar problem. A few more weeks went by and the merge window opened again and nothing showed up. I started to suspect the bootloader again since it was unlikely a bug in the kernel since nobody has stumbled on it and went back to the ARM booting guide. A bit of trial and error and I had something that would now work 100% of the time! It was probably the bootloader's fault after all. I quickly sent a patch over to Vogtinator and voila, it was confirmed we had fixed the bug!

PTT LEDs finally unlocked

On the side, I was also researching how to unlock the PTT LEDs. A few months ago, I had partial success and managed to unlock one register (which was enough to control the LED). Now, the LED interface is fully cracked and unlocked - we can use the LED again!

The catch is, we can't unlock the LED in the TI-Nspire OS because it resets if it detects the LEDs have been unlocked. However, that doesn't bother us since we're booting Linux Being able to use the LEDs is really awesome for Linux since we can now have activity indicators for various things in the kernel (like NAND access)

Thanks

I don't think I've properly credited the few people who've contributed a lot to the project. Cheers to:

• Lionel Debroux - for kindly hosting nightly builds of the kernel, pressuring me to mainline the kernel and providing assistance in managing the project
• Vogtinator - for all the work he has contributed to linuxloader2, kernel and TI-Nspire documentation
• All the end users - for your support and being guinea pigs testing the kernel for us

So, that's the state of Linux on TI-Nspire right now. It's moving slowly (it's my final year of school so things are pretty busy) but it's moving surely!

Yes, during development I also got a lot of these errors. Unfortunately, I'm not exactly certain of why these errors occur. I suspect the elf2flt program is too old to handle the new kinds of relocations in gcc. I understand this is a bit of a pain for a lot of people so I'll probably end up either writing a custom program to do the conversions from ELF to bFLT when I have time.

Technically speaking, elf2flt is trying to handle most of the linking which is why it's giving all these errors. In reality, we can tell the linker to do it for us and add the --emit-relocs flag. This creates a section in the ELF file that has a list of relocations that the linker did. All we have to do is search for the R_ARM_ABS32 relocations and somehow add the base address to it at run time.

The program I am thinking of writing will call the linker to link it for us while adding the --emit-relocs flag. It will then dump the text and data section into a bFLT file and search through the list of relocs for R_ARM_ABS32 types and add them to the relocations list in the bFLT file.

Sorry for all this mess. The runtime linker might be working but the toolchain doesn't appear to

I suspect the calculator isn't able to supply enough power to both devices.