Surface Go 4 incompatible
-
Microsoft recently released a “business only” surface Go 4.
This go around they switched from having an NVME controller option to only offering a UFS based option.
See also https://www.microsoft.com/en-us/surface/business/surface-go-4
In the past models you could get either eMMC based storage or NVME based storage.UFS, being as it has previously not been a common pc form factor storage option, is not supported in the Fog Kernel (I’m on 6.1.22)
I imagine for me to get this thing deployed right now, I’ll need to go build a custom kernel.
Perhaps we can add UFS storage support in the kernel going forward? -
Some possible usb options found when searching UFS in kernel config.
Seems like we need the UFSCHD driver defined here https://www.kernel.org/doc/html/latest/scsi/ufs.html
One generic option for UFS was enabled at the top level.Symbol: PHY_MTK_UFS [=n] │ │ Type : tristate │ │ Defined at drivers/phy/mediatek/Kconfig:30 │ │ Prompt: MediaTek UFS M-PHY driver │ │ Depends on: (ARCH_MEDIATEK || COMPILE_TEST [=n]) && OF [=n] │ │ Location: │ │ -> Device Drivers │ │ (1) -> PHY Subsystem │ │ -> MediaTek UFS M-PHY driver (PHY_MTK_UFS [=n]) │ │ Selects: GENERIC_PHY [=y] │ │ Selected by [n]: │ │ - SCSI_UFS_MEDIATEK [=n] && SCSI_UFSHCD [=y] && SCSI_UFSHCD_PLATFORM [=y] && ARCH_MEDIATEK && RESET_CONTROLLE
Symbol: PHY_QCOM_QMP_UFS [=n] │ │ Type : tristate │ │ Defined at drivers/phy/qualcomm/Kconfig:89 │ │ Prompt: Qualcomm QMP UFS PHY Driver │ │ Depends on: PHY_QCOM_QMP [=n] │ │ Location: │ │ -> Device Drivers │ │ (2) -> PHY Subsystem │ │ -> Qualcomm QMP PHY Drivers (PHY_QCOM_QMP [=n]) │ │ -> Qualcomm QMP UFS PHY Driver (PHY_QCOM_QMP_UFS [=n]) │ │ Selects: GENERIC_PHY [=y]
Symbol: PHY_SAMSUNG_UFS [=n] │ │ Type : tristate │ │ Defined at drivers/phy/samsung/Kconfig:32 │ │ Prompt: Exynos SoC series UFS PHY driver │ │ Depends on: OF [=n] && (ARCH_EXYNOS || COMPILE_TEST [=n]) │ │ Location: │ │ -> Device Drivers │ │ (3) -> PHY Subsystem │ │ -> Exynos SoC series UFS PHY driver (PHY_SAMSUNG_UFS [=n]) │ │ Selects: GENERIC_PHY [=y]
This top level was enabled
Symbol: SCSI_UFSHCD [=y] │ │ Type : tristate │ │ Defined at drivers/ufs/Kconfig:6 │ │ Prompt: Universal Flash Storage Controller │ │ Depends on: SCSI [=y] && SCSI_DMA [=y] │ │ Location: │ │ -> Device Drivers │ │ (4) -> Universal Flash Storage Controller (SCSI_UFSHCD [=y]) │ │ Selects: PM_DEVFREQ [=y] && DEVFREQ_GOV_SIMPLE_ONDEMAND [=y] && NLS [=y]
This one was not enabled, enabling it in a test
Symbol: SCSI_UFSHCD_PLATFORM [=y] │ │ Type : tristate │ │ Defined at drivers/ufs/host/Kconfig:30 │ │ Prompt: Platform bus based UFS Controller support │ │ Depends on: SCSI_UFSHCD [=y] && HAS_IOMEM [=y] │ │ Location: │ │ -> Device Drivers │ │ -> Universal Flash Storage Controller (SCSI_UFSHCD [=y]) │ │ (6) -> Platform bus based UFS Controller support (SCSI_UFSHCD_PLATFORM [=y])
Also enabling these other choices
--- Universal Flash Storage Controller │ │ │ │ [*] Universal Flash Storage BSG device node │ │ │ │ [*] PCI bus based UFS Controller support │ │ │ │ [ ] DesignWare pci support using a G210 Test Chip │ │ │ │ [*] Platform bus based UFS Controller support │ │ │ │ [] Cadence UFS Controller platform driver
-
Should also mention I’m using the latest available linux kernel version for the test 6.6.1
-
Found that enabling just the PCI option
PCI bus based UFS Controller support
is all that is needed for the disk to show in FOS
On my first attempt to image though it gave errors regarding partition overlap and partition size. The disk shows in fog as 119 GB, my win 10 image (single disk resizable) is under 22 GB. Not sure how it isn’t expanding into the disk, there may be something else special needed.
Trying a different image. -
@JJ-Fullmer No difference with a different image.
This is the error message
Here is the ls -l of that image
ls -l /images/Base-Stable/ total 11098480 -rwxrwxr-x 1 fogproject root 6 Oct 12 07:34 d1.fixed_size_partitions -rwxrwxr-x 1 fogproject root 1048576 Oct 12 07:35 d1.mbr -rwxrwxr-x 1 fogproject root 872 Oct 12 07:35 d1.minimum.partitions -rwxrwxr-x 1 fogproject root 20 Oct 12 07:34 d1.original.fstypes -rwxrwxr-x 1 fogproject root 0 Oct 12 07:34 d1.original.swapuuids -rwxrwxr-x 1 fogproject root 10722570 Oct 12 07:35 d1p1.img -rwxrwxr-x 1 fogproject root 754 Oct 12 07:35 d1p2.img -rwxrwxr-x 1 fogproject root 11352884934 Oct 12 07:40 d1p3.img -rwxrwxr-x 1 fogproject root 153330 Oct 12 07:40 d1p4.img -rwxrwxr-x 1 fogproject root 872 Oct 12 07:34 d1.partitions -rwxrwxr-x 1 fogproject root 872 Oct 12 07:35 d1.shrunken.partitions
And the contents of d1.partitions
cat /images/Base-Stable/d1.partitions label: gpt label-id: 745A6813-735A-4940-840D-28D0E805850A device: /dev/nvme0n1 unit: sectors first-lba: 34 last-lba: 83886046 sector-size: 512 /dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63" /dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63" /dev/nvme0n1p3 : start= 239616, size= 57417925, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition" /dev/nvme0n1p4 : start= 82761728, size= 1120256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
Maybe it’s because it’s captured as /dev/nvmeXX instead of /dev/sdaXX ? Just brainstorming there.
Doing an update to the latest dev version just to be sure this isn’t fixed in a recent patch.
-
Made a pull request for including the ufs in the kernel config
https://github.com/FOGProject/fos/pull/78Probably should get it fully working before doing that pull though
@SEBASTIAN-ROTH any thoughts?
-
@JJ-Fullmer I’m currently working on new kernels and inits. Having issues with building partclone for the inits, but I’ll hopefully have some time this weekend to get it done.
I will include the ufs changes for the kernels. -
So more findings
Did a test of a different image that is based on
/dev/sda
instead of/dev/nvmeXnX
That image deployed with the modified kernel just fine (minus booting to the OS, but that was a windows server image, which I didn’t expect to work on a surface go).
But wait there’s more!
As I started playing around in a debug session I found that the UFS disk wants to have a sector size of 4096. This is the dump after manually creating the partitions to match the d1.minimum.partitions of the image
sfdisk --dump /dev/sda label: gpt label-id: 745A6813-735A-4940-840D-28D0E805850A device: /dev/sda unit: sectors first-lba: 6 last-lba: 31246330 sector-size: 4096 /dev/sda1 : start= 256, size= 25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63" /dev/sda2 : start= 25856, size= 4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda3 : start= 29952, size= 7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition" /dev/sda4 : start= 7369984, size= 140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
Whereas the header of d1.minimum.partitions in my normal base image is 512, though it seems like it might actually be 2048 based on math of partitionSectors/sector-size = size in MB (but I might be wrong about that formula, it’s been a minute since I’ve had to deal with sectors).
This is the contents of my d1.minimum.partitions from the image I want to deploy
label: gpt label-id: 745A6813-735A-4940-840D-28D0E805850A device: /dev/nvme0n1 unit: sectors first-lba: 34 last-lba: 83886046 sector-size: 512 /dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63" /dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63" /dev/nvme0n1p3 : start= 239616, size= 57417925, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition" /dev/nvme0n1p4 : start= 82761728, size= 1120256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
I tried what @Sebastian-Roth mentions in another post here https://forums.fogproject.org/topic/15608/imaging-from-large-drive-to-small-drive/4?=1700488459744 and what @Tom-Elliott mentions here https://forums.fogproject.org/topic/13004/error-trying-to-restore-gpt-partition-tables-on-multiple-dell-machines/13?=1700488480736
When I try to restore from the original file I get an error saying the
last-lba
is invalid/too high for the disk.What’s weird, is I can use that syntax to restore the server based image, and that min parts file also has a higher lba, but it makes a little sense as the final sector is below the drive’s “31246330” last lba.
cat ../SVR-Base-Stable/d1.minimum.partitions label: gpt label-id: 0B6865A1-3053-4F45-9371-B73F033C7395 device: /dev/sda unit: sectors first-lba: 34 last-lba: 188743646 sector-size: 512 /dev/sda1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=3DF3DEBB-C856-4CC2-9263-EAF0AABF2DDF, name="EFI system partition", attrs="GUID:63" /dev/sda2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C9738054-91F0-4B3A-AFFA-A9C9ABCC9663, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda3 : start= 239616, size= 27175378, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=42364778-3F9E-4421-88C1-698974428C14, name="Basic data partition", attrs="GUID:63" /dev/sda4 : start= 27415040, size= 1269760, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CA25B771-91EC-40A3-B200-1360371A0AD8, attrs="RequiredPartition GUID:63"
So I made a backup of my original image mbr and patition files and edited the d1.minimum.partitions to look like this
label: gpt label-id: 745A6813-735A-4940-840D-28D0E805850A device: /dev/nvme0n1 unit: sectors first-lba: 6 last-lba: 31246330 sector-size: 4096 /dev/nvme0n1p1 : start= 256, size= 25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63" /dev/nvme0n1p2 : start= 25856, size= 4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63" /dev/nvme0n1p3 : start= 29952, size= 7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition" /dev/nvme0n1p4 : start= 7369984, size= 140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"
Making it match the dump after making the partitions by MB and GB size manually.
After editing it this command worked without error
sfdisk /dev/sda < /images/Base-Stable/d1.minimum.partitions
So I made a new version of the d1.mbr
sgdisk -b /mnt/d1.mbr /dev/sda
And popped that on the server to test deploying with that. ON this test, I’m not editing the d1.partitions or d1.shrunken.partitions which may make it so it doesn’t expand properly, but we’ll see how it goes…
It got past the previous errors and is now imaging! woo hoo!
How to fix this permanently though, that’s a different question. -
The image did complete but it did not boot into Windows. Looks like I need to embed the storage controller driver for UFS.
Or it could be a 512b vs 4k block disk type issue.
-
@Sebastian-Roth or @Tom-Elliott any chance you have some time to help me out with this issue?
It’s looking like its a 4k block issue.
I was trying to find a formulaic way to change the partitions files to line up to the 4k layout, like dividing by 8 and some other tweaking as needed but found it more complicated than expected.Any ideas?
-
It’s looking like I have to find a way to either capture the image or a separate image from a device that defaults to 4k logical sectors or a way to force the device to change sector size to 512 when deploying a 512e based image
I tried
hdparm
but got this errorhdparm --set-sector-size 512 --please-destroy-my-drive /dev/sda /dev/sda: READ_LOG_EXT(SECTOR_CONFIGURATION) failed: No such file or directory
I also tried capturing the image using the new kernel on the off chance that would make a difference, but no good.
I guess I will have to try making an image from a 4k native device since it’s not being changed?