Jeston AGX Orin AVerMedia D315 Carrier Board Support

Product support balenaOS
, ,
1

Hey there, we’ve recently begun moving to a Jetson AGX Orin-based fleet for our product, and to this end we ended up selecting this carrier board.

The good news is that this basically already works with the existing device support in Balena: We’re able to flash it via jetson-flash and the device boots and shows up in Balena Cloud properly. Almost all of the hardware also works, except for one part that we rely on: The USB3 ports.

I’m reaching out here in case there’s a simpler way than going through the entire custom board documentation since support is effectively already 95% there and most of the BSP stuff etc isn’t really necessary.

We’ve already tried loading this as an overlay DTB by:

  • Copying the file to /mnt/sysroot/active/current/boot/ on the running system.
  • Setting Define the file name of the DTB to be used. Only supported by supervisor versions >= v14.2.16. to the filename tegra234-p3701-0004-d315ao-no_camera.dtb.
  • Rebooting

The dmesg log does show that a string from that DTB file now appears so we assume it’s being loaded, but we don’t really know enough about how this stuff works to say that for certain. Problematically, even with this DTB loaded (or several others we’ve tried), the USB3 ports stubbornly refuse to work.

The behavior is as follows:

  • USB2 ports work perfectly fine, connected devices are immediately recognized
    USB3 ports don’t detect any devices at all
  • No messages relating to those ports appear in the dmesg logs
  • Devices plugged into these ports do not receive power
  • lsusb shows the two USB controllers (even the USB3 one), just no child devices

Here is a screenshot of lsusb with a USB3 device connect (but not showing up). Several USB2 devices are connected and do appear:

Screenshot 2023-12-15 at 16.46.04
Screenshot 2023-12-15 at 16.46.041136×722 176 KB

I’d provide the DTB file as well, but apparently I can’t upload that directly and not even a ZIP is accepted, so I can mail it on request, if required.

There’s currently a device running with UUID 3b9481fd9b9177e35b4c9ba4ae3e5e83 and support access enabled, just in case.

If anybody has any hints as to what might be causing this, it’d be much appreciated. Some thoughts we’ve had:

  • The DTB files are not being loaded properly
  • The DTB files are wrong and we need different ones
  • Some weird BalenaOS interaction with however these USB ports are connected
2

Small update: I’m pretty sure the DTB is being loaded properly now as the machine name does change between when it’s applied and when it’s not:

Without custom DTB:
Machine model: Jetson AGX Orin Developer Kit

With custom DTB:
Machine model: NVIDIA Jetson AGX Orin - AVerMedia D315

Unfortunately the application of said DTB file does not make the USB3 ports work, they remain just as inactive as they were before. Since we’ve already tested that they’re not physically broken, what could cause this behavior? Does BalenaOS need any extra ‘help’ aside from these DTB files?

I checked the USB firmware version as well and -far as I can tell- it should be the latest available version:
Firmware timestamp: 2023-02-10 03:48:10 UTC, Version: 80.05 release

Some relevant excerpts from the dmesg output:

[    0.515619] tegra-xusb 3610000.xhci: Adding to iommu group 1
[    2.194198] tegra-xusb 3610000.xhci: Firmware timestamp: 2023-02-10 03:48:10 UTC, Version: 80.05 release
[    2.194206] tegra-xusb 3610000.xhci: xHCI Host Controller
[    2.194232] tegra-xusb 3610000.xhci: new USB bus registered, assigned bus number 1
[    2.195112] tegra-xusb 3610000.xhci: hcc params 0x0180ff05 hci version 0x120 quirks 0x0000000000050810
[    2.195160] tegra-xusb 3610000.xhci: irq 238, io mem 0x03610000
[    2.196396] tegra-xusb 3610000.xhci: xHCI Host Controller
[    2.196400] tegra-xusb 3610000.xhci: new USB bus registered, assigned bus number 2
[    2.196407] tegra-xusb 3610000.xhci: Host supports USB 3.1 Enhanced SuperSpeed

