<angerman>
I know some people actually use haskell.nix to build arm binaries. blackriversoftwa I abbliebe and there is another one in the issue haskell.nix tracker who just found a weird ghc llvm Ir bug. I haven’t heard of incorrect sizes yet?
<clever>
angerman: first, i should start by trying to just build brick for the host, using haskell.nix, then it should "just work" when i set crossSystem...
<angerman>
That’s the idea after all, yes.
<clever>
angerman: what if i lack both a stack.yaml and a cabal.project?
<angerman>
cabal.project < "packages: ."
<clever>
i dont have a cabal file either, i was trying to get brick to build before i started that
<angerman>
I think we might even infer that if there is no cabal.project, but maybe not.
<angerman>
Haskell-Nix.hackage-package { Name = „brick“ ... }
<clever>
heh, i cant just eval haskell.nix from `nix repl nix/sources.nix`
<clever>
the attr needs to be quoted, so it wont work via the current scope, only as foo."haskell.nix"
<jamii>
You asked about the app I was making and I said I would post something tomorrow. About three weeks ago :)
<samueldr>
oops, that memory of the event must have left me :)
<jamii>
:)
<samueldr>
I'm currently putting some ducks in a row about writing stuff
<samueldr>
I'll end up writing a (personal blog) post about mobile nixos and the pinephone "some assembly required"
<samueldr>
because while I don't remember about the app, now I remember about helping you getting started
<jamii>
Sweet, I'll keep an eye out for it
<clever>
angerman: ah, it needed just "packages:", the `.` complained due to a lack of .cabal files
<jamii>
Thanks for the help btw
<samueldr>
they'll mostly be a rehash of the instructions, plus a couple alternative ways to do so
<samueldr>
I don't think they'll end up useful for you :)
<angerman>
clever: cabal less projects seem odd.
<clever>
angerman: its more that i havent written a cabal file yet, because there is no point if i cant get the deps to build
<jamii>
They might. I have everything working but I don't understand what I did. Eg why there are separate stages, what the boot process looks like.
<jamii>
I guess I don't know much about arm in general.
<jamii>
samueldr: Can you recommend any good resources for getting a high-level understanding of how the boot process works on arm?
<samueldr>
hmm
<samueldr>
in a way, most of what is relevant here is not specific to arm
<samueldr>
the main thing specific is u-boot, and how it's part of the image
<samueldr>
u-boot is not specific to arm, though
<samueldr>
u-boot is kind of both a firmware (like a bios, like an uefi) and a bootloader (like grub, like systemd-boot)
<samueldr>
we can abstract the boot flow here to "somehow it jumps to u-boot", the details are probably not important unless you work on the bootloader
<samueldr>
and "somehow it jumps to u-boot" can be explained that the SoC looks for a program at a specific offset on the storage
<clever>
for allwinner stuff, i believe the SoC loads a small blob from a specific offset
<clever>
that blob brings dram online, and loads more blob after itself (the uboot code)
<samueldr>
yeah
<samueldr>
(but let's not break down the abstraction)
<samueldr>
at that point it's a bog standard nixos thing, nothing from Mobile NixOS
<samueldr>
that is stage-2
h0m1 has quit [Ping timeout: 240 seconds]
<samueldr>
so the boot chain specific to Mobile NixOS exists only from the boundary at the bootloader, up until the standard NixOS stage-2
<samueldr>
here the u-boot program is an implementation detail, it's not really part of Mobile NixOS and that u-boot build should be able to boot anything just like u-boot does
<jamii>
Ok, that makes things a lot clearer. Thanks for the explanation.
<jamii>
I have to join a call in a minute but I'll dig through this stuff tomorrow and see if I can get it all straight in my head :)
h0m1 has joined #nixos-aarch64
<samueldr>
no worries
<samueldr>
it _is_ a lot to digest, but thankfully there's not too much that's specific to Mobile NixOS
jamii has quit [Remote host closed the connection]
<{^_^}>
libjpeg-turbo/libjpeg-turbo#425 (by thefloweringash, 10 minutes ago, open): Build: add missing dependency for jpegtran icc test
FRidh has joined #nixos-aarch64
<Valodim>
we just wanted to plug a device into the rpi3b, and use it as a hidraw device. doing so we found that the kernel is built without CONFIG_HIDRAW
<Valodim>
it's a nixos 20.03 with no specific kernel package configured, which resolves to a 5.4.35
alp has joined #nixos-aarch64
<sphalerite>
Valodim: PR welcome ;)
<Valodim>
I'm not sure what to PR even? CONFIG_HIDRAW=y is set on five other nixos machines I could look at right now
<Valodim>
is there just one stray kernelPackages package that doesn't have it?
<fps>
ok, after installing nixos in a vm and getting my package to build now it's time to try building an image for the rpi4 :)
<fps>
wish me luck ;)
<fps>
will i need both the module and the overlay?
<fps>
ah, the qemu.nix references an overlay.. hmm
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
<fps>
hmm, i'm following the guide on the nixos arm wiki. trying to go the binfmt qemu wrapper route.
<thefloweringash>
Hm. That wiki looks a little outdated. There’s `boot.bintfmt.emulatedSystems = [ “aarch64-linux” ]` in upstream which does most of the work that the overlay does.
<srk>
gchristensen: thanks for the armv7 builds!
<srk>
looks way better now
makefu has quit [Quit: WeeChat 2.6]
<srk>
thefloweringash: and you too ;)
makefu has joined #nixos-aarch64
<makefu>
thefloweringash: sounds great, could you please fix the wiki entry with the new setup? :+1:
alp has quit [Ping timeout: 265 seconds]
<fps>
thefloweringash: oh, good to know!
<thefloweringash>
makefu, fps: I’ve updated the wiki
<makefu>
great, thanks!
<thefloweringash>
clever: FYI I’ve removed the link to your qemu directions on the wiki in favor of nixpkgs #61257
<srk>
playing with cross-compiling, something pulling copying path '/nix/store/lri4ga36rs450iwvvbcvsihjdcjfwzzr-firefox-60.9.0esr.source.tar.xz' from 'https://cache.nixos.org'...
<srk>
/o\
<thefloweringash>
I bet it's spidermonkey
<thefloweringash>
I think I saw spidermonkey 60 and spidermonkey 68 both scroll buy in recent times
<thefloweringash>
scroll by*, when building a system for mobile-nixos
<srk>
I see, what's pulling that?
<srk>
polkit..
<thefloweringash>
didn't stop long enough to find out :-)
<srk>
of course
<srk>
polkit is js based nowadays
<thefloweringash>
why such an old codebase? at least spidermonkey 68 should correspond to firefox esr
<thefloweringash>
firefox don't make it easy to find their esr release schedule. is 60 still supported? I must be searching with the wrong terms
<fps>
hmm, so i have an sd-image.nix, i have boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; and nixpkgs.config.allowUnsupportedSystem = true; in my configuration.nix, nixos-rebuild switched the system, and rebooted. i also have { allowUnsupportedSystem = true; } in my ~/.local/nixpkgs/config.nx and now tried nix-build '<nixpkgs/nixos>' -A config.system.build.sdImage -I nixos-config=./sd-image.nix.
<fps>
i still get that error about these two allowUnsupportedSystem settings.
<fps>
i also tried with --argstr system aarch64-linux on the nix-build call. that does more.
<srk>
thefloweringash: it does look more resonable with security.polkit.enable = false
<fps>
i get loads of error messages about something being unable to allocate memory. are those critical?
<clever>
fps: in your sd-image.nix, you must set nixpkgs.system = "aarch64-linux";
<thefloweringash>
fps: the `--argstr system aarch64-linux` is required. You said it does more, what’s the failure?
<thefloweringash>
^ or that
<clever>
ah, for <nixpkgs/nixos>' may also support --argstr system
<fps>
thefloweringash: it hasn't failed yet. i just wondered about the gazillion error messages
<fps>
clever: ah ok. the nix exp for the sd-image imports <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-aarch64.nix>. wouldn't that be a natural place for that?
<clever>
fps: kinda, but you could build that for armv7l instead if you wanted
<fps>
hmm, ok..
<clever>
oh, i notice the deprecated `arm_control=0x200` in the config.txt of sd-image-aarch64.nix
<thefloweringash>
I wouldn’t expect a spam of error messages. If nothing breaks I guess it’s ok. What’s the test of the message? Is it from figuring out what to build or when building a package?
<fps>
i don't have the scrollback for the start of the spam, but this is the tail end of it:
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fps>
btw: thanks for your work! i just reinstalled nixos yesterday and getting up to speed with building an image this quickly is quite amazing :)
<srk>
now my only question is regarding dt overlays is whether to expose compileDTS derivation (.dts -> .dtbo) from pkgs as bennofs[m] suggested (provided I give it a better name)
<srk>
is..
<fps>
*reinstalled after a hiatus of a couple of years after checking nixos out initially
<srk>
fps: \o/ cool
<srk>
fps: what's the reason for binfmt? cross failing for you?
<thefloweringash>
I don't know what to make of those error messages, but they make me a bit suspicious
<thefloweringash>
it looks like it succeeded though, shrug
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<fps>
srk: i'm not sure. i'm just following the wiki on "nixos on arm" ;)
<fps>
i'm trying to build an aarch64 image for the rpi4. and i'm just chugging along semi blindly
<clever>
2020-04-29 13:31:28< clever> 2020-01-22 13:53:12< clever> Tenkawa: `nix-build '<nixpkgs/nixos/release.nix>' -A sd_image_raspberrypi4.aarch64-linux` for an rpi4 i believe
<clever>
fps: from my notes, on how to make an rpi4 image
<fps>
clever: yeah, i also plan on installing some custom software on it, setup a user, etc.. basically ready to plug into a rpi4 as a guitar effects appliance ;)
<clever>
ah, nice
<fps>
clever: my nixos system is x86_64 though in a virtual box. so i follow the wiki's advice on the binfmt wrapper
<fps>
hmm, after a long lasting last step i got a 641 meg image out of the process..
<fps>
i guess i need to bunzip2 it and slap it on an sdcard and see what gives..