veleiro` has quit [Read error: Connection reset by peer]
veleiro` has joined #nixos-aarch64
veleiro` has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
<Gaelan>
Anyone have a real aarch32 (i.e. not aarch64) machine that's fast enough to compile things? If so, I'd love to know if `nix-build . -A stdenv.__bootPackages.linuxHeaders` (in nixpkgs master) works.
<Gaelan>
It fails on a Pi 4 pretending to be aarch32, and it also fails if I copy all the deps over and do the last step on an Pi 0, but I'd like to be sure it isn't an issue with how the Pi 4 builds some dependency.
<samueldr>
Gaelan: pretending how?
<samueldr>
you could be booting the armv7l kernel natively, executing the armv7l kernel in KVM, or alternatively running 32 bit binaries on the 64 bit kernel
<samueldr>
(not sure it would matter)
<Gaelan>
32bit binaries on 64bit kernel
<samueldr>
last time I know of someone that tried it that way, things weren't successful (elsewhere) :(
<Ke>
I guess 64-bit kernel allows userspace to use full 32 bits of address space
<samueldr>
AFAIUI the kernel does much less compared to the magic it can do for i686 on x86_64
<samueldr>
and I guess that v6 would be even harder
<samueldr>
considering that impurities armv7-specific could slip in
<samueldr>
(raspberry pi 0 being armv6)
<Ke>
but I don't think that happened
<Ke>
I believe at least OS X maybe windows did this on 32-bit
<Ke>
maybe were not suspectible to 32-bit meltdown either
<Gaelan>
So yeah, what I'm trying to figure out is whether the bug I'm running into is due to impurities (and therefore my fault) or a real bug (and therefore worth fixing)
<samueldr>
you might want to do a cross-compilation of nixos for armv7l, and boot that system (e.g. on another sd card) on the pi 4... though thinking about it you'll need to customize the build so it builds with the raspberry pi foundation kernel
<samueldr>
then you should be able to run an armv7l system for that
<samueldr>
BUT, that might not be enough since you want armv6l
<samueldr>
not sure if you can run an armv6l kernel on the pi4
<samueldr>
(there are no fast armv6l boards that anyone here can get too)
<{^_^}>
#107386 (by Gaelan, 5 days ago, open): Can't build linux-headers on armv6l
<Gaelan>
IIRC, until recently Raspbian was armv6l on every pi
<samueldr>
yeah, that's part of my doubt
<samueldr>
I know it was 32 bit for the pi4 at release (and still is the recommended version)
<samueldr>
but I don't know for sure if it used a v6 or v7 build
<Gaelan>
I think the reason they did 32 was so there was only one version of raspbian, and the 0 is v6, so they probably did v6 everywhere
<samueldr>
their firmware can load a different kernel per pi version
<Gaelan>
oh right
<samueldr>
so it's entirely possible that the kernel is built for v7, but with a v6 userland
<Gaelan>
in any case, I'm not sure, but I doubt this is a v6 vs v7 issue
<samueldr>
(I haven't really looked at the issue, sorry :))
<Gaelan>
it's all good
<Gaelan>
i'll see if I can reproduce the bug building from scratch on a pi 0 overnight - it's early in the stdenv bootstrap, so there's not too much to deal with
steveeJ has quit [Ping timeout: 246 seconds]
steveeJ has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
Darkmatter66 has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.9]
justanotheruser has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Guest62093 has quit [Quit: No Ping reply in 180 seconds.]
justanotheruser has quit [Ping timeout: 272 seconds]
Amanda has joined #nixos-aarch64
Amanda is now known as Guest57308
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
Guest57308 has quit [Ping timeout: 264 seconds]
AmandaC has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rajivr has quit [Quit: Connection closed for inactivity]
justanotheruser has joined #nixos-aarch64
<flokli>
ouch, that poor little pi 0
<flokli>
make sure to mount a sufficiently amount of swap via usb stick :-P
<Gaelan>
update: it failed successfully
ryantrinkle has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-aarch64
<Gaelan>
btw, pro tip for anyone struggling to compile aarch64 stuff: you can get a 32-core arm box from amazon for $0.33/hr (spot instance, Ohio)
<samueldr>
note: it's aarch64 only, no 32 bit mode on that hardware IIRC
<samueldr>
so no "native" 32 bit ARM builds, and no 32 bit KVM vms
<Gaelan>
indeed, I learned that the ard way
<Gaelan>
hard way*
* samueldr
grumbles
<samueldr>
to "properly" support kexecing into a generation, I need to load the dtb for the generation the system is booting into
<samueldr>
which is something the kernel doesn't deal with itself, does not even provide facilities to know which filename it prefers
<samueldr>
so it looks like I have to somewhat duplicate some of the work u-boot had to make
<samueldr>
and add manual mappings between devices and dtb filenames
<samueldr>
going to even require runtime bits to abstract
<samueldr>
e.g. the pinephone will require reading /proc/device-tree/compatible and interpreting from pine64,pinephone-1.0 -> allwinner/sun50i-a64-pinephone-1.0.dtb, and following names
<samueldr>
do y'all know if there's a "jq, but for dtb files"?
<gchristensen>
I need to get used to codium for real
* colemickens
is actually finally improving his vim setup+skills after a decade of refusing to invest more than 10 minutes on it. It's not as hairy as I remember it being long ago.
<samueldr>
I basically only want to go to the root compatible string
<samueldr>
equivalent to /proc/device-tree/compatible
<clever>
that should be easy, just fdt_getprop i think
<samueldr>
yeah, though what might be harder (not that hard) will be the ffi bindings and binary tool to handle that, at least, requires more effort than I have the will to conjure right now :)
monk has left #nixos-aarch64 ["Error from remote client"]