Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - tangrs

Pages: 1 2 [3] 4 5 ... 16
31
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: December 25, 2013, 02:40:45 am »
Here's the CX release of the Linux-based bootloader for rapid Linux development on TI-Nspires.

To use, install the attached image via nLaunchy and reboot. It'll boot to a screen that reads "Waiting for boot command" and your computer will register a USB serial device.

Use the following script to upload a kernel, initrd and dtb:

Code: [Select]
#!/bin/bash

set -e

if [ "$#" -ne 4 ]; then
echo "Usage: $0 kernel.img devicetree.img initrd.img /dev/serial"
exit 0
fi

mkdir -p tmp
cp -v $1 tmp/kernel.bin
cp -v $2 tmp/devicetree.bin
cp -v $3 tmp/initrd.bin
touch tmp/bootcmd

cd tmp
sz * -y -8 > $4 < $4

You'll need the lrzsz package of what ever OS you're using for this.

For now, initrds aren't supported (kexec 2.0.4 is broken for initrd loading with DTBs - nothing I can really do about this unfortunately) so you'll have to embed a rootfs into your kernel image and pass an empty file for the initrd.

Enjoy.

32
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: November 24, 2013, 11:08:18 pm »
There's no defconfig right now for the newer kernels. I usually just do a make allnoconfig and manually select the drivers I need.

Here's a quick list of options you should have

Code: [Select]
CONFIG_BLK_DEV_INITRD=y
CONFIG_ARCH_NSPIRE=y
CONFIG_AEABI=y
CONFIG_BLK_DEV_RAM=y
CONFIG_KEYBOARD_NSPIRE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_FB=y
CONFIG_FB_ARMCLCD=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_TMPFS=y


33
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: November 23, 2013, 12:25:07 am »
Hey guys, exams are finished and I can resume work on the kernel (Y)

Not much going on right now, here's a list of things I've gotten done so far:

  • Can get *either* USB peripheral or USB host mode working but no seamless switching yet
  • Device tree compatible USB driver

Also, attached is a nice treat for developers that I spent the last 48 hours hacking up. It's a nLaunch compatible OS file containing the most minimal and fast booting Linux Kernel/Initrd combination I could manage (~1.5MB) for booting Linux kernels.

That's right, a Linux OS for bootloading Linux :)

It's intended to speed up development by loading quicker than the TI-Nspire OS and automated deployment of code. It boots in seconds, also letting you download code over USB using the ZModem protocol which is a lot faster than transferring via TI's software. The new kernel and initrd is booting using Kexec. Basically, instead of going Boot1->Boot2->TI-Nspire OS->Xfer over USB->linuxloader2->Linux, you're going Boot1->Boot2/nLaunch->Minimal Linux->Xfer over USB->Linux

All the DTB and initrd is embedded in the file so nothing else is necessary. The attached OS is for Touchpad models only right now but if you're desperate to get it working on the CX, add
Code: [Select]
compatible="zevio,nspire-usb" to the device tree for the CX, compile it and hexedit it into offset 0x100 of the extracted OS file, replacing the touchpad dtb.

I'll release the configs and source code for it soon but here's the script used to upload code to the bootloader.

Code: [Select]
#!/bin/bash

set -e

if [ "$#" -ne 4 ]; then
echo "Usage: $0 kernel.img devicetree.img initrd.img /dev/serial"
exit 0
fi

mkdir -p tmp
cp -v $1 tmp/kernel.bin
cp -v $2 tmp/devicetree.bin
cp -v $3 tmp/initrd.bin
touch tmp/bootcmd

cd tmp
sz * -y -8 > $4 < $4

34
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: August 20, 2013, 05:53:19 am »
Thanks everyone for your help!

It seems the only model I have to worry about are the non-removable Clickpad CAS keyboards.

35
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 20, 2013, 10:42:52 pm »
Hi,

I'm adding hot swap support to the keypad driver. Could a couple of people test this with various keypads and report back whether it detected it correctly? If you could also include your keypad type/s and raw ADC value in your replies, it would be appreciated.

