Hi all,

Just received the efikamx, courtesy of Genesi. Thank you. First impression was "Wow, really nice form factor!"

I'm responsible for pushing to Linus' tree the base HW initialisation bits for i.MX515. However, what I've done is a tiny, tiny part of the BSP (basically a serial port and ethernet). A USB driver was contributed by Freescale. Adding all the features of the BSP to mainline will be a long, arduous journey w/o Freescale committing full-time resources to the task. So anybody looking to get started with kernel development, feel free to dive in, especially now that Freescale has release the reference manual to the chip here: http://cache.freescale.com/files/dsp/do ... MX51RM.pdf

My first thought on seeing the efikamx was whether I could replace my aging Xbox1 setup that runs XBMC with a low power, noise-less efika. The only major output missing IMO, is a digital audio out to carry raw PCM streams. With 3D drivers, the i.MX515 should be able to drive 420p and perhaps 720p (haven't checked). Thoughts regarding the feasibility of this are welcome.

Cheers,
Amit

hello Amit, welcome aboard!

with the risk of slightly hijacking your thread, let me try to partially answer your question about imx515's display-driving 3D capabilities.

the original XGPU has indisputably higher raw characteristics - at ~930MPix/s raw peak fillrate and two TMUs, it can output notably more '3D' pixels than the z430 (166MPix/s peak), or any other mobile SoC GPU today. that said, xbox has a rather hapless memory architecture (framebuffer in UMA, with no local 'tile' buffers whatsoever), which brings to some serious CPU/GPU bus contention. additionally, z430 is a contemporary mobile GPU, capable of things that are either too difficult on the XGPU (nv2a) or plain impossible.

I think that you would be more interest how z430@EfikaMX compares to other contemporary SoC GPUs. And there it stands its grounds.

While not the fastest ROP performer (1 pixel/clock @ 166MHz), imx515's z430 has probably the highest ALU shader performance in its class today (I'm yet to check SGX54x though) - that means that the z430 is better suited for 'complex' pixel scenarios, at modest resolutions - 1024x768 is about as high as I'd try to drive the chip to do real-time 3D; at that res, we get a peak of 166Mp/s / (1024 * 768) = 211 framebuffers/s, @30 fps = 7x overdraw factor - that's not abound but it's still usable in game-like scenarios. needless to say, at such resolutions you'd also need good occlusion techniques for your complex-shader pixels, and you have to be careful not to go overboard with 'dumb' pixels (such as those in particles, post-process filters, etc).

Hi Amit,

Digital audio out is routed to the HDMI connector. It's not used right now (in favor of routing i2s from the audio codec, SII9022 converts it to PCM for us) so if you have a TV with SPDIF out then you can chain them up. There is a switch in the git kernel to enable "hdmi_spdif=1" and you should then be able to pick the SPDIF driver as your output source and it will go out over HDMI as intended.

XBMC would be better if it supported OpenMAX. I believe some guys supporting Tegra have already done this work along with making OpenGLES support a bit better. I have no idea if this got merged into mainline yet, but I did see some discussion earlier this year about how well it works (just a little slower than they thought). I would assume it's fixed now.

We have one longstanding but close to be solved with the VPU video overlay.. it may be that video playback is very very fast using OpenMAX codecs, but it also may be that this bug causes some strange bus behavior or IPU clocking issue, whereby the display blanks while playing video. It only happens using the *overlay*, decoding video is unaffected.

Therefore, it should be very feasible.

_________________
Matt Sealey

Hi, just got my box, so I thought I should share my first impressions with you.


