Internal install: Linux on userdata, kernel booted from it directly #15

Open
opened 2026-08-22 14:55:23 +00:00 by kit · 0 comments
Owner

Move the rootfs off the SD card onto the internal UFS by reusing the userdata partition, and boot the kernel straight out of it.

Why userdata

It is the only partition big enough, we do not need Android's data, and — importantly — this is not a GPT change. We ruled out repartitioning because we could not confirm sboot's behaviour, but reformatting an existing partition is not the same thing. Reading ABL's Partition.c and Samsung's XBL additions turned up no partition-table integrity check, and reusing userdata avoids the question entirely.

The payoff is real: UFS measured ~891 MB/s vs the SD card, so this is the single biggest performance win left.

Boot path

U-Boot already has CONFIG_SCSI=y, CONFIG_CMD_SCSI=y and CONFIG_CMD_EXT4=y, so it can read ext4 on UFS:

ext4load scsi 0:N ${kernel_addr_r} /boot/Image.gz
unzip ${kernel_addr_r} ${loadaddr}
ext4load scsi 0:N ${fdt_addr_r} /boot/dtbs/qcom/sm8150-samsung-gts6l.dtb
booti ${loadaddr} - ${fdt_addr_r}

So the kernel lives in /boot on the rootfs like any normal Linux system — no separate boot partition, no Android boot image, no CRC sidecar. See u-boot-gts6l#1.

This also makes the linux-gts6l package actually meaningful: pacman -U installs /boot/Image.gz + /boot/dtbs/... and that is what boots.

Steps

  1. Confirm U-Boot can read the fs: scsi scan; ext4ls scsi 0:N /boot. Our filesystem uses orphan_file (TWRP's e2fsck rejected it), so verify U-Boot's ext4 driver copes before depending on it.
  2. Create the rootfs on userdata (mkfs.ext4 — consider disabling newer features if U-Boot struggles).
  3. Copy the SD rootfs across, fix root= in bootargs.
  4. Keep SD boot working as fallback during the transition.

Caveats

  • Wipes Android's user data (expected).
  • A future Odin flash would rewrite the GPT from the PIT — a wipe, not a brick.
  • Rootfs damage then costs booting; fbauto fastboot fallback and TWRP remain as recovery.
Move the rootfs off the SD card onto the internal UFS by reusing the `userdata` partition, and boot the kernel straight out of it. ## Why userdata It is the only partition big enough, we do not need Android's data, and — importantly — this is **not a GPT change**. We ruled out repartitioning because we could not confirm sboot's behaviour, but reformatting an existing partition is not the same thing. Reading ABL's `Partition.c` and Samsung's XBL additions turned up **no partition-table integrity check**, and reusing `userdata` avoids the question entirely. The payoff is real: UFS measured ~891 MB/s vs the SD card, so this is the single biggest performance win left. ## Boot path U-Boot already has `CONFIG_SCSI=y`, `CONFIG_CMD_SCSI=y` and `CONFIG_CMD_EXT4=y`, so it can read ext4 on UFS: ``` ext4load scsi 0:N ${kernel_addr_r} /boot/Image.gz unzip ${kernel_addr_r} ${loadaddr} ext4load scsi 0:N ${fdt_addr_r} /boot/dtbs/qcom/sm8150-samsung-gts6l.dtb booti ${loadaddr} - ${fdt_addr_r} ``` So the kernel lives in `/boot` on the rootfs like any normal Linux system — no separate boot partition, no Android boot image, no CRC sidecar. See u-boot-gts6l#1. This also makes the `linux-gts6l` package actually meaningful: `pacman -U` installs `/boot/Image.gz` + `/boot/dtbs/...` and that *is* what boots. ## Steps 1. Confirm U-Boot can read the fs: `scsi scan; ext4ls scsi 0:N /boot`. Our filesystem uses `orphan_file` (TWRP's e2fsck rejected it), so verify U-Boot's ext4 driver copes before depending on it. 2. Create the rootfs on `userdata` (mkfs.ext4 — consider disabling newer features if U-Boot struggles). 3. Copy the SD rootfs across, fix `root=` in `bootargs`. 4. Keep SD boot working as fallback during the transition. ## Caveats - Wipes Android's user data (expected). - A future Odin flash would rewrite the GPT from the PIT — a wipe, not a brick. - Rootfs damage then costs booting; `fbauto` fastboot fallback and TWRP remain as recovery.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kit/linux-gts6l#15
No description provided.