I also came across this thread, but it doesn’t seem to have gone anywhere.

4

I read something about disable_acs_redir which may or may not help in this case and wanted to try that out, but as it turns out it’s apparently simply impossible to set custom kernel parameters when using BalenaOS? That seems like a major oversight, and of course prevents me from even testing this in the first place.
I could try building a custom base image, I suppose, but surely there’s gotta be an easier way to achieve this goal than that. This is compounded by the fact that the balena-jetson-orin doesn’t really support building images on an Apple M1-based system, which makes everything even worse in my particular case.
Ideally I’d like to try setting pci=disable_acs_redir=pci:12D8:2404 (which should be the correct Bus/Port of the affected USB controller in this case), but no dice.
Are there any other ways to achieve this without suffering a lot of pain?

Edit 1: Based on this old forum reply I figured out that there is a version of the file that is mounted as R/W, though I’m unsure whether modifying it has any actual effect on the boot process or not. I did make the changes in there on the running system and subsequently rebooted, but nothing really changed, far as I could tell. The mystery lives on for another day…

Edit 2: I’m also attaching the detailed output of lsusb for the USB3 part of the XHCI controller, in case it helps:

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.10
  bDeviceClass            9
  bDeviceSubClass         0
  bDeviceProtocol         3
  bMaxPacketSize0         9
  idVendor           0x1d6b
  idProduct          0x0003
  bcdDevice            5.10
  iManufacturer           3 Linux 5.10.120-l4t-r35.4.ga xhci-hcd
  iProduct                2 xHCI Host Controller
  iSerial                 1 3610000.xhci
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
        bMaxBurst               0
Hub Descriptor:
  bLength              12
  bDescriptorType      42
  nNbrPorts             4
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  bHubDecLat          0.0 micro seconds
  wHubDelay             0 nano seconds
  DeviceRemovable    0x00
 Hub Port Status:
   Port 1: 0000.02a0 lowspeed L1
   Port 2: 0000.02a0 lowspeed L1
   Port 3: 0000.02a0 lowspeed L1
   Port 4: 0000.02a0 lowspeed L1
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x002b
  bNumDeviceCaps          2
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x0008
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat         598 micro seconds
  SuperSpeedPlus USB Device Capability:
    bLength                28
    bDescriptorType        16
    bDevCapabilityType     10
    bmAttributes         0x00000023
      Sublink Speed Attribute count 3
      Sublink Speed ID count 1
    wFunctionalitySupport   0x0001
    bmSublinkSpeedAttr[0]   0x00050034
      Speed Attribute ID: 4 5Gb/s Symmetric RX SuperSpeed
    bmSublinkSpeedAttr[1]   0x000500b4
      Speed Attribute ID: 4 5Gb/s Symmetric TX SuperSpeed
    bmSublinkSpeedAttr[2]   0x000a4035
      Speed Attribute ID: 5 10Gb/s Symmetric RX SuperSpeedPlus
    bmSublinkSpeedAttr[3]   0x000a40b5
      Speed Attribute ID: 5 10Gb/s Symmetric TX SuperSpeedPlus
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled
5

Hi @byteminer , we are currently looking into defining a uniform way of applying custom kernel cmdline parameters for all device types. We do not have a timeline for when this will be available but if you want to do a quick test, you can do that by editing /mnt/sysroot/active/current/boot/extlinux/extlinux.conf and add the extra args you need and then reboot the board. Note that this change will not persist between OS updates.

1 Like
6

Thanks for the confirmation, looks like I was on the right track then, at least.
Unfortunately it appear that I was on the wrong train, since the kernel parameter did indeed not do anything. I confirmed that it was actually considered via the dmesg logs and it does appear in there. The USB3 ports still don’t work, however. Alas, it was a shot in the dark in any case.
If anyone has any ideas as to what could cause this odd USB behavior (since that is the original problem), I’m all ears.

7

I’ve looked in the BSP download page for the product you linked but I don’t see any diff between the BSP that comes from Nvidia for L4T 35.4.1 and the one provided by the manufacturer. Maybe they provide this on request? I see the final image provided as a 3GB compressed package but that will make it pretty difficult for you to isolate what’s been changed for this carrier board in particular.

