Support for BeagleBone Green Gateway

There’s a new variant of SeeedStudio BeagleBone Green Wireless called SeeedStudio BeagleBone Green Gateway. I tried using the Green Wireless image, but it didn’t seem to boot.

Is there an easy way to add the updated u-boot and .dtb or otherwise get support?

@jkridner the first thing I’d do is check what the output of the boot process is using a serial debug console to help figure out why the device is failing to boot. If you know what you’re doing with board support check out these links: and the BeagleBone repo is here:

It would be great to see support added for this new board!

Serial is always helpful. The board ends up booting as a BeagleBone Black. Not terribly surprising, based on the EEPROM value and how old the u-boot is.

It turns out the flashing operation is working, but the LEDs never do the Larson scanner effect we do for the Debian flasher images. That would really help to know it was flashing. Unsure if it ever powered off before, but I watched it go to completion and power off this time.

I tried copying am335x-bonegreen-gateway.dtb to am335x-boneblack.dtb, but the kernel is just too old and doesn’t boot.

Back to the Yocto drawing board. I so thought I was done with having to do that myself.

Out of curiosity, because you mention “ends up booting as a BeagleBone Black”, what happens if you actually try flashing our BeagleBone Black image? Same thing, non-booting (but very handsome) paperweight?

(A followup step may be to once again overwrite the .dtb file as you did previously)

It boots, but it doesn’t have what is needed to enable the WiFi… so, it isn’t on the network. I guess I could have tried the Ethernet (since Gateway has both), but it doesn’t solve my needs.

Getting this Yocto build up and running after I haven’t done so in years is a bit more arduous than I even remembered. Is there any kind of chance you could build a similar image with Buildroot?

Buildroot will not work, no…but…I have pinged our Device maintainers to have a look here and see what they can do to assist. :slight_smile:

Cannot work? Or, just really hard?

Oh man, flashbacks to why I abandoned OE. Sooooo fragile. Why don’t you support newer versions than 2.6?!? I’m having problems with gcc 10 on such an old version of OE. Guess I’ll need to switch to an older gcc.

OK, this is nuts. I’d have to go back to a glibc older than 2.30.

Is it just that the README is really old? There is a dunfell layer and I’d expect it is tested, despite the README.

Hey Jason, we merged Dunfell to meta-balena 2 days ago, and we’ve opened to keep track of updating all beaglebone images to it. You can keep an eye on that issue, or we’ll get back to you once the issue is closed.

Hi Jason,

Please check if this PR on dunfell Update to dunfell by acostach · Pull Request #249 · balena-os/balena-beaglebone · GitHub works as a base for your local build. It has the kernel 5.4.70 and u-boot 2019.04.

As usual, after cloning and updating the git submodules you can trigger the build with:

balena-yocto-scripts/build/barys -b build_bbgw -m beaglebone-green-wifi --shared-sstate /home/user/sstate-cache/ --shared-downloads /home/user/downloads/ -d

I’m trying to get thud to build right now. Using your docker image to try to enable a build environment with the older tools.

jkridner@slotcar:~/workspace/balena-beaglebone$ cat 
#!/bin/bash -x
GID=$(getent group docker | cut -d: -f3)
docker run \
  -e BUILDER_UID=$(id -u) -e BUILDER_GID=$GID \
  -v /home/jkridner/workspace/balena-beaglebone:/yocto/resin-board \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --privileged \
  -it resin/yocto-build-env \

jkridner@slotcar:~/workspace/balena-beaglebone$ cat 
set -e -x

# Create the normal user to be used for bitbake (barys)
echo "[INFO] Creating and setting builder user $BUILDER_UID:$BUILDER_GID."
groupadd -g $BUILDER_GID docker
useradd -m -u $BUILDER_UID -g $BUILDER_GID -G docker builder

# Start barys with all the arguments requested
echo "[INFO] Running build as builder user..."
sudo -H -u builder /yocto/resin-board/balena-yocto-scripts/build/barys -m beaglebone-green-wifi

