Samsung Galaxy Book Go (Snapdragon 7c gen 2) no keyboard or mouse at install screen

[skeptical]

Hi, using installer v0.4 on a Samsung Galaxy Book Go (np340xla-ka1us)

• boots to grub fine with keyboard working
• selecting regular or graphic install opens either installer screen nicely, but keyboard/mouse are inactive and there is no way to proceed.
• I haven't tried any of the advanced automated install options in grub, being unsure of recovery if things go wrong.

I should say that even getting this far seems like a miracle on this device 👍, linaro images crash immediately. Anyhow any pointers on what to try would be appreciated, and I'd also be glad to do any remote diagnostics if you want.

[kennethgomez01]

@skeptical have you find away for keyboard and mouse work in linux installation? It seems that the hardware is not enabled to be use in installtion of this os.

[leezu]

I'm attaching the kernel log printed at boot. The errors may clarify how to fix keyboard / mouse support.
I verified that USB Keyboard / Mouse is not working either (even though it works in the Bios and Grub).

[leezu]

The reason for lack of keyboard and mouse support in the 5.11 image is that SC7280 (Snapdragon 7c Gen 2) SMMU support - which handles IO - was not yet part of 5.11 but added later torvalds/linux@0b779f5.

Booting mainline Linux (5.18-rc3) which enables the SMMU and would provide keyboard / mouse support, the screen turns black and the system reboots after a few seconds. Booting with earlycon=efifb keep_bootcon to obtain kernel log (instead of black screen), the last lines before reboot are:

  arm-smmu arm-smmu.0.auto: probing hardware configuration...
  arm-smmu arm-smmu.0.auto: SMMUv2 with:
  arm-smmu arm-smmu.0.auto: ◦stage 1 translation
  arm-smmu arm-smmu.0.auto: ◦non-coherent table walk
  arm-smmu arm-smmu.0.auto: ◦(IDRO.CTTW overriden by FW configuration)
  arm-smmu arm-smmu.0.auto: ◦stream matching with 71 register groups
  arm-smmu arm-smmu.0.auto: ◦61 context banks (0 stage-2 only)
  arm-smmu arm-smmu.0.auto: ◦Supported page sizes: 0x61311000
  arm-smmu arm-smmu.0.auto: ◦Stage-1: 36-bit VA -> 36-bit IPA

Disabling the SMMU support at build time (CONFIG_ARM_SMMU=n, CONFIG_ARM_SMMU_V3=n, CONFIG_QCOM_IOMMU=n) restores the "no catastrophic fault but no keyboard/mouse support" behavior observed with the laptops-5.11 image.

[shawnguo2]

@leezu The installer has been tested only on Lenovo Yoga C630 (SDM850) and Flex 5G (SC8180X). And installer boots kernel with ACPI instead of DT. Although SC7280 is supported by kernel, I assume it's mostly about DT boot. With that being said, I'm not surprised by that the installer doesn't boot on SC7280.

[leezu]

@shawnguo2 it makes sense. Are you aware of any DT Boot enabled live-usb / installer / documentation to create one?

[shawnguo2]

It shouldn't be too hard to pack a DTB into debian-cdimage and instructs installer to do a DT boot. But do you have a DT for Samsung Galaxy Book Go?

[leezu]

I don't, but do you think it's possible to extract it while running the pre-installed Windows? If you have any pointers how I could try that, that would be very helpful.

[shawnguo2]

Windows only does ACPI, so there is no DT from Windows.

[leezu]

Adding a DTB into debian-cdimage is indeed trivial. One just needs to add a profiles/gnome.extra file before calling build-simple-cdd listing any .dtb files that should be copied. The devicetree can then be specified at boot by editing the grub entry and inserting devicetree /simple-cdd/NAME.dtb as a new line.

The crux is how to obtain the device tree for the Samsung Galaxy Book Go. Rob Clark pointed out that Snapdragon 7c Gen 2 corresponds to SC7180 not SC7280. But none of the SC7180 device trees from https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/qcom that I tried worked. They would enable the device to boot to the installer page, but keyboard would remain dysfunctional.

