We have a boxer like this one: https://www.aaeon.com/en/p/nvidia-xavier-nx-embedded-box-pc-boxer-8251ai
I am able to see microSD with a custom flash from boxer provider.
But when I flash Jetpack4.4 I don’t see the microSD card with lsblk
dmesg does not react on microSD insertion when jetpack4.4 is flashed.
What can I do with Jetpack4.4 to be able to read micro SD ?
I’ve never used one of these, but as a general concept, different carrier boards have different device trees. The default flash assumes the dev kit, and for any change to carrier board layout on the Boxer, there would need to be device tree changes. The manufacturer of the Boxer probably needs to provide this (the “board support package”, or BSP, contains a device tree).
Any custom BSP is probably just copied into the flash software for the dev kit, and after that flash would “do the right thing” for your carrier board, but the BSP must match the release version of the flash software. The makers of the Boxer would need to provide this information.
Thanks @linuxdev
Do you know which dtb file of Jetson NX is responsible for sdhci@34… devices?
Or what is the fastest way to navigate dtb files, except their decompilation to dts?
I’ve not looked at the details of any specific device tree for sdhci. What I usually do is reverse compile the device tree first:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
I also log a command line flash, for example:
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1 2>& | tee log_flash.txt
I find a symbol/address I am interested in from the extracted tree, and then go through the flash logs to see which original tree components were flashed, followed by looking to see if my symbol is in one of those. A very manual process, but you can reverse compile the named dtb files and simply grep for your symbol and/or address. Not exactly a fast way to do this, but it is thorough.
Other official docs will tend to describe modifications to kernel files related to device tree, and then say to compile the tree from the kernel source.
If you are just browsing, then it is very fast to use “find” in combination with “/proc/device-tree”.
I looked through /proc/device-tree and I’ve found a difference in symbols of a flash that can read microSD and the other one.
I found a dtb tegra194-p3668-all-p3509-0000.dtb that has this symbol, I tried to change
status = “disabled”;
to
status = “okay”;
But when I reflash, those changes weren’t applied.
I will try to go through the flashing log to verify if it should be another dtb with the same symbol.
This is the not-so-fun part…each release and Jetson version may have slightly different directions for this. Often it involves replacing a generic reference version somewhere in “Linux_for_Tegra/”, and then flashing normally, but check the docs for your specific case (device trees can end up in “/boot” files, or in a signed partition).
Thanks @linuxdev , that’s exactly what was the problem.
There were several copies of the same dtb file in different subdirectories of "Linux_for_Tegra/"
When I changed tegra194-p3668-all-p3509-0000.dtb in /kernel/dtb it worked.
Hi @dorozhko.a, I have the same problem, could you help me explain the detailed steps? Thank you so much.
I don’t know how to get tegra194-p3668-all-p3509-0000.dtb
If you’ve ever flashed, then you will have a directory “~/nvidia/nvidia_sdk/JetPack_...version info.../Linux_for_Tegra/”. In terms of flashing, everything will be in that directory or a subdirectory. For example, you should be able to find:
~/nvidia/nvidia_sdk/JetPack_...version info.../Linux_for_Tegra/kernel/dtb/
# Which has several dtb files. One is:
~/nvidia/nvidia_sdk/JetPack_...version info.../Linux_for_Tegra/kernel/dtb/tegra194-p3668-all-p3509-0000.dtb
Also, if you look in the docs for kernel build or kernel customization, then most device trees are also a build target there. If you were to configure the kernel source to match your running system, and then build the kernel target for “make dtbs”, this would result in a lot of “.dtb” files being generated. Presumably, " tegra194-p3668-all-p3509-0000.dtb" would be one of them.
Note that dtb files can be reverse compiled, examined, edited, and recompiled. A typical reverse compile would go something like this:
dtc -I dtb -O dts -o reversed_tegra194-p3668-all-p3509-0000.dts tegra194-p3668-all-p3509-0000.dtb
# You could then examine tegra194-p3668-all-p3509-0000.dts, edit, and rebuild:
dtc -I dts -O dtb -o reversed_tegra194-p3668-all-p3509-0000.dtb reversed_tegra194-p3668-all-p3509-0000.dts
(I preppended the name “reversed_” to generated files, but you can name them anything you want).
Hi @linuxdev, when I apt-get upgrade (nvidia-l4t-bootloader, nvidia-l4t-gstreamer, nvidia-l4t-tools), the dts has been changed.
I reboot the Jetson NX, the microSD is not detected again.
How can I keep the dts ?
I have heard of other people running into this as well. I think the technically correct way to do this is to make your device tree into an Ubuntu package, and have that package cause the offending overwrite package to be blocked. I am not sure of which package that is.
Alternatively, you could blacklist the package causing issues from updating. The problem there is the same: I am unsure which package that is. Someone probably knows and has some advice on how to blacklist that package.
as per my experience sometimes microsdcards were not detected until formated at host PC / windows pc