zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<sphalerite>
nice. Path registration is missing from the SD image, so a gc just wiped out everything \o/
<sphalerite>
ls: Command not found
<patagonicus>
sphalerite: If you still have a single bash interactively, you could probably recover without needing to reflash. But reflashing will be easier. :D
<sphalerite>
yeah I did and I know but no. :p
<sphalerite>
it's already booted into a fresh install.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<patagonicus>
sphalerite: At least in the default sd-image.nix that's probably what will happen - it checks if a specific file exists, if so it grows the root FS and then does the registration, before deleting that file.
<patagonicus>
Yay, got Gnome running on my Pinephone. The setup window is about three times as wide as my screen, which makes it a bit awkward.
<patagonicus>
Also it seems to recommend "Cameroon Multilingual (Dvorak)" as the keyboard layout for some reason.
<patagonicus>
Uuuh. The "all applications" selector seems to render the icons one pixel wide. I have no idea what is what.
orivej has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<angerman>
sphalerite: yes. If you feel like writing the grow + resize logic and open a PR, I’d be very greatfull ;-)
<sphalerite>
hm, building on the community box is a bit hobbled by the ofborg evaluation (?) workers because `make -l$NIX_BUILD_CORES` looks at load average ⇒ doesn't start anything because borg is hammering the cores.
<angerman>
It fails for two reasons: (a) awk is not found (b) lsblk returns something in the 70+ for MIN in MAJ:MIN, and the script assumes MIN corresponds to the partition number.
<angerman>
sphalerite: just use the image. You’ll see the failing script in the console. Cat it and do it by hand ;-)
<sphalerite>
ah yeah that's silly.
zupo has joined #nixos-aarch64
<patagonicus>
What's ba reliable way to find the partition number? Resolve the by-label udev entry and look athe digits at the end of the /dev/mmcblk0p2 device file name?
alpernebbi has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
bridge[evilred] has quit [Ping timeout: 264 seconds]
bridge[evilred] has joined #nixos-aarch64
red[evilred] has joined #nixos-aarch64
<red[evilred]>
minor device number?
<red[evilred]>
maybe?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<LinuxHackerman>
red[evilred]: that's exactly what's going wrong here, assuming that the minor device number is the partition number.
<Ke>
it is not
<Ke>
well it can be, but generally is not
<red[evilred]>
hence the "maybe?" :-)
cole-h has joined #nixos-aarch64
<Ke>
reliable way is to map the canonical device name and find it on sysfs like /sys/block/sda/sda1/partition
<Ke>
canonical name is on /proc/partitions
<Ke>
and major minor
<Ke>
but [0-9]$ of the canonical name works for all the cases I know of also
fooker has quit [Ping timeout: 260 seconds]
<sphalerite>
Ke: [0-9]+$ ;)
fooker has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
veleiro has quit [Ping timeout: 260 seconds]
zupo has quit [Client Quit]
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
<Ke>
either works, since these programs are mostly greedy anyway, just affects the return value for scritps
<LinuxHackerman>
Emil Karlson: ooh, it was mangled by element's markdown parsing. Your `*` got eaten.
<Ke>
oh right
<Ke>
it't not element though, I am sending with weechat and I always forget asterisks are not sent
<sphalerite>
oh ok x)
<patagonicus>
Ke: oh, /sys/block/sda/sda1/partition is nice. So, basically just use `cat /sys/class/block/$(basename $(realpath $(findmnt -n -o SOURCE /)))/partition`. Plus some quoting just for safety
<patagonicus>
Btw, someone at least fixed awk not being found.
<patagonicus>
Maybe I'll try making a pull request for that tomorrow. Depends on if I'll have to work or not …
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<sphalerite>
argh. Was wondering why my u-boot couldn't see the eMMC. Turns out the jumpers disable it pretty hard :D
<samueldr>
hah
<sphalerite>
"just the boot order", he thought.
<samueldr>
AFAIK there is no way to do that with the rk3399 boot rom
h0m1 has quit [Quit: WeeChat 3.0]
<samueldr>
and then there's the confusion that could arise from the SPI flash'd firmware reading the eMMC even though the jumper asks not to boot from it
<samueldr>
(would need some u-boot work)
h0m1 has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
<sphalerite>
yeah it's fair enough, I just didn't realise
monk has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
zupo has joined #nixos-aarch64
<andi->
That reminds me.. I still have to figure out how to flash the SPI on my RockPi from within linux.. Not going to get that weird USB-A cabel..
<samueldr>
andi-: or you can do it from u-boot ;)
<samueldr>
andi-: it's something mtd related IIRC in the kernel and packages
<andi->
that requires moving to it..
<samueldr>
though this also requires your device tree to describe it appropriately
<andi->
mhm, i might still have that serial connected
<samueldr>
(which it might)
<samueldr>
I still haven't gotten to investigating that part
<samueldr>
andi-: look under /sys/class/mtd
<samueldr>
,locate bin mtdinfo
<{^_^}>
Couldn't find in any packages
<andi->
I think I tried something like that without much success but let me check again
<samueldr>
> mtdutils.meta.description
<{^_^}>
"Tools for MTD filesystems"
<andi->
yeah, /sys/class/mtd is empty
<samueldr>
look at the kernel config
<samueldr>
it might not have the modules built?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
(I haven't tried any of that myself yet)
<samueldr>
the normal nixos kernel config does seem to build a lot of mtd modules
<andi->
there are a few mtd modules but not all of them
<andi->
actually could be all but not all flags set
<samueldr>
I love me some good documentation
<samueldr>
>> You need the kernel built with SPI flash device support, which will supply a device similar to:
<samueldr>
nowhere they describe the config option required
<andi->
yeah
<andi->
or which kernel tree...
<samueldr>
CONFIG_SPI_SPIDEV apparently
<andi->
that is present
<samueldr>
>> modules built: spidev
<samueldr>
might not autoload the module
<andi->
ok no obvious difference to before tho...
<samueldr>
andi-: using dtc /proc/device-tree
<samueldr>
look for spi@ nodes, and check if all have the `status = "okay";` config
<samueldr>
on my rk3399 device I tested on (ROC-PC) all are `status = "disabled"`
<andi->
same here
<samueldr>
status = "disabled"; means the kernel will not use them
<andi->
does that mean it doesn't know how or just that you have to enable thme as they might conflict with other stuff?
<samueldr>
that no one made the change to configure it to be enabled, that it most likely would work if you used the right one
<samueldr>
this applies on top of the spi1 label (which is stripped from what you see using dtc)
<samueldr>
another rk3399 from friendlyarm also says spi1 is used for the spi flash
<samueldr>
most likely it's the right node
<samueldr>
the status = "okay"; means that linux will use it, but it does need more than just being available, the other node(?) added configures it with a "compatible" string, which a kernel module will use
<samueldr>
if you were to gre `jedec,spi-nor` in the kernel tree, you'd find (at least) one module that will handle that
<andi->
yeah, looks like there are a few handling that including drivers/mtd/spi-nor/core.c
<samueldr>
I kinda hate how the kernel upstream device trees doesn't strive to enable every bit of hardware
guest41 has joined #nixos-aarch64
<samueldr>
especially since they don't have an overlay mechanism, default to a build that makes overlays impossible, and decided that they themselves are the holders of the one true source of device trees :(
<andi->
I kinda think that is the only way to avoid more fragmentation with DTs..
<andi->
I guess I'll have to start patching the kernel and deploying a DT with that bit set?
<andi->
already building custom kernels for the device so not much lost just takes about 15min or so..
<samueldr>
we should setup a helper function to rebuild *only* the device trees from the kernels
<andi->
yeah
<samueldr>
which, I think there might be something for that in a PR
<samueldr>
about device tree overlays
<andi->
oh
<samueldr>
though, I don't buy the "avoid more fragmentation" bit... it creates two worlds, the vendor world, and the kernel world
<samueldr>
the kernel doesn't try to ship "one true" ACPI tables for every ACPI devices
<samueldr>
they do have code paths to handle quirks for those
<samueldr>
when they are wrong
<samueldr>
if we forget about outright horribly bad vendors
<andi->
was there some discussion on this topic on one of the MLs?
<samueldr>
and think only about vendors like the raspberry pi
<samueldr>
I don't know
<samueldr>
we can clearly see how it harms mainline adoption
<samueldr>
nothing from the hardware ecosystem for the raspberry pi works out of the box on the mainline kernel
<andi->
and there is no effort as they can just use their fork?!?
<samueldr>
and nothing will work even though they do the device tree thing "the right way"
<samueldr>
the raspberry pi firwmare can load device tree overlays from hardware add-ons
<samueldr>
which is basically how the spec says things should be handled
<samueldr>
bu the mainline kernel tramples over that and says "NO, YOU ARE THIS HARDWARE NOW"
<andi->
the whole dt sync between bootloader & kernel is weird. Isn't there some interface to hand that over?
<Ke>
does someone have pbp configs updated for linux-5.10
<samueldr>
sorry, no
<samueldr>
(well, not me)
<samueldr>
andi-: not sure I follow your question
<Ke>
well at least I did not just waste time extracting the manjaro patches for 5.10
<andi->
samueldr: the fact that I have to tell u-boot about the device tree as well as the kernel and both could have different versions / features
<samueldr>
there is an interface to hand that over, that's where e.g. u-boot loads the FDT in memory the dtb file
<andi->
ah
<samueldr>
but that's the crux of the issue
<samueldr>
why is the kernel mandating _their_ device trees?
<samueldr>
do you use _their_ ACPI tables on your thinkpad?
<Ke>
do you need an overlay for panfrost still at this time
<samueldr>
no idea :)
<samueldr>
no, you use the vendor provided ones from lenovo
<samueldr>
I wouldn't mind a "community maintained device trees" repo that projects like u-boot would sync from
<samueldr>
because we know that vendors can be bad
<andi->
Ke: IIRC panfrost just works on my rockpi
<samueldr>
but some vendors are not outright bad and provide appropriate descriptions
<andi->
that is with 5.10-rc6
<Ke>
andi-: that's what I would assume indeed
<andi->
samueldr: I see... yeah maybe that would be great.
<samueldr>
we already have that community-maintained device tree repository, but it's not optional, it's mandated for mainline use
<samueldr>
but the kernel itself doesn't provide a method to load the right device tree!
<samueldr>
so now the firmware has to handle that
<samueldr>
which is an issue in our generations-based setup
<samueldr>
thankfully u-boot can handle that just right enough
<samueldr>
but try to get aarch64 grub to do that
<samueldr>
it cannot
<samueldr>
it would have been much better if the protocol instead used a key at the root of the (in-memory) FDT
<samueldr>
something like `kernel,device-tree = "";
<samueldr>
and the kernel then loaded from an initrd-appended image
<samueldr>
the FDT from the firmware should be sufficient to let the kernel start enough to handle loading things from memory, and then override the FDT
<samueldr>
AFAIUI
<samueldr>
then *any* bootloader that loads kernel+initrd would be sufficient to load the right device tree according to the kernel
<samueldr>
no need to make the bootloader more complex, the kernel handles it
<andi->
I just hope there were got reasons not to do that... maybe nobody ever thought that far back then..
<andi->
DTs are already a lot better than the situation we hade before that
<samueldr>
I'm thinking they thought it was sufficient that way because anyway, you only load what, one kernel per device?
<samueldr>
yes, DTs are not the issue, it's the way the kernel decided they are the gatekeepers of the "right" DTs
<samueldr>
DTs are a plenty fine solution
<samueldr>
DTs outright, once you have the right FDT in memory, is fine
<andi->
i guess that way they can do refactorings of DTs along with code... which isn't great as they might diverge then?
<samueldr>
something like that
<samueldr>
I don't know if they keep their implementation backward compatible
<samueldr>
or if it's strictly always relies on whatever they decide the DTs represent at the current version
<samueldr>
and they often push "quirks" into the FDTs
<samueldr>
which would be fine... if it wasn't for the fact that you shouldn't assume the kernel is in control of the FDTs!
<samueldr>
which might still be fine if at least they applied overlays on boot on top of the vendor DTs in these situations
<samueldr>
and what about other non-linux projects? should they sync-up with the kernel's DTs? or should they make their own variants? use the vendor's?
<sphalerite>
so what I'm hearing here is dtbs shouldn't live in the kernel tree and there should be a built-in overlay mechanism
<samueldr>
multiple points, but those are two of them
<sphalerite>
actually the first part might be my subjective interpretation of the situation :p
<samueldr>
I'm thinking it's fine to have a community-managed list of DTs
<samueldr>
but they shouldn't be _mandated_
<sphalerite>
(would be really nice to not have dtb patches result in having to rebuildthe kernel)
<samueldr>
and one of the points you haven't touched on
<samueldr>
the kernel should handle loading its own dtbs, since reality is they want their owns
<samueldr>
one way to do so in a generic manner would be by appending an initrd image with dtbs
<sphalerite>
actually, is there any reason why we wouldn't provide dtbs as a completely separate package from the kernel?
<Ke>
isn't the point of the dtb to be OS independent
<samueldr>
sphalerite: there shouldn't be any AFAIK, except that it is easier to use the kernel's own
<samueldr>
Ke: yes
<sphalerite>
samueldr: I mean exposing the kernel's dtbs in a package separate from the kernel itself.
<samueldr>
well, I don't know if it's "the point", but it's my interpretation thereof
<samueldr>
sphalerite: yeah, I understood, it needs to be hard to accidentally start using the wrong set of dtbs
<samueldr>
so it would be a kernelPackages.kernel-dtbs I guess
<sphalerite>
oh right. I mean, would it hurt much to use a 5.10 dtb with 5.4?
<samueldr>
it shouldn't... but in reality it could
<sphalerite>
why can't we have nice things :'(
<samueldr>
I don't think they strive for forward or backward compatibility, or at least I haven't seen any proofs
<samueldr>
e.g. raspberry pi 3B+ worked fine with the 3B DTs for a while
<samueldr>
and then it stopped working
alpernebbi has quit [Quit: alpernebbi]
<sphalerite>
wow, disabling DRM does make the kernel build a loooot faster :D
<samueldr>
the default builds we do are soooo bloated, but in the best of ways
<sphalerite>
haha
<sphalerite>
it makes perfect sense
<samueldr>
I started working on a device for x86_64 on with mobile-nixos, and cutting what's enabled with `make localyesconfig` REALLY helped with compilation speed
<sphalerite>
yeah I can imagine
<samueldr>
(but won't be part of the actual devices list, only part of my extra devices)
* sphalerite
now wants a script that will grab the kernel source, do the nix-shell stuff to get a localyesconfig, and dump the result as a minimal nix expression to be passed into extraStructuredConfig on buildLinux
<samueldr>
you can do it on another device btw
<samueldr>
if you get the output of lsmod into a file
<samueldr>
but yes, I'd like that too
<sphalerite>
oh but it won't recognise modules that are already built-in?
<samueldr>
localyesconfig needs to start with a `.config` file at the root that is your existing config
<sphalerite>
awwww
<sphalerite>
but makes sense I think.
<samueldr>
so zcat /proc/config.gz > config.txt && lsmod > lsmod.txt
<samueldr>
I did that basically a week ago lol
<samueldr>
almost have that x86_64 tablet working just right
<samueldr>
but the touch screen needs calibration data, which libinput can use... but the GUI doesn't use libinput (yet)
<samueldr>
I need to do a revamp of the code to use libinput, and use DRM (and fallback to fbdev)
<sphalerite>
interesting, we have CONFIG_SATA_AHCI=y on aarch64 but =m on x86_64
<sphalerite>
would probably be good to have it built-in on x86_64 too…
<samueldr>
I think we're due for a total review of kernel options... especially on aarch64
Darkmatter66_ has joined #nixos-aarch64
<samueldr>
I *know* there are options we probably should enable by default
<samueldr>
we need consumer ryzen-equivalent chips
<sphalerite>
it can only be a matter of years :)
<samueldr>
I don't remember where I read it, but I seem to recall that whatever makes ryzen be ryzen is apparently not x86_64 specific
<samueldr>
that they have an AMD aarch64 cpu that's just like it
<samueldr>
(or theoretically)
<sphalerite>
that makes sense to me
<sphalerite>
I'm not familiar with the ins and outs of microarchitectures (don't even know how much public info there is on them) but I'm fairly certain that the instructions executed at the level where the numbers actually get crunched looks almost nothing like the x86_64 instruction set