<samueldr>
neat, flashing the nixpkgs-built u-boot to the SPI works as expected, it can now boot the franken-uefi image!
<gchristensen>
:o
<samueldr>
it also tries to network boot as last resort
<gchristensen>
a different order than most systems attempt. I like it.
<samueldr>
that's not the system, that's u-boot stock :)
<gchristensen>
ah
<samueldr>
the allwinner CPU will try to load the bootloader, in order from the eMMC, then the SD card, finally a small SPI flash chip
<gchristensen>
it is tiring to reboot a system and have it sit at iPXE going "Bueller? Bueller?" for a few minutes waiting for iPXE
<samueldr>
(first two might be in the wrong order, going from memory)
<samueldr>
now wondering how hard (probably too much to care) it would be to port tianocore
<samueldr>
annoying
<samueldr>
I think the easiest method is the least accessible method
<samueldr>
needing a special cable, USB A-to-A
* samueldr
is digging up that cable
<samueldr>
though I could cheat and use my atom laptop which has a micro-usb which acts as a usb host
<samueldr>
yes, I know this sounds horrible
<gchristensen>
usb a-a exists?? :o
<samueldr>
yes
<samueldr>
and though it's parrotted online that it's illegal per the spec
<samueldr>
I couldn't find anything quoting it
<samueldr>
usb 3 A-to-A, though, I could find sources
<samueldr>
but in the case of the pine a64-lts, it's because one of the usb receptacle is plugged to what would usually be a micro-usb receptacle on the CPU
<gchristensen>
huh
<samueldr>
and that receptacle is the one active in "FEL" mode, which is an allwinner low level DFU-type thing
<samueldr>
apparently some rockchip boards also have the same behaviour
<samueldr>
(but sadly, couldn't verify the chromebit did)
<samueldr>
I think the simplest method would be to make a nixos derivation using the sunxi fork of u-boot, which has the plu
<samueldr>
(oops)
<samueldr>
AFAIK, I think the simplest method would be to make a nixos derivation using the sunxi fork of u-boot, which has the plumbing necessary to write to the SPI flash, which would write the mainline u-boot to the SPI flash
<samueldr>
simplest to get working, definitely not the cleanest :^)
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
arianvp has quit [Quit: WeeChat 2.2]
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 244 seconds]
makefu has quit [Ping timeout: 260 seconds]
cstrahan_ has quit [Read error: Connection reset by peer]
cstrahan_ has joined #nixos-aarch64
<bennofs[m]>
does uboot on rpi model 3b still require enable_uart=1?
<bennofs[m]>
seems it doesn't
<bennofs[m]>
oh, I think I found out why my raspberry pi with the aarch64 image felt so slow... seems the cpufreq driver is not loaded, so it was probably not doing frequency scaling. I set force_turbo=1 for now in /boot/config.txt
<samueldr>
bennofs[m]: using the mainline kernel or the rpi kernel?
<samueldr>
I think it's something that should be added to the wiki either way :)
<bennofs[m]>
samueldr: I used the aarch64 sd image from that helsinki link
<samueldr>
mainline it is
<samueldr>
I'm wondering if there is any way to confirm such a speedup
<samueldr>
hmm, force_turbo is detected as overclocking the raspberry pi :/
<bennofs[m]>
I think only if you also set overvoltage
<bennofs[m]>
at least that's what the doc said
<samueldr>
oh, yeah, "*and* any of the over_voltage"
orivej has joined #nixos-aarch64
<samueldr>
added a table with the different models, if anyone has tested those that are marked C* or ? and they work, fix the status, and add device-specific notes if any
<bennofs[m]>
i added a note about missing support for cpufreq scaling in mainline for rpi3 to that page for now. I can't benchmark the difference right now (since the my pi is busy), I'll do that later (if it turns out to be irrelevant for benchmarks I will remove the note again)
Thra11 has joined #nixos-aarch64
makefu has joined #nixos-aarch64
<bennofs[m]>
hmm why is linux_rpi not built by hydra?
<bennofs[m]>
(for aarch64)
<makefu>
bennofs[m]: afair linux_rpi is only for old raspi (1 and 2), you can use the stock kernel for rpi3
<bennofs[m]>
also would linux_rpi maybe take less time to build on an rpi since it wouldn't contain all the modules but only things needed on rpi?
<bennofs[m]>
wanted to check on hydra how long linux_rpi builds take when I noticed that it doesn't even build linux_rpi :)
<makefu>
i am not sure about how long the build would take
<makefu>
afair it took something like a night on a rpi2 to build _rpi
<makefu>
but on rpi3, i am not sure
<samueldr>
linux_rpi was recently changed to build for aarch64
<makefu>
but yeah, maybe hydra should also build _rpi for aarch64
<samueldr>
`extraMeta.hydraPlatforms = [];`
<samueldr>
pretty self-explanatory :)
<samueldr>
aarch64 should be re-added to it I guess
<bennofs[m]>
wait were did you take that from. i checked linux-rpi.nix
<bennofs[m]>
oh no I see it now, seems I was blind
<samueldr>
(I had doubts, since I was on a nixos-18.09 branch)
<bennofs[m]>
samueldr: so would it be ok if I just set hydraPlatforms = stdenv.lib.platforms.aarch64 and push that to master or should I make a PR for it? not sure how controversial that is, impact should be low I guess?
<samueldr>
my personal opinion is that push to master should be disallowed, and only made through PRs
<samueldr>
so it colors my judgement greatly!
<bennofs[m]>
ok then I make a PR
<samueldr>
but I'm 99.99% sure it's not controversial to allow aarch64 hydra builds of linux_rpi
<samueldr>
and I also believe it should be backported to stable, since aarch64 support is quite good in stable
<samueldr>
(both the SBCs I test things on run on stable)
<samueldr>
(backported only if the aarch64 fixes for linux_rpi were already in stable)