<gchristensen>
I'm doing an install of ubuntu overtop
<gchristensen>
just to see how it does its thing
<samueldr>
no relation, but just an odd observation: for a bad bluetooth card on mainline kernel I had to enable what looked like an unrelated module for it to work; wouldn't print anything useful; curious if another HISI option would add something necessary that isn't well gated
<gchristensen>
quite possibly yes
Thra11 has joined #nixos-aarch64
<gchristensen>
their alpine rescue image works ok somehow
<samueldr>
while you're around, any notes about EFI on AArch64 using u-boot, Dezgeg? if I were to rely on it would I face unintended consequences? (that's compared to using extlinux boot)
<Dezgeg>
it's probably more painful than extlinux boot
<samueldr>
I mean, it boots successfully
<samueldr>
my raspi boots from grub with u-boot's EFI already
<samueldr>
no need to touch u-boot; works using nixos' build
<Dezgeg>
does the device tree match the kernel?
<samueldr>
I don't know what to answer
<sphalerite>
isn't the device tree baked into u-boot and provided to the kernel via EFI in that setup?
<samueldr>
the only difference from the stock nixos-built image is rm the extlinux dir, disabling extlinux option, enabling grub for UEFI as usual
<Dezgeg>
yes, if you now boot linux_rpi, you don't get a matching device tree for linux_rpi
<samueldr>
^ sphalerite basically said what I thought
<samueldr>
booting the default mainline kernel
<samueldr>
and my question was more general than raspberry pi, basically "what should I watch out for, using u-boot's EFI support"
<Dezgeg>
or if your kernel is too old and bootloader too new, the kernel will probably break etc.
<samueldr>
anything different than extlinux boot with u-boot then?
<sphalerite>
Dezgeg: why would that break?
<Dezgeg>
if something in your device tree depends on something that an old kernel doesn't know, that device won't probe
<sphalerite>
I'd expect that EFI exposes that sort of thing in a kernel-neutral way
<Dezgeg>
no
<sphalerite>
such that windows can use it too
<sphalerite>
for example
<Dezgeg>
nope, it just provides a dtb
<sphalerite>
oh
<samueldr>
Dezgeg: is it because the extlinux based boot will set FDTDIR, but the EFI based one uses *another* DTB?
<Dezgeg>
yes
<samueldr>
ah I see thanks
<samueldr>
so that's an issue to be on the lookout for
<gchristensen>
hit by that blocking getrandom again
<gchristensen>
interesting hardware is both the best and the worst
<gchristensen>
taking a big detour in getting nixos back on this thing.
<samueldr>
I hope this means that this is a non-issue as long as nixos knows to add this as required to the generations
<Dezgeg>
but you don't know which one to load
<samueldr>
the extlinux configuration has one hardcoded in (FDTDIR ../nixos/d4nslcgsblswhmqxbrhqrl4533m7rqzb-linux-4.18.6-dtbs)
<samueldr>
oh FDTDIR
* samueldr
should read fully before pasting
<samueldr>
hmm, this is an issue that's less annoying to solve without generations :)
<samueldr>
so the EFI program would need to know about the fdtfile value (not the file) so it could load the right one depending on what was in there...
<gchristensen>
I had to brig my bond up manually, which was a learning experience
<gchristensen>
sphalerite: it is your lucky day!
<samueldr>
a week after getting an aarch64 chromebook ;)
<samueldr>
(not trying to rain on your parade, I find this a bit funny)
<samueldr>
this, though, could be useful in the future if nixos has more of armv7l pre-built
<samueldr>
thinking about cheap SBCs, but more importantly: older android-based phones
<gchristensen>
hydra won't bild armv7l
<gchristensen>
not any time soon, anyway
<samueldr>
aww, no sponsorship? or no time to manage?
<gchristensen>
the hw is too rare
<gchristensen>
Packet has a small handful of these machines
<gchristensen>
if it fails, we're not getting another
<samueldr>
right, so kinda half no-sponsorship and no real firepower to handle :/
<samueldr>
good to know
<gchristensen>
I mean it is sponsored
<samueldr>
if only nixos wasn't pure, we could manage on shoestring and bubblegums :)
<gchristensen>
:
<gchristensen>
)
<gchristensen>
we can do whatever we want with this machine
<gchristensen>
but they don't have more, and don't have plans to get more
<samueldr>
right
<gchristensen>
also it isn't commercially available from Packet, its an unlisted instance type
<samueldr>
(unlisted if they removed the leftover remaks I found the other day ;))
<gchristensen>
they don't hide it
<samueldr>
yeah, I understand the fact they can't sell what they don't have!
<samueldr>
(more of it)
<gchristensen>
yeah
<gchristensen>
man this new box is much faster
<samueldr>
the cores are much better than the others?
<gchristensen>
yeah
<gchristensen>
I was going to make it available to the community but we might want this on hydra for aarch64
<samueldr>
sad it's not common hardware
<gchristensen>
yeah
<gchristensen>
ok samueldr let's take a poll
<gchristensen>
by the looks of it you're the only person being polled
<gchristensen>
should this be used by the community for armv7 or go to hydra to give more aarch64 firepower
<samueldr>
I'm kinda split, it would be awesome for the community, but if there's no armv7l official builds, it wouldn't be *as* useful; and I don't know the actual needs as far as aarch64 hydra
<samueldr>
would it be lending more power than needed (unlikely)
<gchristensen>
oh well there is a second option
<gchristensen>
this is for the community and the existing aarch64 one goes to hydra
<gchristensen>
that seems most sensible
<gchristensen>
then community people get both aarch64 and armv7 but also community people probably don't need 160 cores
<samueldr>
seems more sensible put that way
<samueldr>
I don't know if there would have been value into setting an armv7l builder with the others, filling in the caches
<samueldr>
I don't know if for others it's similar, but it's the long compounded builds that get hard to deal with
<samueldr>
though I do understand how it brings a bit more burden on the maintainers
<samueldr>
(and the machine could go away without replacement, making sad end-users)
<gchristensen>
that said, these 64 cores do blow the 96 out of the water