<samueldr>
because that's one of the issues from later on with cross-compilation IIRC
<colemickens>
Asmadeus: Getting iPXE for aarch64 is easier said than done though. It just looks much simpler to do uboot->grub->kernel since I don't have to go figure out how syslinux builds into ipxe :S
<s1ng0c>
previously I clone with depth=1 hence need to clone again
<s1ng0c>
*cloned
<samueldr>
next time,
<samueldr>
`git fetch --unshallow` can do that
<s1ng0c>
oh, will try next time :D, not really good at git :(
<s1ng0c>
seem issue gone
* colemickens
hopes that anyone who thinks my plan is dumb will shout
<samueldr>
colemickens: ipxe -> u-boot ?
<gchristensen>
as long as you have a nice amount of ram and, yeah
<gchristensen>
if it is a pi and you install a bootloader to the disk you'll have a hard time netbooting later
<samueldr>
gchristensen: YMMV with the 4
<samueldr>
since it's user-configurable in the EEPROM
rajivr has joined #nixos-aarch64
<colemickens>
I thought rpi4 was just PXE so I was going to PXE to uboot, since iPXE isn't built for aarch64 in nixpkgs.
<samueldr>
you can change the boot order in the eeprom, so things are extremely not-declarative
<samueldr>
I see
<samueldr>
then use u-boot's whatever for netbooting grub UEFI I guess?
<colemickens>
Something like that, I guess.
<samueldr>
is there a reason for the grub indirection?
<colemickens>
this prompted my question last night of why u-boot doesn't support http?
<samueldr>
(I didn't ingest the backlogs today)
<colemickens>
nah, don't expect that, just restating :)
<colemickens>
just wondering aloud really
<samueldr>
(been uncharacteristically offline these past days)
<samueldr>
I know it doesn't look like it :)
<samueldr>
so what's the reason for the grub indirection?
<colemickens>
samueldr: honestly I stuck grub2 in there because it was easy to find examples of how to get grub to load a big initrd over http.
<samueldr>
ah
<samueldr>
any reason is fine, I didn't know if you had considered straight u-boot
<colemickens>
if u-boot could pull over something other than tftp... or if I knew how to configure extlinux, maybe I'd pursue that more?
<samueldr>
what about tianocore?
<colemickens>
I'm really tempted to just do that, too.
<colemickens>
stick it on an SD card, configure the HTTP server to pull from, call it a day.
<samueldr>
in my experience with the pi 3, tianocore is soooooo much better
<samueldr>
I haven't tried it back on the 4
<colemickens>
for some reason I'm doing that thing where I really want zero-storage devices attached to it, but I'm probably just being silly.
<samueldr>
treat that SD card as if it was a bios EEPROM and forget about it :)
<gchristensen>
the traditional pxe flow is (bad pxe) -tftp-> (ipxe) -http(s)-> real-os
<colemickens>
it worked well enough a couple months ago. I actually had it netbooted as well, but I couldn't really figure out how to get my router to advertise the right DHCP option for HTTP-UEFI boot.
<samueldr>
and bug the raspberry pi foundation for actually useful EEPROM space
<gchristensen>
since rolling out (i)pxe updates is tricky, doing an initial bootstrap via tftp is quite common
<colemickens>
gchristensen: I'm worried getting ipxe on aarch64 will be a time-suck, but I've not looked into it seriously yet.
<gchristensen>
should not be hard
dao_ has joined #nixos-aarch64
dao_ has left #nixos-aarch64 [#nixos-aarch64]
s1ng0c_ has joined #nixos-aarch64
s1ng0c_ has quit [Client Quit]
s1ng0c has quit []
ramram has joined #nixos-aarch64
s1ng0c has joined #nixos-aarch64
s1ng0c has quit [Client Quit]
s1ng0c has joined #nixos-aarch64
<clever>
colemickens: i know more about the pi netboot if you still have questions
* colemickens
looks up the syslinux maintainer and....
<samueldr>
tell me it's not me
<samueldr>
hi
<samueldr>
it me
<samueldr>
note that syslinux is totally unrelated to u-boot's syslinux support
<samueldr>
except for the file format
<colemickens>
I decided to go the "try to get iPXE" working route. It seems like less moving parts and I got a "should not be hard" from a reliable source.
<clever>
colemickens: for the pi4, i believe it will just blindly fetch $prefix/start4.elf or start4.elf from the next-server defined in dhcp, but only if the dhcp server responds with a special tag
<colemickens>
and as far as I know and cant tell, ipxe wants syslinux. I did open an issue to track, might've tagged you in it.
<clever>
Package ‘syslinux-unstable-20190207’ in /home/clever/apps/nixpkgs-hasura/pkgs/os-specific/linux/syslinux/default.nix:95 is not supported on ‘aarch64-linux’, refusing to evaluate.
<gchristensen>
:/
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<clever>
/nix/store/9yapmh2s4z7dz07zdpd626329bcqh1p0-bash-4.4-p23/bin/bash: gcc: command not found
<clever>
builder for '/nix/store/rincr7wkfjk45h54vrnq7b87igczl4bn-syslinux-unstable-20190207-aarch64-unknown-linux-gnu.drv' failed with exit code 2
<s1ng0c>
@samueldr boot screen shown at 1st boot only
<s1ng0c>
dont know why :(
<s1ng0c>
PP v1.1, LCD not on from 2nd boot
<s1ng0c>
any clue?
<s1ng0c>
BTW: don't know if there is any issue by change USB OTG to host/otg mode on u-boot for pinephone?
<s1ng0c>
I need this mode to let pinephone connect to eth via usb doggle
<samueldr>
nothing specific to mobile nixos
<samueldr>
btw, I will be frank, pretty much nothing is "ready" in stage-2 for end-users
<samueldr>
so depending on whether you want to fix things up yourself, you may prefer temporarily running something else
<samueldr>
something that at least claims to be ready for daily use :)
<samueldr>
as for the LCD not working on second boot... I really have no clue, you'd have to go through logs
<s1ng0c>
ok then
tilpner_ has joined #nixos-aarch64
cole-h has quit [Ping timeout: 256 seconds]
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
patagonicus has quit [Quit: Ping timeout (120 seconds)]
patagonicus has joined #nixos-aarch64
bdju has quit [Ping timeout: 240 seconds]
bdju has joined #nixos-aarch64
s1ng0c has quit [Ping timeout: 240 seconds]
<thefloweringash>
Emil Karlson: no gpu, just headless. I use the vendor kernel at version 4.19.68. mainline has some support as of 5.5, but I'm waiting for pcie support
red[evilred] has joined #nixos-aarch64
<red[evilred]>
sphalerite (IRC) I just poked solid run. I'll let you know if I hear anything back.
ramram has quit [Quit: Connection closed for inactivity]
<angerman>
does anyone have a creative idea how to get `mkimage` available during the kernel build?
<angerman>
armbian does some device tree overlay building during the kernel build and it needs mkimage for that.
<samueldr>
but do we need to do it at that step?
h0m1 has quit [Ping timeout: 264 seconds]
<angerman>
samueldr: it's one of their kernel patches m(
<samueldr>
only, they do it quite close to the kernel build, which to my opinion isn't great
<samueldr>
but my opinion is that the kernel vendoring of device trees is a mistake
<angerman>
I have for the helios64 narrowed down what causes the sd card (and emmc) not to come up.
<samueldr>
while I do understand why they did that... some vendors are beyond terrible
<samueldr>
it's just not great to have the kernel basically dictate stuff about the platform, that really should be part of its own independent firmware
<samueldr>
angerman: great
<angerman>
The device tree from the upstream kernel *works*, the helios provided device tree, when used with vanilla 5.8 from nixpkgs, fails to bring up the sdcard.
<angerman>
so something between those two device trees is significantly different, that it stops the sd card from coming up. Now I have very little knowledge about devicetrees :-/
<samueldr>
FDT stands for flattened device tree, which is basically a .dtb file
<angerman>
the armbian one is provided by the kobol folks
<samueldr>
yeah
orivej has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
<angerman>
Looks like my armbian kernel built. Should be able to test after lunch. If that doesn’t work, I’ll try the sd load/unload patch
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
<angerman>
whee, that worked.
<angerman>
so it's probably something with our kernel config.
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 264 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
<Asmadeus>
colemickens: didn't read full backlog but yeah I only have experience with aarch64 uefi for which ipxe works fine, that said it should probably be possible to build a specific ipxe.lkrn (which should chain after uboot easily) for aarch64 as well
<Asmadeus>
from a quick read aarch64 doesn't support the "full image" mode with all drivers because all drivers aren't supported, but if you make something fairly minimal with just what you need it works well
orivej has quit [Ping timeout: 264 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
justan0theruser has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
justanotheruser has quit [Ping timeout: 272 seconds]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
<patagonicus>
Sigh. Of course it failed with a similar error in a related module. Time to build this kernel manually and fix the imports as I go along.
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
adamzivcak has joined #nixos-aarch64
adamzivcak has left #nixos-aarch64 [#nixos-aarch64]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Ping timeout: 240 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
<angerman>
Alright, I pushed the armbian kernel changes for the helios64 to https://github.com/angerman/nixos-docker-sd-image-builder, effectively making nixos use the armbian configured kernel for rockchip64. This works on my helios. What doesn't work are the fans, so I'll need to figure that one out still.
<simpson>
Because 32-bit ARM is hard to work with. So is aarch64, but the very fact that I can say "aarch64" and not "assorted 64-bit ARM arches" is a massive part of why.
<simpson>
That said, https://github.com/nixos/mobile-nixos can support armv7 phones, in theory. Possibly in practice too, but I haven't had the patience to follow through.
Raito_Bezarius has quit [Ping timeout: 272 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
Raito_Bezarius has joined #nixos-aarch64
<cirno-999>
it would be hard to get a compatible armv7 device.