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.
> ...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.
> 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?
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).
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.
> 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.
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.
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.
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
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.
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.
(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.)