justanotheruser has quit [Ping timeout: 268 seconds]
justanotheruser has joined #nixos-aarch64
alp has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
<patagonicus>
I'm considering ordering a Pinebook Pro soon (just to play around/as a laptop for traveling that's inexpensive) - how important are the serial adapter and the USB eMMC adapter? I'm guessing usually you're still able to use MicroSDs to recover a non-booting system, right?
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
<Ke>
if you can do it blind, sure
<Ke>
many people do not need it, but if you would be debugging issues, you might
<samueldr>
the eMMC adapter: not needed
<samueldr>
serial: could be helpful if you hit a snag
<samueldr>
though you can cobble one together quite easily
<Ke>
I guess if you install bootloader on the eMMC and fail the eMMC can only be reset by epic hacking
<Ke>
never install bootloader on eMMC
<samueldr>
what?
<samueldr>
what do you mean by epic hacking? turning off the eMMC switch and turning it back on is easy enough
<Ke>
at least I don't know of a good way to reset the eMMC
<samueldr>
(though does require removing the back panel)
<Ke>
you can maybe connect the eMMC after boot and modify software to probe it after reboot is done
<samueldr>
SPI is a bit more involved if somehow you have a bad program in there, as it seems there is a hardware bug with the switch, so you need to tie one of the SPI chip's leg (not chip enable, but something akin)
<Ke>
how do you get linux to probe the eMMC
<Ke>
I guess you can connect it before booting linux after bootin u-boot
<samueldr>
tbf I didn't have to on the PBP, but with other pine hardware with the same eMMC interface I did and I don't recall having any problem...
<samueldr>
... probably did it like you said incidentally; before Linux started
<samueldr>
though yeah, if the u-boot setup works fine on SD, I believe it's about 99.99% safe it'll work on eMMC
<samueldr>
sams u-boot config for SPI could be broken though! (from experience)
<samueldr>
same*
<samueldr>
though I'm pretty confident that if it works for someone on SPI, it's hard to have it break randomly for others
<patagonicus>
Hmm. Sounds like I might as well just order them along with the laptop as they're cheap (though I think they'll be shipped separately). Just for peace of mind, I guess.
<patagonicus>
On a related note: what's the state of moving aarch64 and arm7 up on the Nixos support tier list? What's currently the limiting thing?
h0m2 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
<patagonicus>
Maybe I was overly optimistic about the ordering soon bit, the PBPs are out of stock again. :D
ib07 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
<bigvalen>
Hey, I downloaded and booted an RPi2 image. All good. There is no configuration.nix or hardware-configuration.nix though. Is it OK to run nixos-generate-config and re-run nixos-build ?
<patagonicus>
bigvalen: Yep.
<bigvalen>
Cool. Hoping it won't brick the box. :)
<patagonicus>
Good thing about the device is that you can just reflash the SD card. I don't think there's a way of bricking a RPi2 with just software.
<srk>
where does the image come from?
<clever>
patagonicus: there are ways to brick it with software, but you have to go really out of your way
<clever>
patagonicus: you need to build a whole cross-compiler toolchain for the gpu, then build a custom firmware, and then use the OTP write commands
<patagonicus>
Ok, right, I forgot about the GPU. I was thinking about the bootcode updates for the RPi4, which make it a bit easier to brick, I think. But I only have RPi1s and 3s.
<clever>
patagonicus: pi4 can be soft-bricked by erasing the eeprom, but recovery.bin can unbrick it
<clever>
patagonicus: however, OTP can also be used to disable recovery.bin, then you run into problems...
superherointj has joined #nixos-aarch64
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-aarch64
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
<bigvalen>
Hmm. On doing a nixos-rebuild --upgrade, my box is getting loads of source tarballs (m4, xz). Is that expected ? I thought, given I'm just using 20.09, it'd use cache.nixos.org.
<patagonicus>
Sorry, but 32 bit ARM doesn't have official binary caches. It's either building yourself or using some community cache (never looked into those, but my machines are more powerful than a RPi2, so building isn't the end of the world).
<bigvalen>
ah, OK.
<bigvalen>
I'll just...wait a while :)
<patagonicus>
compiling works on Nix.
<patagonicus>
You could instead cross-compile your system from a powerful x86 system - it'll still take some time and some things don't like being cross-compiled, but it's most likely faster than building on the RPi2. Downside is that you won't be able to really use nix on the RPi2 then, because that'll trigger a rebuild of everything because of how cross
<patagonicus>
So, I have a system with a few small servers set up, but no desktop environment. I think my 4 odroid HC2 need about 12h to compile it. It's not massively distributed among them, but each of them is an octacore ARM chip.
<srk>
it might take a week to bootstrap from scratch on pi2 :)
<patagonicus>
And every update to something like gcc or coreutils or similar will require a full rebuild.
<srk>
or maybe even few weeks, depending on config :D
<patagonicus>
Oh, also, I don't think coreutils will build with current nixos, although I'm on unstable, not 20.09.
<patagonicus>
So, yeah. Strong recommendation to look into cross-compiling or getting a more powerful arm machine to build for the RPi. :D
<srk>
with master? I was looking at thefloweringas|h`s caches and even unstable looks weird
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bigvalen>
Yeah, I'd built the image on my desktop initially. But that was months ago. Just realised that 20.09 is out now, so may as well move to stable. Huh, I didn't realise perl was in the base image.
zupo has joined #nixos-aarch64
<patagonicus>
I'm a bit behind master, maybe a week or so, but it started a while back. Someone linked me to an upstream bug report and I have my nixpkgs patched - it's just removing a few assertions that don't work on arm. But there's a couple of other packages that use the same tests, so you also need to patch those.
<srk>
configuration.nix has both nixpkgs.localSystem and nixpkgs.crossSystem set for it to work
Acou_Bass has quit [Ping timeout: 240 seconds]
<patagonicus>
bigvalen: If you want I could look into making my machines act as a binary cache on the weekend - I think I managed to not have secrets leak into the nix store :D - but then you'd also have to use a version of nixpkgs with my patches otherwise the hashes wouldn't match.
Acou_Bass has joined #nixos-aarch64
<bigvalen>
I think I'll just suck-up the slow crosscompile.
<bigvalen>
I don't really understand how the nixos community hardware is funded. Where are the issues ? Is it getting hardware, paying for hosting, or what ?
<bigvalen>
I might be able to donate some hardware. But I suspect power/network is the real problem.
<srk>
real problem is trust (security of the devices) ~ maintaining such buildfarms
<srk>
aarch64 builds on server hardware in datacenter, not much of armv7l server hw leads to attempts to use 64bit system to run 32bit vm which has its own issues
<srk>
cross compiling is not slow, you just need to build quite a lot typically
<srk>
but some cross compiled stuff is cached on hydra (even for armv7l)
<thefloweringash>
I think the 32-bit vm is mostly constrained by size issues from the deployment model, but I haven't looked in a while
<thefloweringash>
cross compilation might even be a little bit faster since it doesn't run the tests
<patagonicus>
I'm guessing I can't donate to NixOS specifically for 32-bit arm support, can I?
<patagonicus>
As in with money. I know I can donate time to fix broken builds and documentation. :)
<gchristensen>
is the community builder busted?
superherointj has quit [Quit: Leaving]
<gchristensen>
just wondering b/c I got a page for ofborg aarch64 builds
<{^_^}>
#66741 (by lopsided98, 1 year ago, open): perlPackages.ModuleBuild (a dependency of git) fails to cross-compile
<bigvalen>
srk, thanks for explaining. I sorta have something similar to do (setup build/test farms for coreboot/linuxboot). I won't have as much of a security issue, as a system that's emitting binaries that thousands of people run.
<patagonicus>
Well, doesn't really make sense on x86, does it? :D
<srk>
something like platform.isRPi :|
<srk>
no but it doesn't make sense on all other Aarch platforms except rpi too :D
alp has quit [Ping timeout: 246 seconds]
<patagonicus>
Yeah, would be nice to have individual platforms for the common boards.
justanotheruser has quit [Ping timeout: 264 seconds]
alp has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
tilpner has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-aarch64
das_j has joined #nixos-aarch64
Akira[m] is now known as cirno[m]
rajivr has quit [Quit: Connection closed for inactivity]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
pbb has quit [Ping timeout: 240 seconds]
kloenk has quit [Ping timeout: 272 seconds]
kloenk has joined #nixos-aarch64
pbb has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
alp has quit [Ping timeout: 264 seconds]
tilpner has joined #nixos-aarch64
alp has joined #nixos-aarch64
<andi->
I'm having a weird issue with a RPi3.. the HDMI audio output is at half the playback speed regardless of audio source (mpv, spotifyd, …). Anyone has an idea? The internet seems to throw random config changes and reinstalls onto the problem..
<andi->
I am currently about to throw it out the window again.. A known good configuration doesn't boot anymore.
<sphalerite>
andi-: stereo interpreted as mono?
<sphalerite>
No idea what to do about it though. Are you using pulseaudio?
<andi->
I never have luck with these little beasts. I used a never used RPi3 that I had packaged, a new SD card, an a 2A power supply.. And within 3h the device went from "boots just fine and sometimes glitches" to "stuck on the boot screen after reboot"
<andi->
sphalerite: yeah
<sphalerite>
have you tried all the different profiles on the configuration tab in pavucontrol?
<andi->
yep
<andi->
after randomly switching back and forth it started outputting in half the speed
<sphalerite>
have you tried setting it on fire and replacing it with an x86 board?
<andi->
that is the next step.
<andi->
I actually replaced the board with another board
<andi->
and the issue is the same so I am certain it isn't the board.
<andi->
Maybe those 2x I had to reset it did already kill the SD card...
<sphalerite>
clever knows things about rpis, maybe there's some secret firmware state you can kill.
<sphalerite>
well, the SD card (at least the software on it) should be easy to verify with nixos, right?
<sphalerite>
I do remember having exciting problems with gcc as a result of a broken SD card though.
<samueldr>
there's always that asoundrc state file
<andi->
I can just flash it again and copy the closure on it..
<andi->
That is why we are doing this NixOS thingy right? Hardware sucks.
<samueldr>
though don't worry too much: I hate the raspberry pi too
<sphalerite>
also use a USB stick, they're much more reliable :p
<sphalerite>
or USB HDD
<samueldr>
USB HDD might be too slow to start
<samueldr>
and USB boot has inconsistencies between 3B and 3B+
<andi->
anything USB for storage is a no-go... I never bought those things for anything and do not intend to start doing so..
<samueldr>
3B you'll also need to burn uses
<samueldr>
burn fuses*
<samueldr>
though USB is much more reliable than SD with those platforms
<samueldr>
a workaround, verified to work well with the 3B, is to install Tianocore on a microSD card you'll keep mostly read-only
<samueldr>
and then you can use a slow usb drive, with a bog standard uefi install
<samueldr>
It's a UEFI system! I know this!
<andi->
I wonder why non of my config.txt changes are on the sd card..
<samueldr>
if you're using the default mainline-based image, the FAT32 partition which holds the config.txt file will not be mounted
<samueldr>
because it's treated as an opaque install of u-boot
<andi->
ah ok
<samueldr>
since this is the common denominator for mainline support
<samueldr>
yeah, it's annoying, but the bizarro boot chain from the pi foundation is actually harmful to the ARM ecosystem :)
<andi->
I did copy the example config from nixos.wiki to start out but apparently that doesn't use uboot?! it just disables grub and generix-extlinux-compatible.enable ` true
<samueldr>
that's u-boot
<samueldr>
it reads the extlinux-compatible format
<andi->
Weird, is that the same uboot that is activated via boot.loader.raspberryPi.uboot.enable = true; ?
<samueldr>
no and yes
<andi->
/o\
<samueldr>
sorry :)
<samueldr>
a lot of efforts from before my time were made in parallel into doing things differently
<samueldr>
and I've not had the time to document those more in depth
<samueldr>
but basically we have two "worlds" for raspberry pi
<samueldr>
the managed and the unmanaged "firmware" partition world
<samueldr>
in the "managed" world, the NixOS configuration will edit that FAT32 partition, maybe boot u-boot, maybe directly boot kernels
<samueldr>
this works *extremely* differently than other ARM SBCs
<andi->
Isn't that true for most ARM boards?
<andi->
I think I've never had a consistent experience across vendors.
<samueldr>
not in that manner
<samueldr>
that's managed *specially* for the raspberry pi
<samueldr>
then we have the default mainline builds, which *happens* to ship with the "unmanaged" u-boot firmware for raspberry pi pre-installed
<andi->
also in /boot should be a config.txt that the activation script writes (in both generic and uboot case) but it isn't there...
<samueldr>
that's because installing the firmware for raspberry pi is quite inconvenient
<samueldr>
only if you're expecting to "manage" the firmware partition
<samueldr>
this is way more messy because of the way the raspberry pi foundation does things
<samueldr>
so yeah, we're dealing with "unamanaged raspberry pi firmware" with the mainline build because every other platforms work way closer to that way
<samueldr>
brb
<samueldr>
really, the sd image is meant to be generic, until we have staff paid to work and produce well-maintained board-specific images, this is the only way forward
<andi->
Yeah, that is also good :-)
<andi->
I did just shut it down for a few minutes and now it at least switched the screen again after loading the kernel... the audio timeout spam is there still *shurg*
<samueldr>
my experience is *somewhat* limited with the pi platform because it's so frustrating to deal with
<samueldr>
I have experience with its boot chain, but further up? ugh
<andi->
What other board with HDMI are there that do not suck as badly? (I only need HDMI for audio…)
<samueldr>
I don't *actually* know :/
<samueldr>
and you could be having troubles specific to your hdmi setup too
<samueldr>
*could(
<samueldr>
*could* *
<samueldr>
(guh, keyboarding)
<sphalerite>
andi-: I have a nanopi m4, but haven't used its HDMI output at all. It's based on the RK3399 chipset though, which is pretty well supported and probably less painful than the rpi
<andi->
yeah, those sound really nice
<sphalerite>
there are various other rk3399 devices as well
<andi->
I just impurely edited the config.txt... maybe that fixes all my issues because previously I would change stuff and nothing would change..
* andi-
feels dirty
<sphalerite>
I can give the HDMI output a try on the nanopi if you want an experience report :)
<andi->
go for it!
<andi->
aha, color test screen after boot.. not sure if that is good or bad :D
<samueldr>
might be because u-boot couldn't boot if you made a mistake in the config.txt?
<samueldr>
the rainbow "isn't shown" with u-boot because it boots quicker than hdmi is ready
<andi->
No, it never wrote the things to dsk
<andi->
I did grep the entire sd card for my changes
<samueldr>
fun!
<andi->
they were just not there
<samueldr>
SD really doesn't help with all the headaches of the Pi
<andi->
(it is still showing the color thingy…)
<samueldr>
yeah, if it's stuck there it's not booting
<andi->
ffs
<andi->
but that means the firmware partition config.txt must have some influence..
<andi->
back to square one... flashing the SD card again
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #nixos-aarch64
<clever>
andi-: *waves*
<andi->
clever: hey :D
<andi->
clever: You'll be spammed with questions now, you know that, right ? :P
<clever>
yes :P
alp has quit [Ping timeout: 246 seconds]
<andi->
clever: how do I verify what config.txt is loaded when I'm in linux? I lost trust in all the things on this shitty device
<clever>
andi-: the firmware can only load config.txt from the root of a fat32 fs
<clever>
andi-: it doesnt matter what you put in /boot, it matters what you put in the fat32 fs
<andi->
yeah I did that
<andi->
I modified the conig.txt but I have no idea if that actually works
<clever>
which config flag are you trying to edit?
<andi->
i mounted /dev/disk-by/label/FIRMAWARE -> config.txt
<andi->
the dtb audio=on
<clever>
is that the exact string you put in?
<andi->
As my kernel is constantly spamming some bcm2835_audio timeout
<samueldr>
you could compare the output of `dtc /proc/device-tree` between with and without that line
<andi->
no, `dtparam=audio=on`
<clever>
andi-: do you want pwm audio or hdmi audio? which model? kms?
<andi->
clever: Pi3B & HDMI
<andi->
I probably also need hdmi_drive=2 ?
<clever>
andi-: try `dtparam=audio=off` and `dtoverlay=vc4-kms-v3d`
<andi->
ok
<clever>
andi-: hdmi_drive is only to help with a weak hdmi signal, it turns on a power amp
<clever>
it wont have any effect on error messages, only signal quality
zupo has quit [Ping timeout: 272 seconds]
<andi->
The timeouts are still happening, they seem to correlate with pulse not properly starting up :/
<clever>
this shows you the old expr, so you know how it works
<clever>
its just a plain fetchFromGitHub against raspberrypi/firmware, so override src and your done
<andi->
I am not sure that would work that way. That code that you linked to isn't executed during install as otherwise the config.txt would also exist in /boot (but not have an effect)
<clever>
which code isnt executed during install?
<andi->
I can probably just copy that to the FIRMWARE partition tho..
<clever>
if you flip the enable from extlinux to raspberryPi, and ensure /boot is mounted correctly, i expect the config.txt stuff to work better
<andi->
oh, it is still false /o\
<clever>
uboot tends to break everything dtb related
<andi->
ok, with /boot you mean the fat partition?
<clever>
yeah
<clever>
the fat32 must be on /boot/
<andi->
deploying...
<andi->
is extlinux able to read the kernel from the rootfs? /boot on the generic image isn't large enough to also keep a copy of them
<samueldr>
yes, that's what u-boot does
<clever>
but we are trying to switch away from uboot, because i suspect its breaking all of the dtparam's
<samueldr>
if you're going to use the pi bootloader, you'll have to produce a different image, or customize the image
<andi->
ok, so the mixed mode (NixOS managed firmware + extlinux) isn't possible
<andi->
I have one of those "how could this ever have worked" moments
<clever>
andi-: i think that, would be the uboot.enable
<samueldr>
not from the prebuilt image without resizing the partition
<clever>
rather then extlinux.enable
<clever>
andi-: but i think uboot is the problem
<samueldr>
well, it loads a specific FDT rather than re-use what the firmware gave it
<samueldr>
so yeah, makes sense
<clever>
yeah, it undoes all of the changes config.txt did
<andi->
So i'll have to create a new image with a larger /boot as nobody would want to use uboot?
<samueldr>
I would even say: it entirely ignores it, it just does the same thing whatever happened beforehand
<clever>
samueldr: yep
<clever>
andi-: yeah
* andi-
goes shopping for an x86 board
<clever>
andi-: there is also rpi-open-firmware
<clever>
andi-: in one of my builds, it has the ability to load files from ext2 (but not ext4)
<clever>
andi-: but a lot of if you can use it, depends on what you want to do with the pi
<andi->
I just wnated to listen to music.
* samueldr
looks at iPod
<clever>
audio and hdmi dont work yet on rpi-open-firmware
<andi->
yeeah.
<andi->
For just 10x more moeny I get a Ryzen R4300U but it will probably be setup in <1h /o\
<samueldr>
or you could do as everyone does with the raspberry pi and uses whatever binary blob barfed up by inscrutable builds other people share around
<samueldr>
I think it's built for that purpose in fact
<andi->
Maybe I do not need music.
pbb has quit [Quit: No Ping reply in 180 seconds.]
pbb has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]
alp has joined #nixos-aarch64
<andi->
clever: I updated to the latest firmware we have in unstable (via a custom activation script hack... https://github.com/andir/infra/commit/246d4f2c2a963a71375fcf3c9624a4c1649a24fc) and also updated the config.txt but that didn't really change a thing. Pulse is still stuck starting while the kernel spams the timeouts.