Acou_Bass has quit [Quit: byeeeeeeeeeeeeeee]
Acou_Bass has joined #nixos-aarch64
<samueldr> hi tomberek!
<samueldr> I was waiting for you to come back, good editing in the wiki :)
<samueldr> (I'm sorry though, cannot answer your question, only wanted to thank you for getting it documented)
<tomberek> samueldr: I'm still trying to package it up in a Nix-friendly way. but it's a start
<samueldr> oh, btw, tomberek, the kernel will spit out which dtb file it reads from early in dmesg
<samueldr> well, I say that, go to verify and don't see it :/
<tomberek> samueldr: yep, i just updated that part. Asus does an odd renaming of their DTB and I was unsure what to call my own. At the moment I am using a Nix-produced DTB and a mainline u-boot.
<tomberek> samueldr: the dtb read is earlier than dmesg... i have a serial console watching u-boot.
<samueldr> for allwinner chips, u-boot compiles in the dtb name to give to the kernel, so at least for that family it's not hardware-derived
<tomberek> Do you have any experience with Bluetooth? I think i'm dealing with a Bluetooth-over-UART.
<samueldr> almost none, only as a user, though I did wrangle a specific bluetooth chip on a computer
<samueldr> it *may* be relevant to you
<samueldr> (iirc it's also used in som ARM boards)
<samueldr> rtl8723bs
<samueldr> can't tell for sure, but I think it is rtl8723bs on tinker boards
<samueldr> that's what I'm using on a cherry trail tablet
<tomberek> that's exactly the chip i'm dealing with
<tomberek> wifi is running on it too, and that's up and running. no luck with bluetooth yet.
<samueldr> that's what I had to use, don't know for sure it's going to be what you need, and it's still rough around the edges
<samueldr> though I've been using bluetooth headset exclusively with that cherry trail tablet since... well... *checks history* 6 months ago
<tomberek> thanks, i'll try!
<samueldr> so I guess it works :)
<tomberek> I started packaging up that exact repo, thanks for pointing this out.... will that make it to upstream Nixpkgs?
<samueldr> I haven't made any effort yet, but when I started doing that I wasn't confident in what I was doing
<samueldr> since then... I haven't had to touch it :)
<tomberek> i might have to edit start_sh a bit for this board, where did you get the part about "/sys/devices/pci0000:00/8086228A:00/tty/*/uevent"?
<samueldr> I'm not sure I remember
<samueldr> though that's probably an x86ism
<samueldr> the pocket chip uses that chip
<samueldr> so it may help you find a proper value
<samueldr> or a proper path
<samueldr> yeah, intel-ism, probably wrong for so many reasons, but it works
<samueldr> there is a systemd service in their repo, too
<samueldr> I should probably look into that
<samueldr> with udev rules also
<samueldr> (though they hardcode the /dev/ttyS1 path)
<tomberek> samueldr: you are right, PCI is a "PC/x86" thing. I'm not sure which tty this should be on. I see places that mention UART0 (and some patches that change it to UART3). I don't know how to map from that to a specific /dev/ttyS*
<samueldr> that's where my knowledge fails :/
<tomberek> this helped: ls /sys/devices/platform/*.serial/tty -al
<tomberek> That will help me map from address to tty. then the DTS has an alias mapping from uart to address.
orivej has joined #nixos-aarch64
vcunat has joined #nixos-aarch64
duncan^ has joined #nixos-aarch64
duncan^ has quit [Changing host]
duncan^ has joined #nixos-aarch64
duncan^ has quit [Client Quit]
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
<Dezgeg> auto-build non-artisanal aarch64 images from hydra, anyone wanna give a try: https://hydra.nixos.org/build/72335849
<vcunat> this isn't in 18.03 yet, right?
<vcunat> (but is planned, I guess)
<Dezgeg> correct
<vcunat> I suspect we'll need some tweaks to the channel-updating script to have this next to usual ISOs.
<Dezgeg> probably
<vcunat> Ideally we would fix that by 18.03 announcement time, but we'll see.
<Dezgeg> I need to beat the tested jobset into shape on aarch64 first though
<vcunat> Ah, yes, it doesn't evaluate :-)
<vcunat> Then it seems probable that 18.03 announcement will come later for aarch64, as I don't want to delay x86_64-linux significantly longer than necessary.
<Dezgeg> yes
<vcunat> I hope that today we solve the remaining blocker by systemd "downgrade".
efraim has quit [Remote host closed the connection]
efraim has joined #nixos-aarch64
<Dezgeg> I pushed those patches to master now, will cherry-pick soon if they don't break other stuff
<grw> its necessary to rebuild kernel dtbs to enable symbols, takes a long time due to checking out kernel source
<grw> not sure what the interface should look like- if overlay should (attempt) to be applied to every dtb, or user must specify a specific one
<Dezgeg> ah, is there a .config option to build the kernel DTBs with symbols? maybe the first step is to enable that by default on the architectures using DTB
<grw> i dont think so.. i found this patch allowing it to be controlled from make flags, but dont think it has been accepted https://patchwork.kernel.org/patch/9904785/
<Dezgeg> hm
<Dezgeg> I guess in the worst case we cas pass 'DTC="dtc -@"' or something to the kernel build
<grw> true. presumably symbols increase size of dtb too, are we ok with enabling this even if no overlay was specified?
<Dezgeg> it's in the range of kilobytes, I doubt it matters
<samueldr> if it matters to the end-user, they'll probably do their own customized full kernel build anyway to shave more there, I'd think
<grw> i suppose we could strip symbols again after apply overlay if it really mattered
<grw> any ideas for getting extlinux-conf-builder to use new dtbs?
<grw> it contains: # XXX UGLY: maybe the system config should have a top-level "dtbs" entry?
<grw> perhaps this must be addressed first
<Dezgeg> yes
<grw> as in, be a seperate derivation from kernel?
Sonarpulse has joined #nixos-aarch64
<tomberek> I'm noticing large gcc rebuild right now due to a difference in what seems to be rooted in "stdenv-linux-boot" vs "bootstrap-stage3-stdenv-linux" and I'm not sure where that difference came from. Any ideas or ways to track down the source of the difference?
orivej has joined #nixos-aarch64
<tomberek> i think i got it.. slight differences in nixpkgs... still had an impure one
tomberek has quit [Ping timeout: 260 seconds]
<Dezgeg> anyone have a rpi3 at hand? wanna try building raspberrypi-tools from https://github.com/NixOS/nixpkgs/commit/ad05f12753995fdcd396a4ad47f9baec68087cf2 ?
<Dezgeg> well, not building but seeing if running vcgencmd from that works
orivej has quit [Ping timeout: 240 seconds]
<samueldr> I just `dd`ed the installer, I'll come back to you soon
<samueldr> it may be me doing something wrong, but I get "VCHI initialization failed", even sudoing, Dezgeg
<Dezgeg> well it can't find /dev/vchiq
<Dezgeg> maybe you need to modprobe vchiq?
<samueldr> ah, I already did
<Dezgeg> hmm
<samueldr> [ 398.268067] vchiq: module is from the staging directory, the quality is unknown, you have been warned.
<samueldr> the *only* message when I modproped it
<samueldr> btw, I'm using the mainline kernel, no raspberrypi specific kernel
<samueldr> > boot.kernelPackages = pkgs.linuxPackages_latest
<Dezgeg> let's see
<samueldr> I am your puppet, I'm using 18.03 as the nixos channel if it matters
<samueldr> (I nix-built from a checkout of the branch you linked)
<Dezgeg> there is a kernel commit dated Mar 9 which adds it to the device tree, so it might not be in any release yet
<Dezgeg> yes, it's not coming in until 4.17 I think
<Dezgeg> that explains it, thanks for testing
vcunat has quit [Quit: Leaving.]
<samueldr> n/p, if there's anything rpi3-specific, ask, I'll try it
<samueldr> I'm not using it *right now*
<samueldr> (not until I usb boot it, SDs are sloooow)
<Dezgeg> yes the SD bus on it doesn't support the fastest modes
<bkchr[m]> samueldr: do you have the rpi camera working? I'm currently trying to get it working
<samueldr> I don't have an rpi camera
<bkchr[m]> I'm also having problems when I activate `start_x=1`, I get `MemTotal: 93592 kB`
<bkchr[m]> `gpu_mem=128`
<bkchr[m]> really weird