On Sun, 31 Jul 2016 17:05:52 +0000 (UTC) Craig Comstock <craig_comstock(a)yahoo.com> wrote: [...] 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… [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.