[HN Gopher] Reverse Engineer the BL602 WiFi Driver
___________________________________________________________________
Reverse Engineer the BL602 WiFi Driver
Author : zdw
Score : 131 points
Date : 2021-07-07 16:37 UTC (6 hours ago)
(HTM) web link (lupyuen.github.io)
(TXT) w3m dump (lupyuen.github.io)
| kop316 wrote:
| 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:
|
| https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-...
| baybal2 wrote:
| That a first grade reverse engineering work!
|
| A work of this calibre, and quality level can cost easily $100k+
| in the embedded world.
| axaxs wrote:
| This comment confused me at first, but I think you're being
| complimentary?
|
| 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.
| bserge wrote:
| or "top grade"
| megous wrote:
| 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.
| squarefoot wrote:
| 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(r) 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)
|
| Security (Complete Security features) Secure
| boot Secure debug XIP QSPI On-The-Fly AES
| Decryption (OTFAD) AES 128/192/256 SHA-1/224/256
| TRNG (True Random Number Generator) PKA (Public Key
| Accelerator)
|
| Peripherals 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
|
| Package Type 32 pin QFN (BL602) 40 pin
| QFN (BL604)
| klysm wrote:
| How fast are the ADCs?
| MuffinFlavored wrote:
| Will it be a competitor to... Raspberry Pi? ESP32? STM32?
| Teensy?
| monocasa wrote:
| It's a very similar niche to the ESP32.
| 1vuio0pswjnm7 wrote:
| More info, from the same author:
|
| https://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.
| dmos62 wrote:
| 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.
| muxator wrote:
| Isn't this scary?
| jandrese wrote:
| Why does a WiFi chip have block of code dealing with an Infrared
| Remote Control? Was this chip originally designed for a STB?
| Huwyt_Nashi052 wrote:
| 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.
| jandrese wrote:
| I don't think the article talked about it directly, but there
| was a block right in the middle of the memory map for it.
| SAI_Peregrinus wrote:
| 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.
| tyingq wrote:
| This is confusing to me:
|
| _" 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.
| MS90 wrote:
| It does seem to be the same sentence worded slightly different.
| I'm curious to what the actual distinction is as well.
___________________________________________________________________
(page generated 2021-07-07 23:00 UTC)