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.
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
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!
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. ;)
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.
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:
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.
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.
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.
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……
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.
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.
44 comments
[ 2.4 ms ] story [ 96.4 ms ] threadA work of this calibre, and quality level can cost easily $100k+ in the embedded world.
If so, I think you'd want to use 'first rate' to mean something best in class. First grade is well, first grade(childish), at least in US English.
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
Some companies want to find how someone would RE their devices, so they pay someone to find a way, then tell them.
Sometimes just a random person will want something REd so much that they'd pay for it to be done (happened more than once)
Sometimes no cause is given to me, which is fine because that is none of my business, really.
Sometimes I just do it for fun, but then I do not get paid, eg: http://dmitry.gr/?r=05.Projects&proj=30.%20Reverse%20Enginee...
Anyway, at $200/h you can spend 500h making something work. ;)
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.
[1] https://embeddedgurus.com/state-space/2016/04/beyond-the-rto...
[2] http://dmitry.gr/?r=05.Projects
https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-...
Wireless (Tier-1 RF Performance)
Microcontroller Subsystem Memory Security (Complete Security features) Peripherals Power Modes (Ultra-low Power modes) Clock Package Typehttps://lupyuen.github.io/articles/pinecone
Aside:
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.
https://github.com/aimnas/ja2-1.13-source-mirror/search?q=br... finds 12 occurrences (should be 17), somehow misses https://github.com/aimnas/ja2-1.13-source-mirror/blob/master...
I stopped relying on it after this discovery :/
"How does BL602 compare with ESP32?
BL602 is a General Purpose Microcontroller that supports Bluetooth LE and WiFi
ESP32 is more of a Bluetooth LE + WiFi Controller that supports Embedded Programs"
The microcontroller in an ESP32 isn't second class or anything, and seems "general purpose" to me. So I'm confused as to what point is being made.
Big mystery: why did I think, all along, that ESP32 was ARM? (Don't answer that.)
Datasheet: https://www.espressif.com/sites/default/files/documentation/...
> Are they really the same code?
> We compared the decompiled BL602 WiFi Supplicant code with the Rockchip RK3399 source code… They are nearly 100% identical!
Isn't that a GPL violation? Code should be available!
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.