Author Topic: Prime Linux (Read 1741 times)

Hooloowalrus · « **on:** August 31, 2017, 03:21:09 am »

Linux is coming to the Prime.
It should have been there a long time; the chip it runs on, the S3C2416, has been supported for a long time. Recently gaining access to tools for jtag, I decided I would go and connect things up, not realizing that the newer revision of Prime didn't even have jatag pins broken out on the front of the board. I bought a prime, and started working.

Tonight, I got up and running with a shell. There's nothing else here but the shell, actually, and many things don't work. But I got the LCD and serial port working, which is easily enough to test with.

Here's a picture of the shell up and running on tty0:

The sources can be found on my github:
linux
ripem build with loader
qemu for Prime
Since I don't have a good setup for the initramfs running right now, I'm going to figure out how to get buildroot up and running. As long as I'm not too busy with school, I'll figure out how to make a keyboard driver and get the rest of the theoretically working platform drivers (usb, touchscreen) working. If anyone wants to help, go ahead!

x-posting to Omni and Cemetech

Juju · « **Reply #1 on:** August 31, 2017, 03:31:29 am »

Oooh, that's awesome ^_^

xlibman · « **Reply #2 on:** August 31, 2017, 03:35:27 am »

Great news @Hooloowalrus . I'm glad to see some HP Prime development again, especially here or other TI websites where user reception for such HP Prime project was good. Please, though, don't send this calc in space like your previous HP Prime, though.

pimathbrainiac · « **Reply #3 on:** August 31, 2017, 05:26:02 am »

It was only a matter of time! I like what I see!

That feeling when there isn't a gcc port for ez80 so you can't get TI-80+ CE linux

Jean-Baptiste Boric · « **Reply #4 on:** August 31, 2017, 04:39:18 pm »

Nice!

Looking at the code, my only remark for now would be to use a device tree instead of ATAGS. I don't think it's possible to upstream new non-device tree ARM platforms for Linux anymore.

Hooloowalrus · « **Reply #5 on:** August 31, 2017, 07:16:46 pm »

I wanted to get everything working before starting to mess with DTBs, as someone else working on a similar system, http://blog.weinigel.se/2016/05/07/linux-on-sds7102.html and said that it did not work. I think DT support is worth working on, but I'm not sure if it's my first priority.

Adriweb · « **Reply #6 on:** August 31, 2017, 11:04:35 pm »

Great job !
This also deserves a cross-post on TI-Planet

(Yes, posting in English is perfectly fine)

Edit: and yep, upstreaming the work would be nice, it would also be the 2nd graphing calculator (AFAIK) to be there, after the Nspire (CX)

Lionel Debroux · « **Reply #7 on:** September 01, 2017, 05:48:49 am »

Fantastic job, congratulations

We knew since the beginning that it would be possible, but nobody was sufficiently interested in doing that work - until now.
Good thing to be posting on this board as well.

Mainlining the port is an absolute must for long-term maintenance, and for a 32-bit ARM9 platform, this does indeed require using DT: it already was a requirement when the Nspire Linux port was mainlined years ago, as Arnd Bergmann indicated when replying to https://lkml.org/lkml/2013/4/4/113. The tools associated to Nspire Linux may save you some time with that task: there's a DTB loader in there.
It's alright to make a bit more progress on a non-DT kernel for now, but you'll soon be spending time on code you'll have to redo for using DT, so you shouldn't wait much

Hooloowalrus · « **Reply #8 on:** September 02, 2017, 12:15:24 am »

I updated some stuff, so now loading DT and stuff should work. It appears as if the s3c framebuffer driver doesn't have any DT code in it at all, so I'm going to figure that part out before I start writing drivers of my own, like for the keypad.