8

Yeah, I ran into that road block as well, but I wrote a small script to diff the original L4T download from NVidia vs the carrier-provided BSP. Turns out there’s several dtb’s that differ, though I believe there’s only one that likely matters.

I’ve decompiled the original one and the carrier-provided one, the results of which are attached below. Maybe that can give a hint of sorts.
There are some differences that one might expect, such as some USB ports being disabled (because they don’t exist on this carrier board), so that matches up.
I also notice that a lot of the phandle pointers are offset by 1, not sure why this is the case.

Either way, I’ve tried applying the compiled version of the d315-5.dts file below, unfortunately without any change in results.

d315-5.dts.txt (551.6 KB)
nvidia.dts.txt (550.7 KB)

In case it helps, the total list of DTB files that exist in the carrier-provided BSP package but not the NVidia one is as follows:

avt-p3701-0004-d315ao-ar0230.dtb
avt-p3701-0004-d315ao-no_camera.dtb
avt-p3701-0005-d315ao-ar0230.dtb
avt-p3701-0005-d315ao-no_camera.dtb
tegra194-p2888-0001-e3366-1199.dtb
tegra194-p2888-0001-p2822-0000-imx185_v1.dtb
tegra194-p2888-0001-p2822-0000-imx274-hdmi.dtb
tegra194-p2888-0006-e3366-1199.dtb
tegra194-p2888-0008-e3366-1199.dtb
tegra194-p2888-0008-p2822-0000-safety.dtb
tegra194-p2888-as-0006-p2822-0000.dtb
tegra194-p2888-as-p3668-p2822-0000.dtb
tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-a1-cphy.dtb
tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-c1-dphy.dtb
tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-innolux-c1-dsc-dphy.dtb
tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-tianma-a-dphy.dtb
tegra234-p3701-0000-as-p3767-0003-p3737-0000-dsi-tianma-b-dphy.dtb
tegra234-p3701-0000-as-pxxxx-p3737-0000.dtb
tegra234-p3701-0000-p3740-0000.dtb
tegra234-p3701-0002-p3740-0002-safety.dtb
tegra234-p3701-0008-p3740-0002-c01-safety.dtb

Out of those, I believe that avt-p3701-0005-d315ao-no_camera.dtb is the primary one, though I am unsure.

9

Maybe there is some pinmux configuration applied by a lower level bootloader like mb1/mb2? You can check the machine.conf in the manufacturer BSP and see if it specifies any custom pinmux.cfg or pinmux.dtsi files. If it does, bring it over in jetson-flash using this example to replace the default pinmux.cfg.

For example, in the standard BSP we see:

35.4.1/Linux_for_Tegra$ cat p3701.conf.common | grep pinmux
PINMUX_CONFIG="tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi";

or

35.4.1/Linux_for_Tegra$ cat jetson-agx-orin-devkit.conf | grep pinmux
	# update pinmux for concord
				PINMUX_CONFIG="tegra234-mb1-bct-pinmux-p3701-0000.dtsi";

but the manufacturer BSP may specify other files. You can see exactly which pinmux files and device-tree are used in the logs, when flashing the board with the vendor image.

Then in jetson-flash you can bring in the custom files to be used during flashing:

fs.copyFileSync(path.resolve(__dirname, '../MyCustomCfgs/tegra234-mb1-bct-pinmux-p3701-0000.dtsi'), workPath + '/bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000.dtsi');

You’ll probably need to also bring in that custom kernel dtb after flashing the board, like you mentioned in the first post.

1 Like
10

Ah, that’s an excellent tip, thank you very much.

After some investigation I figured out that the vendor did not provide any new files, but instead modified the existing ones. Specifically I found these two:

  1. bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
  2. /bootloader/t186ref/BCT/tegra234-mb2-bct-scr-p3701-0000.dts

