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 ... 6 7 [8] 9 10 ... 16
106
« on: January 12, 2013, 05:18:13 am »
If you're using an initrd (which needs decompression as well), it doesn't make any difference.
I'd say XZ, but do we really have to discuss about 0.5 MB (the kernel won't be much larger in the future)?
lso, in other news, I2C is working on all touchpad platforms. Now we just need a driver for the touchpad. Just a heads up, since we're using the I2C bus now, we should define a I2C driver instead of a platform driver. Can I do it? 
Sure  . I'll get cracking on the hardest device then - the NAND. 
107
« on: January 12, 2013, 03:55:24 am »
Hey everyone.
Lionel and I are having a little discussion about how the kernel should be compressed. The two methods we're looking at are: XZ (slower decompression but smaller kernel) and gzip (faster decompression but larger kernel).
XZ compressed: 1.2MB kernel, about 2-3 seconds decompression
Gzip compressed: 1.7MB kernel, about 0.5 seconds decompression
I believe that we should favor boot up speed over savings in kernel size since the Nspires have a lot of flash storage so space isn't too much of a concern. Most people are also booting Linux via USB so they don't even need to worry about having free space for initrds.
Lionel believes that we should favor kernel size over boot up speed since the extra time in boot speed is insignificant. In addition, in a embedded environment like nspires, we should be trying to save as much space as we can.
Basically, the question is: will you wait an extra 2-3 seconds on boot up to have a ~30% smaller kernel?
108
« on: January 12, 2013, 12:27:04 am »
Great!
I hope I have some time this weekend to continue working on a touchpad driver, was pretty busy last week.
Serial debugging is really good for that, the screen is way to small to read tons of lines of debugging messages..
I finally integrated OTG into the main branch so you can potentially use it for USB serial debugging. If you're interested in using it, compile the latest kernel and add cx_use_otg to your command line parameters. Also, in other news, I2C is working on all touchpad platforms. Now we just need a driver for the touchpad. Just a heads up, since we're using the I2C bus now, we should define a I2C driver instead of a platform driver.
109
« on: January 11, 2013, 07:12:00 am »
Thanks to Fabian's work on the GPIO, I got i2c working pretty quickly today. Basically this means that Touchpad support for classic Nspires will be coming very soon. The CX uses a different interface for accessing the Touchpad but support for that isn't far behind.
110
« on: January 08, 2013, 12:41:03 am »
Surprise!  Edit: Source code for OTG is at https://github.com/tangrs/linux/tree/otgIt is in a separate tree because switching to a OTG driver breaks host USB on CX.
111
« on: January 06, 2013, 04:06:49 am »
Thanks for your anwser.
Here is my script right now:
kernel linux/zImage.tns
initrd linux/initrd.tns
cmdline root=/dev/ram console=tty0
boot
I still get the error.
Hmmm. It's probably in the initrd then. Mount the initrd and edit the etc/inittab file. Comment out the line that starts with ttyAMA0:: and unmount. If you have no idea what that means, ask the person who gave you the initrd
112
« on: January 05, 2013, 07:08:13 pm »
//Oops; deleted the message above.
Just a question: did anyone ever succeeded in booting Linux on Clickpad?
Of course, it's been made on CX. I also saw it's been made on Touchpad (http://ourl.ca/17131/326297). But did anyone made it on a Clickpad?
//End of deleted message.
My friend doesn't want to downgrade his OS to 3.1 :-(
Tell him how better OS 3.1 is for Clickpads, even without Ndless.
You get much more free space, fewer bugs, faster OS*, ect...
*3.1 isn't faster than others. 3.2 just happen to be much slower in some cases.
---
I've been trying a few configs again.
So, it seems to be "quite" ok with any recent zImage found on TI-Planet and the initrd from here:
http://ourl.ca/17131;msg=266194
He referred to it as ramdisk..
The only problem left being getting "can't open /dev/ttyAMA0: no such device of address" every second or so.
I could still manage to type a few commands, and they are working OK.
Classic calculators have different serial hardware. They're accessed through tty0. Try using console=tty0
113
« on: December 21, 2012, 09:22:23 am »
I did all this already...
Cable is plugged in while still in OS mode, then booting the kernel via ll2 script (the rootdelay is set to 10). I plug my stick in when message appears and then it recognizes my hub and the stick as sda.
After serveral seconds I get the kernel panic.
I can't even mount the stick when I boot the kernel with an initrd and then plug my stick in and type 'mount /dev/sda' or something like this.
What are the specific error messages are you getting? I suspect a badly setup rootfs or root= kernel command line option.
114
« on: December 21, 2012, 04:14:59 am »
Is there a special extension you need for the usb drive? like ext*, MS-DOS or something else?
with a unix system, just copy it with dd on the drive, tripple-check your spelling, otherwise all your data will get destroyed.
the dd command formats it in the right format, I think ext2 in this case.
edit: sorry, this is just possible if the file has a .ext2 ending. othwerwise just format your stick with ext4 (or any other ext*) and copy all the data in the folder . in ther archive on the stick.
What must I write to tell linux to use a partition of my stick as swap? (it is formatted as swap)
ps: my usb power supply is finished (the circuit part). It works quite good, I just have to buy more powerful batteries (~500mAh). I can even connect my little USB HDD, one without external power supply, all power is given by the USB, in my case my circuit. I will publish pictures soon. The HDD eats up to 0.6A.
OMG: If I get a kernel panic beacuse it can't find my root fs on my stick, after a couple of minutes some text output about EHCI controllers is running over the screen until i hard reset my calc... I thought, a kernel panic would total crash the kernel and nothing will happen anymore?
Just tried my first attempts with USB booting, fails with kernel paic about no root fs... Any ideas?
-Stick properly formatted and data on it
-right files used (vogtinator's)
-Stick is recognized (as sda)
You probably need to add a rootdelay=5 to your kernel command line since you need to give the USB device time to initialize. Remember to read the Wiki section on USB host ( http://hackspire.unsads.com/wiki/index.php/Linux#USB_Host)
115
« on: December 09, 2012, 12:41:31 am »
(Find out which and what value if you want to access the LED :-P).
I'll look into this once I work out how I can enter press to test via the emulator
116
« on: December 07, 2012, 10:46:08 pm »
I just measured the outputs and inputs of some GPIOs connected to the pins on the bottom port, and it's correct.
They're even sensitive for fingertips..
The input of the pins 1 and 3 are always high, so there are indeed pullups.
But why does the touchpad not get detected? (At least not through i2cdetect)
Not sure if it'll help or not, but when I was working with the keypad driver, I noticed that any activity on the Touchpad will also cause a keypad interrupt. Read keypad.c in nspire_emu. Other than that, on the CX, the Touchpad seems to be accessed through address 0x90050000 according to a quick read of nspire_emu's source code.
117
« on: December 05, 2012, 05:55:17 pm »
Then how can I see how the OS is changing the GPIOs? Only in nspire_emu, if I compile it with custom debugging?
Simply re-enable interrupts?
Edit: As GPIOs generate only one interrupt (7) I have to use an irq_domain. But there are only 32 irq's available on the device.
Are there some kind of virtual interrupts?
IRQ domains are probably the way to go then. AFAIK, IRQ domains manage mappings over hardware to 'virtual' IRQs. If you're referring the the NR_IRQS macro, I don't exactly know the correct value for the Nspire but 32 seems to work (lol). Feel free to fiddle around with it.
118
« on: December 04, 2012, 05:42:09 pm »
No, im reading the GPIO registers with a C program started with ndless.
Ndless programs are started with interrupts off so the OS won't be able to update it.
119
« on: December 04, 2012, 12:55:57 am »
I'm trying to make sense of all this, is there a build released for touchpad models yet or not?
The source code has Touchpad support but no public build just yet. Lionel is helping to get nightly kernel builds up and running which will support all three models. Of course, in the meanwhile, you can certainly build your own kernel by downloading the source off github or ask around if someone has a build.
120
« on: December 03, 2012, 08:17:50 pm »
I'm currently testing GPIOs with ndless. The binary (input) value of all ports toggles randomly between 0x59d00bf and 0x5bdoobf.
That's probably to be expected. The pins are probably not connected to anything so it's floating. (Could also be periodically, sample rate is highest possible)
What is GPIO 21(0x020000)?
Also, the output value (0x80132d) doesn't vary at all. Isn't the touchpad connected to GPIOs 1 + 3?
The output shouldn't vary at all unless you change it. Edit: Can I use GPIOs both as input and output? Example:
GPIO1 configured as output=HIGH, connected to ground through resistor.
Can I read input=LOW?
I know you can do this with AVRs (people did this to make a cheap touch sensor - i.e. bring pin high and measure how long it actually takes to go high). Not sure with Nspires though. [/quote] Edit2: With linux the gpio input still toggles randomly.
Again, as expected from floating voltages. Should I implement an irq_chip for this? Directly setting, getting and changing direction are working. (At least the right values in the registers change)
Why not? Edit3: Could someone please test GPIOs? I don't know how.
http://dl.dropbox.com/u/105478372/zImagetest.tns
With useless i2c-gpio:
http://dl.dropbox.com/u/105478372/zImagetesti2c.tns
Best test for GPIO is the touchpad Speaking of which, should the touchpad driver be a kernel driver or a userspace daemon (pulling strings with i2c and userspace uevents)?
Pages: 1 ... 6 7 [8] 9 10 ... 16
|
Show Posts