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/
<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>
- 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.
<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
<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]>
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]>
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
<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
<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
<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>
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
<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..
<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?