I found that the 2 Denver cores in TX2 are silent. I only saw them active once(MAX-P). Only 4 A57 cores are active in MAXN mode.
With only 4 cores work, the system is laggy.
What’s the benchmark or application running for your test?
Any tegrastate data as reference to draw your conclusion?
Which JetPack SW you used?
Thanks for your quick reply.
I don’t mean TX2 is not a good SoC(actually much better than my 2 other SoCs). I just wanted to say "without the 2 Denver cores activating, the performance of TX2 is probably as good as TX1 for general use.
I don’t think the 2 Denver cores will be activated without a heavy workload.
Benchmark scores are somewhat theoretical samples which are different from the real world performance.
Compare to my iPad air 2 and HP 8740w(12-year-old), the response of TX2 is a little bit laggy.
I think Nvidia had better set the performance on higher level and let users decide what level of power save modes they need.
The “extlinux.conf” seems to be ignored by L4T and “isolcpus=1-2” cannot be removed.
$ cat /proc/cmdline
console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 nv-auto-config video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= tegra_fbmem2=0x800000@0x96088000 lut_mem2=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/sda1 rw rootwait
The extlinux.conf in eMMC is as follows:
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel SSD
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/sda1 rw rootwait
LABEL eMMC
MENU LABEL eMMC kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait
#When testing a custom kernel, it is recommended that you create a backup of
#the original kernel and add a new entry to this file so that the device can
#fallback to the original kernel. To do this:
#1, Make a backup of the original kernel
sudo cp /boot/Image /boot/Image.backup
#2, Copy your custom kernel into /boot/Image
#3, Uncomment below menu setting lines for the original kernel
#4, Reboot
#LABEL backup
MENU LABEL backup kernel
LINUX /boot/Image.backup
INITRD /boot/initrd
APPEND ${cbootargs}
Hi,
Please check
Jetson/L4T/r32.4.x patches - eLinux.org
[TX2] Denver cores not working on TX2
In certain cases, performance may drop if tasks are scheduled to Denver cores. So we would suggest manually scedule tasks by executing taskset
Thank you.
I will read it later on. If the Denver cores could hinder the performance, TX2 and TX1 is a little difference.
I just didn’t know why the outcome of cmdline is so different from the extlinux.conf?
The extlinux.conf is changed to assign boot drive to sata SSD. Does the extlinux.conf in SSD need to be modified as well?(I already modified it.)
Hi,
It is not supported to switch rootfs to NVMe SSD in extlinux.conf. Please check this page to flash rootfs to the storage.
Thank you. I will study it later on.
Now I want to know how to enable the denver cores?
If it is not support, why the SSD became boot drive after modifying the extlinux.conf in eMMC?
The SSD in your case would just contain the root of running Linux filesystem.
What happens in your boot flow happens first in eMMC and the APP partition (where is flashed Linux in eMMC) will be aceessed and /boot folder will be read for extlinux.conf.
Then depending on extlinux.conf entry (a serial console would be needed for interactively trying), boot flow would also get from eMMC /boot Linux kernel Image, specified DTB (otherwise it would by default use flashed dtb into another eMMC partition) and initrd.
Then it would jump into Linux kernel image and boot Linux. If your kernel arguments specify another linux root device or partition, Linux might not know what is the rootfs it has been lauched from. But all of this is out of this Denver cores topic.
Thanks.
Did you mean L4T boot from eMMC and the file system mounted to SSD? Is the SSD become “working area” hereafter?
The Denver cores did work before but only on MAX-P but not on MAX-N.
No, because L4T is the Linux part at the end.
What happens before is described in Jetson boot flow doc.
L4T is just a Linux variation, it comes with a kernel image and user space binaries, once Linux kernel is loaded in RAM by previous stages and then it runs L4T.
May be MAXP would be required for your L4T release. You may have a look to /etc/nvpmodel.conf for further details.
EDIT; This is just my original way of thinking L4T, but re-thinking to what is now nvidia-l4t packages including nvdia-l4t-bootloader, my way of describing L4T to be a Linux thing may not be be correct.
Thanks. I just wanted to have more space for testing. Actually, it is not important if the system is booting from eMMC or external drive. My main concern is "does the SSD become working drive or current drive after booting up?
Again, this should not be for this topic, but in short there should be no reason for not having an eMMC hosted extlinux.conf running a kernel able to drive a SATA disk to have its Linux root from SATA. To be discussed into your other topic: Boot from sata drive is really that easy?
Yes. That’s what I want (Boot from sata drive is really that easy?).
I don’t think the Denver cores are totally silent. They are active in MAXP mode but the performance is the same as MAXN due to both CPU and GPU are forced to lower speed.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.