<gchristensen>
error: a 'armv7l-linux' is required to build '/nix/store/vpl6gfsq8q6rvb5c1983vi65b67bs51q-bootstrap-tools.drv', but I am a 'aarch64-linux'
<gchristensen>
extra-platforms = armv7
<gchristensen>
extra-platforms = armv7l
<samueldr>
while I could make it work with per-board configurations, I feel it defeats the purpose of generic mainline builds of most everything... I don't know if there's a standardized way u-boot could tell grub *which* dtb file to load from a given directory
<samueldr>
(read the source code of grub's FDT loading, and there is no magic as implemented, and then looked a bit if I could see EFI tricks, but wasn't fruitful in finding any useful information)
<samueldr>
I wonder how efi-first arm hardware handle that
<samueldr>
I guess I'll learn it with the board I got, unless their "EFI support" is u-boot
<clever>
samueldr: i was recently skimming thru qemu code for DT
<clever>
samueldr: and for the most part, all it does is set the bootargs, and the initrd start&end
<clever>
but somebody recently asked in #qemu about qemu obeying the DTB, and generating the entire machine from it
<clever>
so if you define a device in the DTB, qemu then creates it in the vm, and linux knows where it is
<samueldr>
(I'm listening)
<clever>
if taken to the extreme, you could replace a decent chunk of the framework code in qemu, with just dtb files
<clever>
you could possibly even mix&match crazy things, like jamming an x86 and an arm into the same vm, just by claiming they exist in the dtb, lol
<samueldr>
AFAIUI (not much) DTBs are pretty standard, and not dependent on a host architecture like e.g. ARM, so it doesn't sound too bad
<samueldr>
do I understand right that the boot.c line you linked uses the FDT to store the kernel cmdline?
<samueldr>
(note: I'm quite unsure about the right terminologies between dts, dtb and fdt; FDT are the flattened device trees, but still unsure when to use each names; though I think dts are the source?)
<samueldr>
hmm, linux,initrd-start and linux,initrd-end...
<samueldr>
so one *could* extend the FDT dynamically and add e.g. fdtfile in the dtb, which could be used to load the right one (in an EFI loader that knows about it)
<samueldr>
I assumed it was *only* a representation of the hardware
orivej has quit [Ping timeout: 240 seconds]
<clever>
samueldr: when booting linux, you either get ATAGS (which has the cmdline) or the DTB
<clever>
and since you can never have both, the kernel cmdline must go into the DT
<clever>
the format of DT is also designed to allow you to trivially parse it, and insert elements into the tree or edit nodes
<clever>
so a bootloader written in assembly could still manipulate them and configure the boot-time stuff
<samueldr>
so my idea while non-standard (yet?) could realistically work I think
<clever>
what exactly is the idea?
<samueldr>
assuming one wants a portable generic mainline linux NixOS installation for ARM, it will need to load the right DTB from the right generation or else chances are there could be a mismatch
<samueldr>
(assuming I understand the situation right)
<samueldr>
in u-boot, this uses the extlinux-compatible file, with FDTDIR + internal u-boot magic
<clever>
the whole idea of DT, is that you have a generic kernel, with a wide-ish range of drivers linked in at compile time
<clever>
and then the bootloader on the board provides the correct device-tree files at bootup
<samueldr>
yeah, but at boot you need to load the right DT to the kernel
<clever>
and the kernel then enables the right drivers it needs
<samueldr>
right, this is what I understood
<clever>
yeah, the bootloader puts the DT in ram, and sets a register to its address before passing control to linux
<clever>
*looks*
<samueldr>
yay, tmux broke
* samueldr
is mildly annoyed mid-explanation
<samueldr>
all of my terminals run tmux automatically
<clever>
samueldr: one of the wiki pages i stumbled upon just now, mentions that efi and dt are competing solutions
<samueldr>
elinux.org
<samueldr>
?*
<clever>
which makes sense, DT is just a blob that describes the hardware
<clever>
yeah
<clever>
EFI is a full api with functions and services, that can also describe the hardware, or just do things for you, with the hardware
<samueldr>
well, strace wasn't useful in the crash, so let me continue
<samueldr>
(I needed that terminal for its vim buffer for the explanation)
<samueldr>
so I said "internal u-boot magic"
<samueldr>
this is board dependent
<samueldr>
some boards like the raspberry pi you can get a dtb filename from hardware-specific information
<clever>
i think if your doing efi, then you shouldnt be passing the DT to the linux kernel
<clever>
but instead translate it to efi structures
<clever>
but thats bound to have loss
<samueldr>
I'm not entirely sure they cover 100% of the same problem space
<clever>
yeah, hence the data loss from conversion
<samueldr>
it's ACPI I think in x86-land which responds to a load of "what are you?" questions?
<clever>
samueldr: ACPI includes an entire bloody bytecode language!
<samueldr>
:)
<clever>
and you must interpret it to do many things
<samueldr>
because as far as linux and grub are concerned, they're both fine using FDT on EFI on ARM
<samueldr>
so I'm not convinced one "should" use EFI instead of FDT, but I'm no expert either
<samueldr>
grub can load a fdt
<samueldr>
it's just that for a generic AArch64 install, it wouldn't know *which* file to load as it has no internal magic like u-boot has
<samueldr>
but it did have the previous FDT still loaded (AFAICT) and can re-use it
<clever>
yeah, thats supposed to be done by the board manufacturer
<clever>
forwarding it on could work better
<samueldr>
[22:08:09] <clever> forwarding it on could work better
<samueldr>
I don't follow
<samueldr>
forwarding what?
<samueldr>
the whole DT or an identifier only&
<clever>
the whole tree
<samueldr>
yeah, therein lies the issue: u-boot's bundled trees often don't match the better updated trees from the linux kernel
<samueldr>
(which YES should be handled by the manufacturer instead!)
<clever>
the rpi cpu also supports parallel and serial flash chips as boot targets
<clever>
but the board hasnt routed those properly, and the supplied firmware cant boot that way
<samueldr>
so with the idea of keeping the right tree for the right kernel versions, u-boot as configured for nixos will load the trees generated from the kernel version that will load
<samueldr>
therein lies the issue: u-boot does not know which kernel version (generation) willl be booting, so it can't forward the right tree even if we were to add it as a pre-step
Sonarpulse has joined #nixos-aarch64
Sonarpulse has quit [Client Quit]
Sonarpulse has joined #nixos-aarch64
Sonarpulse has quit [Quit: Leaving]
<sphalerite>
gchristensen: there's also the issue that building for armv7 doesn't work out-of-the-box even with extra-platforms=armv7l, because everything still detects the build system wrong based on uname. That's why I spent a lot of time fiddling with it to try and get it to work
<sphalerite>
I never got to the point of being able to build my system on the machine the last time I had access to it
<sphalerite>
I did get the stdenv working iirc, with a bunch of patches, essentially implementing #21471
<sphalerite>
but there were still bits and pieces that didn't build, like rustc (which is necessary for graphical nixos nowadays)
<sphalerite>
also firefox will probably never build natively on aarch32 again, because it simply requires more than 4GB RAM in a single process, which aarch32's address space doesn't support :|
<sphalerite>
or maybe it was more than 3GB
<sphalerite>
so cross-compilation is currently the only way to get a 32-bit firefox
<sphalerite>
so I think working on the cross-compilation story, and particularly working out some efficient way to mix cross/native packages, would be a more effective way of getting better armv7 support
<sphalerite>
and as you said — I'm not so sure I'd state it as armv7 being rare so much as wanting to run nixos on it being rare. But I think that's moslty because of the various barriers in the way of doing so
<sphalerite>
I bet lots of people here would like to run nixos on their phones and manage them with nixops xD
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 252 seconds]
makefu has joined #nixos-aarch64
<Dezgeg>
clever: re "i think if your doing efi, then you shouldnt be passing the DT to the linux kernel but instead translate it to efi structures" it just doesn't work like that
<Dezgeg>
besides some utterly trivial devices like a reboot driver, efivars or the serial console/framebuffer, there are really no abstractions that EFI provides to the OS via runtime services
orivej has joined #nixos-aarch64
<Dezgeg>
all that's going to be done is that the DTB is going to be passed in via some EFI-specific table
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 252 seconds]
duncan^ has quit [Ping timeout: 244 seconds]
duncan^ has joined #nixos-aarch64
<clever>
Dezgeg: ahh
Thra11 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<gchristensen>
can y'all test out this new box as a remote builder?
<gchristensen>
see if it does the business ok?
<gchristensen>
your accounts will work already 147.75.77.190
<sphalerite>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 28
<sphalerite>
[lheckemann@arm-community-2a2:~]$ nix build nixpkgs.hello --argstr system armv7l-linux --extra-platforms armv7l-linux
<sphalerite>
gchristensen: that machine really does feel a lot speedier than the other one!
<gchristensen>
it definitely is :D
<sphalerite>
it kind of bothers me how nix will prefer nixbld100 over nixbld2 :p