-
Notifications
You must be signed in to change notification settings - Fork 59
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
Workflow #56
Comments
Well, PineCone have USB-C connector. About the program and all other things, I'm waiting at the moment for EVB too, so I can't verify, but it should come in near days, so will reply here with my discovery. |
Prefer "cross build from a host computer" to "an intel PC". This could be done (with enough determination) from an ARM chromebook or an Apple Silicon Mac, when such things aren't covered by NDA. It could certainly be done on an AMD station today. Confirmed: there is no BLFlashEnv in the tree. Maybe that's part of #25. Yay for USB-C. The pictures I'd seen were USB-Micro B and that was a drag. |
The Linux Binary from #25 is something else. I noticed that when building from Debian 9:
Apparently, it's needed for building and not flashing. It seems to be picky on the libc version. Because of that binary, I mentioned "intel PC", but I meant it in the broader sense. Note, that's the command in ./genromap that bails out on old libcs:
|
I try to understand the workflow. Eventually a high level overview should be added to README.rst.
Development:
Development is done an intel PC. Communication with the evaluation board is done over an USB-A to Micro-B cable connection.
There is no operating system - what runs is a binary blob like the ones generated in customer_app/. Make yourself familiar with how they are built.
Flashing over the USB connection is done with bl_iot_sdk/tools/flash_tool/BLFlashEnv.
FIXME: I grasp from the documention that we flash with bl_iot_sdk/tools/flash_tool/BLFlashEnv, but I don't have that program. Do you?
Execution on the just flashed program:
Restart the board and connect a serial port terminal over the same USB connection.
FIXME: is that correct? At least the gtkterm screenshot shows /dev/ttyUSB0.
The text was updated successfully, but these errors were encountered: