|
Post by Spanner on Apr 18, 2019 11:59:06 GMT
Janusz Krzysztofik Mon, 17 May 2010 13:35:30 -0700
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
|
|
|
Post by Spanner on Apr 18, 2019 11:59:27 GMT
Ralph Corderoy Tue, 18 May 2010 04:28:40 -0700
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.
|
|
|
Post by Spanner on Apr 18, 2019 11:59:48 GMT
Antony Stone Tue, 18 May 2010 04:53:12 -0700
On Tuesday 18 May 2010 at 13:27, Ralph Corderoy wrote:
> 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.
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
|
|
|
Post by Spanner on Apr 18, 2019 12:00:20 GMT
Janusz Krzysztofik Tue, 18 May 2010 11:25:55 -0700 Tuesday 18 May 2010 13:37:12 Antony Stone wrote: > On Tuesday 18 May 2010 at 13:27, Ralph Corderoy wrote: > > 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. > > 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. 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 > Well done, and thank you. > > > Antony.
|
|
|
Post by Spanner on Apr 18, 2019 12:00:39 GMT
David Given Tue, 18 May 2010 12:36:46 -0700 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - -- ┌─── dg@cowlark.com ───── www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - enigmail.mozdev.org/iD8DBQFL8uTqf9E0noFvlzgRAjt1AKDRwMczYC8m+nUX2/pMhLhd3jaBAwCfQx1N RIjTTu0ICr3GqV4xm2kKeCw= =lZRb -----END PGP SIGNATURE-----
|
|
|
Post by Spanner on Apr 18, 2019 12:01:52 GMT
Janusz Krzysztofik Wed, 19 May 2010 11:54:59 -0700 Tuesday 18 May 2010 21:05:14 David Given wrote: > 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? 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
|
|
|
Post by Spanner on Apr 18, 2019 12:02:25 GMT
David Given Wed, 19 May 2010 12:48:08 -0700 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/05/10 19:53, Janusz Krzysztofik wrote: [...] > I'm not sure what smart card interface could we use for if ever supported. > Removable storage perhaps? That's an intriguing idea. ISO7816-3 says: 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? [...] > 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. 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?) - -- ┌─── dg@cowlark.com ───── www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
|
|
|
Post by Spanner on Apr 18, 2019 12:02:50 GMT
Matt Callow Wed, 19 May 2010 17:47:37 -0700 On 20 May 2010 05:47, David Given <d...@...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19/05/10 19:53, Janusz Krzysztofik wrote: > [...] >> I'm not sure what smart card interface could we use for if ever supported. >> Removable storage perhaps? > > That's an intriguing idea. ISO7816-3 says: > > 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? > 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
|
|
|
Post by Spanner on Apr 18, 2019 12:03:13 GMT
David Given Thu, 20 May 2010 09:38:51 -0700 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/05/10 01:46, Matt Callow wrote: [...] > 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 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). - -- ┌─── dg@cowlark.com ───── www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
|
|
|
Post by Spanner on Apr 18, 2019 12:03:43 GMT
Janusz Krzysztofik Mon, 02 Aug 2010 11:26:51 -0700
Hi, With the 2.6.35 released today, we finally have a slightly modified version of the old Matt Callow's mailboard serio adapter driver included in the mainline kernel.
A small fix for more stable LCD display blanking/unblanking has been integrated as well.
Due to the changes requested by Dmitry Torokhov, the input subsystem maintainer, who finally accepted the resulting serio code and integrated it into his tree, we now need some extra userspace support to get the mailboard working as expected. The preferred way is using a relatively new udev extras utility called keymap. A proper keymap file still has to be created and possibly submitted to the udev maintainer for inclusion.
Still using an older version of udev from the Ansgstrom distribution, I use a different utility, called input-kbd, that is a part of input-utils. My udev rule that automatically loads a required keys map for me looks like this:
ACTION=="add", KERNEL=="event[0-9]*", \ ATTRS{phys}=="GPIO/serio0/input[0-9]*", \ RUN+="/usr/bin/input-kbd -f /etc/mailboard-raw.map %n"
My /etc/mailboard-raw.map is appended below. The top row consists of Esc and F1 - F10. Please modify the map to suit your taste.
This keys map is unidimensional, its purpose is to provide the driver with correct physical keycaps layout. To get the keyboard producing correct characters with shift, ctrl, alt, etc., loadkeys utility with a proper key table must be used on top. I have not yet played with it.
It should be possible to use a standard AT or PS/2 keyboard connected to the E3 instead of the mailboard (I have not tried, but I succesfully tested the opposite, ie. the mailboard connected to a PC). For this, you have to build a special adapter (you can use the gamepad cable if you don't play games on your E3). Since a standard keyboard needs no keys map modifications, don't put the above udev rule in your /etc/udev/rules.d/ if you decide to use it instead of the mailboard. Unfortunately, it's not possible for the udev to distinguish whether the mailboard or a standard keyboard is connected (they respond exactly the same), so it's not possible to switch from one to another without manually loading/unloading the mailboard specific keymap.
Happy typing. Janusz
my /etc/mailboard-raw.map: --- 112 = KEY_ESC 122 = KEY_F1 70 = KEY_F2 124 = KEY_F3 119 = KEY_F4 114 = KEY_F5 105 = KEY_F6 26 = KEY_F7 42 = KEY_F8 28 = KEY_F9 21 = KEY_F10 113 = KEY_TAB 116 = KEY_1 115 = KEY_2 107 = KEY_3 34 = KEY_4 27 = KEY_5 29 = KEY_6 30 = KEY_7 121 = KEY_8 125 = KEY_9 117 = KEY_0 108 = KEY_BACKSPACE 33 = KEY_Q 35 = KEY_W 36 = KEY_E 38 = KEY_R 82 = KEY_T 93 = KEY_Y 13 = KEY_U 14 = KEY_I 50 = KEY_O 52 = KEY_P 44 = KEY_ENTER 49 = KEY_A 51 = KEY_S 53 = KEY_D 54 = KEY_F 41 = KEY_G 91 = KEY_H 3 = KEY_J 118 = KEY_K 58 = KEY_L 59 = KEY_APOSTROPHE 60 = KEY_LEFTSHIFT 61 = KEY_Z 78 = KEY_X 84 = KEY_C 11 = KEY_V 5 = KEY_B 65 = KEY_N 66 = KEY_M 67 = KEY_DOT 62 = KEY_UP 85 = KEY_RIGHTSHIFT 259 = KEY_LEFTCTRL 6 = KEY_LEFTALT 73 = KEY_RIGHTMETA 75 = KEY_SPACE 68 = KEY_COMMA 22 = KEY_LEFT 46 = KEY_DOWN 9 = KEY_RIGHT
|
|
|
Post by Spanner on Apr 18, 2019 12:04:09 GMT
Janusz Krzysztofik Mon, 31 May 2010 16:03:41 -0700
Hi,
Since 2.6.35-rc1 is out, I've already started working on updated ams_delta_defconfig, to get it ready for inclusion on time.
As usually with every new release lately, the current ams_delta_defconfig, even with modifications that I failed to push for 2.6.34 already integrated, gives a kernel that is too big for our old boot loader. From my previous experience I can tell that it should be at most 1795kB to boot without problems. For bigger kernels, I always get kernel checksum verification error reported by u-boot. That's why I fiddle with defconfig for every new release.
Starting with 2.6.35, there is a chance we can get a defconfig that will result in small enough krenel (1348kB instead of 1812kB) for several releases without touching it now and again. For this, we should use LZMA method for kernel image compression instead of previous GZIP. The drawback is that it will take extra several seconds to decompress the kernel while booting. I hope this extra delay will be acceptable for you.
If anyone has any other idea how we could modify the current (2.6.34 or 2.6.35-rc1) ams_delta_defconfig for smaller kernel, than please post it here.
Thanks, Janusz
|
|
|
Post by Spanner on Apr 21, 2019 11:03:25 GMT
Where is E3 Linux 2.6.35, when can you download it..?
|
|