<Dezgeg> is the kwboot binary somehow generic to multiple boards specific to one single defconfig at a time?
<Dezgeg> I guess the first one, since debian has that in their u-boot-tools package
<flokli> Dezgeg: should be xmodem protocol
<flokli> the protocol, that is. Supporting this seems to be kind of Marvel-specific (BootROM firmware image format)
<Dezgeg> what I meant is that if you have boards foo and bar supporting this kwb format, do you need to compile a different kwboot binary for each board
<flokli> I'd highly doubt it
<Dezgeg> yeah, I assume the answer is no as debian has it just one /usr/bin/kwboot in their u-boot-tools
<Dezgeg> so we can imitate what they do (i.e. put it in ubootTools)
<flokli> yes. but this could mean we have to patch their makefiles
<flokli> tools/Makefile
<flokli> 184:hostprogs-$(CONFIG_KIRKWOOD) += kwboot
<flokli> 185:hostprogs-$(CONFIG_ARCH_MVEBU) += kwboot
<Dezgeg> well you could just set CONFIG_ARCH_MVEBU=y in makeFlags for the tools I think (and document why it's needed)
<flokli> maybe we should borrow from debian
<flokli> we currently only have (dump,mkenv,mk)image
<flokli> right. hmm
<flokli> so should we apply their patch? try to find out why it's not upstream like this?
<Dezgeg> does `makeFlags = [ "CONFIG_ARCH_MVEBU=y" ]` do it for the tools?
<Dezgeg> a bit dirty :)
<flokli> so I'll make makeFlags overridable in buildUBoot, and override it from ubootTools
<Dezgeg> oh hmm, there's this 'make tools-all' make target as well
<Dezgeg> does that do it?
<flokli> will check
<flokli> seems to work.
<Dezgeg> ok, nifty
<flokli> will provide a patch
<Dezgeg> sorry, I meant: does changing buildFlags = "tools-all NO_SDL=1"; build kwboot without this CONFIG_KIRKWOOD=y ?
<flokli> seems like i have to do something different before:
<flokli> In file included from include/version.h:11:0,
<flokli> from tools/env/fw_env_main.c:37:
<flokli> include/timestamp.h:11:47: fatal error: generated/timestamp_autogenerated.h: No such file or directory
<flokli> #include "generated/timestamp_autogenerated.h"
<flokli> ^
<Dezgeg> ah, darn. sounds like upstream has broken it in some way
<Dezgeg> let's go with this CONFIG_KIRKWOOD=y then
<flokli> so the PR as it is
<Dezgeg> yes
<flokli> can you try building ubootTools on something arm-ish?
<Dezgeg> yes, I'll try
<flokli> thanks :-)
<Dezgeg> it does build there as well
<flokli> great. the ubootClearfog too?
<Dezgeg> where was that?
<flokli> weird it shows as nixos/nixpkgs… it's still in my repo only…
<samueldr> github de-duplication gone wrong?
<Dezgeg> yeah, that makeis it quite hard to fetch
<Dezgeg> *makes
<> changed the topic of #nixos-aarch64 to: Topic for #nixos-aarch64 is "Get access to the NixOS Community aarch64 build box: https://github.com/nix-community/aarch64-build-box ... todo: https://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-jobs"
<> changed the topic of #nixos-aarch64 to: Topic set by gchristensen!~gchristen@unaffiliated/grahamc on 2017-12-14 00:56:57 UTC
<flokli> sorry
<Dezgeg> tools/kwbimage.c:21:24: fatal error: openssl/bn.h: No such file or directory
<flokli> right, had to add openssl and bc to my build inputs
<flokli> will come up with something for this
<flokli> bc is already there. should we just add openssl for all buildUboot's?
<Dezgeg> I guess for simplicity they could be just always included, there's already dtc which isn't quite always needed after all
<Dezgeg> yeah
<flokli> ok.
<flokli> btw, is it possible somehow to use nix-build with cross-compiling?
<flokli> so i can test the expression here on amd64?
<Dezgeg> at some point it used to work, but I'm not sure if the current cross rework has changed things enough so the u-boot cross compilation has bitrotted
<flokli> how would I do this, anyway? is there a argument for nix-build?
<gchristensen> flokli: is the community box not sufficient in some way?
<Dezgeg> I can't remember, it's so long since I tried
<flokli> gchristensen: the community box is aarch64. My clearfog is armv7 unfortunately :-/
<gchristensen> aahh
<gchristensen> I hope to have armv7 hardware one day too
<gchristensen> I'm sorry that is not today
<flokli> yeah, i was really confident this was aarch64
<flokli> but apparently it's not
<flokli> the clearfog only has 2gb of ram, so it can't really serve as a buildbox
<flokli> Dezgeg: what do you use for building the small unstable package set?
<flokli> qemu?
<Dezgeg> jetson tk-1
<flokli> hui, just 2gb ram too
<Dezgeg> yes, swap is needed
<samueldr> what makes build times slow in most single board computers are the lower-powered CPUs and, especially, the I/O access... SD cards are bad
<gchristensen> fancy, Dezgeg
<samueldr> and yeah, swap on bad I/O = bad time
<Dezgeg> but it's definitely one of the higher-end ARMv7:s that one can find, I think
<flokli> yes, pretty nice - did you toy around with the nvidia parts on it?
<flokli> btw, PR for ubootClearfog (please test, I can't): https://github.com/NixOS/nixpkgs/pull/32996
<Dezgeg> yes, I tried nouveau with it once
<samueldr> (I can build armv7 if second opinion is needed)
<Dezgeg> it does build ok (the nativeBuildInputs issue I commented on doesn't affect non-cross builds)
<flokli> Dezgeg: why should openssl be nativeBuildInput?
<flokli> I can only see it being called in test/py/tests/test_vboot.py
<flokli> apart from that, it's just library usage
<Dezgeg> kwbimage is a host tool
<flokli> ah, and kwbimage still gets built for the host arch
<Dezgeg> if you think about it, there's no way you could link openssl to the bootloader itself, given that linux systemcalls won't be available in the bare metal environment
<flokli> you're completely right :-)
<flokli> urgh, I really need to wrap my head around cross-builds in nixos and try them more often
<Dezgeg> yes, it's quite difficult to get them correct
<flokli> Updated
<Dezgeg> e.g. it's valid for say, flex to be a nativeBuildInput, a buildInput, or both a nativeBuildInput and a buildInput
<flokli> they are completely separate? I thought nativeBuildInputs are also appended to buildInputs…
<Dezgeg> you might need flex, the binary that runs on the build machine, and libfl.a, the library that you link to the cross-compiled code
<Dezgeg> anyway, it looks good now (and builds)
<flokli> great :-)
<flokli> time for bed :-D
* andi- has almost succeeded building a java version that can build a java version that can build openjdk... m(
<samueldr> you're almost there
<andi-> just a few more layers of recursion
<andi-> on the bright side: we might actually be able to bootstrap all supported (as in openjdk supported) architectures then...
<andi-> all those headless builds that depend on a bazillion X-libs...
<flokli> andi-: headless builds are fun! just take a look at virtualboxheadless, which is currently broken upstream, due to some macro foobar in x11 clipboard handling ;-)
orivej has quit [(Ping timeout: 252 seconds)]
<andi-> icedtea seems to be the way to go if you have a proper (version-1) sdk around.. not lieking how they insist on downloading/providing their own sources tho..
orivej has joined joined #nixos-aarch64
disasm has joined joined #nixos-aarch64
<samueldr> Dezgeg: it seems your aarch64 installer image currently has the non-booting 4.14 kernel, care to host either an older version that booted or a (manual) build using 4.13?
<samueldr> unless the update with fix to 4.14 is like a day away, or that we hand-pick the patch
<Dezgeg> let's see if I have some old ones lying around
<Dezgeg> ok now there's something that has linux-4.11.3
<samueldr> if you didn't, I made a 4.13 build, but I'm sure you somehow prefer serving those you personally built
<disasm> well, got nixos on my raspberrypi 3 with samueldr help :) (I had the kernel 4.14 error)
<disasm> great meeting other people with the name samuel, good strong name :)
<Dezgeg> yeah I have these ones called sd-image-aarch64-linux-old.img sd-image-aarch64-linux-old2.img sd-image-aarch64-linux-old-replaced-2017-20-23.img
<samueldr> then I presume you're a samuel too?
<disasm> I'll probably have some more questions later when I start hooking sensors and stuff up to the gpio pins :)
<disasm> I am :)
<samueldr> o/
<samueldr> remember though that it's an upstream non-specific kernel build
<samueldr> there ARE differences with some stuff, like how the vc4 is used with kms
<samueldr> when compared to the usual "raspberry pi" kernel builds
<disasm> that would only be related to using the gpu, right?
<samueldr> I said "like" since I know vc4 has differences
<samueldr> I don't know about other stuff
<disasm> primarily I'll be writing python apps that interface with sensors, motors, etc...
<disasm> and the plan with nix is mainly to use nixops to deploy that code/service to the pi (via ethernet plug, I know wifi is not in a good state)
<samueldr> once the firmwares are there, it seemed pretty good
<disasm> is there a watchdog that automatically reboots after a while? Mines plugged in doing nothing and just rebooted
<samueldr> shouldn't be
<samueldr> though, with the raspberry pi 3, it is quite important to have a proper power supply
<samueldr> and proper cable