I'm a bit confused why pine64 has decided the BL602 should be the target of deblobbing efforts. Surely the ESP32 would be a better, more popular and more available target?

(Some background: Most western designs of wireless MCU have a user-programmable core and another core handling Wi-Fi running a proprietary blob. Often the flash on the Wi-Fi side of these is inaccessible to the user core and thus deblobbing them would be hard. The ESP8266 and ESP32 are unusual in that the Wi-Fi "blob" is just a proprietary static library (.a file) linked in with your application, so it would be entirely feasible to deblob it. The BL602 seems to be trying to compete with ESP parts, follows a similar design, and thus can also be deblobbed, but is presumably much less available and much less documented.)

> The BL602 seems to be trying to compete with ESP parts, follows a similar design, and thus can also be deblobbed, but is presumably much less available and much less documented.

Wasn't the BL602 just released last week? Bouffalo Lab is also a rather new company so trying to gain market share & attention with a more open strategy sounds like a good idea.

? Its their own core, if Bouffalo Lab wants to gain market share & attention they could start by releasing all the sources to begin with.

I primarily use Bluetooth connection to ESP32.

BL602 support Bluetooth 5.0 with longer range, mesh network, lower power consumption ++

For me this makes BL602 a winner, if the SW can catch up.

> ...why pine64 has decided the BL602 should be the target of deblobbing efforts.

The 4-day old HN thread BL602/BL604 RISC-V WiFi and Bluetooth 5.0 SoC will sell at ESP8266 price point [1] links to a cnx-software article with the following:

> TL Lim, the founder of Pine64, also participated in the discussion and would consider launching a Pine64 BL602 board if an open-source toolchain is available.

[1] https://news.ycombinator.com/item?id=24877335

> I'm a bit confused why pine64 has decided the BL602 should be the target of deblobbing efforts. Surely the ESP32 would be a better, more popular and more available target?

Because RISC-V

I too am confused why BL602 and not ESP32?

Basically they want to reverse engineer this 10MB binary file:

components/bl602/bl602_wifi/lib/libbl602_wifi.a

Which references an internal closed-source sdk:

  phy_bl602.c
  phy_hal.c
  phy_tcal.c
  rfc_bl602.c
  bl602_rf_private.c
  etc..

So this is not actually kinda advertisement to raise aware-ness on the chip? I mean if the manufacturer is sponsoring this giveaway, why didn't they release the sources in the first place?

I would be very funny to discover they lose their source code :)

A more serious reason I could think of : maybe pine64 is trying to convince them to do just that, and this contest is to show them there is public interest (pure speculation from me, of course).

Pine64 and Bouffalo are two different entities. The former tries to ship open-source compatible hardware, the latter manufactures the chip.

So Pine64 is itself giving away 1000 pcs of the board? Assuming 5$ for each board, this challenge costs them 5k...

Yep

When I was working with an ESP8266 board I was really frustrated that the wifi stack was blocking. It meant I couldn't make a good user experience in the event that wifi was lost or at boot.

If that blob was open sourced, it would have been great to make changes to the wifi stack and make it truly async.

You can run more than one thread.

Your comment intrigued me as I hadn't found anything at the time to support this, however this unofficial library exists to try to solve my problem: https://github.com/bmellstrom/esp8266-arduino-threads

Many of the solutions I had found talked about cooperative multi-threading, which doesn't work if I can't make the wifi stack cooperate with me.

Maybe I can make my device run that much smoother during wifi drops now!

Blob-free [1]:

> A proprietary device driver is a closed-source device driver published only in binary code. In the context of free and open-source software, a closed-source device driver is referred to as a blob or binary blob.

[1] https://en.wikipedia.org/wiki/Proprietary_device_driver

I always thought Blob stood for Binary Large OBject, so wouldn’t “Binary Blob” be like “PIN Number”?

Sometimes tautology helps understands acronyms faster, without having to reconstruct context.

I think "blob" is being used in this case to refer to a "large undifferentiated mass".

The article was seeking to describe usage of the word(s), not the origin.

As we have seen before, when something is offered for free in exchange for commits, you get a lot of low quality commits.

Right now I see three pull requests: one that adds an echo statement to a build script, another that deletes a file they claim is not needed and one that renames a directory and changes some paths in the README.

That's always gonna happen with giveaways, and 1000 meaningful submissions would be expecting a bit much, so it's clearly planned in (it's also a fairly cheap board, so "wasting" a bunch isn't so bad). Still builds hype, and it's their own repo, so they can manage it how they see fit and don't annoy any third-party that isn't benefiting.

This is also very efficient guerrilla marketing. Instead of asking users to tell their friends about your brand, you can make a lottery making them win t-shirts with your logo on it. They will be so happy to have won something they will wear it.

