Bare metal programming is an interesting activity that allows to get a new perspective for somebody that usually writes applictions for UNIX-like operating systems. Let's see how we can implement a driver for ENC28J60 ethernet controller from scratch and integrate a minimal IP stack to get some connectivity

Even when you define your own cross compilation toolchain in Bazel, it still comes with a set of predefined, 'sane' defaults for the compilation and linking flags. But if you want to take full control over the generated commands, you can turn off all the default features, that

BeagleBone has the possibility to load the bootloader using the serial console and xmodem. To do that lunch picocom with additional --send-cmd definition: $ picocom -b 115200 /dev/ttyUSB0 --send-cmd "sx -vv" If there is no available bootloader on the eMMC and the SD card is not available the

The BaegleBone board seems to have some problem with USB Ethernet gadget not working correctly. It happens quite frequently that the the USB Ethernet device is not able to receive any packets, although transmission is still possible: root@beaglebone:~# ifconfig usb0 usb0 Link encap:Ethernet HWaddr 22:04:F8:8E:

A great introduction to shared libraries is available from Michael Kerrisk: * https://man7.org/conf/lca2006/shared_libraries/index.html A detailed analysis of shared libraries can be found in Ulrich Drepper's paper: * https://akkadia.org/drepper/dsohowto.pdf This paper is a must read if you want

After writing a sketch of own C++ rules, which you can find here: * https://ltekieli.com/writing-custom-bazel-c-rules/, we might extend this example with toolchain support. In order to not conflict with existing C++ toolchain implementation we need to define a new toolchain type using a special rule: toolchain_type( name

All the code that you can read below, can be found under: https://github.com/ltekieli/custom-oe-distro OpenEmbedded, Yocto, bitbake confusion. I have to admit that Yocto and OpenEmbedded were always quite confusing in terms of what is what, especially looking at the history of both and the integration decisions

So previously [/using-crosstool-ng-to-generate-a-gcc-toolchain/] I shortly introduced how to build a custom toolchain, now it's time to put it to use. A bare toolchain is rarely sufficient enough to build useful applications. We usually depend on external libraries, whether it's boost, protobuf or any other piece of

crosstool-ng [https://crosstool-ng.github.io/] is a handy tool for obtaining custom gcc toolchains which are tailored to your needs. This is especially useful when you are up to building a custom system for your embedded device, like a raspberry pi or a beagleboard. Building crosstool-ng itself crosstool-ng can be