I set things up as you recommended and verified that the files were indeed changed and copied. The former I ensured by checking the md5sum during the flashing process in the workPath, and the hashes matched the modified ones that I supplied.
In the logs I was also able to see that the files were copied correctly:

copying pinmux_config(/tmp/Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi)... done.
...
copying scr_config(/tmp/Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb2-bct-scr-p3701-0000.dts)... done.

I subsequently flashed the Jetson with this modified setup and loaded the DTB again just like before, verifying that it was indeed loaded properly by checking the machine name, which did change after its application.

Unfortunately I was unable to observe any kind of change in behavior: The USB3 ports are still unresponsive and don’t provide power to any device connected to them. The 10Gbps speed controller does show up in lsusb just as before though.

Edit 1: I’ve shot the AVerMedia guys an inquiry as well, perhaps they can provide some more insight on the exact DTB’s we might need. Will update here if anything comes of that. In the meantime, I’ll keep this going as far as I can take it.

I’ve also just re-flashed the vendor-provided BSP, just as a sanity check, and the USB3 ports do indeed work just fine on there. Really struggling to figure out what differs here at this point, the pinmux and the main DTB overlay seem to be the two main differences, far as I can tell.

Edit 2: Man, I just realized I typo’d the name Jetson in the thread title and I’m unable to change it, rip.

11

Excellent news for once: I’ve actually gotten the USB3 ports to work! The way I got there, however, is the ugliest thing I’ve ever produced.

Specifically -given that I was rather helpless and exasperated at some point during the exploration of this issue- I attempted the shotgun approach: I wrote a script to compare the MD5 hashes of every single file between the vendor-provided BSP and the original Nvidia one, copying out every single file that differed, no matter what it was.

After removing BOOTAA64.efi, uefi_jetson.bin and the kernel Image files, I was left with 49 modified files of various description, mostly DTB’s and some bootloader stuff, including the original DTB and pinmux I experimented with above.

Turns out that on their own, these few files from the initial attempts didn’t help much, but the whole barrage of everything at once somehow made it work. I extended jetson-flash such that it is able to take in an extra ‘overlay’ folder and simply copy the contents of that folder (directory structure included) into the workPath before flashing, overwriting the Nvidia-provided files or creating new ones where appropriate. I then supplied the flashing script with the delta folder I’d generated.

Lo and behold, it worked. I didn’t even need the overlay DTB anymore, so the board just works fine right after flashing now, without any need for additional configuration via the Balena dashboard, which is nice.

One thing that I suspect has something to do with this is the UPHY lanes and how they’re assigned, which probably happens in one of the 40+ DTB files that I didn’t initially investigate. All of that came from this post on the Jetson forums.

This resolves our immediate issue and we’re now able to use the board with Balena as we’d intended, which is a big relief.

To maybe produce something useful out of this whole ordeal for the wider audience: Provided that I somehow manage to extract the DTB’s that are actually essential for this carrier board to function (likely by flashing and re-flashing with varying subsets of the full set I have right now until I arrive at the minimum working set), would it somehow be possible to contribute carrier board support to Balena directly somehow?

I’m not very in tune with the process for this (aside from knowing that one exists), but I assume it’s likely possible. If I showed up in one of the repos with a set of DTB’s and config changes, would that work or is anything else needed?

Worst case I supposed we can just maintain a fork of jetson-flash modified for our own purposes, but actual support would be nicer, of course.

1 Like
12

@byteminer i’m happy that it is working even if it’s ugly.

Let me inform the devices team and check the next steps! Expect some delays as it’s holidays time :christmas_tree:

14

Nice, thank you! It’s no rush, especially not during the holiday season. Since I got the hacky version to work we already have a way forward for our current project anyway, so this is not urgent.

1 Like
16

@byteminer thanks for getting back and for confirming! So it’s firmware configuration needed too, apart from the custom device-tree. This means that a separate device-type is necessary for this particular carrier board because if you flash the custom configuration using the generic Devkit image, it will not persist across OS updates - the OS change also updates the QSPI memory with the generic Devkit configuration. Apart from this, what AGX Orin variant do you plan to use, the 32 or the 64GB RAM version? I will ask our customer representatives to get in touch with you for the next steps on getting this board supported. May take a bit due to holidays.

