It's Not Qualcomm's Fault: Dispelling TouchPad Myths
by Anand Lal Shimpi & Brian Klug on August 19, 2011 6:40 PM EST- Posted in
- Tablets
- HP
- Snapdragon
- OMAP
- Qualcomm
- Smartphones
- touchpad
- Mobile
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 vfpv3OMAP3x30:Processor : ARMv7 Processor rev 2 (v7l)Features : swp half thumb fastmult vfp edsp neon vfpv3MSM7x30:Processor : ARMv7 Processor rev 1 (v7l)Features : swp half thumb fastmult vfp edsp thumbee neonMSM7x27: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.
Facebook
Twitter
RSS
79 Comments
View All Comments
g1011999 - Saturday, August 20, 2011 - link
If this hardware sounds familiar to you it's because it's the modem-less version of the MSM8x60, the same SoC used in the "HTC Thunderbolt" and the EVO 3D.I think HTC Thunderbolt didn't use the processor but HTC Sensation.
fteoath64 - Saturday, August 20, 2011 - link
Well, HP is expecting too much in terms of sales when the product does not really measure up in terms of price or performance. It has not even given sufficient time to move the product much less the marketing effort being put into it.If you look at the Android tablets, they took about 2 years to get to market, then it started moving but not as fast due to the higher price points. If HP were to position the price at $350 initially, it would have moved volumes compared to their initial prices. They did not learn from Xoom pricing which had to be slashed to move the product. The market is more elastic than it seems, so the marketing people are not doing their jobs.
How could Qualcomm be at fault for their SoCs ?. There are plenty of QualComm Soc smartphones that are plenty fast and selling very well in the market.
piiman - Saturday, August 20, 2011 - link
Yeah at 100.00 bucks these things are flying off the shelves! I find it odd no one as figured out that to beat Apple they should sell their pad for less not more or even the same. I want competition not more of the same.DaemonES - Saturday, August 20, 2011 - link
Scorpion core performing in out-of-order. Article mentioned it like in-order.Wilco1 - Saturday, August 20, 2011 - link
No, the Scorpion core is in-order. It is basically a Cortex-A8 clone, with almost identical integer performance. It supports out-of-order completion of instructions which is something entirely different. Instructions are always executed in-order, but memory instructions use a much longer pipeline which means that simpler instructions which execute afterwards may complete earlier.While out-of-order completion improves performance, any cache miss will still stall the whole core. Given that Cortex-A8 does not support out-of-order completion, and is usually a little faster than Scorpion, it is safe to say that out-of-order completion doesn't provide much performance gain.
An out-of-order core executes instructions out-of-order using register renaming but always completes them in-order. This provides substantial performance gains (20-50%) as the core can continue executing independent instructions after a cache miss. This explains why Scorpion cores have a hard time keeping up with the Cortex-A9, as evidenced by the benchmark results.
Wilco
vshah - Saturday, August 20, 2011 - link
"the same SoC used in the HTC Thunderbolt and the EVO 3D "Should be HTC Sensation, no?
jed22281 - Saturday, August 20, 2011 - link
"The TouchPad needed more work, and webOS as a whole needs more work. You can either scale a project out by taking more time to get it done, or you can scale its width by committing more resources to it. The latter (and more efficient development) is what Palm has needed since day one, what HP promised to bring to it, and sadly exactly what it ultimately failed to receive at HP."Sigh, the parallels with what happened to MeeGo inside Nokia are uncanny.
Symbian kept winning the departmental funding wars until far too late.
As a result Maemo had much less resources, was scaled-out, & need more time.
It didn't get the focus it deserved/needed until Jan 2010, the rest is history.
Despite popular misconception, the merging with Moblin into Meego had little impact on Harmattan's progress compared to the aforementioned.
Penti - Sunday, August 21, 2011 - link
Symbian and MeeGo uses the exact same framework for the applications so there never really was any war, Symbian was carrying QtMobility forward. All the APIs are implemented on Harmattan too. It is a cross-platform runtime/framework and it is a mature runtime/framework/ecosystem/SDK/platform you need. Mango simply isn't getting up to date either it is just trying to catch up technically. It's just a case of killing things too early/before market entry. WebOS was never really launched in a major product by HP as they never got the Pre3 out. Nokia on the other hand had a production used SDK that it ported to run on both Symbian and Linux so it hardly looked hopeless there, however you do have to cancel products some times even before market entry this just wasn't clear that it was the right products that got canceled.Also such things like making it run on the platforms/SoC's is also up to the hardware vendors, and of course platforms like Symbian, Android and even MeeGo which was getting drivers and whole board support packages for several SoCs when Nokia didn't want it any longer as well as the Linux Kernel in general. It's far easier for WebOS to work for a large range of devices then say WP7. MeeGo was essentially put of the map before they got the bits put together with Nokia's regard. Switching from Clutter to Qt was a good move though if they really would have went through with it fully. It wasn't a question of the OS itself there rather the platform on top of it which isn't OS-bound.
It also kinda is like if they would have given up at RIM with the Blackberry Playbook after 45 days. It's ridiculous and no tablet really other then Apple's which wasn't a finished product itself when released, is gonna take off the first minute it is released. If so it would really only be Apple and Samsung on the market. Here in Sweden they never got to release either the TouchPad or the Veer here for that matter. I don't think you can really judge a platform within 30 days as HP management did, it wasn't even a world release, third party software was of course lagging and would of course be lacking as long as they only had the touchpad and veer on the market. It might been out on the selfs in the US but still just as Palm failed wasn't a world release and wasn't given time for the software to be worked out. It would be quite odd if you could create a software platform and framework which would work on tablets alone today. Not many would be familiar with such a platform.
ssnova - Saturday, August 20, 2011 - link
To all those "haters" and paranoid people about Anand selling out to qualcomm, they should find better things to waste their time on, rather than pointing fingers and being useless witchhunters.I found the article to be as fair as possible and technically "enlightening", if one would see other articles out there that say, "oh webOS runs 2x faster on the ipad2", then most would come to the strict conclusion that hp's touchpad's hardware was the sole thing to blame. But when one examine's the touchpad's hardware the whole story doesn't make sense. Anand basically broke it down for us and shed some light on the subject matter, which I thought was cool and appreciated it as a reader.
From what I get, certain aspects would run faster on different hardware, again, not because the hardware is "that much more superior", but because the old code was optimized for other hardware as well.
Any how, here's to hoping that webOS will either: a.) improve...or b.) someone does a good port of android OS to the touchpad's hardware...as I keep my eye out for a low priced touchdpad, :P
Keep on keeping on Anand, you the man!
BillBear - Saturday, August 20, 2011 - link
If we're into clearing up mistaken information on the web, why are you ignoring this?Mojo based WebOS apps can run in Safari.
Palm's very first webcast introducing the WebOS app environment to potential developers featured writing demo app code in Textmate on a Macintosh and then running that demo app on top of Safari.
You can still catch that webcast here: http://www.youtube.com/watch?v=YXS3SQauwPE