vcunat has joined #nixos-aarch64
Robbiedobbie has joined #nixos-aarch64
rob has joined #nixos-aarch64
rob has quit [Client Quit]
<Robbiedobbie> Does anyone know whether some special flags are needed to compile the kernel for the raspi0w? I am still trying to solve the kernel panic I get. The same image runs fine on the raspberry pi 1 (Without any further changes)
<Robbiedobbie> https://www.raspberrypi.org/documentation/linux/kernel/building.md suggests the same kernel should just support both raspi 1 and 0 (w)
ZoomZoomZoom has joined #nixos-aarch64
<ZoomZoomZoom> Hi everyone! Did anyone had any luck building gnutls for ARM? My build fails an SRP test.
<sphalerite> ZoomZoomZoom: 32 or 64-bit?
<ZoomZoomZoom> sphalerite, 32
<ZoomZoomZoom> I'm on orangepi
<sphalerite> ZoomZoomZoom: it works for me on my chromebook but not on a scaleway C1 server, I think it's got something to do with vector instructions
<sphalerite> I think my chromebook has NEON while the server doesn't
<ZoomZoomZoom> I'm not sure what depends on it in my config. I was just trying to upgrade and didn't install anything new. Will it ever appear in dezgeg's caches?
orivej has joined #nixos-aarch64
<sphalerite> ZoomZoomZoom: systemd has a transitive dependency on it
<sphalerite> I think it should be in the cache, for that reason… not sure though
<ZoomZoomZoom> sphalerite, Is there a way to pin a package to avoid it from upgrading?
<sphalerite> not really, since that affects everything that depends on it too
<sphalerite> what you can do is in your checkout of nixpkgs revert the commit that breaks it
<ZoomZoomZoom> Yeah, that would probably be the right decision. The thing is, I don't see any connected packages in the upgrade queue, just a couple of things like ffmpeg and such, which I don't mind upgrading. I understand it goes againt the distro philosophy, but pinning would be useful as a quick hack. It is on arch, for some packages like libreoffice, which I rarely use and don't mind skipping a minor version or two.
<sphalerite> it's not so much "this is against the philosophy" as "this is very impractical to achieve" :p
<sphalerite> maybe you could have a pinned nixpkgs version and grab the working version of gnutls from it in an overlay
<sphalerite> so like self: super: {inherit (builtins.fetchTarball {url = https://github.com/nixos/nixpkgs/archive/<rev>.tar.gz; sha256 = "…";}) gnutls;}
<ZoomZoomZoom> It could be practical as in a case I've mentioned, where the package in question isn't really a dependency but just an end-user piece of software.
<ZoomZoomZoom> Yep, thank you, that's what I'll probably end up doing.
<sphalerite> but I have no idea how nicely that will play along with stuff since this could result in multiple versions of glibc being linked into a single application
<sphalerite> I don't mean "practical" as in "useful", I mean practical as in achievable
<ZoomZoomZoom> Ah, right.
<ZoomZoomZoom> I'm just a kind of user who likes having an easy-to-use option to shoot myself in the leg.
<ZoomZoomZoom> If arm was supported I'd much prefered to get to the bottom of it and fix the failing test, though.
<sphalerite> your use case is *perfectly* valid
ZoomZoomZoom has quit [Quit: Leaving]
<Dezgeg> Robbiedobbie: hmm, there is a separate u-boot build configuration available for the rpi 0, maybe building that and having config.txt conditionally load that could fix u-boot
<Dezgeg> also the linux_rpi package is quite old by now, maybe there are fixes in newer releases
<Robbiedobbie> I've built my own uboot for the zero, and that indeed works fine (Both on the zero and the 1 actually...)
<Robbiedobbie> The problem is now indeed the kernel. I'm trying to build a newer one with the linux_rpi package, but the pi 1 is quite slow unfortunately :|
<Robbiedobbie> How do you manage to build all those armv6 packages?
<Dezgeg> I build it on the faster v7 (Jetson TK1) machine
<Robbiedobbie> I tried building from my rpi3b+ (Would be quite a bit faster) but I didn't manage to build certain packages because they assert armv6, how can I work around this?
<Dezgeg> good to hear the u-boot works, I will add a [pi0] section to config.txt to load that
<Dezgeg> building from 64-bit will currently fail most likely, unfortunately
<Robbiedobbie> I tried building it from the 32 image
<Dezgeg> then nix-build -A linux_rpi --argstr system armv6l-linux should do it
<Robbiedobbie> Hmmz, I'll see if I missed something last time then
<Robbiedobbie> Thanks for the help so far!
vcunat has quit [Ping timeout: 256 seconds]
vcunat has joined #nixos-aarch64
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-aarch64
<Dezgeg> Robbiedobbie: can you try if this image works on the rpi0? http://cs.helsinki.fi/u/tmtynkky/nixos-sd-image-armv6l-rpi0-fix.img
<Dezgeg> it has the 4.14 raspbian kernel + u-boot for rpi0
vcunat has quit [Ping timeout: 255 seconds]
vcunat has joined #nixos-aarch64
vcunat has quit [Ping timeout: 256 seconds]
vcunat has joined #nixos-aarch64
<Robbiedobbie> I just tried, and the bootloader runs fine, and the device tree is also fixed, however the new kernel does not boot on the zero w at all
<Robbiedobbie> The bootloader hangs on starting kernel, and after a while, the display blanks. The led is flashing an error code it seems, though it does not look like one described by the raspi org
<Robbiedobbie> On the 1 the same kernel runs fine
<Robbiedobbie> The old kernel would run up until mounting the sd, after which it would panic
<Dezgeg> huh, that was unexpected
<Dezgeg> can you double-check if there is a /var/log/journal ?
vcunat has quit [Quit: Leaving.]
<Robbiedobbie> I will check tomorrow morning. I will also see if I get output on serial then :)
efraim has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
efraim has joined #nixos-aarch64