Edit2: I compiled psplash and now we have a nice progress bar on boot:

Very nice!

Edit: Added a backlight driver for Nspire Linux so the backlight also turns off as the LCD powers off. That should save some power and not show the ugly white fading screen when the LCD turns off.

I am also planning to get a contrast driver working for the classics so we can remove the ugly /proc/contrast and /proc/backlight files.

I am also planning to get a contrast driver working for the classics so we can remove the ugly /proc/contrast and /proc/backlight files.

Sure, would be good

I wonder where the right place for /proc/adc is.

I think it's something more complicated involving the battery and/or power stuff. Not necessarily a must for the very first mainline RFC submission.

Hmmm, I'm starting to implement a CPU frequency scaling driver. At the moment, it simply reports the CPU frequency.

Now, I need some help with frequency scaling. If we assume that the base speed won't change, what would be a good way to determine a table of "safe" speeds to scale to? Should we be touching the base speed? What happens if the user overclocks the calculator? How do we ensure that AHB/CPU speeds are always within safe limits?

Any ideas?

Edit: I'll try a list of "safe" divisors for now.

The experience with the CX shows that on the CX, IMO, the AHB frequency should never be touched. The default is 66 MHz, and NAND memory corruption occurs quickly if the AHB is set to 75 MHz. 72 MHz seems to be safer, but then it's less than 10% overclocking margin.
The Clickpad & Touchpad have higher tolerance to AHB overclocking, IIRC.

It's okay if the AHB speed is slower than 66MHz right? I'm working with the values that Nover gives me and avoiding everything that's "dangerous".

The CPU warning had better not be ignored, otherwise the calculator will just crash
The problem is, a wide range of maximum tolerated CPU clock speeds have been reported. Few CX calculators can run in a stable manner above 252 MHz, but some have been reported to crash at 222 MHz - so you probably shouldn't let the driver go over 210 or 216 MHz. For the first mainline submission, and even later IMO, stability trumps squeezing the last bit of performance

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.

It's your script, theres "#boot" instead of "boot" which gives an "Unknown command" error.

Edit: "Ramdisk too large" Oops, my mistake  Use the initrd from tangrs for now