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)
leezu has quit [Ping timeout: 480 seconds]
leezu has joined #aarch64-laptops
leezu has quit [Quit: WeeChat 3.0]
leezu has joined #aarch64-laptops
<steev>
1604 held the line. No storm here, just nice “cool” weather
klardotsh has quit [Ping timeout: 480 seconds]
<steev>
okay it looks like, with qzed's changes... it's not fully booting, and it's also not writing whatever part is booting, to the journal
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
SallyAhaj has quit [Ping timeout: 480 seconds]
SallyAhaj has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<robclark>
steev: maybe you need to turn your rpi4 upside-down? :-P
<steev>
nah, looks like it's an issue withthat one, unfortunately, grabbed one of my other ones and it's fine
<steev>
oops, forgot to plug the flex in last night
matthias_bgg has quit []
<robclark>
I guess you found out what the battery life is like?
<steev>
it's not great, but not terrible
<bamse>
steev: i just boot tested my sc8180x tree and hit the rcu stall on the second attempt
<steev>
yeah, it doesn't happen every boot
<bamse>
pretty certain that disabling pcie helps
<steev>
ohh storm might finally hit here
<steev>
just heard some rumbling
<bamse>
didn't know we're getting another one, nice
<bamse>
got plenty of rain here yesterday...so the lawn is almost green again
<steev>
definitely not green here
<steev>
but the rain would be welcome, if it shows up
<bamse>
radar indicates that you have rain down in your area...and there might be a quick shower here later
<steev>
also, i'm not sure disabling pcie would be good as a workaround since the spx uses pcie, even if we don't
<bamse>
probably that enourmous cloud i have outside the window...
<bamse>
steev: no no, we shouldn't work around it...we should fix it!
<steev>
yeah! although i can live with the stalls at boot time... without video output is a little more difficult, on a laptop
<qzed>
are those even real stalls or just those "expedited" things? because I think those are just warnings that things take a little longer than they maybe should
<bamse>
qzed: i think they are a sign that one of the cpus are stuck in secure world, because we did something bad
<qzed>
ah okay
<bamse>
qzed: e.g. hit a trap because we tried to access some unclocked bus or such...
<bamse>
although many of those typically restarts the system
<qzed>
yeah, I mean those are usually hard stalls
<bamse>
or you get them because you have disabled interrupts for ever
<qzed>
(from my very limited experience)
<qzed>
as far as I can tell the expedited thing is just a "warning, things take longer than they should but if the real stall warning doesn't kick in things still progress"
<bamse>
we don't HAVE_HARDLOCKUP_DETECTOR_PERF so we can't enable "Detect Hard Lockups"...and hence this is probably the way you spot them
<qzed>
I've just set CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=250 for now (250ms) and they're pretty much gone for me
<qzed>
i mean yeah, ideally things wouldn't just halt for a couple ms, but then again I also have no clue how long RCU usually takes to progress
<bamse>
hmm, well there's different kinds of rcu stalls
<bamse>
booting again to check which one this is
<qzed>
yeah, thats what I meant with that "expedited" thing vs "hard", because I've seen the expedited a lot when I was experimenting with linux-next until I set the config, but the others only if I screwed up something
<bamse>
ohh, "self-detected stall"...so i presume the core is still up and running...
<steev>
oh yeah, definitely
<steev>
gonna storm here
<steev>
RIP my kernel compile that was going
<bamse>
steev: that's why you need an x13s
<steev>
you didn't pull any strings and now i have to wait on lenovo to figure something out :(
<steev>
though i am watching the ml for the v2 of the dts
<bamse>
the x13s dts?
<steev>
yeah
<steev>
john hovoland(i think?) said they were gonna send a v2
<bamse>
there's a v2 of the dtsi and v3 of the dts
<bamse>
johan hovold
<steev>
hm, i don't see them in patchwork
<bamse>
i got some feedback on the dtsi, so i was updating that right now...and then planning to merge that with johan's dts patch
<steev>
ooh, weird
<bamse>
it's in my inbox at least
<steev>
yeah i see it now
<steev>
i'm blind :)
<steev>
lets see if i can pwcli before the lightning takes out my power
<bamse>
the pcie interrupts are wrong in sc8180x.dtsi...
<steev>
that could be an issue
<qzed>
could that also be responsible for hot-plug command timeouts?
<bamse>
perhaps
<bamse>
hmm, maybe not...depending on how you read the documentation...
<steev>
i do not miss having to interpret documentation
<bamse>
it beats not having documentation ;)
<bamse>
now i at least only have 2 possible values
<qzed>
cross-match with ACPI and you'll have 3 :P
<bamse>
damn i wish that wasn't true :)
<qzed>
in other news: I finally figured out why the redhat grub patches won't boot on the spx
<qzed>
plain grub loads the kernel via a uefi boot-service call
<qzed>
rh patches allocate some memory and jump into that
<qzed>
but turns out... that memory is allocated as data-type, not code-type
<qzed>
and the spx seems to be pretty much the only device on this planet that actually enforces memory protection?!
<bamse>
hehe, nice
<qzed>
the funny thing is, there's even a fairly recent commit from rh that addresses this... for i386
<qzed>
now I just need to figure out how to submit that...
<bamse>
but is this a rh commit? or have they stuck with some old stuff?
<qzed>
it's redhat introducing some loader thing (I assume for secureboot)
<bamse>
looks conceptually like a very sensible change
user0815 has joined #aarch64-laptops
<qzed>
yeah, I mean the main difference between upstream grub and rh grub seems to be that upstream loads the kernel as efi image via the LoadImage boot service, whereas rh loads the kernel in memory and then jumps to the entry point for the efi stub
<qzed>
nothing wrong with that
<qzed>
just that when they allocate the pages to store the kernel into, they use non-executable ones...
user0815 has quit []
jhovold has quit [Ping timeout: 480 seconds]
<javierm>
qzed: interesting, so doing a s/GRUB_EFI_LOADER_DATA/GRUB_EFI_LOADER_CODE makes it work ?
<javierm>
and yes, that custom EFI loader is used to call to the shim_lock protocol
<javierm>
mainline grub2 now has a shim_lock verifier but it still doesn't have feature parity with the SB rh downstream patches (which are also used by most distros that support SB)
<qzed>
thanks! knew it had something to do with secureboot/shim, but I know pretty much nothing specific
<javierm>
qzed: yeah, and also the fact that rh grub uses the x86 EFI handover protocol (2.11 here https://docs.kernel.org/x86/boot.html) while upstream grub doesn't support it yet
iivanov has quit [Remote host closed the connection]
<qzed>
I've opened a PR
<javierm>
qzed: cool, I've pinged the fedora/rhel grub package maintainers
<qzed>
oh neat, thanks!
<javierm>
qzed: I've added a comment in your PR though, I believe that would be better to change grub_efi_allocate_any_pages() instead
<qzed>
right, I think that's sensible if it's only used for code allocation anyways
<qzed>
I can have a look at that
<javierm>
qzed: please double check, I haven't looked at the grub code for some time so maybe I'm misremembering :)
<qzed>
at it right now :)
<javierm>
great, thanks :)
<javierm>
qzed: you have reached the limits of my EFI knowledge, now I'm not sure which grub_efi_memory_type value should be used
<javierm>
qzed: so... according that table I would say that EFI_RUNTIME_SERVICES_CODE isn't the right value but instead GRUB_EFI_LOADER_CODE as in your patch
<javierm>
since the kernel is more of an EFI application than an EFI driver
<qzed>
yeah, I'd argue the same, but I don't know if there are other implications at play
<javierm>
me neither, I don't even understand why they make a distinction between the two
<qzed>
I've read that there is some difference between the types with what happens after ExitBootServices
<qzed>
table 30
<qzed>
for EfiRuntimeServicesCode: The memory in this range is to be preserved by the UEFI OS loader and OS in
<qzed>
the working and ACPI S1–S3 states.
<qzed>
so maybe the reason is to ensure the kernel stays? I have honestly no clue
<javierm>
qzed: but isn't that only for the Linux EFI stub? And the kernel runs with its own memory mapping, not the one provided by the EFI firmware
<qzed>
yeah
<qzed>
I mean I think so...
<javierm>
yeah, dunno. Let's see what they say, I guess in practice doesn't make that much difference
<qzed>
sounds like a good plan :)
<javierm>
I mean... it has been using _DATA until now
<qzed>
right
<qzed>
according to the table the implications between the major types (EFI_LOADER_x) are pretty much the same
<javierm>
maybe is your machine firmware misinterpreting the spec? I don't really know...
<qzed>
no idea
<javierm>
qzed: leaving for today. I think pjones is on PTO but if he doesn't answer in a few days let me know and I can ping him again (I also work at rh)
<qzed>
thanks! no need to rush
<javierm>
qzed: yw! good night
<qzed>
good night!
<bamse>
steev: so what path did we conclude the firmware files for a laptop should live in?
iivanov has joined #aarch64-laptops
<steev>
bamse: i dunno - the aarch64-laptops installer throws them into qcom/MANUF/DEVICEID
<steev>
well, firmware installer script
<steev>
but when you submitted it upstream (i think you did?) it's just in qcom/board/
<bamse>
i was planning not to make that mistake again
iivanov has quit [Ping timeout: 480 seconds]
<steev>
i think we did manuf/devid because of the signed firmwares not being compatible across the board
<bamse>
well, if we've decided on the manuf/devid
<bamse>
right, and the qcom/platform/ thing works fine for the engineering firmware/boards