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