Orin Nano Jetpack 6.0 UART1 issue

mhnrshd93 · July 15, 2024, 7:05am

Continuing the discussion from Orin Nano - Using UARTD or E or F:

Hi,

We require UART0 and UART1 to be used as general purpose UARTs.
We were able to use UART0 using the device node /dev/ttyTHS1.
But we weren’t able to connect with UART1.

Output of the command sudo dmesg | grep tty is given below:

sudo dmesg | grep tty
[sudo] password for mtx003:
[ 0.000000] Kernel command line: root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000
[ 0.000381] printk: console [tty0] enabled
[ 0.072504] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 117, base_baud = 0) is a SBSA
[ 0.184522] printk: console [ttyTCU0] enabled
[ 3.333123] printk: console [tty0]: printing thread started
[ 3.334720] printk: console [ttyTCU0]: printing thread started
[ 3.457601] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 3.458309] 3140000.serial: ttyTHS2 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
[ 8.999080] systemd[1]: Created slice Slice /system/serial-getty.

/dev/ttyTHS0 which maps to UART1 has not been enabled by the kernel device tree.

How to do this?

Jetpack details:

Package: nvidia-jetpack
Source: nvidia-jetpack (6.0)
Version: 6.0+b106
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.0+b106), nvidia-jetpack-dev (= 6.0+b106)
Homepage: Jetson - Embedded AI Computing Platform | NVIDIA Developer
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.0+b106_arm64.deb
Size: 29296
SHA256: 561d38f76683ff865e57b2af41e303be7e590926251890550d2652bdc51401f8
SHA1: ef3fca0c1b5c780b2bad1bafae6437753bd0a93f
MD5sum: 95de21b4fce939dee11c6df1f2db0fa5
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Package: nvidia-jetpack
Source: nvidia-jetpack (6.0)
Version: 6.0+b87
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.0+b87), nvidia-jetpack-dev (= 6.0+b87)
Homepage: Jetson - Embedded AI Computing Platform | NVIDIA Developer
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.0+b87_arm64.deb
Size: 29298
SHA256: 70be95162aad864ee0b0cd24ac8e4fa4f131aa97b32ffa2de551f1f8f56bc14e
SHA1: 36926a991855b9feeb12072694005c3e7e7b3836
MD5sum: 050cb1fd604a16200d26841f8a59a038
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Any help is welcome.
Thank you

KevinFFF · July 15, 2024, 7:59am

Hi mhnrshd93,

It seems you are using custom carrier board(from previous topic)
Please share the result of the following commands on your board.

$ cat /etc/nv_tegra_release
$ cat /etc/nv_boot_control.conf

Please refer to the following UART mapping in JP6.

UART0 => UART2(PX04, PX05, PX06, PX07): uartb@3110000 (NA) - Unused => To M.2 Key E
UART1 => UART1(PR02, PR03, PR04, PR05): uarta@3100000 (serial1) - /dev/ttyTHS1 => General UART
UART2 => UART3(PCC05, PCC06): NA - /dev/ttyTCU0 => Debug

May I know which UART interface do you mean? (i.e. which pins you are connecting with)

mhnrshd93 · July 15, 2024, 8:12am

Hi,

Yes we are using a custom carrier board.
But at the moment we are testing jetpack6.0 in devkit itself before migrating to our carrier board.

The command outputs are here:

cat /etc/nv_tegra_release

R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May 6 17:34:21 UTC 2024

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

cat /etc/nv_boot_control.conf
TNSPEC 3767-300-0005-K.2-1-1-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3767–0005–1–jetson-orin-nano-devkit-
TEGRA_BOOT_STORAGE nvme0n1
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0

Please refer to the following UART mapping in JP6.

UART0 => UART2(PX04, PX05, PX06, PX07): uartb@3110000 (NA) - Unused => To M.2 Key E
UART1 => UART1(PR02, PR03, PR04, PR05): uarta@3100000 (serial1) - /dev/ttyTHS1 => General UART
UART2 => UART3(PCC05, PCC06): NA - /dev/ttyTCU0 => Debug

As per the UART mapping you have given,

UART1 is working for us.

We require UART0 which is /dev/ttyTHS0 to be enabled.

Could please help with this.

Thank you

KevinFFF · July 16, 2024, 1:57am

Do you mean the following one?

UART0 => UART2(PX04, PX05, PX06, PX07): uartb@3110000 (NA) - Unused => To M.2 Key E

