<srk>
reminds me of a friend who was running Inferno on his nexus for few weeks :D
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
<prusnak>
thefloweringash: nice! will you send a PR to the repo soon? I have lg-bullhead (Nexus 5X) here, done some work there, but I assume lots of stuff from your effort can be reused
prusnak has quit [Changing host]
prusnak has joined #nixos-aarch64
prusnak has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has left #nixos-aarch64 [#nixos-aarch64]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Asmadeus has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
orivej has joined #nixos-aarch64
<thefloweringash>
prusnak: I need to iron out a few more things. I'm still having trouble with the display. if you want to see my current state, it's up on github: https://github.com/thefloweringash/mobile-nixos/
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
julm has joined #nixos-aarch64
zupo has joined #nixos-aarch64
samrose_ has joined #nixos-aarch64
samrose has quit [Ping timeout: 256 seconds]
dongcarl has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
mla has quit [Ping timeout: 258 seconds]
v0|d has quit [Remote host closed the connection]
nschoe has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
womfoo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<womfoo>
hi guys! i recently got an e-ink HAT for my rpi3b+. has anyone gotten to make this work on nixos? i'm still unfamiliar with SPI/GPIO/etc. on rasbian, its just a matter of adding dtparam=spi=on in config.txt
<clever>
womfoo: if you add that dtparam to config.txt, and uboot isnt breaking things, you should then get a /dev/spi-something in linux
<womfoo>
yup adding the dtparam still manages to boot. nothing new in /dev/spi*
<clever>
you may need to modprobe something...
<womfoo>
tried modprobing it but nothing shows up
<clever>
`modprobe spidev` ?
<lopsided98>
dtparam doesn't work when using U-Boot
<womfoo>
yes tried that and spi_bcm2835
<clever>
ah, so the firmware is generating a new and updated DTB, but the uboot throws that out and uses its own DTB
<clever>
which breaks everything
<lopsided98>
there is the hardware.deviceTree.overlays option, which works if you have a DT overlay that enables SPI
<womfoo>
oh no wonder i dont see the gradient at startup
<clever>
womfoo: the rainbox is done by start.elf before it launches uboot
<lopsided98>
yeah, that PR fixes a lot of the issues with that option. In particular it is currently not possible to apply overlays to the standard NixOS mainline kernel
<bennofs[m]>
Saw you were talking about DT overlays before. The dtbs in nixos mainline are not compiled with symbols, so the usual overlay stuff is a bit tricky to use
<clever>
/nix/store/fah0fy53gcnm1697xn75hvj8h857lbh2-stdenv-linux.drv is indeed a 32bit derivation
<clever>
i think that will work
<thefloweringash>
ghc on armv7 would be nice to have. There’s no upstream binary but we could build our own cross bootstrap ghc
<clever>
thefloweringash: last time i tried to run ghc natively on arm, it segfaulted if you used more then -j1
<thefloweringash>
Did that pull request to make device tree overlays in nix have symbols by default and also support rpi overlays get merged?
<thefloweringash>
clever: where did you get the ghc from?
<clever>
srk: i think thats the pubkey for my hydra
<srk>
thanks!
<srk>
noted.
<nschoe>
srk: hi, was away. I did manage to build HPi for aarch64. I packaged bcm2835 if needed, too. I can provide the gist.
<clever>
nschoe: does brick build for aarch64?
<nschoe>
clever: did not try it yet.
<nschoe>
clever: give me a sec I'll try right now
<nschoe>
clever: it's building deps now.
<nschoe>
clever: no it fails to build because of depency microlens, because if I understood correctly what alp told me: forcross-compiling we're building a ghc stage1, and stag1 is not able to compile template haskell.
<clever>
nschoe: ah, what about vector?
<nschoe>
clever: building now
<srk>
I can try building native one with stage1 if it works and if I figure out how
alp has joined #nixos-aarch64
<nschoe>
srk: I asked alp to join an quickly described your problem, here's what he's told me: "
<nschoe>
Now I believe alp joined, so if you have more questions he might be able to answer if he's around:-)
<nschoe>
one needs to use -fexternal-interpreter, along with an instance of the "iserv" program, to run TH with cross-compilers"
<alp>
stage 1 ghcs (e.g cross-compilers) _can_ run TH but this requires -fexternal-interpreter along with a local/remote iserv process which can interpret TH for the stage 1 GHC and communicates with it
<nschoe>
clever: (it's still building deps for vector0
<alp>
angerman knows this inside out :-)
<nschoe>
s/o/)
<srk>
oh cool :)
<srk>
I was talking to him today, good to know :D
<srk>
alp++
<clever>
yeah, angerman has written haskell.nix, which deals with the cross-compile and TH stuff fully
<clever>
and cabal conditionals
<clever>
the cabal file can contain if statements, so you only depend on unix on unix-y platforms, and Win32 on windows
<clever>
haskell.nix translates that to nix if statements, so you dont wind up building Win32 on linux
<srk>
awesome, haskell everywhere \o/
<clever>
and it also adds a bunch of new features, like building each component (the library, executables, and tests) in seperate derivations
<clever>
the windows TH currently uses wine and iserv-proxy
<clever>
originally, iserv-proxy was meant to run directly on the target device (like an iphone), and handled running TH on the target
<clever>
qemu-user-arm could also be used, to handle arm TH
<clever>
and if your not running child procs, qemu-user is as simple as wine, no need for root
<srk>
I need to take a good look at haskell.nix :)
<nschoe>
clever: yup, 'vector' just finished building for aarch64, no build error.
<clever>
nschoe: for me, vector depends on primitive
<clever>
nschoe: and primitive fails due to type errors, mixing up 32bit and 64bit stuff
<clever>
nschoe: i think whats happening, is that primitive is using the host sizeof(int) and then things fall apart when the target has a different pointer size
<clever>
nschoe: since you did x86_64 -> aarch64, things lined up, and vector/primitive just work
<clever>
but i'm targetting armv7l, so i need to use an i686-linux -> armv7l cross-compiler
<nschoe>
clever: uh, good catch
<nschoe>
well maybe primitive can be fixed / patched?
<nschoe>
Is it _supposed_ to take the host's sizeof?
<clever>
nschoe: i think its supposed to use target sizeof
<clever>
but its just grabbing a .h file, and using host gcc to build it
<nschoe>
:/
<clever>
haskell.nix might already fix this
<clever>
or maybe not, we are cross-compiling to win64, so it could have slipped under the radar
<nschoe>
Hum, I'm trying to cross-compile hsI2C, it fails because it requires base<4.11. So I have an override of aarch64-multiplatform.haskellPackages with "base = super.callHackage "base" "4.10.1.0" {};" but it fails with "error: anonymous function at /nix/store/ccywvfqq5m3ji9lp7rik74wyb45k2drg-cabal2nix-base-4.10.1.0/default.nix:1:1 called without required argument 'invalid-cabal-flag-settings', at /home/nschoe/nixpkgs/pkgs/
<clever>
nschoe: yeah, and git blame says its been there since day 1
<clever>
the constraint likely has no purpose, and shouldnt really be there
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nschoe>
clever: I'm about to copy teh closure on the rPi and try to make my test program work, seewhat this does.
<clever>
performing step ‘/nix/store/cabwyx7rc82bwsqg2scl6g1xv3x1xx7h-glibc-2.27-armv7l-unknown-linux-gnueabihf.drv’ 1 times on ‘builder@192.168.2.15’ (needed by build 100738 and 1 others)
<nschoe>
clever: perfect! hsI2C test program works on the rPi, and it doesn't "mess the i2c bus" like HPi does when using the clode() and end() function.
<nschoe>
I guess I'll write my driver with it hsI2c then.
zupo has joined #nixos-aarch64
<clever>
performing step ‘/nix/store/avp7kvlrrlgxxgn12j277zmx7pn8wa1w-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-6.5.0.drv’ 1 times on ‘builder@system76.localnet’ (needed by build 100738 and 1 others)
<clever>
performing step ‘/nix/store/qnygsjp79ja0x8i7n2czawapyikmak3m-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-9.2.0.drv’ 1 times on ‘builder@192.168.2.15’ (needed by build 100738 and 1 others)
<clever>
ok, weird, its now cross-compiling 2 gcc's at once
<clever>
srk: i think the problem is that sIZEOF_INT is wrong
<srk>
hmm, patching primitive with hardcoded val work(around)?
<srk>
primitive patch heh
<clever>
/tmp/nix-build-llvm-6.0.1.drv-0/llvm/build/bin/llvm-tblgen: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /nix/store/xyffzrwpk2wrawz6mm5qzpqy2k6l5v18-glibc-2.27-armv7l-unknown-linux-gnueabihf/lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, with debug_info, not stripped
<clever>
it seems that it build an arm binary for the llvm
<clever>
i think its an i686-linux -> armv7l-linux cross llvm
<clever>
and it broke
alp has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<alp>
perhaps you can apply a patch on the fly, to use the right bit-widths where appropriate? might be painful, but better than not being able to use primitive =)
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]