Why should we need to reverse-engineer it?
We have the source code! (And it works, could confirm it with an hexeditor)

Most of the code is obfuscated though and I'm still unsure about the copyright issues involved. It could be possible that the filesystem is patented.

Anyhow, I was talking about reversing the OS for the NAND driver.

There's two things we need to solve for NAND accesses to work. First is to actually get access to the NAND (i.e. get a driver working) and second is to get it to work with a filesystem of some sort.

At the moment, we don't even have a driver for the NAND controller yet (the PL350 is really weird to control). In fact, this is the main limitation that's holding us back - nobody really knows how to interface with the NAND controller.

I have also considered the filesystem issue where there's no public driver for the Datalight filesystem and FlashFX. Unfortunately, we'll probably have to give up being able to access those filesystems.

The plan I have in my head is to try and 'partition' the NAND to divide some space between the Nspire OS and Linux - each to their own filesystems. We could probably find entry points to certain functions in boot2 or the Nspire OS to format the flash and trick them into believing we have less flash than we actually have. That way we could probably have some flash unused at the end that Linux could utilise.

Failing that, we could probably modify nLaunch in a way to load the kernel directly from flash and have the whole NAND to ourselves (save the pages required by the booting process). Obviously, if we use this method, the Nspire OS will not be able to exist so it'd be a Linux-only calculator (whether that's for the better or worse hehe).

Anyhow, no point discussing all that when we don't even have a driver yet. And writing a NAND driver isn't to be taken lightly, it's a notch harder than writing a keypad driver for example (to say the least). I still don't get how the PL350 in the CX works

Yes, it is. (hopefully)

I didn't test x, I used links -g (directfb) which printed
"current mode not upported".
It works only if I return 0 in clcdfb_check.
That's exactly the same error mssage we had earlier.

I changed hsync_len to be 6 so it should pass the clcdfb_check tests. Can you pull the latest changes and check that it actually worked?

With the other kernel, initrd and loader, every time I connected my Nspire to my PC the calculator would show a message saying a USB connection was made and the computer would recognize it as a Gadget Serial and use the corresponding driver. I was able to establish a serial connection using putty, even tough the console was always black (idk if it was suposed to show something but at least I know it was connected).
This time the calculator shows nothing when connected to my PC and the computer is unable to recognise it, calling it Unknown Device. I'm also unable to use putty with this kernel.
BTW, linux logo is still there, I'm using the expanded cfg kernel provided in the nspire linux builds homepage.

Which kernel did it work with and which did it not work? Did you connect any USB host devices to it beforehand?

To get a shell on the Gadget Serial device through putty, you need Nspire Linux to attach a shell to /dev/ttyGS0

On my Touchpad, when I use the defconfig kernel, tiny buildroot ramdisk, and ramdisk script from tiplanet.org/nspire-linux-builds, I get a kernel panic. What am I doing wrong? Can anybody help?

What does the kernel panic message say?

Edit: Does the kernel seem to work correctly after the panic?

The contoller http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#C0000000_-_LCD_controller
Supports 8 bpp. Maybe just use 8bpp instead of 4bpp?

The controller might support it but the panel doesn't. I've already tried

Edit: unless I'm missing something... Was it ever possible to use 8bpp in Nspire OS? Linux renders the screen weirdly when I try to use 8bpp mode.

Edit2: Just had an epiphany. It is most likely possible after all. I made a wrong conclusion I'll give it a whirl again tomorrow.

Why build in such a limitation? just make sure there's a warning somewhere, and make the default lower. Ideally, the default would be normal, so new users can't blame their problems on it.

Sounds good. I'll only include frequencies that Nover doesn't report as dangerous.

Edit: Implemented a simple cpufreq driver. It can only scale between two frequencies though: half of base freq and 1/4 of base freq. It's limited because we can't touch the AHB speed (or else, drivers relying on the AHB and APB clocks will be all messed up) unless we notify the drivers of the change. I'm still looking into it.