<lovesegfault>
samueldr: reviewed it, but I just want to make sure it's ready to go
<lovesegfault>
I need an unstable release to get my thunderbird rewrite
<clever>
This could be fixed by adding a compressed ? false param to the builder. the main difference would be that bzip2 invocation is not used, but rather a cp.
<clever>
 2
<clever>
lovesegfault: that comment, is why i had support for a "cat" compression in make-system-tarball, as far as i remember
<clever>
github creates special invisible branches for every pr, so you can fetch the tip of a pr, without having to care where it came from
<clever>
[clever@system76:~/nixpkgs]$ nix-build nixos/release.nix -A sd_image.aarch64-linux -Q -o aarch64-image
<flokli>
clever: nice, feels like Gerrit. Didn't knew, thanks
<clever>
samueldr: can that one boot on an rpi?
<samueldr>
clever: yes
<clever>
perfect
<samueldr>
3
<samueldr>
it won't a 4
<clever>
thats what sd_image_raspberrypi4 is for
<clever>
but my 4 is still in the mail
<samueldr>
that's a reason I want to delete sd_image_raspberrypi4 ASAP
<samueldr>
it shouldn't be needed :(
<clever>
samueldr: why do they differ?
<samueldr>
because mainline doesn't support the misc. stuff the rpi foundation did
<clever>
samueldr: ah, you need the linux fork again?
<samueldr>
yes
<clever>
samueldr: one minute
<samueldr>
mainline is deciding how to best support the "crap" they did :/
<clever>
for the pi 1-3, the linux kernel had to talk to the firmare, and relied on the firmware heavily
<clever>
which is messy, and i dont know how that got into mainline
<samueldr>
I'm glad I tried the SDL2 stuff outright before starting to use my mruby build harness, since that harness is lacking stuff I didn't know I needed :)
<clever>
for the rpi4, they properly added all of the graphics pipeline to the linux kernel, and mostly disabled it in the firmware
<clever>
so you need the special kernel, in the default config
<clever>
where is that flag...
<samueldr>
that's not even the issue AFAIK
<samueldr>
the main issue they have right now is the way DMA is done IIRC
<clever>
there are ~16 dma engines in the hardware
<clever>
the firmware will reserve some for itself
<clever>
and then tell linux which ones linux can use, via the cmdline, and also over a mailbox api
<samueldr>
I don't have the thread handy, but IIRC there is literally bugs in their implementation with regards to 32 vs 64 bits
<clever>
ah yeah
<clever>
only some of the dma engines are 64bit capable
<clever>
one sec
<samueldr>
and those issues are what they need to handle, and somewhat reluctantly fix in kernel
<clever>
samueldr: if you just put 2 kernels in /boot/, and add the right entries to config.txt, the bootloader will pick the right one, based on the model
<samueldr>
that's how we'll have both u-boots for rpi3 and 4 in there
<clever>
lovesegfault: every 86400 seconds (24 hours) it will query the default branch of nixpkgs, and build whatever nixos/release-combined.nix says to build
<clever>
samueldr: https://github.com/raspberrypi/usbboot can be used to push over the serprog firmware i have planned (and its been reported to work on a 4 already)
<clever>
my initial plan, is to use usbboot to push over a serprog firmware, that talks over the uart
<clever>
but long-term, it should advertise a usb serial gadget
<lovesegfault>
samueldr: thanks for the approval :)
<lovesegfault>
clever: I see
<lovesegfault>
I was amazed by how long the chromium build too
<lovesegfault>
*took
<clever>
my build hung, restarted it
<clever>
ah, it was building a kernel, oops
<lovesegfault>
lol
<lovesegfault>
clever: Are you using the community box?
<clever>
qemu-user-aarch64
<clever>
i dont have my builder ssh keys on the community box
<clever>
only my personal key, which has a passphrase
<lovesegfault>
clever: Oh, I can send you a built img if you want?
<lovesegfault>
Or you can get it from the box
<clever>
sure, whats the storepath?
<clever>
oh, i probably already have it
<lovesegfault>
One second
<clever>
[clever@system76:~]$ nix-store -q --binding out /nix/store/l61glrhdy6jx310wl41kxnqlqvhk4v4b-nixos-sd-image-20.03pre130979.gfedcba-aarch64-linux.img.drv
<samueldr>
though, is there a reason you want to cross-compile?
<samueldr>
it should be pretty well supported using the existing sd image
<samueldr>
meanwhile cross-compilation is uh... not trivial
<ryantrinkle>
samueldr: mostly i want to fish out the bugs in cross-compilation :)
<samueldr>
good idea then :)
<samueldr>
in my experience there is no need to target a specific board when they're well supported enough with mainline and u-boot
<ryantrinkle>
Ericson2314 wrote a lot of that stuff for my company (Obsidian) so we could ship iOS and Android apps written in Haskell
<ryantrinkle>
it would be very cool to expand that to other areas
<samueldr>
I sure would like it if there were fewer issues with some of the deeper nixpkgs stuff :D
<samueldr>
I'm currently working on static+cross for mobile nixos stuff
<ryantrinkle>
samueldr: that makes sense; i'm very new to this kind of stuff myself
<ryantrinkle>
samueldr: nice :) are you thinking about the pinephone?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I have the devkit, but I have shifted priorities around for more android-based hardware stuff before since external contributors already are coming in
<samueldr>
I would have liked to cross-compile rust stuff, but faced issues out of my league for now
<ryantrinkle>
ah, i see
<samueldr>
I have to implement software for stage-1, and don't want to write C/C++ things
<samueldr>
ash (busybox) is not really a solution either
<ryantrinkle>
ah yeah; i did some stuff a while back to try to kerberize the NFS network boot in stage-1
<ryantrinkle>
i got it working, but it was very painful
<samueldr>
ah, mobile nixos's stage-1
<samueldr>
which is different from nixos's stage-1
<ryantrinkle>
oh, i see
<ryantrinkle>
lower-level, i guess?
<samueldr>
not really
<samueldr>
the main difference really is you're more constrained, and that there's a goal that stage-1 for mobile nixos MUST cross-compile
<samueldr>
stage-1 in mobile nixos is just like in nixos, an initramfs started from the kernel
<ryantrinkle>
ahhh yeah, that makes sense
<ryantrinkle>
one of the reasons for cross-compiling is that i'd really like to not (as a general rule) build stuff on phones and other small devices
<ryantrinkle>
and so it'd be nice to have hydra or some other CI sitting there making sure stuff is prebuilt
<samueldr>
the main issue in that situation is that you won't be able to make use of the cache :/
<ryantrinkle>
yeah, because the caches are different?
<ryantrinkle>
er,
<ryantrinkle>
hashse
<samueldr>
different inputs, so yeah
<ryantrinkle>
yeah, that makes sense - although i could perhaps have an x86 build remote, and then just tell the phone it's cross-compiling, couldn't i?
<samueldr>
that's why I don't aim to have stage-2 cross-compiled
<samueldr>
you could yes
<samueldr>
btw, not saying it's not a good idea, but stating the drawbacks :)
<ryantrinkle>
perhaps someday we'll have bit-identical cross-compiles and then we can make the builder system an impure input ;)
<samueldr>
that would be the dream
<ryantrinkle>
yeah, much appreciated! i've just started looking at this stuff, so i'm really trying to come up to speed more than anything else
<samueldr>
I *think* CAS would be used in that case
<samueldr>
and I'm not an expert with cross-compilation, I mostly manage to do most things
<ryantrinkle>
CAS = content-addressable store?
<samueldr>
yeah
<ryantrinkle>
yeah, that would help a lot with this sort of stuff
<samueldr>
I think that, with a CAS, and a binary identical output, the leaves that are all using the same CAS inputs would be the same, whether cross-compiled or not
<ryantrinkle>
so you're working on android support? is there a specific goal you're working towards based on that?
<samueldr>
not android support, linux glibc standard support
<ryantrinkle>
ahhh, interesting! i didn't realize android-based hardware could even plausibly run nixos
<samueldr>
it can!
<samueldr>
stage-2 for mobile nixos is a bog standard stage-2 (with few hacks that are not really android-based hardware specific)
<ryantrinkle>
woah, that's awesome
<ryantrinkle>
would it be helpful to your efforts if I got one of these and tried to use it as my daily driver?
<ryantrinkle>
(don't worry, i won't blame you if it fucks up :P)
<samueldr>
when usable, sure, it's always helpful
<samueldr>
heck, I want it to be used by every nixos users out here :)
<ryantrinkle>
yeah, me too! i'm interested in privacy/security/etc. but one of the most exciting aspects from my perspective is just being able to manage it the same way I manage all my other machines
<ryantrinkle>
which device is the closest to working, currently?
<samueldr>
all android-based devices listed on that page have the same support
<ryantrinkle>
oh ok, cool
<samueldr>
and there's still an unknown about interfacing with the RIL
<samueldr>
(for phone calls, sms and data through cellular)
<samueldr>
wi-fi support will differ depending on the "vintage" of the hardware
<samueldr>
but AFAICT it's all doable, it just needs to be done
<ryantrinkle>
right; i wonder if any of the work Manjaro and the other folks are doing on the pinephone will be carry over
<ryantrinkle>
are there any installation instructions available yet?
<samueldr>
they produce images that can be burned
<samueldr>
and the pinephone is way different from the android-based devices
<samueldr>
that's not really an unknown for cellular
<samueldr>
as long as one of those linux distros get it working, it's going to work for us
<ryantrinkle>
ahh, ok
orivej has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-aarch64
<lovesegfault>
samueldr: Looks like that fix did it :)
<mla>
does anyone know if the rockpro64 will boot with the aarch64 images produced by hydra (default kernel) these days? i know i need to overlay uboot, but is setup just download aarch64, dd the image, then dd uboot?
<samueldr>
not sure, I know some work has happened recently so that upstream mainline u-boot is built
<mla>
i see so potentially wiki is out of date, rockpro64 page says it uses upstream uboot and you need to dd it
<samueldr>
>> Note: Prior to NixOS 20.03, a downstream version of U-Boot 2017.09 was packaged, which placed U-Boot in a single idbloader.img file. If that version is used, simply disregard the second command above.