[leezu]

Got a copy of the ACPI Table DSDT.aml via SSDTTime https://dortania.github.io/Getting-Started-With-ACPI/Manual/dump.html#from-windows and the decompiled DSDT.dsl via iasl.exe https://dortania.github.io/Getting-Started-With-ACPI/Manual/compile.html#windows

Results.zip

[steev]

For that results.zip - the https://github.com/aarch64-laptops/build repo has different directories, it might be better as a pull request there instead of a zip file attached to an issue here - in the misc directory, you can see how it's set up

[merckhung]

So I am able to boot to the shell and use USB and UFS storage on Galaxy Go.
The way I approach it is to reuse the ACPI support, instead of heading off crafting your own Device Tree.

So the first thing to handle is to make SMMU driver recognize the Galaxy Go laptop's ACPI.
(Otherwise the laptop will reboot once the SMMU driver is loaded)

Add this line into arm-smmu-qcom.c file

{ "QCOM ", "QCOMEDK2", 0x7180, ACPI_SIG_IORT, equal, "QCOM SMMU" },

And the next step is to enable USB (DWC3) driver to recognize the USB via ACPI.
So, add this line into dwc3/core.c file

{ "QCOM0826", 0 },

With these two changes, I am able to boot to the shell, and backup the windows 11 from the UFS storage (/dev/sda) via USB hub and drive.

For the keyboard and mouse, they are on i2c-hid, I have no luck here. But I am still trying to enable the keyboard.
And I am able to use USB keyboard and USB Wi-Fi for now.

[merckhung]

I am able to boot the Home Screen of Ubuntu. But still need to get the keyboard and mouse working.

so the ACPI was used. Wi-Fi and Bluetooth do not seem to be PCI devices. So for now, I have to use USB Wi-Fi and keyboard/mouse.

[merckhung]

BTW, I am surprised the internal UFS storage is actually 128GB. I recalled the hardware spec. Is 64GB. Interesting finding.

[hexdump0815]

@merckhung - just fyi: there was some bringup activity regarding the samsung galaxy book go on the #aarch64-laptops irc as well starting here https://oftc.irclog.whitequark.org/aarch64-laptops/2022-10-18#31531576 and going through the following days ... maybe there is something useful in there for you too and maybe you wanna join there as well?

[amcduffee]

@merckhung I have a Galaxy Book Go branch based on v6.1-rc1 kernel that has working keyboard and USB type-a port. I have yet to succeed with getting the trackpad operational. My changes are in a DTS though so it may cause the ACPI changes to be ignored. I am not entirely clear whether or not the DTB taking precedent over ACPI is driver by driver or kernel wide.

Here is my branch:
https://github.com/amcduffee/linux/tree/galaxy-book-go

[hexdump0815]

in case others want to work on bringing forward the galaxy book go as well: i have created a bootable debian image for it, which might be a good starting point to move forward from: https://github.com/hexdump0815/imagebuilder/releases/tag/221101-01

[Matheus-Garbelini]

@amcduffee do you have the flashable image generated from this branch?
Thanks

[Matheus-Garbelini]

@hexdump0815 is it worth to build an image with this kernel from qualcomm instead?
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/tag/?h=qcom-arm64-fixes-for-6.1
the dts folder has tons of new files which are not in the mainstream kernel github repo

[amcduffee]

@amcduffee do you have the flashable image generated from this branch? Thanks

As far as I recall, all of my DTS work is integrated into the image created by @hexdump0815 as noted in #21 (comment).

I suggest writing the image to a spare SD card or external USB disk, then select it from the boot menu. I think the image is very much experimental still, so not a great choice for writing to the internal storage just yet.

I have been quite busy lately and haven't resumed any work on the galaxy book go since the end of last year, so I am not really sure if more forward progress has been made. You can join the #aarch64-laptops channel on OFTC IRC to see if anyone else is working on it currently.

[AlexisBrasileiro]

I would love to help, but i lack on skills about compiling kernel and images;

my USB antena aren't recognized by this linux version, so my hands are quite tied...

and my english lacks pratice too (secondary language with poor experience)

but I'll give a try with a LAN USB-C adapter later

[Matheus-Garbelini]

@merckhung can you share us more details like what kernel version you applied this patch?
Is your Galaxy Go using 8C gen 2? or 7c?
Did you use mainline kernel repository and applied this patch or modified from a custom kernel branch?

[hexdump0815]

@amcduffee - fyi - some progress: based on the work from @TravMurav in his acer aspire 1 v6.2 tree i got the gpu working somehow on the samsung galaxy book go and have xorg running using it :) ... will cleanup what i have a bit and upload it during the next days - now its time to go to bed ... a big thanks to @TravMurav for his work!

[Matheus-Garbelini]

@hexdump0815 is your samsung galaxy book using Snapdragon 7c or 8c? the newer Samsung galaxy book 5G model is using 8C gen 2

[hexdump0815]

@Matheus-Garbelini - this github issue here is about the samsung galaxy book go which has a snapdragon 7c gen 2

[amcduffee]

@amcduffee - fyi - some progress: based on the work from @TravMurav in his acer aspire 1 v6.2 tree i got the gpu working somehow on the samsung galaxy book go and have xorg running using it :) ... will cleanup what i have a bit and upload it during the next days - now its time to go to bed ... a big thanks to @TravMurav for his work!

Wow, that is a pleasant surprise! I was thinking all along the GPU would be the hardest thing to get going. Neat.

So, the major hardware remaining in the trackpad and WiFi at this point?

I'll watch for your updated image and give it a try on my machine too.

[hexdump0815]

@amcduffee - in the end its all about getting a dts together and it looks like the gpu stuff is mainly soc specific and less board specific ... this is my current wip dts i used for this experiment: https://github.com/hexdump0815/linux-mainline-qcom-msm8998-kernel/blob/main/misc.qca/misc/sc7180-samsung-galaxy-book-go.wip ... just put this into the travmurav tree https://github.com/TravMurav/linux/tree/aspire1 and use the "make sc7180_defconfig" in it ... then some firmware from windows is required - see: https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/doc/required-firmware.md and some qcom userspace stuff https://github.com/hexdump0815/qcom-tools-build/releases/tag/20211117-01 ... it is still far from perfect, i think the console showed some random noise before xorg started, but xorg worked perfectly fine with freedreno ... will have to clean the dts up quite a bit still

update: oh i forgot - the gpu firmware needs to be in the initrd i think - for this i added https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/extra-files/etc/initramfs-tools/hooks/firmware

i think wifi should be doable as well if one follows the firmware layout from travmurav and for that i think another userspace tool not yet included in my build - the pd-mapper - and some json config for it is maybe required too

i'll most probably look more into this over the weekend

best wishes - hexdump

[neomax7]

@amcduffee - in the end its all about getting a dts together and it looks like the gpu stuff is mainly soc specific and less board specific ... this is my current wip dts i used for this experiment: https://github.com/hexdump0815/linux-mainline-qcom-msm8998-kernel/blob/main/misc.qca/misc/sc7180-samsung-galaxy-book-go.wip ... just put this into the travmurav tree https://github.com/TravMurav/linux/tree/aspire1 and use the "make sc7180_defconfig" in it ... then some firmware from windows is required - see: https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/doc/required-firmware.md and some qcom userspace stuff https://github.com/hexdump0815/qcom-tools-build/releases/tag/20211117-01 ... it is still far from perfect, i think the console showed some random noise before xorg started, but xorg worked perfectly fine with freedreno ... will have to clean the dts up quite a bit still

update: oh i forgot - the gpu firmware needs to be in the initrd i think - for this i added https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/extra-files/etc/initramfs-tools/hooks/firmware

i think wifi should be doable as well if one follows the firmware layout from travmurav and for that i think another userspace tool not yet included in my build - the pd-mapper - and some json config for it is maybe required too

i'll most probably look more into this over the weekend

best wishes - hexdump

awesome news. thanks for sharing your work

[amcduffee]

@amcduffee - in the end its all about getting a dts together and it looks like the gpu stuff is mainly soc specific and less board specific ... this is my current wip dts i used for this experiment: https://github.com/hexdump0815/linux-mainline-qcom-msm8998-kernel/blob/main/misc.qca/misc/sc7180-samsung-galaxy-book-go.wip ... just put this into the travmurav tree https://github.com/TravMurav/linux/tree/aspire1 and use the "make sc7180_defconfig" in it ... then some firmware from windows is required - see: https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/doc/required-firmware.md and some qcom userspace stuff https://github.com/hexdump0815/qcom-tools-build/releases/tag/20211117-01 ... it is still far from perfect, i think the console showed some random noise before xorg started, but xorg worked perfectly fine with freedreno ... will have to clean the dts up quite a bit still

update: oh i forgot - the gpu firmware needs to be in the initrd i think - for this i added https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/extra-files/etc/initramfs-tools/hooks/firmware

i think wifi should be doable as well if one follows the firmware layout from travmurav and for that i think another userspace tool not yet included in my build - the pd-mapper - and some json config for it is maybe required too

i'll most probably look more into this over the weekend

best wishes - hexdump

I will give this a try hopefully soon.

Are you planning to do another imagebuilder image with all these changes integrated?

[hexdump0815]

@amcduffee - yes, as soon as i find some time i plan to build a new one - i hope to have something ready by next weekend maybe

[hexdump0815]

@amcduffee - new image is ready now: https://github.com/hexdump0815/imagebuilder/releases/tag/230305-01 ... i have created a github issue to track everything around this image here: hexdump0815/imagebuilder#136 ... besides that please read the info on the release page, in the mentioned github issue, the info here: https://github.com/hexdump0815/imagebuilder/tree/main/systems/snapdragon_7c_woa and this one for which firmware is required, where and how to get it and how to enable gpu support: https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/doc/required-firmware.md ... sadly i noticed filesystem errors when using a usb rootfs, so it might be a good idea to use an sd card as rootfs to avoid data loss

good luck and best wishes - hexdump

[hexdump0815]

@amcduffee @neomax7 @saberman888 - new image with slightly newer kernel and no longer starting the pd-mapper service by default - it looks like this might get rid of the usb fs corruption i observed with the last image: https://github.com/hexdump0815/imagebuilder/releases/tag/230308-01

from now on i'll post updates here only: hexdump0815/imagebuilder#136

[merckhung]

@amcduffee do you have the flashable image generated from this branch? Thanks

As far as I recall, all of my DTS work is integrated into the image created by @hexdump0815 as noted in #21 (comment).

I suggest writing the image to a spare SD card or external USB disk, then select it from the boot menu. I think the image is very much experimental still, so not a great choice for writing to the internal storage just yet.

I have been quite busy lately and haven't resumed any work on the galaxy book go since the end of last year, so I am not really sure if more forward progress has been made. You can join the #aarch64-laptops channel on OFTC IRC to see if anyone else is working on it currently.

Hi @amcduffee,

I recently have some time to circle back on Galaxy Go (7c gen2), in the meantime, I have acquired another Galaxy Go (8cx gen2). On 7c front, I am trying to add UFS into dts based on aspire1 6.2 kernel, on the 8th gen2, I have successfully enabled UFS and USB, but I got stuck at defining the i2c-hid interrupt by looking at the ACPI DSDT file.

@amcduffee could you teach me about how did you get to know which and what to specify the interrupt for the ECKB and ECTC devices? I am trying to figure it out by myself but I guess you probably know better than me. Thank you.

[merckhung]

@merckhung can you share us more details like what kernel version you applied this patch?
Is your Galaxy Go using 8C gen 2? or 7c?
Did you use mainline kernel repository and applied this patch or modified from a custom kernel branch?

I have both since this week, I was talking about 7c.

[shawnguo2]

I have been trying to enable keyboard on Galaxy Book Go 5G for a while, but with no luck. I think we have a bigger problem than just figuring out the interrupt (GPIO) line, that is Linux driver fails talk to ECKB over I2C bus because error Bus arbitration lost, clock line undriveable.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-qcom-geni.c?h=v6.3-rc5#n259

[merckhung]

I have been trying to enable keyboard on Galaxy Book Go 5G for a while, but with no luck. I think we have a bigger problem than just figuring out the interrupt (GPIO) line, that is Linux driver fails talk to ECKB over I2C bus because error Bus arbitration lost, clock line undriveable.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-qcom-geni.c?h=v6.3-rc5#n259

As the keyboard has been enabled by UEFI before entering Linux, it must have something to do with clock gating, power gating, and regulators during the Linux driver initialization. I would say a path forward could be commenting out regulators, and clock sources from the i2c nodes in DTS and forcing the driver not to touch the clock and power as UEFI already set them up properly.

[shawnguo2]

Although the issue is seen with DT boot as well, I'm primarily booting the device from ACPI, in which case Linux Kernel doesn't touch the things like clock and regulator.

[hexdump0815]

@shawnguo2 @merckhung ... oh - nice to see some more people with a galaxy book go working on linux support ... i played around with the keyboard a bit more on mine based on my debian image and i meanwhile think that the halfway working keyboard in it is just working by chance - there are quite a few tlmm gpio interrupts i can enter for it and it will work somewhat for a while (the trick is to press any key very early on after the kernel has loaded to get the i2c log spam down) - in my wip dts based on the work of @amcduffee ( https://github.com/hexdump0815/linux-mainline-qcom-msm8998-kernel/blob/main/misc.qc7/misc/sc7180-samsung-galaxy-book-go.wip ) we were using tlmm 32, but that for sure conflicts with the touchpad enable gpio from the acpi/dsl - so i switched to 38 now (but there are dozen others which work too so it does not really seem to be important which one it is, but about half do not work) ... other than that i'm stuck regarding the keyboard and touchpad for now and any new input or step forward would be very welcome

what i got working is the gpu and wifi (will write something about that soon) - this is my debian image which should boot out of the box from usb: https://github.com/hexdump0815/imagebuilder/releases/tag/230308-01 and here are some hints about the required firmware files from windows to get the gpu working: https://github.com/hexdump0815/imagebuilder/blob/main/systems/snapdragon_7c_woa/doc/required-firmware.md

it would be very nice if we could get the samsung galaxy book go a bit further with mainline linux as it seems to be a widely available and not too expensive arm laptop just waiting for linux to run on it :)

[Vogtinator]

Hi! I just bought a Galaxy Book Go to play around with and to get this thing to work with Linux OOTB, by helping REing, debugging and mainlining. Is this issue + the #aarch64-laptops IRC channel the right place?

As a first step to see what the current state is I just tried to boot the latest kernel (6.5.4, then switched to a local build of 6.6-rc2) and it immediately resets even before earlycon=efifb shows anything, presumably due to the SMMU initialization. I followed the steps from #21 (comment) and added the missing match entries ("QCOM " should probably be "QCOM " with two spaces, to be safe I just added entries for both). The resulting kernel still fails surprisingly. I wonder whether this is some other issue (regression?). According to the IORT table, it should match.

[hexdump0815]

@Vogtinator - i think the latest state for the galaxy book go should be https://github.com/hexdump0815/imagebuilder/tree/main/systems/snapdragon_7c_woa and https://github.com/hexdump0815/linux-mainline-qcom-kernel/blob/main/readme.qc7 ... the aarch64-laptops irc channel is a good place to share and ask

[Vogtinator]

