Does JP4.6.1 sdcard oem setup boot break integrity of initrd installed nvme ssd OS?

There is no “initrd boot from nvme”. Only “initrd flash”. The boot process is same. Cboot on QSPI-NOR flash loads either the nvme or the sdcard.

We cannot guess anything here. To debug any kind of boot issue, need the bootloader log.

will bootloader log retrieved from NX booted from sdcard suffice for debug?
there should be a way to dump to a filesystem the log, so it can be retrieved from the disk rather than from uart?

No, this is not possible. Such question has been asked by other guys before. Not possible.

will bootloader log retrieved from NX booted from sdcard suffice for debug?

And sorry to say this question has no sense. UART log does not care about where you boot your device from…

If you can dump bootloader log with sdcard boot case, then you can dump it from nvme boot case too.

@WayneWWW
So what I can see in /boot/extlinux/extlinux.conf is

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

Seems I gotta add lines instead that will boot from nvme?

You can read the post with point 2 here. extlinux.conf only indicates where to load filesystem. Does not represent where to boot.

To tell what is the boot device, it needs to check the cboot log. And I already told you where to dump cboot log.

Isn’t it possible to override cboot order with
cbo.dts
as in Cboot console set-var command ?
In my opinion, what is required in my situation is to determine how to read from UART from AGX or nano

Yes, you can. But you won’t know whether your change is taking effect or not.

Also, cboot console is the UART console.

is there a simple test to confirm uart works?
that could be performed on AGX/NX or nano devkit?
so it will be showing some test output from uart pins
let say pin8 of AGX devkit gets conencted to pin 10
then it is required to generate some output on pin 8 then listen on pin 10 right?
which command will show pin10 outputs?
The problem seems that UARTon AGX, given pins8,10 are shortcut
kindf of non functioning
e.g I tried gtkterm -p /dev/ttyTHS 0 -s 115200
then tried echo symbol to /dev/ttyTHS0, but gtkterm shows nothing

@WayneWWW
Any idea why this simple test fails?
one terminal

 echo 1 > /dev/ttyTHS0

another terminal

cat /dev/ttyTHS0

the second terminal shows nothing during the first terminal execution;

Lets just narrow down the issue to proving that uart works at devkit at all?, then I can get from it the logs somehow, okay?
Or you want me to create a separate forum thread for not working uart?

Thanks
AV

Hi,
Generally we use USB-TTL cable to connect Jetson platform with a host PC to get uart log for further investigation. Woudl be great if you can get the cable and collect the log.

@DaneLLL
Thank you for your inputs.
Once I have a chance I will grab the cable.
However until then I have to figure out why UART won’t work.
Do you have a simple test to test UART shortcut on devkit? NX, AGX, nano? any of the three?
In the past I have had NX-AGX UART working for grabbing logs. It was loose connector/ not stable but still useable [ it would work 1 time of 7]. Moreover, right now I am trying to test trivial devkit shortcut UART within the same devkit which won’t work. Once UART pins [8-10] can be read within the trivial test, using one devkit then i will use UARt-UART cable to read logs from NX using AGX host.

I would suggest you can file a new topic for uart if you really want to find out answer. This whole thread of this topic should not be related to uart itself.

@WayneWWW
posted UART simple test
However, is there anything else to retrieve current cboot configuration from booted NX?
dmesg won’t have that data?

I think we can stop the discussion here. I already said, unless you provide the bootloader log from uart, this issue won’t be able to proceed.

If dmesg can work, then I wouldn’t ask you to dump bootloader log in the past few hours.

Just to clarify
sdcard oem setup one time execution
doesn’t rewrite cboot?
or execution of oem-setup like in my case with prior existing nvme ssd OS does rewrite cboot?
Is it known?
Thanks

If your sdcard image is a fresh one just downloaded, then it needs to compare the bootloader version.

For example, if you plug in the sdcard which is using jp4.6 version but the previous bootloader on the QSPI is jp4.6.1, then it won’t update the bootloader back to old version.

does sdcard [fresh one just downloaded] jp4.6.1 https://developer.download.nvidia.com/embedded/L4T/r32_Release_v7.1/JP_4.6.1_b110_SD_Card/Jetson_Xavier_NX/jetson-nx-jp461-sd-card-image.zip

upgrade previous bootloader in case of present already at another medium JP 4.6.1 ? from less recent than 3.7.1 release?
seems it does, as it will be more recent than the one presented in the system
gotcha
Thank you for letting me know

You should be able to implement a simple facility to collect the bootloader log with another machine using just serial connections.

To do this you will need to connect the TX from one machine to the RX of the other and likewise the RX from the first to the TX of the second.
This is commonly called a crossover connection.
You might also need to tie DCD or CTS to high as well.

In your uart example it is sort of the same thing.
You are writing to the write buffer and reading from the read buffer.
So unless the two are connected you will get nothing!
So you could connect TX to RX and get get feedback that way.
It still might need DCD or CTS to be high

Primitive debugging you should only really need RX, TX, GND to collect anything.

Of course your second machine also needs to set the right speed for via what ever tool you are using to connect with for example minicom.

this is essentially what your ttl usb to serial cable is doing as well.
You just have to make sure RX > TX and TX > RX.
Common mistake is having TX - TX and RX - RX, getting nothing that way!
Also if you have the speed and size of data wrongly set you will get wrongly framed data,
often show up as strange characters or again simply nothing.

Ross

so far I got this as UART output
upon execution of
cat /dev/ttyTHS0

������������������x�#~�@� ��0���L��� ����K�P���������j�:����$$���>��ٽ �}	����<��$�������6�H�d"�,?n����x�����X�j�n[�0�0��p�HV�����n�������
                                                                     �%w�w��~Cs2��<I������:�r&���������������������������������������������������������������������������������������@�������������Ѐ����P�Ғ�@�������������������������`������_~����x�&������d���B���X���������I�����������@���!����"��L���/����x��������v�� �����@������^P������"�f"D���������,���n������b�������F��������������������
    �L��8��6��j��������
��Z����`j���D�������/���������������H����`�����`�pFȀ�y���������6����U\��������@�������X:�X��`���f����������������P���������H��������������h���$�����h������C�����E�����������������������Pw����������dn���ވ�����������<���a����������������������3H������������e���߀��� ���p�������� �����x�����߰���������������d���X���/������(���������*�~�I�����h��,������^C

seems baudrate needs to be specified?
In another window running gtkterm -p /dev/ttyTHS0 -s 115200