Comments (7)
Hi @knowledgejunkie,
First of all, thank you for taking the time to bring this up. It's an angle I hadn't even considered. I'm going to cc @jaustin who is both familiar with this project and also work[s|ed] for ARM in the group responsible for yotta. If he can't clarify the situation, he'll probably know someone at ARM who would be able to advise.
@jaustin, the question is if it's OK for the firmware for MicroPython on the micro:bit (built, in part, using yotta which is, apparently, non-free) to be distributed in an MIT licensed project like uflash. I.e. as @knowledgejunkie says, we want to check such a situation is compatible with the more restrictive licensing of some of the upstream source (yotta).
IANAL, but I'm thankful people like you folks are looking at this.
from uflash.
Hi all,
I can probably clarify a few points.
Is it possible for uflash to pull a runtime from a micro:bit, validate that it is a MicroPython runtime, and then reflash the device after inserting the desired Python scripts, or is the process write-only?
Unfortunately the micro:bit could have any other type of program in the nRF51, so we can't count on MicroPython being present.
The reason for the query is that the MicroPython runtime, as built via yotta and distributed with uflash/Mu, is built partly (as far I can see following the yotta build dependency chain) from sources that include non-free code (https://github.com/ARMmbed/ble-nrf51822 for example). Please correct me if this is not the case.
The DAL pulls libraries from Mbed (I believe they are Apache licensed, but haven't got through all of them) and the Nordic nrf51 SDK, which comes with the Nordic soft devices.
The diagram in this link is a bit outdated, but is still a good representation for the MicroPython stack (microbit-dal and microbit-runtime are the interchangeable names): https://lancaster-university.github.io/microbit-docs/concepts/
I think the soft device might be the biggest problem here as it is redistributed as a binary blob without source code. However, the MicroPython build is configured to not add the softdevice (it uses the bbc-microbit-classic-gcc-nosd
target). This is because the softdevice contains the BLE functionality and consumes too much memory to run alongside MicroPython, and so all BLE code in the micro:bit DAL has define guards to be compiled-out from MicroPython builds.
@knowledgejunkie I believe all the source code published in those repos have an open source licensed. Was the soft device the only worry?
@jaustin, the question is if it's OK for the firmware for MicroPython on the micro:bit (built, in part, using yotta which is, apparently, non-free) to be distributed in an MIT licensed project like uflash . I.e. as @knowledgejunkie says, we want to check such a situation is compatible with the more restrictive licensing of some of the upstream source (yotta).
Yotta is just a build system, which is Apache licensed. In this case the question is about the source code and blobs retrieved by Yotta to build the DAL and MicroPython.
from uflash.
@carlosperate awesome response. Thank you. @knowledgejunkie is this enough to answer your query? AFAICT, all the code use in MicroPython for the micro:bit is liberally licensed (@carlosperate, the BBC told me they prefer Apache over MIT, so it makes sense the DAL is Apache).
from uflash.
Hi all, sorry I'm a bit late to the party....
The DAL is MIT licenced https://github.com/lancaster-university/microbit-dal/blob/master/LICENSE and as Carlos points out, the yotta target we use for building MicroPython (bbc-microbit-classic-gcc-nosd does not include any SoftDevice binaries). https://github.com/lancaster-university/microbit-targets/tree/master/bbc-microbit-classic-gcc-nosd
Aside from that, SoftDevice is licensed by Nordic for redistribution with mbed: https://github.com/ARMmbed/ble-nrf51822/blob/master/LICENSE and https://github.com/ARMmbed/ble-nrf51822/blob/master/softdevice_nrf51822_licence_agreement.txt - I guess it is up to individual projects to rule on the compatibility of that licence with their criteria.
Yotta itself doesn't include the target code, so should be uncomplicated.
from uflash.
@carlosperate @jaustin Thank you both very much for your responses and for making explicit the fact that the yotta build target (and final binary) for the micro:bit does not include any SoftDevice binaries.
A key next question is whether it is possible to build the MicroPython runtime with yotta from completely local sources without requiring:
- an mbed account
- a network connection
- SoftDevice binaries present
Having the full source for the MicroPython build chain available and buildable locally is a key requirement for getting projects that include (or strongly depend on) the firmware into Debian main.
(Please note that yotta itself is not yet packaged in Debian.)
from uflash.
By way of a short update, I've built the DAL locally on Debian testing/sid (using yotta and uflash from pip whilst their packaging) without the non-dfsg-compatible SoftDevice binaries present, flashed my microbit and tried a few examples, which work \o/.
Building the firmware with the current buildchain dependencies in Debian testing/sid did not work out-of-the-box (as others have also found) but it did seem to generate a working micropython environment. I also noted that the filesize of the generated firmware is different to that recently committed to uflash - I'm thinking this is due to differences in the build toolchain only (maybe @carlosperate or @jaustin can confirm? I am not a cpp developer and installed the deps per the micropython instructions).
In terms of packaging for Debain, the next steps as I see them are:
- package yotta (need to file an ITP, and which is reported to be discontinued upstream...)
- get the firmware building from pristine source in a chroot without network access using the packaged yotta
- split the microbit firmware out into its own package (microbit-firmware? need to file an ITP) as other applications/utilities may want it available
- package uflash, repackaging to remove all copies of the included firmware (firmware.hex and uflash.py) and adding a dependency on the new microbit-firmware package and ensuring it can find the installed default firmware file. The latter issue will require patching to make it DWIM out of the box.
Similarly for mu:
- repackage to remove the included convenience uflash/firmware and add a dependency on the new uflash package and again ensuring it finds the system installed uflash script and firmware file.
With builds working without the SoftDevice binaries present, it looks (to me at least) like the firmware (and any packages which depend on it) is suitable for the main part of the Debian archive \o/
from uflash.
Closing this, as building the firmware locally seems possible once yotta and it's missing dependencies are available in Debian.
Thanks for everyone's input.
from uflash.
Related Issues (20)
- Is it possible to flash several .py files simultaneously? HOT 1
- Performance penalty if firmware hex string is dropped? HOT 4
- Please tag releases
- uflash wont flash a 8176 byte script HOT 2
- uflash fails to find microbit HOT 1
- flashing a script is different from putting a main.py HOT 1
- uflash needs a --port option HOT 1
- Flashing with custom micropython is not working HOT 6
- Check .hex file burning completed in microbit HOT 3
- If my computer is plugged into two microbits, how do I know which serial port corresponds to which microbit device?Through VID PID?
- installing uflash gives an error HOT 2
- uflash cannot generate hex for microbit v2. HOT 14
- Error extracting Qtruck-BLE.hex: 'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte HOT 3
- py2hex? HOT 1
- with --runtime disabled, how to upload a new hex file? HOT 4
- Next uFlash release HOT 1
- where do i put microbit.hex so uflash will use that?
- I can't import log HOT 5
- uflash : The term 'uflash' is not recognized as the name of a cmdlet HOT 2
- The 'runtime' flag is no longer supported
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uflash.