ARMv8 Processor rev (v81) x 2 and I have 2 others that are ARMv8 Processor rev (v81) x 4. What is the difference? Icons on the left are different too. Same model number.
Don’t get what you mean. Please share the pictures.
this is the second one
I’m thinking that is just the number of active cores. Do keep in mind that Jetsons have the ability to switch power models, and that this can temporarily disable some cores to reduce power consumption (which can be controlled with the nvpmodel program).
The TX1 is also quite old, and the default was that the Denver cores are reserved for tasks manually scheduled on those cores. You can see what the Linux command line to the kernel was:
cat /proc/cmdline
If you see “isolcpus=1-2”, then that is how the Denver cores were “sort of” removed…those cores are still available, but the scheduler won’t put any tasks there, and thus it looks like you have two fewer cores (it is the scheduler which lists the CPUs). You could put specific programs on those cores, or you could turn them into general use by removing the “isolcpus=1-2”.
Hello,
Thank you. ironic that I was buying ‘a New unit’. never opened. It must have been sitting around since 2021, January 2. I also see that usbcore.old_scheme_first=1 must be why I keep losing my usb speaker. Again, power reduction. I had attached a battery back-up system that now no longer works. Nonetheless, I had a great time using my between-semester break working on these. I wonder how long before the other two drop their processors as well. How does this all explain the different icons on the left?
tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 gpt tegra_fbmem=0x140000@0x92ca9000 is_hdmi_initialised=1 earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
This is what came back. hard to understand but isoclpus=1-2 regards, BH
Hello, I switched the SD card from one Nano (TX1) to the other so now it is x 2. the icons are now the same on the new machine too. I will re-install the Nano Developemnt Kit and save the large SD card as a back-up device. Thanks again, BH
Hello, I installed a new SD card! x 4 and the same icons the other nanos have are now on this one. Back to the beginning. I really like these machines. Thank you.
In this case, it was a mistake on my part when configuring the system. A bad keyboard (since returned) popped down to the second option that uses only 2 processors. That is why it came up that way. That setting was following the SD card to each machine. So, it was apparently not a hardware issue.
First, is this a developer kit? If so, then the SD card slot is on the module itself, and not on the carrier board. When purchasing a third party module and carrier board any SD card slot would be on the carrier board, not the module. The third party modules would have eMMC memory, and quite possibly no SD card slot (but if there is an SD card it would be on the carrier board). I am going to be assuming dev kit, not an eMMC model.
Have you not flashed this Jetson? I don’t mean flashing an SD card, but the Jetson itself (this is where the boot software and board startup code is…there is QSPI memory on the Nano module itself if it is a dev kit). That content is the equivalent of a BIOS (Jetsons don’t have a BIOS, but they need the same function), plus bootloader in the QSPI.
USB low power “sleep” is usually the cause of losing some USB devices. We’d want to start a different topic for that, but disabling USB sleep would be a good test to fix this.
So far as two CPU cores not showing up, this is not a failure. This is the CPU cores being told to not show up except for software which specifically requests those cores. It is easy to change those two cores to always showing up. Do you see this file?
/boot/extlinux/extlinux.conf
That file is plain text and can be edited. Be careful to not edit the wrong thing, but if you go into that file and search for “APPEND”. The “APPEND” is a key/value pair (APPEND is the key, a space-delimited list is the value), and this is passed to the kernel as a command line during boot. Most parameters of that list of space-delimited command line options assume the last value is the correct value (which means someone could accidentally put an option in several times and only the last one would be active). You could put a space and the command to neutralize isolcpus at the end. For example, if the end of that line has this:
rootfstype=ext4
…then you could add a space and this to say “no” isolcpus:
rootfstype=ext4 isolcpus=
By removing the “1-2” you remove isolating CPU cores 1 and 2. Then reboot. Be careful though that the APPEND line remains a single long line and is not broken up with a new line. After reboot htop or other applications which show CPU cores would show the two which were previously reserved. In no case would other cores simply go away or stop working, the Jetson was never broken. The cores were not actually ever lost, they were told to they would be used only for processes specifically asking for them. Nothing ever asked for them. For “cat /proc/cmdline” you should see that the “isolcpus=” is to the right of “isolcpus=1-2”, which implies that the one on the right takes precedence (and the one on the right does not name any CPU cores to reserve).
To disable the USB autosuspend, at least long enough to test it, you could add this to the end of the same extlinux.conf file APPEND key/value pair line:
usbcore.autosuspend=-1
(that is a space plus the option without spaces; the space means it is looking at the next parameter, the rest is a specification which the drivers understand and won’t have spaces within that; the entire line must be one continuous string without any newline)
Try to test these one at a time. If you get sound issues again, you would be better off starting a new forum thread for just that topic.
I want to emphasize that the SD card is often not enough for boot to match between two Nanos. Whenever you get a Nano you should flash the QSPI, and this requires a Linux (preferably, in this case Ubuntu 18.04) host PC. The code on QSPI will work for several releases of SD card, but not for all. Furthermore, there may be bug fixes in newer QSPI content. Think of QSPI as a combination of both BIOS and bootloader.
Side note: It is easy to clone SD cards, and I recommend that whenever you get one to the state you like, that you clone it somewhere else for backup.
The icons on the left are part of Ubuntu. They don’t care that this is Jetson hardware. What shows up there depends on which version of Ubuntu you use, and what has been customized. It is all end user content.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.