Beaglebone and Raspberry Pi: a general comparison | Mender

Beaglebone has a key strength over Raspberry Pi and that is the larger number of input and output ports on the board. Beaglebone has 96 ports compared to 40 with the Raspberry Pi. The Beaglebone also features analogue inputs, important for directly connecting analogue sensors whereas Raspberry has digital inputs only. The BeagleBone features impressive Input/Output capabilities: the board has a digital I/O pin with 8 different modes of operation, including GPIO (General Purpose Input/Output): 65 digital I/O; 8 PWMs and 4 clock signals; 7 analogue inputs (1.8V); 4 UART; 2 I2C ports and 2 SPI ports.


This is a companion discussion topic for the original entry at https://mender.io/blog/beaglebone-and-raspberry-pi-a-general-comparison

The BeagleBone also has CAN controllers and two microcontrollers onboard. You need external transceivers for the CAN, but that’s an really easy job to put on a daughterboard.

It also has an eMMC onboard, which cannot get loose with vibrations (yes, it happened).

Finally, the beaglebone is stable. We use both the RPi4 and the BBB in our project, and I’m thoroughly underwhelmed by the RPi4. One of our boards can’t use the ethernet port, I have issues with USB3 stability, … A lot of bells and whistles, but I guess one has to wait two or three years to get stability. I’m jumping back to x86+BBB instead of the RPi4 the first chance I’m getting.

Unfortunately, unless things changed recently, Mender’s strategy on the BBB has been to avoid being Debian-compatible w.r.t. overlay loading. I think it’ll probably be the biggest impediment with respect to adoption of the platform with mender.

1 Like

Is the problem that uEnv.txt is not respected? If the comment is related to this thread and answer, then I don’t fully understand why uEnv.txt and/or overlays wouldn’t work. U-Boot is just used as is, and then the control is passed to GRUB, which inherits everything that U-Boot gives it. So if anything is missing, presumably it means U-Boot did not load it in the first place.

Well … as the thread you pointed me to clearly indicates, the u-boot version from mender does not load the overlays listed in the uEnv.txt as the debian one does. Which breaks using Debian out of the box - you essentially have to build a single dtb and make it load.

I patched mender’s u-boot version with Debian-specific modifications to make it happen, and proposed it as a pull request on the mender fork, but this was clearly met with a lot of hostility from the developers, so I dropped it.

People that want to use a stock debian workflow with a BBB can use this prebuilt u-boot: Release Fix recovery boot · tidewise/uboot-mender · GitHub

I think we are talking about different things. You are talking about the direct integration with U-Boot, which was removed from mender-convert last year, due to lack of maintenance.

I’m talking about the integration with GRUB, which only uses the upstream U-Boot (no patches) to chain load itself. Since it uses the upstream U-Boot, my assumption would be that overlays would work, since this is exactly what the Beaglebone guys themselves release, but granted, I have not verified it.

So … some things did change. Thanks, good to know. Now I have to find the time to try it out …

My understanding is that mender-convert now uses the u-boot provided by Debian as-is. Is that right ?

Looks like there is still a workaround in place to use a newer version of U-Boot. It’s still the upstream version though, just a newer one, since the Beaglebone guys have not updated their images in a very long time. If you use a newer Debian image, it should use U-Boot as is from the image.