robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
sz3m3k[m] has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
Dylanger has joined #aarch64-laptops
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #aarch64-laptops
<HdkR>
I have myself a really spicy USB-C device that refuses to be picked up by the X13s type C ports
<HdkR>
Nothing shows up in dmesg, but if I plug it in to a USB 3.0 hub then it shows up
<push>
afaik, usb2 and usb3 are totally different protocols, devices have different IDs, everything, these dell monitors here have a usb3 hub in them but the usb3 chip is burnt out
<push>
devices only work if I connect the monitors with a cable that doesnt support usb3
<HdkR>
Looks like this pmic-glink stuff fails to set up a device link for a bunch of things. usb ports, usb phys, usb muxes
firlaev-hans-fiete[m] has joined #aarch64-laptops
<HdkR>
Doesn't really explain how I would go about fixing it or if it even matters for this
Lucanis has quit [Read error: Connection reset by peer]
<dgilmore>
jhovold: I just tested v2 of the patch for the touchpad in 6.6 it seems to work well here. Will work on sending in a Tested By in the morning
alpernebbi has joined #aarch64-laptops
anarchron has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
_[m]1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
pz[m] has joined #aarch64-laptops
quinine has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
jenneron[m] has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
sally[m]1234567 has joined #aarch64-laptops
<jhovold>
dgilmore: thanks, i'll go ping the maintainer as well
<jhovold>
HdkR, push: those "Failed to create device link (0x180)" warnings are mostly benign and not related to your non-working USB device
<jhovold>
HdkR: there's a known issue with cold-plugging SS devices, try flipping the connector if devices show up as HS instead of SS
harvests[m] has joined #aarch64-laptops
<HdkR>
jhovold: I definitely flipped the connector multiple times and it didn't change behaviour
<jhovold>
ok, perhaps some other (fw) incompatibility then, sounds like it may not be getting the the amount of power it needs if connecting an external powered (?) hub makes things work
<HdkR>
So I have Hub->Hub. It works on the second powered hub but not the first powered hub
<HdkR>
First powered hub which is directly on the device gets the massive communication issues
<HdkR>
Second powered hub probably works because it is only running at 480mbit for some reason?
<jhovold>
HdkR: sounds like you have two issues then; the second hub not enumerating as SS and the USB disk only working with HS hubs
<HdkR>
Bunch of spicy problems with the USB
<jhovold>
The only "confirmed" ones are the USB SS coldplug issue, parts of USB PD not being implemented, and the IOMMU throughout issue
<jhovold>
Yeah, you can't rule out that you may have been unlucky with what devices you use just yet
<jhovold>
throughput*
<jhovold>
And when you use external adapters like that you may be hitting the known USB PD issue...
<HdkR>
I'm definitely aware of the DP issue on this particular hub since it can't power my highend displays. And I don't use the Ethernet on it due to the limited throughput
<HdkR>
I should swap the USB 3.0 hub to be the first one and see if behaviour changes. I also have another hub which might behave differently
alfredo has joined #aarch64-laptops
<HdkR>
Would be nice if these NVMe enclosures worked directly attached though
go4godvin has joined #aarch64-laptops
<jhovold>
HdkR: are you still using that 5 Gbit ethernet? I don't have any issues with my directy connected 1 Gnit adapter as long I enable the iommu lazy mode
go4godvin is now known as Guest2233
<HdkR>
Nah, I stopped using that since it breaks the kernel immediately
<jhovold>
ah, right. :)
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<HdkR>
Oh, of course the SteamDeck hub works fine with the drive
<HdkR>
How rude
<HdkR>
and second powered hub directly connected to the laptop works and the drive sees 5gbit
iivanov has joined #aarch64-laptops
<HdkR>
So really two things. The Cable matters hub has a weirdo issue where the drive falls out and can't communicate
<HdkR>
and directly attached it doesn't even show up in dmesg
<HdkR>
I have another powered USB hub coming tomorrow to see if that changes behaviour as well
<HdkR>
So maybe you're right that the USB port refuses to provide the amount of power that the enclosure desires?
<jhovold>
It's an hypothesis at least, I know there are some bits missing in this area which may cause trouble with the laptop not charging through an external adapter. May or may not be related.
<jhovold>
I would have thought the fw should handle the external disk case on its own though
<HdkR>
When in UEFI the drive is powered
<HdkR>
When directly connected
<HdkR>
Power goes out when pd-mapper starts I think. Didn't try killing pd-mapper and seeing if it survives
<jhovold>
interesting, let's ping bamse so he sees this ^
<HdkR>
https://sabrent.com/products/ec-wptf It's a fairly lightweight NVMe enclosure, it's power consumption can't be /too/ terribly high. More than 5W obviously since the SSD can pull like 9W?
matthias_bgg has joined #aarch64-laptops
<HdkR>
Could probably pull the MaxPower spec once I'm done with dinner to see what it is requesting
<hexdump0815>
Dylanger: i did not really look deep into it recently, but to me it looks like this seems to be a chromeos kernel tree kept in sync with mainline which seems to have mediatek and orther changes in
<Dylanger>
This looks good to me
<Dylanger>
I'll try it with cherry
<Dylanger>
I'd like Fedora to provide support for depthcharge, they have aarch64 images for download but they're for like, RPis?
<Dylanger>
If they had an image for "Chromebooks with Depthcharge" that'd be 🔥
travmurav[m] has joined #aarch64-laptops
Lucy[m] has joined #aarch64-laptops
hlr[m] has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
Cyrinux94743 has joined #aarch64-laptops
Cyrinux9474 has quit [Ping timeout: 480 seconds]
Cyrinux94743 has quit []
martiert has quit [Quit: WeeChat 4.0.5]
martiert has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.0.5]
martiert has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
martiert has quit [Ping timeout: 480 seconds]
patzek[m] has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
martiert has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
emily[m] has joined #aarch64-laptops
akawolf[m] has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
malvi[m]1 has joined #aarch64-laptops
Sobek[m] has joined #aarch64-laptops
<bamse>
HdkR: what kind of "spicy USB-C device" is this?
<bamse>
HdkR: if you connect it in windows, does it show up as a usb device or a pcie device?
<bamse>
although it says usb3.2...not usb4...
alfredo has quit [Ping timeout: 480 seconds]
<HdkR>
It's USB, they also have a separate TB enclosure that doesn't work on Linux at all even through a TB port on Linux :D
<HdkR>
USB interface descriptor shows up as a SCSI mass storage device
<HdkR>
Works through either UAS or usb-storage which is nice
<bamse>
when you connect it beyond your hub and it works, you mean?
<bamse>
or did i misunderstand what you wrote above?
<HdkR>
yea
<bamse>
and when you connect it directly, then it doesn't show up at all
<HdkR>
Indeed, LED light doesn't even light for power doesn't even light up
<HdkR>
The device is pretty dumb for the LED light in this regard. Connected directly to a USB-C power source it will light up
<bamse>
ahh, i see...that's a less fun problem than i was hoping for ;)
<bamse>
i guess we need to look at what's going on on the usb pd side then, and then see if that relates to the lack of implemenation there (as Johan points out)
<HdkR>
Oh right, I was going to look at if pd-mapper is killing it once it gets to desktop. Since the power light on the enclosure stays on through boot until some point
<bamse>
ahh, yeah, when we boot linux we reload the adsp firmware...and then when pd-mapper comes up it triggers something in the newly loaded firmware
<bamse>
and when this happens we're loosing the usb bus for a while
<bamse>
i've not spent the time to confirm if it's just vbus, or the whole usb bus is reset for some reason... but the symptom is known at least
<HdkR>
Interesting
<bamse>
and it might very well be that the enclosure doesn't like the glitch
<bamse>
or, does it not work if you connect it after the fact either? i.e. is there something in the loaded firmware (or linux) that is incompatible or missing?
<HdkR>
Does not work after the fact when replugging
<bamse>
okay, seems like it could be an issue with the power-delivery negotiation, as johan suggests
<HdkR>
Okay, the light goes out prior to hitting desktop, sometime during boot messages
<bamse>
how nice, if i order within 23 minutes i can start debugging already tomorrow!
<HdkR>
:D
<HdkR>
Trying to remember/google that kernel config option to delay all messages to slow it down
<jhovold>
HdkR: boot_delay=
<HdkR>
That's one of them, but there was another one to slow down every printk as well
<HdkR>
Oh that is it isn't it, just funny name
<bamse>
ohh, i wasn't logged in to amazon...now i have 1hr5min to order it, and i can start debugging between 5 and 10pm today...
<HdkR>
sick
<bamse>
i need a working usb pd-analyser first though; because the one i have comes with a windows tool that doesn't run on arm64 :(
<HdkR>
Oh, Linux actually sees the drive early in boot. Saw it through boot_delay come up
<bamse>
but not after pd-mapper has started, including if you replug the device?
<HdkR>
I gave pd-mapper the boot. seems like later during boot is when it dies
<HdkR>
boot_delay=60 might have been a bit excessive
Matthew[m] has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<dgilmore>
Dylanger: the Fedora images are for all systems. except Chromebook
aigotchi[m] has joined #aarch64-laptops
<Dylanger>
🙃
<dgilmore>
Dylanger: there is a tool available that will install u-boot into the image for different systems that need it. and for systems with u-boot with UEFI support on SPI, or providing tianocore or some other UEFI implementation they will just work
<dgilmore>
It would be great to figure out producing a image for use on Chromebooks. I personally gave up on them because the unlocking and process to get Linux on themis a pain
<dgilmore>
but they have some affordable hardware options
matthias_bgg has joined #aarch64-laptops
<Dylanger>
It's actually not bad, there used to be a really cool project called Cadmium
<Dylanger>
This has scripts to easily generate a depthcharge compliant kernel
<Dylanger>
imo if Fedora offered support for aarch64 chromebooks, that'd be huuuuuuge
<maz>
just having u-boot support for chromebooks would be the enabler. no need for anything special on the distro side.
<maz>
(I have two trogdor devices collecting dust most of the time because running upstream on them is painful compared to other systems.
<Dylanger>
It's not that bad with Cadmium's scripts
<Dylanger>
I use my cherry every morning to read the news and as a remote client if I go get coffee etc
todi has joined #aarch64-laptops
<Dylanger>
It's so light and nice
<pz[m]>
I ran into an issue installing EndeavourOS on my x13s, I did it twice to make sure it wasn't me making a typo along the way.
<pz[m]>
After following the ironrobin guide, I install and reboot but boots into ArchLinux. It doesn't seem like the EndeavourOS install actually takes.
<maz>
Dylanger: let me put it another way: I have a farm of about 20 different machines. when I test a kernel, I throw the same debian kernel package at all the machines, let them chew on it for a while and pick the pieces. with chromebooks, I need to do all sort of magic incantations, and pray that the kernel image fits in the 16/32MB that is reserved...
<Dylanger>
Totally understand
<Dylanger>
Updating my kernel is a scary process
iivanov has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
sporos11[m] has joined #aarch64-laptops
NomadNaomie[m] has joined #aarch64-laptops
wiizzard has joined #aarch64-laptops
juergh1 has joined #aarch64-laptops
matalama_ has joined #aarch64-laptops
Leandro[m]1 has joined #aarch64-laptops
strongtz[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
qzed has joined #aarch64-laptops
qzed is now known as Guest2291
<HdkR>
Alright, another powered USB hub for poking
matthias_bgg has quit [Quit: Leaving]
<HdkR>
Orientation definitely matters on this one
<HdkR>
New Hub's USB 3.0 ports working which is good
<HdkR>
HDMI not working, although it did complain about the DP AUX IRQ
<HdkR>
Gigabit works on it at least
<HdkR>
and it also has an integrated NVMe slot, so let's see if that works...
<HdkR>
Yep, NVMe works. So the only problems with this new USB hub. HDMI doesn't work and orientation matters so I had to cover it in permanent marker
Nei[m] has joined #aarch64-laptops
Cyrinux94743 has joined #aarch64-laptops
<HdkR>
Oh no, the HDMI connection does work. Just needed to reboot with the connection attached from the start weirdly
<HdkR>
So really just orientation on this dock then
<HdkR>
...Apparently my analog audio USB dongle acts as a radio antenna when disabled. I pick up some random station due to interference when I power cycle it