updated for march 19

9b012733 · dylan.frei · 8daa1cea · 9b012733
Commit 9b012733 authored 1 year ago by dylan.frei
--- a/journal.md
+++ b/journal.md
@@ -375,4 +375,117 @@ The flashing configuration mainly refers to selecting our custom BTC and DTB fil
 ## Note about rootfs modification
 I previously assumed that the system was specified to work only with ubuntu 20.04 and the images provided by Nvidia. However, while researching the necessary modifications for our custom carrier board, I stumbled upon the information that any linux rootfs should work. Nvidia speficies that some rootfs configurations and customizations that are provided in the Linux_for_Tegra/nv_tegra/ directory should be incorporated into the rootfs as well as some of the files that might be required for lower level components (e.g. extlinux.conf).
\ No newline at end of file
+# Week 10-11 : 19.03.2024
+## Objectives 
+Mutiple questions were asked during the last session and the current goal will be answering them.
+Kernel/Extlinux related :
+- Is there a posibility to flash multiple kernels ?
+- Can we change the kernel arguments ?
+- Is it possible to do so without reflashing ?
+- Can pass arguments to the kernel at boot time ?
+Rootfs related :
+- What does the default base skeleton provided by Nvidia contain ?
+- What are the steps in rootfs generation using the default tool ?
+- Can we upgrade from ubuntu 20.04 to ubuntu 22.04 ?
+- Does the filesystem work with systemd ? 
+For this addition to the journal, these questions will mainly be answered theorically. Further on board testing needs to be done.
+## Using the Nvidia provided image to investigate
+At first, I will be using the blob provided by nvidia that is already ready for SD flashing and mount it on my host to investigate its filesystem. This will allow for in depth research and answer most of our questions easily. 
+To understand the right partition to mount, I first inspect the .img file :
+```
+sudo fdisk -l sd-blob.img 
+Disk sd-blob.img: 27.22 GiB, 29228007424 bytes, 57085952 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+Disklabel type: gpt
+Disk identifier: D286F765-5ECA-43C3-AF2E-11825261E3A8
+Device          Start      End  Sectors   Size Type
+sd-blob.img1  3057664 57065471 54007808  25.8G Linux filesystem
+sd-blob.img2     2048   264191   262144   128M Linux filesystem
+sd-blob.img3   264192   265727     1536   768K Linux filesystem
+sd-blob.img4   266240   331007    64768  31.6M Linux filesystem
+sd-blob.img5   331776   593919   262144   128M Linux filesystem
+sd-blob.img6   593920   595455     1536   768K Linux filesystem
+sd-blob.img7   595968   660735    64768  31.6M Linux filesystem
+sd-blob.img8   661504   825343   163840    80M Linux filesystem
+sd-blob.img9   825344   826367     1024   512K Linux filesystem
+sd-blob.img10  827392   958463   131072    64M EFI System
+sd-blob.img11  958464  1122303   163840    80M Linux filesystem
+sd-blob.img12 1122304  1123327     1024   512K Linux filesystem
+sd-blob.img13 1124352  1255423   131072    64M Linux filesystem
+sd-blob.img14 1255424  2074623   819200   400M Linux filesystem
+sd-blob.img15 2074624  3056639   982016 479.5M Linux filesystem
+Partition table entries are not in disk order.
+```
+The system is clearly located on sd-blob.img1. I mount it to a temporary location to investigate the files :
+```
+sudo mount -o loop,offset=$((512*3057664)) /path/to/your/sd-blob.img /mnt/rootfs
+```
+Mounting the image also presents us with a great option to modify the default filesystem before flashing it to multiple targets as it is a way to permanently change the files.
+The update from Ubuntu 20.04 to 22.04 and further is feasable as the default tools provided by Canonical are present and able to be used. However, it is worth noting that ever since my first download, the provided blob already contains Ubuntu 22.04 as the default system. 
+Concerning systemd, the software is indeed present in the rootfs.
+## investigating extlinux
+Extlinux is a syslinux derivative, which boots from a Linux ext2/ext3 filesystem. It works the same way as Syslinux, with a few slight modifications. It is intended to simplify first-time installation of Linux, and for creation of rescue and other special-purpose boot disks. Comparing to other common bootloaders, the complexity and functionalities is inferior to that of grub and even Uboot, which is a good asset in the case of an embedded target. 
+The answer to most of our questions lie in the /boot/extlinux/extlinux.conf file :
+```
+cat /mnt/rootfs/boot/extlinux/extlinux.conf
+TIMEOUT 30
+DEFAULT primary
+MENU TITLE L4T boot options
+LABEL primary
+      MENU LABEL primary kernel
+      LINUX /boot/Image
+      FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv.dtb
+      INITRD /boot/initrd
+      APPEND ${cbootargs} root=/dev/mmcblk0p1 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 
+# 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
+#    FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv.dtb
+#    INITRD /boot/initrd
+#    APPEND ${cbootargs}
+```
+The provided file is fairly easy to understand and even explains how to use multiple kernels. For each entry, the kernel image, the DTB, the initrd and the bootargs are configurable. It is possible to have multiple entries to fit our desired scenarii. The kernels should be in image form and located somewhere in the rootfs, preferably in /boot.