Cheers,

36
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 20, 2013, 04:34:23 am »
Could somebody please help me figure out why I cannot use the larger rootfs files. I don't want to have to make an entire thread for it.

The larger rootfs is meant to be loaded onto a USB drive and booted from there. There's not enough RAM for it to work as an initrd.

Question: If the HP Prime is eventually hackable ("HelPless" or "HPless" instead of "Ndless"?), do you have any plan to port this to that calc since it has a similar processor?

I don't have plans to get a HP Prime but it does sound interesting. If there's documentation, I'm happy to give it a shot.

37
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 05, 2013, 11:26:45 pm »
Can I git the kernel source tree and just compile the kernel for Nspire, or is it more difficult than that?

Yep, just equip yourself with an cross compiler and a copy of the latest kernel sources and you're good to go :P

38
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 05, 2013, 11:22:03 pm »
Just a heads up that minimal kernel support for Nspire CX has been merged into mainline today. For devs, this means you can clone Linus's repo and build a Nspire CX kernel :) We'll also be seeing more patches for the Nspire come up over the next week or so.

Unfortunately, the last patch required for the classic models missed the merge window so we probably won't see mainline support for the classic models until next round :(

39
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: June 13, 2013, 02:50:25 am »
I hope that all of the initial patches which tangrs submitted to the mainline Linux kernel wll be picked up for Linux 3.11 :)
At least two of them have already been picked up by tree maintainers.

We're just waiting on three more patches:

  • Platform code
  • Platform DTBs
  • Classic irqchip driver

Everything else has been pulled into their respective maintainer trees.

40
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: May 25, 2013, 08:30:51 am »
Hi,

Just dropping in to say that this project is not dead! Despite the lack of visible activity, progress is being made. This post will hopefully bring everyone up to date about what's been happening.

Right now, here are some of the things that has happened or is happening now.

  • Getting TI-Nspire support into mainline
  • Rewriting the TI-Nspire port to use device trees
  • Added support for device tree loading in linuxloader2
  • Debugging a very annoying and well hidden bootloader bug which has stumped us for weeks (shout outs to Vogtinator)
  • PTT LEDs finally unlocked

Mainline

We're in the process of getting TI-Nspire support into the mainline kernel. If this is successful, it'll make maintaining the kernel much easier and also have better code.

To start off with, we're just submitting the absolute basic platform code needed to boot Linux. It doesn't have support for any other hardware than the interrupt controller, timer, clock and keypad.
Once the base kernel is mainlined, we'll begin porting hardware support in again.

Device tree rewrite

Part of getting TI-Nspire support into the mainline kernel involved switching to using device trees. This means we can effectively use a file to describe our hardware configuration and we don't have to keep chucking code at the kernel for every new hardware supported which is always nice.

Unfortunately, it was easier to just begin writing the whole platform from scratch than fix up our old code. This was exactly what we did.

The old code was left as-is which is why you're not seeing any new updates in nightly builds.

Device tree support in linuxloader2

Obviously, to boot the newer, device tree kernels, the bootloader needed to be updated to support loading device tree blobs. It turned out adding support for it was a lot easier than originally anticipated. The first version did not have support for initrds and command line in DT kernels.

Support for it quickly improved and, thanks largely to Vogtinator's contributions, we had a initrd loading and command line loading working. There was a little confusion with 'initrds' and 'ramdisks' which caused the initial version with support for initrds to not work properly. This was due to my bad variable naming in the bootloader code which did not clearly differentiate between the two.

Just when we thought we had a good bootloader going, Vogtinator and I started noticing random things happening in the kernel. Drivers weren't being loaded properly, the LCD driver would work about fifty percent of the time. At the time I suspected something was broken in the kernel and a race condition was occurring. We were lucky to even make it to a shell. For the next couple of weeks, we were pulling hairs out trying to work out what was wrong (at least I was :P). Every now and then, someone would come up with a 'fix' that'd work for about an hour and break again. Other times, we'd blame the device tree handling code. Sure, we looked at the bootloader, Vogtinator shuffled some things around but the same things kept happening.

