Thank you for your inputs.
I shall try again.
In my understanding the kernel build succeeded,
and the modules build did complete without errors.
How to explain absence of the dht11 .ko file output of the latter step? I would expect that when modules install process take place that data is read from the new build kernel and that would reflect the change to tegra_defconfig, in my opinion.
Shall I go ahead and flash the resulting kernel and modules to see if the the result the missed dht11.ko file will be generated? It is highly unlikely, as it would have generated rather at the step of building modules with modules install, probably.
However, I shall try and will post back.
Attempt 3
/Desktop/kernel/kernel-4.9$ make mrproper
sudo make modules_prepare ARCH=arm64 O=$TEGRA_KERNEL_OUT
What I can see is that the added parameter is kind of reflected here:
/home/nvidia/kernel_output/drivers/iio/humidity/.dht11.o.cmd
/home/nvidia/kernel_output/drivers/iio/humidity/dht11.o
/home/nvidia/kernel_output/include/config/dht11.h
I am just wondering in what step a .ko file will be build of it.
Thanks
P.S.
./source_sync.sh -k tegra-l4t-r32.2
Couldn't find tag tegra-l4t-r32.2
from where does the command below need to be executed?
git tag -l tegra-l4t*
fatal: not a git repository (or any of the parent directories): .git
Reference: https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fkernel_custom.html%23
Attempt 4
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8 modules_prepare
Attempt 5
Scheduled
zcat /proc/config.gz > .config
make menuconfig
make -j8 modules_prepare ARCH=arm64 O=$TEGRA_KERNEL_OUT
make -j8 modules
make -j8 modules_install ARCH=arm64 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$KERNEL_MODULES_OUT
should there or should there not be dht11.ko file after the actions above are taken?
“CONFIG_DHT11=y” indicates the driver would be built in the kernel image.
If you use “CONFIG_DHT11=m”, then it would be built as a module (.ko).
thank you for the explanation!
and then, when it is loaded either as .ko or as got incorporated into the kernel and flashed?
any insights on how to address request to it? how to read from it?
It seems that I managed to flash the kernel that has had the line
CONFIG_DHT11=y, and now when I cat the "/proc/config.gz " after unzipping it will show within it the line:
CONFIG_DHT11=y
How do I check if it is kind of loaded and operational?
If built with “=y”, then the code is always available and cannot be unloaded. No module listing or module query will have any knowledge of integrated code. All module related commands would become irrelevant. The Image would have to be installed.
If built with “=m”, then all that is needed is to copy the module to the right location in “/lib/modules/$(uname -r)/”. In this case module commands and listings would work.
Sometimes a dependency, even if it can be a module, might trigger a second dependency automatically. In some rare case this might be an “=y” dependency. Then both Image and module would need install.
If “/proc/config.gz” shows “CONFIG_DHT11=y”, then this is an absolute guarantee your kernel has that driver or feature. The kernel itself is telling you this is directly integrated. No loading or unloading is possible for this case because it isn’t a loadable module. The only question is whether some software has tried to use it; if there is a failure, then it might be that the software requesting the driver passed an invalid argument, or the hardware itself is not set up (device trees and firmware come to mind for this).
Thank you for your help!
The next challenge will be to understand how to read from it.
It is said originally at file
:
"gpios: Should specify the GPIO connected to the sensor's data
line, see "gpios property" in
Documentation/devicetree/bindings/gpio/gpio.txt.
Example:
humidity_sensor {
compatible = "dht11";
gpios = <&gpio0 6 0>;
}"
and they seem to refered to the
gpio.txt
The question is to where to put the expression:
"
humidity_sensor {
compatible = "dht11";
gpios = <&gpio0 6 0>;
}"
"
and when? Does it go to the sources file from that the kernel image is built before building the kernel?
like to e.g. /kernel/nvidia/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt ?
Do I put the line as :
humidity_sensor {
compatible = "dht11";
gpios = <&gpio424 6 0>;
}
if it is connected with the data pin to the gpio424 pin of the GPIO? And then rebuild the kernel and flash it?
I usually save a log of a command line flash, and then I see a list of all dtb files used. The one related to kernel device tree would be the one to use. Sometimes different board revisions might name boards slightly different, but if you have a log from flash, then it always tells you which trees were flashed. I don’t know off the top of my head which one it would be.
gpio-intmap.port.BB.pin.0 = 2; # GPIO BB0 to INT2
gpio-intmap.port.BB.pin.1 = 2; # GPIO BB1 to INT2
the above is from the instruction and the below is from the file:L
cat /home/nvidia/nvidia/nvidia_sdk/JetPack_4.2.1_Linux_GA_P2888/Linux_for_Tegra/bootloader/tegra194-mb1-bct-gpioint-p2888-0000-p2822-0000.cfg | grep BB
gpio-intmap.port.BB.pin.0 = 2; # GPIO BB0 to INT4
gpio-intmap.port.BB.pin.1 = 2; # GPIO BB1 to INT4
gpio-intmap.port.BB.pin.2 = 4; # GPIO BB2 to INT4
gpio-intmap.port.BB.pin.3 = 4; # GPIO BB3 to INT4
as 2!=4, where is the typo? in the config or in the instruction?
and could you extend the latter step, please?
Compile device tree and flash the entire board to ensure that the SCR, gpio interrupt mapping and pinmux settings are flashed on the board.
[s]Try instead:
./source_sync.sh -k tegra-l4t-r32.2
JetPack is 4.2.1, L4T is R32.2.[/s]
Nevermind, R32.2 isn’t there either. It is:
./source_sync.sh -k tegra-l4t-r32<b>.2.0</b>