<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: An Introduction to the Symbian Virtual Platform</title>
	<atom:link href="http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/</link>
	<description></description>
	<lastBuildDate>Thu, 18 Mar 2010 11:32:24 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tyson Key</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-6544</link>
		<dc:creator>Tyson Key</dc:creator>
		<pubDate>Sun, 27 Dec 2009 15:33:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-6544</guid>
		<description>Hi Claudio,

Whilst I can&#039;t speak for the Foundation officially, I believe that efforts are being made to allow for upgrading individual Platform components in a piecemeal manner, via in-place upgrades and firmware delta patches. There&#039;s also a general consensus that a low-cost &quot;development phone&quot; in some form would be nice to have. Naturally, I agree that it would be nice to see some flexibility in letting users modify and upgrade their device firmware though, in the spirit of openness and freedom to tinker.

Technically, it&#039;s possible for anyone to create new ROM images, although deploying them on current &quot;off-the-shelf&quot; devices is difficult; since &quot;traditional&quot; device manufacturers tend to keep hardware schematics, baseport code, and user-level applications and enhancements proprietary. OEMs also tend to sign and/or encrypt delta patches and full images with private keys that are never externally shared, in order to control their usage, and provide a predictable, &quot;trusted&quot; (subjective, dependent upon party) boot sequence, too. 

Of course, because said device manufacturers have access to cryptographic keys, and device-specific materials; they&#039;re capable of building new firmware images or firmware update deltas. However, preparing them is expensive, and time-consuming, since it involves locating device-specific components and documentation, and people familiar with the architecture of a device. Not to mention that it&#039;s then necessary to re-integrate and test both new, and old components. In the case of operator-branded devices, approval from the operator is usually necessary before they can be deployed. 

There&#039;s also the not-insignificant &quot;problem&quot; from the OEM perspective of keeping customers on the hardware replacement treadmill as far as features are concerned, given that firmware upgrades have their limits. (Not that I agree with the planned obsolescence philosophy).

Historically, It didn&#039;t help that Symbian Software Ltd. (related to the Foundation by name, staff members - in a few cases, and codebase only) used to charge OEMs for the privilege of licensing new major versions of Symbian OS, as far as I know; which reduced the incentive for providing firmware upgrades, and indirectly created the current culture of &quot;If you want a new version of the Platform, buy an entirely new device&quot;. Likewise, there&#039;s also a culture around licensing proprietary, third-party components and technologies that has persisted in both the Symbian, and general device development communities for a long time - which has only recently started to cede to the current trends towards open hardware and software platforms. 

As they say - you can&#039;t easily change a habit of a lifetime...

Sorry if that was excessively long, and difficult to follow; although there&#039;s a lot involved technically, and politically in this stuff. I don&#039;t know, or even pretend to know everything about what&#039;s involved (and I may even be incorrect in some cases), although I hope that&#039;s provided something to ponder.

