4 ms·

"The SDK is open source" Oh, a BLE MCU with open source code SDK? AFAICT, the BLE code is provided as a binary blob. https://github.com/OpenSiFli/SiFli-SDK/tre

"The SDK is open source" Oh, a BLE MCU with open source code SDK? AFAICT, the BLE code is provided as a binary blob. https://github.com/OpenSiFli/SiFli-SDK/tree/6c82a9b15db49871cf49570b3e3658e214d50610/middleware/bluetooth/lib https://github.com/OpenSiFli/SiFli-SDK/tree/6c82a9b15db49871... Which isn't a problem. But, I wish if something is described as "open source", you could read the source code for it.

pjc50 1y ago
BLE radio device firmware is always going to be provided as binary blobs for a combination of IP and regulatory reasons.
- WJW 1y ago
  I know very little about bluetooth firmware beyond using it for apps and such, but what kind of regulatory reasons are there that prevent publishing source code for bluetooth radios?
  - tcbawo 1y ago
    To avoid intentionally or unintentionally interfering with frequency spectrum it should not be.
  - archi42 1y ago
    The BT blob (or WiFi blob, or general radio blob) often controls low level aspects of the actual RF device. So you can often alter frequencies, power levels and other parameters. This results in the device acting out of spec. Now one might say that's the fault of the person doing the modifications/manipulations, but regulations in various countries require the device to prevent these manipulations. (N.B. I'm not in the exact business, but that's my take away from looking into the topic some time ago)
    - HPsquared 1y ago
      Surely it's possible to maintain control over that while still publishing the source code? Seems like security by obscurity.
      - ratatoskrt 1y ago
        I don't know, I don't think there are many open-source third-party firmware implementations for these kinds of chipsets out there, so it seems pretty well obscured.
      - barrotes 1y ago
        Exactly my thoughts. To avoid out-of-regulation tweaking coudn't they just allow signed code to run? How can I be sure that this closed for, i.e. surveillance reasons? One can publish the source code and still prevent misuse afaik.
        wkat4242 1y ago
        Many modern chips do in fact use signed firmware yes. Technically they could publish the source in that case but I think some patents would prevent them from doing this. Radio stuff is riddled with patents. Also most likely the "why would we" reason. There is no benefit for the manufacturer.
        HPsquared 1y ago
        Why would patents prevent open source? As in, they're afraid of patent trolls trawling their code for "infringements"? If it's concerning their own patents, no need to hide the source code. A patent is literally "letters patent" or public description of an invention. Trade secrets on the other hand I could understand.
        wkat4242 1y ago
        It's often a condition of licensing those patents. NDA's, they're huge in the radio and embedded world. It only became a bit more open when the Arduino and Raspberry projects came along. And even there it wasn't fully open, especially with the Raspberry because Broadcom is one of the worst offenders. I'm surprised how much they were able to open source as-is. I think part of that is that the SoCs powering the raspberry are kinda 'old news', definitely not the bleeding edge kind of embedded tech. The first raspberry basically happened because Broadcom had a whole bunch of old chips they weren't able to sell. Only when it took off they started making some actually for the purpose.
- moring 1y ago
  I understood the criticism to be about describing it as open source when it isn't, i.e. that "We say it's open source because we expect the reader to know that we're not telling the truth" should be replaced by "It's open source except for the BLE firmware blob, which can't be open source due to regulatory reasons." To be fair, the article just repeated the claims made on the GitHub page for the SDK.
- introiboad 1y ago
  Not in Zephyr. There's a full BLE Controller in source code form there.
- 5ADBEEF 1y ago
  Zephyr provides an open source implementation of all layers of the BLE stack. The radios of some devices are documented extensively, Nordic nRF5 devices are probably the best example. The Bluetooth SIG requires that you qualify your device if you advertise that you use Bluetooth IP, similar to what is required for the cellular space. Do you have to do this if you’re just “Bluetooth compatible?” Maybe not. Whatever the case you have to conduct FCC part 15C testing (intentional radiator).
  - solarkraft 1y ago
    > you have to conduct FCC part 15C testing (intentional radiator) Maybe soon you won’t.
    - zwirbl 1y ago
      Care to elaborate?
      - hermitShell 1y ago
        Maybe orange man will abolish the FCC because rules are inefficient
        9283409232 1y ago
        He won't abolish the FCC. It is too efficient at attacking his enemies.
        mrheosuper 1y ago
        looking at his policy to China and Russia, maybe his enemies are not what we thought
        9283409232 1y ago
        His enemies are Americans that don't bow down.
- franga2000 1y ago
  I have yet to see a real case of "binary blob for regulatory reasons". What law prevents open source RF firmware? The device needs to operate in spec and if someone reflashes it with out of spec firmware, that's no different than someone soldering a different resistor onto the PCB or feeding the output of the chip into an amplifier and large antenna. It's a modification by the user and so the user is liable for operating out of spec. And all of this really unrelated to source code, just to reflashablitiy. The code could easily be open, but the productions device could be made unflashable if the law really required it. Yet this is not what we see here. It's IP reasons, and that's fine, but let's not make up additional excuses for them.
  - deleted 1y ago
    [deleted]
  - rollcat 1y ago
    > The code could easily be open, but the productions device could be made unflashable if the law really required it. Excellent point. Many people (myself included) do assume that open source = redeployable, as in GPL3. I guess an e-fuse for read-only is perfectly OK, both from regulatory standpoint, and for ensuring you're running the same code as what you have the source for. That would be cool.

