-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More Open Datasheet? Free Opensource support? Check here #1
Comments
can we get the code for libbl602_wifi.a ? would be great to have no binary blobs |
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. |
@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! |
@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. |
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 =) |
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. |
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? |
@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. |
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. |
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. |
Hi All, thanks for your enthusiasm. |
That is very good news. Thank you for the efforts. |
@YafeiJin that is great news! :) Thank you! |
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 |
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"? |
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. |
@laf0rge Potential regulatory and IP issues are the most likely cause. |
@laf0rge gamelatser&Avamander are right. We need to follow the rules. |
Can you cite particular rules? Law and jurisdiction will suffice. |
@raszpl Really sorry that I don't know the details, just be informed. |
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. |
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. |
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. |
I am very interested in the company answering these questions including follow-ups - however in-depth they want to be. |
@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. |
@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) |
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. YafeiJin>and I will ignore some questions. Sorry for that. Then why direct me to private email conversation in the first place? |
If you really have to ask that question... 🤦 😆 ... 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.
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. |
@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. |
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. |
@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 |
My embedded SDK wish list:
|
@AshUK |
@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. |
@v01d Yes. It will be open after some basic features are ready. |
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. |
@madushan1000 Cause there are limited resources, we try to release the first simple version at the end of this month. |
thanks for the response! that's great news. |
When a baby is born, no one knows what or how great a contribution he will make to society or human beings when he grows up. By Michael Faraday |
Hi @YafeiJin any news about the MAC layer api? Is it going to be delayed more? |
@madushan1000 More time needed, sorry for this. Currently more resource on Nuttx. After Nuttx is done, we will prepare the driver. Thanks. |
Open how rf works. Something like "6.14 RADIO" from "nRF52810 Product Specification v1.0". Nordic's ds also includes registers documentation. |
@uis246 true, but it's only Bluetooth registers. Although, it would be anyway very useful to have... |
@YafeiJin can you at least release the register documentation(or SVD files with various Mac contollers) so we can start writing a driver ourselves if you can't afford the time to open source the existing one? |
Any update on the MAC layer API? I see your engineers are still busy with NuttX but is there still a plan to release a low level MAC layer API? Preferably without much RTOS dependencies (or none at all - just some functions to be implemented by the embedding application) While speaking of NuttX: Is there a noob level getting started guide to make BL602 NuttX connect to a wifi network? I'm not a NuttX user but I tried your code and never managed to make it connect to any wifi AP - it always crashes sooner or later for me |
|
Because it's only GFSK modulation. And it is not Bluetooth registers, but PHY registers. ANT, ZigBee and other protocols can be implemented too. |
@uis246 yeah that would be good, NimBLE porting would be easier |
Since Pine64 is shipping hardware that's NOT based on the BL602 for Wifi, it's discouraging. Has there actually been any progress in opening the radio layers on this device beyond sending cease and desist orders to those that have made progress? |
What hardware? |
@uis246 PineTab2, |
@gamelaster bes2600 has even less info avaliable than bl602. I thought you will mention something like atheros. |
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.
The text was updated successfully, but these errors were encountered: