<jslight90> I've tried a few different aarch64 SD images from Hydra.
<samueldr> you should be able to boot in a working generation still, right?
<samueldr> if you `uname -r` from there it should print the kernel version it's using
<samueldr> (I don't have a B+ to test, only a B, and last I tried earlier this month everything was working as expected))
ryantrinkle has quit [Ping timeout: 268 seconds]
<jslight90> Yes, I can still boot into Configuration 1. It's showing kernel version 4.19.67.
<samueldr> right, try commenting out `boot.kernelPackages = pkgs.linuxPackages_latest;` (or removing it)
<jslight90> Removing "boot.kernelPackages = pkgs.linuxPackages_latest;" seems to have fixed it.
<samueldr> ah, then something is up with 5.2
<samueldr> ...
<samueldr> I think I know what it is
<samueldr> with the release of the A+ things moved around in u-boot and the kernel
<samueldr> on stable (19.03) the u-boot would be too old
<samueldr> hmmm
ryantrinkle has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
<jslight90> I tried adding your u-boot commit (https://github.com/NixOS/nixpkgs/commit/ba6f1a1e829fb691e1577d630077db2ca3b611e2) to my NixOps patches but it still hangs at "Starting kernel...".
ryantrinkle has quit [Ping timeout: 246 seconds]
<samueldr> that might not be enough
<samueldr> (or recent enough)
<samueldr> I'm not sure that's the issue, but it's something I have in the back of my mind
ris has quit [Ping timeout: 245 seconds]
vika_nezrimaya has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 244 seconds]
THFKA4 has quit [Ping timeout: 250 seconds]
THFKA4 has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
tilpner has quit [Quit: WeeChat 2.4]
Thra11 has quit [Ping timeout: 246 seconds]
tilpner has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
orivej has joined #nixos-aarch64
wildtrees has joined #nixos-aarch64
wildtrees has quit [Remote host closed the connection]
wildtrees has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
Thra11 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
clever has quit [Ping timeout: 272 seconds]
clever has joined #nixos-aarch64
orivej has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
<vika_nezrimaya> So. RPi2, want to use GPIO. Can't find modules exposing it. Which kernel package do I need to use to get Raspberry Pi Foundation's kernel? Is it even packaged?
<vika_nezrimaya> or maybe I'm not looking in the right direction?
<vika_nezrimaya> or maybe NixOS doesn't support it at all yet?
<vika_nezrimaya> (i could make an Arduino sketch to drive pins controlled by serial I/O, but... then I'll have to buy 5V leds :3)
<vika_nezrimaya> aaaand I'll lose my UART
<samueldr> vika_nezrimaya: linuxPackages_rpi
<samueldr> though you're in uncharted (by me) territories with those kind of things
<vika_nezrimaya> means no one used it in production yet?
<vika_nezrimaya> well I'll just have to be the first one!
<samueldr> I meant that _I_ haven't had experience with those bits :)
<gchristensen> our productions must just be different :)
<samueldr> I think that some other users are using the _rpi kernels with the 3B and misc. hardware accessories
<vika_nezrimaya> What about RPi 4?
<vika_nezrimaya> does anyone here have it?
<vika_nezrimaya> does it work with NixOS?
<samueldr> its aarch64 support isn't quite there yet
<samueldr> the foundation only supports 32 bit stuff
<gchristensen> eh?
<gchristensen> oh
<gchristensen> rpi foundation
<samueldr> though yesterday some users have had a breakthrough in making it all work
<samueldr> yes, sorry, a bunch of foundations around lol
<gchristensen> :D
<vika_nezrimaya> Because 32-bit GPU stuff isn't easy to drive from 64-bit userland
<samueldr> I don't think that's it
<samueldr> it's mostly because they can ship one image that supports 2 through 4
<samueldr> and the software written continues working
<vika_nezrimaya> mostly, yeah, but also the 32-bit vs. 64-bit too IIRC
<samueldr> which, in a way, it's what they sell: the ecosystem
<samueldr> in what way is it "32 bit vs. 64 bit"?
<vika_nezrimaya> Something-something the Videocore GPU is 32-bit, I don't remember where I read it but I think that's one of the barriers to getting fully 64-bit userland to be production-ready
<vika_nezrimaya> I need to find it
<samueldr> could be, though I haven't seen anything like that
<clever> vika_nezrimaya: the problem is that the structures for passing messages to/from the gpu, have 32bit fields for pointers to userland resources
<samueldr> what I know happens is that by shipping 32 bit images for all boards, compatibility with existing stuff is maximized
<clever> so when you get a reply from the gpu, you can find the userland resource that wanted the reply
<clever> and it would take a major rewrite of the gpu firmware, to support 64bit stuff in that field
<vika_nezrimaya> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md - here is stated that Videocore VI is 32-bit
<clever> but, x86 has a solution for this already
<vika_nezrimaya> clever: you mentioned firmware, means that we'll have to wait for Raspberry Pi foundation to do something for GPUs to work in aarch64 userland?
<clever> vika_nezrimaya: there is a userland work-around for it
<vika_nezrimaya> Is it usable on NixOS? :3 can I try it once I lay my hands on an RPi4?
<samueldr> vika_nezrimaya: the GPU work with aarch64 userland... with the mainline kernels
<vika_nezrimaya> >.<
<samueldr> the 3B and 3B+ work
<vika_nezrimaya> but 4 has true gigabit ethernet and 2 usb 3.0 ports...
<samueldr> though it's an entirely different implementation for the driver, compared to the rpi foundation one
<samueldr> and as far as rpi 4 support
<samueldr> it'll come
<vika_nezrimaya> so it's either GPU or GPIO for RPi 4
<samueldr> though with all the same caveats for using the mainline kernel vs. the rpi foundation kernel
<vika_nezrimaya> unless I manage to make a frankenstein monster out of two
<samueldr> I don't follow
<{^_^}> raspberrypi/firmware#550 (by grigorig, 3 years ago, open): AArch64 support
<clever> found it
<clever> i could swear i commented on this issue.....
<samueldr> you did
<clever> ah, 24 hidden comments!
<samueldr> github helpfully hides comments
<samueldr> because who would go and read those?
<clever> there it is, the x86-only MAP_32BIT flag for mmap
<clever> this forces the linux kernel to allocate something in the 1st 4gig of the address space
<vika_nezrimaya> RPi 4 only has 4G RAM. Hm
<clever> that lets you safely truncate the 64bit poiner to 32bits, and shove into the "32bit only" fields for the GPU api
<clever> vika_nezrimaya: virtual address space
<clever> with a minor change to the userland drivers for the rpi (and a major? change to the linux kernel), full 3d accel can work
<vika_nezrimaya> I'm using it headless anyway
<vika_nezrimaya> but I do plan on getting one as a workstation one day
<clever> if your headless, you can just ignore the gpu problems, and run a 64bit os
<vika_nezrimaya> yay
<samueldr> clever: I don't really understand all that; is it that the mainline vc4 driver doesn't do some of the GPU things that it doesn't seem to have issues?
<samueldr> (searching for anything mainline and raspberry pi is just so hard)
<clever> samueldr: last time i looked into the problem (3 years ago), the api between the linux driver and the firmware in the gpu, involved strucutres that have a 32bit opaque field in them
<clever> and the userland libraries then put pointers to things on the heap in that field
<clever> so when it gets a message back from the gpu side, it can find the thing on the heap that has context on what it was doing
<clever> but once you have a 64bit userland, your pointers dont fit anymore
<samueldr> bleh, I just think I need to actively check on hardware instead of searching
<samueldr> to see what's happening
<vika_nezrimaya> wait, I seem to have /dev/gpiochip0 on the mainline kernel
<vika_nezrimaya> is that how I could interface with RPi 2's GPIO on mainline kernel?
<samueldr> it's possible; I have no experience though
<vika_nezrimaya> samueldr: seems so, but I need three tools from kernel source folder
<clever> vika_nezrimaya: the gpio also shows up under /sys and can be controled from bash
<vika_nezrimaya> It doesn't for me
<vika_nezrimaya> Was the first thing I tried
<vika_nezrimaya> But worked on Raspbian
ris has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 272 seconds]
Thra11 has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
Thra11 has quit [Ping timeout: 244 seconds]
orivej has quit [Ping timeout: 245 seconds]
<lopsided98> vika_nezrimaya: You can use gpioget/gpioset from libgpiod
<lopsided98> NixOS does not enable CONFIG_GPIO_SYSFS, which is why they don't show up in /sys
<lopsided98> Related to the GPU, I have run a partial 32-bit userland on a 64-bit kernel to do hardware video encoding on an RPi 3
<lopsided98> The 32-bit compat ioctls are not that well tested - I ran into a kernel bug that caused a major memory leak (fixed now)
<vika_nezrimaya> lopsided98: if that's possible... then everything's great
<vika_nezrimaya> lopsided98: except libgpiod needs a configure flag to compile on RPi successfully
<lopsided98> on aarch64?
<lopsided98> I just tested it on armv7l and it built fine
<vika_nezrimaya> x86_64 -> armv7l. I assume that's because cross-compiling is weird :p
<vika_nezrimaya> s/on/for
<vika_nezrimaya> please forgive me
<vika_nezrimaya> I don't compile stuff on armv7l natively because I can't compile even the stdenv for it
<lopsided98> yeah, I'm working toward toward cross built NixOS too, but for now I have an ODROID-XU4 dedicated to armv7l builds