Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 260 seconds]
<gchristensen> ##Linux is guessing that Linux thinks the initrd is a ramdisk ,not cpio. [ 11.527696] RAMDISK: incomplete write (7341 != 32768)
<gchristensen> 00:46 <kfrench> gchristensen: Yeah. I'm thinking it thinks it's a rd. I bet your 1.3gig image doesn't have the word "RAMDISK" in dmesg.
<gchristensen> and indeed it does not
<gchristensen> $ zstd -19 ./initrd -o initrd.zstd.19
<gchristensen> it is possible that -19 was too much
<clever> gchristensen: i ran into similar weirdness, when i was implementing initrd support in my rpi bootloader
<gchristensen> oh?
<clever> when i claimed the size of the initrd was something it wasnt
<clever> the kernel couldnt parse it as one thing, then assumed it must be something else
<gchristensen> (wait, zstd isn't going to work)
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
ryantrinkle has quit [Ping timeout: 246 seconds]
<fps> srk: so you say that one doesn't really need the binfmt qemu wrapper trick to build a rpi4 image?
Acou_Bass has quit [Ping timeout: 264 seconds]
Darkmatter66_ has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
Darkmatter66 has joined #nixos-aarch64
<srk> fps: depends
<srk> fps: I'm trying to cross compile the image for armv7 and it looks good but not quite 100% there, I've had to switch to staging which now has issues with gdk-pixbuf :)
<srk> fps: it should work and is probably way faster than emulated
orivej has joined #nixos-aarch64
<sphalerite> gchristensen: oh! How are you making the initramfs? istr something about it being very finicky about paths, and my attempt at doing it manually got it wrong while mkInitrd worked
<sphalerite> something about the exact way in which cpio is invoked
<fps> srk: hmm, what about that comment from the wiki though: "At this moment in time (early 2018) only AArch64 is planned for full support upstream."
<fps> doesn't it make more sense to go with aarch64 then instead of armv7
<srk> dunno, we're fixing armv7 as well
<fps> ok
<srk> but it has few issues .. /nix/store/3b3ighb83nhifa1v4n7855hlbdl1mhf9-binutils-2.31.1/bin/ld: cannot represent machine `arm'
<fps> actually the build using qemu-binfmt seems to have succeeded. i havent' tried booting it yet though ;)
<samueldr> this has all the quirks figured out to cross-compile an sd image
<samueldr> you'd have to tweak it to load the rpi4 specifics though
<fps> samueldr: oh nice :)
<samueldr> not verified in the last few weeks, but if my Mobile NixOS tells me it should still work for master
<srk> samueldr: most ;)
<samueldr> srk: new breakage?
<srk> I've had to switch to staging due to #86283
<{^_^}> https://github.com/NixOS/nixpkgs/pull/86283 (by Ericson2314, 4 days ago, merged): meson: Fix my mistakes
<samueldr> sounds like new breakage :)
<srk> yeah, it can't build systemd looks like it
<srk> was compiling all night long :D I'll grab a coffee and start looking into it\
<srk> and also gdk_pixbuf which is pulled due to environment.variables.GDK_PIXBUF_MODULE_FILE
<srk> hmm, ld attempted in systemd is a host one
zupo has joined #nixos-aarch64
<fps> hmm, the build takes ages in that cross-system. i'm still trying to get my head around all the things included by the installation-device.nix, sd-image.nix, etc..
<srk> :) it takes ages becuase there's a lot to crunch initially
<fps> and what kind of things one could disable to get like the smallest bootable image. kernel, systemd, agetty, bash, nix. please excuse my ignorance. long term linux user, but not experienced at all with cross compiles. nixos and building images for SoC's ;)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fps> srk: i guess once it's done and i don't do a nixos-rebuild switch --upgrade it should go faster next time, right?
<fps> since all the things are then available in the store already
<srk> yes, pretty much
<srk> environment.noXlibs = true;
<srk> if you don't need X helps too
<fps> oh. i'll add that to my checkout of cross-system
<fps> i guess for usb audio devices the alsa-firmware is also no needed, right? that should be mostly for pci(e) soundcards which need special binary blobs right?
<srk> not sure
<srk> ah, firmware, probably not
<srk> not needed
<srk> for usb you just need kernel modules I guess but that's covered by default multi_ config already
<srk> what's the rest of the stack btw? for the guitar effect
<fps> jack2, jalv, and a python3 web frontend with some small custom c++ apps
<fps> oh and dnsmasq/hostapd so one can connect to the wifi with a mobile device to tweak things
<fps> using a usb wifi dongle is fine if the wifi on the rpi4 doesn't work
<fps> and one major thing: a kernel with realtime-preempt patches ;)
<srk> nice!
<srk> musnix?
<fps> i have got the whole thing running on an arch image for the rpi4
<srk> ,musnix fps
<{^_^}> fps: Real-time audio in NixOS - https://github.com/musnix/musnix [see also #musnix channel]
<fps> but i really enjoy tinkering in guix and like the reproducible functional approach so i want to try and build the image in guix or nix. right now i opt for nix because it has some initial support for rpi4 :)
<fps> srk: thanks for that pointer
<srk> it can patch kernel for you but probably won't work easily with rpi4 one foundation kernel
<srk> but when it's switched to mainline it should just work
<fps> musnix looks useful, thanks
<fps> i heard that mainline still lacks some features like gpu support
<fps> i don't care much at all about hdmi outputs
<srk> yeah, me neither
<fps> so i would actually prefer a mainline kernel..
<srk> btw have you considered i2s soundcard?
<fps> in my initial experiments usb 2.0 class audio works fine with 128 frames/period and a realtime preempt kernel
<fps> on the rpi4, since the usb controller on it finally doesn't suck super hard
<fps> i have no experience with i2s soundcards
<srk> right, I have phatdac for a few years, need to try that with mainline now I have overlay support
<srk> looks like I'm gonna loose S/PDIF if I upgrade my workstation mobo so it might be good time to actually make it work
<srk> and then upgrade to something which has s/pdif .. :D
<fps> i also built a midi controller based on a teensy
<fps> that has a picture
<fps> please ignore all the repos, they are in a state of absolute mess..
<srk> cool, I wanna build a sequencer with stm32
<srk> foot switches, nice
<srk> mm
<fps> the nice thing about these usb interfaces is that they already come with high-z inputs
<srk> this would be even better then my current s/pdif to unbalanced setup
<fps> why reinvent the wheel? :)
<fps> it works, it's modular, what else would i want? :)
<srk> because it's usb -> i2s ;)
<srk> you don't need usb in the chain
<srk> (not suggesting you should either if usb works for you)
<fps> most of the i2s sound cards seem to be output only
<srk> just looking for better phatdac so I can switch to balanced outs for monitors :)
<srk> yeah, I have one that does input but it's for antennas not sound .. :D
<fps> hehe
<fps> they are a for a particular market it seems: people who want a music player
<srk> that is also the reason I've started experimenting with i2s as it had a base board with xmega which was basically usb->i2s bridge
<srk> but the firmware was badly outdated and it didn't work most of the time
<srk> and the goal was to add gps timestamping to audio samples which would have to be implemented in that archaic firmware
<srk> also jitter might be a bit worse on usb but I haven't tested that yet
<fps> yuk
<fps> i'm not an audiophile, which is a bonus for me :)
<fps> i do like my balanced cables, my yamaha monitors to listen to music, etc, but i never noticed usb jitter..
<srk> I'm not either but I don't like noise comming out of studio monitors as they are too sensitive and most internal sound cards are bad at that
<fps> yeah, those on the mobos like to catch the noise from the inside of the case..
<fps> so what's the expected ETA for this build run to finish on an 8 core machine [virtualbox guest on amd ryzen 1700x]?
<fps> a couple of hours or a couple of tens of hours?
<fps> :)
<srk> couple of hours, I've compiled two branches master and staging on two cores since yesterday
<fps> ok
<srk> finished \o/ /nix/store/1l194m4jl991qwfailya9fxcqqmy0k2p-nixos-sd-image-20.09pre-git-armv7l-linux.img-armv7l-unknown-linux-gnueabihf
<srk> altough this doesn't look good https://paste.rs/Fp0
<srk> fps: https://github.com/NixOS/nixpkgs/pull/53065 this contains few more minification tweaks
<{^_^}> #53065 (by matthewbauer, 1 year ago, merged): Raspberry Pi cross compilation branch
<srk> cool, looks like it's just a matter of using pkgs = pkgs.buildPackages instead of inherit pkgs; for extlinux-conf-builder
<srk> which probably answers my previous problem as well with system_boot and efi
<srk> No space left on device :D
<srk> lol, I've deleted steam game and it redownloaded it over night :D
<fps> ;)
<srk> ,cross
<fps> srk: hmm, i have a nixpkgs checkout here which seems to have those changes.. i guess the 20.03 channel doesn't :)
<{^_^}> cross defined
<srk> fps: my config was just based on older checkouts and compiled natively before
ehmry has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
doda has joined #nixos-aarch64
ehmry has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ehmry has joined #nixos-aarch64
<doda> hi guys, i installed nixos on my raspberry pi3, version 19.03.173694.27aaaa5ba69. I had issue with GPU not being available, fixed the issue by downloading a custom dtb file from an issue on github https://github.com/raspberrypi/linux/issues/3046
<{^_^}> raspberrypi/linux#3046 (by lategoodbye, 43 weeks ago, open): bcm2835-power: Timeout waiting for grafx power OK
<clever> doda: did you just solve my firmware problems.....
<clever> doda: i cant get video to work, due to power domains being off...
<doda> clever: hah :D, this is a really wierd error, i think it is related to board temperature, since before i found out this issue, Xorg started 2 times out of 10
<clever> doda: in my case, i'm using custom firmware, that doesnt do the gpu init
<clever> so i need linux to manage things more
<clever> and bcm2835-power might be the answer
<doda> ah, nice :D
<clever> drivers/mfd/bcm2835-pm.c: { .name = "bcm2835-power" },
<clever> drivers/soc/bcm/bcm2835-power.c: .name = "bcm2835-power",
<clever> arch/arm/boot/dts/bcm2835-rpi.dtsi: compatible = "raspberrypi,bcm2835-power";
<clever> Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt:- compatible: Should be "raspberrypi,bcm2835-power".
<clever> 2 source files, a dts to enable it, and dts docs
<clever> 5 * This driver binds to the PM block and creates the MFD device for
<clever> 6 * the WDT and power drivers.
<clever> 6 menu "Multifunction device drivers"
<clever> ahh
<clever> drivers/soc/bcm/bcm2835-power.c looks like the complete driver
<clever> 595 static const char *const power_domain_names[] = {
<clever> 596 [BCM2835_POWER_DOMAIN_GRAFX] = "grafx",
<clever> 597 [BCM2835_POWER_DOMAIN_GRAFX_V3D] = "v3d",
<clever> 378 return bcm2835_power_power_on(pd, PM_GRAFX);
<clever> yeah, this is definitely driving it directly
<clever> 227 if (PM_READ(pm_reg) & PM_POWUP)
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
<fps> if a nix set has an expression like pkgs.linuxPackages_rpi4 is there any clue about where to find this in the nixpkgs tree?
<fps> pkgs itself is a set which i guess contains the values of all the packages in the nixpkgs repo
<fps> i can recursively grep for it, but that's no fun
<hexa-> usually ripgrepping nixpkgs is a good approach
<fps> top-level/all-packages.nix: linuxPackages_rpi4 = linuxPackagesFor pkgs.linux_rpi4;
<fps> aha
<hexa-> 16632: linux_rpi4 = callPackage ../os-specific/linux/kernel/linux-rpi.nix {
<fps> yeah
<qyliss> You can also use nix edit
<qyliss> (Probably with -f .)
<qyliss> Which will open an editor for the given attribute path
<fps> oh nice
<fps> soo, there's also this file in nixpkgs: sd-image-raspberrypi4.nix
<fps> which uses the raspberry pi foundation kernel
<fps> which is fine with me
<fps> running this in the nixpkgs top directory: nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix -A config.system.build.sdImage --argstr system aarch64-linux
<fps> seems to do its thing :)
<doda> has anyone managed to play mpeg-4 videos properly on kodi on a raspberrypi 3?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fps> is there a reason for all this image compression and decompression during the builds? i guess it could save some time if the images just stayed uncompressed :)
<samueldr> fps: hydra has size limits
<samueldr> an output cannot be bigger than 2GiB
<fps> hmm, ok
globin has joined #nixos-aarch64
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<fps> ok, that image seeems to have booted just fine. nice :)
<fps> now i can think about modifying it ;)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vika_nezrimaya has joined #nixos-aarch64