OBLFR: use OSS version of bouffalo_sdk tools #80
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`bouffalo_sdk_oss` is my fork of the Bouffalo SDK which aims to avoid hard-coded binaries in the repository. The original SDK used pyinstaller packages to manage the dependencies; since we are not doing this we must tell buildroot about them instead.
OBLFR needs an older version of the Bouffalo SDK.
* python-portalocker reset to v2.0.0 in line with requirements file in bflb-iot-tool * Removed auto-generated Config.in files; these can be replaced with correct Config.in.host files at a later date.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a fork of the
bouffalo_sdk(formerlybl_mcu_sdk) here. It aims to remove hardcoded binaries from the repository.That fork isn't a good fit for upstream
bouffalo_sdk, since most of the hardcoded binaries seem to be there to avoid dependency headaches for the SDK's end users. (Mostly for Windows users, it would seem.) However, buildroot allows us to specify all the necessary dependencies directly, which is what I have done in this PR.The main advantage of this approach (besides OSS purism) is that it allows the buildroot images to be built on non-x86 hardware. (As well as non-glibc operating systems, although they would need to compile the Xuantie toolchain themselves in both cases.)
Note: the current version of OBLFR is only compatible with an older version of the Bouffalo SDK — this is why this PR uses the openbouffalo_compat branch in my fork. If this incompatibility is resolved at some point in the future, we can use the up-to-date SDK by pointing the bl_mcu_sdk package to the master branch.