I’m probably updating a bit much, but…
Once I held the BOOT button, the device was properly identified as a SeeedStudio BeagleBone Green Gateway. The .coffee file I used was an almost exact copy of beaglebone-green-wifi.coffee with wifi replaced with gateway and Wireless replaced with Gateway.
Removing build/hashserve.sock seems to be a common problem with dunfell, so I was able to work through that.
Flashed the image with my custom config.json.
Boot was a bit slow around Load/Save RF Kill Switch and Bluetooth startup (hci0: Reading TI version information failed).
XFRM netlink socket took about 3 minutes to startup, which seems excessive. eth0, resin-dns and supervisor0 have been up for a while, but I’m still waiting for it to show up in my devices. Maybe those settings aren’t read from config.json?
balena ssh ID.local works fine.
Looking at /resin-boot/config.json, it doesn’t match what I put on the flasher boot partition /config.json, so I’ll need to look up how I customize it. It isn’t obvious to me from https://github.com/balena-os/meta-balena.
I’m not finding how to put on my own config.json.
Also…
$ balena join 05488eb.local
"beaglebone-green-gateway" is not a valid device type
I don’t think it makes sense for me to need to use the CLI to inject an updated config.json.
Hi Jason,
When you flashed your custom image, did you add your config.json at that time by placing it in the resin-boot partition? Sounds like you did so not sure why it didn’t take. This page from our docs might offer some insight.
John
OK, Maybe I was looking at the wrong place and looking for the device to show up on my BalenaCloud setup.
root@123456:~# cat /mnt/boot/config.json | jq '.'
{
"apiEndpoint": "https://api.balena-cloud.com",
"apiKey": "XXXX",
"appUpdatePollInterval": 600000,
"applicationId": 1234567,
"deltaEndpoint": "https://delta.balena-cloud.com",
"deviceApiKey": "XXXX",
"deviceApiKeys": {
"api.balena-cloud.com": "XXXX"
},
"deviceType": "beaglebone-green-gateway",
"listenPort": 48484,
"localMode": true,
"mixpanelToken": "XXXX",
"persistentLogging": false,
"registryEndpoint": "registry2.balena-cloud.com",
"userId": 1234,
"vpnEndpoint": "vpn.balena-cloud.com",
"vpnPort": 443,
"wifiKey": "XXXX",
"wifiSsid": "XXXX",
"uuid": "XXXX"
}
I was looking at:
root@161ccf9:~# cat /resin-boot/config.json
{
"deviceType": "beaglebone-green-gateway",
"hostname": "balena",
"localMode": true,
"persistentLogging": false
}
I feel like this is coming down to the CLI/API/Cloud not understanding the beaglebone-green-gateway device type.
19:53 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to pr>
19:53 2020 VERIFY OK: depth=1, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
19:53 2020 VERIFY KU OK
19:53 2020 Validating certificate extended key usage
19:53 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authenticat>
19:53 2020 VERIFY EKU OK
19:53 2020 VERIFY OK: depth=0, C=US, ST=WA, O=balena.io, OU=balenaCloud, CN=vpn.balena-cloud.com
19:53 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
19:53 2020 [vpn.balena-cloud.com] Peer Connection Initiated with [AF_INET]35.169.89.252:443
19:54 2020 SENT CONTROL [vpn.balena-cloud.com]: 'PUSH_REQUEST' (status=1)
19:55 2020 AUTH: Received control message: AUTH_FAILED
19:55 2020 SIGTERM[soft,auth-failure] received, process exiting
Indeed, the API is not aware of this new device type yet. I’m working to add it in the staging cloud environment and will get back to you with details as soon as the image becomes available there.
Meanwhile, we would like to order a device like yours so we can run testing and promote it to the production dashboard too. Can you please confirm that this is the right one and also tell us the hw revision you use: https://wiki.seeedstudio.com/BeagleBone-Green-Gateway ?
1 Like
Yes, that’s the right one. There’s only one revision at this time.
In the meantime, what is the right way to work-around this?
Thanks for confirming the hardware.
You could try using an unmodified config.json from a beaglebone green wifi App in the dashboard, not sure if this is the way you tested before. From what I read the board boots fine, so I’m currently working to get the image in the staging environment, and then you should be able to check it out at https://dashboard.balena-staging.com . Will let you know when it becomes available there.
Oddly, the device showed up this morning, but I didn’t notice. It showed up as a disconnected device as I was reflashing using a config from the staging server. Yet, it never showed up on the staging server.
I’m using beaglebone-green-wifi in the config.json.
Do you need a pull-request from me with the .coffee file and adding the beaglebone-green-gateway.dtb?
Is there a way I can simply get the balena join to stop complaining?
Thanks, I added the coffee file and yocto machine in the repo so it’s not needed. After we get the image in staging you’ll be able to download it from there without injecting the config.json, and it will show up as a Beaglebone Green Gateway. I ordered the board and, after we receive it, we’ll run the BalenaOS test suite and move it from staging to production.
I’m afraid the device type will first need to exist in the API for balena join to work. The config.json you pasted above taken from balena-cloud (not staging) has the deviceType beaglebone-green-gateway, and it won’t show up as the device type doesn’t exist in the api just yet, neither in staging nor in production. Will let you know right away once it becomes available in staging.
I really did update it…
root@cb736de:~# cat /mnt/boot/config.json
{
"apiEndpoint": "https://api.balena-staging.com",
"apiKey": "XXXX",
"appUpdatePollInterval": 600000,
"applicationId": 123456,
"deltaEndpoint": "https://delta.balena-staging.com",
"deviceApiKey": "XXXX",
"deviceApiKeys": {
"api.balena-staging.com": "XXXX"
},
"deviceType": "beaglebone-green-wifi",
"listenPort": 48484,
"mixpanelToken": "XXXX",
"registryEndpoint": "registry2.balena-staging.com",
"userId": 2901,
"vpnEndpoint": "vpn.balena-staging.com",
"vpnPort": 443,
"wifiKey": "XXXX",
"wifiSsid": "XXXX",
"uuid": "XXXX"
}
journalctl seems to report a problem.
31:28 2020 VERIFY OK: depth=1, C=US, ST=WA, L=Seattle, O=balena.io, OU=balenaCloud, CN=open-balena-vpn-ro>
31:28 2020 VERIFY KU OK
31:28 2020 Validating certificate extended key usage
31:28 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authenticat>
31:28 2020 VERIFY EKU OK
31:28 2020 VERIFY OK: depth=0, C=US, ST=WA, L=Seattle, O=balena.io, OU=balenaCloud, CN=vpn.balena-staging>
31:29 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
31:29 2020 [vpn.balena-staging.com] Peer Connection Initiated with [AF_INET]54.83.183.10:443
31:30 2020 SENT CONTROL [vpn.balena-staging.com]: 'PUSH_REQUEST' (status=1)
31:30 2020 AUTH: Received control message: AUTH_FAILED
31:30 2020 SIGTERM[soft,auth-failure] received, process exiting
lines 5940-5963/5963 (END)
Why do all of the BeagleBone boards have separate identifiers anyway? They should all run the same software images.
Can you simply reduce them all to “beaglebone”?
1 Like
Manually editing /mnt/boot/device-type.json to say beaglebone-green-wifi enabled it to join the server.
Doing balena join still fails.
Switching to simply building a beaglebone-green-wifi image and adding my application info with balena config…
Building a beaglebone-green-wifi image with dunfell (with beaglebone-green-gateway.dtb added to meta-balena-beaglebone) “just works” on a BeagleBone Green Gateway. Should have started this way.
Thanks for the support and I look forward to it being official.
For reference (https://github.com/jadonk/balena-beaglebone/commit/3c23e5e73609f82e3f1ecafa652dc5577bfc8f2d):
diff --git a/layers/meta-balena-beaglebone/recipes-kernel/linux/linux-beagleboard_5.4.bb b/layers/meta-balena-beaglebone/recipes-kernel/linux/linux-beagleboard_5.4.bb
index 03bb37a..7cef940 100644
--- a/layers/meta-balena-beaglebone/recipes-kernel/linux/linux-beagleboard_5.4.bb
+++ b/layers/meta-balena-beaglebone/recipes-kernel/linux/linux-beagleboard_5.4.bb
@@ -12,7 +12,7 @@ DEPENDS += "lzop-native"
# Look in the generic major.minor directory for files
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-5.4:"
-KERNEL_DEVICETREE_beaglebone = "am335x-bone.dtb am335x-boneblack.dtb am335x-boneblack-wireless.dtb am335x-boneblue.dtb am335x-bonegreen.dtb am335x-bonegreen-wireless.dtb"
+KERNEL_DEVICETREE_beaglebone = "am335x-bone.dtb am335x-boneblack.dtb am335x-boneblack-wireless.dtb am335x-boneblue.dtb am335x-bonegreen.dtb am335x-bonegreen-wireless.dtb am335x-bonegreen-gateway.dtb"
KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
Hi,
The Beaglebone Green Gateway is now available in the staging dashboard at https://dashboard.balena-staging.com and includes the dtb for the gateway.
Regarding the auth_failed log, if you were seeing this during provisioning and the device type was green-wifi, then it’s an issue that we uncovered recently and are working to fix. The behavior is that during flashing and after flashing is completed, the device does not report post provisioning state in the dashboard. It goes online on the first boot, after it was flashed.
To use balena cli with staging you will need to set an env variable:
BALENARC_BALENA_URL=balena-staging.com balena login
BALENARC_BALENA_URL=balena-staging.com balena devices supported
Please note that the staging environment is not meant to be used for production devices, as soon as we receive the hardware we’ll run the tests and add it in the production dashboard. Might take a week or two until we receive it but will let you know when it becomes available there too.
1 Like