ChanServ 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
iivanov has quit [Remote host closed the connection]
<DanaG>
I copied the contents of the test iso to a USB drive (that is, a file copy, rather than writing the hard-to-deal-with iso format). That made it much easier to set the terminal to gfxterm and override the blank-string dtb and kernel args.
<DanaG>
I also took "quiet splash" out to get at least some chance of seeing at least something on the screen.
<DanaG>
I think it might be helpful for the ISO to have some default devicetree and kernel args, instead of mysteriously resetting because <oops, message blinked by too fast>
jhovold has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
hipboi has joined #aarch64-laptops
iivanov has quit [Read error: No route to host]
iivanov has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
iivanov has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
tobhe_ is now known as tobhe
alfredo1 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
iivanov has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
DanaG_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
DanaG_ has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
crisma has left #aarch64-laptops [WeeChat 3.8]
crisma has joined #aarch64-laptops
crisma has left #aarch64-laptops [WeeChat 3.8]
<zeph[m]>
tobhe: annnd ...it works!
crisma has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<\[m]>
seeing some movement on rocky linux front for arm
flokli has quit [Ping timeout: 480 seconds]
flokli has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
aaaaand the devkit is out of stock again
<Jasper[m]>
That was quick, was like 33 yesterday lol
<SpieringsAE>
jeah thats what I thought too, I wanted to ask my boss to get me one today but I guess I
<SpieringsAE>
will have to postpone that lol
<\[m]>
can you just buy the cpu x1e-00 somewhere?
<macc24>
what
<macc24>
it's a bga chip
<\[m]>
yes
<\[m]>
does that imply they're not for sale seperately?
<macc24>
yes
<abby>
almost certainly only at commercial qtys
<macc24>
and you need special equipment to solder a bga chip
<\[m]>
i checked it's not as expensive in china
<erebion[m]>
@SpieringsAE What devkit? :D
<Jasper[m]>
erebion[m]: c8380 on arrow.com the one for the X Elite socs
hipboi has quit [Quit: hipboi]
<\[m]>
why do they update their stokc if they can't even fullfill the existing orders - I don't get it
hipboi has joined #aarch64-laptops
<maz>
\[m]: don't try to apply logic to the Arrow website. there is none.
hipboi has quit [Quit: hipboi]
<JensGlathe[m]>
I wanted a quite from Arrow, they never sent one
<\[m]>
<maz> "\: don't try to apply logic to..." <- I know I'm stuck, can't login because too many faulty logins and reset pw not working -_-
<JensGlathe[m]>
quote*
<\[m]>
bga reballing looks pretty intense btw - but not impossible, and I mean, if ever you have a feeling of lack of ownership of your hardware, there's how to solve it 😄
<\[m]>
just risk bricking 1.5k euro 😅
<\[m]>
for close to no benefit except: why not
<travmurav[m]>
~~and then realize it doesn't boot because donor soc has enrolled SB keys from a different oem/device~~
<\[m]>
tpm is dedicated chip no
<Jasper[m]>
\[m]: TZ applet... sometimes
<\[m]>
assuming the keys live there
<\[m]>
aren't SB keys for OS tampering security?
<\[m]>
and seperately MSFT gatekeeping certs
<travmurav[m]>
there is uefi secureboot and hardware secureboot, we're talking about hardware secureboot
<travmurav[m]>
with which all firmware on the spi flash is signed with
<travmurav[m]>
and the key hash is enrolled in the soc efuses
<travmurav[m]>
so impossible to change
<travmurav[m]>
so unless you get a brand new unfused soc to solder on, you can just assume it wont' work
<\[m]>
smoll disclaimer 😄
<\[m]>
if you reset/clear that spi, you break the system too ?
<travmurav[m]>
well until you reflash it with the original oem firmware xD
<\[m]>
yeah not the fw but like the certs?
<travmurav[m]>
wihch one would proabbly have to do by removing and flashing the chip manually since the usb programmer blob also must be signed by the oem
<travmurav[m]>
all firmware blobs on the spi flash are signed and obviously without firmware the soc won't boot
<travmurav[m]>
in this case firmware == uefi, tz and all the bootloaders before those
<\[m]>
I guess smarter people designed it to be hard to circumvent lol
<\[m]>
but it's the same cpu no - it will not be like taking hash on model name but on some hardware level ID no?
<travmurav[m]>
hash of the oem key is programmed into the soc efuses at the factory
<\[m]>
I'm thinking now how they sign the fw in manufacturing, like a testbench where they flash the spi and have some intermediate cert mm
<\[m]>
oh they put a local key in the hw? mm
<travmurav[m]>
as in, brand new soc would be "unfused" and allow booting any signatures, but as soon as it boots (at the factory) firmware would install the keys into the soc itself
<travmurav[m]>
you may remember the "amd efuses" story where if you put a ryzen cpu into some lenovo thing, it will only ever run in that lenovo from that point
<travmurav[m]>
this is the same thing
<travmurav[m]>
so like OEM has private key, with which uefi is signed, and a public key for that private key is attached to the uefi along with the signature. Then that is flashed to spi flash and the device is booted.
<\[m]>
it had some sort of hard overwrite of the efuse? lol
<travmurav[m]>
The soc sees that there is no key hash in efuse, so it allows "unknown" signature and boots firmware/uefi
<\[m]>
or no, the lenovo local key put something in the cpu??
<travmurav[m]>
the firmware sees that it's signed with the oem key but that key wasn't yet placed into the soc efuses, and immediately burns the public key hash into the soc
<\[m]>
ah just the pub key in spi flash?
<travmurav[m]>
on the next boot the soc will see that it has a public key hash so after loading firmware from the spi it will check the attached cert matching the efuse hash and then check the signature against that cert
<travmurav[m]>
the pub key is attached to the firmware but the hash of that key is stored inside soc efuses
<travmurav[m]>
so if you replace the spi flash firmware with one that wasn't signed by same oem, soc will load it, check the public key and refuse to boot, since the hash doesn't match
<\[m]>
then if you check the firmware for different soc, and it's binary equal, you can assume the certs will work for both
<travmurav[m]>
and no, there is no way to update efuses after they were enrolled. they're one time programmable and there is an extra write protect bit
<travmurav[m]>
well yes, if the firmware is exactly the same then you can just use the one signed by correct oem :D
<\[m]>
assymetric crypto hurts my brain always 😄
<travmurav[m]>
but the problem is that dsp dtb blobs are also signed by the oem and those are board-specific afaiu
<travmurav[m]>
so in the end, as soon as the soc efuses were enrolled, it's pretty much married to the board it's on
<travmurav[m]>
(since afaik qcom recommends having a public cert per board, and some oems like samsung do certs per-region even, so even if the board is the same, fw keys are different)
<\[m]>
waw tx for explaining this 😲
<travmurav[m]>
there is an additional complication in the recent socs that there are actually two key pairs, one for qcom itself so even if the oem signs something, for lowest level firmware it also must be blessed by qcom
<travmurav[m]>
but that doesn't really matter in the end then, just that effectively all modern qcom socs are vendor-locked to qcom firmware
<\[m]>
still I thought the boards were the same and the only diff is the cpu sillicon quality
<travmurav[m]>
not like they will give away docs anyway, who needs innovation in that space
<\[m]>
probably even less worth the risk now
<travmurav[m]>
well if you have same board from the same oem, then you may be able to change the soc, but I'd just by default assume it won't work
<\[m]>
damn that does fck a bit with replaceability of parts mm I don't think you could say, out of warranty the customer can choose to unlock their spi flash mm
<\[m]>
gg owning your hardware
<travmurav[m]>
yep, welcome to the mobile systems world :D
<\[m]>
travmurav[m]: you're triggering me haha
<\[m]>
(funnily, the vmware carbon black security monitoring had compat issue with secure boot - we had to boot a bunch of servers with it disabled - the irony)
<\[m]>
but i never thought about the hw security extent
<travmurav[m]>
but well, the hardware secureboot is the exact reason why we can't just "hack the firmware" to make it boot linux in el2 and need some very special magic to jump through correctly signed blobs
<travmurav[m]>
the chain of trust starts in hardware
<\[m]>
I was reading slbounce repo, I'm like who are these genuises 😲
<\[m]>
I am guessing this was not a one-person effort
<travmurav[m]>
slbounce was I'm afraid
alfredo has joined #aarch64-laptops
SpieringsAE has quit [Quit: Leaving]
<tobhe>
zeph[m]: \o/
<tobhe>
feel free to comment on the bug if you identify any commits or features we are missing
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
<maz>
devkit has landed.
<travmurav[m]>
maz: on your doorstep or in the linux tree? :D
<maz>
travmurav[m]: in my grubby hands. have to start somewhere!
<travmurav[m]>
nice, I think there is a dt patch on the lists already
<Jasper[m]>
Yes, lots of stuff functioning too
<maz>
yup. slbounce and serial first, though.
<maz>
if that doesn't work, there will be a devkit up for grab..
<travmurav[m]>
maz: well unless you want to quickly try sltest you won't get much without linux I guess :D
<travmurav[m]>
I hope that thing has display working in uefi
<travmurav[m]>
considering all that edp/hdmi mess
<travmurav[m]>
maz: but what I wanted to ask is when/if you get to linux proper, if you could share output of `sudo fwupdtool hwids` for dtbloader purposes
<maz>
travmurav[m]: of course.
<travmurav[m]>
serial should be trivial though I think, seems like that board is just some actual hw devkit in a fancy box so it has a convenient usb to serial adapter built in, fancy :D
* travmurav[m]
finds it so stupid that they just didn't put a black sticker over the hdmi hole since he assumes thye had to respin the plastic
<maz>
I want to probe it first. I've seen boards where the 1.8v serial pins were exposed over a similar u-USb connector...
<travmurav[m]>
uh oh
<travmurav[m]>
but I think I saw a wch chip near it
<maz>
yeah... holy smoke...
<\[m]>
<maz> "if that doesn't work, there will..." <- just desolder the cpu for me 😄
<\[m]>
it doesn't have hdmi in the end I think
<travmurav[m]>
yes, because they re-spun/reworked the hdmi subboard and re-spun the plastic shells to remove the hole
<travmurav[m]>
which is probably why it was delayed so long
<travmurav[m]>
instead of saying "sorry it doesn't work", unplugging the edp cable and slapping a black sticker on the housing
<travmurav[m]>
for $0.1
<travmurav[m]>
respinning plastic molds costs stupid amount of money, especially for such a low volume product
<maz>
no clue how you get to EFI with that thing. I get a snapdragon logo, then a windows logo, and then it boot into the dread thing.
<travmurav[m]>
no button mashing?
<maz>
the power button, you mean?
<travmurav[m]>
I'd assume/hope it's same as crd or something tbh, but dunno how those go into the setup
<travmurav[m]>
well I mean all the fn buttons and esc xD
<maz>
yeah, tried that.
<travmurav[m]>
I wonder if it may have something on serial
<travmurav[m]>
uhhh
<sgerhold>
on CRD: press "down" key for booting from USB
<sgerhold>
EFI menu is a bit hard to reach
<sgerhold>
but it's also not too useful
crisma has quit [Ping timeout: 480 seconds]
<macc24>
you can hold shift and press reboot button in windows
<macc24>
that'll get you into startup options menu
<macc24>
from there you can go into advanced settings and somewhere in there should be an option for booting into bios/uefi/boot firmware
<DanaG>
I've found that for some reason, shift to get the menu doesn't work on the Surface Pro 11.
<DanaG>
What does work is the command (in an admin command prompt):
<DanaG>
shutdown /r /t 0 /fw
<maz>
ah, the eDP cable is there. only the stupid connector is missing.
<maz>
(HDMI)
<travmurav[m]>
maz: wait they even put the cable inside???
chrisl has quit [Remote host closed the connection]
<travmurav[m]>
probably on some testpoints or that huge debug connector but impossible to know without either probing all of them or having the schematics
chrisl has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
<maz>
EBKAC. UART is on.
<travmurav[m]>
\o/
<travmurav[m]>
does it spew early boot logs on it?
<travmurav[m]>
Jens Glathe: but you said they tried to ship it?
<JensGlathe[m]>
My packge is in transit (Amsterdam now, next destination Berlin), we'll see if it arrives
<travmurav[m]>
oh I really hope it does (and that they refund it too) xD
<travmurav[m]>
but this is sad
<JensGlathe[m]>
sorta, yeah
<JensGlathe[m]>
should it arrive it will def run Linux bc Win support is gone, but UEFI updates, too
<JensGlathe[m]>
what would incline QCOM for such a move
<travmurav[m]>
this board is actually a very nice thing to have for platofrm bringup, but I'd assume people who actually do platform would be all qcom sponsored anway so not sure how much of a loss this is in the end
<maz>
wow.
<JensGlathe[m]>
exclusivity with MSFT ends?
<JensGlathe[m]>
and there have been "differences in expectations" or something?
<travmurav[m]>
well they certainly failed on many levels with it
<travmurav[m]>
not enough supply, delays in shipping...
<travmurav[m]>
but eh
<travmurav[m]>
it's the faith of qcom original design: you can't get one
<maz>
oh well, free machine.
<maz>
wonder if I can claim import duty...
<JensGlathe[m]>
🤷♂️
<JensGlathe[m]>
If I get it then yes
<maz>
149 quid, that's quite a few beers!
<Jasper[m]>
<JensGlathe[m]> "image.png" <- WTF
<JensGlathe[m]>
oh the other way round, its the price of getting a box
<Jasper[m]>
HAHAHAHA
<JensGlathe[m]>
what are alt aarch64 laptop chips? Apple M only?
<travmurav[m]>
allegedly it might actually be off and just configured externally to behave as on, but that's a slim bet
<JensGlathe[m]>
You can get into the UEFI BIOS? Usually you can switvh it off
<travmurav[m]>
this is hw secureboot
<travmurav[m]>
for firmware itself, obviously the uefi secure boot can be disabled xD
<JensGlathe[m]>
Oh I expected as much, so snafu
<travmurav[m]>
maz: so a weird thing I saw on the linaro crd debian image page is that if you spam `\033[H` into uart, it would go into a setup menu, idk how true that is
<travmurav[m]>
\033 is ESC byte
<freekurt[m]>
<JensGlathe[m]> "what are alt aarch64 laptop..." <- rockchip, MediaTek and allwinner come to mind right away. there might be more.
<freekurt[m]>
JensGlathe[m]: I'm not following these companies to see what new aarch64 chips they have out recently or have plans for. Maybe they have plans to try to compete?
<maz>
travmurav[m]: managed to get into that menu via the shutdown /fw command
<JensGlathe[m]>
for waht market is the question
<macc24>
<JensGlathe[m]> "what are alt aarch64 laptop..." <- mediatek and rockchip
<travmurav[m]>
maz: nice, btw assuming you booted into windows, next time you do, may want to double check that the cpu perf monitor things says virtualization enabled on the cpu tab, tho I think for x elite windows wont' even boot without
<travmurav[m]>
so I guess just need efi shell now? :D
<macc24>
so far i've seen mtk only in chromebooks, rockchips have pinebook pro, pinetab(and pinetab 2) and chromebooks as well
<travmurav[m]>
(and maybe dump the tcblaunch.exe from the windows install)
<maz>
travmurav[m]: EFI shell indeed
<maz>
it's already there.
<maz>
any concern about disabling secure boot? it's on offer///
<maz>
"This operation disables UEFI secure boot by clearing the Platform Key"
<travmurav[m]>
probably doesn't matter unless there is bitlocker
<travmurav[m]>
as in, you'd probably want to dump some files from windows later
<JensGlathe[m]>
never done this, but always decrypted the Windows disk before tampering with the UEFI settings
<travmurav[m]>
i.e. signed firmware which idk where one'd get now especially since the thing is dead xD
<travmurav[m]>
but disabling uefi SB is defined as deleting the platform key so it's exactly what that button does
<travmurav[m]>
and enabling re-enrolls microsoft key when you do it via the menu xD
<maz>
yeah, I think I'm going to copy the whole nvme device in one swift go...
<maz>
ahahah -- PXE boot is on offer!
<travmurav[m]>
well would be annoying if it's encrypted and tpm state will be destroyed after disabling secure boot
<maz>
yup. not touching secure boot until I've secured the firmware stuff.
echanude has joined #aarch64-laptops
DanaG has quit [Remote host closed the connection]
DanaG has joined #aarch64-laptops
<DanaG>
Hardware secure boot on laptops feels like a "you will own nothing and be happy"
<JensGlathe[m]>
vibe of the times
<robclark>
maz: I haven't tried it but PXE boot does show up as a boot option on my yoga 7x if I have usb-eth plugged in
<travmurav[m]>
maz: I will be off for the night but I hope sltest just works assuming uefi actually sets up the GOP framebuffer that you can see. You may need to use tcblaunch.exe from the windows install on that exact device tho
<DanaG>
Heaven forbid Qualcomm let us run Linux without being inside a dang hypervisor...
<steev>
JensGlathe[m]: some rockchip stuff would be decent as a laptop
<steev>
decent, not zomg
DanaG_ has joined #aarch64-laptops
<freekurt[m]>
I live in Minnesota and we have a law here called Right To Repair. I wonder if people from Minnesota could request datasheets and stuff from Qualcomm in order to allow this community to fix laptops so they work better with Linux.
DanaG has quit [Remote host closed the connection]
<DanaG>
An LX2160A might work in a laptop (I have the Honeycomb dev board), but there are alignment issues with amdgpu, especially with Navi GPUs. The driver fails to load firmware and then goes kaboom with a null assertion due to fragile teardown code.
<HdkR>
^ I hit that, good times
<HdkR>
Hoping NXP will one day put out a new chip with fixed PCIe fabric
<macc24>
<steev> "Jens Glathe: some rockchip stuff..." <- afaik pinetab2(rk356x) is as close as you can get?
<DanaG>
I don't know enough about PCI or how the kernel works to try working around the init failure... I wonder, if we got it to get past the init failure, would userspace running stuff also smack into the same alignment issues?
<HdkR>
There's some kernel patches floating around to add more unaligned fault handlers to the kernel. Don't think it is enough
<maz>
travmurav[m]: stopping for the night, will start playing with slbounce tomorrow, now that I have a way to access external mass storage.
<maz>
getting serial was a good-enough start! :)
srinik has joined #aarch64-laptops
DanaG has quit [Remote host closed the connection]
<HdkR>
If we could get SoCs with CPU cores newer than 2018 that would be greeeat
<macc24>
isn't qcom's oryon fairly recent?
<robclark>
I think he was referring to the imx8 ;-)
<Jasper[m]>
macc24: I think this is in context to alternatives
<HdkR>
Yea
<HdkR>
It's a spicy market with all these CPU cores from 2018 or 2020 :D
DanaG has joined #aarch64-laptops
<steev>
the bigger issue with any of the laptops is what kind of upstream support will they get
<steev>
and will the pinebook pro every not have the massive audio pop
noisycoil[m] has joined #aarch64-laptops
<DanaG>
The LX2160A has proven that even when the product company tries to officially upstream stuff, they can easily get roadblocked forever by upstream.
<macc24>
huh
<steev>
roadblocked in what way? i've only ever experienced it when they ask for changes
<Jasper[m]>
HdkR: How far can we die shrink A53's
<macc24>
lenovo's parts lookup has surprisingly nice photos
<steev>
well.... there was the whole usb thing with the efika
<HdkR>
Jasper[m]: nooooooo
<Jasper[m]>
HdkR: Some consider it a challenge
<Jasper[m]>
How is that core design still alive
<macc24>
Jasper[m]: price?
<Jasper[m]>
We're at A520 these days, A55 is only SLOWLY becoming more commonplace
<HdkR>
At this point A53 has longer legs than A7 and A9 that was zombified for two decades
<pstef>
hmm, running Debian Trixie, 6.10 worked great OOTB, I just upgraded to 6.11 and lost battery status and external monitor. Fetched johalun's 6.12-rc3 WIP, only added btrfs, installed that - and unfortunately still no battery indication or external monitor. pd-mapper service is active running, restarting it didn't change anything. Can't see errors in dmesg about inability to load relevant firmware
<pstef>
I should add, with the kernel upgrade there were other apt package upgrades, but nothing jumps out
<robclark>
pstef: ok.. I think it comes down to driver probe order, and/or whether adsp fw ends up in the initrd
<robclark>
maybe adsp needs to be loaded before pd-mapper, or something like that??
<pstef>
I just realized I never shared any info about HW - it's the x13s. Even more impressive that you knew the exactly right incantation
echanude has quit [Quit: WeeChat 4.3.5]
<robclark>
it's always remoteproc0 ;-)
srinik has quit [Ping timeout: 480 seconds]
crisma has joined #aarch64-laptops
echanude has joined #aarch64-laptops
<JensGlathe[m]>
Thank you for all the links,quite a bit to look at.
<noisycoil[m]>
Hi all!
<noisycoil[m]>
Does anyone know if the x13s has issues booting a 16k-page kernel?
<JensGlathe[m]>
I guess we're lucky with the current gen of x1e laptops. I could very well imagine that Microsoft and Qualcomm sort of part ways due to different expectations and outcomes.
xroumegue has quit [Quit: WeeChat 2.3]
<robclark>
noisycoil[m]: oryon does not support 16k page size, so I wouldn't expect to get very far trying to boot a 16k-page kernel.. 4k and 64k page sizes are supported. (16k pages are optional in aarch64 spec)
xroumegue has joined #aarch64-laptops
<JensGlathe[m]>
This really odd Dev Kit desaster looks like a tell to me that they're not working together like they should.
xroumegue has quit []
<robclark>
JensGlathe[m]: MS has been on this path w/ qcom for, what.. 5yrs+ already? Maybe more..
<noisycoil[m]>
robclark: Thank you. I found some logs around that would suggest that but needed confirmation. freekurt here's your probable culprit. Fixed in the last image
<robclark>
I think the devkit situation is all arrow
<steev>
pstef: yeah, with 6.11, pd-mapper is now a kernel driver, you don't need the userland service, but it would probably be good to put the firmware into the initramfs, on my x13s i have the following intramfs-tools hook https://paste.debian.net/hidden/415fd34f/
xroumegue has joined #aarch64-laptops
<HdkR>
robclark: Since at least 2018 with the Asus Novago and Snapdragon 835
<JensGlathe[m]>
They are selling electronic components, but not manufacturing them.
<Jasper[m]>
HdkR: They had the 820 compute thing earlier
<robclark>
HdkR: ahh, right, I forgot that one.. so yeah, the WoA thing is a long term investment for MS.. and I guess QC too, since it was probably a large part of forking over >$1B to acquire nuvia
<robclark>
so I wouldn't expect either side to just get bored and wander off
<JensGlathe[m]>
All the more odd. IMO. I know MSFT did ARM stuff with TI and then QCOM for a long time. Maybe there were some expectations, and then MSFT botched the launch with this Copilot+ thing instead of doing useful stuff
<pstef>
steev: thanks. I'm not sure this all is needed in the image, seems to work for me without anything like that, sans the issue I mentioned
<HdkR>
Jasper[m]: Ah right, even older
<robclark>
JensGlathe[m]: meh, I think copilot is less the reason for WoA and more just an excuse to generate some PR around the launch, whether it was "botched" or not is mostly irrelevant
<HdkR>
There was also the Tegra 3/4 WoA devices before qcom as well :D
<steev>
pstef: well it's trying to start the remoteproc without the firmware, that's why starting it after booting is fine (because it can find it)
<pstef>
steev: makes sense now, thanks
<steev>
at the end of the day, it's your machine :) an rc.local echoing start works just as easily :D
<pstef>
once I learn how to plug that in, I'm going to follow your advice. Maybe trim some of that firmware that isn't necessary immediately
<steev>
that file just goes into /etc/initramfs-tools/hooks as whatever you wanna call it and mark it as executable; then run update-initramfs -u -k all
<pstef>
great, thank you!
<steev>
(or just specify the 6.11 kernel after the -k)
<DanaG>
Something I noticed with my Surface Pro 11 is that it won't actually do the 4k 120hz output it was advertised as supporting, even with a Thunderbolt 4 dock (CalDigit TS4). I'm wondering whether it's a hardware limitation, a firmware flaw, or a sofware restriction. Once Linux is bootable on it eventually, I should see if the same applies there.
<robclark>
DanaG: IIRC support for switching # of dp lanes is still WIP (and 4k@120 needs more lanes)
jhovold has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
DanaG has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<noisycoil[m]>
Are there known issues with booting a live distro on the x13s using squashfs?
<noisycoil[m]>
I've built some Tails images for that platform and freekurt is unable to boot them on his hardware
<abby>
generally with usb booting you need to prevent a certain module from loading in the initramfs iirc
<noisycoil[m]>
He's seeing squashfs errors which are identical to those you would get if the squashfs was corrupted
<noisycoil[m]>
Can you remember the module? I'm already adding to the command line because of that
<noisycoil[m]>
No, that's just to reduce the size of the initramfs, and Tails' already is as small as possibile
<noisycoil[m]>
*possible
<abby>
no, it's something like qcom_qv5_pas (there's another number in the name)
<freekurt[m]>
Gotcha
<steev>
q6v5
<noisycoil[m]>
abby: You need to disable that?
<abby>
in the initramfs only, as it reinits usb and will make boot fail
<noisycoil[m]>
Ok, let's see if we can make progress with that
cyrinux has quit []
cyrinux has joined #aarch64-laptops
<noisycoil[m]>
IT WORKS!
<noisycoil[m]>
I'm expecting various bugs and shortcomings, but Tails now boots and runs on the x13s
chrisl has joined #aarch64-laptops
<steev>
nice!
<noisycoil[m]>
Thanks a lot abby
<noisycoil[m]>
For some reason ubuntu doesn't use that command line parameter. Have no idea why
chrisl has quit [Ping timeout: 480 seconds]
<steev>
they may exclude the module from the initrd
<noisycoil[m]>
No they don't, quite the contrary, they add it explicitly
<\[m]>
<steev> "at the end of the day, it's your..." <- are you running devuan 😄
<\[m]>
oh initramfs?
<kuruczgy[m]>
<freekurt[m]> "I live in Minnesota and we..." <- Would be cool but I can't imagine qcom giving up datasheets easily, sounds like it would be a multi-year legal battle. Not sure who would have the resources for that. Maybe if you can convince some right to repair advocacy group that x1e datasheets are _that_ important.
<steev>
\[m]: nope, kali (since i'm a kali dev and whatnot)
<noisycoil[m]>
Ah interesting, at some point I also ported kali to bare metal apple silicon
<noisycoil[m]>
But it was just to play around so I'm not actually maintaining it
<steev>
it's not that it's not doable, it's that i'm the only arm person, and i don't have the time to walk people through the install (and at the time, the kernel support was lacking) - as we're getting closer to having everything in debian, i might write it up
<steev>
but i tweaked my back something fierce earlier this week (and my brother is in the hospital) so i've been able to do almost nothing this week, this is the first time i've really sat at the computer all week
sally has quit [Quit: sally]
minecrell has quit [Quit: Ping timeout (120 seconds)]