NVidia Prefers WinCE to Android

There have been hordes of ARM-powered netbooks that have been popping out of the woodworks of Computex this year. One of which was touting the new NVidia ARM Tegra chip.

Here's a link to an article on Slashdot which reports that NVidia is not ready to back Android as a capable platform for Netbooks.

I unfortunately say that I must agree - although its not completely Google, or the Open Handset Alliance, or Linux that is truly at fault - or NVidia for that matter.

The problem is that NVidia would need to expose yet another kernel and user-space ABI (for their latest, integrated Tegra GPU no-less), and they are not prepared to do so. Aside from that, Android performs much of the hardware acceleration (a.k.a. DSP algorithms) for graphic and audio in a completely re-done set of non-portable libraries (the last time I saw the code), rather than using a single, portable abstraction layer such as OpenGL.

My recommendation? End-users should stick with WinCE (as well as the NVidia-modified UI) that will ship with the NVidia-based netbooks - IF THEY CHOOSE TO BUY A NETBOOK THAT USES AN NVIDIA TEGRA CHIP. Certainly, there are many other, more mature ARM chip vendors that will be offering netbook platforms (e.g. Qualcomm, TI, etc).

However, for almost all other ARM cores with unencumbered ABI's and API's for hardware acceleration - by all means use Android! The Android community, which is composed of literally thousands of developers, will have an exponentially greater ramp-up on new technology and software integration speed than NVidia & MS will, as single entities. Plus, as we have seen in the past, the release cycle for Android will likely be more frequent and since it's Open Source. Furthermore, there is less likelihood that Android will fall behind and become unmaintained (which was the whole purpose of the OHA in the first place), while the NVidia & WinCE combination will likely become unsupported and outdated at some point.

CeGCC / MingW32CE Ebuild for Gentoo Linux

It's probably safe to say that there are not many Gentoo Linux users out there who are actively developing WinCE applications. However, today I compiled my first "Hello, WinCE World!" app, messagebox and all, using the compiler from the CeGCC project. CeGCC-0.51.0 is based on fairly recent tools (e.g. gcc-4.1.0), which is a big bonus.

Although seeing a "Hello, World!" dialog in Windows CE surely made my day, the CeGCC compiler is really only a means to get Linux running on  a certain unnameable portable computing device for work. I'm using the HaRET bootloader which has shown promise for many others who have ported Linux to mobile or embedded devices that run WinCE. 

Just in case there are any Gentoo users out there who would also like to install the compiler using Portage, I have included Ebuilds for CeGCC and MingW32CE that install the i686/Linux toolchain components. Just to clarify, for those who are compiling applications for Win32, or people who want to hack HaRET, use the MingW32CE toolchain. For those who are interested in porting GNU software to ARM/Win32, use CeGCC.

You can download the overlay in tarball format here, but I would suggest using layman, just like for my other overlays.

The ultimate goal of my current project is to have an industrial handheld compuer / scanner that runs Android, and so far its been coming along very well.

Linux Console Via Bluetooth

These days, I find myself hacking, reverse engineering, whatever, several mobile devices that run Windows Mobile. A really great tool that I've started using is called HaRET (Handset Reverse Engineering Tool). In most, it's necessary to get terminal access to them in order to perform low-level debugging. Sometimes, a mobile device will have Linux USB OTG support without any hassle, and I can use the g_ether kernel module to bring up usb0 as a network device at boot time, assigning a static IP address. Then, by using usbnet and other kernel modules on my workstation, I am able to communicate to the mobile device using telnet or ssh. Great!

However, in many cases, USB OTG does not work "out of the box". Furthermore, given that the LCD rarely ever works "out of the box", that leaves me with very few options for getting any type of feedback from the mobile device at all, aside from maybe generating morse code with the vibration unit - that's a joke... please believe me.

It's very necessary to have terminal access, or ICE access, to perform low-level debugging when porting Linux to a new mobile device. One option is to find unpopulated pads on the PCB, where a UART has possibly had pins brought out, and to solder some wires directly to those pads and create the appropriate level-shifter circuit, attaching an RS232 cable to the workstation. Another possibility is to use the JTAG port. In some cases, neither of those options will work because either a) the pins have not been brought out,  or b) the JTAG port has been fused (See my previous opinions on Fusing the JTAG port). In many cases, there is a debug port on the board, with an unpopulated header. Finding the appropriate header and FPC cable is sometimes possible, but in many cases it's like looking for a needle in a haystack. Luckily, I found that needle in my last reverse engineering project, and fabricated a small PCB to bring out the pins of the FFC connected to the UARTS of the embedded device.

When I don't find that needle, then I'm left having to do some very creative reverse engineering. My suggestion: Why not build a small daemon into the kernel that would actually bring up the system console over bluetooth? Most, if not all, mobile devices manufactured in the last decade have bluetooth hardware directly connected to one of the UARTS. I can't imagine that it would be terribly difficult to build something like this into the kernel. My only main concern would be missing valuable information that the Linux kernel spits out at boot time. To counter that, I would probably introduce a "consoledelay" boot parameter, that functioned much like the "rootdelay" boot parameter. Such a boot parameter would allow the underlying hardware of the console to initialize before performing any IO on it.

If anyone feels like funding me to build this into the kernel, I am very open to suggestions :)