pjc50 1y ago

BLE radio device firmware is always going to be provided as binary blobs for a combination of IP and regulatory reasons.

WJW 1y ago
I know very little about bluetooth firmware beyond using it for apps and such, but what kind of regulatory reasons are there that prevent publishing source code for bluetooth radios?
- tcbawo 1y ago
  To avoid intentionally or unintentionally interfering with frequency spectrum it should not be.
- archi42 1y ago
  The BT blob (or WiFi blob, or general radio blob) often controls low level aspects of the actual RF device. So you can often alter frequencies, power levels and other parameters. This results in the device acting out of spec. Now one might say that's the fault of the person doing the modifications/manipulations, but regulations in various countries require the device to prevent these manipulations. (N.B. I'm not in the exact business, but that's my take away from looking into the topic some time ago)
  - HPsquared 1y ago
    Surely it's possible to maintain control over that while still publishing the source code? Seems like security by obscurity.
    - ratatoskrt 1y ago
      I don't know, I don't think there are many open-source third-party firmware implementations for these kinds of chipsets out there, so it seems pretty well obscured.
    - barrotes 1y ago
      Exactly my thoughts. To avoid out-of-regulation tweaking coudn't they just allow signed code to run? How can I be sure that this closed for, i.e. surveillance reasons? One can publish the source code and still prevent misuse afaik.
      - wkat4242 1y ago
        Many modern chips do in fact use signed firmware yes. Technically they could publish the source in that case but I think some patents would prevent them from doing this. Radio stuff is riddled with patents. Also most likely the "why would we" reason. There is no benefit for the manufacturer.
        HPsquared 1y ago
        Why would patents prevent open source? As in, they're afraid of patent trolls trawling their code for "infringements"? If it's concerning their own patents, no need to hide the source code. A patent is literally "letters patent" or public description of an invention. Trade secrets on the other hand I could understand.
        wkat4242 1y ago
        It's often a condition of licensing those patents. NDA's, they're huge in the radio and embedded world. It only became a bit more open when the Arduino and Raspberry projects came along. And even there it wasn't fully open, especially with the Raspberry because Broadcom is one of the worst offenders. I'm surprised how much they were able to open source as-is. I think part of that is that the SoCs powering the raspberry are kinda 'old news', definitely not the bleeding edge kind of embedded tech. The first raspberry basically happened because Broadcom had a whole bunch of old chips they weren't able to sell. Only when it took off they started making some actually for the purpose.
moring 1y ago
I understood the criticism to be about describing it as open source when it isn't, i.e. that "We say it's open source because we expect the reader to know that we're not telling the truth" should be replaced by "It's open source except for the BLE firmware blob, which can't be open source due to regulatory reasons." To be fair, the article just repeated the claims made on the GitHub page for the SDK.
introiboad 1y ago
Not in Zephyr. There's a full BLE Controller in source code form there.
5ADBEEF 1y ago
Zephyr provides an open source implementation of all layers of the BLE stack. The radios of some devices are documented extensively, Nordic nRF5 devices are probably the best example. The Bluetooth SIG requires that you qualify your device if you advertise that you use Bluetooth IP, similar to what is required for the cellular space. Do you have to do this if you’re just “Bluetooth compatible?” Maybe not. Whatever the case you have to conduct FCC part 15C testing (intentional radiator).
- solarkraft 1y ago
  > you have to conduct FCC part 15C testing (intentional radiator) Maybe soon you won’t.
  - zwirbl 1y ago
    Care to elaborate?
    - hermitShell 1y ago
      Maybe orange man will abolish the FCC because rules are inefficient
      - 9283409232 1y ago
        He won't abolish the FCC. It is too efficient at attacking his enemies.
        mrheosuper 1y ago
        looking at his policy to China and Russia, maybe his enemies are not what we thought
        9283409232 1y ago
        His enemies are Americans that don't bow down.
franga2000 1y ago
I have yet to see a real case of "binary blob for regulatory reasons". What law prevents open source RF firmware? The device needs to operate in spec and if someone reflashes it with out of spec firmware, that's no different than someone soldering a different resistor onto the PCB or feeding the output of the chip into an amplifier and large antenna. It's a modification by the user and so the user is liable for operating out of spec. And all of this really unrelated to source code, just to reflashablitiy. The code could easily be open, but the productions device could be made unflashable if the law really required it. Yet this is not what we see here. It's IP reasons, and that's fine, but let's not make up additional excuses for them.
- deleted 1y ago
  [deleted]
- rollcat 1y ago
  > The code could easily be open, but the productions device could be made unflashable if the law really required it. Excellent point. Many people (myself included) do assume that open source = redeployable, as in GPL3. I guess an e-fuse for read-only is perfectly OK, both from regulatory standpoint, and for ensuring you're running the same code as what you have the source for. That would be cool.