Since it was not obvious from the title/article, the BL602 is in the Pinecone, and Pine64 put out a contest to make a fully open Wifi/BLuetooth stack for the BL602:
This is another interesting example of the "convenience" of centralisation of source code control around a single website: github.com.
The author seemingly never has to search competing source code control websites or hardware manufacturer websites. Most everything he references is found on github.com
Pine64 required all nutcracker entries to use github.com
Is it worth pondering that a company founded on the idea of not releasing source code to software users, instead copyrighting it and enforcing copyright through the courts and law enforcement, as a means for selling software (licenses), is now in control of accesss to all this open, freely avaialble source code.
It is worth pondering, in my opinion. Maybe if we had a more fundamental high-level way to handle pull requests, permissions, and some other peripheral features that Github offers, we would find ourselves centralizing less. Git is great, but often on its own it's not enough anymore.
If only we could search the whole web of hypertexts through a single unified interface……there shall be a text box to type in a query, a Search button, and a colorful logo on top……
The BL602 is a relatively new SoC, so here is some more information taken from the producer's homepage (https://www.bouffalolab.com/bl602).
Wireless (Tier-1 RF Performance)
Wi-Fi 802.11 b/g/n
Bluetooth® Low Energy 5.0
Wi-Fi Fast connection with BLE assistance
Wi-Fi and BLE coexistence
Wi-Fi Security WPS/WEP/WPA/WPA2/WPA3
STA, SoftAP and sniffer modes
Multi-Cloud connectivity
2.4 GHz RF transceiver
Integrated RF balun, PA/LNA
Microcontroller Subsystem
32-bit RISC CPU with FPU
L1 cache
RTC timer up to One year
Two 32b general purpose timers
Four DMA channels
Dynamic Frequency from 1MHz to 192MHz
JTAG development support
XIP QSPI flash support
Memory
276KB SRAM
128KB ROM
1Kb eFuse
Embedded Flash (Optional)
SDIO 2.0 slave (AP-Host)
SPI master/slave
Two UART
I2C master/slave
Five PWM channels
10-bit general DAC
12-bit general ADC
Two general analog comparators
PIR (Passive Infra-Red) detection
IR remote HW accelerator
Flexible 16 GPIOs (BL602) / 23 GPIOs (BL604)
Power Modes (Ultra-low Power modes)
Off
Hibernate
Power Down Sleep (flexible)
Active
Clock
Support XTAL 24/26/32/38.4/40MHz
Support XTAL 32/32.768KHz
Internal RC 32KHz & 32MHz oscillator
Internal System PLL
I recently got a smart LED strip controller to put Tasmota on and found a BL602 instead of an ESP32. This chip has been a drop in replacement with the intention of lowering cost and potentially protecting against trade dispute chip issues with the US govt.
ESP8266 and ESP32 (outside of that one variant with a RISC-V core) all run Tensilica Diamond Standard 106Mirco and Tensilica Xtensa LX6 cores, respectively.
No ESP variant so far has had an ARM core.
Which is kainda neat, but not unheard of woth embedded microcontrollers.
At least it is not yet another 8051.
Embedded world has low standards, then. :) For $100k+ I'd expect some working PoC FOSS code, based on the RE, not just a nice summary of looking around at code in Ghidra, and searching on Github.
Making a PoC is usually only the beginning. Firmware upgrades for microcontrollers may be difficult to do in the field, without UART and JTAG debugging. If clients expect that pretty demos will continue working, they might be quite disappointed. It's better to follow good design patterns (Active Objects, state machines [1]) from the start when possible.
dmitrygr is a legendary embedded hacker [2]: his Transcend WiFi SD card reverse-engineering is what led to me having a PQI Air Card in my pocket, and he's also written a bit-banged Bluetooth Low Energy driver. Great for a demo or when there's nothing else available, but far from a finished product.
Writing a MISRA-compliant BLE driver would make me MISRA BLE.
You underestimate the cost of a competent reverse engineer's time. eg: I charge $995/hour for such stuff (reverse engineering unknown chips/devices) and have no shortage of takers.
A large amount of initial RE work is research, such as this article. Not doing it costs you a lot more time later on.
Working code could easily be over 100 hours of work on an under-documented radio chip, so your cost estimate is too low for that
I know how much re costs in the amount of time spent. I've RE'd all kinds of things, and re-implemented in a better way, from weird payment terminals, camera sensors, to really weird eInk/SoC combos where a big manufacturer is bitbanging eInk protocol over data lines of LCD interface from memory patterns, USB bootloader protocols, software protection schemes... Pre-RE research is valuable, but that's just a start.
Anyway, at $200/h you can spend 500h making something work. ;)
Genuine curiosity, who is paying for that type of work? What is a typical use case? Where is the ROI? I'm not familiar with this world at all. I appreciate any insight!
No, it only means that Rockchips (or one of their customers) ships a kernel with a a driver for a Marvell wireless devices (presumably now made by NXP), for which Marvell claims to own the copyright and gives permission under GPL.
Assuming that the license text is correct, Marvell or NXP would have been in their full rights to provide the same source code to some users under the GPLv2 for use in a Linux driver, and to other users under a different license.
Another possibility is that Marvell themselves licensed the supplicant code from someone else and replaced the copyright information when publishing it together with their driver.
Yeah, but I think this an avenue we should peruse. If by any chance they copied anything from rk3399-linux, the whole thing should be released under GPLv2.
As Huwyt_Nashi052 said, IR controllers are generally very flexible and allow for receiving/sending arbitrary low-to-medium frequency signals.
BL602 is no exception with the software mode the controller provides, giving you access to raw pulse lengths; for example I use it as a pulse frequency counter to interpret a BLDC driver's "speedometer" line, and there are countless other applications like controlling an eInk display's common anode/cathode line.
I must have missed it in the article but a hardware peripheral for interfacing with IR remotes is common in microcontrollers and can be very versatile with the right configuration. It's often used for driving addressable RGB LEDs, for example.
Lots of SoCs start by licensing (or already having) an existing MCU or CPU core and adding a bunch more peripherals. They didn't need the die area, so they left the IR peripheral in.
Could also be that they figured somebody might want to make an IR to wifi bridge solution.
Or maybe somebody might make some RGB light strip with both local IR control and app control via wifi or bluetooth?
It does make sense and IR receiver is a very simple peripheral.
https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-...