If so, please enable the node serial@3110000 in device tree.
Please also note that /dev/ttyTHS0 is not enabled by default.
You also have to modify the following line in device tree.

        aliases {
                ..
                rtc1 = "/bus@0/rtc@c2a0000";
                nvdla0 = "/bus@0/host1x@13e00000/nvdla0@15880000";
                nvdla1 = "/bus@0/host1x@13e00000/nvdla1@158c0000";
                tegra-camera-rtcpu = "/rtcpu@bc00000";
                serial1 = "/bus@0/serial@3100000";
                serial2 = "/bus@0/serial@3140000";
+               serial3 = "/bus@0/serial@3110000";
        };

and the /dev/ttyTHS3 should be available for UART0 (0x3110000)

mhnrshd93 · July 16, 2024, 10:57am

kernel_tegra234-p3768-0000+p3767-0005-nv.txt (238.4 KB)

Hi,

The modified dtb file is attached here.
It is not showing /dev/ttyTHS3.

These are the commands used:

1. Decompile dtb to dts
$ dtc -I dtb -O dts -o temp.dts kernel_tegra234-p3768-0000+p3767-0005-nv.dtb

2. Modify the contents I shared in previous response

3. Assemble dts back to dtb
$ dtc -I dts -O dtb -o kernel_tegra234-p3768-0000+p3767-0005-nv.dtb temp.dts

Also you say that /dev/ttyTHS0 is enabled by default.
But I dont have that.

I only have /dev/ttyTHS1 and /dev/ttyTHS2.
Screenshot is attached.

Could you check and recommend any changes.

Thank you

KevinFFF · July 16, 2024, 12:49pm

You can share the content of dts instead of the dtb binary here.

Could you also share the /boot/extlinux/extlinux.conf for further check?

It’s my typo.
/dev/ttyTHS0 is NOT enabled by default.

mhnrshd93 · July 17, 2024, 5:13am

kernel_tegra234-p3768-0000+p3767-0005-nv_dts.txt (310.1 KB)

The dts file is attached.

cat /boot/extlinux/extlinux.conf
Command output:
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config

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}

Also where should the dtb file be copied?

/boot/dtb/kernel_XXX.dtb

or

/boot/kernel_XXX.dtb

Thank you

KevinFFF · July 17, 2024, 7:28am

This one, but it seems not specified in your /boot/extlinux/extlinux.conf so that it will load the dtb from UEFI binary.

Please modify the following line in your extlinux.conf.

LABEL primary
      MENU LABEL primary kernel
+    FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv.dtb
      LINUX /boot/Image
      INITRD /boot/initrd

After applying the above change, please run the following command to check if it has been applied correctly.

$ cat /proc/device-tree/bus@0/serial@3110000/status

Or you can check dmesg for details.

mhnrshd93 · July 17, 2024, 7:57am

Hi, it didn’t work. something else happened. Please see the dmesg out.

cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv.dtb
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config

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}

cat /proc/device-tree/bus@0/serial@3110000/status
okay

sudo dmesg | grep tty
[ 0.000000] Kernel command line: root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000
[ 0.000390] printk: console [tty0] enabled
[ 0.072624] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 117, base_baud = 0) is a SBSA
[ 0.182263] printk: console [ttyTCU0] enabled
[ 3.327597] printk: console [tty0]: printing thread started
[ 3.328770] printk: console [ttyTCU0]: printing thread started
[ 3.464896] 3110000.serial: ttyS3 at MMIO 0x3110000 (irq = 198, base_baud = 4250000) is a Tegra
[ 3.465509] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 3.465938] 3140000.serial: ttyTHS2 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
[ 13.023033] systemd[1]: Created slice Slice /system/serial-getty.

You can see that ttyS3 just got mapped to 0x3110000.

Could you check please.

My doubt in dts file are these:
1.

