|TuxScreen on SourceForge||TuxScreen CVS||search the Wiki|
|Browsing -> Wiki -> Users -> [DerekMulcahy]|
|edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki||create a new user or login|
Back to application land. Compiled QTE-3.0.0, having decided that Java is a not ready for prime time on the ARM. Made a simple change to QPE to support the touchscreen, available if anyone wants it. Tomorrow I will begin to learn QT and write my phone app for delivery at Xmas.
Serial flash driver works, tracked down the data corruption, I neglected to wait for the fifo to write all the bytes down to the flash. Next step checking it with JFFS2. Not much progress on 40M patch, running into weird problems with linux when trying to load kernel at 2M chunk at 0xC0300000.
Woohoo, 32M working at 0xd0000000. Just needed to track down all the dependencies. Much easier with DaveAnders and Russ's advice about using printascii() for printing early in the boot sequence. Preparing patches for later today. Bootloader memory setup is still required.
More progress of sorts on 32M memory issue,decided to load kernel at 0xd0000000 as this address is valid in 16M and 40M memory configs (sorry 8M). Problem is it hangs. Advised by Russ and DaveAnders to use printascii() to debug. Unfortunately this had been changed to use UART1 for output. As this is our IR keyboard it was not useful for debug. Hmmm, all hair pulled out (photos to prove it) but progress is now being made. Happy Halloween.
Posted a provisional patch for the serial flash MTD driver today. It supports reading and writing using polled io and delays. I'm running into problems when trying to write a JFFS2 filesystem to it but that is almost certainly due to having missed something obvious. This thing currently shares 50% of the code with the DSP driver and hence, for the moment, lives inside of wheaties.c.
Progress, of sorts, with the 32M SODIMM issue, altering the MDCNFG register on the SA-1100 to use 12x10 and 12x8 row/col setup causes the memory to be recognised. Bad news is that under this configuration the onboard memory is fragmented into 8 x 1M pages, which are mapped on 4M boundaries. Linux needs contiguous memory so we are royally hosed. Avenues of investigation include hacking blob to remap the memory, loading the kernel at a different address or trying to tweak the memory control registers to do the right thing.
Another woohoo. Reading from the serial flash. 2048x264byte pages of non-volatile storage accessed across a 1 bit interface, that's a cool 4,325,376 bits in all it's bit twiddling glory. The interface to the serial flash uses the SSP bus on the SA-1100, which has fifos so it's not so shabby at all.
Reimplemented wheaties driver using interrupts, pretty lean mean driver.Driver has a spinlock around most of it's vital parts. Needs to be tinkered with. All of the most bogus delays have been removed. Shipped it out to a select team of gurus who are doing untold crazy things to it already.
A big day, after three days steady hacking on the DSP have managed to send commands and receive responses. Promised to complete a device driver by tomorrow. The SPI interface is pretty gross so no complaining about the awful driver code and the ludicrous loops and udelay() calls.
Xfbdev from the familiar distribution works great. One funny quirk starting X from /etc/inittab fails to initialise the color map IF the tty field in the inittab is not set to null, weird.
I have a patch for the kernel to allow X to power down the backlight (which works fine now) and a standalone touchscreen calibration program if anyone should need them.
the touchscreen works! We were on the right track, just needed to reset the UCB1200. Information was gleaned from shannon.h. If that is the only serious TuxScreen specific documentation then it's amazing what has been done so far. Not sure that the backlight code is working though, doesn't seem to alter things, but it doesn't hang.
Writing a little app to flip the coords and calibrate the touchscreen, it is to be called tuxctl.
7th October 2001
Progress, of sorts, on TouchScreen/Backlight problems. On my TuxScreen the backlight hangs in ucb1200_sa1100.c:sa1100_mcp_read_codec(). It hangs because the read request is never completing. Completion is indicated by the MCSR_CRC bit being set in the Ser4MCSR register on the ARM. This doesn't happen. The code is
Ser4MCDR2 = ((addr & 0xf) << FShft(MCDR2_ADD)) | MCDR2_Rd; while (!(Ser4MCSR & MCSR_CRC)); // LOOPS FOREVER return Ser4MCDR2 & 0xffff;
Funnily enough the code in sa1100_mcp_write_codec() is very similar and this executes fine. It confirms transfer completion using the MCSR_CWC bit and this sets and resets. No amount of proding will get the damn MSCR_CRC bit (0x2000) to set.
A possible indicator of what the problem could be the state of Ser4MCSR when the read_codec() routine is entered, this indicates that a write is pending (0x1505 for Ser4MCSR, 0x1000 == MCSR_CWC).
4th October 2001
Feeble attempt to track down the TouchScreen not working. Added debug to ucb2100_ts.c, inserted handler on all 16 UCB1200_IRQ(x) interrupts. Nothing happens when screen is touched whilst running tuxcal.
1st October 2001
Downloaded familiar from handhelds.org and ran Tcl/Tk mounted over NFS and displaying on my workstation. It worked, not fast as this is via PPP. Would be more interesting if Tk had a native port without needing X.
28th September 2001
Having fun building stuff to put on the TuxScreen. Compiled pppd and am using it via the serial port until my network card arrives. Soldered together a JTAG clone from parts bought from Radio Shack. Happy to assist if someone else wants to do the same.
Software I compiled and running on TuxScreen
Most required just minor tweaks.
|Content of these pages are owned and copyrighted by the poster.|