Hi list, After some break finally I managed to describe and commit all changes made to MT6235 Linux port during last one and the half month. Currently I got full Angstrom Linux distribution running with UI. Now you can run everything what I'm writing below without changing Sciphone's original firmware. Just use osmocon to load U-Boot to RAM and SD card which has rootfs (with Linux kernel placed in /boot/uImage). For the beginning I chose OPIE, which runs on both versions of Sciphone - with 32MB and 64MB of RAM. OPIE is based on Qtopia which is lightweight and runs pretty fast on MT6235. When you run OPIE on Sciphone G2 it works as full blown PDA. In OPIE there is no telephony support. I also ran X window server with blackbox and matchbox window managers. It runs fine with this difference that sometimes I got oops messages concerning memory on phones with 32MB of RAM . I'll investigate it in the future. Next step is running SHR and Android (probably only on 64MB versions). Android will be working very slow, but from marketing point of view "Android" is magic word so I guess it'll bring more interest into project. For building Linux distributions I chose OpenEmbedded where you can build a lot of Linux variations. To be able to do this I prepared patch which adds Sciphone G2 target and adds U-Boot and Linux kernel repositories from OsmocomBB project. All details regarding OE are described on wiki: http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 With above patches you're able now to build Linux distribution with any configuration by yourself (Angtrom, SHR, QTE, OPIE, GPE, etc.). Video presenting how Angstrom Linux with OPIE is running on Sciphone G2 is placed under following link: http://www.youtube.com/watch?v=-_guRruQi0I As you can see, there is already new OsmocomBB logo. When it's on white background, it means that U-Boot is running, when it's on black background it menas that Linux is starting up. On above video I used phone (32MB of RAM) which has only U-Boot flashed, everything else is running from SD card. Unfortunatelly OPIE has a lot of elements on boarders of screen (scrolling, application close, etc.) and Sciphone's touchscreen has pretty bad quality and it doesn't work well. You have to be patient while operating it. In the middle of screen it works pretty well. I'm going to improve touchscreen driver, so hopefully it'll work better. I prepared ready to load images from above presentation for people who want to try it out without building: http://downloads.qi-hardware.com/people/marcin/sciphone_g2_mt6235/images/ Below is short status what's going on now in Linux work. Peripherals which are already running under Linux: 1) GPIO 2) clocks 3) timers 4) SD card 5) LCD frame buffer 6) touch screen 7) keypad 8) NAND - not yet finished under Linux as I had no motivation to finish it (it fully runs under U-Boot) 9) RTC - not yet integrated 10) U-Boot has been rebased to newest version and commit history was cleaned - preparations for mainlining of Sciphone G2 port Topics on which we're working now: 1) rebase Sicphone's kernel to newest version 2) USB 3) Audio - needs to know how DSP is working 4) Android porting I hope above software will also run on your devices. BR, Marcin
<SNIP awesome announcement details> First I'd like to just say it's awesome that you are doing this, I've been following the various efforts to get open software on phones, and your progress is heartening.
Unfortunatelly OPIE has a lot of elements on boarders of screen (scrolling, application close, etc.) and Sciphone's touchscreen has pretty bad quality and it doesn't work well. You have to be patient while operating it. In the middle of screen it works pretty well. I'm going to improve touchscreen driver, so hopefully it'll work better.
One thing you might want to look into is translating the touchscreen interface into a touchpad interface. I use this setup when using VNC to connect to a desktop system remotely from my phone, and having the absolute events translated to relative events seems to be the most usable option for interacting with the tiny desktop elements. Thanks, Kevin <SNIP awesome progress details>
BR, Marcin
Hello. On Thu, 2011-02-17 at 16:23, Marcin.Mielczarczyk@tieto.com wrote:
After some break finally I managed to describe and commit all changes made to MT6235 Linux port during last one and the half month. Currently I got full Angstrom Linux distribution running with UI. Now you can run everything what I'm writing below without changing Sciphone's original firmware. Just use osmocon to load U-Boot to RAM and SD card which has rootfs (with Linux kernel placed in /boot/uImage).
Nice progress. :)
For building Linux distributions I chose OpenEmbedded where you can build a lot of Linux variations. To be able to do this I prepared patch which adds Sciphone G2 target and adds U-Boot and Linux kernel repositories from OsmocomBB project. All details regarding OE are described on wiki:
Are you planning to change the OE patch soon or would you like to get it into the OE tree? If you are fine with its current state I could review it for you and push it when it is ready. (Well, Holger could do it as well but I think he is busy enough :)) regards Stefan Schmidt
Hi Stefan,
Are you planning to change the OE patch soon or would you like to get it into the OE tree? If you are fine with its current state I could review it for you and push it when it is ready. (Well, Holger could do it as well but I think he is busy enough :))
For initial support of Sciphone G2 this patch is sufficient and I don't plan to change anything at the moment. Probably while building new features there will be need to add new options, but then I can create incremental patches. In this case I'm definitely fine to get this patch in OE tree. You can only change PV variable in "linux-mtk_git.bb" recipe to 2.6.37 wich will be available on OsmocomBB repository today. Thank you for support. BR, Marcin
Hello. On Fri, 2011-02-18 at 09:56, Marcin.Mielczarczyk@tieto.com wrote:
Are you planning to change the OE patch soon or would you like to get it into the OE tree? If you are fine with its current state I could review it for you and push it when it is ready. (Well, Holger could do it as well but I think he is busy enough :))
For initial support of Sciphone G2 this patch is sufficient and I don't plan to change anything at the moment.
Good.
Probably while building new features there will be need to add new options, but then I can create incremental patches.
Indeed. Thats easy enough.
In this case I'm definitely fine to get this patch in OE tree. You can only change PV variable in "linux-mtk_git.bb" recipe to 2.6.37 wich will be available on OsmocomBB repository today.
Great. I will do some review and testing tomorrow to get the patch in.
Thank you for support.
No problem. regards Stefan Schmidt
Coincidently, I had rebased Marcin's kernel to 2.6.37. You can find it under "target/linux/mt623x" of this OpenWRT port: http://ac.nl.eu.org/mt623x/ Regards, André On 17/02/11 15:23, Marcin.Mielczarczyk@tieto.com wrote:
1) rebase Sicphone's kernel to newest version
Coincidently, I had rebased Marcin's kernel to 2.6.37. You can find it under "target/linux/mt623x" of this OpenWRT port: http://ac.nl.eu.org/mt623x/
Thanks for information. Wolfram Sang have written me already that he also rebased Sciphone G2 kernel to newest one without issues, so I don't expect problems here. Today I'll commit rebased kernel to OsmocomBB repository. BR, Marcin
Hi Marcin, awesome work again! One comment:
Today I'll commit rebased kernel to OsmocomBB repository.
Please don't rebase against linux-next again. Latest tag should be fine (2.6.38-rc5 as of now); Russell has a devel-branch you can check your patches against shortly before sending them (when they are ready). Regards, Wolfram
This is a very nice effort. I have an HTC Kaiser running FroYo, and I would like to add some observations based on this phone, which is more capable in every respect than the G2. The Kaiser is just barely adequate. While the G2 can run Linux, and by extension, Android, it's just too underpowered to make it usable, IMHO. I haven't seen Android on more modern hardware, but I imagine it would be similar in responsiveness to the iPhone 4, which is VERY smooth. It's too bad that there doesn't seem to be any alternative that is responsive enough on lighter, but still capable, hardware like this.
There isn't any good open source alternative to run on this but one could be crafted I guess. There's Meego which has a Qt interface that could be slimmed down and should run on Qt on the framebuffer and there's also some open source Qt stuff for Symbian that might be portable to Linux. This is just an idea but I'm planning on investigating this as it certainly sounds better to me than Android. I like Qt and C++ better and it's better option for such a low end configuration anyway. P.S. : Sorry for the offlist response , damn gmail - Hide quoted text - On Fri, Feb 18, 2011 at 2:40 AM, Scott Weisman <sweisman@pobox.com> wrote:
This is a very nice effort. I have an HTC Kaiser running FroYo, and I would like to add some observations based on this phone, which is more capable in every respect than the G2. The Kaiser is just barely adequate. While the G2 can run Linux, and by extension, Android, it's just too underpowered to make it usable, IMHO. I haven't seen Android on more modern hardware, but I imagine it would be similar in responsiveness to the iPhone 4, which is VERY smooth. It's too bad that there doesn't seem to be any alternative that is responsive enough on lighter, but still capable, hardware like this.
Guys, this is a mailinglist about runnign custom Free Software on the _Baseband_ processor of a telephone. Please keep it on-topic. This is not a discussion forum for the various official or unofficial Linux ports to application processors in phones (like htc-linux, iphone-linux, Openmoko, OpenEZX, etc.) Thanks. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Maybe it's more blue sky than current focus, but these goals are on the wiki page (http://bb.osmocom.org/trac/wiki/MasterPlan) as long term goals: - Port some minimalistic RTOS that already supports ARM7TDMI well to the Calypso - Attempt to move L2 from PC into the phone - Attempt to move l3 from PC into the phone Maybe the page needs to be updated if the above are no longer goals of the project. Scott On Fri, Feb 18, 2011 at 12:32 PM, Harald Welte <laforge@gnumonks.org> wrote:
Guys,
this is a mailinglist about runnign custom Free Software on the _Baseband_ processor of a telephone.
Please keep it on-topic. This is not a discussion forum for the various official or unofficial Linux ports to application processors in phones (like htc-linux, iphone-linux, Openmoko, OpenEZX, etc.)
Thanks.
-- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Feb 18, 2011 at 12:50:37PM +0200, Scott Weisman wrote:
Maybe it's more blue sky than current focus, but these goals are on the wiki page (http://bb.osmocom.org/trac/wiki/MasterPlan) as long term goals:
- Port some minimalistic RTOS that already supports ARM7TDMI well to the Calypso - Attempt to move L2 from PC into the phone - Attempt to move l3 from PC into the phone
Maybe the page needs to be updated if the above are no longer goals of the project.
I don't understand your comment. The ARM7TDMI that we are talking about is the _baseband_ processor. The long-term goals still exist as they stand in the wiki. What has been discussed previously on this thread (and triggered my response) was running Linux on HTC phones and the like. That was about the _applicaiton_ processor. Marcin's work is different, as we are talking about a port of Linux to the (in this case ARM926EJS) _baseband_ processor of a phone. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
I have to apologize, because I think I am missing something here. Does the G2, or any of the phones that OsmocomBB currently supports, have more than one ARM CPU? I vaguely recall reading an email on this list that one of the ways the G2 was able to keep costs down was not have separate baseband and app CPUs. Plus, all the wiki pages I've read, seem to indicate not. I don't understand your comment. The ARM7TDMI that we are talking about is
the _baseband_ processor. The long-term goals still exist as they stand in the wiki.
What has been discussed previously on this thread (and triggered my response) was running Linux on HTC phones and the like. That was about the _applicaiton_ processor.
Marcin's work is different, as we are talking about a port of Linux to the (in this case ARM926EJS) _baseband_ processor of a phone.
From what I understand MT6235 has just one ARM926EJS processor and a DSP. This probably means that the it runs both the application and the GSM stack on a single CPU , right ? I read in an article about Symbian that it's able to do this because it's a realtime OS but to my knowledge Linux is not ( hence the GSM stack runs on a second processor in Android phones ). Now I also know there's a realtime Linux kernel but the question is would it be possible to run both the application and GSM stack together on the MT6235 under Linux. Please excuse my question if they're newbish. Thanks. On Fri, Feb 18, 2011 at 6:42 AM, Scott Weisman <sweisman@pobox.com> wrote:
I have to apologize, because I think I am missing something here. Does the G2, or any of the phones that OsmocomBB currently supports, have more than one ARM CPU? I vaguely recall reading an email on this list that one of the ways the G2 was able to keep costs down was not have separate baseband and app CPUs. Plus, all the wiki pages I've read, seem to indicate not.
I don't understand your comment. The ARM7TDMI that we are talking about is the _baseband_ processor. The long-term goals still exist as they stand in the wiki.
What has been discussed previously on this thread (and triggered my response) was running Linux on HTC phones and the like. That was about the _applicaiton_ processor.
Marcin's work is different, as we are talking about a port of Linux to the (in this case ARM926EJS) _baseband_ processor of a phone.
On Fri, Feb 18, 2011 at 3:27 PM, Marius Cirsta <mforce2@gmail.com> wrote:
From what I understand MT6235 has just one ARM926EJS processor and a DSP. This probably means that the it runs both the application and the GSM stack on a single CPU , right ? I read in an article about Symbian that it's able to do this because it's a realtime OS but to my knowledge Linux is not ( hence the GSM stack runs on a second processor in Android phones ). Now I also know there's a realtime Linux kernel but the question is would it be possible to run both the application and GSM stack together on the MT6235 under Linux. Please excuse my question if they're newbish.
Under Linux probably not, under RT Linux maybe. Depends on the amount of work done by DSP, CPU load by applications etc... Nothing prevents you to implement stack and applications handling on the single CPU except performance limitations (but you should have in mind memory isolation, security issues, etc). As a matter of fact, what becomes more and more attractive now days are L4 hypervisors, which could separate BB and APP system in the separate containers, running on the same CPU. BR, Drasko BR, Drasko
Hi, On Fri, Feb 18, 2011 at 03:52:53PM +0100, Drasko DRASKOVIC wrote:
As a matter of fact, what becomes more and more attractive now days are L4 hypervisors, which could separate BB and APP system in the separate containers, running on the same CPU.
The only reason why commercial companies (most notably ST-Ericsson) with proprietary GSM stacks use this is to make sure they don't have to release any of their proprietary code under GPL. There is absolutely no technical reason why you cannot do a GSM L1 inside the regular Linux kernel. You just have to do it in a GPL-compatible way :) -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Feb 18, 2011 at 6:57 PM, Harald Welte <laforge@gnumonks.org> wrote:
Hi,
On Fri, Feb 18, 2011 at 03:52:53PM +0100, Drasko DRASKOVIC wrote:
As a matter of fact, what becomes more and more attractive now days are L4 hypervisors, which could separate BB and APP system in the separate containers, running on the same CPU.
The only reason why commercial companies (most notably ST-Ericsson) with proprietary GSM stacks use this is to make sure they don't have to release any of their proprietary code under GPL.
There is always a way to insert your PS code in some FOSS system and keep it closed. You can use any BSD licensed system. Apparently with L23 you can do this with Linux, since you are in the userspace, so you do not have to link with GPL'd kernel. L1 can be a baremetal app running side by side with your kernel. I would not say that L4 is used only to close code. It gives you opportunity to clearly separate several systems running on the same core, and have them communicate between themselves in a standardized and secure way. It can also serve as a powerful HAL and can come into play with security requirements. I think we'll be looking a lot of into this in the future... but that's just my $0.2. BR, Drasko
On Fri, Feb 18, 2011 at 07:27:59AM -0700, Marius Cirsta wrote:
From what I understand MT6235 has just one ARM926EJS processor and a DSP. This probably means that the it runs both the application and the GSM stack on a single CPU , right ?
It's actually 2 DSP cores. But yes, your last statement is correct.
I read in an article about Symbian that it's able to do this because it's a realtime OS but to my knowledge Linux is not ( hence the GSM stack runs on a second processor in Android phones ). Now I also know there's a realtime Linux kernel but the question is would it be possible to run both the application and GSM stack together on the MT6235 under Linux.
Don't believe marketing crap by any company (or the Symbian foundation) ;) Layer 2 and Layer 3 of GSM have no realtime requirements, it's only the L1 that has. Running L1 inside the kernel in IRQ priority should solve all those problems. If not, we can still use the FIQ to pre-empt all the other IRQs in the kernel. Layer2 + Layer3 then run as regular userspace programs on top of the kernel. The entire' "realtime vs. non-realtime" debate often seems nothing but a religious and/or marketing war. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Feb 18, 2011 at 7:55 PM, Harald Welte <laforge@gnumonks.org> wrote:
On Fri, Feb 18, 2011 at 07:27:59AM -0700, Marius Cirsta wrote:
From what I understand MT6235 has just one ARM926EJS processor and a DSP. This probably means that the it runs both the application and the GSM stack on a single CPU , right ?
It's actually 2 DSP cores. But yes, your last statement is correct.
Didn't read the datasheet that well it seems.
I read in an article about Symbian that it's able to do this because it's a realtime OS but to my knowledge Linux is not ( hence the GSM stack runs on a second processor in Android phones ). Now I also know there's a realtime Linux kernel but the question is would it be possible to run both the application and GSM stack together on the MT6235 under Linux.
Don't believe marketing crap by any company (or the Symbian foundation) ;)
I usually don't but since I have only basic knowledge in telecom I thought what they said was true and it did acutally make sense.
Layer 2 and Layer 3 of GSM have no realtime requirements, it's only the L1 that has. Running L1 inside the kernel in IRQ priority should solve all those problems. If not, we can still use the FIQ to pre-empt all the other IRQs in the kernel.
Layer2 + Layer3 then run as regular userspace programs on top of the kernel.
The entire' "realtime vs. non-realtime" debate often seems nothing but a religious and/or marketing war.
Thanks for these clarifications , it answers my question. I do have another one though , out of curiosity. Why do most if not all Android phone have a separate core for running the GSM stack ? Even MT6516 has a dedicated ARM 7 core. I cand think of the advantages being isolation of the GSM stack and keeping it hidden and proprietary but until now I thought it was a must.
Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Feb 18, 2011 at 7:54 PM, Marius Cirsta <mforce2@gmail.com> wrote:
Thanks for these clarifications , it answers my question. I do have another one though , out of curiosity. Why do most if not all Android phone have a separate core for running the GSM stack ? Even MT6516 has a dedicated ARM 7 core. I cand think of the advantages being isolation of the GSM stack and keeping it hidden and proprietary but until now I thought it was a must.
As I said, it is mostly performance issue.
Marcin, I can only second the other people who have commented: Congratulations on your great work! It's good to see that you have still been on track. I was already starting to wonder after the comparatively long period of silence. Unfortunately I still haven't had much time to work on the GSM side of the MTK chipset - though I've spent some 2 days and think I have a farily good understanding of the architecture and the required drivers for the analog/RF side. The biggest unknown part so far is the ARM/DSP shared memory interface, and the "API" (rather an ABI) that is used to exchange information on it. I have done some initial research, but given my high workload with other (interesting + paid) GSM protocol R&D related work, I still cannot make any promises when we'll actually see some progress here. If anyone else feels interested to dive into it, feel free to do so. Especially the RF transceiver driver, TDMA timer driver, etc. should all be possible to develop right now based on the documentation that is available. Those of you with a Racal 6103 or similar device should also be able to take measurements and test the drivers, i.e. whether it tunes to the right Tx frequency, whether the TDMA timer are firing at the right point in time (power ramp up/ramp down, ...) Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
The biggest unknown part so far is the ARM/DSP shared memory interface, and the "API" (rather an ABI) that is used to exchange information on it.
I agree, as I have the same problem here to run audio.
I have done some initial research, but given my high workload with other (interesting + paid) GSM protocol R&D related work, I still cannot make any promises when we'll actually see some progress here.
No problem.
If anyone else feels interested to dive into it, feel free to do so. Especially the RF transceiver driver, TDMA timer driver, etc. should all be possible to develop right now based on the documentation that is available.
I'm gonna dive into this topic. That's something where I don't have experience so it'll take me some time to understand it, but it's worth effort. As I mentioned some time ago I had adventure with L2/3 development and I'm gonna refresh my knowledge. I'm also eager to try something new, so I'll be satisfied stepping down into RF part. BR, Marcin
Marcin, On Fri, Feb 18, 2011 at 12:46:23PM +0200, Marcin.Mielczarczyk@tieto.com wrote:
If anyone else feels interested to dive into it, feel free to do so. Especially the RF transceiver driver, TDMA timer driver, etc. should all be possible to develop right now based on the documentation that is available.
I'm gonna dive into this topic. That's something where I don't have experience so it'll take me some time to understand it, but it's worth effort.
I'm happy to hear this. The problem sort-of is: Do you have the kind of measurement equipment to facilitate that kind of development? In order to e.g. test the VCO/PLL / Transmit code, you would have to have something like a spectrum analyzer or a scope that can go up to at least the GSM900, preferrably up into 1800/1900 MHz. If you want to test the receive side, something like a GSM signal generator (HP 8922, Racal 6103, R&S CMD 55) would be great, as they can transmit a well-known bit pattern (all-1, all-0, 101010101010 and the like) on a configured ARFCN, then configure the RF Transceiver (MT61400 and you can watch the analog baseband signal on an oscilloscope and determine if it mathes the expected singal. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
I'm happy to hear this. The problem sort-of is: Do you have the kind of measurement equipment to facilitate that kind of development? In order to e.g. test the VCO/PLL / Transmit code, you would have to have something like a spectrum analyzer or a scope that can go up to at least the GSM900, preferrably up into 1800/1900 MHz.
If you want to test the receive side, something like a GSM signal generator (HP 8922, Racal 6103, R&S CMD 55) would be great, as they can transmit a well-known bit pattern (all-1, all-0, 101010101010 and the like) on a configured ARFCN, then configure the RF Transceiver (MT61400 and you can watch the analog baseband signal on an oscilloscope and determine if it mathes the expected singal.
I have access to such equipment. I have access to Agilent Spectrum Analyzer E4405B (9kHz - 13.2GHz) and Rohde&Schwarz CMU200 (Universal Radio Communication Tester, it also has spectrum analyzer). In this case there're no obstacles to start, only matter of time available for this project. BR, Marcin
participants (9)
-
André Černâk -
Drasko DRASKOVIC -
Harald Welte -
kevin granade -
Marcin.Mielczarczyk＠tieto.com -
Marius Cirsta -
Scott Weisman -
Stefan Schmidt -
Wolfram Sang