ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
geertu has quit [Ping timeout: 256 seconds]
geertu has joined #armlinux
apritzel has quit [Ping timeout: 248 seconds]
wolfshappen has quit [Ping timeout: 252 seconds]
wolfshappen has joined #armlinux
macromorgan has joined #armlinux
bochenchen has joined #armlinux
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #armlinux
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #armlinux
alpernebbi has quit [Ping timeout: 248 seconds]
alpernebbi has joined #armlinux
amitk has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 248 seconds]
frieder has joined #armlinux
Pali has joined #armlinux
mcoquelin has joined #armlinux
iivanov has joined #armlinux
wens has quit [Ping timeout: 255 seconds]
wens has joined #armlinux
viorel1 has joined #armlinux
viorel1 has quit [Quit: WeeChat 3.5]
viorel1 has joined #armlinux
viorel1 is now known as viorel_suman
headless has joined #armlinux
frieder has quit [Ping timeout: 248 seconds]
frieder has joined #armlinux
Pali has quit [Ping timeout: 256 seconds]
monstr has joined #armlinux
luispm has joined #armlinux
matthias_bgg has joined #armlinux
matthiasbgg[m] has joined #armlinux
shawnguo has joined #armlinux
apritzel has joined #armlinux
nsaenz has joined #armlinux
headless has quit [Quit: Konversation terminated!]
frieder has quit [Ping timeout: 255 seconds]
frieder has joined #armlinux
Amit_T has joined #armlinux
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
<Xogium>
okay, newb question... What does the kernel do if it can't find a console ? I'm trying to boot without having usb gadget serial console plugged in, but doing that hangs the whole boot a little bit after init starts
<Xogium>
far from the stage of launching any login prompt
<Xogium>
the last line I see is systemd[1]: detected architecture arm.
<Xogium>
I boot with a real uart attached, not serial console, I leave that usb socket empty
<Xogium>
*not usb serial console, sorry
<Xogium>
I wonder if that comes from the kernel or if its init that's somehow freezing the entire boot because it doesn't find the tty. Crazy weird. Tty only appears when I plug in a cable
<Xogium>
but I mean finding boot or not I should see something like start job running for getty ttyGS0 is running or something
<Xogium>
er finding the console
<Xogium>
but here it just stops
<robmur01>
if you've got as far as systemd then it's unlikely that the kernel itself is unhappy
<Xogium>
robmur01: what I thought too
<Xogium>
hrm this is dumb
<Xogium>
dumb and weird
<Xogium>
I've never seen something like that before
<Xogium>
even if it was waiting for that tty to show up it should have prited this on ttyS0
<Xogium>
but... nop. Its not even getting ready to start up units by this point
<Xogium>
*printed
<robmur01>
empirically, adding a completely made-up "console=ttyGS7" after my existing UART and VT consoles makes zero difference to my board
<Xogium>
I know right ?
<Xogium>
could it be a hardware bug ? Somehow
<Xogium>
I'm assuming you use maybe another init though ?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
jeeeun4 is now known as jeeeun
NipunGupta has joined #armlinux
NipunGupta has quit [Quit: Client closed]
nsaenz has quit [Quit: Leaving]
agherzan has joined #armlinux
<agherzan>
Hi everyone. I have question about ACPI support in arm64. I have worked on integrating EFI boot with qemu arm64 using the EDK2 project. And almost everything works as expected with the exception of the fact that without CONFIG_ACPI, the platform wouldn't boot at all.
<agherzan>
Now, CONFIG_EFI arm64 selects ARCH_SUPPORTS_ACPI but CONFIG_ACPI only defaults to y for x86
<ardb>
(btw you realise those patches are 4+ years old right?)
<agherzan>
So my question is, would there be any reason not to have CONFIG_ACPI enabled on arm64 as a dependency of CONFIG_EFI?
<ardb>
yes
<agherzan>
Or even default to y on arm64 on CONFIG_ACPI
<ardb>
EFI boot supports both ACPI and DT boot
<ardb>
did you try running qemu with -no-acpi?
<agherzan>
I was thinking of that but would it break to have it enabled on platforms that are not ACPI-based?
<agherzan>
for example u-boot
<ardb>
it wouldn't break no
<agherzan>
But on the other hand it will fix boots by default for acpi-only boot
<agherzan>
So I'm wondering why wouldn't such a default make sense
<Xogium>
uefi and acpi on arm...
<ardb>
the defconfig enables CONFIG_ACPI
* Xogium
shudders
<broonie>
agherzan: defconfig already has ACPI
monstr has quit [Remote host closed the connection]
<ardb>
if you are not using the defconfig, you are expected to know what you are doing
<agherzan>
I see. That makes sense.
<broonie>
There's a goal to get EFI widely adopted for Arm, but we don't want ACPI on large swathes of the systems out there because they just aren't designed to run it and cause terrible problems with assumptions it makes.
<broonie>
(ACPI itself is a perfectly reasonable interface so long as you use it with systems designed to run it)
<Xogium>
tbh I've got real bad experience with uefi but that's due to x86... I'm a little bit scared of it turning as messy on arm
<agherzan>
Right - that's what I was looking for. To know that this is not wanted as it is a known issue on some systems
<Xogium>
as for acpi, I'll take device trees over that any day
<broonie>
Xogium: u-boot implements a subset of EFI functionality so you'd best start avoiding that :P
<ardb>
Xogium: i take it you work in the embedded space?
<Xogium>
ardb: yeah, both for my own amusement and work
<ardb>
yeah ACPI does not make a lot of sense there
<Xogium>
I suppose on servers it would
<ardb>
absolutely
<agherzan>
This was super useful. Thanks a bunch for taking the time to clarify this for me
<ardb>
agherzan: yw
<Xogium>
but yeah uefi in general pretty much pissed me off on x86, both due to the implementions from one vendor to the next not being standard when, as far as I'm aware uefi means its supposed to be unified and hence standard but... If they want to play it that way, fine
frieder has quit [Remote host closed the connection]
<ardb>
Xogium: UEFI on x86 is a mess because PC vendors only care about the WIndows sticker
<ardb>
not about actual spec compliance
<Xogium>
I had to fight to disable secure boot on my machine because the linux distro I wanted to use had no secure boot support, and that was a nightmare. So I was like, hey, lets use shim, and it has a mode to let you boot up unsigned images, you boot debian or something then you set a password you have to type at the shim prompt for unlock and...
<ardb>
we are seeing the same issues with the WoA laptops
<ardb>
shim != uefi
<ardb>
far from it
<Xogium>
and then I realized that shim asks you for random letters of the password and went like, bloody hell you're kidding me
<ardb>
i have been fighting tooth and nail to get the distros to make shim at least optional
<broonie>
Windows having decided board files are great and idiomatic has done a lot of damage to ACPI.
<ardb>
but apparently, they want things to be exactly like x86
<Xogium>
yeah but the whole point of trying to use shim was to bypass the fact that I couldn't disable secure boot in my bloody uefi bios because not accessible
<ardb>
you should blame your vendor for that
<Xogium>
oh sure
<ardb>
the easiest way to comply with the MS requirements si to remove the 'off' switch
<Xogium>
but then again you might as well blame every vendor
<Xogium>
not accessible as in, the bios doesn't have a screen reader
<Xogium>
as for shim, it doesn't either and the random letters of the password pissed me off
<ardb>
iirc shim does have an 'off' switch
<ardb>
anyway, you get my point
<Xogium>
yeah, but to access that you have to set a password... Which shim will then ask you but each letter in a random order
<ardb>
there are *many* things wrong with the UEFI spec, with the UEFI forum, and with the reference implementation
<ardb>
but none of those are to blame for these usability problems
<Xogium>
but if it doesn't talk then how could I know it is in fact asking me for the third symbol in my defined password
<ardb>
i had no idea shim worked like that
<Xogium>
yeah its horrible. I opened an issue on their repo and they basically told me to fsck off
<ardb>
or what the pointof that is
<Xogium>
rude
<Xogium>
so yeah I got confused by uefi a lot, and I'm a littlbe bit scared it would end up the same way on arm one of these days
<Xogium>
that it would end up having a bios a la x86, all that...
<ardb>
as i said, the arm64 laptops that were built to run windows are basically in the same situation
<ardb>
but it is the same problem: the vendors only care about running windows, and if their code violates the UEFI spec, they don't care as long as windows boots
<ardb>
they typically use the reference implementation but with their own 'value add'
<ardb>
(best euphemism in computer tech by far)
<ardb>
and that is where things usually break
<Xogium>
I see
<Xogium>
makes more sense
<broonie>
ardb: Plus Windows forces ACPI and the chips people already have just aren't intended to work with ACPI which makes everything worse.
<ardb>
broonie: true
<Xogium>
honestly, if I could, I'd switch to arm as my daily driver and would get rid of every x86 machine around the place
<Xogium>
:D
<ardb>
i've been using arm64 machines for hacking exclusively for 5+ years now
<Xogium>
but as it is I can't, mainly because I need a powerful machine for my work, ryzen 7 / 9 kind of powerful, and to my knowledge arm isn't quite up to that level just yet
<ardb>
i have a thunderx2 workstation
<Xogium>
that's cheating ! :p
<ardb>
i know :-)
<robmur01>
Ampere Altra boxes are probably the thing to look for these days, but bring $$$
<ardb>
interestingly, microsoft's uefi requirements for server systems are much more rigorous
amitk has quit [Ping timeout: 252 seconds]
<ardb>
especially for the ones they might be interested in using in their own cloud
headless has joined #armlinux
amitk has joined #armlinux
<broonie>
I suspect with the current laptops it does come down to the availability of suitable chips in combination with the ACPI requirements.
<Xogium>
yeah... here I spent 1300 euros or so with the help of a friend on a 32 gb ram, ryzen 7 3700x, 2 tb nvme build... Makes you wonder what I could have gotten for that price in the arm world, eh
<robmur01>
the WoA laptop segment will be a lot more interesting if it ever becomes more than just a single SoC vendor doing most of the firmware work and hiding the rest in their drivers
<Xogium>
yeah :/
<robmur01>
at least it's doing a passable impression of "real" ACPI
<Xogium>
I'm not considering the pine64 laptop in there, btw
<Xogium>
from what I gathered its as messy as the rest of vendors, they don't focus on upstreaming