<mla>
getting error: value is a path while a set was expected, at /home/m/nixpkgs/pkgs/top-level/default.nix:63
<mla>
so i know i need to specify config -- i suppose but how do i do that
<mla>
just following along w/ instructions on pinephone on mobile-nixos; seems like im missing something
<mla>
shouldnt nix-build --argstr device pine64-pinephone-braveheart -A build.disk-image just work
<mla>
either that or docs need to be updated?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<samueldr>
mla: before doing anything else, is this against a recent nixos-unstable?
orivej has joined #nixos-aarch64
<mla>
im running nixos on host, and just let it do its thing (running stable 20.03 channel); cloning nixpkgs atm and will run with NIXPATH against that and latest good rev to see if i get same result
<samueldr>
right now, to reduce the maintenance burden it's only targeting the latest nixos unstable commits ±1 month
<mla>
ran command from mobile-nixos/devices/pine64-pinephone-braveheart
<mla>
feel like im missing something obvious
<mla>
do i need to make a config and pass it somehow? im just trying to follow instructions for pinephone doc
<samueldr>
ah, run it from the root of the mobile-nixos repo
orivej has quit [Ping timeout: 246 seconds]
<samueldr>
the device/*/ folders are configuration files for the devices
<samueldr>
as in modules system like what's in <nixpkgs/nixos> or your configuration.nix file
<mla>
oh silly me
orivej has joined #nixos-aarch64
<samueldr>
note that if you're building that, it'll look like it is hanging at the Mobile NixOS splash, but in fact it's successfully booting a system that can do absolutely nothing
<mla>
now im getting value is a path while a set was expected http://ix.io/2t14
<mla>
cant wait till i get it actually building and booting
<mla>
this error looks a bit more managable
orivej has quit [Ping timeout: 260 seconds]
<samueldr>
not sure it's related, but how is your NIX_PATH set?
<samueldr>
because all I see here confuses me
<samueldr>
nix will pick the *first* element it finds in NIX_PATH
<samueldr>
(and -I has more precedence than the environment variable)
<mla>
export NIX_PATH=nixpkgs=/home/m/nixpkgs
<samueldr>
then I'm thoroughly confused
<samueldr>
nix-build '<nixpkgs>' -A hello # works as expected?
<samueldr>
I don't know what your issue is though :)
<samueldr>
to me, this looks like most of the solution is that they load a specific .dtb (to disable bluetooth)
<apache8080>
Oh oops, When I build sd-image-aarch64 I get `card did not respond to voltage select` and `device 0: unknown device`
<samueldr>
hm
<apache8080>
it was the issue I posted about here on friday
<samueldr>
right
<samueldr>
I don't see anything about voltage select here
<apache8080>
I tried the latest nixpkgs and then also just tried the 20.03 and running in to the same issue
<apache8080>
yeah but the device 0: unknown device happens here so thats why I was thinking it may be related
<samueldr>
>> USB device 0: unknown device
<samueldr>
if yours has "USB" too, it's nothing to worry about
<apache8080>
no it doesnt have USB
<apache8080>
I guess it isn't related then
<samueldr>
in *their* issue here it's because it continues after failing to boot from SD and it tries to boot to USB AFAIUI
<apache8080>
ah ok
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 245 seconds]
rajivr has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<colemickens>
samueldr: do you have experience building kernels from the android-linux-stable project? They have one for bluecross, but I can't quite figure out their build system to figure out what I need to do to compose the defconfig file.
<apache8080>
samueldr when I use this command: `nix-build '<nixpkgs/nixos>' -A config.system.build.sdImage -I nixos-config=./sd-image-aarch64.nix` it creates this `nixos-sd-image-20.03pre-git-aarch64-linux.img` whats weird is this used to create a .bz2.img and that image worked fine
apache8080 has quit [Ping timeout: 245 seconds]
<samueldr>
colemickens: kind of, see walleye
<samueldr>
colemickens: what's this about composing a defconfig though?
<samueldr>
you could copy this as device/google-.../kernel/config.aarch64 and use `bin/normalize-config google-...` to get a full config
<samueldr>
or `bin/menuconfig` for menuconfig
<colemickens>
b1c1 / bluecross is what I want
<colemickens>
I tried using the b1c1_defconfig directly and it didn't work
<samueldr>
define "didn't work"
<colemickens>
it seemed like maybe it stitches the b1c1_defconfig together with the sdm... one? They have some build/build.sh script that is referenced frm the very top build scripts that... isn't in the repo.
<colemickens>
./build_bluecross.sh
<samueldr>
AFAICT b1c1 is a superset of what the others set, with a really cursory look
<samueldr>
it might, tbf I didn't use anything from there
<colemickens>
oh
<colemickens>
I didn't do the "copy this as... and normalize" yet
<samueldr>
at that point in time I was relying on extracting a config from a known working system
<samueldr>
e.g. TWRP or a custom ROM
<colemickens>
at time of doing walleye, you mean?
<samueldr>
yes, and most other devices :)
<colemickens>
ooh I see
<colemickens>
you mean literally by hand, lol
<colemickens>
I was getting ready to write nix for it
<samueldr>
if you use `binwalk -e` on a kernel you ungzipped, from an unpackbootimg'd system, you might have a linux .config "ikconfig" file
<colemickens>
okay, I'll see if I can figure this out
<samueldr>
as is used to provide /proc/config.gz
<samueldr>
well, I don't *make* the file, I start from a working OS
<samueldr>
if you boot TWRP, you probably can just cat /proc/config.gz
* colemickens
acks
<colemickens>
maybe kernel-builder could eventually do this copy/normalize dance though
<samueldr>
that binwalk method is for when you don't want to, or can't boot it
<colemickens>
or is the hope of using upstream defconfigs too optimistic?
<samueldr>
most OEMs end up shipping the IKCONFIG in the kernel
<samueldr>
even if /proc/config.gz is not there
<samueldr>
google doesn't
<samueldr>
mainline kernel defconfig: probably won't work
<samueldr>
android-linux-stable is basically the downstream kernel + updates to LTS
<colemickens>
I think I can boot twrp fairly easily now that I put the a9 bootloader on it. I might just do that since I dont 'know know how to run the nromalize thing you mentioned
* colemickens
nods
<samueldr>
basically `bin/kernel-normalize-config $DEVICE_NAME` it does the hard work for you
<samueldr>
but it needs to be under `$device_dir/kernel/config.aarch64`
<samueldr>
I should add a flag to the tool to allow passing a specific file
orivej has quit [Quit: No Ping reply in 180 seconds.]
<colemickens>
did you switch to the normalize method? your kernel config is from such a recent kerel
<samueldr>
hm? normalize is just about passing the config through the kernel's menuconfig tool
<colemickens>
yea, I'm going off the version stamped in the config
<colemickens>
mine is from a much earlier 4.9 build
<colemickens>
I was just curious why yours was from such a newer build
<samueldr>
look, 4._4_.
<colemickens>
oh I can't read, got it
<samueldr>
still, when a kernel gets updated, the normalize script should always be run so new options are present in the file
<samueldr>
(or removed options removed)
<samueldr>
though less likely to be useful in LTS kernels :)
<samueldr>
I'm off for the night, hopefully these clues will help you
<colemickens>
thanks samueldr , cheers!
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
<colemickens>
sometimes stuff like this makes me frustrated that everyone doesn't just use nix, would be so much easier than all this guessing and relying on things put in special places
ashkitten has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
<clever>
colemickens: yep, i'm in their discord channel
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 264 seconds]
<colemickens>
well, time to join that. this sounds really lovely
<clever>
colemickens: its on the developer ecosystem discord
<clever>
which works-on-arm have moved to
<colemickens>
already found and joined, thanks!
cole-h has quit [Ping timeout: 260 seconds]
<colemickens>
ooh I wonder if you can tftp boot the uefi payload
<clever>
pretty sure you can
<colemickens>
It's kind of surprising to me how long its been out for the 3gb/dma limit to not have been fixed (and seemingly not have a super clear plan from the sounds of that issue)
<clever>
colemickens: some of the peripherals have a 1gig limit, that was known of from the start
t184256 has joined #nixos-aarch64
cornu has quit [Quit: Idle for 30+ days]
kai_w has quit [Quit: Idle for 30+ days]
leonardp has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
julm has joined #nixos-aarch64
alp has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<angerman>
wavirc22: I think I've managed to get rid of aml_encrypt_g12a.
t184256 has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
alp has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
t184256 has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<hsngrmpf[m]>
I finally managed to build a nix binary tarball for armv7l. I published instructions + binary here if anyone needs it: https://github.com/DavHau/nix-on-armv7l
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
alp has quit [Ping timeout: 264 seconds]
<samueldr>
heh, using a docker image of a new debian to get a nix to build the nix tarball
<samueldr>
good thinking
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
pachumicchu has joined #nixos-aarch64
zupo has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
<samueldr>
hmmm, I'm curious if that soongnix thing will be helpful in making a halium or halium-like container for the proprietary bits
<danielrf[m]>
I've currently been able to build `adb` and `fastboot` from source using the clang toolchain from nixpkgs
lordcirth__ has joined #nixos-aarch64
lordcirth_ has quit [Ping timeout: 246 seconds]
<samueldr>
that's what I understood from the commits
<samueldr>
that's great work danielrf[m]++
<{^_^}>
danielrf[m]'s karma got increased to 4
<danielrf[m]>
thanks. I was pretty happy to get it working!
noonien has joined #nixos-aarch64
<samueldr>
hopefully this also brings in incremental builds
<samueldr>
even if in reality many options end up making shared incremental builds between components impossible
<samueldr>
at the very least if you're e.g. updating only the kernel repo to not have to rebuild the whole thing
<danielrf[m]>
I'm not super confident it will be the right approach for robotnix in the near future.
<danielrf[m]>
It's very much a "bottom-up" approach to incrementalism
<danielrf[m]>
which is nice, but we'd need to write a ton of soong modules in nix--and then there's the maintenance burden with new releases of android
<samueldr>
oh, I see
<danielrf[m]>
I think having the "go soong" controlling the android build is still the right approach for now
<danielrf[m]>
and potentially patching it to save some components in "sub-derivations" of the whole android build--(using recursive nix or something)
<danielrf[m]>
e.g. first build a really generic AOSP build for the particular arch--save a bunch of the output, and then building the user's actual robotnix configuration (hopefully reusing some built products)
<danielrf[m]>
I still think soongnix is nice to have--but just don't think it would be ready to replace "actual soong" for the whole build anytime soon.
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]