OsmocomBB releases

[Denis 'GNUtoo' Carikli]

Hi,

As I understand it is now possible to have a full software GSM stack in
software[1], with the stock osmocomBB since trx_toolkit target was
merged in OsmocomBB.

Many network side components have releases[2] and several distributions
already have part of the osmocom stack packaged[3][4].

To me having releases for osmocomBB as well also look interesting as
we could then more easily make packages for it. 

It could then be used to test the other components of the stack either
with hardware[5] or with pure software, or to easily install and
keep up to date the tools (osmocon, osmoload, etc).

Would the osmocomBB be interested in doing releases? Or is there
something that is preventing that from happening (lack of interest?,
lack of time/volunteers?, technical issues?).

References:
---
[1]https://osmocom.org/projects/baseband/wiki/FakeTRX
[2]https://projects.osmocom.org/news/152
[3]https://packages.debian.org/search?keywords=osmo=names=stable=all
[4]https://packages.gentoo.org/packages/net-libs/libosmocore
[5]As I understand, it would require either a test license or a specific
   hardware setup with cables, attenuator(s) and a duplexer/circulator
   and to enable transmit support.

Denis.


pgpffNPdS5aEX.pgp
Description: OpenPGP digital signature

Re: layer 1 port to nuttx-bb progress?

[Denis 'GNUtoo' Carikli]

On Sun, 31 Jul 2016 17:05:52 + (UTC)
Craig Comstock  wrote:

> I have fernvale-nuttx running on a couple of MTK6260-based watch
> phones and plan on working on porting layer1 to these devices.
[...]

Port story:
---
Here's the story behind the Nuttx port of osmocomBB:
Me and Alan[1] worked together to:
- Adapt the previously existing Nuttx port to run on the devices we
  had.
- Upstream such support, and add more drivers.

We both stopped working on it for different reasons.

Personally I didn't have time anymore, because of my day job and other
reasons.
Still, I attempted to make a quick and *very* dirty port of the layer1
as a Nuttx application in order to show people that it was possible.

I thought that there was more probability of someone being
interested in picking my work or restarting it from scratch once
something was working.
However I only succeeded at making the device scan the network and then
hang unexpectedly while scanning.

I don't remember which toolchain I was using for that, but there is a
huge probability that I didn't use the one advised by the wiki (gnuarm):
The 32bit[5] version of gnuarm couldn't properly link nuttx and outputed
some message about code being compiled with both -msoft-float and some
other floating point ABI. I might have used a codesourcey toolchain
instead.

Using another toolchain to compile osmocomBB resulted in the same
behavior: the device hanged when scanning the network.

Years later, I learned, thanks to the osmocomBB wiki[2], that the issue
preventing to use other toolchains issue had been resolved.

Since the interest in osmocomBB seem to have progressively faded away,
and I still didn't have time for it, I didn't even try to update the
layer1 port, and to run it[6].

Since the layer1 port was unspeakably dirty, it's preferable to re-port
it from scratch. My attempt was only made in a desperate way, to
foster interest.
If made to work, it could still be used as a reference code that is
known to work, in order to help debugging potential issues with a
cleaner code.

After that, I started to do try to port it correctly but I never
found the time to finish it.

I can try to find the cleaner attempt if you want, but I fear it won't
be that helpful:
It mostly consisted in making a very thin compatibility layer in the
form of a header, wrapping nuttx semantics(function names, etc) to match
osmocomBB's.

I also pushed some of the previous code on gitorious[3].
Note that the gitorious repositories URL now point to a read-only mirror
of gitorious[4].

Code separation, and licensing:
---
Nuttx is under a permissive license while osmocomBB is copyleft.
With Alan, to be able to upstream some of the osmocomBB code, we had to
ask its original authors the permission to relicense it.

You can find the exact terms of such relicensing in the baseband-devel
mailing list archives.

Some authors gave us very clear limitations on what part of the code
they relicensed.

Practically speaking some of the drivers for usual peripherals were
relicensed(like serial port, and so on), but at least one author was
very clear on the fact that he wound not relicense any of the GSM
related drivers and application code he wrote.

I clearly support such views, and it's not a problem at all:
While you need to have the same license than Nuttx to upstream code in
the OS part of Nuttx, you have no such requirements for applications:
Nuttx even has, in its repositories, applications under different
licenses.

Since you want to run the layer1 on the Fernvale, you will then
need to adapt it to your hardware, and have some hardware abstraction
done in the application for the GSM related hardware.
OsmocomBB already have some hardware abstraction in it, as the RF
frontend weren't always the same across supported phones.

References:
---
[1] Alan Carvallo De Assis. He is now actively contributing to Nuttx
for his work.
[2]http://osmocom.org/projects/baseband/wiki/Toolchain
[3]https://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-gta02.git
[4]Gitorious was shut down.
[5]I had to relocate in a hurry, the laptops I had with me were 32bit
   only (The I945 Thinkpads supported by coreboot).
[6]I'm not saying that the "toolchain bug" was the cause, but rather
   that it could have been. Since I didn't test, I've no way to know.

Denis.


pgpqc7_vcvD7w.pgp
Description: OpenPGP digital signature