However, I’m getting an error within the do_compile step of docker-disk.

| Step 6/6 : CMD /
|  ---> Using cache
|  ---> 0ce9dd511162
| Successfully built 0ce9dd511162
| Successfully tagged docker-disk-1521992:latest
| docker: Error response from daemon: error while creating mount source path '/yocto/resin-board/build_bbgw/tmp/work/beaglebone_green_wifi-poky-linux-gnueabi/docker-disk/balena_armv7hf-supervisor-v11.14.0-r0/build': mkdir /yocto: read-only file system.
| WARNING: exit code 125 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /yocto/resin-board/build_bbgw/tmp/work/beaglebone_green_wifi-poky-linux-gnueabi/docker-disk/balena_armv7hf-supervisor-v11.14.0-r0/temp/log.do_compile.1521701)
ERROR: Task (/yocto/resin-board/build_bbgw/../layers/meta-balena/meta-balena-common/recipes-containers/docker-disk/ failed with exit code '1'

I’m not a pro at using docker and all the docker-in-docker layers are confusing me a bit.

It looks like running docker as a child (new process within the container) is working, rather than running as a sibling (providing access to the same docker instance that is running the resin/yocto-build-env container).

Bunch of QA issues around uid matching and potential host contamination, but I’m not sure that it isn’t a coincidence my uid is 1000.

Once I figure out next how to add a new board, I’ll next try out switching from thud to dunfell.


To build an image specifically for this board you’ll need to create the yocto machine, probably the beaglebone green wireless machine can be re-used and renamed, and also add a coffee file for it.

The Dunfell branch has the updated patches for u-boot 2019.04, should now recognize the board so probably the fastest way is to check if the device boots a Dunfell beaglebone-green-wifi build. Let us know how it works!

Sorry, I didn’t read your message very well. Last night, I got the new machine added and started working on the bootloader. I didn’t realize you had updated the bootloader as well, so that should help me over my last hurdles and I’ll give it a try later today.

Thanks for all the support!

That’s great, please let us know how it works!

Good news: it boots.

Bad news: when I provide the ‘-d’ parameter to bayrs to get a developer image I can log into, the build hangs:

BeagleBoard-XM                           : $ MACHINE=beagleboard-xm bitbake resin-image
BeagleBone Green Gateway                 : $ MACHINE=beaglebone-green-gateway bitbake resin-image-flasher
BeagleBone Green                         : $ MACHINE=beaglebone-green bitbake resin-image-flasher
BeagleBone Green Wireless                : $ MACHINE=beaglebone-green-wifi bitbake resin-image-flasher
BeagleBone Black                         : $ MACHINE=beaglebone bitbake resin-image-flasher
PocketBeagle                             : $ MACHINE=beaglebone-pocket bitbake resin-image

[000000001][LOG]BalenaOS build initialized in directory: build.
[000000001][LOG]Run build for beaglebone-green-gateway: MACHINE=beaglebone-green-gateway bitbake resin-image-flasher 
[000000001][LOG]This might take a while ...
NOTE: Retrying server connection (#1)...
NOTE: Retrying server connection (#2)...
NOTE: Retrying server connection (#3)...
NOTE: Retrying server connection (#4)...

Also, the flasher seemed to report the wrong board.

Board: BeagleBone Black
board_name=[A335BNLT] …
board_rev=[GG1A] …
loading /boot/am335x-boneblack.dtb …

So, I still have the wrong bootloader. Come to think of it though, I didn’t hold the BOOT button!

The newly flashed u-boot didn’t print any status, so I’m unsure which device tree it loaded.

Anyway, back to trying to build the development version image so I can log in. Also, I need to find where to provide my own config.json.

For future reference:

Looks like I’m running into an issue discussed here:

Hi Jason,

I’ve let the devices team know that you’ve made progress but have a few more hurdles. They’ll get back to you when they can.