There's a whole lot of misinformation on the web right now about reasons why HP had troubles with the TouchPad and eventually had to abandon the entire webOS hardware division. We'd moved on internally after yesterday's news but a bunch of stuff that popped up online today prompted a quick discussion about the realities of webOS hardware.

It's Not Qualcomm's Fault

Someone somewhere started this idea that by using Qualcomm hardware the TouchPad and presumably Veer/Pre 3 were handicapped. The theory is that by using Qualcomm hardware HP somehow limited performance of these devices and made it very difficult to run on devices that used other, non-Qualcomm SoCs.

Time for a reality check.

Palm's webOS launched on TI's OMAP 3. The original Palm Pre ran on an OMAP 3430. In fact, I did a quick head to head between it and the iPhone 3GS when it came out given the similar specs of the 3430 and Apple's 3rd generation SoC.

The Palm Pixi, on the other hand, used a Qualcomm MSM7x27 SoC. At the same time, the Palm Pre Plus was available with the same OMAP 3430 as the original Pre. Here we have two different SoCs which themselves implement different versions of the ARM instruction set (the MSM7x27 runs ARMv6, OMAP 3430 runs ARMv7), and yet it was possible to port the current version of webOS between two different SoCs from different vendors running different ARM instruction versions entirely. 

Morover, webOS 2.0 is fundamentally the same beast at an OS level as webOS 1.x. The Pre Plus and original Pre can run webOS 2.x just fine (with appropriately changed radio firmware), an OS originally intended for the OMAP 3630 in the Pre 2 and the HP Veer's MSM7230. Porting between different SoCs thus isn't entirely impossible - already we're up to webOS 1.x and 2.x running on 4 different SoCs. It's reasonable to say that porting is actually relatively easy. 

In fact, while doing the HP Veer review and poking around inside webOS 2.1.2, we found numerous references and plugins which were definite remnants of OMAP3 compatibility. This isn't a surprise at all considering that the Pre 2 likewise runs webOS 2.1.0.

It's not flip-a-switch trivial to port between SoCs, but it's not shoe-eating impossible, either. Apple, NVIDIA, TI and Qualcomm all implement the same ARMv7 instruction set in their latest SoCs (with the exception, again, of the Pixi's MSM7x27 which used ARMv6), and thus code compiled for one processor should run just fine on another. There are differences in terms of power management and what other instruction set extensions are supported (e.g. ARM's NEON SIMD extension, or thumb, vfpv3, and others) but these are minor in the big scheme of things. They require development time, but presumably the webOS team has (or is it had, now?) developers on staff whose responsibilities were to smooth over these differences.

Respective Extensions from cat /proc/cpuinfo:

MSM8x60/APQ8060:
Processor : ARMv7 Processor rev 2 (v7l)
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
 
OMAP3x30:
Processor : ARMv7 Processor rev 2 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3
 
MSM7x30:
Processor : ARMv7 Processor rev 1 (v7l)
Features : swp half thumb fastmult vfp edsp thumbee neon 
 
MSM7x27:
Processor : ARMv6-compatible processor rev 5 (v6l)
Features : swp half thumb fastmult vfp edsp java 

One of the bigger issues in porting between these SoCs has to do with graphics drivers. While all of the aforementioned companies implement the same ARM instruction set, they all use very different GPUs. Each GPU requires its own driver, no different than on an notebook or a desktop. In the Windows world it's like driver heaven, every major GPU has a driver available for every major version of Windows. In the mobile space it's a bit more complicated.

Because there's an Adreno 220 driver for Android doesn't mean that one exists for iOS or webOS. To a certain extent, each OS needs its own driver. Granted there can be a lot of code reuse thanks to similar standards existing across the OSes (OpenGL ES 2.0 for example is on all three OSes) but here's another area where development time is required.

There are other differences as well between SoCs. Differences such as what video encoders the OS will use for camera input to encode both JPEG and MPEG video. What decoders onboard the SoC to use for video playback or flash video acceleration. Where and how big the SDRAM is. What interfaces (I2C, SPI, GPIO and USB) are to be used for accelerometer, ambient light, gyro, pressure, or compass sensors. Which of those I/O ports are used for controllers for the touch panel, backlight, LED, vibrate and WLAN. All of these are considerations that make moving an OS between not just SoCs but hardware platforms, something that initially seems daunting but really amounts to pointing things in the right direction and including the right kernel drivers. Thankfully since webOS is linux based, the kernel should take care of a huge percentage of that difficulty and largely make any SoC that Android runs on a potential host for webOS. 

In the end, while it does require work to port webOS to various SoCs it has not only been done in webOS history but it's a small part of the work required to bring a new tablet or phone to market. If this were an insurmountable task then we wouldn't see Android working on every single major SoC released.

It's Really Not Qualcomm's Fault
POST A COMMENT

79 Comments

View All Comments

  • kmmatney - Saturday, August 20, 2011 - link

    Damn....that's cheap! Reply
  • piiman - Saturday, August 20, 2011 - link

    they are sold out now :-( Reply
  • Stuka87 - Friday, August 19, 2011 - link

    Arstechnica had an article today about this exact subject, and about how the hardware was such a limiting factor, and how it was designed over a year ago, and a bunch of other stuff.

    And I was really quite sure that this could not be the case (in reference to speed). So thanks for taking the time to clear things up Anand.

    I am bummed that WebOS may go the way of the dodo, as I really liked the interface and the way it acted. But it is slow, even on the TouchPad which has a lot of hardware.
    Reply
  • killerroach - Sunday, August 21, 2011 - link

    That being said, Ars does have a pretty long-standing tradition of taking glee in the hardships of anybody not named Apple. Reply
  • AmdInside - Friday, August 19, 2011 - link

    What about developer relations? It is a key that many big companies use to push their products by offering development assistance to help the customer make a better product. Look at how well tuned apps are to intel processors because of this. Perhaps Qualcomm did not provide sufficient assistance to HP to make WebOS as fast as it could be.

    I picked up a couple of Touchpads this evening. Fingers crossed that someone can figure out a way eventually to get honeycomb on the Touchpad.
    Reply
  • DanNeely - Friday, August 19, 2011 - link

    I don't know if they actively sought developers out; but it appears they were responsive to anyone who contacted them. A friend of mine contacted HP and offered to port one of his employers games if they gave him hardware. He got both a phone and a tablet to play with. Reply
  • GrizzledYoungMan - Saturday, August 20, 2011 - link

    How poopy the actual Android user experience is. Reply
  • kmmatney - Saturday, August 20, 2011 - link

    Have to agree...I tried an Android tablet, but the user experience just wasn't there, so sold it and paid a lot more money for an iPad2. I'm itchin to upgrade my 2+ year old 3GS, but at the moment Android is a downgrade, so I'm just waiting for the next iPhone. I'll probably have to wait a month or more after it comes out because of all the hoopla. Pain in the ass to be tied to Apple products, but the user experience is worth it, IMO. Reply
  • piiman - Saturday, August 20, 2011 - link

    Please define "user experience" Reply
  • Sterman - Saturday, August 20, 2011 - link

    you know... that magical thingy that makes you feel good inside. Reply

Log in

Don't have an account? Sign up now