I assumed that if the device tree handling code was truly broken, there would surely be a kernel patch fixing it very soon so I waited to see if anyone else reported a similar problem. A few more weeks went by and the merge window opened again and nothing showed up. I started to suspect the bootloader again since it was unlikely a bug in the kernel since nobody has stumbled on it and went back to the ARM booting guide. A bit of trial and error and I had something that would now work 100% of the time! It was probably the bootloader's fault after all. I quickly sent a patch over to Vogtinator and voila, it was confirmed we had fixed the bug!

PTT LEDs finally unlocked

On the side, I was also researching how to unlock the PTT LEDs. A few months ago, I had partial success and managed to unlock one register (which was enough to control the LED). Now, the LED interface is fully cracked and unlocked - we can use the LED again!

The catch is, we can't unlock the LED in the TI-Nspire OS because it resets if it detects the LEDs have been unlocked. However, that doesn't bother us since we're booting Linux :) Being able to use the LEDs is really awesome for Linux since we can now have activity indicators for various things in the kernel (like NAND access)

Thanks

I don't think I've properly credited the few people who've contributed a lot to the project. Cheers to:

  • Lionel Debroux - for kindly hosting nightly builds of the kernel, pressuring me to mainline the kernel and providing assistance in managing the project
  • Vogtinator - for all the work he has contributed to linuxloader2, kernel and TI-Nspire documentation
  • All the end users - for your support and being guinea pigs testing the kernel for us

So, that's the state of Linux on TI-Nspire right now. It's moving slowly (it's my final year of school so things are pretty busy) but it's moving surely!

41
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: April 05, 2013, 08:29:43 pm »
As to the USB issue, did you try the workaround on the Wiki? There's a bit of weirdness with USB host.

http://hackspire.unsads.com/wiki/index.php/Linux#USB

42
Ndless / Re: Ndless bFLT loader
« on: April 01, 2013, 06:22:47 pm »
Yes, during development I also got a lot of these errors. Unfortunately, I'm not exactly certain of why these errors occur. I suspect the elf2flt program is too old to handle the new kinds of relocations in gcc. I understand this is a bit of a pain for a lot of people so I'll probably end up either writing a custom program to do the conversions from ELF to bFLT when I have time.

Technically speaking, elf2flt is trying to handle most of the linking which is why it's giving all these errors. In reality, we can tell the linker to do it for us and add the --emit-relocs flag. This creates a section in the ELF file that has a list of relocations that the linker did. All we have to do is search for the R_ARM_ABS32 relocations and somehow add the base address to it at run time.

The program I am thinking of writing will call the linker to link it for us while adding the --emit-relocs flag. It will then dump the text and data section into a bFLT file and search through the list of relocs for R_ARM_ABS32 types and add them to the relocations list in the bFLT file.

Sorry for all this mess. The runtime linker might be working but the toolchain doesn't appear to :(

43
TI-Nspire / LED protection in TI-Nspires partially cracked
« on: March 17, 2013, 06:54:46 am »
Quote from: somewhere in TI's PTT documentation
The flashing LED is hardware-secure and cannot be impacted by coded software.

Lies! :P



At the moment, it only responds to writes to 90110b00 though - flashing still doesn't work. It probably needs more researching.

This one really had me stumped for a while. TI hid this one well. I've spent almost a year behind the scenes, on and off with this one.

A bit too long considering the final answer to the puzzle was actually pretty short :)

As to releases, I don't think I will until I'm convinced that this won't piss off TI. My interests in this was as a puzzle and its potential uses in the Linux kernel (as an indicator of hard drive activity for example) but somehow, I don't think TI thinks the same way.

44
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: February 25, 2013, 03:30:02 pm »
I suspect the calculator isn't able to supply enough power to both devices.

45
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: February 24, 2013, 04:25:24 pm »
Pretty much all packages available for ARM debian are available for the calculators.

Pages: 1 2 [3] 4 5 ... 16