I've changed it so the classic nspires uses 8bpp. I'll push it when X is working on it.

@Vogtinator, I've been researching the meanings behind clcdfb_check's (5+1) magic numbers and this is what I got. Does this mean we can simply put hsync_len as 6 (and change left_margin and right_margin as appropriate as well)? It doesn't seem to be panel specific so maybe we don't have to set it to the same settings the nspire OS uses.

Also, regarding X being broken, did you enable the FBDEV driver in buildroot? The config option is BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBDEV When I use the FBDEV driver, I found that clcdfb_check isn't even called at all so even hsync_len values less than 6 will be accepted (possibly because FBDEV doesn't try to change the video mode).

Basically, should we just simply chuck the minimum value of 6 into hsync_len, left_margin and right_margin?

Edit: Woo!

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.

Hi
I have a question : what are the limitations (unless time) to have Nspire linux to work with the NAND filesystem ?
We know it uses Datalight Reliance v2.10 Build 1150 and Datalight FlashFX Pro v3.00 Build 1358 and after some research on them I found that it has "somewhere" a support for bootstrapping linux : http://embedded-computing.com/white-papers/white-flash-flashfx-tera-reliance-nitro/

I cannot find sources (even the "free 30-days source demo" doesn't work when logged in), but maybe already packaged libs exist for Linux running on ARM9 ?

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

So, would a basic NAND driver potentially fix the issue with partially corrupting the NAND on reboot? (My CX CAS often freezes on reboot or it reboots with a non-functional touchpad, very weird). I think I saw a whitepaper on Datalight's site for using their NAND in linux (im probably looking at the wrong thing). Honestly, the quality of this NAND seems pretty low overall (seems prone to corruption/bad blocks, etc.), so partitioning could cause more problems.

Even if dual boot was possible (maybe a new bootloader could be written to boot1, or those first 128kb where the logo is stored), it would be extremely difficult to write/set up.

Edit: Nice find, Vogtinator, someone should save that before they realize their mistake.

You would have to load boot2 in memory, and to its specific address. I don't think Linux will like that^^.

Well, why not then. You also have to uncompress it.
And isn't that a problem is the boot2 starts writing in interrupt register/ sets the screen buffer, ect...?

Lots of things to patch...

Edit: http://ftp.icpdas.com/pub/beta_version/WinPac-8000/flashfx/dcl/common/loader/reliance/dlrelcore.h
Edit2: http://ftp.icpdas.com/pub/beta_version/WinPac-8000/flashfx/doc/ Someone forgot to make a .htaccess xD

I hate you so much :p