In this link's case, if pine64 want to get people excited about that EVB and start hacking with it, it sounds like an efficient strategy. Whatever the real value of the commits are, it's the users who are committed :)

At least, in this case, they ask for contributions on a repos they own.

> Right now I see three pull requests: one that adds an echo statement to a build script, another that deletes a file they claim is not needed and one that renames a directory and changes some paths in the README.

Sure, some people aim at low hanging fruit. But remember that this challenge was just announced. Actual quality contributions take time.

It'll be interesting to check again in a month or so, and see what has been committed.

There are a few more PRs now. The bigger problem I can see is that in a month's time there are going to be 1000 PRs that haven't been able to build on each other, and 20,000 merge conflicts to resolve.

those may be low effort, but if are they useful I think it's still a net good, since they would also be easy to review.

I doubt anyone can make a useful contribution without having the physical board to test on.

Sure you can translate documentation or fix grammar, but otherwise there isn't much you can or even should do without a board to test your changes on. "It compiles: ship it" level contributions are not helpful in general

That's not true at all. People can start reverse engineering the library right away. It should be possible to extract quite a bit of info from it, because it seems to be compiled with debug symbols.

It should be possible to start documenting what it does, start investigating how it's structured, how it interacts with the HW, etc. This would help understanding the HW, and so on.

I just downloaded it, and ran `firefox docs/html/index.html`... and everything is in Chinese :P

It will require more than I thought to make a non-trivial commit!

A cleaned-up translation would probably be accepted.

Just be sure to submit it with a comment "improve docs" and nothing more...

BL602 is RISC-V based. There's DT-BL10 development board based on the same chip which sells for $5 on aliexpress already.

How ironic when a website for a privacy niche product uses browser canvas fingerprinting.

Is it canvas fingerprinting or just trying to determine if emojis are properly rendered(toDataURL calls)? that part seems to be default WordPress emoji Javascript

Any good extensions out there yet for blocking these or are you checking manually?

Canvasblocker for Firefox seems to do its job.

Interesting update: https://github.com/bouffalolab/bl_iot_sdk/issues/1#issuecomm...

The vendor plans on releasing a low-level radio API.

And it's gonna be more open than it is now: :)

https://github.com/bouffalolab/bl_iot_sdk/issues/1#issuecomm...

If I want to contribute meaningfully, I need hardware to test on. To get hardware, I must contribute something first.

Is there something I'm not getting? Is this a filter to make sure only people that know git will get hardware to start hacking on top of?

The hardware is just $5 though

https://aliexpress.com/item/1005001459376242.html

Also available for $3.69 at vvdoit.com which, unlike many Aliexpress vendors, accepts Paypal.

impossible

Why do you say that? Blob-free Bluetooth LE for example has been done on other platforms.

On which platforms? Are you including the firmware runningon the BLE chip, or just what is on the PC CPU?

nrf5x and DA1469x - the firmware running on the BLE chip.

https://github.com/apache/mynewt-nimble/tree/master/nimble/d...

There is no PC here - those are microcontrollers.

Great! Was not aware that there was an open alternative to the SoftDevice for the Nordic NRF5x. That makes these chips even more attractive than before.

The open alternatives for the Nordic NRF5x are not at the same quality level as the Softdevice:

- the idle power consumption is noticeably higher, there are open bugs for more than 1 year about that

- They are not validated by the Bluetooth consortium. You're gonna need to get your own certification to claim product supports BLE.

If you're building a commercial BLE product - my advice: go with Softdevice.

Not really worth it to be honest, as the BL602 is 2.4GHz only (it's aimed at IOT after all), and only b/g/n (no ac, let's not even talk about ax). I don't get why Pine64 would look at this, and not let's say mt76 based devices…

MT76 firmwares are pretty small (of the order of 100kB), while Intel Iwlwifi firmwares are like 1MB, and ath10k-ct is like 200kB big, so it means reversing MT76 firmware is probably a bit easier.

Oh, yeah, it's probably not RISCV so no hype.

Good luck to them anyway, more "open" firmware, the better.

> I don't get why Pine64 would look at this, and not let's say mt76 based devices…

There isn't a blob-free WiFi/BLE IoT chipset. It would be appealing for many.

> Oh, yeah, it's probably not RISCV so no hype.

It is though?

mt76 is an application processor (running Linux) whereas BL602 is a microcontroller (running the RTOS of your choice).

Entirely different categories in both electrical and compute power.

There's a lot of mt76 chips. Some are application processors with MIPS cores, some are dedicated wireless chips with just a Cortex R4 and a Cortex M4.

Their marketing/product folk really aren't doing them any favors.

IMO 2.4GHz is fine, even in the crowded high rise I live in. If I really need high speed for something I just use Ethernet.