<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
<>
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?
<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