You should grab the code from the git repo and compile it.

The #if/#else/#endif for the prototype definition is gone (yay!) because even I had problems with it. I am currently discussing with Pegatron why this is even in there.

There's several updates to stability of NEON and suchlike, but for a TO2 user.. you will lose it completely (this is not bad, it will lock if you try..)

I think I also fixed the SD card problem, but... it seems different with each SD card. Have a try. If you are desperate for a precompiled version give me a nudge.

_________________
Matt Sealey

ack, grabbing as i type. apropos, is mx51_efikamx_defconfig from the efikamx-10.07.11 branch good to go?
i skimmed through the respective commit log - what's the deal with neon there?
i've got a few cards waiting here.

update: front SD is still not there for me. tried two cards, one HC and one non-HC - same result. at each ejection the driver reports (timestamp nonwithstanding): the only other place in the kernel log where mmc1 is met is early on: on an unrelated note, 2.6.31.14 seems to shutdown properly for me, in contrast to 2.6.31-TO3.

It is now. Wireless should work pretty well (rt2870sta driver, please get the firmware from ralink and rename it to rt3070.bin :)
NEON on TO2 MX51 chips is broken due to a memory controller issue. Essentially unaligned data of large sizes can cause it to lock up. It happens only
for NEON code because of the way the data is fetched. Actually, you may never have seen a NEON lockup, or you may have seen a crash where you didn't think it could be NEON..
I really cannot understand why the card is not detecting in the front slot. The code seems fine to me.. it picks the right IOMUX for the board (internal for sdhc1, registers sdhc1) and then determines it is a 1.1 board and therefore sdhc2 can be configured in IOMUX and registers sdhc2.

It should work, I've seen it work in the past.. I am just really confused as to why not today. It does report ejections just fine..

_________________
Matt Sealey

thanks, but as i'm wireful the original version did fine for me.
oh. good thing i did not succumb to autovectorisation and neon compiler optimisations then.

so is there nothing that could be done about TO2 there? perhaps put the memory controller into some peculiar granularity mode to counter the neon fetch hazard? i'd really love to be able to use neon at some point in the future.
well, it's not a priority for me now as i'm stuck in 2.6.31.12.3 land anyway due to the z430 modules (un)availability. i might try to do a quick cross-reference between 2.6.31.12.3 and 2.6.31.14 to find clues about the sd issue.

No extra modules for 3D required now. It's all in the 2.6.31.14 release. What you will need though is a new userspace and we're stuck on a bug :)

_________________
Matt Sealey

Hello, dear Sirs. Has this been fixed? I'm still getting the same thing. I cannot get any picture to my Sony KDL-52W5500 via HDMI. The Efika MX box tries to set some very bizarre refresh rate that the Sony won't accept. After listing unsupported and supported modes, dmesg says "SIIHDMI: Setting Resolution: 1920x1080@10.7". Whaaaaat??? 10.7 Hz refresh rate?

The unsupported and supported lists don't make much sense either. It claims that for example 1920x1080@25 and 1920x1080@30 are unsupported by the Sony TV. How can that be? The only full HD resolution listed as "supported" is 1920x1080@24.

I added vmode=1920x1080@24 to the kernel boot parameters, and it is indeed printed in the beginning of dmesg, but it doesn't have any effect.

What do I have to do? Do I have the wrong version of the kernel or something? It's the latest 2.6.31.14.20.

That dmesg line is misleading - I seems like a bug in the printout calculation. To see what clock the display is really getting, you need to either see the display's own OSD (apparently not possible in your case) or see what the following says:
The driver has a rather sophisticated logic for filtering out modes that the display reports as supported. Each rejected-mode line is prepended with a single-character 'reason for rejection' code in the kernel log. Their loosely-translated meanings are:
I've never tried the vmode argument, but one temporary workaround for you is to stick with 720p for the time being i.e. pass boot parameter 'siihdmi.teneighty=0'.

