I did some work to port layer 2 layer 3 on chip . i did ported ccch_scan and cell_log app but too lazy to port mobile app :(

On Thu, Aug 7, 2014 at 8:25 PM, Alexander Huemer alexander.huemer@xx.vu wrote:

Hi,

On Thu, Aug 07, 2014 at 04:42:00PM +0200, mark.neuhaus@email.de wrote:

...

Does the current version of OsmocomBB supports to run the layer 2 or the layer 3 on the baseband chip, now?

No.

Kind regards, -Alex

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thu, 07 Aug 2014 18:03:24 +0200 ☎ Max.Suraev@fairwaves.co wrote:

Instead of porting it to BB directly you can use OpenMoko Neo Freerunner and run mobile on AP while talking to BP from proper GNU/Linux.

Not sure how much work it would be to integrate it with FSO stack but at least you won't have such strict space constraints. BEsides you'll get much nicer screen and other hw features ;)

And a very limited battery life. The s3c24xx won't be able to suspend to RAM... Still there is a recipe for an old version of osmocombb for SHR.

There was an attempt to port nuttx to osmocombb compatibles phones.

It was stopped due to the lack of time of the developers who had some changes in their lives.

I had a *very dirty*[1] port of layer1 on top of nuttx. It blocked during the scanning, it could be related to some compiler issues that were solved more recently. Note that the code has to be cleaned becuase it's very dirty and probably incomplete (some #if 0 [...] #endif might remain).

Beside the dirty layer1 port, we upstreamed a lot of the work in nuttx.

Upstream, in the OS part, the code has to be BSD/permissively licensed. So the code adapted from osmocombb has to be relicensed, which means that the person doing the port: 1) he/she does the port 2) he/she finds all the copyright holders of the particular driver 3) he/she submit upstream

Sometimes writing a new driver is easier and makes more sense (like for the C155 LCD driver).

Upstreaming worked fine for many drivers, and that can work because only some drivers need to be in the nuttx OS part, they accept a lot more licenses(including the GPL) for the nuttx applications. Some developer specifically stated that he won't relicense GSM specific code to BSD, including some GSM specific drivers, so I guess that puting theses drivers inside the application would be fine.

References: - ----------- [1]repository:git://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-gta02.git branch:gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-gta02

Denis

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Fri, 08 Aug 2014 01:00:05 +0200 ☎ Max.Suraev@fairwaves.co wrote:

08.08.2014 00:49, Denis 'GNUtoo' Carikli пишет:

...

And a very limited battery life. The s3c24xx won't be able to suspend to RAM...

If you use suspend to RAM on the s3c24xx, and that the s3c24xx runs the layer 2 and 3, then the layer 2 and 3 won't be able to execute anymore while the s3c24xx is suspended.

So the solution, if you want to use it as a phone, would be to prevent the s3c24xx from suspending, which would mean a very poor battery life.

Denis.