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
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
Lucanis has quit [Ping timeout: 480 seconds]
malvi[m]1 has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
jenneron[m] has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
KREYREN_oftc has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
PterKoczka[m] has joined #aarch64-laptops
svarbanov_ has quit [Ping timeout: 480 seconds]
nekogirl[m] has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
Prawn[m]1 has joined #aarch64-laptops
enick_50 has joined #aarch64-laptops
<steev> hm, although now, that patch might be dropped?
<steev> afaik, the mic has **not** been working (properly) at all on the X13s; when i try to use armcord and go into voice chat, i'm told that i sound like 'hot trash' or 'a robot with hiccups'
<jglathe_x13s> I've seen Ubuntu update alsa-ucm-conf last night
<jglathe_x13s> it says 1.2.9-1ubuntu3.2
<jglathe_x13s> but I have sound
<steev> what does the changelog say?
<jglathe_x13s> how do I check
<steev> they may be applying the patches based on that "ubuntu3.2" part
<steev> usually it's somewher ein /usr/share/doc/pkgname/
<steev> or you'd have to check their git repo
<jglathe_x13s> d/p/0001-ucm2-Qualcomm-sc8280xp-fix-device-numbers.patch
<jglathe_x13s> - ucm2: Qualcomm: sc8280xp: fix device numbers
jglathe_x13s has quit [Remote host closed the connection]
<steev> that bug # would tell you what all is what
Sobek[m] has joined #aarch64-laptops
jglathe_x13s has joined #aarch64-laptops
<jglathe_x13s> rebooted, sound is still there.
<jglathe_x13s> _[m]123 do you have the remoteproc firmwares in your initrd? Was the problem for enyalios
<jglathe_x13s> travmurav[m] sltest on my X13s worked, green line.
sz3m3k[m] has joined #aarch64-laptops
travmurav has joined #aarch64-laptops
<travmurav> jglathe_x13s nice
<travmurav> jglathe_x13s does lxc imply a container or a real vm though? ;D
<jglathe_x13s> real vm
<travmurav> cool
<jglathe_x13s> had to enable CONFIG_VIRTUALIZATION in the kernel, and did your stress-ng test for fun
<jglathe_x13s> it takes all the performace cores then
<travmurav> yeah, I was just trying to show that on the host the cpu load accounts as "guest"
<jglathe_x13s> yep
<jglathe_x13s> trange colour here, but different than the other loads
<travmurav> but I suppose it makes sense it would schedule the sustained load on perf cores first so it gets done with earlier
<jglathe_x13s> yeah the scheduler does that
<jglathe_x13s> nice
<jglathe_x13s> what would be the next steps to get that IOMMU going
<travmurav> I've heard there is someone with insight into the hw who was interested in making it work
<travmurav> but otherwise would be nice to have logs on how linux dies when touching that iommu
<travmurav> to see if i.e. it's defined wrong
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<jglathe_x13s> the vid of it booting and dying with IOMMU available https://drive.google.com/file/d/11Z6q6mvxMtPQNCSqI7tI2nog3MRLskYv/view?usp=sharing
<travmurav> oh interesting
<jglathe_x13s> can you get a still of the last flash?
<travmurav> there are only 4 uninteresting lines after the smmu messages
<travmurav> but smmu messages themselves are "good" I think
<travmurav> I think that message means "something tried to use memory" (something == nvme just few lines above)
<travmurav> but linux doesn't know that it should use this iommu to allow DMA
<jglathe_x13s> yeah I can remember seeing that kind of messages early in May '23. Kernel parameter? Like iommu.strict=0
<travmurav> not even strict, probably need to force passthrough
<travmurav> the correct way of fixing it would be to link pcie to iommu
<jglathe_x13s> but that should be in the sc8280xp.dtsi anyway, I guess?
<travmurav> but I think linux sees the smmuv3 properly at least
<travmurav> well yes but the problem would be that we can't touch it in el1 and having links defined in base dtsi would probably result in defers with "normal" boot
<travmurav> what I'd do right now is create some sc8280xp-el2.dtsi, include it in your device and have that one set status=okay for that iommu + define iommu props for pcie in it (could also /delete-node/ for zap shader)
valida-69[m] has joined #aarch64-laptops
* travmurav tries to look into the smmuv3 spec
iivanov has joined #aarch64-laptops
iivanov has quit []
jhovold has joined #aarch64-laptops
clover[m] has joined #aarch64-laptops
<jglathe_x13s> we're on EL2, so a specific dtsi (for now) would be the way to make it work. There will be more, like loading the remoteproc FW
<travmurav> Ideally I think that dtsi can get converted to an dt overlay one could load to a device
<travmurav> ah and also I mean a dtsi that extends the soc one, not a changed copy of the soc dtsi
<travmurav> so later it would be clear what specific changes are required for el2
<travmurav> oh hm
<jglathe_x13s> yeah, I guess for the time being it would be a specific dts and dtsi, and when it works refactor to a more palatable form
<travmurav> jglathe_x13s can you try adding "iommu-map = <0x0 &pcie_smmu 0x0 0x10000>;" and add a "pcie_smmu:" label to the smmuv3?
<travmurav> not sure if the map is exactly correct but who knows what happens haha
<travmurav> jglathe_x13s as in, add iommu-map to the pcie
<travmurav> to the pcie that is used by nvme
<jglathe_x13s> ok I try
<travmurav> pcie2a I guess
<travmurav> might want to kill pcie 3a and 4 for now too
KREYREN_oftc has joined #aarch64-laptops
<jglathe_x13s> the nvme is pcie2b. the root port is pcie2a no idea if they are distinguished, would also try pcie2a first
iivanov has joined #aarch64-laptops
<travmurav> tbh I'd expect one would need to add iommu-map to all pcies but I'm not sure if and how the offset and size should be adjusted for them
* travmurav haven't had any pcie-enabled device to play with
<jglathe_x13s> need to do some wage slaving for now, its Monday
xroumegue has quit [Ping timeout: 480 seconds]
<jhovold> steev: you broke peoples audio by pulling in a random patch from the mailing list which was never needed for the X13s and which was rejected upstream
<jhovold> what's the point of running stable kernels if you add random stuff like that on top?
xroumegue has joined #aarch64-laptops
<jhovold> regarding the analog microphone; that one too is working ok just as the dmic
<jhovold> as I've mentione before, and as I've documented in the wiki, playback and *capture* is broken with pipewire
<jhovold> you can switch to pulseaudio as a workaround
<jhovold> the pipewire issue appears to be a generic problem with the qualcomm sound driver
<jhovold> I've asked srini too look into it, I'm done with audio for while
patzek[m] has joined #aarch64-laptops
<jhovold> jglathe_x13s: pcie2a and pcie2b are two separate controllers
<jhovold> when you use the nvme in four-lane mode as we do on the x13s, the pcie2b lanes are used by pcie2a
iivanov has quit [Remote host closed the connection]
<jhovold> so you should most likely never use the 2b and 3b nodes
LoganLeland[m] has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
<jglathe_sdbox2> ok, so the iommu-map goes to the a nodes if that works
Nao[m] has joined #aarch64-laptops
<jhovold> right
<jhovold> (it's really a single controller, but it can be used in either 4-lane mode or as two (logical) 2-lane controllers)
Khaldee906[m] has joined #aarch64-laptops
abcdw has quit [Read error: Connection reset by peer]
abcdw has joined #aarch64-laptops
<jhovold> Here's an updated wip branch for the X13s:
<jhovold> Changes include:
<jhovold> - fix PCIe ASPM deadlock (regression in 6.7-final)
<jhovold> - fix potential drm prime deadlock
martiert has quit [Quit: WeeChat 4.2.1]
owc[m] has joined #aarch64-laptops
matthew[m]12 has joined #aarch64-laptops
Stirl[m] has joined #aarch64-laptops
mynery[m] has joined #aarch64-laptops
Las[m] has joined #aarch64-laptops
harvestz[m] has joined #aarch64-laptops
Leandro[m]1 has joined #aarch64-laptops
martiert has joined #aarch64-laptops
averyfreeman[m] has joined #aarch64-laptops
baspar[m] has joined #aarch64-laptops
freekurt[m] has joined #aarch64-laptops
qzed has joined #aarch64-laptops
qzed is now known as Guest1707
NomadNaomie[m] has joined #aarch64-laptops
LikeNeosMatrix[m] has joined #aarch64-laptops
albsen[m] has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<steev> jhovold: well gnome has seemed to gone deep into pipewire so removing it, removes gnome
<jhovold> steev: ok, yeah, i think the pipewire issue should be prioritised, unfortuantely i have a lot of other high prio things on my list
<steev> i'm not asking you to prio it, i just want working audio :) and i assumed, wrongly, that krzk patch was correct and would be accepted
<jhovold> and we have a workaround, use pulseaudio, which should work for most folks (i hope)
<jhovold> steev: yeah, i know, ideally srini should fix this but he is busy with other things
<krzk> steev: the DTS patch, just like corresponding driver change, requires changes in mixer settings, so if you did not update them, it should make things worse :/
<steev> it's already not working so
<steev> can't really be worse :)
<jhovold> it's working for folks with pulseaudio, so you definitely broke things
<krzk> steev: hm, ok, I had impression microphones are working fine in general (except of course some of user-space plumbing)
<jhovold> and we have a workaround for pipewire playback (reducing the quantum size)
<jhovold> so it's really mostly, recording with pipewire that is completly borked
<steev> apparently microphones are working fine, as long as you don't use a modern linux desktop
<jhovold> yeah, tell that to srini, it's a generic qualcomm audio stack issue
<jhovold> as i told, i agree that it should be prioritised
<steev> so, i need to drop that patch, but also there should be some alsa ucm config changes too?
<steev> because without, i get the snd-sc8280xp sound: ASoC: Failed to add route ADC2_OUTPUT -> TX SWR_ADC1(*)
<steev> but i'm just using alsa-ucm-conf git, no extra patches on top
<jhovold> drop those two-three patches that messed with the audio route (beacuse it was needed for some *other* soc, not x13s)
<jhovold> it's the other patches, which never should have been merged
<jhovold> to your "stable" branches, I mean
<steev> got it
travmurav[m] has joined #aarch64-laptops
travmurav has quit [Quit: travmurav]
<steev> Pushed out the 6.7.3, dropping the breaking patches clover[m] sorry about that (and others who use it)
<steev> In my defense, they’re only called stable because that’s what they are based on.
<jglathe_sdbox2> steev: hmm rebase shows me 5 commits. all 5 out, or are there also new ones? https://drive.google.com/file/d/1cltpwfPVSUDcTNvCVc8M1LGaubXs_qfL/view?usp=sharing
<steev> just dropped
<maz> jglathe_sdbox2: out of curiosity, what is the HW you managed to get EL2 on?
<travmurav[m]> I think at this point we confirmed both volterra and x13s as well as a bunch of devices on other socs
<jglathe_sdbox2> maz: Volterra aka windows Dev Kit 2023.
<jglathe_sdbox2> On Volterra its not catastrophic if the remoteprocs don't work yet.
<travmurav[m]> as in "get el2" afaik is confirmed on sd850, sc7180, sc8180x, sc8280xp, "booting linux in el2" is a bit less
<jglathe_sdbox2> steev: all 5, wow
<steev> it was a patch and the dependencies
<jglathe_sdbox2> okay
<maz> travmurav[m]: sure. except that as far as I remember, there was no way to run *anything* at EL2 on non-chromebook QC HW.
<travmurav[m]> maz: well now there is :P
<jglathe_sdbox2> that appears to have changed
<travmurav[m]> at least on everything that is in today's retail and runs windows
<maz> maybe my C630 will stop collecting dust then...
<jglathe_sdbox2> Linux sdbox2 6.7.3-EL2+ #5 SMP PREEMPT Sun Feb 4 19:47:39 CET 2024 aarch64 aarch64 aarch64 GNU/Linux
<travmurav[m]> (idk if qcom/ms now decides to change the protocol for exelite)
<maz> is there any place where this is documented one way or another?
<travmurav[m]> https://github.com/TravMurav/slbounce and the old SL writeup (linked in theory of operations)
<maz> cheers.
<jglathe_sdbox2> current state of hackery on the linux side is here https://github.com/jglathe/linux_ms_dev_kit/tree/jg/el2-hackery
<maz> thanks. I don't see much in terms of code change on the linux side, so I assume most of the trickery is on the EFI side and the interaction with the existing firmware?
<travmurav[m]> maz: linux needs few changes in places that used proprietary hyp before, otherwise yes - it's just doing some magic before booting linux (or other os)
<travmurav[m]> i.e. on sc8280xp we need to enable and manage the pcie iommu ourselves (hyp was doing(forcing passthrough?) that before)
<travmurav[m]> on all platforms we need to kill the zap shader and boot remoteprocs in a different way too, since hyp was involved before
<travmurav[m]> those are main changes I think
<maz> right. so this is basically restoring sanity on the platform after some other agent messed with everything. In a way, that's pretty similar to what Linux would do before performing a kexec.
<maz> in any case, cool piece of work!
<ardb> yeah very nice!
<Libre___> nice to see linux on the dev kit, it's been staring at me from my shelf for too long so I should get on using it
martiert has quit [Ping timeout: 480 seconds]
jglathe_sdbox2 has quit [Remote host closed the connection]
mothenjoyer69 has joined #aarch64-laptops
janrinze has joined #aarch64-laptops
<janrinze> Finally bit the bullet and got a Aarch64 laptop. Configured it it boot from USB/SDcard. Built the kernel for the MT8195 (It's a HP Chromebook x360 13) and did all the cgpt stuff on the SDcard but no boot. Need some help.
<jenneron[m]> janrinze: if you're okay with Alpine linux, i'm working on a port for pmOS for mt8192/mt8195
<jenneron[m]> i can build an image for mt8195 and send it
jglathe_sdbox2 has joined #aarch64-laptops
<janrinze> jenneron[m]: thanks. Let's take a few small steps first.
<jenneron[m]> i'm not sure what you mean
<jenneron[m]> it would be enough to flash an image to SD or USB with dd and try booting it
<janrinze> jenneron[m]: Okay, let's have a try with that.
<jenneron[m]> i was told that it works on mt8192, but would be cool to test mt8195 as well and fix if there are some problems
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_sdbox2 has joined #aarch64-laptops
<janrinze> jenneron[m]: It's been ages since i built kernels for Chromebooks. There are a few steps required to make a kernel usable for chromebooks and I need to look for my old build scripts. (Last one was for the Acer CB511..)
<janrinze> jenneron[m]: But those script might not be compatible with the latest chromebooks anyway.
<jenneron[m]> i'm building an image right now
<janrinze> thanks
wiizzard has joined #aarch64-laptops
<travmurav[m]> does sc8280xp supposed to have pcie1a/b too given the first one is 2?
push_ has joined #aarch64-laptops
push has quit [Read error: Connection reset by peer]
<jhovold> travmurav[m]: it has pcie0 and pcie1, they are not used currently
<travmurav[m]> ah cool, was just looking into acpi to find the iommu mappings
<jhovold> for usb4, supposedly not used on windows either
<travmurav[m]> and saw there are 7 not 5 of them :D
<jenneron[m]> janrinze: the image http://185.235.217.31/google-cherry.img
<jenneron[m]> (download from my PC directly)
<jenneron[m]> hopefully it will just work after flashing to SD/USB
<jglathe_sdbox2> hmm travmurav[m] tried iommu-map = <0x0 &pcie_smmu 0x0 0x10000> and iommus = <&pcie_smmu 0x0>; no success. Same lines as in the vid
<jenneron[m]> and booting with Ctrl+U
<travmurav[m]> jglathe_sdbox2: I'm looking into the acpi, will try to suggest something in a moment
<travmurav[m]> jglathe_sdbox2: iommu-map = <0x0 &pcie_smmu 0x20000 0x10000>; for nvme and 2 == linux,pci-domain = <2>;
<travmurav[m]> I thiiink this is what acpi tells me
<travmurav[m]> and so pcie 0006 (pcie4) would have offset 0x40000
Guest1707 is now known as qzed
<jglathe_sdbox2> lets start with one working
<travmurav[m]> konradybcio: I think hyp kills the config, it for sure messes with that smmu on handover
<janrinze> jenneron[m]: Let's see if that image boots.
martiert has joined #aarch64-laptops
<clover[m]> pushed 6.7.3 to my arch repo. audio working just fine here. thanks steev
<travmurav[m]> travmurav[m]: I missed my num row here and didn't see, 0x60000
<travmurav[m]> ah, I just confused myself with the dtsi name vs real name while having multiple chat threads I guess
<jglathe_sdbox2> hmm
<jglathe_sdbox2> linux,pci-domain = <2> is already there
<travmurav[m]> yes, you put 2 into iommu-map as 0x20000 (third number)
<travmurav[m]> so for domain=6 you put 0x60000
<janrinze> jenneron[m]: it says no valid image detected
<jenneron[m]> hm?
<jenneron[m]> can you show partition table on flashed storage?
<janrinze> cgpt show /dev/sdc
<janrinze> 1 1 Pri GPT header
<janrinze> start size part contents
<janrinze> 0 1 PMBR
<janrinze> 2 32 Pri GPT table
<janrinze> 8192 262144 1 Label: "pmOS_kernel"
<janrinze> Type: ChromeOS kernel
<janrinze> UUID: 0CBE305D-E26A-2246-9087-B87F96F4B620
<janrinze> Attr: priority=9 tries=1 successful=0
<janrinze> 270336 524288 2 Label: "pmOS_boot"
<janrinze> Type: EFI System Partition
<janrinze> UUID: A41E7A7B-8321-D74B-A173-13BAC6C92A38
<janrinze> 794624 3676127 3 Label: "pmOS_root"
<janrinze> Type: Basic data
<janrinze> UUID: 90C57D43-C2D7-FF45-9D74-5B98B9D1E1E4
<janrinze> 250347487 32 Sec GPT table
<janrinze> 250347519 1 Sec GPT header
<jenneron[m]> ok, maybe you can send a picture of the error?
<jenneron[m]> i don't think i have ever seen that one
firlaev-hans-fiete[m] has joined #aarch64-laptops
<janrinze> OOh.. i have changed from SD card to USB stick and now it does boot.
<janrinze> But the boot says Error: boot partition not found.
<janrinze> below that the postmarketos troubleshooting URL and below that the kernel 6.7.0-rc8-next-20240103 | Google Cherry
<janrinze> jenneron[m]: looks like it is getting somewhere
<jenneron[m]> meh
<jenneron[m]> probably needs some USB modules in initramfs
<janrinze> No idea why it doesn't like booting from the SDcard.
<jenneron[m]> i actually don't know how to get those until someone boots from another storage and runs lsmod with and without USB connected
<jenneron[m]> yeah it should boot form SD card as well
<jenneron[m]> from
<jenneron[m]> another thing that might happen is failing USB in kernel, but i'm not sure
<jenneron[m]> it's quite difficult to guess
<janrinze> does it require firmware?
<jenneron[m]> i don't think USB does
<janrinze> A sufficiently 'able' initrd might help.
<janrinze> like dropping into a shell.
<jenneron[m]> i can make one
<jenneron[m]> but first i want to take a few guesses and look what modules might be required in initramfs
<janrinze> do you have a link for building this myself? I'd like to be able te reproduce.
<jenneron[m]> yeah just created it
<travmurav[m]> jglathe_sdbox2: I was reading the docs a bit more and if the other suggestion doesn't work (which I now guess it won't), you can try "iommu-map = <0x20000 &pcie_smmu 0x20000 0x10000>"
<travmurav[m]> and redact both 0x20000 according to the pcie bus number for each pcie
<jenneron[m]> janrinze: the source is at https://gitlab.com/postmarketOS/pmaports/-/tree/jenneron/mt81xx?ref_type=heads, you need pmbootstrap to build from it
<jenneron[m]> you can run pmbootstrap init, when it clones pmaports abort it, then go to ~/.local/var/pmbootstrap/cache_git/pmaports, then git checkout jenneron/mt81xx, then pmbootstrap init again, and you can select "google" as manufacturer and "cherry" as codename
<jenneron[m]> then you can do pmbootstrap install --sdcard /dev/sdX to install it
<jenneron[m]> that's very briefly
<jenneron[m]> this is our kernel config currently https://dpaste.com//B8VLFP3Y7
<janrinze> okay. Got the repo, did checkout of jenneron/mt81xx
<jenneron[m]> janrinze: if you want to modify cmdline or initramfs modules you need 1) modify https://gitlab.com/postmarketOS/pmaports/-/blob/jenneron/mt81xx/device/testing/device-google-cherry/deviceinfo?ref_type=heads#L20 or https://gitlab.com/postmarketOS/pmaports/-/blob/jenneron/mt81xx/device/testing/device-google-cherry/modules-initfs?ref_type=heads 2) pmbootstrap checksum device-google-cherry 3) pmbootstrap pkgrel_bump device-google-cherry
<jenneron[m]> 4) pmbootstrap build device-google-cherry
<jenneron[m]> you need checksum on second step because files change their checksum when modified, third step because it is a package and it will rebuild only if it is newer, fourth step actually builds stuff
jglathe_sdbox2 has quit [Remote host closed the connection]
<jenneron[m]> very briefly, again
<jenneron[m]> let me know if you have any questions
<janrinze> you are using pmbootstrap version 1.50.1, but version 1.53.0 is required. :-(
<jenneron[m]> janrinze: i think what you want to do is to set cmdline to `console=tty1 PMOS_NOSPLASH PMOS_NO_OUTPUT_REDIRECT`. this will give you kmsg logs on screen instead of splash screen
<jenneron[m]> janrinze: you can clone https://gitlab.com/postmarketOS/pmbootstrap and use pmbootstrap.py
<jenneron[m]> janrinze: mt8192 guy uses USB for booting, so i think initramfs modules should be fine..
szclsya[m] has joined #aarch64-laptops
jglathe_sdbox2 has joined #aarch64-laptops
<janrinze> jenneron[m]: I'm on Debina 12. Updating to 12.4 now so i hope all is well after that. Will reboot and connect here soon(ish)
<janrinze> LOL.. Debian 12
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_sdbox2 has joined #aarch64-laptops
<jglathe_sdbox2> Ooh, need to verify
jglathe_sdbox2 has quit [Remote host closed the connection]
janrinze has quit [Quit: Leaving.]
janrinze has joined #aarch64-laptops
jglathe_sdbox2 has joined #aarch64-laptops
<janrinze> Okay, rebooted and now have a new kernel on my M1 and of course: pmbootstrap --version
<janrinze> 1.50.1
<jglathe_sdbox2> travmurav[m] something has changed with "iommu-map = <0x0 &pcie_smmu 0x20000 0x10000>;"
<jglathe_sdbox2> other signal, running further, but not booting up as it seems. Shot a vid, need to upload
iivanov has quit [Remote host closed the connection]
<jenneron[m]> janrinze: just clone it from git
<jglathe_sdbox2> i have only mapped pcie2a now, to not muddy things
<jglathe_sdbox2> with 0x20000 &pcie_smmu 0x20000 0x10000 its the same as before
jglathe_sdbox2 has quit [Remote host closed the connection]
<travmurav[m]> jglathe_sdbox2: hm same as the first one or new same?
jglathe_sdbox2 has joined #aarch64-laptops
<jglathe_sdbox2> Same as the first vid from this morning
<travmurav[m]> Interesting
<jglathe_sdbox2> sorta.
<travmurav[m]> Uh, which node are you adding it to?
<jglathe_sdbox2> signal 10 received was what I've seen
<jglathe_sdbox2> pcie2a
<travmurav[m]> (just making sure not phy)
<janrinze> pmbootstrap --version
<janrinze> 2.1.0
<janrinze> Better..
<travmurav[m]> Hm
<jglathe_sdbox2> pushed to jg/el2-hackery, sc8280xp.dtsi
<jglathe_sdbox2> vid follows
<janrinze> pmbootstrap status
<janrinze> [19:45:36] User Interface: lxqt
<janrinze> [19:45:36] Device: google-cherry (aarch64, "Google Cherry Chromebook")
<janrinze> [19:45:36] *** CONFIG ***
<janrinze> [19:45:36]
<janrinze> [19:45:36] *** GIT REPOS ***
<janrinze> [19:45:36] Path: /home/janrinze/.local/var/pmbootstrap/cache_git
<janrinze> [19:45:36] - pmaports (jenneron/mt81xx)
<janrinze> [19:45:36]
<janrinze> [19:45:36] *** CHECKS ***
<janrinze> [19:45:36] [NOK] pmaports: not on official channel branch
<janrinze> [19:45:36]
<janrinze> [19:45:36] *** CHECKLIST ***
<janrinze> [19:45:36] - pmaports: consider checking out: master, v23.12, v23.06, v22.12, v22.06, v21.12, v21.06, v21.03, v20.05
<jenneron[m]> should be fine?
<travmurav[m]> jglathe_sdbox2: 0x10 is worse I think
<travmurav[m]> I suggest using my last suggestion but adding to all pcie nodes (adjusting for the bus number)
<travmurav[m]> since I'd guess it's event 2 but for other pcie
<travmurav[m]> (need to see the fault to say)
<jglathe_x13s> might look into the dtsi and check for iommu-map
<travmurav[m]> jglathe_x13s: I don't understand the need to comment out unused ufs iommus but the pcie ones look correct to me, I suggest uncommentign all and trying to boot
<janrinze> jenneron[m]: looks like it uses all 20 cores to build \o/
<travmurav[m]> jglathe_x13s: ah, "uncomment all and fix pcie 2a according to the same scheme"
<janrinze> jenneron[m]: build done, copying to sdcard is the slowest part :-D
<janrinze> jenneron[m]: reproduced the situation.
<jenneron[m]> janrinze: you can install on USB
<jglathe_x13s> yeah but that failed, strangely
<jenneron[m]> better modify cmdline to print logs
<travmurav[m]> jglathe_x13s: on that vid nvme clearly worked
<travmurav[m]> but ugh
<travmurav[m]> hm did it
<travmurav[m]> not sure why translation fault happened for it ugh
<travmurav[m]> jglathe_x13s: is this with 0x0 as the first value?
<jglathe_x13s> yeah, that's the astonishing part
<travmurav[m]> weird
* travmurav[m] thought he understood the documentation
<jglathe_x13s> maybe iommus = <&pcie_smmu 0x20000>; or sth like that as direct assignment, although the offset may be 0 or something really odd
<travmurav[m]> do you happen to have a vid for the one with non-zero first value?
<travmurav[m]> no, that's not correct since we assign a range to all possible pcie devices not a single stream to the pcie controller
<janrinze> jenneron[m]: No idea what changed but the SDcard now boots into Alpine Linux.
<janrinze> \o/
<travmurav[m]> ugh
<jglathe_x13s> I can do, original recording failed
<jglathe_x13s> but it looket like signal 2 twice
<jenneron[m]> janrinze: interesting
<jenneron[m]> what about USB storage when booted from SD?
* travmurav[m] takes out his calculator
<janrinze> from USB it's a no go.
<janrinze> jenneron[m]: From the console I can see USB when plugging in a USB disk.
<janrinze> So USB works.
<travmurav[m]> jglathe_x13s: can you try first value being 0x200 (for bus 2) and all other the same
<janrinze> jenneron[m]: X won't start though.
dcavalca has joined #aarch64-laptops
<jenneron[m]> janrinze: try connecting to wifi, then `apk add soc-mediatek-mt8183` and reboot
<jenneron[m]> check if x11 startx
<jenneron[m]> starts
<jenneron[m]> i'm wondering if it needs the same configs
<jenneron[m]> you can connect with nmtui or sudo nmtui
* travmurav[m] is very not sure if he calculated the offsets properly as it's late for him to do things like this already
<jglathe_x13s> I'll try
<jglathe_x13s> only pcie2a for the try
<janrinze> jenneron[m]: \o/ the apk worked. Now see X desktop!!
<jglathe_x13s> one try left for today
jglathe_sdbox2 has quit [Remote host closed the connection]
<janrinze> jenneron[m] is building kernels from the laptop easier? I mean I don't need to rebuild an entire disk image again, right?
<travmurav[m]> for pmos, as long as you have network on the device, you can cross-compile with pmbootstrap and send the apk to the device automatically
<travmurav[m]> probably much faster than building the kernel on the device itself
<travmurav[m]> (see pmbootstrap sideload <package> --host <ip>)
jglathe_sdbox2 has joined #aarch64-laptops
<jglathe_sdbox2> Hmm as I said, signal 2 twice. Vid follows
konradybcio has joined #aarch64-laptops
<jglathe_x13s> what i've seen is that of complains about missing translations for 0x0 and 0x100
<jglathe_x13s> maybe we need a more complex declaration. Or, reading the driver source for smmu-v3
<jenneron[m]> janrinze: you can bump pkgrel or pkgver at kernel, then do `pmbootstrap sideload linux-postmarketos-mediatek-mt81xx --host <your wifi ip address>`. you might need --install-key for the first time
<jenneron[m]> i'm not sure it's what you want though
<jenneron[m]> do this after building the package
<travmurav[m]> jglathe_x13s: hmm I guess I misunderstood how it would count the offsets and first value as 0x0 is correct then
<jenneron[m]> janrinze: why do you need to rebuild kernel btw,
<jenneron[m]> ?
<travmurav[m]> then I guess translation fault (0x10) is some other fun issue
<jglathe_x13s> enumerating pcie buses?
<jglathe_x13s> nah, enumerating some slots in the iommu... its hard wired
<travmurav[m]> jglathe_x13s: I guess then for the next time you'd be interested in poking at this, I'd suggest setting first value as 0x0, setting all other as is and configuring the map for all pcie controllers to see if maybe this helps it boot further and not die
* travmurav[m] has no idea why the system would die in that state
konradybcio has quit []
<jglathe_x13s> maybe its just zombie, and I could ssh into it. Will try tomorrow.
<jglathe_x13s> thanks for working on it
<janrinze> jenneron[m]: I need a few different kernel settings to try out.
<janrinze> jenneron[m]: Normally I would use make menuconfig to do my tweaks.
<jglathe_x13s> will try this
<janrinze> jenneron[m]: Call me oldschool ;-) I'm looking where the kernel sources are and have trouble finding it. These build environments are pretty complex.
<janrinze> jenneron[m]: pmbootstrap kconfig edit linux-postmarketos-mediatek-mt81xx should do it, right?
EricCurtin[m] has joined #aarch64-laptops
<janrinze> travmurav[m]: after 'pmbootstrap kconfig edit linux-postmarketos-mediatek-mt81xx' and 'pmbootstrap build --force linux-postmarketos-mediatek-mt81xx' it rebuilt but apparently decided to overwrite the config to the default again, So i have a new kernel but not with my config chages..
<janrinze> Okay, how do I avoid pmbootstrap from reverting my changes?
<janrinze> I folowed https://wiki.postmarketos.org/wiki/Kernel_configuration but apparently this guide is not complete, the config will be overwritten and 'pmbootstrap kconfig edit linux-postmarketos-mediatek-mt81xx' reloads the entire kernel config. So I cannot see may changes afterwards either.
KREYREN_ has joined #aarch64-laptops
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<janrinze> jenneron[m]: Why does building the kernel revert my changes during the build process?
<jenneron[m]> janrinze: can you upload the output of git diff in pmaports directory?
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<janrinze> git diff is empty.
<janrinze> jenneron[m]: which explains the issue.
steevdave[m] has joined #aarch64-laptops
<janrinze> I think I have trouble understanding the pmbootstrap build process
sally[m]123 has joined #aarch64-laptops
lun[m] has joined #aarch64-laptops
<jenneron[m]> <janrinze> "I think I have trouble understan..." <- you change build instructions in pmaports
<jenneron[m]> pmbootstrap builds a package only when build instructions are "newer"
<jenneron[m]> "newer" means higher pkgver + pkgrel in APKBUILD
<janrinze> where do I find the build instructions for the kernel?
<janrinze> 'pmbootstrap kconfig edit linux-postmarketos-mediatek-mt81xx' unpacks the kernel sources and configures the kernel. Then it starts `make menuconfig`. All that looks perfectly fine. However when the buildprocess is started the .config is not used.
<jenneron[m]> janrinze: oh sorry.. this is based on my branch that completely reworks all this stuff
<jenneron[m]> what you're trying to do is the way, but not in my branch
<jenneron[m]> janrinze: you should go to device/testing/linux-postmarketos-mediatek-mt81xx, add .config fragment, add it to APKBUILD and bump pkgrel
<janrinze> jenneron[m]: Ah. then it makes sense.
<jenneron[m]> i'm surprised you figured that much about pmbootstrap etc in one evening using my drunk explanations
<jenneron[m]> and this problem was not supposed to happen to you
<janrinze> jenneron[m]: I'm more a debian person but I learn quickly ;-)
<janrinze> debian has its own quirks ;-)
<jenneron[m]> btw what are you trying to add to kernel?
<jenneron[m]> i'm just curious
<jenneron[m]> and i'm curious because i'm wondering if you're trying to add something that will be useful for other mt8192/mt8195 users or overall
<janrinze> Oh, I'm trying to enable running RISCOS under Linux.
<janrinze> https://github.com/TimothyEBaldwin/RISC_OS_Linux_Binary/tree/master has a binary if you want to try it yourself ;-)
<janrinze> It runs a 32 bit app with some peculiar requirements
<janrinze> if you try the binary you will see an error.
<jenneron[m]> janrinze: note that alpine uses musl instead of glibc so you may not be able to run some random binaries
<janrinze> jenneron[m]: This is static compiled.
<jenneron[m]> janrinze: what does it need from kernel? qemu?
<janrinze> Nope memory management and 32 bit support
<jenneron[m]> huh i see
<janrinze> firstly 4k pages (already in your kernel) Seccomp BPF, some others
jhovold has quit [Ping timeout: 480 seconds]
enserzo[m] has joined #aarch64-laptops
emily[m]1 has joined #aarch64-laptops
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #aarch64-laptops
DocGalaxyBlock[m] has joined #aarch64-laptops
KREYREN_oftc has joined #aarch64-laptops
KREYREN_ has quit []
<janrinze> jenneron[m]: Thanks for helping to get me started. I'm not familiar with alpine Linux and will have a look at how I can get debian running.
Bioxvirizm-x13s[m] has joined #aarch64-laptops
<janrinze> jenneron[m]: The trick to get your image to boot is to once trying it to boot over USB (I have a USB SDcard reader) and reinsert when it looks for an image. Then it will fail loading the rootfs. Remove card and insert in SDcard slot, reboot and voila, the image will boot.
Dantheman825[m] has joined #aarch64-laptops
<jenneron[m]> janrinze: meeeeh
<jenneron[m]> please boot from SD card and check if USB storage works when booted
<jenneron[m]> if yes, please send me lsmod with and without USB storage inserted
<janrinze> what's the password for the 'Linux User' ? :-D
<jenneron[m]> oh lol, 147147 or 115963
<janrinze> jenneron[m]: the image boots all the way to the desktop and now i can also login. I saw it also resizes the rootfs during bootup
<jenneron[m]> yeah
<jenneron[m]> if storage works when it is booted we can make it boot properly
<jenneron[m]> i'm also planning to add support for having multiple kernels in pmOS, so people will be able to build an additional kernel locally and use it, but we're not there yet
<janrinze> actually it is in a very Fancy desktop a.t.m.
<jenneron[m]> does USB work after booting though?
<janrinze> I'm not that fast ;-)
<jenneron[m]> i should be more patient, heh
<janrinze> yup works.
<janrinze> Oh, you mean booting from USB?
<jenneron[m]> no
<jenneron[m]> i mean booting with your workaround and checking USB storage in booted system
<janrinze> USB storage is accessible. I plugged in a USB stick (had to find one that does not have important stuff on it) and can see the files.
<jenneron[m]> if it works i want the output of lsmod command with and without USB storage inserted. this should help me to fix USB booting properly
<jenneron[m]> also dmesg would be useful
<jenneron[m]> the easiest way to upload is wgetpaste (use apk add wgetpaste)
<janrinze> jenneron[m]: good news, no difference in lsmod before and after inserting USB stick.
<jenneron[m]> hmm, i don't see it being a good new..
<jenneron[m]> i have one more thing to try though
<janrinze> jenneron[m]: dmesg is also very 'normal' recognises the superspeed USB without any issues
<jenneron[m]> janrinze: open /etc/deviceinfo with text editor, uncomment cmdline append variable and set it to `console=tty1 PMOS_NOSPLASH`
<jenneron[m]> then save it and run sudo mkinitfs
<jenneron[m]> on next reboot you should see kernel logs instead of splash screen
<jenneron[m]> and please upload dmesg and lsmod, it still can be useful for me to fix it
<janrinze> jenneron[m]: https://pastebin.com/9wsfctU9
<janrinze> do those pastebins work for you?
<jenneron[m]> thanks!
<jenneron[m]> yes
<jenneron[m]> janrinze: could you also try modifying cmdline the way above and booting from USB? i'm wondering if we get anything useful in kmsg log
<janrinze> Already did that but was side tracked. :D
<janrinze> why are we using busybox?
<jenneron[m]> do i correctly understand that you have LAN adapter connected to USB?
<janrinze> yup
<jenneron[m]> i can see this recognized even before running /init
<jenneron[m]> so usb should be fine
<janrinze> yeah
<jenneron[m]> it is possible that USB takes too long to initialize
<jenneron[m]> *USB storage
<janrinze> if so, add rootwait
<jenneron[m]> it uses initramfs, so not really
<jenneron[m]> i have a MR to fix these cases https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4775
<janrinze> google-cherry:~# shutdown -h now
<janrinze> -sh: shutdown: not found
<janrinze> really..
<jenneron[m]> i can build an image with these changes tomorrow if you have a possibility to test it
<janrinze> sure.
<jenneron[m]> janrinze: you can install it i think https://pkgs.alpinelinux.org/contents?file=shutdown&path=&name=&branch=edge
<jenneron[m]> and yeah alpine uses busybox utils by default, it makes system very small. if these utilities are not functional enough you still can install normal utils
<janrinze> busybox is nice. I need tar with xattrs so it's a bit too limited for me.
<janrinze> how do I give it a proper shutdown? there is no 'leave' or anything in the desktop..
<janrinze> found it.. need to search
<jenneron[m]> janrinze: i'm sorry if it becomes too annoying for you, but i have one more thing to try.. try connecting USB storage to another port (where you have your LAN adapter) if you haven't tried it before
<janrinze> ooh lovelym got boot with console now.
<jenneron[m]> it seems that LAN adapter is connected to a USB bus directly, but another USB port (where USB storage is connected) is actually through USB hub, so it may take more time to initialize and it may be a problem
<janrinze> and yes, booting takes forever now.
<jenneron[m]> janrinze: anything useful? :P
<janrinze> not yet..
<janrinze> massstorage was not seen.
<janrinze> unplugged and replugged now it sees it but probably too late.
<jenneron[m]> interesting
<janrinze> yeah, it is definitely not happy booting from USB. 'cannot enable, Maybe the USB cable is bad?'
<jenneron[m]> so it is kernel problem
<jenneron[m]> is it the same from another USB port?
<janrinze> let's try a different USB stick.