Thank you for confirming it works on your side now too.
It happened on this custom build solely due to timing and how the changes were automatically pulled from upstream by the BSP layer, which is not maintained by us. It’s all explained in detail in my latest commit message for the jn30b branch.
Yes, the default nano dtb is built along with the kernel and is ignored, and the custom one is actually signed and then written to the corresponding partitions.
These warnings that you see appear due to meta-balena layer being standard and used with various BSPs. Some BSPs, like the tegra one for instance, have minor variations in certain repositories. We are actively working and adapting changes so the warnings get solved for each of the boards.
The immediate next step is for us is to peer-review the jn30b branch, the one in which I gathered and re-formatted the patches you submitted, and then have it merged.
I’ve pinged Alexandru to confirm, but usually after the merge of a PR on one of our meta layers, the device needs to go through formal testing to ensure that everything works correctly. This usually takes between two to three weeks, after which the new version is released to balenaCloud.
If this isn’t the case this time, we’ll let you know!
Apologies, my previous response was incorrect. Because this is a community board, we won’t be undergoing the usual testing routine but this will be released alongside the next jetson-nano update. As this is merged, we’ll let you know when this occurs!
Hi, all releases for the board you added support for will happen whenever we have a new release for the jetson nano, and all changes and improvements done for the nano will reflect for this board as well. You are also welcome to contribute with any other improvements for this or other boards in a similar manner as explained here. Feel free to get back to us if you have any other questions.
Thanks for your answer. We would like to contribute within the reach of our knowledge and capabilities. Actually we have some other interesting ideas which are worthwhile discussing. But first step would be to get the production module supported.
We started to test the BalenaOS image by pushing our application locally. So far so good but I will let you know as soon as we encounter some issues.
I do have a question related to the image. In current merge, only the .dtb file is replaced in order to support the board. However, Auvidea also supplies kernel_headers and kernel_supplements with their firmware. Is this something we need to incorporate in BalenaOS?
We generate and publish kernel headers when balenaOS release is published.
You can check this project for an example of how to use the headers to build a new module for your app container:
If you are referring to some pre-built modules supplied by Auvidea, I don’t think they would work because, to my knowledge, they need to be rebuilt against balenaOS kernel headers.
As Roman mentioned, I’m also not sure I understand the reason for using those, do you have a specific use-case in mind?
If there’s something in the kernel that needs to be custom for this board, it can be submitted by means of a PR that adds patches for the specific device.
We are relying on the meta-tegra yocto layer because it allows for bringing in BSP improvements and fixes faster and directly from upstream, while keeping custom board changes and configurations separate and thus easier to maintain.
Thanks for the explanation. I was just making use of the opportunity to ask these questions without any specific use-case in mind. I don’t think the current board is dependent on any OOT kernel modules so the current image should be fine. However, there could be a need for more exotic boards in the future so it’s good to know how to handle this with Balena. At least I wasn’t aware of the procedure.
We will start continue application testing tomorrow, will keep you updated if problems arise.
Thank you for contributing the JN30B Nano device, it is now available for download both in the staging and production dashboard at BalenaOS version 2.45.0+rev2.