Hey,
I noticed that my custom os was showing just 6.9GB available memory. That made me wonder if it should not be 7.9?
Checked on release R32: Free shows 7959912 total memory
Checked on release R35: Free shows 7019444 total memory
I tested this with the 5.0.2 SD Card image, so no modifications have been made in that case.
Where is my 1GB memory? And how do I get it back?
Could you dump the device tree to check the reserved-memory {} if any different.
sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
Hey @ShaneCCC ,
Find the output you requested here:
extracted_proc.dts (386.1 KB)
Looks like r35.x reserved additional memory for camdbg_carveout and ramoops_carveout
Okay and that means? Is that intended?
I’d like to use the 8GB of the module as we need them.
If you don’t use CSI camera you can try remove the camdbg_carveout
Hey Shane,
we plan to use a CSI camera, but not one of the drivers NVIDIA supplied, but one for which an external supplier has created a driver. Would it be possible to remove it then too?
How much memory is reserved for each the camdb and the ramoops? Device Tree is not my speciality, forgive me the question if I can’t read it from the dts.
Why is it that the previous system allowed the user to use the 8GB and now we get the same functionality with 1GB less?
The camdbg_carveout reserved about 1G rameoop much smaller to ignore.
Could you try to remove it to check if any problem.
Thanks
camdbg_carveout {
alignment = <0x00 0x100000>;
alloc-ranges = <0x01 0x00 0x01 0x00>;
compatible = "nvidia,camdbg_carveout";
size = <0x00 0x6400000>;
status = "disabled";
phandle = <0x3e1>;
};
``Sorry, it’s my mistake.
Looks like camdbg_carveout doesn’t enable due the status = “disable”
Will check it again.
Thanks
okay, then I’ll wait for your results.
If you need any more info you can let me know.
Do you have any information by now?
Any other moderator here can give an update on this?
Is the issue in the L4T or do I have to search on my side?
I am on the same boat. Spent the last hour looking for the answer. Jim from Jetson Hacks pointed me to your post.
Any news?
Hey @jackshbc5e , I am glad that you can confirm the issue. So the missing 1GB seems to be the “standard” bugged behavior.
Probably @ShaneCCC or if he is unavailable at the moment @WayneWWW will respond after they have identified the issue.
Confirming the same problem with two installs In two different NXes using SSD
From 5.10 kernel, to align with upstream, VPR memory carveout is static reserved. In 4.9 kernel it was resizable and seen as part of CMA memory.
CMA memory is considered as reclaimable memory which is accounted in available memory as well. So, more available memory should be seen on rel-32.
Dmesg from 5.10, cma is 64MB and VPR is not part of kernel memory.
[ 0.000000] Memory: 6944136K/7473856K available (18496K kernel code, 3174K rwdata, 7176K rodata, 4032K init, 1094K bss, 464184K reserved, 65536K cma-reserved)
while in rel-32 K4.9 , VPR is resizable and part of kernel memory.
[ 0.000000] Memory: 7192656K/8134656K available (15294K kernel code, 2968K rwdata, 6716K rodata, 8640K init, 616K bss, 188336K reserved, 753664K cma-reserved)
If the customer has no requirement for secure playback then he can completely disable VPR through device tree. Otherwise, static VPR has to be present.
Hey @Bibek
thanks for your answer. In the Kernel the VPR is disabled and apparently in the device tree too:
\source\public\hardware\nvidia\soc\t19x\kernel-dts\tegra194-soc\tegra194-soc-memory.dtsi
which is included by tegra194-p3668-common.dtsi → tegra194-soc/tegra194-soc-cvm.dtsi → tegra194-soc/tegra194-soc-base.dtsi → tegra194-soc-memory.dtsi
vpr: vpr-carveout {
compatible = "nvidia,vpr-carveout";
status = "disabled";
};
tegra-carveouts {
compatible = "nvidia,carveouts-t19x";
memory-region = <&generic_reserved &vpr>;
status = "disabled";
};
# CONFIG_TEGRA_VPR is not set
That seems to be the default of the L4T sources. Can you please guide me how to really disable it?
Hi,
In the BCT file present in BSP misc/tegra194-memcfg-sw-override-l4t.cfg,
make this variable as ZERO
McVideoProtectSizeMb = 0x00000000;
Hey @Bibek
I changed the file and recompiled the kernel (Wondering how it should change anything, the file is not even in the kernel source folder) , the device tree is unchanged and the 1GB is still missing…
Any idea what could be wrong?
the file is present in bootloader/t186ref/BCT and has nothing to do with kernel. this is a bootloader file and from here you need to disable vpr so that bootloader does not enable vrp in kernel during boot.
Just change the file and reflash the board