So is there a way to force a particular video mode? Or not?

I also tried the demonstrational Android image, and it did get a display mode going with the Sony.

Anyway, there was one full HD mode listed as supported, the one with 24 frames per second. What was wrong with that then? I don't know about the level of "sophistication". How sophisticated is it that after doing all this so-called logic, it finally decides to set a mode that the Sony TV cannot display?

I'll try the teneighty thing, so let's see what it does.

I just looked up the standard way to set a particular mode to a KMS kernel at boot time, and one needs DRM for that. So no, you cannot do that for now.

Currently the HDMI driver's logic appears to be:

1. unless asked not to, try the highest-refresh mode among some low-refresh (<= 30Hz) 1080p modes (subject to aforementioned filtering)
2. unless asked not to, try the closest to a 'default' 720p mode (ditto)
3. pick the mode that is closest to the monitor's preferred mode (as declared by the monitor itself) - i.e. could be the preferred mode itself, if that was not filtered out (but chances are the preferred mode gets filtered out in your case, if that's a native 1080p set). Preferred mode is marked with an asterisk in the list of accepted modes, or with a captialized rejection code, in the rejected modes list.
4. if everything else fails, set the most vanilla 720p mode known (not subject to filtering).

From your description of the problem, the driver most likely gets 'stuck' somewhere on step 1 - it picks a low-refresh 1080p mode which, when attempted to be actually fed to the display, is met by a refusal.
That just indicates that Android is not trying to feed your monitor the exact same mode the stock HDMI driver is. Another mode, by the same display/HDMI driver combo, could be absolutely fine. Apropos, what does the display say about the mode supplied by the Andorid image? There should be a source-signal info box somewhere in the display's on-board menus.
Normally that should not be the case. Bar bugs in the kernel driver and/or monitor's firmware (yes, some monitors/tvsets report modes the former cannot actually reproduce). Definitely give the teneighty=0 option a try.

Now, it is a bit unclear whether the correct parameter is sii9022.teneighty=0 or siihdmi.teneighty=0 with the official Ubuntu 10.10 image. Guess just need to try...

It's siihdmi; The Genesi driver is siihdmi, the Freescale driver is sii902x

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

Actually I cannot be sure which one we shipped: I think "sii9022" for 2.6.31.14.20, "siihdmi" for 2.6.31.14.21 and above, and if we get 2.6.35 out of the door, "sii902x" will be the Freescale driver and we will stick with "siihdmi".

Sorry about the churn.

This is all going to be cleared up this week: 2.6.31.14.22 will have "siihdmi.teneighty=0" by default, and try to go for a 720p mode. There'll be a boot script update so you can edit this in really easily to get 1080p back if you want it.

_________________
Matt Sealey

Aaaand you just fixed it, we committed it to the repo this afternoon. The kernel update will go out this week.

_________________
Matt Sealey

It's very sophisticated - it's almost impossible for it to send a mode your TV cannot display unless your TV is lying through it's teeth about what modes it can display.

The only time it will force a mode is if there is not a single mode in the list the TV sent that is capable of being displayed, at which point it will fall back to a CEA standard 720p mode, and if your TV doesn't display that, it is frankly a poor purchase :)

_________________
Matt Sealey

Disabling 1080 doesn't help, and Efika's "logic" feels as weird as ever.
If I understood correctly, the "20.93" rate is some kind of number-to-text conversion bug, but whatever 1280x720 mode is eventually being attempted, the Sony TV cannot display it any more than the 1920x1080 modes. Sound is working through the HDMI, however.

To tell the truth, it never even crossed my mind that getting a working picture to an HDMI display isn't a plain vanilla standard piece of cake these days. So far I've been able to get all HDMI devices I've tried to work with the Sony W5500 TV, including PS3, Xbox360, Denon AV amplifier, Samsung DVD recorder, various Canon and Sony cameras, and a Samsung laptop PC.

The unsupported modelines are these: