<JensGlathe[m]>
There were people who tried this, successfully
<JensGlathe[m]>
And the normal op mode for the Ubuntu ISO is with secure boot (signed kernel with stubble)
<travmurav[m]>
> it's because you can't have secure boot and efi drivers
<travmurav[m]>
You can sign the drivers but can't be sure slbounce is ""secure"" in a sense that there is no unintentional backdoor inbetween whatever slbounce/qhee/mssecapp does, especially given it internally updates tpm in interesting ways
<JensGlathe[m]>
So if it works, it is not secure
<MohamedBana[m]1>
Can you drive an eGPU (on Linux or otherwise) with the Snapdragon X2 Elite?
<travmurav[m]>
well maybe someone can make a guarantee that a specific efi driver is "secure", but for slbounce I can't
<Mis012[m]>
MohamedBana[m]1: with m.2 riser yes, with usb4 only on windows for now
<travmurav[m]>
it may be secure, it may be not
<Mis012[m]>
and only if you have drivers for it obviously
<Mis012[m]>
JensGlathe[m]: only actually secure flow would be having EVERYTHING self-signed, I don't think TME is even dual signed so not sure if you can have shit secured against qcom on modern stuff
<Mis012[m]>
* you can even have shit
<Mis012[m]>
<valpackett> "it seems like qcom (correctly..." <- eh, they hired Hans who is best known for getting ugly hacks for broken ACPI into mainline
<Mis012[m]>
it seems clear they want to use ACPI eventually
<travmurav[m]>
I mean in the end the only way to know everything is secure is to live in a way that the only piece of technology you ever interact with is a shotgun under your pillow while living deep in the woods /s
<Mis012[m]>
* ACPI eventually (but not on googlebooks for sure)
<Mis012[m]>
* ACPI eventually (but not on googlebooks for sure, to be clear)
<Mis012[m]>
well, easier than bootstrapping silicon production from basic principles with a small circle of trusted friends I suppose
<Mis012[m]>
but not the only way :P
<MohamedBana[m]1>
Mis012[m]: LOL!
<Mis012[m]>
and for reasonable levels of security mainly want existing security features but have them actually work in your best interest for a change
<deathmist>
MohamedBana[m]1: tbh when I tried e.g. CS2 I preferred iGPU (was genuinely enjoyable with usual "esports settings" like 1280x1024 low without FSR) than USB4 eGPU because of the 1% lows which just felt bad. if only the useless NPU part of SoC was gone and there was an even bigger iGPU..
<Mis012[m]>
the NPU is probably pretty small considering it's just a small part of the hexagon cores in cDSP?
<Mis012[m]>
but yeah, obviously latency over pcie is worse than with iGPU
<Mis012[m]>
and usb4 is presumably even worse than m.2 riser (or the ideal case of a dGPU on the mainboard)
<Mis012[m]>
also ideally want to use an external monitor
<Mis012[m]>
because otherwise you have extra latency from copying the rendered image back
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<deathmist>
idk if it's just me but on X2E the CPU core clustering seems to cause problems, getting more consistent performance with "taskset -c 6-11" in Minecraft where it's otherwise wildly migrating between the 3 clusters "randomly" causing significant FPS drops and not seemingly wanting to use any of the different ones together
<deathmist>
JensGlathe[m]: they didn't seem to help help with the dock situation at least, but so far I haven't had a freeze+reboot, not sure which they were supposed to help with but I'm not complaining if they unintentially fix the more annoying issue :D
<JensGlathe[m]>
They are for hotplug situations, to bring up the quite sensitive USB and DP blocks in the right order. Helped here to un-quirk the Ideapad Slim5 HDMI port among others.
notHorseface has joined #aarch64-laptops
<JensGlathe[m]>
well, make that "right", I guess you know what I mean
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
dc7800 has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
cow123 has quit [Ping timeout: 480 seconds]
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
Guest15483 is now known as alexeymin
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
Lenni has quit [Quit: Gateway shutdown]
Lenni has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<deathmist>
HdkR: anything in particular you did to get proper CPU perf on Linux? I'm comparing short openssl3 build and I can get WSL even using only the 12 fast cores to beat Linux using all 18. seems to just not be clocking as fast as it should be despite "boost" enable too
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<HdkR>
deathmist: performance governor and enabling the "boost" option because Linux decides to not enable it by default.
<HdkR>
deathmist: Also yes, cpu_capacity problems on X2E exist, currently prime/performance cores aren't described correctly in the DTS, so the kernel doesn't know how to schedule them.
<HdkR>
prime versus performance cores can have up to a 30% perf difference at the same clock speed in my testing.
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<deathmist>
hm no such luck, it was defaulting to ondemand for me but performance or schedutil made no real difference. a few seconds into the built it just drops all cores to somewhere around 2 GHz
<weirdtreething>
fwiw i have several patches on top of that too
<weirdtreething>
perhaps i should push this somewhere
dc7800 has quit [Read error: Connection reset by peer]
<weirdtreething>
on my a16 i have the hdmi port and altdp on both type c ports working
<deathmist>
without replug for type-C? that's one of the more annoying things for me atm especially paired with the random freeze/reboot stuff
<weirdtreething>
wdym replug?
<weirdtreething>
ah yeah the random freeze/reboots seem to be gone for me now
<deathmist>
every time I boot with my dock plugged in I won't get video out until I replug it after every reboot
<weirdtreething>
oh i never tested with the hub plugged in at boot
<deathmist>
tbf a bunch of my problems could be because of .config and excluding modules from initramfs, idk I don't even have display for FDE unlock but laptop keyboard/USB etc have worked anyway
<weirdtreething>
right i had to add several modules to my initramfs to get a display
<deathmist>
apparently I'm even missing all qcom firmware from there now looking closer, classic. maybe I should've reused my X1E configs/hooks
<HdkR>
anthony25: Maybe sending an MR to enable boost by default will get some opinions generated :D
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Remote host closed the connection]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
FANTOM has quit [Read error: Connection reset by peer]
FANTOM has joined #aarch64-laptops
FANTOM has quit [Ping timeout: 480 seconds]
FANTOM has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
FANTOM has quit [Ping timeout: 480 seconds]
dlezcano has quit [Read error: Connection reset by peer]
dlezcano has joined #aarch64-laptops
FANTOM has joined #aarch64-laptops
cow123 has joined #aarch64-laptops
dlezcano_ has joined #aarch64-laptops
FANTOM has quit [Ping timeout: 480 seconds]
dlezcano has quit [Ping timeout: 480 seconds]
FANTOM has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ has quit [Ping timeout: 480 seconds]
kalebris has joined #aarch64-laptops
notHorseface has quit [Ping timeout: 480 seconds]
FANTOM has quit [Ping timeout: 480 seconds]
FANTOM has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
FANTOM has quit [Ping timeout: 480 seconds]
FANTOM has joined #aarch64-laptops
<MohamedBana[m]1>
Has anyone seena USB-C to USB-C null modem cable before?
<penguin42[m]>
Mohamed BanaI just used a standard usb-c - usb-c cable
<MohamedBana[m]1>
penguin42 What about the chip - FTDI?
<MohamedBana[m]1>
I am trying to get a serial console into another machine that doesn't have a native serial console.
<MohamedBana[m]1>
s/console/port/
<penguin42[m]>
Mohamed BanaAh that's different from my case - I was doing networking between two machines
<JensGlathe[m]>
but not too far away IMO. You need OTG on the target that does the cdc serial via USB
<penguin42[m]>
Jens GlatheWell not necessarily - I think that device that Mohamed Banafound has two usb->serial devices with the cross over on the serial side
<penguin42[m]>
If you have OTG/device mode available then you should be able to use the gadget-serial driver and a standard c-c cable
<JensGlathe[m]>
yes
<JensGlathe[m]>
like the rpi does
<penguin42[m]>
Mohamed BanaWhy don't you just get a pair of usb serial adapters and wire the serial side ?
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
<penguin42[m]>
Hmph, someone just posted a set of USB4/thunderbolt stuff for the Apple M series - hope qualcomm stuff catches up!
<MohamedBana[m]1>
penguin42: I don't think I've seen it done. I was searching around on how to turn the several ESP32 into a virtual serial device that the kernel thinks is there, but I couldn't find anything.
<penguin42[m]>
Mohamed BanaOh that should be doable, the ESP32 can do device mode - I've got one set up as a HID device
<Mis012[m]>
<MohamedBana[m]1> "Has anyone seena USB-C to USB-..." <- does neither device support gadget mode?
<Mis012[m]>
but this is basically just two usb UART controllers on the same PCB
<Mis012[m]>
can achieve same thing with both sided header pins
<Mis012[m]>
* header pins and two normal UART controllers
<Mis012[m]>
* header pins and two normal USB UART controllers
<JensGlathe[m]>
When you swith the dwc3 controller to gadget (otg) mode it should work, too.
<Mis012[m]>
well, if at least one device has DRD then obviously you should do that
<penguin42[m]>
one problem I've found though is that, certainly on this snapdragon, I can't configure a gadget until the other device is switched on; which means you can't catch stuff right at the start
<Mis012[m]>
well, technically the other device should be the one in gadget mode?
<Mis012[m]>
but in either case I assume to catch everything you need to buffer everything that gets printed before the console shows up
<penguin42[m]>
Mis012Nah like if I want to make it so the other device sees a USB HID as soon as it's switched on, I want my snapdragon to be sitting with a hid gadget set up on it as soon as the other machine switches on
<Mis012[m]>
HID?
<penguin42[m]>
keyboard/mouse/etc
<penguin42[m]>
Mis012But even for serial
<penguin42[m]>
Mis012There's no UDC visible on my snapdragon until the other machine powers up, and you can't bind a gadget without a UDC
<Mis012[m]>
interesting
<penguin42[m]>
Mis012Which also means I can't try sending a 'power on' key press!
<Mis012[m]>
well, that wouldn't do anything?
<Mis012[m]>
if the usb link is not up
<penguin42[m]>
it does on some USB keyboards doesn't it?
<Mis012[m]>
not if the usb link isn't up clearly
<penguin42[m]>
I assume it polls or something?
<Mis012[m]>
would need to be out of band special fuckery with D+ and D-
<MohamedBana[m]1>
Mis012 The devices are; pc that I want to get a serial console on, and a laptop that I will use to view the console logs. So both in host mode, I think.
<Mis012[m]>
Mis012[m]: so even if it exists and I never heard of it, it would be out of the scope of UDC
<penguin42[m]>
Mohamed BanaYeh just get a pair of normal USB-serial adapters and wire the serial side together
<Mis012[m]>
MohamedBana[m]1: what SoC
<Mis012[m]>
qcom intel amd?
<Mis012[m]>
two of those three have DRD
<Mis012[m]>
so unless you have the lucky combination of both devices being AMD...
<Mis012[m]>
I guess not all intels have DRD
<Mis012[m]>
but more than AMDs by a lot
<penguin42[m]>
(Does anyone know if it's possible to get serial or debug out of grub on the snapdragons booted through efi ?)
<Mis012[m]>
I'm only aware of steamdeck
<Mis012[m]>
penguin42[m]: without custom fuckery? no way
<MohamedBana[m]1>
Mis012: Both are Intel, but I do have an AMD gaming laptop as well that I could possiblly check.
<penguin42[m]>
Mis012Bah, too easy
<Mis012[m]>
Mohamed Bana: check if one of your Intel SoCs supports device mode
<Mis012[m]>
I think they call it xDCI
<Mis012[m]>
if it's supported, I will refer you to nergzd723 who has used it before :P
<penguin42[m]>
still sounds like your easiest way is a pair of cheap USB-serial adapters and 3 wires
<Mis012[m]>
penguin42[m]: but that requires buying stuff
<nergzd723>
I think all Intel stuff has DRD
<nergzd723>
At the very least all mobile stuff
<Mis012[m]>
didn't we find that it's actually not that common on desktop?
<nergzd723>
Mis012[m]: Well e.g. Kaby Lake also has it, both mobile and desktop
<nergzd723>
but enabling it is sort of a pain with the hidden efi settings, etc
<Mis012[m]>
Mis012[m]: and waiting for it to ship
<nergzd723>
And is specific to device so its sad
<Mis012[m]>
nergzd723: well, those just fiddle some register somewhere presumably
<Mis012[m]>
and coreboot might just document which one :P