Tyson.</description>
		<content:encoded><![CDATA[<p>Hi Claudio,</p>
<p>Whilst I can&#8217;t speak for the Foundation officially, I believe that efforts are being made to allow for upgrading individual Platform components in a piecemeal manner, via in-place upgrades and firmware delta patches. There&#8217;s also a general consensus that a low-cost &#8220;development phone&#8221; in some form would be nice to have. Naturally, I agree that it would be nice to see some flexibility in letting users modify and upgrade their device firmware though, in the spirit of openness and freedom to tinker.</p>
<p>Technically, it&#8217;s possible for anyone to create new ROM images, although deploying them on current &#8220;off-the-shelf&#8221; devices is difficult; since &#8220;traditional&#8221; device manufacturers tend to keep hardware schematics, baseport code, and user-level applications and enhancements proprietary. OEMs also tend to sign and/or encrypt delta patches and full images with private keys that are never externally shared, in order to control their usage, and provide a predictable, &#8220;trusted&#8221; (subjective, dependent upon party) boot sequence, too. </p>
<p>Of course, because said device manufacturers have access to cryptographic keys, and device-specific materials; they&#8217;re capable of building new firmware images or firmware update deltas. However, preparing them is expensive, and time-consuming, since it involves locating device-specific components and documentation, and people familiar with the architecture of a device. Not to mention that it&#8217;s then necessary to re-integrate and test both new, and old components. In the case of operator-branded devices, approval from the operator is usually necessary before they can be deployed. </p>
<p>There&#8217;s also the not-insignificant &#8220;problem&#8221; from the OEM perspective of keeping customers on the hardware replacement treadmill as far as features are concerned, given that firmware upgrades have their limits. (Not that I agree with the planned obsolescence philosophy).</p>
<p>Historically, It didn&#8217;t help that Symbian Software Ltd. (related to the Foundation by name, staff members &#8211; in a few cases, and codebase only) used to charge OEMs for the privilege of licensing new major versions of Symbian OS, as far as I know; which reduced the incentive for providing firmware upgrades, and indirectly created the current culture of &#8220;If you want a new version of the Platform, buy an entirely new device&#8221;. Likewise, there&#8217;s also a culture around licensing proprietary, third-party components and technologies that has persisted in both the Symbian, and general device development communities for a long time &#8211; which has only recently started to cede to the current trends towards open hardware and software platforms. </p>
<p>As they say &#8211; you can&#8217;t easily change a habit of a lifetime&#8230;</p>
<p>Sorry if that was excessively long, and difficult to follow; although there&#8217;s a lot involved technically, and politically in this stuff. I don&#8217;t know, or even pretend to know everything about what&#8217;s involved (and I may even be incorrect in some cases), although I hope that&#8217;s provided something to ponder.</p>
<p>Tyson.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Claudio</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-6538</link>
		<dc:creator>Claudio</dc:creator>
		<pubDate>Sun, 27 Dec 2009 00:33:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-6538</guid>
		<description>Hello. Please excuse me because i&#039;m not a developer, but a unhappy user, that spent a lot of money in a supossed top-of-the-notch e90 communicator.

With all this thing of the symbian kernel released, how far is the day that someone could build a rom with a updated OS for any current symbian based phone?

I&#039;ve seen that in linux world there are an active community in creating the perfect open OS for mobile devices.

Do you think this will happen with symbian?

Thanks. Your talk is purely &#039;developer / hacker stuff&#039;, but maybe with your knowledge you can have a greater vision of the things to come than me, just a simple user.</description>
		<content:encoded><![CDATA[<p>Hello. Please excuse me because i&#8217;m not a developer, but a unhappy user, that spent a lot of money in a supossed top-of-the-notch e90 communicator.</p>
<p>With all this thing of the symbian kernel released, how far is the day that someone could build a rom with a updated OS for any current symbian based phone?</p>
<p>I&#8217;ve seen that in linux world there are an active community in creating the perfect open OS for mobile devices.</p>
<p>Do you think this will happen with symbian?</p>
<p>Thanks. Your talk is purely &#8216;developer / hacker stuff&#8217;, but maybe with your knowledge you can have a greater vision of the things to come than me, just a simple user.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Future of Mobile Graphics &#38; Emulation &#124; Because we can</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5883</link>
		<dc:creator>The Future of Mobile Graphics &#38; Emulation &#124; Because we can</dc:creator>
		<pubDate>Mon, 30 Nov 2009 18:02:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5883</guid>
		<description>[...] rendering&#8230;oh dear) then you need to step outside the emulator&#8217;s sandbox. For the Symbian Virtual Platform, that means we need to tunnel the drawing operations through a virtual peripheral to a translation [...]</description>
		<content:encoded><![CDATA[<p>[...] rendering&#8230;oh dear) then you need to step outside the emulator&#8217;s sandbox. For the Symbian Virtual Platform, that means we need to tunnel the drawing operations through a virtual peripheral to a translation [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cdavies</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5852</link>
		<dc:creator>cdavies</dc:creator>
		<pubDate>Fri, 27 Nov 2009 15:39:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5852</guid>
		<description>There&#039;s no way to actually build a full graphics ROM for Qemu right now without full access to the source.

There are key components missing from the build.

Foremost, every adaptation needs a screendriver, a DLL which plugs in to the bottom of bitgdi.

Then, there&#039;s the whole NGA issue.

Incidentally, using buildrom makes the whole determining and satisfying dependencies about a million times easier.</description>
		<content:encoded><![CDATA[<p>There&#8217;s no way to actually build a full graphics ROM for Qemu right now without full access to the source.</p>
<p>There are key components missing from the build.</p>
<p>Foremost, every adaptation needs a screendriver, a DLL which plugs in to the bottom of bitgdi.</p>
<p>Then, there&#8217;s the whole NGA issue.</p>
<p>Incidentally, using buildrom makes the whole determining and satisfying dependencies about a million times easier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tl</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5842</link>
		<dc:creator>tl</dc:creator>
		<pubDate>Thu, 26 Nov 2009 19:27:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5842</guid>
		<description>Thanks, that video was just what I was looking for.</description>
		<content:encoded><![CDATA[<p>Thanks, that video was just what I was looking for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyson Key</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5839</link>
		<dc:creator>Tyson Key</dc:creator>
		<pubDate>Thu, 26 Nov 2009 14:31:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5839</guid>
		<description>Update: I&#039;ve just rediscovered the video at http://developer.symbian.org/wiki/index.php/SEE_2009_Presentations/Demo_Labs/Videos#QEMU_Simulator_.26_Symbian_Foundation, after some digging around.

Hopefully, the very brief demo of S60 ROMs, with and without Qt should give an idea of how long it takes to boot with a full interactive S60 GUI, and how long it takes to launch Qt-based applications from within. 

Naturally, it could do with some performance tuning, and better graphics acceleration support overall, before the experience is as fluid as a real handset, although it isn&#039;t exactly a slouch from what I&#039;ve seen.</description>
		<content:encoded><![CDATA[<p>Update: I&#8217;ve just rediscovered the video at <a href="http://developer.symbian.org/wiki/index.php/SEE_2009_Presentations/Demo_Labs/Videos#QEMU_Simulator_.26_Symbian_Foundation" rel="nofollow">http://developer.symbian.org/wiki/index.php/SEE_2009_Presentations/Demo_Labs/Videos#QEMU_Simulator_.26_Symbian_Foundation</a>, after some digging around.</p>
<p>Hopefully, the very brief demo of S60 ROMs, with and without Qt should give an idea of how long it takes to boot with a full interactive S60 GUI, and how long it takes to launch Qt-based applications from within. </p>
<p>Naturally, it could do with some performance tuning, and better graphics acceleration support overall, before the experience is as fluid as a real handset, although it isn&#8217;t exactly a slouch from what I&#8217;ve seen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyson Key</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5838</link>
		<dc:creator>Tyson Key</dc:creator>
		<pubDate>Thu, 26 Nov 2009 14:17:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5838</guid>
		<description>Hi tl,
At present, it&#039;s capable of booting a full S60 5th Edition GUI, and Qt presumably works (if the presentation above is anything to go by), although not all of the necessary source code, components and infrastructure have been supplied to the general public by Symbian (yet). 

Unfortunately, since I&#039;m neither a member of a Symbian Foundation member company, or an employee of the Foundation, I also don&#039;t have access to the aforementioned components.

However, a handful of prebuilt S60 components are supplied in recent PDKs, and I&#039;ve contemplated attempting to test those, although I haven&#039;t done anything with them, yet.

I would have been happy enough with just TechView, to be honest - although because certain core S60 components conflict with those supplied by TechView, it isn&#039;t supplied in binary form at all to the public, to the best of my knowledge.

Of course, even if a working GUI was available, you&#039;re still limited in what you can do with it, since the TCP/IP stack isn&#039;t fully functional (or easy to configure in a user-friendly manner, from what I&#039;ve discovered so far), and audio support isn&#039;t quite ready.

Additional work would probably also be necessary, before a GSM/UMTS radio or some other device supporting Hayes/AT Commands can be used, although the ModemAdaptation source code repository has been opened, and QEMU itself has serial port support - as mentioned in the post itself.

If there&#039;s anything else you want to know, just ask, and I&#039;ll see what I can do.

Tyson.</description>
		<content:encoded><![CDATA[<p>Hi tl,<br />
At present, it&#8217;s capable of booting a full S60 5th Edition GUI, and Qt presumably works (if the presentation above is anything to go by), although not all of the necessary source code, components and infrastructure have been supplied to the general public by Symbian (yet). </p>
<p>Unfortunately, since I&#8217;m neither a member of a Symbian Foundation member company, or an employee of the Foundation, I also don&#8217;t have access to the aforementioned components.</p>
<p>However, a handful of prebuilt S60 components are supplied in recent PDKs, and I&#8217;ve contemplated attempting to test those, although I haven&#8217;t done anything with them, yet.</p>
<p>I would have been happy enough with just TechView, to be honest &#8211; although because certain core S60 components conflict with those supplied by TechView, it isn&#8217;t supplied in binary form at all to the public, to the best of my knowledge.</p>
<p>Of course, even if a working GUI was available, you&#8217;re still limited in what you can do with it, since the TCP/IP stack isn&#8217;t fully functional (or easy to configure in a user-friendly manner, from what I&#8217;ve discovered so far), and audio support isn&#8217;t quite ready.</p>
<p>Additional work would probably also be necessary, before a GSM/UMTS radio or some other device supporting Hayes/AT Commands can be used, although the ModemAdaptation source code repository has been opened, and QEMU itself has serial port support &#8211; as mentioned in the post itself.</p>
<p>If there&#8217;s anything else you want to know, just ask, and I&#8217;ll see what I can do.</p>
<p>Tyson.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tl</title>
		<link>http://blog.symbian.org/2009/11/20/an-introduction-to-the-symbian-virtual-platform/#comment-5836</link>
		<dc:creator>tl</dc:creator>
		<pubDate>Thu, 26 Nov 2009 13:56:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.symbian.org/?p=3229#comment-5836</guid>
		<description>Very informative, how far away is booting to a UI? It would be interesting to hear how long it takes to boot a &#039;full fledged&#039; OS environment.</description>
		<content:encoded><![CDATA[<p>Very informative, how far away is booting to a UI? It would be interesting to hear how long it takes to boot a &#8216;full fledged&#8217; OS environment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
