The "buildroot" approach

[Enoch]

Hi,

Buildroot, to those who are not familiar with, is a minimalist approach to building embedded Linux.

With this approach one does software development using desktop cross compilation tools rather than rely on Gcc and friends running on the much slower BBB.

Modifying Linux drivers, creating one own's device tree is easy this way.

I had good Buildroot luck with the BBB using simple capes (for serial communication).

However, a complex cape such as the "LCD 7.0" CAP-TOUCH BEAGLE BONE" is not an easy task "to buildroot" for the formidable number of components (drivers, packages, ...) that need to be correctly selected.

I would like to create Buildroot/Linux defconfig-s where hardware support is on par with Robert Nelson's fine Debian image:
BBB-blank-debian-9.5-lxqt-armhf-2018-08-20-4gb.img.xz with /boot/uEnv.txt having dtb=am335x-boneblack-bbb-exp-c.dtb ...

Has anyone taken this BBB buildroot approach with a similar complexity LCD cape?

Thanks, Enoch.

[r.rei...@robopec.com]

Hi,

I had also some issues porting my system from Robert's Debian image to a Buildroot config (using PRU).

I had to choose between TI or Robert's methods to add capes, so with device tree overlays or write a single device tree with everything hard coded.

I think it would be nice to join the effort and create a Buildroot defconfig using Robert's patches but uBoot in order to use the "capes manager" and using the same kernel config as starting point.

And sorry, I have never used the LCD cape.

Sincerely,

Romain

[Enoch H Wexler]

Thanks Romain,

I succeeded too with Buildroot by ditching the linux-stable 4.16.18-rt12 kernel (*) for beagboard/linux 4.14.67-ti-r73 and using Robert's am335x-boneblack-bbb-exp-c.dts.
There must be some cape driver issue to resolve in 4.16.y

Like you I think that the Beagleboard organization and its TI sponsors would benefit having a dedicated mailing list around the Buildroot method of embedded Linux development. TI is a Yocto member but I prefer Buildroot simplicity. In any case, working with BBB and friends via their own resource constrained Debian distribution is an inconvenient method for any serious product development...

Cheers, Enoch.

(*) Which works for me well in another BBG case.

---

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/1t6VLjrzBRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9149a708-48a3-4bf7-bba8-0f581d4a2cd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Enoch Wexler, Embedded Systems Engineer
Voice/SMS: +1 (551) 333-9391

[Robert Nelson]

On Wed, Sep 5, 2018, 10:01 AM Enoch H Wexler <emc.con...@gmail.com> wrote:

Thanks Romain,

I succeeded too with Buildroot by ditching the linux-stable 4.16.18-rt12 kernel (*) for beagboard/linux 4.14.67-ti-r73 and using Robert's am335x-boneblack-bbb-exp-c.dts.

This cape is special, they swapped the i2c bus that could have had an eeprom with id for detection for a can bus.

Thus its an undetectable custom board.

Regards,

[Enoch]

Hi Robert,

1) Can the beagleboard/linux 4.14.67-ti-r73 kernel support the SGX530 graphic accelerator of BBB's AM3358 SoC? 
buildroot/package/ti-sgx-km says that it requires a special (Imagination Technologies built) kernel and indeed it fails to build using beagleboard/linux standard kernel. No luck with the earlier ti-gfx libraries either.

Do you use the SGX accelerator at all in your debian distributions?
I'd like to have OpenGL ES 2.0 compatibility... but that seems to require a functioning graphic accelerator.

2) Does your debian distribution succeed to initialize AM3358's internal power management module (Cortex-M3)?

Thanks, Enoch.