serial@3110000 {
compatible = “nvidia,tegra234-uart\0nvidia,tegra20-uart”;

serial@3140000 {
compatible = “nvidia,tegra194-hsuart”;

serial@3100000 {
compatible = “nvidia,tegra194-hsuart”;

Are these values correct?

symbols {
…
uarta = /bus@0/serial@3100000;
uarte = /bus@0/serial@3140000;
…
}

There is no entry for serial@3110000.

Is that correct?

Thank you

KevinFFF · July 18, 2024, 2:45am

From your dmesg, it seems serial@3110000 has been enabled and you can use it through /dev/ttyS3.
If you want it to be ttyTHS3, you can modify the following line in device tree.

serial@3110000 {
-    compatible = "nvidia,tegra234-uart\0nvidia,tegra20-uart";
+    compatible = "nvidia,tegra194-hsuart";

You can also add the following line for serial@3110000

symbols {
…
  uarta = /bus@0/serial@3100000;
+ uartb = /bus@0/serial@3110000;
  uarte = /bus@0/serial@3140000;

mhnrshd93 · July 18, 2024, 5:23am

Hi,

It has issues:. ttyS3 doesn’t get enabled.

sudo dmesg | grep tty
[sudo] password for mtx003:
[ 0.000000] Kernel command line: root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000
[ 0.000379] printk: console [tty0] enabled
[ 0.072609] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 117, base_baud = 0) is a SBSA
[ 0.195431] printk: console [ttyTCU0] enabled
[ 3.395488] printk: console [tty0]: printing thread started
[ 3.396677] printk: console [ttyTCU0]: printing thread started
[ 3.488996] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 3.490211] 3140000.serial: ttyTHS2 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
[ 13.063678] systemd[1]: Created slice Slice /system/serial-getty.

 serial@3100000 {
 	compatible = "nvidia,tegra194-hsuart";
 	reg = <0x00 0x3100000 0x00 0x10000>;
 	interrupts = <0x00 0x70 0x04>;
 	clocks = <0x03 0x9b>;
 	resets = <0x03 0x64>;
 	status = "okay";
 	reset-names = "serial";
 	phandle = <0x1fc>;
 };

 serial@3140000 {
 	compatible = "nvidia,tegra194-hsuart";
 	reg = <0x00 0x3140000 0x00 0x10000>;
 	interrupts = <0x00 0x74 0x04>;
 	clocks = <0x03 0x9f>;
 	resets = <0x03 0x68>;
 	status = "okay";
 	reset-names = "serial";
 	phandle = <0x1fd>;
 };

 serial@3110000 {
 	compatible = "nvidia,tegra194-hsuart";
 	reg = <0x00 0x3110000 0x00 0x10000>;
 	interrupts = <0x00 0x71 0x04>;
 	clocks = <0x03 0x9c>;
 	resets = <0x03 0x65>;
 	status = "okay";
 };

Certain entries are missing in serial@3110000 like reset-names and phandle

dts file attached.

Please take a look.

Thank you
temp_dts.txt (310.1 KB)

KevinFFF · July 19, 2024, 1:29am

What do you mean about “doesn’t get enabled”?
Why it appears in your previous dmesg but missing now?

You can try to add reset-names back.
Or you can rebuild the kernel image/dtb instead of modifying it through decompile dtb.

mhnrshd93 · July 19, 2024, 5:35am

Hi,
I think you misunderstand.

If I do this,

serial@3110000 {
-    compatible = "nvidia,tegra234-uart\0nvidia,tegra20-uart";
+    compatible = "nvidia,tegra194-hsuart";

ttyS3 doesn’t get enabled.

You can verify this from the dts file I shared in my previous reply.

If the above changes are not done, ttyS3 will be there in dmesg output.
Even then, it is not working properly. I tried to send data. Rx-Tx was connected in loopback.
I’am receiving only garbage values.

For example, If I send ‘A’ or 0x41 or 65 what I get is 0x100
If I send ‘1’ or 0x31 or 49, I get 0xC0

I shall add reset-names and phandle manually in dts files.
What should be the value in phandle for serial@3110000?

Looking forward to your reply.
Thank you

KevinFFF · July 19, 2024, 8:04am

It is expected. In this way, does the /dev/ttyTHS3 show up?
If not, please share the full dmesg for further check.

Please short TXD/RXD and run the following command to verify loopback test.

$ sudo su
# stty -F /dev/ttyS3 115200 raw -echo
# cat /dev/ttyS3 &
# echo "test" > /dev/ttyS3

phandle is generated during building the dtb so that I suggested you modify it from kernel source and build kernel image/dtb manually.

mhnrshd93 · July 19, 2024, 9:05am

Hi,

Please short TXD/RXD and run the following command to verify loopback test.

$ sudo su
# stty -F /dev/ttyS3 115200 raw -echo
# cat /dev/ttyS3 &
# echo "test" > /dev/ttyS3

I tried this with ttyS3. Nothing is displayed by cat.
Tried the same with the working ttyTHS1. I got the results. Loopback is working.
So ttyS3 has an issue.

phandle is generated during building the dtb so that I suggested you modify it from kernel source and build kernel image/dtb manually.

This can be difficult for us at this point.
It is expected. In this way, does the /dev/ttyTHS3 show up?
No that’s what I mentioned in the previous reply. It doesnt. Not just even ttyS3 doesnt show up in dmesg reply.
I posted the dmesg output for your reference too.
sudo dmesg | grep tty
[sudo] password for mtx003:
[ 0.000000] Kernel command line: root=PARTUUID=4842dbf5-9a9b-45b9-9905-ef6688e1c949 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000
[ 0.000379] printk: console [tty0] enabled
[ 0.072609] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 117, base_baud = 0) is a SBSA
[ 0.195431] printk: console [ttyTCU0] enabled
[ 3.395488] printk: console [tty0]: printing thread started
[ 3.396677] printk: console [ttyTCU0]: printing thread started
[ 3.488996] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 3.490211] 3140000.serial: ttyTHS2 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
[ 13.063678] systemd[1]: Created slice Slice /system/serial-getty.

Could you check?

Thank you

KevinFFF · July 22, 2024, 9:34am

Could you get a scope and check the waveform?

I think it should be fine w/o phandle if no other nodes in device tree using it.

Please search for 3110000 in dmesg and check if there’s any spelling issue in device tree since I can’t find any message related to address 0x3110000 in your current log.

mhnrshd93 · July 22, 2024, 10:57am

Hi,
Checked the ouput of ttyS3, the signal simply toggles when there is activity.
There is no serial waveform. Its garbage.
If I send 0, then the signal remains low.

I have attached the entire dmesg output. I dont see any spelling mistakes.

Please check.

Thank you

dmesg.txt (53.9 KB)

KevinFFF · July 23, 2024, 5:14am

[    3.655085] 3110000.serial: ttyS3 at MMIO 0x3110000 (irq = 198, base_baud = 4250000) is a Tegra

From your dmesg, are you using 4250000 as baudrate for serial communication?

mhnrshd93 · July 23, 2024, 6:22am

Hi,
No I’m not using that baud rate.
Our usual baud is 115200. We use that while running our UART application.
I tried ```
stty -F /dev/ttyS3 115200 raw -echo

 Still ```
base_baud = 4250000

remains same in dmesg.

If you check the dmesg again,
[ 3.488996] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[ 3.490211] 3140000.serial: ttyTHS2 at MMIO 0x3140000 (irq = 113, base_baud = 0) is a TEGRA_UART
base_baud is 0

How these “base_baud” values are modified?

Thank you

KevinFFF · July 26, 2024, 10:54am

They are configured in driver.

Did you short them(TXD/RXD) from M.2 port?

[    3.699551] 3110000.serial: ttyTHS3 at MMIO 0x3110000 (irq = 198, base_baud = 0) is a TEGRA_UART

I could get above result in dmesg on Orin Nano devkit after configuring the device tree as following.

                serial@3110000 {
                        compatible = "nvidia,tegra194-hsuart";
                        reg = <0x00 0x3110000 0x00 0x10000>;
                        interrupts = <0x00 0x71 0x04>;
                        clocks = <0x03 0x9c>;
                        resets = <0x03 0x65>;
                        reset-names = "serial";
                        status = "okay";
                };

Topic		Replies	Views
Communicating with /dev/ttyTHS1 (UARTE) is causing a fault Jetson AGX Orin uart	30	159	April 22, 2025
JetPack 6.1 Change Debug UART3 to UART1 on Custom Carrier Jetson AGX Orin boot , hw , uart , jetson	9	72	March 7, 2025
How to enable UART7 (D8, D5) as normal UART like other UART (uartc@C280000) Jetson TX2	54	9814	October 18, 2021
Replacing Debug serial with normal UART Jetson Orin NX uart	28	3125	January 4, 2024
About UART talks to a drone Jetson TX2	36	4782	February 7, 2018
Can we change the debug port to a regular serial port? Jetson Orin NX uart , board-design	9	122	July 27, 2024
TX2 (p3310) UART configuration Jetson TX2 uart , board-design	25	1844	August 12, 2022
Jetson TX2 NX RS232 Communication Not working Jetson TX2 uart	21	4106	October 18, 2021
General UART on Jetson TX2-NX (pin #203 - TxD and pin #205 - RxD) Jetson TX2 uart	18	3317	April 6, 2022
[Orin Nano Jetpack 6.2 UART1 issue] Jetson Orin NX uart	11	91	March 10, 2025

Orin Nano Jetpack 6.0 UART1 issue

R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May 6 17:34:21 UTC 2024

KERNEL_VARIANT: oot

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}

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}

Related topics