layer 1 port to nuttx-bb progress?
Denis 'GNUtoo' Carikli
GNUtoo at no-log.org
Fri Aug 12 19:00:19 UTC 2016
On Sun, 31 Jul 2016 17:05:52 +0000 (UTC)
Craig Comstock <craig_comstock at yahoo.com> wrote:
> I have fernvale-nuttx running on a couple of MTK6260-based watch
> phones and plan on working on porting layer1 to these devices.
Here's the story behind the Nuttx port of osmocomBB:
Me and Alan worked together to:
- Adapt the previously existing Nuttx port to run on the devices we
- 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
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 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
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, 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.
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
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
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
I also pushed some of the previous code on gitorious.
Note that the gitorious repositories URL now point to a read-only mirror
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
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
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.
 Alan Carvallo De Assis. He is now actively contributing to Nuttx
for his work.
Gitorious was shut down.
I had to relocate in a hurry, the laptops I had with me were 32bit
only (The I945 Thinkpads supported by coreboot).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the baseband-devel