Hello Forum members!
I'm working for a client developing a new AM6458-based design using the TI Processor SDK for Linux. We are currently using 06.00.00.07, which I believe is the latest SDK code.
My client would like to use Buildroot to create a cross-compilation toolchain, bootloader (U-Boot), root filesystem (ext4), and Linux kernel. Eventually they would like to add their own applications and tools to the Buildroot output as well. They have used Buildroot in the past with other TI Sitara processors with good results, and like the simplicity and relative speed that Buildroot offers.
After a _lot_ of work with our local FAE, we were able to get a U-Boot image and Linux image built, copy it onto an uSD card using the create-sdcard.sh provided in the SDK, and got to a Linux login prompt. I should also mention that this new design uses LPDDR4, and that was the source of some significant pain, including updates to the provided DRAM driver and special .dtsi configuration for the LPDDR4 that is being used. Fantastic support.
With that said, my client does not want to check in the whole SDK with its cross-compilers, U-Boot source, Linux source, etc. Instead, they would like to use Buildroot, which is an open-source project aimed at creating the above-mentioned components using a simple board configuration file and the ubiquitous 'make' utility. The whole thing will be done using a "br2-external" tree, which essentially means that there is an "overlay" that contains all of our board-specific stuff. The plan is to install a specific version of Buildroot at the same level as our overlay, and then run something like:
make BR2_EXTERNAL=<path_to_our_overlay> our_defconfig
make menuconfig # To configure what we want to create
make savedefconfig # To save our configuration back in our_defconfig
make # To make all of our tools, U-Boot, Linux, and rootfs
Then we would take the resulting binaries and Image file and directly copy it onto a uSD card using the "dd" utility. We would end up with a boot partition and a rootfs partition on the uSD card. Only the overlay and configuration, along with any specific project executables would need to be checked into version control. Buildroot itself would not be in version control - just downloaded and put adjacent to our overlay.
Has anyone gone through getting Buildroot to do this for the AM65X? If so, can you provide any advice on how configure Buildroot to get it to work?
One problem I see is that U-Boot for the AM65X apparently requires both a 32-bit compiler for the R5 core, and a 64-bit compiler for the A53 core. Both cores are involved in the U-Boot execution. This means two separate toolchains (which are provided by the SDK if you build things from what TI provides). However, it appears that Buildroot will only create a single toolchain based on a specific architecture (e.g. 64-bit AARCH64). I do not know how Buildroot can be make to create a second toolchain (e.g. 32-bit ARM), or how to control which pieces get built by each toolchain.
Further, it seems like the U-Boot sources and Linux kernel sources have specific nuances and drivers for the AM65X. Letting Buildroot pull all of the "stock" code down from websites or repositories does not seem like it will work. I'm thinking specifically of the modified DRAM driver that was required to get the LPDDR4 to work, but there may be other differences, too. I confess that I just don't know.
I still consider myself a novice with U-Boot, embedded Linux, and definitely with Buildroot, and to this point have managed to get something working through the SDK only with TI's excellent FAE support.
Is anyone else out there using Buildroot for the AM65X, and if so, is what we are trying to accomplish even feasible with Buildroot instead of TI's (Yocto-based) SDK?
Any advice is welcomed. If I can clarify anything further, please let me know. There is significant time pressure, and if this is not feasible, I'd like to be able to intelligently explain why to my client.
Thanks for listening, and I appreciate any help/advice you can provide.
Scott
