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

  • seapeople - Saturday, August 20, 2011 - link

    I think it's pretty clear that ANAND has sold out to the INTARWEB because of how quickly he used it to past ALL HIS ARTICLES. I know this because I've been reading lots of OTHER TECH BLOGS and they are much more CRITICAL of NON-INTARWEB communication!

    I mean, Anand hasn't even mentioned the Verizon strike that's been going on. Should he mention such a major issue in telecommunications? Of course not, it's because he's in the INTARWEB DIRTY MONEY BUSINESS.
    Reply
  • ssnova - Sunday, August 21, 2011 - link

    "I mean, Anand hasn't even mentioned the Verizon strike that's been going on."

    If you've been an avid Anandtech reader, then you would know they don't waste their time on politics and issues of that nature. If you want that kind of "intarweb" "buzz" then that's what Dailytech is for. Anandtech has always focused more on technical articles, educating the reader, breaking things down in an informative manner.

    I vouch for Anandtech because I've been an avid reader of their articles since 2003, and though no review is perfect, something that I always respected Anandtech for was their thorough in-depth breakdowns of subject matters and drawing logical conclusions(as best as possible, drawn from the subjective/objective data). This goes generally for all their veteran staff, which I haven't seen some of them post articles in a while.

    ...On a random note, whatever happened to Kristopher Kubicki? I don't even see Dailytech posts by him anymore?

    Any how... again... the stuff on here is just a technical breakdown with some insight, perhaps it could have been titled better, but after reading the article I see no reason to try and please the crowd when spitting it out in your own way.
    Reply
  • WeaselITB - Monday, August 22, 2011 - link

    @ssnova

    I think you need to get your sarcasm-meter checked ...

    -Weasel
    Reply
  • jaysns - Sunday, August 21, 2011 - link

    I like this kind of article when you see the internets abuzz, and by that I mean the bigger blogging sites, with misinformation. A lot of sites were reporting on this and a nice little write up explaining why it was untrue and didn't even make sense is a good thing. Not everyone knows these things, and even I who understands this, and is well read up enough at least to notice the BS that engadget and others were putting out, enjoyed reading this. This is my favorite tech site. Just wish you guys posted more :p. Keep up the good work. Reply
  • Zoolookuk - Sunday, August 21, 2011 - link

    I can't ever remember thinking an Anand article was way off target, but this one is. You dedicated 3 pages to telling us this wasn't a hardware issue, and then showed a benchmark illustrating the TouchPad was half the speed of the iPad 2, which has fairly modest hardware specs. If you reviewed the latest AMD chip and showed it at half the speed of a 6 month old Intel processor, you wouldn't claim it has 'similar performance'. I really don't get that.

    The irony here of course isn't you letting a 200% performance gap go, it's that NO ONE is saying the reason the TouchPad bombed is because of overall performance. Leaping to it's defense seems a little weird.

    I don't even agree that the issue is WebOS - it's a fine operating system that had a lot of promise. The issues were:

    - Terrible design and build quality (it looked and felt like a budget iPad)
    - Non-existant or poor marketing (Glee? Really?)
    - No integration within anything meaningful. Android has the entire Google eco system, while Apple has iTunes and virtually everything else

    Maybe read this too early on a Sunday morning, but you seem to be trying to prove a point that just isn't there.
    Reply
  • ViRGE - Sunday, August 21, 2011 - link

    "Maybe read this too early on a Sunday morning"

    I think that would seem to be the case. The only argument Anand is making is that the poor performance you see - "then showed a benchmark illustrating the TouchPad was half the speed of the iPad 2" - is due to the software and not the hardware. That still makes the TouchPad a lousy device, but the purpose of the article is to establish why.

    And someone did say the problem was the TouchPad's performance: http://thenextweb.com/apple/2011/08/19/hp-tested-w... . That's the article that spurred this one, since the idea that a dual-core A9 is twice as fast as a dual-core Snapdragon (clocked 20% higher) is silly.

    Snapdragon ~= Tegra 2 (source: many, many AT phone reviews)
    Tegra 2 ~= Apple A5 (source: AT Galaxy Tab 10.1 review)
    QED: Snapdragon ~= Apple A5

    Hence the idea that the iPad (Apple A5) platform being twice as fast as the Snapdragon platform is silly. The software stinks, the hardware is fine.
    Reply
  • tipoo - Saturday, December 10, 2011 - link

    No, he said that it had similar performance to the Tegra 2, then showed the huge performance difference between them, showing that its a software thing and not a CPU thing. Reply
  • sirsoffrito - Sunday, August 21, 2011 - link

    I was already suspicious of these other websites claiming Qualcomm's incompetency. It seemed pretty hard to believe given the amount of inefficient bloat HP's Windows machines come with. In such a competitive market as tablets now, manufacturer's have exactly *one* shot to prove they are up to snuff, and I can't say I've been terribly impressed with HP's build quality hardware wise in recent years, much less all the software they try and foist upon people. What's funny is that the software is so incredibly important and is often the most ignored. A well optimized program can make all the difference in the world. People respond to a clean, snappy interface; hence Apple's success. Reply
  • superccs - Sunday, August 21, 2011 - link

    SO essentially you are saying that this device has legitimate hardware, just poor implementation...?

    Wouldn't this make this device a steal for rooters and modders?
    Reply
  • Zoolookuk - Monday, August 22, 2011 - link

    The WebOS team apparently experimented with their OS on the iPad2 hardware, where it ran 'twice as fast' .

    http://www.appleinsider.com/articles/11/08/22/hp_r...
    Reply

Log in

Don't have an account? Sign up now