By the second half this year, developers around the world will be examining the source code for the forthcoming Symbian^3 platform release. Some of these developers will be moved to experimentally modify parts of that code – to improve it, add features, refine the support for their own plug-ins and new applications, etc. How will these developers know if their changes are good or bad?
A big part of the answer lies in the Zoom 2 reference hardware from Texas Instruments (TI):
As announced earlier today, the Symbian Foundation has selected the Zoom 2 – or to give its full name, the Zoom OMAP34x-II MDP (Mobile Development Platform) – as the first hardware reference execution environment for the Symbian Platform.
Here’s how things will work:
- Every two weeks, the Symbian Foundation will make available the latest version of the Symbian^3 PDK (Product Development Kit);
- This kit will contain a large number of binaries, built from the appropriate versions of the source code from all the components that will make up the platform release;
- Scripts and tools will be provided to combine these binaries along with binaries from TI to produce a software “image”, which people can flash into the Zoom 2 device;
- The Zoom 2 should then boot up and run the Symbian Platform code.
That’s the vanilla version. Where things get interesting is when developers make their own versions of some of the components, and substitute the corresponding binaries into the overall image.
The commitment of the Symbian Foundation is that, every two weeks, the platform test code will be run on the Zoom 2 (that’s what’s meant when we say that it’s a reference execution environment). We’ll publish the test results: which tests can’t be run (for any reasons), which tests run but produce wrong results, and which tests pass. Developers can then run the same test suite on their version of the image – and compare the outcomes.
Developers who want to submit their changes to the relevant package owners will in most cases be expected to provide evidence that they have tested their changes on a reference execution environment.
By the way, the Zoom 2 should also be of considerable interest to developers who have no intention of modifying the Symbian Platform code. These developers will be able to copy their own applications onto the device and see how they work. In this way, they’ll become familiar with Symbian^3 even before any device manufacturer releases a product based on that software.
19 Comments
Dear David,
Zoom 2 will be the only hardware reference execution environment? Will Symbian OS work on ATOM platforms?
Thanks in advance,
Dan
The main problem with the ‘old’ DevKits was that they were missing the S60 part. The TechView platform was good for creating components but no good for apps.
Will the new Zoom2+Symbian^3 include common S60 bits? (I realise each OEM might customise S60 further) or will there be still need to license source from Nokia?
Simon Judge
http://www.simonjudge.com
http://www.mobilephonedevelopment.com
Two things worry me a lot in this posting.
Firstly.
> Developers who want to submit their changes to the relevant package
> owners will in most cases be expected to provide evidence that they have
> tested their changes on the reference execution environment.
This is not *so* bad for companies like Sony Ericsson, although having to buy substantial new amounts of hardware in this difficult economic climate will be painful for them. However for non-corporate developers this makes it significantly harder for people to become involved in working on the OS compared to, for example, Linux or Eclipse.
Secondly.
> These developers will be able to copy their own applications onto the
> device and see how they work.
Since the Foundation must be striving for backwards API compatibility with previous Symbian releases I would hope that application level programs could be tested on an 9-series-OS smartphone (functionality permitting).
I was under the impression that the Foundation would be distributing a tailored version of QEMU to remove the need to developers to have reference hardware. Has this idea been abandoned now?
Hi Dan,
>Will Zoom 2 be the only hardware reference execution environment?
The reference execution environments are decided by Symbian’s Architecture Council. They can decide to select more than one hardware reference execution environment for each Symbian platform release.
There can also be other hardware reference boards, supported by vendors, but where there is no commitment from Symbian Foundation to run the entire test code on the reference board for each biweekly build. (We use the term “VSEE” for a board in this latter category – standing for Vendor-Supported Execution Environment. We also use the abbreviation REE for Reference Execution Environment.)
>Will Symbian OS work on ATOM platforms?
It will depend on someone stepping forward to do the work of converting relevant parts of the Symbian platform software to run on this platform. (That’s the open source way…)
Hi Simon,
>Will the new Zoom2+Symbian^3 include common S60 bits?
Yes. A Symbian platform release contains software that used to be separately available as the S60 layer, as well as the software that used to be separately available as the Symbian OS layer.
Hi David,
>having to buy substantial new amounts of hardware in this difficult economic climate will be painful for them
Your comments made me realise my original posting was incorrect. I’ve edited the posting. Instead of “Developers … will in most cases be expected to provide evidence that they have tested their changes on the reference execution environment” this sentence now reads “Developers … tested their changes on a reference execution environment.
>I was under the impression that the Foundation would be distributing a tailored version of QEMU to remove the need to developers to have reference hardware
Yes, there will be a PC-hosted REE as well as a hardware REE. The PC-hosted REE will be either an emulator or a simulator.
>Since the Foundation must be striving for backwards API compatibility with previous Symbian releases I would hope that application level programs could be tested on an 9-series-OS smartphone (functionality permitting)
That’s another good point! Yes, each new Symbian platform release should preserve the public APIs from previous releases. However, a different category of APIs (known as “platform APIs”) are allowed to change between releases. A developer who uses platform APIs in an application may want to test a new version of their app on a hardware REE. (They will probably want to test their app on a PC-hosted REE too. But different REEs will vary in how much functionality they provide. So there can be advantages, in some cases, to testing on a hardware REE.)
// David W.
Is there any chance that we’ll see a “real” ARM architecture Symbian OS emulator, any time soon? (Based upon QEMU or similar, maybe).
A couple of points:
1) The website says $1150 – that’s an awful lot (although not unusual for a limited production reference platform – the gigantic screen can’t help either). I still think that a developer version of a production phone (assuming a manufacturer agrees to allow it) would be a much better choice for a reference platform – this hardware is slightly less interesting than the OmniaHD and has the major disadvantage of being too big to carry around.
2) The one thing that might make this platform more interesting to some than a production phone would be if it had a full open source base port. That isn’t made clear on the website, indeed under software it says:
Open source Linux BSP based on kernel 2.6.22 available from TI and the open source community
Any chance of some clarification there?
Mark
Have you considered naming the reference desing platform as Zombian^2. Zoom 2 + Symbian^2 = Zombian
I suppose the title should say “The first hardware reference execution environment” because the term Design leads one thing the industrial design, for which the Zoom2 hopefully will not be a reference
So Zoom2 will be used for executing and verifying that the code in Foundation works but real device designs will hopefully be a lot prettier and smaller.
// Yes, there will be a PC-hosted REE as well as a hardware REE.
// The PC-hosted REE will be either an emulator or a simulator.
It seems risky to rely on the existing emulator to provide a REE for contributors and to make the statement that the foundation will not commit to running the entire test code on the reference platform.
It’s too easy to write code which out of the box won’t work in a hardware (or ARM execution) environment. If I was a package owner and someone gave me a significant submission that was only tested on the emulator I wouldn’t touch it with a bargepole.
I could understand the SF position if there was ARM architecture simulator environment available instead. This should virtually eliminate most runtime problems and reduce the field of issues of making a component work on real hardware to adaptation/configuration problems or at worst timing issues.
Then again I guess you are reliant on the significant contributors to close the gap, and in the early days I’d expect these contributors are for practical purposes almost entirely Nokia – who you expect to test things on hardware as a matter of course.
But it does raise some interesting questions.
If a component breaks on hardware, who fixes it?
Is there any commitment from package owners/integrators to test on hardware? Further to this how are different system configurations handled – if someone only tests in an XIP ROM configuration their component may not work in a NAND based, or demand paged environment. Who fixes these problems or will any issues have to be fixed ‘on demand’?
It there a commitment to ensure that components are buildable with the RVCT toolchain? One might also mention GCCXML as well. It does make one wonder if there is a future for a $5000 development environment in the SF world.
It would be great if S^1 and S^2 would also be validated on the Zoom board. What is the plan regarding the validation environment of these earlier releases?
Hi Tyson,
>Is there any chance that we’ll see a “real” ARM architecture Symbian OS emulator, any time soon? (Based upon QEMU or similar, maybe)
Short answer: Yes!
Longer answer: Details will be announced shortly.
Hi Mark,
>I still think that a developer version of a production phone (assuming a manufacturer agrees to allow it) would be a much better choice for a reference platform
If any phone manufacturer comes forward with any such proposal, I’m sure the Architecture Council will be very interested to review it!
>one thing that might make this platform more interesting to some than a production phone would be if it had a full open source base port. That isn’t made clear on the website
The reason this isn’t made clear is because it’s still an open question.
Hi Antti,
>Have you considered naming the reference design platform as Zombian^2
Interesting suggestion!
Simple answer: the naming is up to the manufacturer.
Longer answer: Since this hardware is capable of running other operating systems, in addition to Symbian, I guess that it would be presumptive to change the name like this
Hi Kimmo,
>the term “Design” leads one to think of industrial design, for which the Zoom2 hopefully will not be a reference
Fair point!
I was thinking of having “The first hardware reference execution environment” as the title, which would have been more accurate. Then I thought I should pick a shorter title. However, the brevity sacrificed some accuracy. Sorry!
// David W.
Hi tl,
>the foundation will not commit to running the entire test code on the reference platform
Actually, Symbian does commit to running the entire test code on all the agreed REEs (Reference Execution Environments). There will be at least two REEs for each platform release – one being PC-hosted, and one being a separate piece of hardware, such as the Zoom 2. So the entire test code will be run on at least two REEs during each release cycle.
>It’s too easy to write code which out of the box won’t work in a hardware (or ARM execution) environment. If I was a package owner and someone gave me a significant submission that was only tested on the emulator I wouldn’t touch it with a bargepole.
I completely agree!
However, the key word here is significant. If the contribution is smaller, a package owner may elect to adopt it with a lower threshold. (This is the point made well, earlier in this discussion, by David Durant.)
>raise some interesting questions…
Yes, these are good and important questions. The new beta Symbian developers wiki currently has 39 pages on the topic of “Symbian Platform Contributor Guidelines”. I’m sure that some of that material will find its way into this blog before too long!
>If a component breaks on hardware, who fixes it?
If the hardware is an agreed REE, the package owner will take the responsibility to find a fix. If it’s different hardware, the question will in general fall to the entire development community. If the community deems this particular use case (ie the combination of software and hardware) important enough, the community will come up with a fix.
>One might also mention GCCXML
The intent is that all components will, in time, be buildable using the (zero cost) GCC toolset. To start with, a number may only be buildable under RVCT.
>it does make one wonder if there is a future for a $5000 development environment in the SF world
The quality of the code produced by RVCT is likely in some cases to be significantly better (in terms of codesize and execution speed) than code produced by GCC. If this quality difference is sufficiently important to a vendor, they will want to invest in the RVCT tools.
// David W.
Hi Tuukka,
>It would be great if S^1 and S^2 would also be validated on the Zoom board. What is the plan regarding the validation environment of these earlier releases?
Symbian^2 is the first platform release where the code is stored in the Symbian Foundation repository and where Symbian Foundation processes are applied.
The validation of software earlier than Symbian^2 follows the processes in place at Symbian Software Limited (“Symbian v1″) and at Nokia S60.
Symbian^2 is a transitional release, with much of the software already created before the Symbian Foundation processes ramped up. The individual package owners will specify their own policies regarding validation of software (such as bug fixes) that is submitted for inclusion in Symbian^2.
// David W.
Hey Mark / David,
>>The one thing that might make this platform more interesting to some than a production phone would be if it had a full open source base port. That isn’t made clear on the website
Fair point! I can say the TI team is working on updating this info. Its our intent to make available the baseport – with the general philosophy of making available what we’ve made available in linux. And rest assured we’re not just updating info on websites – we’re also doing the work to update the tree to match the SF base, updating license.txt files, reviewing what we want to make available in source vs binary etc.
@Kevin – Excellent news, thanks for the update!
This looks interested, but what about compilers variants.
Having just finished tracking down a rather nasty gcce bug in 5.0, will we see mandated builds against specific compilers to check the code works on the supported platforms. Or at least notes saying the platform was built against baselined RVCT 2.2 Rev x.y
I am in particular thinking of this issue (https://developer.symbian.com/wiki/display/KBSDN/Global+writeable+static+data+in+DLLs+does+not+appear+to+work+when+projects+are+compiled+with+GCC-E.+What+can+I+do+about+this)
[evil mode]
Why the picture of the device is the homescreen of Android with a Symbian-logo background?
[/evil mode]
Hi detronizator,
>evil mode…
You don’t have to look too far to see a video of Zoom 2 running Symbian code. TI have been showing Zoom 2 running a number of different operating systems (including Symbian) at several trade shows.
// David W.
@DavidW: I did, I did.
But looked “strange” to see this particular screenshot here
5 Trackbacks
[...] fà sapere David Wood, dal blog ufficiale della Symbian Foundation, che con la seconda metà di quest’anno gli sviluppatori di tutto il mondo esamineranno il [...]
[...] I was reading about Texas Instruments Zoom(TM) OMAP34x-II MDP, the first hardware reference design for Symbian^3 (future opensource version of SymbianOS). And I’ve found that it seems some [...]
[...] parte del software che la comporrà era già pornto prima che la Foundation iniziasse a funzionare (SymbianFoundationBlog). Ma andiamo a vedere quali sono le specifiche di questa pittaforma di sviluppo, presentata al [...]
[...] parte del software che lo comporrà era già pronto prima che la Foundation iniziasse a funzionare (SymbianFoundationBlog). Ma andiamo a vedere quali sono le specifiche di questa pittaforma di sviluppo, presentata al [...]
[...] the Symbian Foundation blog, David Wood notes [...]