ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
flowriser has quit [Remote host closed the connection]
FizzBuzz has quit []
<maz>
macc24: no worries. I'll sort this machine myself (it's not like I never ran Linux on chromebooks before). it's just that the idea of a 'distro' that would drop Debian on a brand new crbook without much effort was pretty appealing!
<macc24>
maz: it isn't just debian, voidlinux, archlinux and maybe ubuntu are planned too
<macc24>
and it's not about "without much effort", but rather "run linux as easily as chromeos" and "flex on sbc devs"
flowriser has joined #aarch64-laptops
<maz>
macc24: I only listed the use case I personally care about. I'll go back to doing it my way (boot from USB, install on the MMC using KVM and the Debian installer, fiddle with the kernel boot).
<flowriser>
maz, I actually wonder if going the way of kvm is the best way
<flowriser>
We need the kvm to do the kernel wedge stuff, right?
<flowriser>
I just don't understand why we would need to go through kvm to do kernel wedge when all that kernel wedge does is remove some package info from the build kernel in order to create the udebs
<maz>
flowriser: it may not be "the best way", but it is the way that's easy for me. the the kernel stuff is the one thing that I can't do using the debian installer, since it doesn't understand the chromebook booting protocol.
alyssa has joined #aarch64-laptops
<alyssa>
wp follow_batt_pres (which will tie the write protect line to the battery presence).
<alyssa>
robclark: ^ what does this mean?
<alyssa>
the machine is write-protected unless you physically remove the battery? or unless the device is connected to mains?
<kbingham>
Are the batteries even removable in the chrombooks?
<alyssa>
kbingham: ...anything is removable if you try hard enough? :_p
<kbingham>
haha ;-) Maybe indeed
<kbingham>
Ohh that's confusing. I just ran the cadmium build and plugged in the usb stick to the X2 ... but it takes the host name from my builder so it boots up as if I had a console on my main pc name
<kbingham>
Threw me off for a second ;-)
<kbingham>
uname -m definitely confirms it's not my build machine though ;-)
neobrain has quit [Remote host closed the connection]
<robclark>
alyssa: you can do the ccd open thing to remove fw write protect (this is different from just being in dev mode and removing rootfs write protect) with the battery connected, but it takes ~5min of sitting there hitting the pwr button when prompted.. but removing battery also removes write protect (being connected to mains has nothing to do with it.. other than not much interesting happens with no battery and no mains
<robclark>
connection).. the idea is that if you have the device in your physical possition long enough to do the pwr button dance or remove the battery, then you actually "own" the machine (ie. you are not just an evil maid).. this is the same with at least all modern chromebooks (ie. things new enough not to have wp screw)
<kbingham>
Even in dev-mode I couldn't get the ccd open to run. It kept saying I didnt' have permission. But I haven't needed it open yet so I haven't progressed there.
<kbingham>
Now have debian sid running on the X2 though, thanks to cadmium, definitely some quirks to figure out.
<robclark>
hmm.. well, `ccd open` has always just worked when I've needed it (but I usually don't).. but dianders or amstan probably knows more about that.. possibly there is some flag to make it not possible to open (ie. presumably schools would want to do that for their managed devices?).. idk
<alyssa>
robclark: Ah ha, got it
<alyssa>
I remember removing the physical wp screw on a chromebook years ago.. was a pain though
<dianders>
kbingham: I'm not a huge expert on `ccd open`. I know that there are a whole lot of similar sounding things and it's not always obvious which ones to do, so make sure you really did `ccd open` and not something like `ccd unlock`, which sounds the same but means something different. As Rob says, if you get a device from a school or business it's possible that they've locked down ccd, too...
<kbingham>
alyssa, first guess, because that hit me yesterday: usermod -aG dialout $USER
<kbingham>
newgrp dialout
<alyssa>
kbingham: ah yes it works as root
<alyssa>
...Lol. I don't know why I find dev console over serial on a chromebook so funny but I do
<alyssa>
Life is silly :-D
<alyssa>
laugh!
<alyssa>
I don't suppose depthcharge has any suzyq integration (to load a kernel over usb)
<dianders>
alyssa: no, since that would transfer the kernel at 115200. The way some folks at Google do this is via TFTP. Add a USB-to-Ethernet connector in a different port and install the "dev" or "net" version of depthcharge which can grab the kernel over TFTP. I'm 100% certain amstan will be happy to extol the benefits of this. ;-) At least for Chrome OS kernels there's always the issue w/ TFTP of the modules getting out of sync thu.
<alyssa>
dianders: Oof!
<dianders>
Of course, getting a "dev" or "net" version of depthcharge can get a bit of a pita since they're not officially distributed.
<alyssa>
I'm spoilt by the setup we have for apple silicon
<alyssa>
usb otg support in our bootloader, so can push a kernel over usb (at usb2 speeds)
<alyssa>
("our" = Asahi Linux, not Apple)
<amstan>
otg's usually hit or miss, especially when we need to add hubs in the way to get more external ports
<alyssa>
ah well yes
* alyssa
builds kernel on M1
<alyssa>
this is unreasonably fast
<alyssa>
i usually build kernels on my rk3399 chromebooks :-p
flowriser has quit [Remote host closed the connection]
* alyssa
tries to figure out console= for uart
<alyssa>
amstan: dianders: ^
<alyssa>
for mediatk
<alyssa>
I think it should be ttyS0, but..
<amstan>
sounds about right?
<amstan>
let me check my bash history from when i worked on krane
<alyssa>
thank you
<amstan>
--enable_serial=ttyS0 yep
<alyssa>
so what did I do so broken that I can't even get anything on earlycon! :(
<amstan>
does it beep at you when you try booting from usb? probably packaged the kernel wrong
<alyssa>
No beep
<amstan>
that's the point where i would try getting a depthcharge that's more chatty and see how the dts selection and kernel loading is working
<alyssa>
maybe I'm being too optimistic thinking mainline would have support for serial..
<amstan>
i think it should
<amstan>
krane was pretty upstream happy as well
<alyssa>
Welcome to Debian GNU/Linux bookworm/sid!
<alyssa>
ah ha :-)
* alyssa
wonders why there are random characters missing in the playback of what I type
flowriser has joined #aarch64-laptops
<amstan>
dianders: ;) ^
<dianders>
you mean over CCD?
<amstan>
alyssa: pls do not be surprised if random characters are missing over ccd, it's been like a chronic bug in that stack
<dianders>
It's gotten _much_ better on the latest versions of Cr50
<dianders>
...but that means figuring out how to update it...
<dianders>
Easy if you are booting Chrome OS or if you have a chroot...
<maz>
I get these drops every so often. the fix is always to unplug the SQ and replug it, and it's good again for a while.
<robclark>
I've not noticed drops, or at least not for a long time.. but also I've only used suzyq on qc devices.. (and in case it makes a difference, I usually use kermit, ie `kermit -C "set line $dev, set speed 115200, set flow xon/xoff, set carrier-watch off, set prefixing all, connect"`)
<robclark>
(or I guess ckermit depending on your distro)
<flowriser>
what does "over ccd" mean? :D
<maz>
I use conserver, but I have a pretty weird setup
<robclark>
flowriser: I think he means serial console over suzyq (suzyq and related things are generally called "closed case debugging", ie. ccd)
<flowriser>
robclark, thanks! Are there more general CCD tools? Might come in handy when I get tired of building everything, burning iso to an usb just to see I messed up when I boot that
<flowriser>
or is this only a google chromebook thingy?
<robclark>
It is I suppose more of a chromebook thing.. I'm not aware of any (for ex.) windows laptop that supports it..
<robclark>
it's kinda part of the cr50 (the security chip in chromebooks)
flowriser_ has joined #aarch64-laptops
flowriser has quit [Read error: Connection reset by peer]
flowriser_ has quit [Remote host closed the connection]
flowriser has joined #aarch64-laptops
flowriser has quit [Remote host closed the connection]
flowriser has joined #aarch64-laptops
<alyssa>
Okay, configured ethernet over a usb-c adaptor and then installed ssh (all over serial over suzyq), and now can ssh into the device over a link local link
<alyssa>
....what the F am I doing again? :-p
<amstan>
alyssa: it's so you can put on a new kernel over ethernet that has ethernet drivers compiled in
<alyssa>
no ethernet on this machine :')
<alyssa>
(hence the adaptor)
* alyssa
plays "kernel developer"
<flowriser>
what is the difference between defconfig and distro_defconfig? it seems I need a certain module that is in defconfig but not in distro_defconfig :thinking:
<steev>
distro_defconfig is the config shawn made based on debian's config
<steev>
it has a lot more modules enabled, but not all, obviously
<flowriser>
adding CONFIG_VLAN_8021Q=m now made kernel-wedge work properly on the 5.15 kernel but now I got another very weird issue
<flowriser>
I get "some modules are in more than one package"
* macc24
reads the scrollback
<macc24>
*noted*
<flowriser>
Oh god, it appears some module (debian/nic-usb-modules-5.15.0-rc3-custom-di) is in 2 different .ko files (mdio_devres.ko and selftests.ko)
<flowriser>
I think I should recompile the kernel without selftests maybe
<flowriser>
Are the selftests important?
<macc24>
ooh more kernel talk *grabs popcorn*
<macc24>
keep on talking while i watch ;)
<alyssa>
macc24: r00d
<alyssa>
currently figuring out why the gpu isn't powering on, oh boy.
<macc24>
if only there were kernel patches and config that are known to work reliably on mt8183 chromebooks
<flowriser>
macc24, I kinda like screaming at my screen whenever I notice that I need to recompile the kernel again
<macc24>
flowriser: my average of recompiled kernels per day is like, 10 in 2021?
<macc24>
if not more
<flowriser>
The thing is I also didn't setup caching properly in my docker containers so it is always a full build
<flowriser>
Hopefully I set it up correctly this time
<macc24>
>docker
<flowriser>
I can use buildx to create the debian installer iso for arm64; it could actually work faster than a vm since you wouldn't have to have user input to set the vm up or do the arcane network boot configs for unnatended installs of that iso