ryantrinkle has quit [Ping timeout: 258 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 246 seconds]
mog has quit [Quit: im quiting!]
mog has joined #nixos-aarch64
<sphalerite> samueldr: huh, there are 2bs with aarch64??
<clever> sphalerite: they began shipping 2bs with the 3b board, but just omitted the wifi chip and called it a 2b
<sphalerite> huh
<clever> because some people dont want to pay extra for wifi, but broadcom doesnt want to pay extra for making 2 different CPU's
<sphalerite> I'm guessing mine is too old to be one of those though
<clever> yeah, it only started after the 3's came out
<sphalerite> how can I tell though?
<clever> the cpu looks noticably difference
<clever> 2's and older are the regular old black package
<clever> 3's (and the "2b" with a 3 cpu), have a metal cover
<clever> at least, thats what i remember....
<clever> my 3 has the black epoxy....
<clever> ahhh, i'm thinking of the 3b+
<clever> mine is a 3b (japanese) i believe
<clever> or just plain 3b
orivej has quit [Ping timeout: 246 seconds]
<sphalerite> clever: I think I have the 2b 1.2, based on that picture
<sphalerite> is that the aarch64 one?
<sphalerite> (based on that picture and memory, I'm not at home right now to check :) )
zupo has joined #nixos-aarch64
<sphalerite> clever: ooh, looks like mine is indeed an aarch64 one! Excitement!
<sphalerite> so maybe I can run nixos on it after all <3
orivej has joined #nixos-aarch64
<Ashy> isnt there a nixos build for the older pi's anyway though?
Guest99428 is now known as LnL
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Ashy> lopsided98: not sure if you're around but i'm about to try nixos on the rockpro64
<Ashy> im in ayufan's armbian booted off the emmc, nix is installed
<Ashy> this is a 64gb emmc with heaps of space, you reckon i could add another partition for a nixos root and just reuse ayufan's /boot and kernel and add a u-boot menu item to boot the nixos root?
<Ashy> and actually, duh, i can just plug in the pcie nvme adaptor and install direct to the nvme
ryantrinkle has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 248 seconds]
ryantrinkle has quit [Ping timeout: 246 seconds]
<sphalerite> Ashy: there is, but then I still need to compile everything on the pi, which isn't fun
<Ashy> ah yeap, add a fan and wait wait wait
<Ashy> haha
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Ashy> ok nixos-install is running to the nvme partition, time for bed
<Ashy> see how it went in the morning
zupo_ has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has joined #nixos-aarch64
andi- has quit [Ping timeout: 250 seconds]
andi- has joined #nixos-aarch64
andi- has quit [Excess Flood]
andi- has joined #nixos-aarch64
<lopsided98> Ashy: What needed to be compiled? The binary cache should have everything you need except your system configuration and a custom kernel if you are using one
<lopsided98> Also, if you were to manually add a extlinux.conf entry, the problem you would run into is that it needs to be updated with every new generation
andi- has quit [Ping timeout: 246 seconds]
andi- has joined #nixos-aarch64
<sphalerite> gchristensen: #61162 ought to fix zfs on recent kernels on aarch64
<{^_^}> https://github.com/NixOS/nixpkgs/pull/61162 (by lheckemann, 20 hours ago, open): Kernel config: use PREEMPT_VOLUNTARY
zupo has joined #nixos-aarch64
<sphalerite> um, that plus #61181
<{^_^}> https://github.com/NixOS/nixpkgs/pull/61181 (by lheckemann, 9 hours ago, open): spl: fix build with linux 5.1
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jackdk has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
<sphalerite> samueldr: I've got a full-featured u-boot working on the nanopi! Now I need to work out how to actually boot linux using it, any chance you can help with that? :)
<samueldr> full featured what version?
<samueldr> might want to read about how booti and/or bootm works
<samueldr> I never really investigated non-uefi non-extlinux booting methods since they work so wall with nixos :)
<samueldr> (though I do have something that's working with bootm from a mobile-nixos thing)
<sphalerite> samueldr: more recent than 2019.04-rc4
<samueldr> oh, then try the uefi usb stick
<sphalerite> ooooooooh
<samueldr> or if it fits in the gap before the first partition, sd_image should work too
<sphalerite> how can I build the uefi usb stick or sd_image?
<sphalerite> hm, I think I need a new_kernel one but with zfs. Picky, I know ;)
<samueldr> welp
<samueldr> then it's "like on x86_64, but aarch64"
<sphalerite> perfect
<samueldr> (for the iso)
<samueldr> I mean, making the aarch64 iso literally was just adding the right paths :)
<samueldr> and the armv7 uefi iso too!
<samueldr> (though it also requires a patched grub, this is why it isn't done in nixpkgs yet)
<sphalerite> aah, good old mmcqd…
<sphalerite> wait, it wants to rebuild linux? This bodes ill
<samueldr> not sure I follow
<sphalerite> so I'm using my own nixpkgs because my zfs fix patches aren't merged yet
<sphalerite> and one of the drvs it wants to build for the iso is /nix/store/r7vwx4bc7rvlnr3nxqcm6d55z9fwg1dz-linux-5.1.drv
<sphalerite> even though I've already built linux 5.1 from that nixpkgs rev for another purpose :/
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite> aah found the bit
orivej has joined #nixos-aarch64
<samueldr> and it was?
<sphalerite> I'm using an override in my system config that adds an extraConfig
<sphalerite> so I went and put that extraConfig in the installer-new-kernel.nix or whatever it was as well
<sphalerite> huh, it's building 2 different grubs for the image
* sphalerite decides not to question it
<sphalerite> blargh mksquashfs
<sphalerite> maybe I should have gone with sd_image after all :)
<sphalerite> meh, the u-boot isn't finding my USB stick
<samueldr> sd_image it will be I guess :/
<samueldr> and just thought of something
<samueldr> device tree handling with uefi is still an unresolved issue as far as mainline linux device trees go
<sphalerite> what does that mean, practically?
<samueldr> you won't have fixes that the kernel maintainers think the device tree needs for your device
<samueldr> e.g. describing the hardware right, or even more right
<samueldr> i.e.*
<sphalerite> ah so u-boot will pass its own device tree on to the kernel?
<samueldr> AFAIUI yes
<samueldr> which they do sync to the kernel device trees, I think
<samueldr> but then are you gonna update u-boot as frequently as the kernel, probably not
<sphalerite> aah I see
<duncan^> The UEFI thing does mean you can load something that's not got a mainline dt tho
<sphalerite> blargh, this doesn't seem to be an efi image at all..?
<sphalerite> wait no I think I'm just Doing It Wrong
<samueldr> technically u-boot can, but the way the extlinux generation is made in nixos, and the way u-boot wants to use it makes it so it won't work
<samueldr> basically, something in u-boot tells u-boot which name to look for in the path given in the extlinux configuration
<samueldr> and it fails if it cannot find a fdt/dtb :/
<samueldr> (for sunxi [allwinner] it is hardcoded at build, dunno for others)
<sphalerite> um
<sphalerite> this u-boot doesn't seem to have iso9660 support
<sphalerite> right, sd_image time
jackdk has joined #nixos-aarch64
<sphalerite> aw poo, the ESP is at the same offset as I need u-boot.img…
<sphalerite> but I guess I can work around that
<samueldr> in that case it's not an ESP
<samueldr> two solutions
<samueldr> (1) resize to the right that FAT32 partition
<samueldr> (2) manual manipulations to put the boot files in the ext4 one
<sphalerite> how is it not an ESP?
<sphalerite> But yeah I'll shuffle it around a bit to make it work
<samueldr> it's not for EFI booting, and doesn't have the ESP type on a GPT table
<samueldr> it's just a dumb FAT32 on MBR for the raspi
<samueldr> the E in ESP is for EFI
<samueldr> and technically speaking, while the spec says it should be FAT32, if the firmware has support for other FS it should be able to handle another FS for the ESP
<samueldr> (but would be out of spec)
<sphalerite> ooooooh
<sphalerite> how convenient :D
<samueldr> and it does have to be on GPT, it's the _part_ type that makes it the ESP
<samueldr> well, _partition_ type
<samueldr> EF00
<sphalerite> ooh wait, this isn't a GPT image…
<samueldr> that's it :)
<samueldr> sd_image is not UEFI booting at all
<sphalerite> oh.
<sphalerite> but uboot should be able to boot it anyway, right?
<sphalerite> samueldr: Retrieving file: /extlinux/../nixos/27499va52fsg55g1jmyhy7aifgf7cgcb-linux-5.1-dtbs/rockchip/rk3399-nanopi-m4.dtb
<sphalerite> that looks good to me?
<samueldr> good sign
<samueldr> and yes, u-boot will boot that
<samueldr> our sd_image are made for booting with u-boo
<samueldr> t
<sphalerite> hm, but it doesn't say anything after Starting kernel ...
<sphalerite> is there a nice way to edit the kernel parameters from the u-boot command line?
<samueldr> mount and vim
<samueldr> (or emacs if you're one of 'em ;))
<sphalerite> from the *u-boot* command line :p
<samueldr> and yeah, most likely the boot logs are left hanging in the void :/
<sphalerite> I don't like moving SD cards around any more than strictly necessary :p
<samueldr> "console=ttyS2,1500000n8" "earlycon=uart8250,mmio32,0xff1a0000" "earlyprintk"
<samueldr> you're likely to want those
<sphalerite> ttyFIQ0 actually on this device I think
<samueldr> likely, at least it was for both mine and makefu's rk3399 based boards :)
<sphalerite> maybe it's only ttyFIQ0 on the downstream kernel
<sphalerite> I can always put both :D
<samueldr> plausible, wouldn't know
<samueldr> though, it will only send messages to the first console= listed
<samueldr> we still don't have boot messages mirrored on all consoles :(
<sphalerite> wooooo it's booting!
<sphalerite> weird, I only added the console and earlycon parameters, yet it booted, unlike before
<samueldr> if it had no console to show a console to, it might have looked hung?
<samueldr> not sure it will show a console if it's not in the console= list
<samueldr> (assuming you weren't using an hdmi out)
<sphalerite> no, the heartbeat LED wasn't flashing on my last attempt
<samueldr> though, through all that, I think we should maybe do a bit of work to make the image more friendly to rockchip boards
<samueldr> (1) move the actual boot files to the ext4 partition, keep the /boot fat32 partition only for the raspberry pi files
<samueldr> (2) pad more in front of the fat32 partition for those big "downstream" u-boot builds for rockchip
<sphalerite> [ 12.746741] systemd-journald[574]: Failed to open system journal: No space left on device
<samueldr> I mean, those with the rockchip blobby bits
<sphalerite> oh no, that's no good
<samueldr> hmmm, it should have resized the partition
<samueldr> maybe you cut it when it was doing it?
<sphalerite> fsck is happy with the filesystem
<sphalerite> but it is also indeed full
<sphalerite> (and can't be grown, since I moved the boot partition to after the root partition)
<samueldr> oh!
<samueldr> that would do it
* sphalerite removes 133MiB of firmware from the firmware-linux-nonfree store path #yolo
<samueldr> not sure if sd_image is still edging really close to the hydra limits or if the base closure size situation was reduced since then
<sphalerite> uuuuugh stupid getty
<sphalerite> it changed the baud rate from what was passed on the kernel cmdline, making the console invisible
<samueldr> oh right, you might have that issue
<samueldr> :)
<sphalerite> anyway, happy to know that 5.1 runs well on my nanopi if I use a modern u-boot
<samueldr> how did you build the u-boot?
<sphalerite> in a nix-shell :p
<samueldr> I meant, rockchip blobby bits or only u-boot?
<samueldr> because if it's only lacking lpddr4 training maybe I can share the lpddr4 patch that I have around
<samueldr> AFAIU it's the main issue with rk3399 boards and a clean u-boot
<samueldr> though I may be really in the wrong here :)
<sphalerite> only u-boot
<sphalerite> well hang on
<sphalerite> actually
<sphalerite> I did need the arm trusted firmware, but that's something else, right?
<samueldr> yeah
<samueldr> oh, so maybe the patch is in?
<sphalerite> (and amarula/u-boot-amarula at rockdev is the branch I used)
<samueldr> >> Option 2: Package the image with SPL:
<samueldr> right?
<sphalerite> yes
<sphalerite> I don't think it's upstream yet
<samueldr> ah!
<samueldr> it's ddr3 ram
<samueldr> though there is an LPDDR4 branch there too https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4
<samueldr> which to my untrained eye seems wildly similar to what I have here
<samueldr> or uh, maybe not wildly, but superficially