Ok. I'm wondering in particular regarding DT vs ACPI. Most efforts are about the DT, but for proper OOTB support, ACPI is necessary.

The resulting kernel still fails surprisingly. I wonder whether this is some other issue (regression?). According to the IORT table, it should match.

Apparently this is because of the kernel EFI stub. Booting linux "natively" through GRUB instead of running it as EFI executable gets it much further. I'll try to figure out why.

[hexdump0815]

@Vogtinator - as far as i understand it acpi on arm64 is nearly a dead end as a lot of important information is missing in acpi (and hardcoded in the windows drivers) and also many drivers used on arm have zero support for getting information from acpi - as a result one can get basic functionality with acpi but there it ends (for instance the gpu driver will definitely not work based on acpi and iirc its not really realistic to get it there) and it looks like there is no real way out of this ... so dts is the way to go on arm64 - acpi might work on servers with much less and more common hardware, but not on socs with lots of special functional blocks

[Vogtinator]

for instance the gpu driver will definitely not work based on acpi and iirc its not really realistic to get it there

Any more info about this?

Working with device model specific DTB files is a pain and only leads to even more bitrotting device specific image builds. Concentrating some effort to get it working with ACPI means that distros will just work, even without work spent on specific models.

[hexdump0815]

this might be interesting regarding the dts vs acpi topic and why dts currently is the way to go most probably: https://kernel-recipes.org/en/2023/schedule/the-arm-laptop-project/

[Vogtinator]

this might be interesting regarding the dts vs acpi topic and why dts currently is the way to go most probably: https://kernel-recipes.org/en/2023/schedule/the-arm-laptop-project/

Yep, though at least the slides itself didn't really go into detail there.

It mentions that the X13s boots in EL1, which is also what I observe on the Galaxy Book. Windows is able to use virtualization though, so I guess there is some mechanism to escalate to EL2, maybe some PSCI call.

[TravMurav]

It mentions that the X13s boots in EL1, which is also what I observe on the Galaxy Book. Windows is able to use virtualization though, so I guess there is some mechanism to escalate to EL2, maybe some PSCI call.

Sadly, the windows bootloader negotiates the takeover with the firmware in a vendor-locked way. I have a rough overview of this process here:

https://github.com/TravMurav/Qcom-Secure-Launch

[Vogtinator]

It mentions that the X13s boots in EL1, which is also what I observe on the Galaxy Book. Windows is able to use virtualization though, so I guess there is some mechanism to escalate to EL2, maybe some PSCI call.

Sadly, the windows bootloader negotiates the takeover with the firmware in a vendor-locked way. I have a rough overview of this process here:

https://github.com/TravMurav/Qcom-Secure-Launch

Ah, more bullshit, but not completely unexpected (can someone please sue the vendors for anti-competitive behaviour?...).

I was hoping this validation is also controlled by the SB flag in the FW config, but I guess not. According to https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4457.pdf, tcblaunch.exe does not validate components if driver signing is disabled, at least o x86_64 Win 10. That might be an entry point, albeit a very cumbersome one to use.

[TravMurav]

Ah, more bullshit, but not completely unexpected (can someone please sue the vendors for anti-competitive behaviour?...).

I was hoping this validation is also controlled by the SB flag in the FW config, but I guess not. According to https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4457.pdf, tcblaunch.exe does not validate components if driver signing is disabled, at least o x86_64 Win 10. That might be an entry point, albeit a very cumbersome one to use.

I kinda gave up re-ing this stuff after I saw the chain of trust is established from oem to the ms, but I think it shouldn't even be /that/ hard to jump to el2 with patched winload.efi that would make tcblaunch fail at the last moment, after it installed new vbar_el2, since it would then jump back to the user controlled code. I never really bothered making a PoC for this though... Then one could probably derive a way to launch this thing isolated from the whole windows install, and it would be """just""" one MS signed blob to go through to boot in el2 :/

[TravMurav]

I kinda gave up re-ing this stuff

FWIW https://github.com/TravMurav/slbounce