More Open Datasheet? Free Opensource support? Check here

[bouffalolab2020]

We are glad to hear voice from you.

Any requirements? Feel free to talk or request Here.

BTW: We are plan to add Nuttx support soon.

[maidenone]

can we get the code for libbl602_wifi.a ? would be great to have no binary blobs

[Avamander]

Pine64's is evaluating releasing a product based on the BL602.

The decision mostly depends if there's enough documentation to implement an open-source WiFi and Bluetooth stack or if the Bouffalo's stacks are going to be open-source to an usable extent.

For example, if Bluetooth LE + Mesh and WiFi+WPA2 stacks were to be open-source, that would already be a huge plus over competitor devices such as the ESP8266 or ESP32. If everything remains proprietary, there's not a huge lot that would tilt the balance towards the BL602 to be totally honest. It's up to Boufffalo to decide what approach you wish to take.

[rafacouto]

We are glad to hear voice from you.

Any requirements? Feel free to talk or request Here.

@bouffalolab2020 It is a great idea to publish every source code, specially those 'archive' binaries. Accessing to registers in memory is not a big secret to hide and it is important to optimize and to add more API hardware-based features.

Product specification in detail is also important (a good example is Nordic's nRFx docs). English is the worldwide most spread language related to IT developers, please, always a version in English!

It will be a significant advantage over your competitors like Expressif. Community will support your hardware from foundation, you only have to lead the project... Go fully open!

[YafeiJin]

@maidenone @Avamander @rafacouto Thanks for your feedback. We are preparing documents with more details. For stack part, it's a little complex, and will take more time & resource to deal with. We will consider this requirement seriously. Thanks again.

[protobits]

I second the necessity of a fully open platform. This could be a big competitor to ESP8266/ESP32 which has no plans to release BLE/WiFi low-level code nor to document the corresponding radio peripherals.

Speaking as a NuttX maintainer, openness is a huge factor since NuttX does not include third-party HALs. For instance, BLE support for Nordic 52* is being added with a link-layer written from scratch following Apache 2.0 license, and this was possible since all the corresponding peripherals are documented. There's work in progress to support ESP32 by calling into the binary blob, which goes against the goal but it is more of a pragmatic solution (and this actually involves Espressif working towards supporting NuttX and remove FreeRTOS specific code from the blobs).

So, yes, please fully document RADIO peripherals. You can keep your stack propietary in such case but of course opening this as well would be a huge advantage over Espressif solutions. Moreover, it allows anyone to inspect this critical portions of the code for vulnerabilities and propose fixes.

That said, thank you for opening this issue, asking the community is the right step =)

[JF002]

Thanks for publishing your SDK under an open source license!! I also hope you'll be able to provide the complete documentation of the radios and/or source code of the wifi/ble stacks.

As the maintainer of InfiniTime, an open source firmware for Pine64 PineTime, I decided to switch the BLE stack from NRF Softdevice to NimBLE mainly because NimBLE is open source. An integration of the BL602 radio into NimBLE would also be awesome!

[acassis]

Hi @JF002 recently @v01d worked porting NimBLE to NuttX. Please take a look at his repo: https://github.com/v01d/incubator-nuttx/tree/nrf_ble Did you already test NuttX on Pine64 PineTime with LVGL?

[protobits]

@Pine-A64 can you explain a bit more about the challenge? I'm not sure I follow the idea of achieving a blob-free wifi without vendor documentation, unless you reverse engineer the blobs.

[DurandA]

@sipeed comment on Twitter:

only 3 lib: libblecontroller.a, libatcmd.a, libbl602_wifi.a and they are un-obfuscated, you can easily disassembling it

[JF002]

Hi @JF002 recently @v01d worked porting NimBLE to NuttX. Please take a look at his repo: https://github.com/v01d/incubator-nuttx/tree/nrf_ble Did you already test NuttX on Pine64 PineTime with LVGL?

I didn't know about NuttX until a few days ago :) I've seen references to NRF52 in the code, so it moght run on the PineTime, but I've not try it.

[acassis]

Yes @JF002 ! The nRF52 is well supported by NuttX. Actually @v01d ported NimBLE to run on NuttX on nRF52832. I'm testing it on Makerdiary nRF52832-MDK board! :-)

[protobits]

@sipeed comment on Twitter:

only 3 lib: libblecontroller.a, libatcmd.a, libbl602_wifi.a and they are un-obfuscated, you can easily disassembling it

This feels a bit backwards when the vendor is seeking community response and has shown open mindedness regarding opening documentation. If these are reverse engineered maybe the vendor feels less pressure to officially document the required hardware.

[YafeiJin]

Hi All, thanks for your enthusiasm. After discussion, we decided to move one step further towards open source. We plan to provide one set of low level APIs on mac layer some time later, with that BL602 can work well as one high performance raw packet tranceiver. These APIs will cover HW encryption & deencryption/HW retransmission/HW packet filter/HW DateRate control/HW PowerTable/TSF/Qos/HW Backoff/HW Aggreation. We think these are powerful enough to import Mac80211 and supplicant to implement one open source stack. Things under this layer are related to the HW(RF/PHY) register settings, which can not be open. BTW, the original libs are also kept for other kind of users. Hope this is helpful

