Hi. We been having issues with trying to add CONFIG_STRICT_DEVMEM=n to tegra_defconfigwhen following the endpoint tutorial found in PCIe Endpoint Mode — Jetson Linux Developer Guide documentation. We were able to be flashed it successful when adding it into the tegra_defconfig, but after we finish doing the wizard configuration, the system is not able to reboot and enter the operating system (loading on the default linux background). We did try using previous version of the bsp to see if it works, but it results in the same thing. We also did try to follow the xavier series’s solution (Recompile the kernel without any changes to source files causes errors), but we end up reaching some unknown mnemoic entry and endproc error. Is there a step by step way for us to reboot it again successful. Our other device is using ubtuntu 20.04.
How about updating the kernel after you’ve done the wizard configuration?
Whenever we get to the wizard configuration, the system basically froze and force us to reboot and restart the process again. We did however managed to get the kernel configured by redoing the process from Recompile the kernel without any changes to source files causes errors with sudo, but we still have the problem when we insert CONFIG_STRICT_DEVMEM=n to the end of the tegra_defconfig file, where it is telling us that devmem mmap operation not permitted. We did notice that there were two tegra_defconfig file (tried changing the larger of the two), but it doesn’t make too much of a difference. Is it because after ./nvbuild.sh -o $PWD/kernel_out there should be more steps needed for the shared ram?
Editing the config file directly is risky. I only do this with CONFIG_LOCALVERSION because I know it has no dependencies. For something as invasive as CONFIG_STRICT_DEVMEM, you really need to use a configuration editor (e.g., “make menuconfig”, or my favorite since it has symbol search, “make nconfig”).
Incidentally, with something that invasive, you really need to build an entirely new kernel and all modules. The “uname -r” result has to change too so that the old module directory is not used (meaning to set CONFIG_LOCALVERSION to something other than “-tegra”, e.g., “-nodevmem” is descriptive). I advise always leaving the original kernel and adding a new boot entry, and renaming the kernel something named after the CONFIG_LOCALVERSION. For example, “Image-nodevmem”.
Btw, what is your current “uname -r”?
Hi @stevenyang1548 ,
You need to run your application as a root user to resolve the “devmem mmap operation not permitted” issue.
(using sudo wont work, you need to login as a root using the su command).
It’s interesting that normal “sudo” inherits part of the regular user’s environment. So if actual login to root works differently than sudo, it implies the environment variables have a big part in the issue. One might compare the output of:
sudo -s
printenv
exit
su -
printenv
exit
sudo su
printenv
exit
hello help
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.