I have a fork of the bouffalo_sdk (formerly bl_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.
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.