cornu has quit [Read error: Connection reset by peer]
dtz has quit [Write error: Connection reset by peer]
leonardp has quit [Write error: Connection reset by peer]
gmr has quit [Read error: Connection reset by peer]
colemickens has quit [Write error: Connection reset by peer]
yangm has quit [Write error: Connection reset by peer]
Ericson2314 has quit [Write error: Connection reset by peer]
goibhniu has quit [Write error: Connection reset by peer]
bqy has quit [Remote host closed the connection]
hpfr[m] has quit [Write error: Connection reset by peer]
JJJollyjim has quit [Write error: Connection reset by peer]
hsngrmpf[m] has quit [Remote host closed the connection]
codyopel has quit [Write error: Connection reset by peer]
Amanda has joined #nixos-aarch64
Amanda is now known as Guest65220
danielrf[m] has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
comrandroxaos[m] has joined #nixos-aarch64
cornu has joined #nixos-aarch64
matthewbauer has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
bqy has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
theotherjimmy[m] has joined #nixos-aarch64
yangm has joined #nixos-aarch64
AberDerBart[m] has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
Jake[m] has joined #nixos-aarch64
goibhniu has joined #nixos-aarch64
dtz has joined #nixos-aarch64
hpfr[m] has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
marius851000[m] has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
gmr has joined #nixos-aarch64
hsngrmpf[m] has joined #nixos-aarch64
Ke has joined #nixos-aarch64
kgtzy[m] has joined #nixos-aarch64
kai_w has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
edrex has joined #nixos-aarch64
colemickens has joined #nixos-aarch64
bigvalen[m] has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
<samueldr>
hmmm... the UEFI NixOS iso (with proper kernel) is booting on the PBP, but there's no graphics :/
<samueldr>
I wonder if it's efifb causing some trouble
<samueldr>
something to look into at a later time, I also need to test whether grub on the iso should work graphically or not
<samueldr>
because I know the installed grub on my pinebook (a64) is graphical
<samueldr>
heh, forgot grub is generic, I can just boot it
<samueldr>
it wasn't graphical
<samueldr>
anyway, looks like I'm not installing UEFI yet as grub reading the files (AFAIUI) takes quite a long time
<samueldr>
not sure where the fault lies
<samueldr>
it could be coming from the fact it's usb though
<samueldr>
nope, took a long time from SD too
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<danielrf[m]>
samueldr: It would take a surprisingly long time for my PBP to load into systemd-boot as well. Even on the emmc. Maybe an extra 10 seconds or so
<danielrf[m]>
with ueif + systemd-boot the display would only work like 10-20% of the time anyway
<samueldr>
so it must be u-boot
<danielrf[m]>
i'd presume so
<samueldr>
display with linux?
<samueldr>
that's with 5.4 that you tested (or the workaround)?
<danielrf[m]>
yeah--the systemd-boot display work 1/2-way work, but usually no output when loading linux
<danielrf[m]>
this was with 5.4
<samueldr>
right, I tested only two boots
<samueldr>
OH, it could be because of the device tree
<danielrf[m]>
I might try the workaround later to see if that helps any
<samueldr>
as I didn't, you probably didn't put an FDT for u-boot in the ESP
<danielrf[m]>
yeah, i didn't do anything extra like that
<samueldr>
right, so it's booting with u-boot's built-in FDT rather than whatever linux fancies
<samueldr>
(ugh)
<samueldr>
I had completely forgotten about that
<samueldr>
and that basically kills good uefi booting
<samueldr>
at least with the concept of generations
<samueldr>
at least until a solution is found that allows us to load an FDT per-generation-per-board
<samueldr>
(in my opinion, this should be part of the kernel's job)
<samueldr>
I recently realised (but learned less recently) that the kernel can load multiple initrds
<clever>
i cant see how that would work
<samueldr>
why?
<clever>
the kernel needs the dtb, to know how to even access storage media
<clever>
it needs dtb to even know what ram is safe to use
<samueldr>
that assumes that it needs to read the storage media
<samueldr>
what if instead ALL FDTs were loaded into memory?
<clever>
you could give it many dtb inside the initrd...
<samueldr>
and we assume the board's basic FDT is good enough for ram
<clever>
but you still need to give it a bare one, defining ram
<clever>
yeah, that could work
<samueldr>
because it's basically bogus that the kernel is the gatekeeper of the "one true FDTs", but pushes the task to the bootloaders
<clever>
my gut feeling, is that the dtb is the responsibility of the bootloader/firmware
<clever>
and it should be tied to the hw, and never change
<samueldr>
unless you absentmindedly think that the only usage of linux with device trees is to make custom golden builds for embedded~ish use and not universal builds
<samueldr>
clever: that's it
<samueldr>
that's what it should be
<samueldr>
but the kernel does not agree :)
<clever>
but even in the rpi, you have problems like nodes describing how to talk to the firmware
<samueldr>
and that's the issue, the board's FDT should be enough to let the kernel somehow load the FDTs it so desires
<clever>
for most hw like a phone or tablet, there is no variant in the hw
<clever>
so the dtb should be a constant for the given model
<samueldr>
and the "somehow", in a scheme with let's say an initrd of FDTs, would work just well
<samueldr>
clever: you think so
<samueldr>
but it's not
<samueldr>
dtbos get loaded from built artifacts by (I think) the firmware depending on the panel or ram manufacturer on some phones
<samueldr>
so you might have two of the "same model", but different hardware
<clever>
yeah
<samueldr>
but yeah, I'm splitting hair here
<clever>
the rpi firmware will mutate the dtb, based on the hat eeprom, and things like `enable_uart=1` will also mutate the dtb
<samueldr>
yeah
<samueldr>
and that's fine
<samueldr>
then the kernel should load a .dtbo with whatever it wants
<clever>
on the pi, i would prefer if uboot would relay the dtb on, whatever the firmware gave it
<clever>
so the standard firmware stuff does its job
<samueldr>
instead of saying "I KNOW BETTER THAN YOU, PUNY BOARD, LOAD THE RIGHT FDT FOR ME AND IT SHALL PASS"
<samueldr>
clever: I think it should be possible
<clever>
i believe there is an env var in uboot, for the dtb it got as an input
<samueldr>
BUT, u-boot assumes the mainline linux scheme for FDTs
<clever>
and you can use uboot script to then load and further mutate it
<samueldr>
so in the end it's impractical
<samueldr>
all this is probably seriously hurting ARM development and adoption
<samueldr>
because all boards are cajoled like fragile babies
<samueldr>
well, in SBC-land where cheap u-boot BSPs are thrown around
<samueldr>
if it was ACPI+TianoCore things would be different
<samueldr>
not sure if they'd be better though, but different
<clever>
the pain-point i see with tianocore stuff, is that they dont want to use dtb
<clever>
so they re-define everything in acpi
<clever>
and are trying to avoid needing custom drivers
<samueldr>
yeah
<clever>
the pci-e on the rpi4, isnt even defined
<samueldr>
though ACPI doesn't have the failings I just griped about in Linux
<clever>
it just ignores pci-e and declares the vl805 as a platform device, like genet
<samueldr>
though a trick like google (others too?) do with coreboot could exist
<samueldr>
chromebooks, even x86_64 chromebooks, have dtbs that end up compiled into ACPI tables
<clever>
for phones that have mainline support, have you had any success in sharing 1 kernel between many models?
<samueldr>
haven't checked
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
<clever>
thats part of what dtb is supposed to allow
<samueldr>
I only have the pinephone and a chromeos tablet that have mainline support
<clever>
modules either get compiled in or as modules in the initrd
<clever>
and the dtb enables the right ones
<samueldr>
yeah, just like ACPI does
<clever>
and pci as well
<samueldr>
well, neither ACPI nor dtb do that
<samueldr>
but the kernel does according to what's in those
<samueldr>
I will admint that device tree, to my slim experience, looks more palatable than ACPI
<clever>
acpi has bloody bytecode in it
<samueldr>
and possibly better to extend with overlays
<samueldr>
yeah, ACPI scares me
<clever>
that you have to interpret to do certain tasks
<samueldr>
BUT, the way the kernel forces THEIR versions of the device tree down the throat of boards, is not good :/
<samueldr>
at the very least have the decency of loading what you clearly want and have compiled at the same time yourself :(
<clever>
do you have an example of where mainline and a board disagree on how dtb should define something?
<samueldr>
the raspberry pi
<samueldr>
they don't name nodes the same way
<samueldr>
that's the moment I realised things were bad
<clever>
i dont think the name of a node really matters at all
<samueldr>
it does when you try to extend one with an overlay
<clever>
its more about the key/value pairs within a node
<clever>
ah, yeah
<samueldr>
so I can't load the frikkin overlays made for the foundation's kernel without changing things that (at the time) I didn't really get
<clever>
i dont see why the foundation can just accept the new names?
<samueldr>
because of all the existing ecosystem :)
<samueldr>
imagine all the pump-and-dump hardware that won't work anymore!
<clever>
why not just use the foundation dtb then?
<samueldr>
because the kernel wants its own!
<clever>
if the only change is name, then it doesnt matter which base you use
<samueldr>
I don't know if there's other differences
<samueldr>
but that's for a specific issue where there are differences in equivalently-featured device trees
<samueldr>
now let's talk about broken or half-finished device trees
<samueldr>
like the PBP
<samueldr>
whatever is in u-boot does not define all that is required for the linux kernel to use all of the hardwar
<samueldr>
hardware*
<samueldr>
that's not a PBP-specific issue
<samueldr>
sometimes there's also fixes like clock rates
<samueldr>
to work around issues sometimes internal to the kernel AFAIUI
lordcirth__ has joined #nixos-aarch64
<samueldr>
meanwhile, if the kernel had a mechanism to load its own device tree instead of forcing the bootloader to do it, this wouldn't be an issue
<samueldr>
and it would be easier for *everybody*
<clever>
there is a dtoverlay command in raspbian, which can load an overlay at runtime
<samueldr>
yeah
<samueldr>
it's possible to use something of the sort with mainline
<samueldr>
I had something half-packaged for that when I was trying to get something working on the rpi
<samueldr>
(but failed miserably due to the previous issue with names not matching up)
<samueldr>
I really should look into implementing dtb-loading-by-the-kernel
<samueldr>
even though it's too big of a bone to chew
<samueldr>
it is my genuine opinion that this is probably the most damaging factor with the linux kernel's boot chain on device tree platforms
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Client Quit]
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
lordcirth_ has joined #nixos-aarch64
lordcirth__ has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
lordcirth__ has joined #nixos-aarch64
lordcirth_ has quit [Ping timeout: 260 seconds]
edrex has quit [Quit: Idle for 30+ days]
marius851000[m] has quit [Quit: Idle for 30+ days]
alp has quit [Ping timeout: 240 seconds]
spacekookie has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bennofs[m] has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
andi- has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 246 seconds]
<srk>
uboot graphics, nice samueldr++ !
<{^_^}>
samueldr's karma got increased to 254, that's Numberwang!
orivej has joined #nixos-aarch64
PirBoazo has joined #nixos-aarch64
alp has quit [Ping timeout: 264 seconds]
PirBoazo has quit [Quit: Bonne Fin de Journée]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
julm has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
julm has quit [Quit: leaving]
julm has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
orivej has quit [Quit: No Ping reply in 180 seconds.]
lordcirth_ has joined #nixos-aarch64
orivej has joined #nixos-aarch64
lordcirth__ has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]