Please find attached the outputs in terms of images (the names of the images are in accordance with the test conditions , like with and without the uhs patch for sdmmc3 and ios and benchmark outputs).
We already run jetson_clocks by default at startup, and the cpu and gpu frequencies are already fixed to max.
This benchmark does not seem to have support for aarch64. Do you have specific link or version of iozone that I should install? I looked for one with aarch64 support and found an rpm file, which I am figuring out how to install. Am I proceeding in the wrong direction?
Besides, could you please let me know the purpose of this benchmark meanwhile? The thing is we are running out of time (deadline to fix this is coming Monday) and would need the most effective method to debug. Since the benchmark suite I am using (gnome-disks) is already indicative enough that the SD card access speeds are slow,and also our observation when we copy huge files to the SD card.
Thank you for the solution! We checked in the TX2 kernel and device tree source code (on which we did not have this slow SD card access issue) and found that the max-clk-limit was set to <208000000> for sdr104. Do you recommend this? If no, we shall just use the patch you provided, i.e., just delete the max-clk-limit.
Hi Karis,
I tested with the above solution and got clock speed as 204000000. Also, my dmesg -w output gives:
[ 1.649105] mmc1: Tuning correction cannot be applied
[ 1.649127] mmc1: hw tuning done ...
[ 1.649177] mmc1: new ultra high speed SDR104 SDXC card at address e624
[ 1.649475] mmcblk1: mmc1:e624 SN64G 59.5 GiB
Please find attached the complete dmesg output. dmesg-w.txt (49.5 KB)
I find a problem on our nano, if I use dmesg -w and unplug SDcard, it shows “Tuning done, restoring the best tap value :91” ,I would like to know, do you have the same problem.
Sorry didn’t get you earlier. Yes I have the same problem. I get the below logs with dmesg -w:
[ 146.018945] mmc1: card e624 removed
[ 146.019720] sdhci-tegra sdhci-tegra.2: Tuning done, restoring the best tap value : 23
[ 146.075067] sdhci-tegra sdhci-tegra.2: Tuning done, restoring the best tap value : 23
The “Tuning done, restoring the best tap value : 23” logs are repeated.
Also, are you using a production version or dev version?
We ran into some issues because of which I had to reopen this ticket, sorry. The thing is my dtb changes take into effect only after a hard reboot (power off + on). But when I do a soft reboot, the dtb changes related to SD card speed are not reflected and they show some older dtb values. For instance, when I do a soft reboot, and then check the ios, I get the following output:
cat /sys/kernel/debug/mmc1/ios
clock: 50000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
But I have changed the dtb already before flashing, so this should not be the case. Instead what I should get as an output is the following, which I also get with a hard reboot (power off+on).
cat /sys/kernel/debug/mmc1/ios
clock: 204000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)
It seems an old dtb is loaded from somewhere which I need to prevent. How do I do this? For the soft reboot case, I also observe that the SD card access speeds are actually slower 4 times (like 23 MBps vs 85 MBps on a hard reboot), when tested with the gnome-disks benchmarking utility that I mentioned before.
I moved the discussion to a new topic: Jetson Nano SD card enters back to high speed mode instead of uhs mode after soft reboot. The solution provided above does not solve the issue. Basically it is for a different issue - the person loses his dtb changes on a reboot, which is not the same in my case. In my case the SD card switches to a low(er) speed mode (details in the next forum) on soft reboot and it is a coincidence that the speed it switches to are the same as before my dtb changes, hence the confusion. I can always get back to the high speed mode (as intended by the dtb changes) by a hard reboot, and I have no clue why this behaviour is different in both the reboot cases.
Besides, the changes in patch provided in the link in the answer above is already present in the the L4T sources (32.2) I have.
Hi @WayneWWW ,
Sorry for bothering,
I am using jetsonNX devkit and facing same issue.
Can you help me clarify my confusion?
What is dtsi file? and where is it located?
Also, This is files located in /boot