<Bla[m]>
samueldr: colemickens 👋 I'm archseer on github
<Bla[m]>
Just noticed you guys discussed the same change here that I mentioned on the PR
<samueldr>
yeah
<Bla[m]>
The model for flakes that I was looking at was similar to nixos-hardware
<samueldr>
didn't want to cut you off from the discussion or anything
jumper149 has quit [Quit: WeeChat 3.0]
<samueldr>
I'm not looking into adding actual flake support yet, only making the eval pure from NIX_PATH so it _can_ be used within a flake
<Bla[m]>
The flake layer would basically have you do: imports = with mobile-nixos.nixosModules; [ devices-pine64-pinephone all-modules ]; and sidestep default.nix
<samueldr>
default.nix really is only used when "imperatively" building an image
<Bla[m]>
I was able to get the image builder running via `nix build `.#nixosModules.mypine.config.system.build.disk-image` as well
<Bla[m]>
* I was able to get the image builder running via `nix build .#nixosModules.mypine.config.system.build.disk-image` as well
<Bla[m]>
So for the most part it works out of the box, it just needs that flake shim
<samueldr>
yeah, in the end all results are nixos build output
<Bla[m]>
PR-wise: I think, if using `(import <mobile-nixos/lib/configuration.nix> { device = "xxx-yyy"; })` in your configuration.nix will run into the same issue I was having: a missing _mobile-nixos parameter
<samueldr>
I'll be taking a more in-depth look in a short while
<Bla[m]>
I'll push what I have later today, just figured I'd quickly jump in the conversation
<Bla[m]>
Got one of those new pinephone models last week so I'm messing around with it this week -- planning to update that nixpkgs phosh PR as well
<samueldr>
thanks
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-aarch64
<colemickens>
how do people build for armv6 btw?
<samueldr>
slowly
<samueldr>
with great difficulty
<colemickens>
doesn't seem like there's as much literature about using qemu or such like there was for arm7l on aarch64
<samueldr>
the only safe method to build for armv6l is actually native builds
<colemickens>
so like emulate the entire arch on x86 or something?
<samueldr>
actually native can be a full blown qemu emulator
<samueldr>
qemu-user IIRC is problematic as always
<samueldr>
qemu-user is _more_ problematic with armv6l than with armv7l
<colemickens>
do you get an advantage for using full qemu arm6 on aarch64?
<colemickens>
or am I better off getting a beefy x86_64 and running it there?
<samueldr>
I'm not sure you can do KVM virt for armv6 building
<samueldr>
I seem to recall having checked and that it was actually an armv7l cpu in the end
<samueldr>
I literally don't know what to do for armv6l
<samueldr>
I would say: use cross-compilation
<samueldr>
but you know
<colemickens>
ah I see okay
<colemickens>
yeah
<samueldr>
there is no "fast armv6l" platform
<samueldr>
and AFAIUI no way to make armv7l or armv8 or aarch64 be strictly armv6l
<samueldr>
so you get ambient impurities of the instruction set existing on the CPU
rajivr has joined #nixos-aarch64
<samueldr>
fun tidbit, if you boot a samsng-a5y17lte by plugging its usb cable, it boots in "battery charge indicator" mode, which is a full linux system
<samueldr>
which, in turn is the normal boot.img
<samueldr>
normally its boot gets interrupted that early in the process to show the battery charge applet
<samueldr>
but we don't support that yet
<samueldr>
but the fun thing is that it (I suppose) uses a different FDT
<samueldr>
and the touchscreen is not active!
<samueldr>
and yes, Linux gets booted to show you the charge level on AFAIUI most android phone implementations
cole-h has quit [Ping timeout: 246 seconds]
<colemickens>
do we know who Gaelan , oh hello Gaelen!
<colemickens>
I modified thefloweringash 's thingy to make kvm optional as well as a switch between qemu-system-{aarch64,arm}. So if I can get an initial VM build up with cross, maybe I can go from there.
<colemickens>
aha
<colemickens>
nice
<colemickens>
(qemu-system-arm has a profile for raspi0 it seems, fingers crossed)
<samueldr>
yes, the goal indeed was to go from an armv7l cross-compiled vm
<samueldr>
oh, though you need to run qemu-system-aarch64 IIRC to get KVM
<samueldr>
or else it's just emulation
<samueldr>
you actually run an armv7l kernel (32 bit) on an aarch64 KVM vm
<colemickens>
but that's what I want for raspi0 due to arm6l
<samueldr>
yeah
<colemickens>
hence the switch ;)
<samueldr>
just saying
<colemickens>
it still supports both
<samueldr>
in case you thought it was odd to use qemu-system-aarch64 for armv7l
<colemickens>
oh, no, not really, I saw the aarch64=off somewhere that I guess makes that magic happen
<colemickens>
plus it makes sense since I know I can boot the rpi4 in arm7l somehow
<samueldr>
yep
<colemickens>
cool
<samueldr>
nixos-20.09 may also cross-compile more readily, using my repo with known workarounds
<samueldr>
Bla[m]: I just checked that on one device the documented way to eval a nixos config for nixos-rebuild still works
<samueldr>
not sure if there's anything else about flake you can test
<samueldr>
I did make the change you proposed
<Bla[m]>
okay, I just left a comment on the PR
<Bla[m]>
I think you can drop _mobile-nixos & custom eval completely now
<samueldr>
haha oh
<samueldr>
no
<Bla[m]>
Is there places that still reference the _mobile-nixos path?
<samueldr>
I need _mobile-nixos for path for hermetic eval in another repo
<samueldr>
(without flake)
<Bla[m]>
hmm okay 🙂
<samueldr>
well, path not really, but _mobile-nixos.evalConfig I do
<samueldr>
I have this x86_64 tablet which boots using the UEFI system
<samueldr>
but it *also* can boot android bootimg
<Bla[m]>
so app-wise I've been looking at writing some stuff in flutter. flutter + wayland is popular in embedded development currently
<samueldr>
I don't give a crap about stage-2 ;)
<Bla[m]>
yeah 😛
<samueldr>
nah, really I mean the goal of the project is abstracting and harmonizing the device specifics
<samueldr>
but that's cool to hear
<Bla[m]>
Oh I was curious, what made you choose mruby for some of the bootloader code?
<samueldr>
(1) not C
<samueldr>
(2) I know it
<samueldr>
(3) cross-compiles trivially
<Bla[m]>
I don't really have a good impression of it, I used to write some patches for it back in the day
<Bla[m]>
wrote a game engine that used it at some point too
<samueldr>
I wanted to use Rust at first, but cross-compilation *within Nixpkgs* doesn't work
<samueldr>
I think you can use "rust-y" cross-compilation, but I'm not a Rust user/dev yet
<samueldr>
so it also failed (2)
<Bla[m]>
back then matz seemed to passively maintain it, and mainly address crashes through user reports
<samueldr>
"I know it" meant Ruby
<samueldr>
I hadn't used mruby
<samueldr>
my opinion is that it's passable-to-good, would use it again
<samueldr>
but I know it's not perfect
<Bla[m]>
That said, stage 0 and 1 do look a lot better than the native nixos ones
<samueldr>
that was partially a goal of mine
<Bla[m]>
I know there's some work to do those with systemd in early boot but most of the PRs went stale
<samueldr>
since we can't rely on the console on many devices, I had to implement *some way* of making the status obvious
<samueldr>
and since I *anyway* had to do a recovery app, I used the same GUI thing
<samueldr>
and since it has a lot of features, it was trivial to make that juicy boot
<Bla[m]>
colemickens: by the way, it's crazy how every time I have a nixos problem there's either an issue, a PR or a helpful forum comment by you somewhere 😀
<samueldr>
though yeah, once systemd in stage-1 becomes something with Nixpkgs, I'll re-evaluate for init
<samueldr>
but mruby is likely to stay for the apps and boot splash
<Bla[m]>
I looked into helping out there but the systemd documentation was really sparse
<samueldr>
if it hadn't been mruby, it would have been lua, probably luajit because of its ffi
<Bla[m]>
The user side is well documented, but there's not a lot of demand for early user docs I guess
<samueldr>
I guess :)
<Bla[m]>
*early boot
<samueldr>
elvish//jerricco has been working on systemd in stage-1 on their own time, not shared anything yet
<colemickens>
what kind of little tease is that that just got dropped
<samueldr>
colemickens: which?
<colemickens>
oh okay, I see it relates to the mruby init stuff
<colemickens>
systemd in stage-1 is some specific weird thing that I'm excited to see
<samueldr>
there might be contributions soon about that
<samueldr>
(in NixOS proper)
<samueldr>
but I don't have any special knowledge
<samueldr>
only what was said publicly in #nixos-dev
<colemickens>
aha
<samueldr>
Bla[m]: I must also say that, since I was already used to Ruby dev, it made things *real* quick for developing the initial drafts
<Bla[m]>
systemd: there was one or two PRs open about that, they're just old
<Bla[m]>
one reimplemented the whole boot from scratch the other one kinda patched it in
<samueldr>
I am willing to bet that, because I never actually did Rust, I would have hated a lot of the time spent on it, and it might have taken 10× the time
<Bla[m]>
samueldr: yeah once upon a time Ruby used to be my main language too 🙂
<samueldr>
(hated only because I would have spent time fighting with learning instead of doing)
<matthewcroughan>
samueldr: I'm still stumped on u-boot :D
<matthewcroughan>
Some guy suggested I compile uboot with DEBUG on
<matthewcroughan>
Gonna do that next, but do you have any more wisdom in your fountain?
orivej has joined #nixos-aarch64
<samueldr>
not really
* colemickens
imagines a nix build split across 96 single core qemu-system-arms
<samueldr>
colemickens: I/O starvation ahoy!
<samueldr>
every one of those cores wanting to do filesystem access for a different purpose, at the same time
<samueldr>
that can't end well
<Bla[m]>
Yeahh so I still get missing _mobile-nixos failures
<samueldr>
no idea if u-boot is expected to work though
<samueldr>
and recent images are built using u-boot
<elvishjerricco>
It complained about not finding a usb controller then looped on pxe, eventually dropping into a u-boot shell thingy
<samueldr>
ah
<samueldr>
then u-boot works
<samueldr>
booting from SD/MMC or from USB?
<elvishjerricco>
SD, yea
<samueldr>
hm
<samueldr>
I would assume some shenanigans with u-boot and SD support on the CM4
<samueldr>
without any more detail
<elvishjerricco>
Hm. I would have figured SD would be the same on CM4 as rpi4
<samueldr>
I would have too
<samueldr>
but here we see u-boot not using SD AFAICT
<samueldr>
:)
<elvishjerricco>
samueldr: Was that hydra link the right place for me to start? Or should I try a different image?
<samueldr>
that's the sd image built for the raspberry pi 4
<samueldr>
that's as good a place to start as a ny
<samueldr>
I wouldn't expect the generic sd image to boot
<elvishjerricco>
From the wiki for nixos on rpi4: "(Until the generic image works, a temporary device-specific image is build on Hydra. Note that this image is not using u-boot, but rather the Raspberry Pi specific bootloader configuration.)"
<elvishjerricco>
The quote says it doesn't use u-boot but mine dropped me into a u-boot shell
<samueldr>
it didn't
<samueldr>
now it does
<elvishjerricco>
Ah, so the wiki is out of date?
<samueldr>
yeah
<elvishjerricco>
Hm. So what are the next steps?
<elvishjerricco>
I'm happy to put in the effort for supporting CM4 as long as I can understand it :P
<samueldr>
A. figure out if u-boot should work with CM4
<samueldr>
B. build a non-u-boot raspberry pi 4 image
<samueldr>
(alternative steps)
<samueldr>
C. open that PR with stage-1 systemd
<samueldr>
oops
<samueldr>
;)
<elvishjerricco>
:P
<samueldr>
do you have another aarch64 system to build from?
<samueldr>
since it's about assembling the image, it shouldn't require much cpu horsepower
<elvishjerricco>
If the rpi 3B+ counts, yea, but that's bad
<samueldr>
assuming you start from a revision of nixpkgs hydra built the image for
<elvishjerricco>
But I found that building GHC using qemu binfmt emulation for aarch64 only took 8 hours so that's also an option :P
<samueldr>
right, and since it's only about assembling an image it may work
<elvishjerricco>
Well I was joking but if that's seriously plausible I'll give it a go
<samueldr>
yeah, since it's about assembling the image
<samueldr>
which gives a false illusion qemu-user is a good solution to build aarch64 stuff :)
<samueldr>
(you get a lot from the hydra cache)
<elvishjerricco>
Well cool. I'll probably start on this tomorrow
<elvishjerricco>
One more footnote: The CM4 doesn't have a USB 3 controller, instead offering a PCIe slot.
<elvishjerricco>
I'm guessing the SD card in the usual rpi4 isn't through that USB 3 controller, right?
<samueldr>
pretty sure it isn't
<samueldr>
must be to the SoC
<elvishjerricco>
Alright. That's probably a good thign
<elvishjerricco>
samueldr: I'm curious what the stage-1 systemd thing would do to help here
<samueldr>
that was a joke
<elvishjerricco>
Ah :P
<elvishjerricco>
Yea I got LUKS working, so now I just need to rewrite it as a part of nixpkgs instead of a standalone module
<samueldr>
I think many contributors and users are interested in seeing that
<elvishjerricco>
"rewrite" meaning "replace one file with another and change like 3 identifiers"
<samueldr>
native is native to where the build happens
<Bla[m]>
Found pkg-config: /nix/store/d398vgb2p8w5kamkncn7lwd3d33lk7a8-aarch64-unknown-linux-gnu-pkg-config-wrapper-0.29.2/bin/aarch64-unknown-linux-gnu-pkg-config (0.29.2)
<Bla[m]>
did not find cmake
<samueldr>
oh uh
<samueldr>
yeah
<samueldr>
misread
<Bla[m]>
> Run-time dependency libxml-2.0 found: NO (tried pkgconfig)
<{^_^}>
error: syntax error, unexpected ':', expecting ')', at (string):471:37
<Bla[m]>
maybe it needs to be listed under both nativeBuildInputs and buildInputs?
<samueldr>
(when things start to break, I generally wait it out a week or two to batch subsequent breakage fixes)
<Bla[m]>
I'm probably doing something wrong
<Bla[m]>
> output '/nix/store/b8b8s11y4dc7d4h55d15jlf3n2fy2f5j-libxkbcommon-1.0.3-aarch64-unknown-linux-gnu' is not allowed to refer to the following paths:
<Bla[m]>
I know I could pin an older nixpkgs version, I just like to build all my devices from the same base
<samueldr>
for me the lazy way is using an older nixpkgs version
<Bla[m]>
neat! it built, took about 15min total
<colemickens>
what a small world. I had the acme PR pulled up and the person I mentioned in here a while ago commented 2 hours ago on it. I guess it is still nixpkgs, but for a name I didn't recognize before today :mindblown:
<colemickens>
gah, and their nixpkgs got a lot further, but still didn't cross compile for armv6
<Bla[m]>
I got everything built then realised it needs a sd card to flash to eMMC still... looks like I'll keep testing tomorrow
<samueldr>
yeah
<samueldr>
that's a bit of a bummer to be frank
<samueldr>
if the u-boot build had display out, and usb, all configured, it should be possible to make it do either fastboot or mass storage device from the main os
<samueldr>
well, from the main u-boot installed to it
<samueldr>
the latter should be readily possible, though (usb)
<samueldr>
I simply think the community don't care at all for u-boot
cole-h has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo_ has quit [Client Quit]
zupo has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
evils has quit [Ping timeout: 265 seconds]
hexa- has quit [Ping timeout: 265 seconds]
Church- has quit [Ping timeout: 264 seconds]
hexa- has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
evils has joined #nixos-aarch64
Ox4A6F has quit [Quit: Bridge terminating on SIGTERM]
Ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
fgaz has quit [Quit: Bridge terminating on SIGTERM]
edrex has quit [Quit: Bridge terminating on SIGTERM]
hpfr has quit [Quit: Bridge terminating on SIGTERM]
Dandellion has quit [Quit: Bridge terminating on SIGTERM]
JJJollyjim has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
dtz has quit [Quit: Bridge terminating on SIGTERM]
yangm has quit [Quit: Bridge terminating on SIGTERM]
danielrf[m] has quit [Quit: Bridge terminating on SIGTERM]
DavHau[m] has quit [Quit: Bridge terminating on SIGTERM]
hiroshi[m] has quit [Quit: Bridge terminating on SIGTERM]
roberth has quit [Quit: Bridge terminating on SIGTERM]
colemickens has quit [Quit: Bridge terminating on SIGTERM]
cornu has quit [Quit: Bridge terminating on SIGTERM]
Ke has quit [Quit: Bridge terminating on SIGTERM]
kloenk has quit [Quit: Bridge terminating on SIGTERM]
unclechu has quit [Quit: Bridge terminating on SIGTERM]
manveru[m] has quit [Quit: Bridge terminating on SIGTERM]
thefloweringash has quit [Quit: Bridge terminating on SIGTERM]
pinage404[m] has quit [Quit: Bridge terminating on SIGTERM]
Danct12[m] has quit [Quit: Bridge terminating on SIGTERM]
flo[m] has quit [Quit: Bridge terminating on SIGTERM]
leonardp has quit [Quit: Bridge terminating on SIGTERM]
Bla[m] has quit [Quit: Bridge terminating on SIGTERM]
submoo[m] has quit [Quit: Bridge terminating on SIGTERM]
craige[m]1 has quit [Quit: Bridge terminating on SIGTERM]
pachumicchu has quit [Quit: Bridge terminating on SIGTERM]
l-as has quit [Quit: Bridge terminating on SIGTERM]
bbigras has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
veleiro has quit [Quit: Bridge terminating on SIGTERM]
sarcasticadmin has quit [Quit: Bridge terminating on SIGTERM]
noneucat has quit [Quit: Bridge terminating on SIGTERM]
puzzlewolf has quit [Quit: Bridge terminating on SIGTERM]
mica[m] has quit [Quit: Bridge terminating on SIGTERM]
chr0ma[m] has quit [Quit: Bridge terminating on SIGTERM]
<colemickens>
git history probably isn't clean, and I should send just the u-boot bit as a PR. Though I understand we have longer term aspirations for how all of this should go.
<samueldr>
(I have)
<samueldr>
I don't think there is a "we" plan really
alpernebbi has quit [Quit: alpernebbi]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
dustinm has quit [Quit: Leaving]
justanotheruser has quit [Ping timeout: 260 seconds]
mahogany has quit [Quit: Konversation terminated!]