Skip to content

Symbian kernel is now open source: Driver developement is now possible!

The Symbian has released the kernel as open source! The development environment consists of:

  • Open source kernel and other complementary packages
  • RVCT 4.0 compiler: free for developers and companies of less than 20 employees
  • Open source simulation environment based on QEMU
  • Open source base support package for the low cost Beagle Board

The kit has everything required for Symbian kernel development.Β  I’m planning on testing the new kit and investigating if it would be possible to make my own memory driver to flush the cache for executing code without creating a special memory chunk for the code and using the IMB_Range deal.
Why theΒ  this kind of driver is required, if the there’s already exist an API for self modifying code? Well, it would solve the memory mapping issue, which I explained on the post: Why Symbian is so slow compared to Linux.
The driver would give significant boost for all applications relying on dynamic recompilation, or self modifying code. This would give a big performance boost for emulators such as gpsp and psx4all. I think that the psx4all would probably be playable with the special memory driver.
Developing a driver:
The first phase would be to implement a test software, and the driver with the QEMU. If I’ll get this far, then I could think about purchasing the BeagleBoard, which could be used for verifying the driver functionality with the actual hardware. If the driver works on the HW, then it would probably work on the actual phone too. However, the Symbian platform security will be a big problem preventing the installation of the driver into an actual phone.

Symbian Signed:
The Symbian signed will be a big issue for the driver. I would have to get all capabilities from device manufacturers such as nokia, samsung, and sony ericson to get a legal certificate to install the driver. We all know that’s not going to happen.
I think that the user should be able to turn off the f*cking platform security if they want to. This could be even hidden under some special code, like the phone’s reset is currently implemented. Take also a look of the red pill mode on maemo. I think that Symbian needs something similar. Why not the user to bypass the platform security and let them have open devices.
However, I know that there are already some hacks that can be used to install unsigned applications. You would have to do something like this to get the driver to work on an actual phone.
I don’t want to get your hopes up:
As already being said: The driver development is possible, but it’s not possible to utilize that driver on you own phone. I’m not going to make any hacks for your to help you with the driver installation. I’m only interested to get more speed to the emulators with dynarec. I’ll release all the source code as usual, but I’m not sure if there ever will be a change to create a valid sis installation file for the driver. It’s just a nice thing to try out with the QEMU and the beagleboard.


  1. ReS says:

    Best news EVER, really cause the same guys who made Hellox would possibly make this as a hack so i cant wait now until they do πŸ™‚
    Big news really, what about psx4all? can or will you make it? cause the work you did on AntSnes for S60v5 aka 5800 and n97 are truly awesome work, and with your programming skills you can make a psx4all port for us i am sure πŸ™‚

  2. khan4251 says:

    Really great news?
    Now it is possible to use DSP in some OMAP phones to boost sound?

  3. ohinkka says:

    I still don’t understand why you actually need to have driver for your memory mapping issues… If you know what you are doing, you can create chunks quite easily pretty much at whatever address you want(whatever address being less than 0x80000000). Also I don’t get it why you needed to slow down gpsp by creating jump trampolines for immediate bl instruction, as it is possible to relocate the process code section to whatever address aswell (again, under 0x80000000), which pretty much means that it is possible to stay within +-32mb jump range. Ofcourse relocating the code section requires some assembly trickery and does have some caveats, but I’ve actually used that technique in one dynarec base emulator and it works pretty well… and the best thing is that you can do this already with currently provided system functions in user mode.
    So I think that before you state that Symbian is slow, you really should study how the system works first.

    • Summeli says:

      Well, I have studied how the system works. The problem is that the memory are is over 32mb away from the memory are where the actual program is executing.There is no way to get codechunk memory addresses near to where the actual program is running. I’m not slowing gpsp for this, the problem is that I need 4 more instructions to do the jump from one memory are to another, which is slow.
      If you have some tricks to affect the chunk’s address, please share the info to me too πŸ™‚ The chunk must be created with RChunk::CreateLocalCode command. I don’t see any ways to actually change the base pointer from there!
      Don’t worry. I’ll make some benchmarks with new driver, that fixes the memory mapping issues in Symbian πŸ™‚

      • ohinkka says:

        I still don’t see why you need a driver for this? In the emulator I’m working on, I create chunk for the dynamic code with RChunk.CreateLocalCode, and with some trickery that chunk is created @ address I want. Then I just create another chunk (again with RChunk.CreateLocalCode) whose address is dynamicchunkbase+8mb. I then relocate the process text section(ie. compiler generated code) to that chunk(that requires even more trickery). This guarantees that the dynacec and static code are both within 32mb range -> I can directly use immediate b/bl instuctions to the compiler generated static code without any additional code or trampolines.
        It’s not a problem that you can’t change the base address of a chunk, just have a look what the addresses are when you create few chunks in a row. The addresses are actually sequential, so if you want to create a chunk @ specified address, create one chunk, check it’s base address, if that’s not suitable for you, calculate the offset between the address you want, and the base address of the chunk created. Then delete the created chunk, and create it again with the size being the offset you just calculated. Now create another chunk what is the chunk you actually use, and delete the temporary chunk. If you now check the address of that chunk, it’s surprisingly exactly the address you wanted…

        • Summeli says:

          Woah! Thanks for the tip! This is exactly what I want! Now, if I can get inside that 32mb range, then I really don’t need this driver, and I can get more speed for all dynarec emulators! Thanks a lot! These comments really makes it worthwhile to have a blog. Is it OK to change some emails, if I have some more questions about this?
          Creating the chunk over and over again, until you hit the desired memory range is a really good idea. I wonder how I didn’t thought about that πŸ™‚ It sounds really obvious solution now. Well, I’m going to test this first with the gpsp. It should give a really nice performance boost for it πŸ™‚

          • ohinkka says:

            I guess that atleast you can see my email, so go ahead. You could also use finnish in private emails πŸ™‚

  4. cansual says:

    WoW that sounds good summeli nice too hear that from you. Is it possible to play antsnes now with good sound on symbian

  5. LiL_Stenly says:

    Sorry if I’m asking this question, I’m still not a programer so can you reply to them with few words?
    I see that you resolve one of your problems, mapping memory, but what about “No direct access to the frame buffer”, is there anyway any way to be done now?
    And about the “driver”… if your phone is hacked then you just to turn off security of the device and install it, right?

    • Summeli says:

      The framebuffer issue still remains, but Symbian Foundation is talking something called DirectUI. I haven’t seen any documentation, so I don’t know what that means, but name of that concept sounds promising, so that issue might be solved in future.

      • LiL_Stenly says:

        You mean that they maybe will include this DirectUI in the firmware update for all phones?
        I’m not so sure about it! πŸ™‚
        Anyway, when the kernel is open source there can be done a lot of things.
        P.S. Thanks for the reply… I’ll keep my eye for some news.

        • Summeli says:

          The DirectUI will be in Symbian^4, so they probably won’t include it in future firmware updates. But it’s nice to think that these problems could be solved in my next phone πŸ™‚

  6. Jordane BR says:

    Congratulations initiative !!!!! Pending!! Good luck!

  7. nsx says:

    Very interesting. But, what is simbian’3 and simbian’4? What phones will have that platform? Maybe N900? But there is Maemo, not simbian. And the number? Simbian OS 10? I’m REALLY confused! Could you explain?
    And again. Thank you.

Leave a Reply