After opening the box, I immediately appreciated the overall design of the device. The machine feels quite solid and reliable. However, the size of the touchpad is a bit meager after being used to a Macbook, and the positioning of the keyboard slightly too low. Otherwise, it is a good keyboard to write with (and I'm usually quite picky about which tools I accept for text or code creation.) An odd feature is that sometimes a key gets doubled even though I intended only a single keystroke, evidently this is a kernel thing that can be fixed.

The biggest problem with the machine is the suspend/hibernate support. It seems that after re-opening the lid, the Wifi isn't able to resume the previous connection. A kernel oops results (it seems to originate from wpasupplicant on the userspace side, so clearly related to the wifi). If one does not cherish the idea of a reboot, it seems it suffices to rmmod rt2870 and then re-modprobe it.

My first session (after the initial reboot) ended quite clumsily: the machine grinded to a halt with some visible artifacts on the LCD display (it looked like every second column of graphics was shifted 32 pixels sideways). All I could do was use the power button to remove the life force from the machine and then start it all over again.

What can I say about Ubuntu/GNOME? It's a mixed blessing: the GNOME theme engines and whatnot are slow at rendering, and this is especially evident with the 800MHz Cortex-A8 and the constrained memory accesses of the MX51. I think this is even aggravated by the fact that the screen depth is 16 bits which means a lot of bit shifts to get the 24bit pixels crammed in. Since the X11 on Efika seems to enjoy EXA acceleration, it would make perfect sense to run X11 at 32 bits of pixel depth to avoid expensive CPU conversion from 24 bits to 16 bits. Unless maybe the conversion routines could be written in NEON.

My verdict: if one gets rids of the GNOME desktop, this is a very usable machine even with the shipped software for coding and web dev. Or at least as long as the rt2870 driver doesn't hiccup. Coders without wall power will value the fact that running buggy code with CPU pegged at 100% does not significantly accelerate the battery drain, entirely unlike on any Intel CPUs.

A short list of problems:

- some issues with the wifi
- a crash with framebuffer going berserk
- the touchscreen is a bit too sensitive while typing
- backlight does not remember the brighter setting after screen blanks (one notch less than while not blanked)
- Division by zero in kernel (every 0.01 seconds) for one minute

kernel 2.6.31.14.20-efikamx

the wifi issues are known, unfortunately, we're using the staging driver with 2.6.31 as rt2x00 is completely unworkable in the kernel; you might be able to compile compat-wireless, and use that driver, I had mixed results here, depending on day, position of the sun, who was winning the hockey game, and so on and so forth, although recently it has gotten pretty stable, but I was using a different kernel that would be missing too much other functionality to make it work.

the division by zero is also related to said wifi :/

how often does the framebuffer go berserk on you? are you doing anything in particular, and can you reproduce the issue reliably?

sadly, we can't turn off the touchpad while typing do to the way it is connected to the board, this issue should be rectified with the mx53 version once it is released.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

brand new Efika MX Cloud (smartbox?)

Initial boot worked, it took me a while to realize that your name and user name had to match, but after that, fine. After initial boot, screen went blank. I Forced reboot, got a splash screen, then blank again. I Managed to mash the keyboard long enough to pull up terminal in full screen, but I don't know what to do at this point.
I have what I believe to be the latest (at least according to the blog mentioned above), version 2.6.31.14.20-efikamx #1 PREEMPT Fri Feb 25 13:24:56
Matt, is this kernal the correct one, or should I reinstall?
Another issue that is very annoying, is that every time I try to do something, it forces me to reset my password. Perhaps if I had a GUI I could find a setting to stop that...

Most likely the time of the system is way off. Verify this in the prompt with 'date'. When you correct the date it'll start working better. When it comes to the blank screen you might be out of luck until the kernel starts liking your display after some upcoming revision. Try with another display to see if there's anything coming out.

Thanks, I'll try another monitor (or 2).

The date checks out (Friday the 13th)

Current Monitor is an Acer V223W

I have the same problem. Displayed during installation on a large monitor (1366x768), but no visuals post-installation. Shortly remedied by running Android 2.2 from an SD card. I'll deal with it later, but I'm almost positive this monitor just isn't going to cut it; I'll have to try another one.

-Regards,
Derek

Hi Derek,

1366x768 should work fine. I'm more interested in what you mean by "no visuals" though. As in, you can't use X, do you see the Genesi logo and dots as it is booting? Do you see the logo, and then it goes black and just sits there, does it just not do anything at all when you turn it on?

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

This really does sound like the system time is/was wrong. Typically if it wants you to constantly reset your password it is because the timestamp is wrong on the file.

While a quick hack solution is to just change your password, set the correct date, then change it back to whatever you want, I'd more recommend re-imaging. Either with an active and working internet connection (it needs to be able to reach a ntp server) or without a connection at all (and then when going through OEM config, make sure it has an internet connection and can get out).

We have seen issues where people connect via a wire to an AT&T Uverse router and while it gets an IP address, it can't actually reach the internet, and this causes the date to be incorrect.

If after you have re-imaged the machine, you are still having issues, please let us know.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

I just received my Efika MX today. I couldn't wait to get it hooked up and running. Everything was going along like was laid out for the first boot, but when it finally finished, it was using 1280x720. The display is sharp, but the toolbars are outside the screen. This is a VISIO 26" LCD with a native resolution of 1366x768. So far, I have not found a way to get the system to use 1366x768. Some tools like xrandr don't seem to work to well for trying to get information. At this point, I'd even be happy if I could find a way to pan around the screen, but I can't figure that out in Ubuntu either. One other un-related note, the wireless has trouble connecting to my Airport Extreme. I got it to connect once, but not again. Fortunately, I have a wireless bridge I can use until I figure that out. Any help would be appreciated.

Are you connecting to the HDMI port of your monitor? I know some monitors will use overscan on the HDMI input, thus making you lose the outer edges of the picture. My TV does this.
If you are using the HDMI input, you could try connecting to the DVI port of your monitor instead, to see if the overscan is still present.

Also, including /var/log/Xorg.0.log might make it easier to figure out why you aren't getting 1366x768 on the monitor.

I am hooking this up to a VISIO TV, so it only has HDMI. I did connect it to a 24" Samsung monitor with an HDMI2DVI cable and it detected that monitor at 1024x768. I could see everything on that monitor, but it was stretched. When I connected it to the VISIO, I get the following information from my Xorg.0.log:


[ 1.528941] Console: switching to colour frame buffer device 30x20
[ 2.158003] SIIHDMI: Device ID: 0xb0 (TPI revision 2.9)
[ 2.160877] SIIHDMI: sink detected (hotplug, receiver sense)
[ 2.208052] SIIHDMI: Added 6 modes from CEA Video Data Block
[ 2.208065] SIIHDMI: HDMI sink verified
[ 2.208074] SIIHDMI: Port Config 2.0.0.0
[ 2.208102] SIIHDMI: Unsupported modelines:
[ 2.208123] SIIHDMI: p "1920x1080@60" 148.500 1920 2008 2052 2200 1080 1089 1094 1130 +hsync -vsync
[ 2.208145] SIIHDMI: i "1440x480@60i" 13.500 1440 1478 1602 1716 480 494 500 531 -hsync -vsync
[ 2.208168] SIIHDMI: i "1920x1080@60i" 74.250 1920 2008 2052 2200 1080 1094 1104 1135 +hsync -vsync
[ 2.208190] SIIHDMI: i "1440x480@120i" 27.00 1440 1478 1602 1716 480 488 494 524 -hsync -vsync
[ 2.208212] SIIHDMI: i "1920x1080@120i" 74.250 1920 2008 2052 2200 1080 1084 1094 1124 +hsync +vsync
[ 2.208233] SIIHDMI: c "1280x720@60" 74.250 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
[ 2.208255] SIIHDMI: v "800x600@60" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync
[ 2.208276] SIIHDMI: c "640x480@60" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync
[ 2.208289] SIIHDMI: Removed 8 modes due to incompatibilities
[ 2.208298] SIIHDMI: Supported modelines:
[ 2.208315] SIIHDMI: C "1280x720@60" 74.250 1280 1390 1430 1650 720 730 735 755 +hsync -vsync
[ 2.208336] SIIHDMI: C "720x480@60" 27.00 720 736 798 858 480 495 501 531 -hsync -vsync
[ 2.208356] SIIHDMI: C "640x480@60" 25.175 640 656 752 800 480 492 494 527 -hsync -vsync
[ 2.208376] SIIHDMI: "720x480@59" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync
[ 2.208396] SIIHDMI: "1024x768@60" 65.02 1024 1048 1184 1344 768 771 777 806 -hsync -vsync
[ 2.208417] SIIHDMI: * "1360x768@60" 85.506 1360 1424 1536 1792 768 771 777 795 +hsync +vsync
[ 2.208437] SIIHDMI: Setting Resolution: 1280x720@25.12


I'm wanting to use 1366x768 vs the 1280x720 that it defaults to. The 26" VISIO has a native resolution of 1366x768, but I didn't even see it listed in the logs. The closest line is 1360x768 and it has a * by it.

I think the best advice I can give you is to try a kernel with updated HDMI output drivers:
http://www.powerdeveloper.org/forums/vi ... =DRM#14758