<veleiro>
as do i, but its just a container based off of termux right
<samueldr>
running on the system itself, in control, probably much less plausible
<samueldr>
all depends on the exact system, and how rooted and how much kernel modifications you want to have
<samueldr>
"container" isn't exactly right
<samueldr>
it is running natively, but yeah, contained into the execution context of an app
<veleiro>
yeah not like an lxc type container
<samueldr>
I don't think there would really be any benefit of running it on the raw android system
mschwaig has quit [Quit: WeeChat 3.0]
<samueldr>
but it wouldn't be totally impossible
<samueldr>
though, probably harder than what it's worth
<veleiro>
but that app doesnt have access to system graphics or anything?
<samueldr>
AFAIK, that's about right
<samueldr>
though, sorry, got to go
mschwaig has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
<colemickens>
this is kind of random, but I think realistically I'm taking the pixel3 off my list of projects to return to. Just too low on the list, so if someone wants to continue my work, I could send a p3 to them to work on.
mschwaig has quit [Quit: WeeChat 3.0]
mschwaig has joined #nixos-aarch64
mschwaig has quit [Quit: WeeChat 3.0]
mschwaig has joined #nixos-aarch64
<angerman>
sphalerite: I find the arctis ones substantially quieter. The Helios has also stopped crashing after the initial bout of crashes.
cole-h has quit [Ping timeout: 260 seconds]
<samueldr>
colemickens: hi
h0m1 has quit [Ping timeout: 264 seconds]
h0m1 has joined #nixos-aarch64
quinn has quit [Ping timeout: 260 seconds]
<siraben>
Anyone running NixOS on aarch64 as a daily driver?
<veleiro>
yes, pinebook pro
<veleiro>
few people here do
<samueldr>
not really using... yet... but swimming in builds daily
quinn has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
veleiro has quit [Read error: Connection reset by peer]
Darkmatter66 has quit [Ping timeout: 256 seconds]
<Gaelan>
Anyone know where the RPi kernel dtbos are in nixpkgs these days?
<Gaelan>
found it: ${pkgs.raspberrypifw}/share/raspberrypi/boot/overlays
<unclechu>
samueldr: using 4.19 kernel modules fixed console in HDMI for me
<samueldr>
good to know
<samueldr>
though that does point to there being some kind of issue
<unclechu>
`error: unable to fork: Cannot allocate memory` i guess it’s time to add a swapfile
<unclechu>
hey, any ideas why wpa_supplicant systemd service may fail to start at device boot?
<unclechu>
when i just restart it after booting manually it connects to the wifi network perfectly fine
veleiro has joined #nixos-aarch64
<unclechu>
in the journalctl it looks like when it runs wpa_supplicant-start it just shows wpa_supplicant executable usage info
<unclechu>
like the arguments are incorrect
<unclechu>
in the service file it has `Before=network.target`, does it mean that wpa_supplicant starts before even network is initialized?
Darkmatter66 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
cole-h has joined #nixos-aarch64
veleiro has quit [Remote host closed the connection]
<sphalerite>
unclechu: that happens when there aren't any network interfaces available iirc. Maybe try adding systemd.services.wpa-supplicant.after = ["sys-subsystem-net-devices-wlp3s0.device"];
<sphalerite>
unclechu: and also the same but with wantedBy instead of after
<sphalerite>
(and replacing wlp3s0 with your wlan device name of course)
<sphalerite>
angerman: btw the SD image builds a LOT faster if you use a bigger block size for the dd commands, like dd conv=notrunc if=./root-fs.img of=$img seek=$((START/64)) count=$((SECTORS/64)) bs=$((512*64))
<sphalerite>
though not limiting it to a specific block size would be the best solution
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
NickHu has quit [Quit: Bridge terminating on SIGTERM]
Ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
mica[m] has quit [Quit: Bridge terminating on SIGTERM]
Dandellion has quit [Quit: Bridge terminating on SIGTERM]
fgaz has quit [Quit: Bridge terminating on SIGTERM]
colemickens has quit [Quit: Bridge terminating on SIGTERM]
thefloweringash has quit [Quit: Bridge terminating on SIGTERM]
kyren has quit [Quit: Bridge terminating on SIGTERM]
Ke has quit [Quit: Bridge terminating on SIGTERM]
hpfr has quit [Quit: Bridge terminating on SIGTERM]
pinage404[m] has quit [Quit: Bridge terminating on SIGTERM]
manveru[m] has quit [Quit: Bridge terminating on SIGTERM]
bbigras has quit [Quit: Bridge terminating on SIGTERM]
danielrf[m] has quit [Quit: Bridge terminating on SIGTERM]
kloenk has quit [Quit: Bridge terminating on SIGTERM]
Danct12[m] has quit [Quit: Bridge terminating on SIGTERM]
submoo[m]1 has quit [Quit: Bridge terminating on SIGTERM]
cornu has quit [Quit: Bridge terminating on SIGTERM]
puzzlewolf has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
roberth has quit [Quit: Bridge terminating on SIGTERM]
DavHau[m] has quit [Quit: Bridge terminating on SIGTERM]
noneucat has quit [Quit: Bridge terminating on SIGTERM]
zaynetro[m] has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
l-as has quit [Quit: Bridge terminating on SIGTERM]
unclechu has quit [Quit: Bridge terminating on SIGTERM]
Ox4A6F has quit [Quit: Bridge terminating on SIGTERM]
flo[m]3 has quit [Quit: Bridge terminating on SIGTERM]
leonardp has quit [Quit: Bridge terminating on SIGTERM]
bennofs[m] has quit [Quit: Bridge terminating on SIGTERM]
yangm has joined #nixos-aarch64
roberth has joined #nixos-aarch64
mica[m] has joined #nixos-aarch64
LinuxHackerman has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
cornu has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
submoo[m] has joined #nixos-aarch64
kloenk has joined #nixos-aarch64
manveru[m] has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
Ke has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
flo[m] has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
pinage404[m] has joined #nixos-aarch64
NickHu has joined #nixos-aarch64
siraben has joined #nixos-aarch64
DavHau[m] has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
colemickens has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
unclechu has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
l-as has joined #nixos-aarch64
zaynetro[m] has joined #nixos-aarch64
kyren has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Remote host closed the connection]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 246 seconds]
Darkmatter66_ has quit [Ping timeout: 240 seconds]
__gotcha has joined #nixos-aarch64
<sphalerite>
uuuugh "import fees are due for this package" sooo I won't be getting my honeycomb _too_ soon.
<sphalerite>
Well, that's the $100 discount out the window again x)
bdju has quit [Ping timeout: 260 seconds]
__gotcha has quit [Ping timeout: 264 seconds]
mschwaig has quit [Quit: WeeChat 3.0]
mschwaig has joined #nixos-aarch64
Ultrasauce has quit [Quit: Ultrasauce]
mschwaig has quit [Quit: WeeChat 3.0]
mschwaig has joined #nixos-aarch64
mschwaig has quit [Client Quit]
mschwaig has joined #nixos-aarch64
Ultrasauce has joined #nixos-aarch64
<Ke>
pretty much, though you would have had to pay even more import fees covering that 100 too
<LinuxHackerman>
true
mschwaig has quit [Quit: WeeChat 3.0]
__gotcha has joined #nixos-aarch64
mschwaig has joined #nixos-aarch64
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
srk has quit [Ping timeout: 240 seconds]
srk has joined #nixos-aarch64
__gotcha has quit [Ping timeout: 264 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
__gotcha has joined #nixos-aarch64
bdju has joined #nixos-aarch64
__gotcha has quit [Remote host closed the connection]
rajivr has quit [Quit: Connection closed for inactivity]
Darkmatter66 has joined #nixos-aarch64
<clever>
lovesegfault: hyperpixel screen has arrived!
<clever>
along with a pi0
justanotheruser has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
Mic92 has joined #nixos-aarch64
<cole-h>
samueldr: (whenever you're back) How would I go about finding the "proper files" and "board-specific boot order"? If I want to boot from SPI, do I need a specialized image for NixOS?
<cole-h>
Oh, looks like "boot order" is SPI, eMMC, uSD, USB, then PXE for the rock64
<samueldr>
you can also, on a built u-boot, during runtime, explore the environment using `env`
<samueldr>
btw, if it wasn't obvious, "marked bootable" is the MBR flag (or legacy flag for GPT)
<samueldr>
it can alternatively be the ESP type GUID
<samueldr>
but our builds can't support GPT for the time being because of embedding u-boot at arbitrary locations on the media
<samueldr>
cole-h: depending on what your goal is, basically you need to run u-boot in some way... the most trivial way if it's not in SPI flash already, is to have it loaded from SD card
<samueldr>
the rockchip SoC will not load the firmware from usb
<samueldr>
(firmware == u-boot)
<samueldr>
u-boot acts more like a bios than a bootloader, or rather, it's really sitting on the fence
<LinuxHackerman>
both, no?
<samueldr>
yes and no for both ;)
<samueldr>
the ATF does some stuff
<samueldr>
(Arm Trusted Firmware)
<samueldr>
and it might be loading an EFI program, which in turn would be the real bootloader
<samueldr>
where u-boot's job starts and ends is fuzzy
<samueldr>
but it _is_ squarely sitting on both seats at once
<samueldr>
oh, and it will differ depending on the platform!
<cole-h>
I see. IIUC, I can just flash the SPI with u-boot, and then install to the USB disk as "normal"?
<samueldr>
"just" :)
<cole-h>
I guess there's only 1 way to really find out
<samueldr>
but yeah
<cole-h>
Well, assuming I can use the prefab uboot from ayufan, it should only amount to that
<samueldr>
if it's on SPI, your board will act much more like a "normal computer"
<samueldr>
rock*64? why would you not use mainline u-boot?
Mic92 has quit [Quit: WeeChat 3.0]
<cole-h>
Because ayufan has an image that I can burn to the sd card that will flash the SPI for me :P
<andi->
Now that the unstable channel bumped I can continue.
<samueldr>
(this is the u-boot side of the equation)
<samueldr>
I'd like to have the firmware installer menu somehow into nixos
<samueldr>
and working across all boards that can support it (e.g. allwinner too)
<andi->
I saw your script but I didn't really get how or why that works
<andi->
it seems like many indirections
<samueldr>
heh, it needs to be cleaned-up
<samueldr>
oh poo, I forgot
<samueldr>
it also needs mainline u-boot patches to be written
<samueldr>
as there are... issues...
<samueldr>
but yes, it's some levels of indirection
<andi->
I was just trying to build with one of those and it doesn't apply anymore..
<samueldr>
the flashing script needs to be able to be ran from an already-installed SPI flash image
<samueldr>
so you can insert your USB drive, then "boot" from USB into the firmware flash script
<andi->
I stil prefer being able to flash from within linux but ultimately you are right we need that as alternative & recovery method
<samueldr>
yes
<samueldr>
I want all the flash methods to be available :)
<samueldr>
but this menu is maybe not a nixos project outright
<samueldr>
but a "golden u-boot builds association of distros" kind of thing
<samueldr>
something I alluded to being needed
<samueldr>
semi-impartial cross-distro group of maintainers of binary builds of the mainline u-boot
<samueldr>
with work towards ease of use
<samueldr>
make it work through menus
<samueldr>
make it easy to grasp
<andi->
yes!
<andi->
Right now it is such a mess.
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 264 seconds]
<sphalerite>
build a forth interpreter into it :p
<cole-h>
If I enabled `boot.binfmt.emulatedSystems`, I need to reboot for it to take effect, right? Trying to make an aarch64-linux ISO image to try to boot from
<sphalerite>
cole-h: hm, shouldn't be necessary I think
<samueldr>
sphalerite: isn't there already one?
<sphalerite>
samueldr: news to me, but also I wouldn't be completely surprised.
<samueldr>
anyway, if I was left to my own machinations, I would use the same stuff I use for mobile nixos' stage-1 to make a truly graphical menu
<andi->
ok, the SPI supporting u-boot is built. Now I've to figure out the offset at which I've to flash it and how I can then configure that u-boot so my device still boots from sdcard..
<andi->
I wish this would just be EFI to configure the boot payload..
<sphalerite>
u-boot can do that, no?
<andi->
yeah but initially? :D
<andi->
and where do the efivars go?
srk has quit [Ping timeout: 240 seconds]
<andi->
I fear I might have to implement that for the SPI chip?
srk has joined #nixos-aarch64
<sphalerite>
initially? I guess u-boot can use the fallback path?
<andi->
> UEFI variables storage service via OP-TEE
<{^_^}>
undefined variable 'UEFI' at (string):460:1
<andi->
It also supports file based storage
<samueldr>
andi-: no efivar
<samueldr>
uh
<samueldr>
maybe efivar in the end?
<andi->
yeah
<andi->
looks like one can make it happen
<andi->
not sure what it takes for the specific board
<andi->
but I guess file system or op-tee is standardized enough
<samueldr>
probably ATF shenanigans
<samueldr>
(OP-TEE being a name for a trustzone implementation)
<andi->
yeah
<samueldr>
filesystem cannot happen
<andi->
hu, why?
<samueldr>
because the operating system would be in control in practice of the block devices
<samueldr>
you could do it
<samueldr>
and break things
<samueldr>
though saving on SPI flash should work because it's not really a block device like your SD card
<samueldr>
the OS really shouldn't be fighting with the firmware
<andi->
so that gets me back to implementing EFI VAR on SPI? :D
<samueldr>
yeah, through the ATF I figure
<andi->
ATF?
<sphalerite>
surely u-boot should be able to do that?
<samueldr>
ATF -> Arm Trusted Firmware
<samueldr>
the open source and reference trustzone implementation
<andi->
kk
<sphalerite>
Since the SPL loads u-boot from the flash, why shouldn't u-boot or the SPL be able to load efivars from flash as well?
<samueldr>
sphalerite: possibly, but if there's already code paths to do it from a trustzone implementation, it's probably best to leave it to the trustzone ?
<andi->
sphalerite: theoretically it should be possible I just do not see anything shouting SPI + EFI in the source
<samueldr>
yeah, the EFI services for u-boot are extremely minimalistic by design
<samueldr>
just enough to boot an EFI program
<andi->
which is perfectly fine
<samueldr>
yes
<andi->
worst case we boot yet another loader on the devices
<andi->
Best case I can just push EFI entries for each generation
<sphalerite>
samueldr: aaah makes sense
<samueldr>
AFAIK there is no support for anything else than the default fallback EFI program right now
<sphalerite>
samueldr: oh, I didn't realise that.
<andi->
so you can't boot into say grub?
<sphalerite>
sure, you just need to put grub at the fallback path
<samueldr>
exactly
<samueldr>
my pine a64-lts boots grub
<samueldr>
euh
<samueldr>
maybe
<samueldr>
I'm not sure about that one
<samueldr>
my pinebook a64 boots grub
<andi->
nice
<samueldr>
(but I don't boot the pinebook a64 really because its keyboard angers me)
<andi->
(so sad :/)
<samueldr>
note: pinebook a64, not pinebook pro, pinebook pro has a more-than-passable keyboard
<andi->
I lost track of all those pine devices
<samueldr>
heh
<samueldr>
there's even two pinebook a64, I think the 14" should have a better keyboard
<andi->
so the way to approach this would be to "hardcode" booting from grub in the fallback path so I do not need EFI Vars?
<samueldr>
I was thinking about using rEFInd, but at the time the aarch64 build didn't work
<samueldr>
refind can save boot options to a text file
<samueldr>
or uh
* samueldr
boots the pinebook a64
<samueldr>
yep, directly to grub
<andi->
and that means uboot -> grub, right?
<andi->
I am still missing lots of documentation on this whole mess :/
<andi->
The u-boot repo isn't really well documented
<samueldr>
yes, u-boot boots (using EFI) to GRUB
<andi->
ok
<samueldr>
rEFInd would be really helpful as a default payload to u-boot too
<andi->
that directly confused me for a second :D
<samueldr>
because of how it scans for *any* EFI program
<cole-h>
grr, HDMI doesn't work for some reason
<samueldr>
on u-boot? is it supposed to work with that fork?
<cole-h>
I mean, after u-boot does it's thang
<cole-h>
do I have to install to the HDD before I do the SPI flash thing? I can't tell if it's booting from my USB image or not.
<andi->
Ok, now on to figuring out how to append config to the SPI image
<samueldr>
cole-h: where it's installed doesn't matter to u-boot, it only needs to run *somehow*
<samueldr>
but it may or may not be able to use the media you want to
<samueldr>
(for booting the system)
<cole-h>
jfkldsa
<cole-h>
I can't even tell what's not working
<cole-h>
Is it the USB image that's busted? Is it the SPI boot thing? Is it networking?
<cole-h>
Frustrating
<samueldr>
do you have a serial interface cable?
<samueldr>
how is u-boot currently starting?
<samueldr>
(or trying to)
<cole-h>
I don't have a serial cable, and I did the SPI method with ayufan's prefab image
<cole-h>
Maybe even ethernet isn't working, because even setting a static IP in the ISO config doesn't work
<cole-h>
Guess I'll try again tomorrow
<andi->
So apparently armbian isn't just concatinating spl + u-boot.itb but writing u-boot.itb at offset 0x300... I just wish there was documentation on this stuff anywhere.. The radxa rockpi4 SPI image has just the string "uboot" at 0x300 and then a space a few hundred characters later...
<samueldr>
yeah, I don't remember being able to find good info on how SPI builds actually boot
<andi->
I mean it still amazes me that the sd-card just worked
tilpner has quit [Remote host closed the connection]
* andi-
bookmarks todays conversation for next time
<samueldr>
you'll have to handle those differently
<samueldr>
I don't deal with binary blobs
<samueldr>
rkspi_loader is a binary blob from rockchip
<andi->
I haven't had to us that for sd boot so I guess I will not need it
<samueldr>
you shouldn't
<samueldr>
AFAIK if it works on SD, everything will work for SPI*
<samueldr>
* as long as SPI is configured properly in the device tree
<samueldr>
AFAIK there is nothing board-specific to SPI vs. SD
<samueldr>
(except configuring it)
<andi->
so apparently I can't build SPI + SD u-boot into one binary :/
<andi->
that would be too good
<samueldr>
ah
<samueldr>
that would be nice indeed
<andi->
I do not understand why that wouldn't work
<samueldr>
but I assume the initial loader is different
<samueldr>
because the initial loader has to init just enough of u-boot to load u-boot from the storage it was loaded from
<samueldr>
the SoC will not load all of u-boot
<samueldr>
it will only load "n" amount of bytes
<samueldr>
and that program will, in turn, do the work of loading u-boot for real
<samueldr>
(different per platform IIRC)
<samueldr>
(but same idea)
<samueldr>
that's why you see u-boot-sunxi-with-spl in the filenames for allwinner
<samueldr>
with-spl is that "intial" (uh secondary) loader
<samueldr>
I guess in their terminology initial would be the SoC bootrom
<andi->
garr, how I hate these distributions that are held together with 50 levels of makefiles and shell scripts downloading random binaries build in other repositories..
<samueldr>
I do too :)
<clever>
i believe the SPL (secondary program loader) deals with bringing dram online, and then loading whatever was appended to it
<andi->
that actually makes sense
<samueldr>
clever: yeah, on som SoCs it has to do more work than *only* loading
<clever>
it may not even be "whatever was appended", but instead just "whatever is at offset X"
<andi->
but why that weird padding after the spl in some variants?
<samueldr>
but basically the same idea, it has to finish booting up the system to continue booting
<clever>
but they arrange the size of the SPL, so when you put it at offset Y, the uboot you appended winds up as X
<samueldr>
andi-: rockchip binary blob loader
<samueldr>
that replaces the SPL from u-boot
<samueldr>
it's code from rockchip that does stuff to then load "a" program at a given offset
<clever>
samueldr: in other news, i got a pi0 and a hyperpixel display, both work together well, but 512mb of ram and armv6 are crippled by just opening chrome, lol
<samueldr>
heh
<andi->
swap!
<andi->
zram!
<clever>
andi-: i added swap, and it didnt really help
<andi->
anyway, i'll continue this journey another day..