[Avamander]

That is very good news. Thank you for the efforts.

[maidenone]

@YafeiJin that is great news! :) Thank you!

[JingyanChen]

Thank you for Bouffalo Lab's contribution to open source community. BL602 is one of the best powerful RISCV based rfid chip i have ever seen. Wish more information will be offerd to construct "the age of interconnection". Let's make everything smart! LOL

[raszpl]

BL602 is one of the best powerful RISCV based rfid chip i have ever seen.

rfid? did you perhaps mean wireless? and is it the second ever RISCV based wireless solution on the market at this point? By on the market I mean announced 5 days ago. And by i have ever seen you mean "read the announcement"?

[laf0rge]

Things under this layer are related to the HW(RF/PHY) register settings, which can not be open.

Can you please explain the reasons for that? Why can this not be open? It would be great to finally have an small wireless IoT platform without proprietary libraries/blobs, but where everything is available fully in source code.

[gamelaster]

Things under this layer are related to the HW(RF/PHY) register settings, which can not be open.

Can you please explain the reasons for that? Why can this not be open? It would be great to finally have an small wireless IoT platform without proprietary libraries/blobs, but where everything is available fully in source code.

Licenses? If RF will be open, user can make wifi jammers etc.

[Avamander]

@laf0rge Potential regulatory and IP issues are the most likely cause.

[YafeiJin]

@laf0rge gamelatser&Avamander are right. We need to follow the rules.

[raszpl]

@laf0rge gamelatser&Avamander are right. We need to follow the rules.

Can you cite particular rules? Law and jurisdiction will suffice.

[YafeiJin]

@raszpl Really sorry that I don't know the details, just be informed.

[laf0rge]

Licenses? If RF will be open, user can make wifi jammers etc.

You can make wifi jammers in any way you like already today. whether in pure analog/physical domain, or using softmac based Wifi chips.

If you give people a hammer, they can use that to put nails in the wall, or they can use it to kill another person. The majority of people luckily uses hammers in a constructive way. Did we outlaw hammers because they can be ued for illegal purposes? No, we didn't.

[laf0rge]

@raszpl Really sorry that I don't know the details, just be informed.

Can you plese inquire on the specifid details? It is important to understand those details to determine if the argument is a real argument. Thanks for your efforts.

[Avamander]

@raszpl Really sorry that I don't know the details, just be informed.

Can you plese inquire on the specifid details? It is important to understand those details to determine if the argument is a real argument. Thanks for your efforts.

@laf0rge It literally isn't any of our business. They said they can't.

[raszpl]

@laf0rge It literally isn't any of our business.

Dont know about you, but open source radios are laf0rges business ;-)

They said they can't.

They said they wont and gave us unsubstantiated excuse with appeal to authority.

[Avamander]

@raszpl

Dont know about you, but open source radios are laf0rges business ;-) They said they wont and gave us unsubstantiated excuse with appeal to authority.

But not your business. They have their reasons, and it should be understood and acknowledged. An appeal to authority is totally valid when the authority is who decides.

[BryanQuigley]

I am very interested in the company answering these questions including follow-ups - however in-depth they want to be.

[raszpl]

But not your business.

?

An appeal to authority is totally valid when the authority is who decides.

https://en.wikipedia.org/wiki/Argument_from_authority#Appeal_to_false_authority The authority here being vague "follow the rules".

[YafeiJin]

Hi all, Be relaxed please... And sorry for my previous vague reply. I would like to correct as the following: Limited by IP license, the low level parts can not be open.

[raszpl]

Limited by IP license, the low level parts can not be open.

Great news. Who is the IP licensor?

[gamelaster]

@raszpl I think you're asking too much sensitive information. Why you want to know it so much? How it will help you? We should be happy that the Bouffalo want to help us and contribute as much as they can.

[YafeiJin]

@raszpl I always respect the people keeping being curious. I had sent email last day, if you like we can talk there. Thanks

[pfeerick]

If RF will be open, user can make wifi jammers etc.

This is nonsense... you can make a wifi jammer by just turning on a microwave, or a plethora of different ways. Security through obscurity is no security at all.

I'm glad and grateful that YafeiJin is taking the time to respond to all the questions asked as much as possible. If information can't be disclosed, it can't be disclosed. But that does not mean anyone should stop questions being asked. The only stupid question is the one not asked.

I would also like to thank everyone at Bouffalo Lab for the work they have done thus far, and for the commitments they have made to open up more of the architecture as they are able.

[raszpl]

gamelaster> @raszpl I think you're asking too much sensitive information. Why you want to know it so much?

Did you perhaps miss the title of this topic?

YafeiJin> @raszpl I always respect the people keeping being curious. I had sent email last day, if you like we can talk there. Thanks

I dont mind talking in the open.

[YafeiJin]

@raszpl We all know this project has its limits, which can not meet everyone's requirement, and I will ignore some questions. Sorry for that.

