Sorry, does this allow you to run linux programs?

Yep.

It's as Lionel said. Once USB host works, things will get interesting very quickly (easier said than done though )

I understand the boot loader is confusing.

The best way is to write a boot script to avoid typing everything in all the time. Copy and paste the following into a file, name it something.ll2.tns and copy it to your calculator. Make sure you have ext.ll2=linuxloader2 in your ndless.cfg and you can just run the script every time you need to boot Linux. This script assumes your kernel and initrd are all in a folder called linux

kernel linux/zImage.tns
initrd linux/initrd.tns
cmdline debug root=/dev/ram console=tty0 console=ttyAMA0,115200n8
boot

(there's a bug in the command line parsing so ensure you have a newline after boot)

I've also attached the latest development kernel and ramdisk. As usual, run at your own risk

There is a generic EHCI platform driver which is what I'm using at the moment. Unfortunately that doesn't work well with the OTG controller since the generic driver was made for host-only controllers.

As of yet, I haven't found a way to configure the controller in a way which to completely disable device mode and become host-only which somewhat complicates things.

I've made a boring vid that can be found at

&feature=youtu.be .

Also Tangrs, sometimes boot halts just after keypad initialization. It appears to occur at random, although I've a feeling it might have to do with me (accidentally) pressing a key sometimes after it started to boot. Not sure if that's even possible though ..

It might be related to touching the touchpad before the driver had a chance to init.

Quote

Just a quick reminder that there's a 4MB soft limit for RAM disks. Make sure the final image is less than that until I rework the bootloader to lift it.

ACK
It's easy to reach 8 MB without even attempting to add an X server + its libraries.

Hmmmm. If you get the source for the bootloader you could try changing MAX_RAMDISK_SIZE to something higher. But I can't guarantee it'll work without hitches since it might overwrite the bootloader code.

The solution is to relocate the bootloader itself into SRAM or somewhere out of the way before loading. That way, the max ramdisk size is limited by the amount of physical memory. I'll get the done soon

Edit: Random thoughts: snes9x SDL on Linux on CX?

Attached is a .config for buildroot 2012.08, which yields bzip2'ed rootfs, binutils 2.22, GCC 4.7.1 with C++ support, and several extra goodies such as, but not limited to, lua / luac / luajit, less, nano for simple text edition, SDL (with framebuffer support, sdl_gfx, sdl_image with BMP, JPEG and PNG support), expat, libusb, minicom.

Needless to say, the size of the rootfs raised a bit, to 7.2 MB uncompressed and 2.6 MB bzip2'ed; it can be reduced to ~5 MB uncompressed by disabling several bits:

Just a quick reminder that there's a 4MB soft limit for RAM disks. Make sure the final image is less than that until I rework the bootloader to lift it.

Good news and bad news!

Good news is that I now have a working userspace and rebooting has been fixed as well. I also just finished writing a keypad driver but it weirdly freezes sometimes for no reason.

Bad news is that I just realised how crap my code is. I read up on kernel coding conventions and my copy-pasta code (yes, most of the porting was just copying and adapting existing code) breaks quite a lot of it

Oh well. My excuse is "I'll fix it up later"

Anyhow, enjoy the demonstration video:

what o.o
do you mean you are making linux for the TI-nspire?

Yep. Well hopefully

Wow awesome o_O
Coming from such a talented developer as you are, you will surely get some more people interested and I truly hope this is going to be a great step towards ... a new world ?

(also, you should modify the topic title to make it more attractive )


EDIT : cross-posted/newsed on tiplanet

btw tangrs : you're using XCode for nspire dev too ?

No, I usually just use a simple text editor

Quote from: aeTIos on October 02, 2012, 06:40:50 am

So any chances that this will be available for the non-cas ever?

I believe that's not a problem
(However, CX is probably a pre-requisite)

It's CX only right now because that's the only hardware I have right now to test on. I've found that the nspire emulator can't emulate some of the instructions Linux uses (especially to do with caches) so I actually need real devices to test on.

It is definitely possible to make it work on the older calculators - there's no reason why it wouldn't work. Linux only needs ~4MB of RAM which even the old calculators have plenty of.

Extremely interesting
Of course you should upload the source code (of the kernel, device tree definitions, U-Boot, etc.) somewhere in public, tangrs

Note that a Linux port for the Clickpad series would be even much more interesting than a port for the CX series, because on the Clickpad series, it is certainly possible to install Linux permanently (because it is definitely possible to change the contents of the boot1), and thereby be completely free of whatever lockdown TI will try - and fail, as usual - to put forth (instead of embracing developers and making its calculator more useful as a result)

And indeed, CAS vs. non-CAS (especially on the CX, which does not have interchangeable keyboards) is, for all practical purposes, only a difference of several bits in the ASIC ("CAS bit" and two leading hex digits of the product ID), as shown by RunOS (never released, in 2010) and OSLauncher (independently reimplemented, and released, in 2011).

Alright. In that case, I'll post up sources some time tonight - but beware! I'm new to kernel developing and the code is quite messy to say the least.


Edit: Added links to source code