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

@WayneWWW will it make sense to capture the encrypted output?

~�����k���
          R���	����h���������8�������� �@0m������������������P����� @�����<��������r���(��/���������:��~�����:�������0�������W�`�@��������+�����̳�������4����J� ���=���8x�d��a��������P��� ��������|�
                                                 ��������X���@����0��^f��������������0�����������&�����}���p�����������p7����@���������������� ��������������Ŀ8������� ��@������������G�������r����������(�����`�����������H�N�p�K����x���������|����@���>��`���������� ��u���\���������P��������p�������� �`�����0�����������������������������!�������>�"�	��$������ ������hF����������@���@����������8� ��������������
                                          `����b�������������������r���渿�������q��������[�x����u�� �����������d�{�J��������� ��@��@0� >���������X����������p����@|���������������`������������.������I���������d���B����
                                                                     ���������l��������������������7�\������������
                                        ����a������������������������������������0�����P�������4���ƿ���t�����������������@��������������������������p|� ����|���x������������@����X ���������f�����������h�p�����p��@���
                                                                    ��`�������@�.������� ������X�@z��������P������������������X�����`���s���j�����A�����@��b����`�@����������P���� ��� ��� �����`�����p������������}��������������z����,��Ⱥ����(� ����p���������v����0����<�������P�����p������������@����������l��|��>�����}���@���t��@��y�P�nʠ��������ӟ������������g��$ހ��k���(�����0�������������������������������|�
                                      ���������������������������2���^�%��������p��������@���������p����������� ������;����4��,����������ذP��x������@����|��������z���0����4������������H	���b��������������q��@����R������r@����������������c��������������N�������

Yes that looks like a framing error.

If you are using minicom on your collecting machine make sure the
speed - baud rate matches and also the parity and stop bits are the same for the two machines.

Also as this is TTL be very careful that the voltages are the same or at least tolerant.

So your mincom settings should be the same as what you set if you had TTL usb - serial cable.

Ross

its not encrypted its just wrongly framed, the number of bits in a byte must match, likewise stop bits and parity if needed. usually no parity is set, but you still need the parity bit.

Hope that makers sense.

Also it pays to use a tool like minicom or putty as
these open the serial connection and use the setting specified the whole
time the connection is open.

Otherwise the connection settings might get set to what ever the unopen state is.

Having a tool also gives a ready facility to save a buffer of what ever you capture.

Ross

which exactly command to execute to see correct output?
Hm, I noticed that even if I power OFF/ disconnect the power cable, but then touch the NX module the sequence of the input continues perhaps due to electromagnetic input/sink from touch
Thanks

first make sure you have minicom installed.
apt install minicom if it is not already there.

minicom
The following list of arguments can be used to alter minicom’s behavior from the command line:

-b
The serial port baud rate used by the external device–typically a SOM.
-D <device_name>
The device name for the serial port being used.
-h
Show a list of arguments that minicom accepts

So you need to know what serial port you are using on you collecting machine, Again if you are using TTL serial ports make sure voltages match.

If you just type in minicom
you get a window where you can set up all of your setting for that port and use it as your default connection.

you can check serial ports using

ll /sys/class/tty/

Down the bottom of the list will be the ones you are interested in .
Check with the tegra documentation to find which pins correspond to which ports you should use, so the physical connections.

once you have TX - RX for each machine and reverse you will be able to set everything from within minicom by selecting that port.
It just depends what ports you want to connect and having the wires or jumpers leads t hook up.

Ross

so the question seems narrowed down to which exactly terminal command to use instead of

 sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS0

that results in hyerogliphs:

                                          ����x�����t��������@�����������hw���r
      ���P��������������@@�����D������������`����
                                                 ��������������<��������r��������@I���������p��8����ా�^����X��[�������������e������������������`��>��������x��,�������������������@����`�����B�p�0�����������@����������N�\�������������v����`���������ж�����������`�������}���������������v.$���n����`�����������������������f���������������"�������m�����6$�@�������<�������������������e������������������@�J����������������������@�������������h����������t�������������������h�������������`�����������������������z!@������������!n����8���B�B@�����ذ�������������<�������������������@��v���������������������@��H�����t��y�P�����������������`�Ⰰ�����������������������������v�wF��*���-� �r����p���q������������3���������������������|�@��������w�� �<���������������������������~��������z����������������f�����������@ �ր���,�@��� �������p�������@��`����p~�

the wire connection is tx pin of NX devkit [8 of 40 pin header] to rx pin of AGX devkit [ 10 of 40 pin header]
gtkterm executed at AGX devkit

From what you displayed before it looks like a framing error or speed setting is wrong. choose the speed to match the NX device. Likewise the stop bits and parity. Just the same as if you were using a usb to serial TTL cable.

It could of course just be electrical noise, but it does not look like that.

what machine are you using as a data collector? I have forgotten?

Ross

I have never used gtkterm

but it would be something like:
gtkterm -p /dev/ttyTHS0 -s 115200 -a none -t 1

just make sure the defaults for parity and stop bits are correct by setting them. use the same settings that a usb to serial cable would use.

Also make sure you have permission to read and write the tty.
So if gtkterm is setguid dialout you should be a member of that group.

Ross

that specific command

gtkterm -p /dev/ttyTHS0 -s 115200 -a none -t 1

shows hyeroglyphs/ symbols
what is required is an exact command that will show corect output, unless it is noise, in which case more complex solution will be required to factor the noise out

gtkterm -p /dev/ttyTHS0 -s 115200 -a none -t 1 -b 8 

Just to force it to eight bit characters, speed 115200 baud, parity none, and stop bits one.

I would think that should work if everything is connected.

the permissions on the serial port need to be readable abd writeable.
crw–w---- 1 root tty 238, 1 Apr 26 06:27 /dev/ttyTHS1

in this case only root can read and write and group tty can write.

so unloess you are root you could do a chmod a+r

Ross

this specific command results in symbols/hyerogliphs

sudo gtkterm -p /dev/ttyTHS0 -s 115200 -a none -t 1 -b 8 
���@�����pR�����@���~����������p��V�q��d���@�r���*V���������v������@��4�� ��������������x���`�����z>���������
                                    �����������������@����v��2

Maybe other folks will add on which command will show correct outputs

the other thing to try here is to make sure that output looks the same each time the system starts issuing the boot loader output.

If it is then it is just a serial framing error.
One of the parameters speed, data size, parity or stop bits is wrong.

If it looks different every time you start then something is very wrong.

with the gtkterm running on the AGX, just power cycle the NX and watch that output, especially at startup.

Ross

The other thing is to make sure there is a common ground.
Often does not matter, but is more correct and may stop voltages from floating about and reduce “noise”.
So you should have a ground pin 9 to pin 9

All I can think of at the moment.

were the output the same each time you started the NX?

Ross

once ground is connected there is no any output
symbols seem mostly same regardless which state is nx [booting/ on/off with touch of hand to the module] but if it is just off there are no symbols

maybe try minicom.

apt install minicom

and then open minicom on the xavier with the corresponding parameters:

minicom -D /dev/ttyTHS1 -8 -b 115200

It is /dev/ttyTHS1 isn’t it? There are only /dev/ttyTHS1 /dev/THS4

I think you should be using /dev/ttyTHS1,

/dev/ttyTHS0 is the xavier debug port

Ross

according to the

[J14]: 12-pin button header. Brings out system power, reset, force recovery, UART
console, and other signals:
• Pin 1 connects to LED cathode to indicate System Sleep/Wake (Off when system
is in sleep mode).
• Pin 2 connects to LED anode.
• Pins 3 and 4 are respectively UART Receive and Send.
• Pins 5 and 6 disable auto power-on if connecte

according to Jerry Chang:
hello Andrey1984,

there’re 3 UARTs available on Xavier NX,
UART0 to M2
UART1 to 40PIN
UART2 to debug

So what you want is pin 4 (TX) on J14 NX to be connected to pin to RX pin of AGX devkit [ 10 of 40 pin header]

Then use /dev/ttyTHS1 on the xavier with mincom or gtkterm,
setting appropriate speed, stop bits and parity.

Ross

He’s replacing a UART in cable with the Xavier. The Xavier is just used as a UART TX/RX/GND, and can pretend the Xavier is just a host PC with the serial terminal reading the Xavier’s UART (no USB cable required, just twisted pair wire plus ground). Assumes the 40-pin header pins 8 and 10 of the NX are serial console.

Is there any way to just override the overriden bootloader in a way it will specifically boot from nvme again?

That’s something I couldn’t answer. Possibly through manipulation of boot environment variables since they can do macro expansion (at least on most releases…not sure if the newer UEFI has macro expansion).