18

Ah, shame about the QSPI issue, but thanks for the heads-up. We’re planning on running the 64GB variant exclusively.

1 Like
19

Small follow-up on this:

So far, I’ve never received any communication in regards to getting this board supported. Not that big of a deal, but I figured I’d state the current status here at least. Situation is exactly the same as in December, and we do want to get this board properly supported if it’s not too expensive to do so.

Additionally, my initial excitement about getting the USB ports to work was a bit too premature, as it turned out that applying the diffed DTB files resulted in making only one of the two ports work: The other would only ever recognize USB devices as USB2, never USB3, despite this working just fine with the carrier-board-provided BSP. Just today, after literal months of struggle, I’ve finally managed to get both ports to work.

My solution consisted of:

  • Exporting a full DTS dump from a live system running the vendor-provided BSP
  • Exporting a full DTS dump from a live system running with the already-patched Balena version
  • Comparing the entire dump line-by-line and noting all differences
  • Hand-editing the Balena-dump to rewrite the xusb_padctl@3520000 section to match the one in the vendor-provided BSP, being careful not to touch the phandles (as presumably those should remain as-is)
  • Recompiling this hand-edited DTS to a DTB and overlaying it via Balena’s DTB overlay support for an initial test, during which I was able to confirm that indeed both USB ports started working as expected

It seems like somewhere in this whole process -which I have to admit I barely understand- the padctl mappings got messed up, leading to USB3 and USB2 pads/lanes switching places and requiring a manual fix.

Unfortunately the forum disallows uploads of ZIP files (strange choice for a tech-oriented forum, but okay), so I’ve changed the extension to .txt such that I may still provide my final diffed DTB setup for supporting the AVerMedia D315 carrier board on Balena with full USB functionality. Going through the normal jetson-flash process but copying these files into the /tmp/Linux_for_Tegra directory before the flashing begins should make everything work.

delta.zip.txt (3.2 MB)

balena.dtb.txt (427.1 KB)

I have a fork of jetson-flash available that helps with this right here.

The only remaining problem is the fact that so far I can only get this to work when applying balena.dtb via the Balena Dashboard and the DTB override (i.e. copying it to /mnt/sysroot/active/current/boot/ and setting the name via the dashboard). Copying the DTB file into the delta and applying it in one go for some reason does not work: The DTB is apparently never applied. If anybody knows how to fix this so I can flash things in one go, help would be much appreciated!

1 Like
21

Hi @byteminer , that’s correct, when you set the dtb override in the dashboard, that specified dtb located in /mnt/sysroot/active/current/boot/ is loaded. Looking at the commit in your jetson-flash fork it’s not clear what exactly is in the delta folder, but it doesn’t seem to inject the dtb in the OS image file, to replace the existing default device-tree in the filesystem prior to flashing. The file seems to be copied to the flashing directory, Linux_for_Tegra/ , and the kernel device-trees there are not packed into the OS image. Only the kernel dtbs that have been included during the OS image build are present.

If it’s only kernel device-tree changes that are necessary for making the board fully work, then you could PR the dtb in the balena-jetson-orin repository so we can ship it with new images.

Please keep in mind that now the OS images are on l4T 35.4.1, in the next couple weeks we plan to update and release OS images based on L4T 35.5.0 and after that we plan to update to L4T 36.3. It’s not totally clear if the final dtb that you have right now makes all peripherals and ports work, or if more changes are needed to have all ports working. Maybe you can confirm?

22

Ah that’s a good shout, I was operating under the impression that files copied there would all end up in the image eventually. Truth be told I still have no idea what I’m doing aside from semi-randomly copying kernel files around, so that probably accounts for most of this weirdness.

I actually uploaded my delta folder in my previous post, you can refer to that ZIP file to see what it currently includes that -somehow and magically- makes it kind of work.

