Flashing chip issues on linux (Missing tool?) #71
Comments
|
There's an (incomplete) open source tool here. Other than that, I've seen a few OpenOCD configurations floating around, but couldn't point you to one at the moment. The only other option would be the Windows tool provided with the SDK ( |
|
This is kind of a dupe of #56, where it was first reported that flash_tool is missing. Windows devs are guided to simple_flasher and it doesn't exist, either. I think we (English speakers & particularly non-Windows developers) mayto have to rely on upstream to fill in some of the missing tools and doc for these final stages on actually getting code onto the devices once we receive them. I suspect that someone just excluded a directory - with source - for something that should be included. The untranslated doc is a turn-off and earlier patches to machine translate the doc were rejected. Is a human somewhere responsible for translating them and keeping them synched? There is a whole lot of flash_tool that doesn't have corresponding source. Jlink comes from Segger and is cross-platform, but there's a lot of other binaries checked in that directory without clear heritage and/or that is mentioned in doc but is missing. Pine64, do you have any leverage with the designers? You have devices in your hands. How are you programming them? |
The docs reside in a separate repo and translating is up to volunteers mostly. It does look better now than it looked a month ago. |
|
Hi @robertlipe
Not yet, pine64/bl602-docs#9 is not merged yet.
Well, you had a lot of similar questions, and to respond you to this following question, let me explain how actually Nutcracker (and PINE64 works). Firstly, PINE64 is just community, maintained by people in their free time. Then there is PINE Store (company). This company is taking care of designing, manufacturing and shipping the products, The Founder of PINE64 and PINE Company is the only connection between those "entities". He also created the idea of Nutcracker challenge, and I was asked if I want to take care of it free of charge. So I do, together with @Avamander which I asked for help 😊 So, what this means? Firstly, we don't have any connection with designers, and also, I don't have the device in my hands yet (since it's still in transport, it was shipped at first batch, but some devs received it already). From what we tried, @pfeerick already received his PineCone, and already flashed the PineCone with BLFlashEnv or with the .exe variant for Windows. Also, this means that relationship with Bouffalo is mostly as we doing just community fork, where we want to reverse engineer the blobs and also improve the SDK and documentation. Secondly, as this is community effort, basically anyone can join us, and if you would like to help us with maintaining, please contact me at gamiee (at) pine64.dev . |
|
Since my ears were burning... For the record, it's a BL-10 BL602 dev board... my PineCone probably won't get to me till early December. However, since it uses the BL602 module, it'll do as far as being able to run/test stuff. I used BLFlashEnv on Windows, and it worked fine. I followed the instructions I somehow found here (perhaps because I was looking for more on the specific board I have... I'm not sure now) https://github.com/SmartArduino/Doiting_BL/blob/master/README_EN.md On Linux, I found BLFlash to be a nightmare... it will either work for you or won't - more likely to work on Ubuntu in my limited experience with it. However, if you can get your board flashed once with the bootloader and partition layout, you can then use https://github.com/stschake/bl60x-flash to flash just your app image via the command line ... I have only used it a couple times, and only on Linux so far (Ubuntu, Manjaro) and it is working great... (hm... have to try the Pinebook Pro next). As mentioned by the others, this is in early stages... people are still getting their boards... and work is being done when community members can do it. There should not really be anything missing from upstream... this was forked from the upstream repo, and is building upon it, translating it, bugfixing it, de-blobifiying it, etc. The linux binary is actually completely missing from their repo... I'm not sure why - perhaps because it's a ~100M file, so to big to add to git without adding LFS support or something... regardless of the reason... it's a PITA and should be avoided where possible, which is why I hope to see While pine64 doesn't have leverage, the amount of interest from the pine64 community (and other developers) has resulted in Bouffalo Lab committing to open up more of the source (as much as they can without breaching IP licensing)... so a lot of progress is being made in a very short period of time. |
I tried this on W10 and I got the following error: I think for noobs like me I should wait for some source to come out or more documentation. Thanks for the response! |
|
To add to this, if you guys need contributors I'm more than down to dedicate 100% of my free time to this chip, but I'm really only proficient in a few things whereas for things like this it seems like you need to be an expert in reverse engineering and risc-v. If anyone wants to mentor me or throw me some resources for learning it would be much appreciated =) (I have never submitted a pull request because I fear I might break something, but I have developed firmware for devices that have seen flight time in aero/industrial) |
|
I'm clearly interested and involved. While I can't match that offer of
100%, I'm "in" at the hobbyist level for a while. (I have relevant
experience. One of the first things I want to do is pry their examples out
of the Amazon RTOS.) One high value project - not that tasks are mine to
assign - is to set up build runners for all the OSes so that every proposed
pull request gets built and run, either on real hardware or emulators, for
all three OSes. Travis-CI's self-destruction doesn't help, but AppVeyor
lives. Self-hosting a build farm with hardware or GitHub Actions are
options.
So who is actually making these boards and modules? The hardware from doit
and Spieed looks the same DT-BL1-, but if yours has a USB-C, it's a
different PCB, right? Doing USB-C right is more than just replacing the
socket. I thought Pine64 actually built hardware.
Is the deal that Pine64 is also distributing the stock BL10 boards and
being the English support arm for Bouffalo? (I find it totally weird that
they build the chip, are withholding some of the code and the specs, and
then encouraging people to reverse engineer it.) There shouldn't BE 100MB
binaries - there should be source code. The GNU toolchain is included as
binaries only (which is odd) but there are at least enough clues to
reconstruct it. Uploaders should be provided *somewhere* for all three OSes
because *someone* is presumably testing all three OSes, right? (When I said
'left out of the repo', I meant upstream and not during the actual
clone/branch process.)
I'm assuming that the actual market here isn't for the $5 dev boards in
Qty1 but rather for the $1 module thingy at the end that has the SoC and
radios in Qty 100,000 at commercial use. Again, relying on volunteers to
replace missing pieces of build processes seems odd. Relying on them to
flesh out examples and share code is totally reasonable.
As for other ways of flashing, if the provided tools are messy and they
really do have JTAG-class support, I've been using the Segger tools (J-Link
and others) on other RISC-V on Mac and Linux and they've worked well. It
may be a route worth chasing. Once we work out the JTAG story, the need for
software loaders drops a lot and, as a bonus, it becomes much easier to
recover the board after a brick event.
My point about the missing code was that they provide tools to build on all
three OSes, but there seems to be code missing for the final mile of
getting the code onto the devices at least for two hosting OSes and maybe
for three.
I had seven different packages scheduled to leave China all about the same
time as PineCone some three+ weeks ago. The one I really wanted
(Sipeed Amigo - a K210 product) was returned today by some postal inspector
and zero of them have left China. I get that China is far away, but it
seems that products take leisurely time to actually LEAVE China. :-) It
seems likely that very few of us will have these by December. I'm
deadlocked on several projects. Waiting on that literal Slow Boat. I'm
hopeful we'll see a development explosion once these get into the hands of
developers. I'm excited to have a GD32V alternative with "enough" RAM!
…On Sat, Nov 14, 2020 at 1:07 PM Penguin ***@***.***> wrote:
To add to this, if you guys need contributors I'm more than down to
dedicate 100% of my free time to this chip, but I'm really only proficient
in a few things whereas for things like this it seems like you need to be
an expert in reverse engineering and risc-v. If anyone wants to mentor me
or throw me some resources for learning it would be much appreciated =)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#71 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35LWZZSG6XCZJYSCB3SP3IPFANCNFSM4TU2JSRA>
.
|
|
@embeddedpenguin Well, you can contribute in things you know 😊 |
From what I know, it's custom PCB done by PINE Store company (most likely contractor).
PINE Store company dealing with building the hardware. PINE64 as community is taking care of software.
No, PINE Store company is distributing only their own design, which is PineCone for Nutcracker Challenge.
PINE64 and PINE Store target is to provide open-source and fairly priced hardware, so 5$ dev boards in 1 quantity is okay.
Once again, all this effort is for having open-source wifi and bluetooth for PinePhone and Pinebook. It has nothing to do with "replace missing pieces of build processes". But also, in same time, I think this effort is also about make BL602 easier to use, so make some examples, get compilation and flashing working across OSes etc.
Some developers already received PineCone, so hopefully you will receive it soon. If you will have any issues with shipment or having any other questions, please let me know. |
|
Good explanation. Thank you! I'm sure I'm not the only one curious and with
an incorrect understanding here. Please consider copy-pasting some of those
words into a doc or wiki or something that helps explain the relationship
between BuoffaloLab, Pine64, Nutcracker.
I thought that BL10 was the board that held the BL602, but with this
explanation, and a closer look at the photos, I think I understand that the
board has a different name from each company and probably has
straight-forward "bring out the GPIOs, power, attach some kind of a
USB/Serial system (in 2020, sigh...), buttons, and lights and that the
little module is the BL10 and inside that module is the BL602 SoC. So BL602
chip (common, from BL) < BL10 module (common, from BL) < PineCone
(vendor-specific name from PineStore, etc.).
BL602 = SiFive E24 + RAM/Flash + Timers + Ethernet WPA, PHY-level stuff,
Bluetooth, SoC stuff.
BL10=BL602 + Physical Radios + Antennas + convenient packaging. Probably
FCC certified.
PineCone = BL10 + buttons, LEDs attached to GPIO + USB/Serial adapters.
It's thus BL that did the "real" engineering and created the code now
served by Pine64, Doit, and Sipeed with each using the BL10 module that's
provided by BL, right?
In the sense that the build system is seemingly missing pieces for MacOS
and Linux and, from earlier in this thread, broken on Windows, we should be
applying pressure upstream, right? A working system to compile and install
code is surely what was intended to be provided, right? For all the secrecy
in the data sheets, uploading code was probably not intended to be a
mystery and this is surely an oversight. This isn't the work this group
should be building, right? A functional 'make install' (whatever) should be
the entry ticket.
Is that a better understanding?
Thanx!
…On Sat, Nov 14, 2020 at 3:39 PM Marek Kraus ***@***.***> wrote:
@robertlipe <https://github.com/robertlipe>
So who is actually making these boards and modules?
From what I know, it's custom PCB done by PINE Store company (most likely
contractor).
I thought Pine64 actually built hardware.
PINE Store company dealing with building the hardware. PINE64 as community
is taking care of software.
Is the deal that Pine64 is also distributing the stock BL10 boards and
being the English support arm for Bouffalo? (I find it totally weird that
they build the chip, are withholding some of the code and the specs, and
then encouraging people to reverse engineer it.)
No, PINE Store company is distributing only their own design, which is
PineCone for Nutcracker Challenge.
Also, PINE Store is not support for any Bouffalo MCUs. The SDK, Docs,
Datasheets and other things are all from Bouffalo directly, PINE Store or
PINE64 Community doesn't have access to nothing more (and if PINE Store
have something more, they can't release it). So everything I share here is
directly from Bouffalo with permission that we can share it. The PINE64
effort of reverse engineering the BL602 is solely made by PINE64, as seeing
it as opportunity to have Open-Source WiFi and Bluetooth chip for products
as PinePhone or Pinebook. Also, PineCone can become successor of "PADI"
module. So, as I said, everything here is all what we as PINE64 Community
have, and it's about what Bouffalo will be able to share with us.
I'm assuming that the actual market here isn't for the $5 dev boards in
Qty1 but rather for the $1 module thingy at the end that has the SoC and
radios in Qty 100,000 at commercial use
PINE64 and PINE Store target is to provide open-source and fairly priced
hardware, so 5$ dev boards in 1 quantity is okay.
Again, relying on volunteers to
replace missing pieces of build processes seems odd. Relying on them to
flesh out examples and share code is totally reasonable.
Once again, all this effort is for having open-source wifi and bluetooth
for PinePhone and Pinebook. It has nothing to do with "replace missing
pieces of build processes". But also, in same time, I think this effort is
also about make BL602 easier to use, so make some examples, get compilation
and flashing working across OSes etc.
I had seven different packages scheduled to leave China all about the same
time as PineCone some three+ weeks ago.
Some developers already received PineCone, so hopefully you will receive
it soon.
If you will have any issues with shipment or having any other questions,
please let me know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#71 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD372LNOYSKWNZ6YFFUTSP32I7ANCNFSM4TU2JSRA>
.
|
|
It probably helps if you look at the wiki when trying to come to some understanding as to what is going on... ;) As when you look at the picture of the Nutcracker EVB, you'll see that it doesn't have a BL10 module on it :-P Also, this is not the final board, as it will have a metal shield on it when it gets certified. It is primarily missing now so that you a) know that it does have a BL602 chip, and b) don't have to remove the can if you need to get at the chip during this early dev stage. Buffalo Labs have provided the BL602 and some SDK, just as Espressif have provided the ESP8266 and some SDK... Pine64 plans to take the BL602, and make it available in ESP-01S (NUT-01S), ESP-12S (NUT-12S) and RTL8723/AMPAK (NUT-15) packages, and I presume will also have a dev board like the Nutcracker EVB also, which is a near drop in replacement for the NodeMCU dev boards. I believe that just like with the ESP8266, third parties will the BL602, and making their own modules. For the ESP8266, Espressif made their own, but the more popular ones were the Ai-Thinker modules. For the BL602, so far to looks like DOIT and pine64 (and perhaps Sipeed?) are the first ones out of the gate. Obviously I'm biased, but I still think pine64 will be here for the long haul due to the efforts made to make it as much of a drop in replacement for the ESP8266 as possible. BL have given us the starting point, and just like with the ESP8266, it's now up to us to get it into a usable state, rather than relying on them to maintain and improve it. This was the case with the ESP8266... it will be the case here. We are in a better situation than the ESP8266 was as there are only a few binary blobs to it, and even those appear to be able to be reverse engineered, and the manufacturer is willing to open up a bit more themselves. My experience with the build system so far is that on windows, you need to use WSL or a linux VM to compile (I haven't done it, that is what the instructions state). On Linux it compiles just fine for me. Another PR suggests MacOS is problematic, but possible. This does not surprise me... BL would have gotten it working for their environment and not done anything more than was necessary. This is why this repo exists... to get a build environment / SDK that's more usable. As you'll note in #23, it's entirely possible to dump the whole toolchain that's bundled in the SDK, and use the SiFive distribution, as that's what it's basically a copy of... meaning if we can get that part working, it is one less thing to maintain and support. In other words, break this back down into it's individual parts, and then apportion any support issues or bugs elsewhere where relevant ;) btw, It was not the build env that was broken on Windows, but a third-party flasher tool. |
Exactly! Although, PINE64 plans to use BL602 in PinePhone, and since BL10 package is too big, it will directly use the chip only About the toolchain and flash tools. Yes, it's bit chaotic, but I think with cooperation with Bouffalo, we can improve it and push it into upstream. I was also thinking to separate this repo (so it wouldn't be fork anymore), and we will just pull the official SDK changes as single commit, and same will be for pushing the changes (I will cherry pick compatible commits and push them to upstream). From begin of Nutcracker I'm thinking about how the "upstreaming" will work, how we will manage our fork etc. Also, yes, the main target of Nutcracker is to reverse the blobs and have open-source chip. But there is also a lot of people, which can't contribute to this target, but they have another skills which can improve BL602 SDK, so why not use this "human-power" to make great platform for everyone 😊 Well, I'm open for any discussions about the "way" of we want to move with our fork, so we can discuss about here on messaging platforms. |
It says on the wiki that I should be using "BLFlashEnv", which should be found under
/bl_iot_sdk/tools/flash_toolfor flashing binaries. This doesn't exist in the repo so I'm a bit confused. I tried using openocd with an ftdi cable but that refused connection. How are people flashing the chip?The text was updated successfully, but these errors were encountered: