Subject: [E3-hacking] Support status update

From: Janusz Krzysztofik <[email-masked]>
Date: Mon, 17 May 2010 22:33:49 +0200

Hi,

As linux-2.6.34 is out, a few words on what's new regarding our E3's.

Modem support and dependant audio mixer functionality, that got broken in 
2.6.33, have been corrected and should work again.

Contrast control has been added (not extremely usefull, but just for 
completeness). You should be able to play with it by writing 
to /sys/class/lcd/omapfb/contrast and /sys/class/lcd/omapfb/lcd_power. 
Unfortunatelly, I failed to get the updated ams_delta_defconfig included, so 
you have to select this manually for now:

	Device Drivers  --->
	  Graphics support  --->
	    [*] Backlight & LCD device support  --->
	      <*>   Lowlevel LCD controls

For the same reason, you may have to make more corrections to the default 
configuration if you would still like to use the new kernel together with old 
installation tools, otherwise the resulting uImage would probably be too big. 
Try these changes that got accepted too late for inclusion:

	General setup  --->
	  RCU Subsystem  --->
	    RCU Implementation  --->
	      (X) Preemptable tree-based hierarchical RCU

	[*] Enable the block layer  --->
	  [ ]   Support for large (2TB+) block devices and files

	Kernel hacking  --->
	  [ ] Verbose BUG() reporting (adds 70K)

That's all for 2.6.34. The long awaited external keyboard support is already 
present in linux-omap and should appear in mainline as soon as 2.6.35-rc1 is 
out.

BTW, my 12-bit framebuffer display support has been accepted and included in 
mplayer svn revision 31139 on May 6th. Using it, I can enjoy a prescaled 
422x316 5fps MSMPEG-4 encoded live video stream playing fluently in 
fullscreen mode on my E3 display.

Thanks,
Janusz

---

From: Ralph Corderoy <[email-masked]>
Date: Tue, 18 May 2010 12:27:54 +0100

Hi Janusz,

> BTW, my 12-bit framebuffer display support has been accepted and
> included in mplayer svn revision 31139 on May 6th. Using it, I can
> enjoy a prescaled 422x316 5fps MSMPEG-4 encoded live video stream
> playing fluently in fullscreen mode on my E3 display.

This is all excellent news.  Thanks for your hard work.

Cheers,
Ralph.

---

From: Antony Stone <[email-masked]>
Date: Tue, 18 May 2010 13:37:12 +0200

> This is all excellent news.  Thanks for your hard work.

Indeed, and thank you particularly for posting here to tell us about the 
current state of the kernel drivers and hardware functionality.

It's really good, not only to know that such good progress is being made, but 
also to see it presented here where we can see what has happened.

Well done, and thank you.

Antony.

-- 
Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

                                                     Please reply to the list;
                                                           please don't CC me.

---

From: Janusz Krzysztofik <[email-masked]>
Date: Tue, 18 May 2010 20:24:12 +0200

Tuesday 18 May 2010 13:37:12 Antony Stone wrote:
> It's really good, not only to know that such good progress is being made,
> but also to see it presented here where we can see what has happened.

It's good to know there are still people over there who are interested ;).

One more information: before the 12-bit display support has been added to 
mplayer, I managed to get necessary changes included in a widely used ffmpeg 
video library. Thus, it should be now relatively easy to extend 12-bit 
display support to other ffmpeg based media players / media i/o libraries, 
like vlc or libxine, if someone is interested.

Thanks,
Janusz

---

From: David Given <[email-masked]>
Date: Tue, 18 May 2010 20:05:14 +0100

On 18/05/10 19:24, Janusz Krzysztofik wrote:
[...]
> It's good to know there are still people over there who are interested ;).

I'm definitely still interested --- I even have a Killer App for my
emailer in mind: console and modem for my SheevaPlug.

Unfrotunately something's gone a bit weird with my setup. I seem to get
the first half of the PBL boot signature but not the second half. The
lights all flash correctly so I don't think the device is fried, but I
haven't gotten around to rebuilding the cable yet to try and figure out
what's going on.

It's good to see work being done on the kernel; thank-you for all the
hard work! Is there anything left to do, or is all the hardware supported?

- -- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL

---

From: Janusz Krzysztofik <[email-masked]>
Date: Wed, 19 May 2010 20:53:19 +0200

> hard work! Is there anything left to do, or is all the hardware supported?

Not all yet.

For completness of the device primary application, ie. video phone, camera 
support is still missing. I have plans to look at it.

I'm not sure what smart card interface could we use for if ever supported. 
Removable storage perhaps? That would make sense to protect internal flash 
from getting weared out if used not only as a root filesystem, that can be 
mounted readonly, but as a temporary non-volatile storage. Other similiar 
purpose could be storing unit specifi configuration data, like hostname etc. 
After all, it would depend on available capacity of a smart card.

Of course, one can use an USB stick as an external flash memory, but I prefere 
plugging a signle bluetooth adapter there in. Having it running, I've already 
arranged for LAN access, and can imagine extending its usage further with 
things like direct internet access, wireless headset support, mobile SIM 
access, printing, wireless keyboard/mouse, etc., etc., all at the same time 
without fiddling with several USB adapters or an external USB hub.

Getting DSP core supported seems most problematic. There was an effort, 
code name DSP Gateway, but has been abandoned in favour of a new project, 
DSP Bridge. Unfortunately, the new code seems lacking OMAP1 support, only 
OMAP2/3/4's work.

Last, the dock-it port. I have no single idea what we could do about it.

Thanks,
Janusz

---

From: David Given <[email-masked]>
Date: Wed, 19 May 2010 20:47:14 +0100

On 19/05/10 19:53, Janusz Krzysztofik wrote:
[...]
> Removable storage perhaps?

That's an intriguing idea. ISO7816-3 says:

http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx

...that the clock rate defaults to 9600 b/s. OTOH, depending on how you
read the excruciating spec, it may be possible to increase it to either
54 kb/s or 860 kb/s, which correspond to 5 kB/s and 90 kB/s after
framing. About twice floppy disk speed...

Does the E3's smartcard reader support this? Is it flexible enough to
support any of the weirder smartcard protocols which use the two aux
pads to turn the whole thing into an MMC or USB device?

[...]
> DSP Bridge. Unfortunately, the new code seems lacking OMAP1 support, only 

I had a quick look a while back but found that doing anything with OMAP
was hampered by the total absence of free tools. I don't know if that's
still the case.

> Last, the dock-it port. I have no single idea what we could do about it.

I have a Dock-It. It's possibly the most stupid computer I've ever
owned. I suspect the most useful thing to do with the Dock-It port is to
keep pencil and paper in it.

(Is the Dock-It protocol known?)

- --

---

From: Matt Callow <[email-masked]>
Date: Thu, 20 May 2010 10:46:46 +1000

On 20 May 2010 05:47, David Given <dg@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
I think the E3 card reader is just done in software - bitbang on a
couple of GPIO pins.  So I think it should be possible to use if for
SPI/MMC. I think USB is less likely

Matt

---

From: David Given <[email-masked]>
Date: Thu, 20 May 2010 17:36:50 +0100

On 20/05/10 01:46, Matt Callow wrote:
[...]
> SPI/MMC. I think USB is less likely

Bitbanging MMC is pretty grim. Although, now we have the FIQ handler
less grim than it was...

Can one still get mass storage smartcards? The only ones I ever heard
about were M-Systems' MegaSIM, which then became SanDisk's SIM5000, and
then vanished completely.

And speaking of SPI --- isn't there a proper SPI interface somewhere
inside? Like, one with a FIFO? Given that all SD and MMC cards support
SPI, could this be used as an easy mass storage option (and hopefully a
faster one than the smartcard interface).

- --