<samueldr>
it's because on sd-image-aarch64, at first boot, /nix/var isn't populated yet
<samueldr>
though, the hack you have seen isn't even really in use
orivej has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Ping timeout: 264 seconds]
lopsided98 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<sphalerite>
samueldr: aaah ok
FRidh has joined #nixos-aarch64
<exarkun22>
aarch64 on pi was so easy. armv7l is such a clusterfuck.
<exarkun22>
so sad.
FRidh has quit [Quit: Konversation terminated!]
<tilpner>
samueldr - ping
<samueldr>
tilpner: tilpong
<tilpner>
Hey, I had a few more questions regarding your pine64 deployment :)
<samueldr>
always ask :)
<tilpner>
1. You have enabled xserver with modesetting. Did you magically get the gpu working by using the special kernel fetched in your repo?
<samueldr>
no hw accel AFAIK, it was mostly a one-time test that I didn't elaborate on
<samueldr>
I was mainly checking how the perfs are on that board for things like chromium
<tilpner>
2. Did nixos-rebuild Just Work™ for you? I'm not sure yet what caused it, but when I nixos-rebuilt, my /boot partition was corrupted and remounted read-only, which of course prevented the rebuild from completing
<samueldr>
(which makes me think, I had chromium building, but never shared the patches, neither document it)
<samueldr>
nixos-rebuild just works every time on all my aarch64 boards
<samueldr>
the only issue I had was filling the FAT32 partition... which I now always side-step
<samueldr>
on both my raspberry pi (which boots via usb, completely sd-less) and my pine64 I applied those changes
<samueldr>
THOUGH, I must say I did have some weird corruption on my /boot partition..
<samueldr>
... which puts it in read-only
<samueldr>
maybe it's the sd-image-aarch64 that makes it weird?%
<samueldr>
I brushed it off as not-an-issue as anyways it's not in use anymore on my system
<tilpner>
Hmm, I was going to check if u-boot supports booting from ext4, but this single-partition layout looks even better
<samueldr>
u-boot does in fact support booting from ext4
<samueldr>
but I'm not removing the first partition
<tilpner>
But you could, right?
<samueldr>
simply removing the boot flag
<samueldr>
not on a raspberry pi, but elsewhere you could
<tilpner>
Why not on a pi?
<samueldr>
it boots using that partition :)
<samueldr>
the raspberry pi boot process is different than all those allwinner boot processes in that it loads files from a partition instead of looking at a pre-defined location on the storage device
<samueldr>
so, if you were to remove the FAT32 partition, and moving the second partition up, make sure not to overwrite that special location where you dd-ed the secondary bootloader
<samueldr>
:/ the aarch64 hydra builder may be over-burdened, not sure how, or probably more, who can check and confirm
<samueldr>
"simple" [citation needed] builds like the kernel timing out
<samueldr>
four hours
<tilpner>
I'll try the single-partition approach, thank you :)
* tilpner
wonders if u-boot can handle unpartitioned media too
<samueldr>
as in, one filesystem directly on /dev/sdX?
<samueldr>
if it can, it won't work well on platforms loading u-boot from the media
<samueldr>
you can't control what's going to be on the specific offset it looks at, I think
<clever>
you would have to fuss around with the filesystem, to force data blocks of a given file to be at a given offset
<clever>
and something as simple as cp on the wrong path would break it hard
<clever>
like the old lilo days
<clever>
far simpler to just throw gpt on it, and make a "bios boot partition" at the right offset
<tilpner>
Oh, right, it does that
<samueldr>
yeah, pretty much my point :)
<clever>
then you can just dd if=uboot-spl.bin of=/dev/sda1
<clever>
tilpner: lilo was a little better, it read the current location of the blocks, and baked them into the MBR
<clever>
but allwinner doesnt let you configure that
<samueldr>
though, the pine 64 does have a 128MB (mb?) SPL
<clever>
typically, the "bios boot partition" is used by legacy bootloaders to run on GPT disks
<clever>
and the stub in sector 0 loads the blob in the BBP
<samueldr>
haven't taken the time to find good documentation and test burning u-boot there
<clever>
but who says you cant just make the whole thing start at the BBP?
<samueldr>
with u-boot in the SPL, it would almost be possible to share one usb drive between different vendor systems (e.g. raspi and allwinner) main issue would be with how we deal with device trees :/
<samueldr>
(the fact that we will load the right device tree for a given generation, thus no generic device tree per hardware platform)
<clever>
samueldr: i think the "proper" way, is to have the uboot provide the DT, and it "should" be baked into the hardware
<samueldr>
thing is, it's not how things work in reality :/
<clever>
of note, you can easily get 2 DT's right now
<clever>
put an rpi DT in the fat32 /boot/
<clever>
then bake an allwinner DT into the uboot in the SPL
<clever>
which bootloader you start from, controls the DT you get
<samueldr>
u-boot has their own set of DTs for their platforms, and the linux kernel has their own set of DTs for their platforms
<samueldr>
downstream OEMs also ship between zero to multiple DTs
<clever>
can you patch uboot to provide a given DTB?
<samueldr>
u-boot will forward the device tree it was built with, IIRC, and can load a device tree too
<samueldr>
u-boot needs a DT to boot, and then it can load another one if needed
<clever>
ah
<samueldr>
BUT, the big issue AFAICT is there's no identifier that could be used to script loading the right DT depending on the booting hardware
<clever>
i'm thinking, configure each bootloader with the right DT for the platform that bootloader works on
<clever>
and then have them all share a single /boot/
<clever>
the rpi cant use the SPL offset, so it will never load an SPL based DT
<samueldr>
what should happen when the kernel has a different DT than u-boot provides?
<samueldr>
because as it is, it's already what happens, when building u-boot, it gets its own DT built into itself
<clever>
yeah, if they conflict, then you have problems...
<samueldr>
and I'm thinking also, boards that uses (abuses?) device-trees to activate different things
<clever>
many years ago, i had made a uSD card, that booted on both x86-64 and armv7(rpi)
<samueldr>
I'm not 100% confident, but I believe the pinebook does that :/
<clever>
it had a single configuration.nix, and a single / and /boot
<clever>
i messed with /nix/var/nix/profiles/ to give each arch its own set of profiles
<clever>
and since it had 2 bootloaders, they each started from a different nixos build
<samueldr>
clever: the other month I did make a usb drive that probably could have booted off the pine A64-LTS and the raspberry pi using UEFI+u-boot... but the whole device tree loading was kind of a stop
<clever>
i think the only way to do things "right" is to find something like SPI or NAND flash that the board can boot
<clever>
and jam a u-boot with the right linux DT onto that
<samueldr>
still doesn't help with the DT the kernel will provide and want :(
<clever>
and configure it to properly store uboot vars to the same flash
<samueldr>
ah yeah
<samueldr>
that could do
<clever>
then you can just update the DT in the flash
<samueldr>
but what about older generations?
<clever>
and it will be part of the board, not the usb
<samueldr>
(though, AFAIUI DTs should be forward and backward compatible, but I don't know if reality matches that expectation)
<samueldr>
I mean, it's a *description* of the hardware and board-specific things after all
<clever>
i think that the DT should just describe the hardware, and that never changes
<samueldr>
yeah, it should
<samueldr>
though, not 100% sure about what I'll say, but what about when you add a screen or a camera using the on-board connectors
<samueldr>
I think I've seen boards where they say "use that DT to support that device"
<clever>
bbl
Thra11 has joined #nixos-aarch64
<bennofs[m]>
samueldr: kernel builds taking about 4h seems to be normal from the history? there were even some successful builds that took 6h
<bennofs[m]>
even the x86_64 build takes about that long
<bennofs[m]>
though I wonder why that is
<bennofs[m]>
is it just me or can nixos-rebuild be really slow on rpi 3?
<bennofs[m]>
(just the evaluation part takes a lot of time)
<samueldr>
It can, sd cards are generally slow, couple that with the cpu
<samueldr>
Though, weird that it times out at four hours if it took six in the past?
nschoe has joined #nixos-aarch64
<nschoe>
Hi everyone :) Quick question: once I cross-compiled my package (with `nix buils -f .... pkgsCross.raspberryPi.hello`) and it succeeded (I have a ./result). Is `nix-copy-close / nix copy` the correct way to put that binary on the raspberrypi?
<tilpner>
Yes, those work well
<nschoe>
tilpner, thanks. When trying this it fails with "copying 1 pathserror: cannot add path '/nix/store/zz58ixsgzc8b5nbdcz49j6rh6v7mbh00-hello-2.10-armv6l-unknown-linux-gnueabihf' because it lacks a valid signature"
<nschoe>
From what I seem to understand from reading several sources, this seems to have smth to do with signing packages. But I also saw there was a --no-chekc-sigs flag, which doesn't change anyuthing for me:/
<tilpner>
Huh, are you sure? I would have expected --no-check-sigs to "solve" that
<nschoe>
tilpner, no it doesn't. No on my machine. In the meantime I've just learned about "trusted users" and root beign one of them. So I just managed to get `nix copy` work, but I had to be logged **as root** on the target machine, and use `nix copy --from` **with** the `--n-check-sigs` option!
<nschoe>
Ho no :/ And then I ran `/nix/store/zz58ixsgzc8b5nbdcz49j6rh6v7mbh00-hello-2.10-armv6l-unknown-linux-gnueabihf/bin/hello` on the rapsberypi and got "Illegal instruction" :/
<tilpner>
Well, that is what you asked for
<nschoe>
what do you mean?
<tilpner>
pkgsCross.raspberryPi.* will compile for armv6l-unknown-linux-gnueabihf
<nschoe>
I cross-compiled it from my host with pkgsCross.raspberryPi.hello. Shouldn't the executable execute on the raspberrypi once the closure is copied?
<nschoe>
Okay
<tilpner>
Which Pi do you have?
<tilpner>
AFAICT pkgsCross.raspberryPi will only work on the first one
<nschoe>
tilpner, rPi 3
<nschoe>
Ho okay
<nschoe>
This is for the first rPi, I understand.
<nschoe>
So I have to use one of the aarch64 target
<tilpner>
Try pkgsCross.aarch64-multiplatform or pkgsCross.armv7l-hf-multiplatform
<nschoe>
tilpner, thanks, I'm building again.
Thra11 has quit [Ping timeout: 245 seconds]
<nschoe>
tilpner, aarch64-multiplatform worked :) Thanks