support for L2/3 on chip
<mark.neuhaus@email.de>
2014-08-07 14:42:00 GMT
Does the current version of OsmocomBB supports
to run the layer 2 or the layer 3 on the baseband
chip, now?
I read through the arxiv of the mailing list but
have maybe overlooked this.
best,
\jo
Re: support for L2/3 on chip
Alexander Huemer <alexander.huemer@xx.vu>
2014-08-07 14:55:07 GMT
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
Re: support for L2/3 on chip
Akib Sayyed <akibsayyed@gmail.com>
2014-08-07 15:00:38 GMT
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 :(
Re: support for L2/3 on chip
☎ <Max.Suraev@fairwaves.co>
2014-08-07 16:03:24 GMT
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 ;)
--
--
best regards,
Max, http://fairwaves.co
Re: support for L2/3 on chip
Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
2014-08-07 22:49:30 GMT
-----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 SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJT5AJ+AAoJENWQk6o21VqZii4P/i4Cs1Osxv0z5JmZ/adjlsW/
LzHsLshzMvZZnW3e4kku+Fl1EZJeBl+0q6YEwehwCH0WLFFJYkS+ghSW9wYr6aLJ
1CysZ/qXjDQNJyElXhwn8jcxiMA9wcp9C7R5NY1BxeYhmHkqBtf9d5GFyYHc6/Fs
Hmg2d3dWbArTCSmaMuOzAqNt/PWDefZg9QER1YdmvGLPBXfOAxjBohBEaCDx96Cx
WiyUaoFgo8xx72GpnTsGnOqYj2wC6PStgOTq6Zlplz6zlYZGh7D+raN1FyM//q3+
ebPaZFzQMx7dYx/D4Wly/KeqJRiQEoZWzHXoElgQvguNGl2xXoizgg357qVPyY1u
zMpaAy3uRjKheBSt2QHxT2zDaqRjl/gnTEVbGxo9edKP9cwpl5BZlquYKrxmB5QE
NcZI37hjirUbQv/P63g0gd/aLLWIar0EmW7vvF/peH1bBfuD7irfnbnJ3PsExR/x
6cPwSgLUWFlArO3/hjWfH4HQCYtPB8m5aHU9H7Cfx7+cEi3aRiP5OxE735hNZ6Sb
tRVg7d+uBP6m+j9AEkhRUNoh/sEgZ50If1X/BUBCGctNpvnrqRUIPMZRDzptJn+F
iqhieAmSNx+KgmMSlp5z77sQsU+uQFV3/3+6JCJ+5IpZ2YqMCEuJYk+ND5toBgPn
B44JBng9BKSpCo+uk+1w
=Ojiu
-----END PGP SIGNATURE-----
Re: support for L2/3 on chip
☎ <Max.Suraev@fairwaves.co>
2014-08-07 23:00:05 GMT
08.08.2014 00:49, Denis 'GNUtoo' Carikli пишет:
> And a very limited battery life. The s3c24xx won't be able to suspend
> to RAM...
>
> There was an attempt to port nuttx to osmocombb compatibles phones.
>
Interesting. Could you clarify more technical details? What is needed for s3c24xx to
suspend2ram and what it has to do with nuttx?
Is there some documentation/notes covering current developments?
--
--
best regards,
Max, http://fairwaves.co
Re: support for L2/3 on chip
Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
2014-08-08 07:44:51 GMT
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJT5IABAAoJENWQk6o21VqZaboP/23TuuefLguYEoIA17Z9oSup
6qUhio7i+qHDWMcMPXwgdkY2v7rml07/gPkh/lATw0HLXYpERDApLQ0ZC2j3f7ft
FQoseB6R+etFCc8lq1o0FaK3qBJFZpxTETfkuVtKi9zs1NLGSEg5JTj2xdZKfJJb
33GVyoxUUbG1O5D729zId2SiR95rf7iYDxSE2hCVDPz6ZeqQDCGBOqDyR+ERMRuU
a0obzqplEnUNvMrMllMdaUYJgPlNHsjNN6SRvxu1dtbdeFliAc1Nyq8pNY7agTqB
ndofShXD4sM9MWzxW1pJtxrLB141LsQgQ2TPe10c3XARVfNpz/61VtjBYydY1I3W
VLwDoU2OlY/n8wMywhPJQOUJIyKbmO9iqr7rK+9s9tJRR2cZDMyQ/qlAwrr/c1SY
MOMdmtYzJBIYnhvwNzFrV9NQwSn6aZOY5xRbDl43c9jtrzguHEVpvrfaM6pxzpTp
Mk5NHqotSjXn0ibYhGjd/cKh7c7wxqu7lSTovLbmLM/RwPxbbgwmAUDJJzoosMIH
43y/6L/4Y0+B6CZMntCNMksbfKGCyOukz/MYrJRLOIQMjs7/BoUfz+kFx/Qs0i6K
ZpPmUfdCTmrV5uXHLwmHYCQI3DRXfoIZjOB2d3ryIM99GuV1RLWAmOs3XoJlX5t9
hifNsVhfWr6ljDS8tu+i
=o4Vg
-----END PGP SIGNATURE-----