<{^_^}>
#97883 (by samueldr, 1 week ago, open): Use U-Boot for the Raspberry Pi 4-specific image
<lovesegfault>
is hydra building images?
<lovesegfault>
oh, nice
<samueldr>
not yet
<samueldr>
but it's quite mechanical
<samueldr>
no real compilation
<samueldr>
so build it on your existing rpi4 install I guess
<samueldr>
oh
<samueldr>
no
<samueldr>
I'm lying
<lovesegfault>
:D
<samueldr>
there's a kernel update in there
<samueldr>
see, the actual changes wouldn't take much time on a pi4, only the time to build the image (and u-boot)
<samueldr>
but that kernel update
<samueldr>
might take a hot minute
<lovesegfault>
I have a beefy aarch64 builder
<samueldr>
oh
<lovesegfault>
eMag 32-core
<samueldr>
I would like something at home with enough power for workstation use (including building)
<samueldr>
though you could checkout the PR and revert the kernel update
<samueldr>
since all the changes were made without the kernel update
<samueldr>
oh
<samueldr>
no
<samueldr>
I forgot about the cma change
<lovesegfault>
lying again? 🤣
<samueldr>
you'd need to also drop that change
<lovesegfault>
checking out that branch of yours
<lovesegfault>
rebasing onto nixos-unstable-small
<samueldr>
having additional testing would be nice :)
<samueldr>
I think *my* only leftover task is making sure the wiki is updated
<lovesegfault>
Is this what I want? `nix-build ./nixos/release.nix -A sd_image_raspberrypi4`
<samueldr>
if it builds, most likely yes
* lovesegfault
builds
<samueldr>
I mean, that looks good, but I don't know if it's the right file right attrname
<lovesegfault>
I think it's the right attr, I may be misremembering from the last time clever taught me how to do thi
<lovesegfault>
s/thi$/this/
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
<lovesegfault>
kernel is building
<lovesegfault>
built
<lovesegfault>
building zfs (?!)
<lovesegfault>
well, it built
<lovesegfault>
I need to go find my micro-hdmi to hdmi adapter
<lovesegfault>
brb
<lovesegfault>
writing image
<lovesegfault>
samueldr: it works!
<lovesegfault>
and boots
<lovesegfault>
time to ssh into
<lovesegfault>
*it
<lovesegfault>
annoyingly seems like the TOFU info is wrong
<samueldr>
TOFU info?
<samueldr>
what I'd be more interested in knowing is if the dtbo stuff you were doing works just as well
<lovesegfault>
Oh, nvm, I'm being dumb
<lovesegfault>
I gotta run passwd before I can ssh
<samueldr>
yeah :)
<samueldr>
secure by default, annoying first use
<lovesegfault>
Alright, ssh'd in, all is working
<lovesegfault>
going to try the dtbo stuff with uboot now
<lovesegfault>
brace yerselves
<lovesegfault>
samueldr: do I need to start fresh or can I "convert" a system that was using not-uboot to uboot
<lovesegfault>
i.e. do I need to wipe my sd and flash the new image
qyliss has quit [Quit: bye]
<samueldr>
in theory you should be able to convert, but it takes manual steps... maybe
<samueldr>
there's something in the nixos options for raspberry pi + u-boot, but I have literally no idea if that'll work
<lovesegfault>
I'll start fresh, it's no biggie
<lovesegfault>
I already think this is going to work
<samueldr>
I have a strong belief it should just wor
<samueldr>
just work*
<samueldr>
sure, u-boot won't be on the display
<samueldr>
but otherwise things should
<lovesegfault>
Yeah, I'm working on it right now
<samueldr>
I feel something is quite off with a kernel I'm trying to use as a basis for a new device in mobile nixos
<samueldr>
it looks like the kernel as it is shouldn't compile, at all, meanwhile there are binaries purportedly built from that user's source code tree
qyliss has joined #nixos-aarch64
<samueldr>
really hard to gauge because I still don't have a definitely-known-working kernel and testing protocol on that device yet
<veleiro>
i suppose i'm still fuzzy on NixOS supporting other arch
<lovesegfault>
NixOS supports AArch64
<veleiro>
i mean, images for other arches arent offered on nixos.org
<lovesegfault>
You need to fetch them from hydra
<samueldr>
i686 is available out of nixos.org
<samueldr>
>> NixOS currently runs on 32-bit and 64-bit x86 machines (i686-linux and x86_64-linux), and experimentally on ARM.
<samueldr>
that's what the site says
<samueldr>
though it should be updated to specify AArch64
<samueldr>
and it's not really much experimental
<veleiro>
ah yes, thats a good summary
<samueldr>
that's an old quote
<samueldr>
I'd say AArch64 is almost prime-time ready, many of the issues are not NixOS specific
<samueldr>
or caused not by lack of support, but lack of "people hours" to drive the support
<samueldr>
the whole technical stack is there and working and solid
<veleiro>
isn't there still too much variation in aarch64 platforms to offer "working"
<veleiro>
installs?
<veleiro>
for end users getting into nixos
<samueldr>
here's where the good ol' "arm is different" comes in :)
<samueldr>
it's not
<samueldr>
x86_64 support relies on mainline kernel support
<samueldr>
AArch64 support relies on mainline kernel support
<samueldr>
so it's a bit out of our hands the situation with multiple boards, for _official_ support
<samueldr>
but we're building this with agnosticity in mind
<samueldr>
the mainline-based universal "default" image for AArch64 assume somehow U-Boot (recent enough) will be available to boot the system
<veleiro>
so you'd offer images to devices rather than arch?
<samueldr>
there's also the UEFI AArch64 iso, which as long as the AArch64 device boots from UEFI, works
<samueldr>
nope, still a universal image
<samueldr>
it's just much less of a problem than some people think, at least for making things work well enough to allow the end-user to change the kernel to one that has better support for their board
<samueldr>
and it's becoming months after months less of an issue, with the good work from the Linux communities all around
<samueldr>
so, to circle back to "nixflk", whatever this repo is supposed to be, they're talking as themselves, I don't know that this is a project of even the "nix-community" enlarged community
<veleiro>
RFC for a starting point to a nix machine config to replace configuration.nix?
<veleiro>
probably silly
knerten2 has joined #nixos-aarch64
<veleiro>
coelmickens was pretty shiny too but he was changing a lot really fast
<veleiro>
colemickens*
<colemickens>
veleiro: fwiw I think I've settled on most of my flake.nix changes across my repos
knerten1 has quit [Ping timeout: 240 seconds]
<colemickens>
but I've been cribbing from others tbh
<veleiro>
good to know
<veleiro>
highly made use of nixpkgs-wayland for sway, thats where i found u
<veleiro>
my PBP is unusable :( and i was using it daily
<veleiro>
structural integrity is terrible and i cant repair it enough
<veleiro>
they also have no replacement keyboard+chassis for ANSI in stock
<clever>
samueldr: pkgsCross.armv7l-hf-multiplatform.pkgsStatic.python38 fails to build even bash for me, is that known?
<samueldr>
I don't know about it
<samueldr>
that's it
<clever>
e-final-gcc-debug-9.3.0/lib/gcc/armv7l-unknown-linux-musleabihf/9.3.0/crtbeginT.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
<lovesegfault>
samueldr: that PR fails to boot for me
<lovesegfault>
I get a zillion GPIO errors in early boot
<lovesegfault>
and it then never finds my root partition
<lovesegfault>
Unfortunately I can't send the errors to you b/c I don't have a capture card
<clever>
lovesegfault: serial adapter?
<lovesegfault>
that I do have
<clever>
lovesegfault: you should be able to configure it to send all the kernel logs to the serial port
<clever>
because gnd rx and tx are labeled right on the pins
<clever>
it also has a jumper on the bottom to switch between 5v and 3.3v
<samueldr>
clever: that still doesn't solve my issue of never knowing whether rx or tx on the board labels rx and tx according to the board's vieewpoint or the other way around :)
<clever>
samueldr: the rx on the ftdi is input to the ftdi
<clever>
and the rx on the pi is input to the pi
<clever>
so you just tie tx->rx and tx->rx, done!
<samueldr>
but can I trust all documentation for boards to properly label that? :)
<lovesegfault>
yep, reading 5.1v across VCC/GND
<clever>
the problem is the other guys, that label rx ad tx, because they expect idiots that do tx->tx
rajivr has quit [Quit: Connection closed for inactivity]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 272 seconds]
<lovesegfault>
clever: good morning :D
<lovesegfault>
trying it oyt
alp has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
h0m2 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
<lovesegfault>
samueldr: here's my verdict on your PR after a weekend of testing: It's good, but the old RPi kernel needs to remain since a bunch of stuff in the Pi ecosystem still relies on it
<samueldr>
we have a problem
<lovesegfault>
dum-dum-dum
<samueldr>
the old kernel is AFAIUI not going to be updated anymore
<samueldr>
(but I do understand where you are coming from)
<samueldr>
see: this is why relying on vendor specific things is problematic!
<lovesegfault>
I think we can default to the new one
<lovesegfault>
and just leave the old one around until the ecosystem moves a little bit forward
<samueldr>
let the users .override to the previous one?
<samueldr>
the raspberry pi foundation is as closed as many vendors ecosystems are :(
<lovesegfault>
Right, that is true
<lovesegfault>
my feeling is for those running headless RPi setups the transition will be painless
<lovesegfault>
it will literally make no difference
<samueldr>
yeah, the real issues (all the time) with the raspberry pi stuff is the additional hardware
<samueldr>
though I wonder how we should proceed
<samueldr>
this is going to break people's stuff without a warning
<lovesegfault>
anyone who is using the MIPI CSI-2 iface, or have a head(ful? ed?) setup will be in pain
<samueldr>
*could* be in pain
<samueldr>
which makes the situation kind of worse
<samueldr>
if it was outright broken, it would end up being fixed
<samueldr>
but as different things are at different levels of brokenness, it's pretty sure it will end up with different levels of fixed
<lovesegfault>
Yeah :/
<samueldr>
one thing we could do, but a bad solution to the problem
<samueldr>
force the user to pick
<samueldr>
break build for linux_rpi4
<samueldr>
force them to use something like linux_rpi4.override { branch = "4.9"; }
<lovesegfault>
I was thinking `linux_rpi4` is 5.4, and `linux_rpi4_legacy` is 4.9
<samueldr>
hm, anyway .override wouldn't apply the overlay to the packages attrset
<samueldr>
but I really don't want to have an explosion of linux_* attrnames either
<samueldr>
it's already pretty bad with linux_rpi*
<lovesegfault>
Yeah, that's understandable
<lovesegfault>
Although I do feel that eventually we should just drop support for the RPi1 kernel
<samueldr>
why?
<lovesegfault>
these things are cheap and the 1 is _old_ and unmaintained by upstream by now
<samueldr>
no
<samueldr>
the raspberry pi 0 is built on the same SoC and everything
<samueldr>
still part of the ecosystem
<lovesegfault>
ah, yikes
* lovesegfault
sighs
<samueldr>
and anyway dropping it would be bad
<samueldr>
well, we need a proper plan forward in that case
<samueldr>
because they are still used and useful devices
<lovesegfault>
fair enough
<samueldr>
and uh
<samueldr>
let me think
<samueldr>
I guess it depends on mainline
<lovesegfault>
here's a salient question: do you see the situation with Pi's needing custom kernels improving in the near future?
<samueldr>
no/yes
<samueldr>
they don't seem to care about that
<samueldr>
but mainline linux always improves
<samueldr>
so the raspberry pi themselves will never really need custom kernels
<samueldr>
but the ecosystem built on the custom stuff, yes :(
<samueldr>
so yeah, to go back to 1/0
<lovesegfault>
Hm
<samueldr>
I guess it depends on whether 1/0 uses mainline already, and that mainline is good enough
<samueldr>
it might be something we see as an "external" repo of prebuilt cached artifacts by the nixos org if this ever becomes a thing
<samueldr>
(that's something I'd like to see, some things like community-supported kernels for specific devices cached but not part of Nixpkgs proper)
<lovesegfault>
I have to say, I don't see having more kernelPackages* is that bad. I mean, I get that it is annoying, but I think having proper support for more hardware >>> having less packages to build/choose from
<samueldr>
the real issue is not having more attributes
<samueldr>
the real issue is support level
<samueldr>
they're not even well supported at the time being
<samueldr>
we don't do timely updates
<samueldr>
it takes effort and specialized hardware to test
<samueldr>
(specialized being just the dang devices)
<samueldr>
the project itself should only target mainline linux
<samueldr>
NixOS that is
<samueldr>
unless we can get funding to have people *working* on better support, I suppose
<lovesegfault>
Fair enough
<lovesegfault>
oh, this reminds me
<lovesegfault>
the Python GPIO library doesn't recognize a 5.4 kernel Pi as a Pi
<lovesegfault>
it fails to be imported saying the device isn't a RPi :^)
<lovesegfault>
Oh, this reminds me, I need to test uboot + 4.9 kernel + hyperpixel
alp has quit [Ping timeout: 272 seconds]
bennofs_ has joined #nixos-aarch64
bennofs has quit [Ping timeout: 272 seconds]
<samueldr>
yes please
<samueldr>
that'd give us a much more definitive answer as to what to do nex
<samueldr>
next*
<lovesegfault>
Alright, I'm on it
alp has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<lovesegfault>
samueldr: fascinating
<lovesegfault>
even with the 4.9 kernel the shitty RPi GPIO lib doesn't recognize it as a Pi if you boot with U-Boot
<lovesegfault>
is the custom bootloader setting some MSR?
<samueldr>
I guess the answer would be: look what the lib checks for
<samueldr>
it's possible the firmware sets some values in the in-memory FDT that is not present in the kernel-shipped dts
<samueldr>
I guess follow the flow and check for yourself
<lovesegfault>
yeah, checking
<samueldr>
for stuff under /proc/device-tree pipe through xxd or something aware of \0 (NUL bytes)
<lovesegfault>
Well, before any of this
<lovesegfault>
How do I check whether the overlay was applied?
<samueldr>
best method would be using `dtc /proc/device-tree` to decompile it and check whether things are there
* lovesegfault
does that
<lovesegfault>
I don't _think_ it's applied
* lovesegfault
tried by hand
<samueldr>
the rpi gpio lib should still identify that as a raspberry pi
<samueldr>
regardless of your overlay being applied or not
<lovesegfault>
Right, I just want to tackle that issue after I'm sure the overlay is loading
NinjaTrappeur has quit [Quit: WeeChat 2.8]
NinjaTrappeur has joined #nixos-aarch64
<lovesegfault>
idk what I did
<lovesegfault>
my hdmi output is now just a rainbow
<lovesegfault>
:P
<samueldr>
that means generally that the firmware hasn't been able to start anything
<samueldr>
one of the first few things the firmware does is send a 2×2 texture to the videocore display, which ends up stretched on the displa
<samueldr>
display*
<samueldr>
and is how that rainbow is made!
<samueldr>
(texture? might be a triangle pair)
<lovesegfault>
I think my sd suicided
<lovesegfault>
dingit
* lovesegfault
sighs
<lovesegfault>
alright, flashing new card
veleiro has quit [Read error: Connection reset by peer]
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
<samueldr>
yay, went back to the drawing board, restarted fresh from the OEM's source code dump rather than that user's kernel tree with great success
<samueldr>
not syncing: Attempted to kill init! exitcode=0x00000200
<samueldr>
(it _is_ great success when the kernel ends up logging correctly!)
<lovesegfault>
do I need to do anything special when I'm writing a derivation that statically links a C program?
<heywoodlh>
samueldr: if you have any suggestions and can spare some cycles I'd be curious to know if you have any ideas why razer-cheryl-wip is not building.
<samueldr>
right
<samueldr>
you weren't there when I ended up trying, and yeah, turns out it'S not building
<samueldr>
not sure at the moment
<heywoodlh>
Ah, okay, cool
<samueldr>
I forgot what it was
<samueldr>
(looking at cheryl2 right now)
<heywoodlh>
Haha okay, would it help if I tried to build again and shared the trace?
<samueldr>
it might make me remember
<heywoodlh>
K, will build again
lafa has quit [Remote host closed the connection]
<lovesegfault>
samueldr: I can't get that dtbo to apply anymore, not even manually
<samueldr>
I mean, I knew full well once you said that that it was a possibilty
superherointj_ has joined #nixos-aarch64
superherointj_ has quit [Client Quit]
superherointj has quit [Quit: Leaving]
<lovesegfault>
Yeah, I simply cannot get this thing to work with U-Boot
<lovesegfault>
samueldr: when is our RPi fw from in nixpkgs?
<lovesegfault>
as in: how old is it
<samueldr>
whatever the date in the version field says
<samueldr>
oh neat
<samueldr>
[ 42.381244] $ reboot bootloader
<samueldr>
~80% sure this is from the menu code that ran while not being able to display
<samueldr>
yes Creating LVGL::LVContainer as screen.
<samueldr>
great, so I'm back at having code running
<lovesegfault>
samueldr: making a PR, there's a new release
<samueldr>
there's always a newer release :)
<Jake[m]>
[lovesegfault](https://matrix.to/#/@freenode_lovesegfault:matrix.org): I might be telling you things you already know, but I didn't quite realize that nixos is not gonna touch your firmware. If you want to upgrade it, you need to use `rpi-eeprom`. I'm not sure actually if the raspberry pi firmware in nixpkgs is relevant at all for the rpi4. I use
<lovesegfault>
Jake[m]: I did _not_ know about this
<samueldr>
the eeprom is an additional part of the puzzle
<lovesegfault>
As if I needed any more parts to this mess :P
<Jake[m]>
Haha samueldr I feel like I always don't really know what's going on but get something working and then you break it down and explain what's actually going on. What are the other pieces of the puzzle? Sorry if it wasn't relevant to what you were talking about.
<samueldr>
oh
<samueldr>
the boot puzzle
<samueldr>
the rpi4 [somehow] ends up loading the eeprom firmware, which in turn is what is loading the firmware partition on the storage medium
<samueldr>
AFAIK in this instance it should change nothing, that eeprom firmware is mostly tasked into getting the "conventional" raspberry pi firmware loaded
<samueldr>
then that firmware loads *something* to boot
<samueldr>
which conventionally is the linux kernel
<colemickens>
hm, I got the stuff for rpi-eeprom-config from a github comment in a nix related repo but I don't know where. now its just part of my nixcfg
<Jake[m]>
[colemickens](https://matrix.to/#/@colemickens:matrix.org): I linked it above dwai.
<Jake[m]>
If we're thinking of the same comment.
<samueldr>
AFAIK it should never be needed to update it, except to get more ways to boot or fixes in earlier boot
<colemickens>
oh yeah, fancy Matrix links :) I see, and it is.
<samueldr>
otherwise _their_ own ways to provide the OS will fail badly
<samueldr>
I could be wrong!
<Jake[m]>
So is the conventional firmware start.elf or something, and that's managed by NixOS?
<samueldr>
half managed, depending
<samueldr>
ideally it shouldn't be "managed"
<samueldr>
it should be just like u-boot or your computer bios
<Jake[m]>
So it's not nixos's job, it's the users job to put something like uboot where the eeprom stuff can see it that can then load the kernel provided by NixOS? So uboot will replace start.elf but not the eeprom part?
<samueldr>
it shouldn't be our job, in my opinion, or else we're going to be left working overtime to support all platforms
<samueldr>
but we still need to tie some loose ends to make this work right
<samueldr>
we can't support all the different platforms special needs
<samueldr>
we need to move forward into a universal "just works" ARM ecosystem
<samueldr>
which U-Boot has a basic implementation of
<samueldr>
it's just like we started supporting a custom boot method for, let's say, dell laptops
<samueldr>
that's not a good thing
<samueldr>
there are standards slowly developing around ARM and booting
<samueldr>
I'm thinking I should research the topic and propose a talk for nixcon, how we (I) propose ARM booting with NixOS should be done
<samueldr>
a "detailed high level oveview"
<samueldr>
so nothing about exception levels in ARM, nothing about how ARM platforms actually work
<samueldr>
but what big pieces people all around the ARM communities are working towards
<samueldr>
e.g. talk about EBBR, SBBR, presenting what it means for SBCs
<samueldr>
though whew, a big chunk of work in not that much time :/