after years working with the “old” BBG I wanted to switch. The “new” Green Eco gets delivered with a working debian on the eMMC, but I am looking for an image that runs out of the box from the sd-card. I tried several debians from Index of /rootfs (debian 12 & 13 in combination with kernel 6.1, 6.6, 6.12 and 7.3). All fail to appear on the network. I followed the UART-Output and narrowed it down to a misbehavior in u-boot.
The pre-installed debian boots with:
debug: [enable_uboot_overlays=] ... loading /boot/dtbs/6.12.40-bone30/am335x-bonegreen-eco.dtb ... 96314 bytes read in 13 ms (7.1 MiB/s)
Somehow the wrong device-tree gets selected, despite am335x-bonegreen-eco.dtb being present in the device-tree-folder for all 6.x++ kernels. I tried commenting out enable_uboot_overlays=1in uEnv.txt and it seems to do the trick.
Is that a bug? I looked for answers online, but found no hint, that overlays are problematic for the Green-Eco. Am I still able to load my own device-tree-overlays?
The ECO is a special TI/Seeed board for the Chinese only market.. If it’s not loading the correct overlay with our images, make sure u-boot is built after Dec 30th 2025.. ( Commits · beagleboard/u-boot · GitHub )
The version packaged in:
voodoo@21-am335x-bbb:~$ dpkg --list | grep u-boot-am335
ii bb-u-boot-am335x-evm 2022.04.20240115.8-0~trixie+20260122 armhf beagleboard.org u-boot for am335x_evm
It uses a brand new PMIC (TPS65214 a new variant of the TPS65219) that went mainline fairly recently, it’s advised to use 6.18.x or newer for Regulator support..
I checked U-boot during boot - even with the images build today on Index of /rootfs it tells me right after powerup, that the older version is used: U-Boot 2022.04-ge543709d (Jun 27 2025 - 18:09:26 +0000). So I guess I have to flash a newer image to the eMMC and everything should work?
BTW: I bought 40 of these Green Eco in Europe - they came right from Frankfurt-Warehouse of Seeedstudio. So no Chinese only market, I guess.
As you predicted, after running the update-command, the image boots naturally even with enable_uboot_overlays=1 and gets network right away. Thanks a lot for the help! I think the problem is solved. Now I have to update the eMMC on the 39 other nodes.
As there is only little information on the green eco, may I ask two other questions?
Our testbed only recently made the jump from kernel 4.19 to 6.1. There are serious changes and drawbacks for us migrating to 6.18. I saw the board booting fine with older kernels. Would you worry not having the direct support for the PMIC?
What did Seeed think by not populating the power-button? Lets save half a cent and let debugging users without remote access corrupt the filesystem by pushing reset. I guess Eco stands for economical
The biggest thing, is probably the default cpufreq, pmic rails should be pre-setup in u-boot. Once you stabilize on 6.1.x, test 6.6.x/6.12.x/6.18.x as from a high level they are pretty close for am335x devices..
So funny story, it’s actually hiding a RTC wake-up bug on am335x. The designer of the ECO started with the the Black and EVM as reference but tried adding later fixes/optimizations. By the time of final verification and testing, we found that no one had ever got (RTC-wakeup thru EXT_WAKEUP_EN pin) working on am355x devices on mainline. So it was decided to just remove the button that doesn’t work.
The fun part of EXT_WAKEUP_EN is it’s default state (off)… So you need to start the board, tell the pmic to enable it, then shutdown… then the button could work to turn on…
Thanks for the info! Regarding the unpopulated Wakeup-Button I somehow thought it’s the same functionality as the previous Power-Button on the Green-Boards. It was always able to shutdown and wake the system - at least for me. But now that I used tweezers to push the new Wakeup-Button I can confirm that it does not shutdown the system. But okay - the Shutdown-Pin is still routed to the Pinheader P9_09.