I’m trying to use a Jetson TX2 4GB module. It’s supported in meta-tegra using the jetson-tx2-4gb machine but I don’t see it in Balena. Has anyone got it to successfully work? I came across this repo and discussion but I don’t think it’s actually working (based on commit messages). I tried adding a jetson-tx2-4gb machine (cloned jetson-tx2) in balena but the resulting image wouldn’t boot. Before I sink a ton of time debugging the cause I thought I’d ask if anyone has got it to work.
Thanks @mpous, I did start there but the TX2 module isn’t the same as the TX2 4GB module. The two use different DTBs and even have a different *.conf file in L4T when flashing. The meta-tegra layer has a separate machine file for the 4GB version.
I’ve now got a booting image. It doesn’t look like it’s registering with the Balena cloud yet but I’m hoping I can get that sorted out. When I do, I’ll make a pull request to get these changes in.
Thanks @mpous. I think I’m almost there. You wouldn’t by chance know what program makes the call to the balena cloud to register a device do you? When I boot up the TX2 4GB, I see
I should also add that I first configured the image using
balena os configure
I also tried downloading a config.json file for my application from the dashboard and copied that into /mnt/boot (overwriting the existing one) but that returned the same result. The config.json files look correct.
That weird error Pool overlaps only showed up that one time.
I’ve tried “faking” this device as an existing one in the dashboard (jetson-nano-emmc) but I still get the same error.
root@e277407:~# balena logs 6
[info] Supervisor v12.5.10 starting up...
[info] Setting host to discoverable
[warn] Invalid firewall mode: . Reverting to state: off
[info] 🔥 Applying firewall mode: off
[debug] Starting logging infrastructure
[debug] Performing database cleanup for container log timestamps
[success] 🔥 Firewall mode applied
[info] Starting firewall
[debug] Starting api binder
[info] Previous engine snapshot was not stored. Skipping cleanup.
[debug] Handling of local mode switch is completed
(node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods inste
ad.
[info] API Binder bound to: https://api.balena-cloud.com/v6/
[event] Event: Supervisor start {}
[debug] Connectivity check enabled: true
[debug] Starting periodic check for IP addresses
[info] Reporting initial state, supervisor version and API info
[info] Attempting to load any preloaded applications
[info] VPN connection is not active.
[info] Waiting for connectivity...
[info] Starting API server
[info] Supervisor API successfully started on port 48484
[info] Applying target state
[debug] Ensuring device is provisioned
[event] Event: Device bootstrap {}
[info] New device detected. Provisioning...
[event] Event: Apply config change in progress {}
[event] Event: Apply config change success {}
[error] LogBackend: server responded with status code: 401
[event] Event: Device bootstrap failed, retrying {"delay":30000,"error":{"message":""}}
[debug] Finished applying target state
[success] Device state apply success
I faked the device as a jetson-tx2 and it registered on the cloud. So far everything looks good. I’ll do some more testing and then submit some pull requests (jetson-flasher needed to be updated as well). Thanks.
@mpous , one thing I’m running into while faking the device. I’m editing the file I compiled (balena-image-flasher-jetson-tx2-4gb.balenaos-img) to fake it as a jetson-tx2 so it will register. In the first partition on the image I’ve found a config.json file and a device-type.json file. I’m putting the faked files in there (ones that are confirmed to work if I copy them to the /mnt/boot folder of a flashed device) and then flashing them using jetson-flash. The flashing works but for some reason it’s modifying the device-type.json file back to the original machine name (jetson-tx2-4gb) instead of the faked name (jetson-tx2). Do you know where that is happening? I would prefer not to have this a 2-step process (flash device, let it boot and then modify the device-type.json so it will register with balenaCloud).
Hi @smithandrewc, indeed the device type you’re working to add support for isn’t available in the API and that’s why it isn’t registering as tx2-4gb and needs masquerading. Regarding the device-type.json, I think you’ll need add it to the list of files to be copied from the flasher image.
By the way, if you want to PR your changes to add community support for this device type maintained by you, please check if the boot blob doesn’t need some slightly different patching that might be specific to the TX2 4GB. To do this you need to check if the device boots correctly after flashing your image with using the SD card. If it doesn’t, you can paste the small differences between the blob stored in mmcblk0boot0 of the device flashed with jetson-flash into a diff file and apply it for the tx2-4gb only in the binaries recipe.
Once the device boots correctly after flashing with the sd-card it will boot fine after performing a hostOS update too.
I’m not flashing it to an SD card, I’m flashing directly to the emmc on the TX2 4GB. Initially I did try the SD card method and it didn’t work (wouldn’t boot). I prefer to flash the emmc directly since not all of our boards have an SD card available but I’ll looking into your suggested changes and test them out for completeness before I issue the pull request. Thanks.
I made the changes you suggested for the tegra-flash-dry and I can confirm it fixes the SD card flashing issues. Using the changes from the second pull request, I can flash the emmc directly or flash using the SD card method.
Hi @acostach, I added some comments to the new PR. It boots ok when directly flashing the emmc but when using the sd card method it doesn’t come back up after the reboot. I left the details in the PR. Thanks.