Oh ok. Then the next thing to do is figure out which kernel panic do you hit.
You can try to add console=none keep_bootcon to your kernel command line and it will print out the rest of log.
Below one is put under board config file.
+CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
Just want to make sure that we’re on the same page:
On the ubuntu running host I edit the file /home/nvidia/HWImage/JetPack_4.5.1_Linux_JETSON_TX2/Linux_for_Tegra/jetson-tx2.conf and add at the end of the file the above mentioned line:
CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
and then I should flash the image again, and verify the log provided by the flashed unit upon boot.
correct?
I am not sure about the exact procedure to be done here since clone is getting involved.
Actually, I don’t care how you make it. The final result should be you need to see “console=none” and “keep_bootcon” shows up in your kernel command line. dmsg will show that.
I guess the process should require two flash process
You flash both jetson TX2, first one on devkit while another one on your custom board. And you shall see both side have this console setting.
Clone the image from devkit case to your custom board with the command you used. Boot up the device and make sure the kernel command line still has these properties. And you shall see the full log.
I do not have a devkit in my possesion, thus I cannot apply exactly what you request.
Though I was thinking that the following line is currently depicted while the unit boots, after Starting kernel …:
[ 0.000000] Kernel command line: 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 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= tegra_fbmem2=0x140000@0x96081000 lut_mem2=0x2008@0x9607e000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1
and actually your request is that the console will be output to none and the flag keep_bootcon will be added.
I guess that I could do it by the following procedure:
I remember extlinux cannot set console status. Only flash can take effect.
@WayneWWW, hi,
it is great that Nvidia keeps track of all issues raised, per your reply TX2i can not boot on custom carrier board, but TX2 is ok. What's the difference between them? - #11 by WayneWWW
I shall modify the file
/home/nvidia/HWImage/JetPack_4.5.1_Linux_JETSON_TX2/Linux_for_Tegra/p2771-0000.conf.common:
modifying
ROOTFSSIZE=28GiB;
CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2”;
CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
target_board=“t186ref”;
Note: I do not know what isolcpus=1-2 does so I just add a new line and not replace the previous CMDLINE_ADD
Regards.
@WayneWWW, hi,
I have applied the changes to both:
BTW, I have a backup image on the flashed unit, that is when the unit boots I can select another image to boot from (a backup image stored on the /boot directory) in this case the unit boots OK. This means that all other partitions are good while the kernel image is defected for some reason. The original unit boots OK, so the process of reading the image from this unit is not working OK.
I keep on searching what should I change in order to add the keep_bootcon to the boot command line. Now I’m going to replace the lines as following:
ROOTFSSIZE=28GiB;
# CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2”;
CMDLINE_ADD=“fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”;
target_board=“t186ref”;
Not quite sure what you tried to say here.
on host p2771-0000.conf.common - no change in the boot command line
on unit to the /boot/extlinux/extlinux.conf file - no change in the boot command line
If you are trying to say the kernel command line are not showing up…
I think you should share how you flashed the board and the boot up log so that other people can find out why something can work/cannot work…
BTW, I have a backup image on the flashed unit, that is when the unit boots I can select another image to boot from (a backup image stored on the /boot directory) in this case the unit boots OK. This means that all other partitions are good while the kernel image is defected for some reason. The original unit boots OK, so the process of reading the image from this unit is not working OK.
If the kernel image might be the cause of your issue, why not you just copy /boot/Image from your cloned board and to your custom board to verify your assumption?
you’ve asked me to modify the boot command line, not stating how so I’m depicting the ways that I try to modify it:
append: 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 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= tegra_fbmem2=0x140000@0x96081000 lut_mem2=0x2008@0x9607e000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1
Retrieving file: /boot/tegra186-quill-p3310-1000-c03-00-base.dtb
cannot see there the console=none keep_bootcon
The flashing operation was not changed during the whole discussion it is detailed here TX2 not booting after successful flashing :
sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1
I shall copy the image from my cloned unit to the cusotm, and keep the discussion posted.
BTW, during my searches where I can modify the boot command line to take affect, I found that the following flag sdhci_tegra.en_boot_part_access is only depicted in the flash.sh file for the Nano type:
>elif [ "${target_rootdev}" = "cloning_root" ]; then
if [ "${tegraid}" = "0x21" ]; then
# Nano
CMDLINE_ADD="console=ttyS0,115200n8 sdhci_tegra.en_boot_part_access=1";
elif [ "${tegraid}" = "0x18" ]; then
# TX2
CMDLINE_ADD="console=ttyS0,115200n8";
elif [ "${tegraid}" = "0x19" ]; then
# Xavier
CMDLINE_ADD="console=ttyTCU0,115200n8";
else
echo "Unknown tegraid/board,exiting..";
exit 1
fi;
I’ve never used nano neither in the SDK nor on the unit, could you guess whats going on?
Regards.
Hi,
Just do the full flash first to see if it can take effect. Step 1 in my previous comment is full flash. Which means no -r -k APP in your command.
If you think flash.sh overwrites your setting again, then change that under 0x18 case for TX2.
So, should I read the image the same way (without -r -k APP):
read:
sudo ./flash.sh -G backup.img jetson-tx2 mmcblk0p1
sudo cp backup.img.raw bootloader/system.img
write:
sudo ./flash.sh jetson-tx2 mmcblk0p1
correct?
Regarding the settings:
I am not saying that flash.sh overwrites, all I say is, that the flag sdhci_tegra.en_boot_part_access is depicted in the flash script when programming a Nano type device.
The clone command is always same. Just do the full flash and make sure the kernel command line has the correct console setting we need for debug…
I am not saying that flash.sh overwrites, all I say is, that the flag sdhci_tegra.en_boot_part_access is depicted in the flash script when programming a Nano type device.
Not sure why you mentioned this. This is not related to your issue at all. What I am trying to ask you to do now is just one thing.
“Add that console setting and then reproduce the error again”. With such console setting, more log should get printed after “bootconsole [uart8250] disabled”.
I have activated the command to flash the unit with the image file on the host:
sudo ./flash.sh jetson-tx2 mmcblk0p1
and it started to overwrite the file bootloader/system.img. Makes sense?
Yes it makes sense. Let’s do the step 2 now.
Do you really understand what I am asking you to do now?
I though that the command without the -r -k APP will overwrite the whole image.raw to the unit, but I guess it reflashed from scratch the unit. So now the unit is in mode as it was after SDK programming, where I need to configure the user name, etc…
Let me recap what I am trying to ask you to do… looks like you toally don’t understand what you are doing now… I don’t care about what was flashed on that board before. What I am asking now is doing the clean setup with below.
If you claim there is an issue with image cloned, then below steps shall give us the error again. But this time you will have more logs to check because we have new console setting in kernel cmdline.
- You flash both jetson TX2, first one on devkit while another one on your custom board. And you shall see both side have this console setting. → Now you are doing this step. Please confirm if console setting is seen.
- Clone the image from devkit case to your custom board with the command you used. Boot up the device and make sure the kernel command line still has these properties. And you shall see the full log.
Is it clear now? I don’t want to tell this again so please ask right now if you still have any question.
No, we do not have the new console configuration, as you don’t tell me which configuration file to modify, and I’ve to modify the configuration files on the without any success.
Unless tyou advise where I should put the keep_bootcon configuration, the only thing that I can do is copy the image from my cloned unit to a new unit and check if the unit boots OK.
Ok, then I have to say the same comment again…
If you are trying to say the kernel command line are not showing up…
I think you should share how you flashed the board and the boot up log so that other people can find out why something can work/cannot work…
I think where you modified the configuration is fine. Actually, I am no jetson god so cannot 100% remember every config file would take effect since I have to take care about every SoC.
Please do share the log file so that we can check why it does not take effect.
I’m sorry but I don’t understand the phrase “how you flashed the board”
This is how I flashed
sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1
all logs are provided during discussion, for eaxmple this is the log on the host:
If this is not what you meant please elaborate.