lopsided98_ has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
mthst has joined #nixos-aarch64
<mthst>
hello. i installed nixos on my raspberry pi 3 by writing an aarch64 image from hydra to a micro sd card. it boots fine but after i begin typing the screen goes black.
<mthst>
unplugging and replugging the HDMI cable fixes it for some time, then it goes black again.
<mthst>
i've made sure it's plugged in well on both ends. i've also tried another cable, to no avail.
NickHu has joined #nixos-aarch64
<NickHu>
Is this the right place to ask questions about NixOS on ARM, even armv7l?
zupo has joined #nixos-aarch64
mthst has quit [Ping timeout: 252 seconds]
mthst has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<mthst>
never mind, it works now, on a different screen.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
<samueldr>
NickHu: sure
<samueldr>
mthst: it could also be due to the power supply not providing enough power; the raspberry pi 3 family often exceeds the limits that usb power supplies can deliver :/
jtojnar has quit [Quit: jtojnar]
<clever>
samueldr: the more modern rpi's also disable the power LED when the voltage drops too low
<clever>
so you can easily see if the voltage is sagging
<samueldr>
the firmware does it or is it the kernel that's handling it?
<clever>
gpu firmware
<samueldr>
just asking since mainline might not do it
<samueldr>
then yeah, likely to do it
<clever>
it also shows a symbol on the video output
<samueldr>
yeah
<samueldr>
that symbol also causes headaches :)
<samueldr>
or caused*
<clever>
the symbol is also "better" then the led, because it has fadeout
<samueldr>
at one point the mainline vc4 modesetting drivers really didn't handle those notifications well, and would revert to the last u-boot messages
<clever>
if your sagging only happens 0.05% of the time, its hard to notice the led blinking off briefly
<clever>
but the symbol fades out, so it keeps popping back to fully visible
<samueldr>
or uh, last boot messages up to when the vc4 modesetting driver would kick in
<clever>
ahh
<clever>
that sounds problematic
<samueldr>
fun thing: even if the power supply is e.g. 3A, the cable could be the weakest link
<clever>
yeah
<clever>
voltage drop over the wire, at the given current
<samueldr>
I've had best success with my old blackberry playbook charger: it has a built-in cable so the ratings are for the whole device including cable
<clever>
ive been having trouble booting my rpi's lately
<samueldr>
(note that power issues are mainly for the 3 family, the 0/1 shouldn't have much problems with most higher power PSU, and the 2 I don't really know :/)
<clever>
ok, pi1 doesnt have the netboot firmware, needs an SD card...
<clever>
[1178705.727363] Buffer I/O error on dev sda1, logical block 260, lost async page write
<clever>
ok, scratch that SD card
<samueldr>
I try really hard not to use SD cards anymore for system stuff :)
<clever>
the plan is to have an SD card with ONLY bootcode.bin, and NOTHING ELSE
<samueldr>
yeah, and that's a good idea
<clever>
fdisk: cannot open /dev/sda: Input/output error
<clever>
scratch that card as well
<samueldr>
just like how I have this half-broken SD card with what I treat as a read-only install of tianocore
<samueldr>
used to boot UEFI on the raspi3
<samueldr>
it has a range of blocks that cannot be written to anymore, but the first few GBs are fine, so enough for the few tens of MB needed
<clever>
lol
<samueldr>
tianocore can handle usb booting from a slower to start usb hard drive, while the raspi3 firmware with usb boot enabled doesn't wait long enough
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
<clever>
having trouble finding an unused SD card that actually works, lol
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
<clever>
samueldr: :O, found a still-sealed SD card!, 8g
<samueldr>
you're in luck :)
<clever>
its no-micro, so it wont fit the newers pis
<clever>
/dev/sda1 8192 15564799 15556608 7.4G b W95 FAT32
<samueldr>
from my experience, older SD only cards tend to be a bit more reliable :/
<clever>
there is an SD card slot in my laptop, right by the USB i was using for the reader!
<samueldr>
eh, I've had more success with continuous use with usb readers/writers than built-in readers; for a while on my main laptop ejecting an SD card could eject the reader, and it wouldn't be usable until I rebooted
<clever>
lol
<clever>
samueldr: one of the usb cellular modems i have, will initially claim to be a usb cdrom drive
<clever>
autorun.inf will install the windows drivers
<clever>
if you attempt to eject the "cd" from the "cd drive" it will replug itself, and then claim to be a usb serial port!
<samueldr>
that's useful; drivers, at least good enough for basic use, are always at hand
<clever>
linux has the serial drivers out of the box
<samueldr>
reminds me of those U3 drives which have an initial partition that's showing itself as a CD-ROM
<clever>
so i just needed a udev rule to yell "go away" every time the cd appears
<samueldr>
at the time windows would happily run an autorun file from CD-ROMS, even usb ones
<clever>
then its just plain wvdial and you got internet
<clever>
auth was based on the ESN on the cell network, so no login prior to ppp
<samueldr>
never had the (dis?)pleasure to deal with usb modems, was never able to find any that I was sure that would work here; and definitely don't want to buy one from a telco considering how they will be locked and at one point they'd use those ridiculous pricing schemes specially for those
<clever>
the one i have was used by my dad, and its back from the days before wifi tethering
<clever>
when you had to do either usb tethering (serial port, ppp), or bluetooth tethering! (serialport, ppp, lol)
mthst has quit [Ping timeout: 264 seconds]
<NickHu>
So I'm trying to rebuild on armv7l, and basically the SD card doesn't have enough space for it. It's a bananapi with a SATA port and connected hard drives, so can I just copy contents the NIXOS_SD partition to a new partition on the hard drives and then boot the installer from that by editing /boot/extlinux/extlinux.conf?
<sphalerite>
NickHu: can't you use nixos-install from the SD card?
<NickHu>
Ah, potentially yes - but seeing as the nixos wiki made no mention of it I thought it might be broken or something
<sphalerite>
It depends™
<NickHu>
I'll give it a shot and see if it works
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 252 seconds]
<clever>
NickHu: i think its more that you cant boot arm machines from a cdrom, so the usual nixos-install procedure is never needed
<clever>
so nobody bothers to mention that it should still work
<samueldr>
clever: eeeeeeeer
<NickHu>
I see - if it works I'll update the wiki page accordingly
<samueldr>
clever: I should figure out how to burn a minimal iso to a dvd, and boot the raspbery pi from it just to spite you
<samueldr>
but first I'd need to figure out if I still have blank DVDs
<NickHu>
Just to confirm, no armv7l derivations are on cache.nixos.org right? I've seen things in the nixos-rebuild log which seems to suggest that it downloads stuff from there
<samueldr>
but the .iso can and will work where EFI boot can happen; which will become more and more the norm since there are efforts towards that
zupo has joined #nixos-aarch64
<samueldr>
there is no armv7l cache on cache.nixos.org
<samueldr>
it will download source files
<samueldr>
and of note about EFI boot, mainline u-boot supports EFI boot
<NickHu>
I don't think I can use EFI on my board
<samueldr>
if it can be coerced to wait for the DVD, it will boot; but the raspberry pi has tianocore, which I bet doesn't need to be coerced :)
<NickHu>
But I'm not super sure of the details
<samueldr>
NickHu: mainline u-boot? then in theory it can boot EFI, but for simplicity's sake, prefer the generic distro sd_image for u-boot
<NickHu>
Even still, you could boot the nixos installer on your pi and then install to an external USB HDD for root
<samueldr>
there is ni .iso build for armv7l yet, and grub right now has issues with armv7l which are fixed in git, but they haven't made a release yet
<NickHu>
Is git.denx.de the mainline u-boot?
<samueldr>
yes
<samueldr>
non-mainline are the forks from the different board vendors, which are generally stale and forked from a while ago
<samueldr>
hmmm, not really, it exists to handle bootloading from initial state up to some other OS
<NickHu>
And it does all the stuff that a BIOS on a typical PC would do before handing off to the kernel right?
<samueldr>
u-boot is kinda like a bios
<samueldr>
yeah
<samueldr>
but like a really featured bios
<samueldr>
and most boards will load that bios from storage at a fixed offset
<NickHu>
Because it's unified across a bunch of different devices right?
<samueldr>
it helps in getting more features, but that's not "because" it is unified, it's mainly that the ARM boards have been using that as a good base for booting
<NickHu>
So how does EFI fit into the picture? Do we want it essentially for the same reason UEFI is preferable to MBR booting or is there something more to it with ARM?
<samueldr>
u-boot can provide UEFI booting; just enough "services" (uefi terminology) to boot EFI things
<samueldr>
the main advantage is that this conforms to an existing specification, which is platform agnostic, and is already in use in many ARM systems
<samueldr>
almost everything server-y already boots UEFI
<NickHu>
I guess EFI provides a nicer path for device and peripheral initialisation perhaps
<samueldr>
not even, it still ends up using device trees, I think
<samueldr>
and u-boot handled initializing things
* samueldr
digs up SUSE's presentation
<NickHu>
What's the main difference we'd see from a usability standpoint if all the EFI stuff were complete?
<samueldr>
they are pushing hard to also add firmware storage built-in boards
<samueldr>
e.g. my Pine A64-LTS has a SPI NOR Flash which holds u-boot
<samueldr>
I can unplug every sd cards, eMMC and usb drives, and still boot to u-boot
<samueldr>
this means that it can boot "just like a PC"; I dd the UEFI aarch64 iso to a usb drive, plug it in, it boots just like a PC
<samueldr>
so, no need to add the platform-specific u-boot after flashing the system, the image is universal
<NickHu>
I see
<clever>
samueldr: the rpi boot rom, can also load firmware from SPI NOR flash, but there is none on the pcb, and the bootcode.bin doesnt know how to load start.elf from there
<samueldr>
IIRC it will from the compute modules, won't it?
<clever>
nope
<NickHu>
But it doesn't seem like a huge deal to dd over the u-boot binary over the installer image anyhow
<clever>
those use eMMC
<samueldr>
NickHu: until you want to boot the same image on three different boards
<samueldr>
imagine building something like a hydra builder machine image, and flashing it to three SDs, and having it boot on three wildly different machines; on x86_64 it's normal, but in ARM-land it's not usual... yet
<flokli>
gchristensen: sphalerite: nah, i know the machine might eventually be rebooted and loose state. go ahead :-)
<NickHu>
I see
<gchristensen>
this is part ofwhy "Raspberry Pi Linux" is a thing
<gchristensen>
well it'd be one thing if it was just a "marketing" thing to be so closely tied to raspberry pi (raspbian for example)
<gchristensen>
but it is also because all the boards boot differently
<samueldr>
a unique bootloading system, a unique hardware ecosystem, not entirely dissimilar, but just enough to not be directly compatible
<samueldr>
and another annoying bit; even on their 64 bit boards, they still only support 32 bit :/
<NickHu>
Are you talking about, say, a couple of years ago when you went out and bought a board you'd pretty much have to use whatever kernel provided by the manufacturer, and that would lock 95% of users into a very narrow selection of distros?
<gchristensen>
no
<gchristensen>
well, partly yes
<gchristensen>
but also because the hardware is different enough you can't just get "the YourFavoriteDistro.iso and boot it"
<samueldr>
device trees mostly "fixed" that; though it still takes time until it's supported right, but easier to support right
<gchristensen>
you have to get yourfavoritedistro-for-raspberrypi.iso
<NickHu>
I see
<NickHu>
gchristensen: But even without EFI, we can solve that with u-boot right?
<NickHu>
Sure, by perhaps flashing a different u-boot binary on top of the iso
<NickHu>
Is there a way to run nixos-install in verbose mode to give output similar to nixos-rebuild? My build failed for some reason but I can't tell from the tiny output it gives me
<clever>
SD card doesnt count as "extra hardware" ?
<samueldr>
clever: I hate you :D without the usual extra required hardware then
<NickHu>
Also, it shouldn't matter that / (which is NIXOS_SD) is low on memory should it?
<samueldr>
NickHu: hmm, it should have expanded on first boot
<NickHu>
samueldr: It did, but this is a 4GB SD card
<samueldr>
if it hasn't maybe pop it back into your computer and resize the ext4 partition
<samueldr>
ah
<samueldr>
it might, depending on what was needed to build and if /tmp had enough space
<NickHu>
Ah I guess it needs to build nix, throw it onto /mnt and then effectively chroot
<NickHu>
Perhaps it failed to build nix
<samueldr>
I'm not 100% positive, but I think that during install it will always use the /tmp from the booted system, and here it would be on the SD card, even during install
<samueldr>
I don't think it chroots the nix builds
<NickHu>
Can I mount /tmp onto my hard drive?
<NickHu>
I guess I'll just whack it into the fstab and reboot
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]