[gamelaster]

This is nonsense... you can make a wifi jammer by just turning on a microwave, or a plethora of different ways. Security through obscurity is no security at all.

@pfeerick Well, of course, there is another XYZ ways of how to jam the WiFi, but from I've heard, for this reason Espressif didn't wanted to share their low-level API. (It was discussed in #offtopic of PINE64 Discord, will send you in DM)

[raszpl]

YafeiJin> @raszpl We all know this project has its limits

You know where those limits lie and reasons for them, we dont. Whole point of communication is passing those kinds of information, preferably in transparent manner. Revealing RF IP licensor would let us move this conversation upstream, petition owner to open source HW block interface API. Keeping it secret doesnt make much sense, its not like you are using stolen IP, or hiding backdoors. Besides unless the design was custom tailored its only a matter of reverse engineering the firmware and comparing register block arrangement/accesses to other chips on the market. You have seen what open source did to Espressif popularity/market share. You want design wins, we want open source radio chips. At the end of the day its all about the goodwill and cooperation.

YafeiJin>and I will ignore some questions. Sorry for that.

Then why direct me to private email conversation in the first place?

[pfeerick]

Then why direct me to private email conversation in the first place?

If you really have to ask that question... :facepalm: :laughing: ... perhaps to be able to focus on the discussion one-on-one, rather than us random interlopers... plus some more detail may be able to hinted upon since it's no longer a public forum?

I fully understand what you are trying to do... which was clearly not understood given some of the negative comments ... I couldn't have said this much better... the "whole point of communication is passing those kinds of information, preferably in transparent manner" ... it's not to say "we can't" but "why we can't" ... i.e. we now know (not guess, surmise, infer, etc.) they can't open up certain things due to Intellectual Property agreements... that's fine. If the who can be disclosed, that would be great, but it can't, it can't - but that needs to be said (and obviously the question asked) - then everyone is on the same page.

Well, of course, there is another XYZ ways of how to jam the WiFi, but from I've heard, for this reason Espressif didn't wanted to share their low-level API. (It was discussed in #offtopic of PINE64 Discord, will send you in DM)

I think I saw that (the discussion). Just because Espressif ran with that excuse doesn't make it right... I don't support illusory truth arguments ('if you say it enough times then it must be true')... they were wrong when they used that as the excuse then, and BL would be wrong if they used it now, and doubly so if they used Espressif as the authority. Now, if it were said some fool at the FCC said they couldn't open that sort of stuff up and still get regulatory approval, because the FCC thinks that would happen... I would say that's fine... and then deal with the FCC for that rather stupid viewpoint. But this is all semantics... we know now it's IP obligations, so enough said.

[YafeiJin]

@raszpl I am glad to answer the second question. I noticed your stern words since the beginning, so I consider if there might be some misunderstanding. Following, I saw your questions began to cover the sensitive topic, and I think it's time to communicate directly to solve it better. Hope you don't mind the mail too. Lastly, I want to talk one logical thing that what you can do is not what I can do.

[raszpl]

Since you arent open sourcing the radio part there is zero differentiation between your part and upcoming ESP32-C3 https://esp32.com/viewtopic.php?t=18107&p=67696

[Avamander]

Since you arent open sourcing the radio part there is zero differentiation between your part and upcoming ESP32-C3 https://esp32.com/viewtopic.php?t=18107&p=67696

@raszpl Juding your current and past replies, I think you need to learn how to look at the positive things we have now. There are very few platforms that are as open and when low lever API of the mac layer is published it will be even more so. The approach Boufallo has taken has already shown to be useful and good, even Espressif is considering becoming more open. We should also keep in mind that the BL602 is a competitor for the ESP8266, other chips in the series might become competitors for the 32-C2.

[YafeiJin]

@raszpl The difference is that BL602 was defined in last Sep., and sample ready in April, MP already. If you are familiar with this industry, you will know what's the meaning. Even for open source, it's less 4 weeks. It's just the beginning. As for the radio part, maybe you could try C3. Thanks

[AshUK]

My embedded SDK wish list:

• Nuttx support
• Binary free SDK
• LLVM/clang based tool chain
• Enforced code styling and formatting
• Extensive and well written unit tests and coverage
• Off target application development
• Clean code and cyclomatic complexity monitoring
• Automated SMT based model checking
• Bazel powered build system

[YafeiJin]

@AshUK Nuttx is started internally. We will evaluate other possible requirements, and improve SDK step by step. Thanks.

[protobits]

@YafeiJin does this mean Buffalo Labs is working on NuttX support directly? If so, it would be very beneficial to open that effort to the NuttX community to ensure it can be merged upstream.

[YafeiJin]

@v01d Yes. It will be open after some basic features are ready.

[madushan1000]

Hi @YafeiJin, Do you know if we getting the mac layer API anytime soon? I've seen the rf layer sources elsewhere on github. If you release the mac layer, that's probably most of the sources in the open.

[YafeiJin]

@madushan1000 Cause there are limited resources, we try to release the first simple version at the end of this month.