<samueldr> env set bootcmd run distro_bootcmd
<samueldr> env save
<samueldr> not sure if it'll work
<makefu> run distro_bootcmd should boot from usb, right?
<samueldr> (I know for the pine it doesn't; it can't write to SPI storage, and even outside I don't know if there's storage for the environment elsewhere)
<samueldr> makefu: maybe, maybe not
<samueldr> it's part of the targets
<samueldr> so chances are good
<samueldr> if it doesn't might need to be on SD
<makefu> that would be quite neat.
<samueldr> I'm making this up along the way btw
<makefu> i really like how the uboot boot mechanism can be introspected with printenv
<samueldr> yeah, when I figured that out and figured out the distro_bootcmd was only a bunch of environment variables baked in it sounded good
<samueldr> sure, not as elegant as barebox does it (afaiui) but still not bad
<makefu> absolutely
<makefu> sheesh it is already 1AM ... gotta go to bed now. thanks so much for your help!
<samueldr> you're welcome, have fun with that and take notes :)
<makefu> sure!
lopsided98 has quit [Ping timeout: 252 seconds]
lopsided98 has joined #nixos-aarch64
<samueldr> hm, heads up, configs/firefly-rk3399_defconfig is part of upstream u-boot too, no idea what's the upstream status though
<samueldr> board/rockchip/evb_rk3399/README might be a good read
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
sphalerite has quit [Quit: rebooting!]
sphalerite has joined #nixos-aarch64
<makefu> thanks for the info! i will test it later
tilpner has quit [Ping timeout: 250 seconds]
LnL has quit [Quit: exit 1]
LnL has joined #nixos-aarch64
LnL is now known as Guest28061
Guest28061 has joined #nixos-aarch64
Guest28061 has quit [Changing host]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
Guest28061 is now known as LnL
lopsided98 has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-aarch64
worldofpeace has quit [Quit: worldofpeace]
worldofpeace has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<samrose_> samueldr: do you know of any way to boot and run tests on sd-aarch64 image via hydra build process? (sorry I hadn't just outright asked that previously)
<samueldr> you'll have to figure out a way to boot u-boot with qemu, which will work on your aarch64 build machine
<samueldr> which could mean disabling kvm for the vm
<samueldr> I don't remember for sure if aarch64 too had issues, but qemu-system-arm with u-boot failed on kvm
<samrose_> samueldr: I feel like in all the "flailing around" I did early on, I was able to get an aarch64 image to boot on qemu without kvm. It was very slow
<samueldr> ah, but then you're not testing sd_image!
<samueldr> you can boot aarch64 vms by skipping the bootloader altogether, just as easily as on x86_64
<samueldr> but you probably want to test it with u-boot, which will test the extlinux booting mechanism
<samrose_> ok. probably I will need to dig into qemu-system-arm
<samrose_> to "boot aarch64 vms by skipping the bootloader altogether, just as easily as on x86_64" this is working with the aarch64 iso images eh?
<samueldr> qemu-system-aarch64 *
<samueldr> arm is for armv7l
<samrose_> ah, right
<samueldr> no, the iso image isn't what I had in mind, the iso image still tests the bootloader
<samueldr> qemu vm tests can start the kernel + initrd + disk without a bootloader (just as qemu can natively)
<samueldr> so any test that isn't testing a full boot will be made that way
<samrose_> that is all part of the testing framework
<samueldr> yeah
<samrose_> aha, ok I will check both of those out thank you
<samueldr> samrose_: if you get u-boot tests working, that's something that's prime for nixpkgs inclusion :)
<samrose_> samueldr: ok, sure thing
<samrose_> samueldr: I was planning on building u-boot, and can take a crack at the testing of it too
<samueldr> well, as said, if you want to test sd_image, you need to boot it using u-boot :)
<samueldr> (which is what I meant when saying "u-boot tests")
<samueldr> nix-build nixos/tests/boot-stage1.nix # this'll work on aarch64-linux
orivej has quit [Ping timeout: 272 seconds]
<samrose_> samueldr: got it. (this looked interesting https://github.com/u-boot/u-boot/blob/master/doc/README.qemu-arm )
<samueldr> btw, my memory of this is that u-boot booted fine on qemu, but failed with qemu-kvm
<samueldr> it started, but the virtualised hardware would stop working
<samueldr> sometimes before handing off to the kernel, sometimes after
<samueldr> while non-kvm worked
<samrose_> I would also actually be running qemu on an arm64 server
<samueldr> yeah, that was on aarch64
<samrose_> samueldr: I think you are right, I feel like I got aarch64 sd image running under qemu if not using kvm back in maybe october
<samrose_> I guess the host needs kvm support in it's kernel
<samueldr> if you want kvm, yeah
<samrose_> this ubuntu page seems to think they achieved it https://wiki.ubuntu.com/ARM64/QEMU
<samueldr> it will also need it from the hardware, but IIRC all armv8 should
<samrose_> ok
<samrose_> I will try it either way
<samueldr> no u-boot there
<samrose_> aha
<samrose_> I see
<samueldr> there it's tianocore
<samueldr> tianocore works wonder
<samueldr> but that's UEFI boot :)
<samueldr> not the sd_card with u-boot :D
<samrose_> right on gotcha
<samueldr> the whole array of different boot methods on ARM makes this hard
<samueldr> because not only each hardware families are different, and sometiemes different inside a family
<samrose_> well it said it right there "I've chosen to describe a UEFI-based" I just overlooked that
<samueldr> there is often multiple methods!
<samueldr> for the record, qemu-kvm + UEFI I tested personally with armv7l on aarch64 and aarch64 on aarch64 and it works
<samueldr> (both on a Raspberry Pi and on a Pine A64-LTS)
<samueldr> and the cost of kvm is not too onerous, making it viable for end-users to use aarch64 for armv7l builds if they have hardware supporting it