What would be the correct way to inject all of my files (dts/dti/dtb for kernel and bootloader) into the final image? Mounting and rewriting the filesystem directly in the image I get from Balena, then flashing with the unmodified jetson-flash utility? I don’t really know where exactly in Balena these files need to go, so I might need some help with the proper file paths here, should this be the way to approach it. This would also likely make my additional, hand-tweaked dtb unnecessary, I expect.

Currently, the ports that I care about work, those being the 2 USB3 ports, 2 USB2 ports and the 2 Ethernet ports (1G and 10G), although the 10G port still seems to have some kind of issue that is beyond my ability to debug it. It kinda works but sometimes hard crashes the entire system, seemingly at random. I’m pretty sure the built-in HDMI port does not work, and I have never tried any of the audio ports. GPIO also generally works with the Jetson.GPIO Python library (as well as direct sysfs access), so that seems fine.

It’s like 90% there but the way to get here is ugly and paved with armed land mines, so any pointers that lead me around rather than straight into them are always welcome :slight_smile:

I must also add that -given our current method of ‘provisioning’ devices prevents them from ever being updated in the field in any way- we can never touch their OS again, which is a massive shame. I’d hoped to get this properly supported before we actually shipped these out, but since that wasn’t possible we now have these devices out in the field and we’ll deal with whatever madness comes from this down the line. I might eventually be able to get them back in to reflash them once I have a better solution, but until that solution manifests, I guess this is it.

Still, I’ll keep being active here until I actually manage to get this board properly supported, come hell or high water. I was lucky enough to get in contact with Rafael at Balena who might be putting me in contact with people that can help us with this problem, so fingers crossed on that front. Alas, it’s a slow-moving train so we’ll see when we can turn this around.

1 Like
23

Final update on this, so I don’t leave this thread unresolved: Unfortunately, we could not come to an agreement. Balena’s custom board support partners are extremely expensive, prohibitively so for anything but large companies. Supporting custom boards (even if the variations aren’t that big) is very difficult and virtually impossible without someone with specialized knowledge on retainer. While I managed to fumble my way to a semi-working solution, we never got 100% there, even after almost a year of engaging with this issue on a weekly basis.

As such, our solution was quite simple: We have fully moved away from Balena, dropping them as a vendor, and migrated to Portainer. It supports our use case better with an easier setup process, less complicated and more reliable build system, and as a bonus it can run anywhere Docker runs, without necessitating a full custom OS like Balena does. We’ve migrated all of our existing devices (which was very easy and took less than week, contrast this with almost a year of struggle with Balena) and things have been running in a stable manner ever since. Gone are all of the hardware issues we were struggling with before. There are some usability/DX things that Balena does better than Portainer (plus the smaller delta updates were nice), but for us they’re not worth the daily struggle any longer.
Unfortunately I could never get to a point where we could contribute carrier board support for this particular board, and at this point it will no longer happen. This is unfortunate, but at some point you gotta go with what works over what you would’ve liked to do.

Many thanks to @acostach and @mpous for helping me out during this time, your help was much appreciated :slight_smile:

24

Hi byteminer,

Thank you so much for sharing your experience and for staying with us during such a long time. We are really happy to hear that you found a solution that works better for you, and that things are going well now. For us, the most important thing is that your project succeeds!

We understand that working with certain boards and architectures can be very complex and, yes, sometimes a bit hard to manage. Supporting hardware does require specialized expertise, and we always try to make it easier through our tools and partnerships. That said, we already support 100+ device types and we keep adding more, though we know we can’t cover everything, specially when the design differs from the rest.

In regards to requiring balenaOS to benefit from container updates, this is an intentional decision on our part. We not only upgrade containers but ensure that systems run reliably on remote devices. This includes kernel and security patches at the OS level, secure remote connections, and other features that are essential for our product. We understand that each project has different needs, and sometimes our solution may not be the perfect fit for everyone.

We really appreciate your feedback about the areas where balena was helpful, like the smaller delta updates and usability features. Your comments help us learn and improve. If your needs change in the future, or if we can help with something else, please feel free to reach out.

1 Like