Robertof__ has joined #nixos-aarch64
Robertof_ has quit [Ping timeout: 272 seconds]
webster23 has quit [Ping timeout: 252 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 240 seconds]
Robertof__ has quit [Quit: Leaving]
julm has quit [Remote host closed the connection]
julm has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.8]
h0m1 has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 260 seconds]
stego has joined #nixos-aarch64
stego has quit [Quit: leaving]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
alp has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zarel has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
alp has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
webster23 has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22_ has joined #nixos-aarch64
s1ng0c has joined #nixos-aarch64
<s1ng0c> hi there
<s1ng0c> noob question, I try to build NixOS for PinePhone, build fine, device boot to login screen
<s1ng0c> but I couldn't find right login username/password
<s1ng0c> tried nixos/nixos but didn't work
<s1ng0c> anyone can help?
wavirc22_ has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
dao has joined #nixos-aarch64
s1ng0c_ has joined #nixos-aarch64
<fps> does not cleanly apply to
<fps> boot.kernelPackages = pkgs.linuxPackages_rpi4;
<fps> which is annoying
<fps> and i don't know how to override the tag and modDirVersion of the linuxPackages_rpi packag
<fps> so i could use a kernel version closer to one for which a rt-preempt patch is available
orivej has joined #nixos-aarch64
<srk> fps: you need to override linux package and then used that with linuxPackagesFor, something like https://github.com/novena-next/nixos-novena/blob/master/overlay.nix#L10
<srk> fps: that creates linux_nvn which is then used to create linuxPackages_nvn which you can set to your boot.kernelPackages
<fps> srk: hmm, ok. i will give it a shot :)
<fps> thanks
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
dao has quit [Quit: WeeChat 2.7.1]
s1ng0c has quit [Remote host closed the connection]
s1ng0c_ is now known as s1ng0c
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fps> s1ng0c: what configuration.nix did you use?
<fps> s1ng0c: you can either enable passwordless login or maybe some initial empty passwords
<fps> s1ng0c: btw: i'm thinking about getting a pinephone, too at some point in time ;)
s1ng0c37 has joined #nixos-aarch64
<s1ng0c> I dont use any
<s1ng0c> Build default config
<s1ng0c> Im trying to figure out howto, seem there is local.nix where i can specify user/pass
<s1ng0c> I am trying now, build takes time
<s1ng0c> Yeah, get one, so much fun
<fps> s1ng0c: let me phrase it differently: how and where did you aquire the image for the pinephone?
s1ng0c37 has quit [Remote host closed the connection]
<fps> srk: that repository also has: https://github.com/novena-next/nixos-novena/blob/master/kernel/default.nix. why is it split into that package and the overlay?
<fps> i'm still very confused..
<fps> this https://nixos.wiki/wiki/Linux_kernel is using yet another approach: just specifying the kernel completely in the configuration. hmm
<srk> fps: because it needs custom kernel
<srk> fps: you can just override pkgs.linux or pkgs.linux_latest for example
<srk> fps: what's on the wiki also calls pkgs.recurseIntoAttrs (pkgs.linuxPackagesFor linux_sgx);
<srk> it doesn't have to be part of the overlay, that's just convenience
<fps> hmm, so pkgs.linuxPackagesFor is a function that takes an attribute set as argument and returns a derivation?
<fps> still trying to get my head around the nix language :)
<srk> pretty much, I think it just takes a kernel derivation and wraps it so it can build other modules for it
<srk> and yeah, the output is another derivation
<srk> you can always check the source if not sure :)
<fps> true
<fps> so this: linux_nvn = callPackage ./kernel {
<fps> i'll readup on callPackage first..
<srk> callPackage is used to import and fill in function arguments of the ./kernel/default.nix in this case, you can see it uses e.g. fetchFromGitHub which is provided by callPackage from pkgs scope
<srk> so you don't have to refer to it directly via pkgs.fetchFrom..
<fps> it's probably easier to just create a new branch in my nixpkgs checkout and just change the damn versions in the linux-rpi.nix file ;)
<fps> and then copy that whole damn thing over to the sdcard, too, so that it;s available there, too :)
<srk> hehe, possibly - you can try something linke linux_rpiMy = linux_rpiX.override ( .. )
<srk> override { .. }
<fps> i tried the .override way, but iirc the override attribute was missing on that kernel package
<fps> boot.kernelPackages = pkgs.linuxPackages_rpi4.override { };
<fps> error: attribute 'override' missing, at /home/fps/src/projects/linux-audio/ogfx/ogfx-nixos-rpi4/configuration.nix:23:25
<srk> yes because that's wrapped
<srk> > pkgs.linux.override {}
<{^_^}> "<derivation /nix/store/1gdasfd8zd6n88jk4afnf7fhimqr40ns-linux-5.4.39.drv>"
<srk> (wrapped in linuxPackages, that's the next step you need to do after overriding pkgs.linux_xyz)
<srk> in my overlay that's done after linux_nvn - linuxPackages_nvn = linuxPackagesFor final.linux_nvn;
<fps> > pkgs.linux_rpi4.override {}
<{^_^}> "<derivation /nix/store/4v9ps87hm4d6247c6r9cl503fvcv4b86-linux-4.19.75-1.20190925.drv>"
<fps> ok, i think i understand a little more now. it really helps to look into all_packages.nix sometimes
wavirc22 has quit [Ping timeout: 264 seconds]
<fps> ah drats
<fps> boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.callPackage pkgs.linux_rpi4.override { tag = "1.20200212"; modDirVersion = "4.19.120rt52"; });
<fps> the tag gets lost on its way to linux-rpi.nix :)
<srk> nice! :)
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<fps> no, not nice. it still tries to build 4.19.75 ;)
zupo has joined #nixos-aarch64
<srk> ah, overriding version?
<srk> instead of modDirVersion as that is derived from version iirc
<fps> will try.. hmm
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
<fps> from linux-rpi.nix: version = "${modDirVersion}-${tag}";
<fps> the problem is that modDirVersion and tag are bound in a let expression i thin
<fps> think
<fps> maybe i can also directly try to overrride the src attribute. hmm
<hexa-> any reason rpi.gpio is not available in nixpkgs?
<srk> because it's not needed, you can use libgpiod instead if you're not on pi4 with linux_pi4 specific kernel
<srk> or /sys/class/gpio but that's disabled in recent kernels (deprecated)
<hexa-> i'm on an rpi4
<hexa-> rip me
<srk> :(
<srk> /sys/class/gpio should be available
<hexa-> it is
<srk> :D but how to control it, right?
<hexa-> that I can find out
<srk> I'm not using it anymore and migrated to libgpiod but it is useful in some cases :)
<hexa-> ok, thx
<srk> a case of I don't have a compiler but "just" want to turn on this pin badly :D
<hexa-> hm, I want to control a ultrasound sensor :<
<srk> which one?
orivej has quit [Ping timeout: 260 seconds]
<hexa-> jsn-sr04t 2.0
<hexa-> the plan is to measure the water-level of cistern
<srk> how do you read data out of it? looks like it has serial as well
<hexa-> have not yet looked into that
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<srk> do you have /dev/gpiochip?
<hexa-> 0, 1 and 2
<srk> ah cool, you can use libgpiod as well
<hexa-> anyway I'm testing this on an rpi3 first, so I'd go with the portable solution
<srk> .. I have a pi4 booted next to me but no access because I forgot to configure autologin / ssh :D
<hexa-> :D
<srk> so instead of rpi.gpio you can use libgpiod for your app
<srk> best would be to write a kernel driver
<hexa-> yeah, no :D
<srk> :D
<hexa-> that does not sound like me
<clever> hexa-: do you know haskell?
<hexa-> i don't
<srk> clever: I do a bit! :D
<clever> ah, then my recent work in haskell support for gpio may not be of use
<clever> srk: let me grab a link...
<clever> srk: have a look at this beast
<srk> 404ed
<clever> the mouse sometimes cuts things off on copy
<srk> oh mad!
<clever> srk: what is line 182 doing? :D
<srk> /dev/gpiomem??
<clever> srk: thats a window into a sub-region of MMIO for gpio, owned by the gpio group
<clever> srk: so you can poke raw mmio without root
<srk> nice
<clever> crw-rw---- 1 root gpio 247, 0 May 5 23:14 /dev/gpiomem
<srk> love it, will play with that
<srk> how's that created btW?
<srk> /dev/gpiomem I mean
<srk> delete mode 100644 HPi.nix
<srk> :D
<clever> srk: HPi.nix lacks the ability to even read alt modes, which is half the point of what i had begun
<clever> drivers/char/broadcom/bcm2835-gpiomem.c: "gpiomem");
<clever> srk: this driver is responsible for the char device
<srk> I see, thanks
<clever> 5 obj-$(CONFIG_BCM2835_DEVGPIOMEM)+= bcm2835-gpiomem.o
<clever> and its gated behind that kernel flag
* srk noted
<clever> 36 config BCM2835_DEVGPIOMEM
<clever> 37 tristate "/dev/gpiomem rootless GPIO access via mmap() on the BCM2835"
<clever> and it defaults to module, so you can just modprobe it
<clever> 38 default m
t184256 has left #nixos-aarch64 [#nixos-aarch64]
<srk> I wonder what's the libgpiod way of allowing user to use gpio via /dev/gpiochip
t184256 has joined #nixos-aarch64
<srk> daemon that does that on users behalf?
<clever> srk: probably, and it can likely assign permissions on a per-pin basis
<srk> need to finally try libgpiod haskell bindings to learn more about it. I wanted to write openOCD backend for it but ST people beat me to it and it's already available
<clever> srk: what i did, is launch openocd in another window (sysfs gpio backend), and watched the pins change from input to output
<srk> clever: hmm but that's linux_rpi-only, right?
<clever> srk: probably
<srk> ooh I wish LoRa support was mainlined already, would ditch the C packet_forwarder for a bit of haskell glue right away. wanted to do that for a long time now but
<srk> no haskell and no kernel LoRA :D
<srk> but I could do it with userspace-SPI meanwhile
<srk> "driver"
<clever> srk: HPi includes userland i2c and spi i think
<srk> yeah, I want as little rpi-specific things as possible :)
<clever> srk: then you want one of /dev/spi things
zupo_ has joined #nixos-aarch64
<srk> yup
<srk> socket with AF_LORA, call it a day
<clever> srk: how much do you know of the gpio alt functions on the pi?
<srk> not much, what are you looking for?
<clever> more, explaining some features i added
<clever> for each pin on the rpi, you can select between input, output, or one of 6 alt modes
<clever> the haskell code i linked previously, will show the current mode of each pin
<clever> if you want to use something like SPI0, you have to pick some pins (line 7-11), and then set them all to the right mode (alt0 in this case)
<srk> yeah, that's done via device trees typically
<clever> and SPI0 has 2 chip-select lines, so you can drive 2 SPI slaves like that
<srk> yup
<clever> what if you want to switch to gpio 35-39 temporarily?
<clever> to control a different pair of spi slaves?
<srk> from kernel or userspace?
<clever> either
<srk> doesn't make much difference
<srk> as you have /dev/spi0 bound to specific set already
<clever> but you have to start messing around in the gpio alt modes
<clever> and rebind the entire spi0 to a diff set of pins
<srk> but you can probably unload, apply dt overlay and load spi module back
<clever> i have a much simpler solution
<srk> btw
<clever> this creates an i2c mux in the dtb file
<clever> which explains the altmodes to linux
<srk> you can use any gpio pin for CS
<srk> hardware CS is pretty rare
<clever> yeah, but then the CS wont be synced to when the hw is pushing bytes out
<clever> so you need to wait for the queue to fully flush before you deactivate CS
<srk> like when hw is master and rpi slave?
<clever> i think the rpi can only be master
<clever> ive checked before, and it lacks spi slave support
<srk> til
<clever> the dts file i linked above, will create 3 virtual i2c devices
<clever> and if you try to use any of them, the kernel will change the altmodes dynamically
<srk> that's cool, didn't know that's possible
<srk> wow
<clever> spi likely has the same thing
<clever> or maybe it doesnt, lol
<srk> I'm going for a walk with one kernel hacker in about a hour, will ask him few things :D
<clever> next thing...
<clever> srk: i think you can detect the dts names for things, from a udev rule
<clever> and then create a /dev/i2c-smps and /dev/i2c-cam
<srk> that would be nice to have, 0 and 1 are confusing
<clever> my i2c mux makes it worse
<srk> :D
<clever> you now have i2c0, i2c1, i2c2, i2c3, i2c4, and i2c5
<clever> have fun! :P
<srk> hahah :D I see the need for udev rules now :D
<clever> if you peek in /sys, you can see the name behind each one easily
<srk> i2c-smps - that's pi4 power supply?
<clever> both the power supply and gpio expander are on that i2c bus
<srk> nice, that's new
<srk> can it do pmbus?
<clever> its been that way since the rpi2 i think
<srk> new to me .. :D
<clever> its been hidden by the firmware
<clever> the gpio altmode table i linked, doesnt even say what altmode to reach these
<srk> ahaa!
<srk> that explains a lot
<clever> srk: see the SDA on gpio 46/47?
<srk> yes
<clever> those where added, after i brute-force searched every hole in the table :P
<srk> :D good job!
<clever> and the problem...
<clever> is that the wifi/bluetooth chipset on the rpi3, has its reset line driven by the i2c gpio expander
<clever> so i cant get the wifi to respond until i release that reset signal
<clever> so now i need linux to support the gpio expander, without the firmwares help
<srk> it is different to one in pi3?
<srk> *is it
<clever> i think the rpi2 and rpi3 have the same expander
<clever> 29.172648 [LDR:LoaderImpl]: Jumping to the Linux kernel...
<clever> Uncompressing Linux... done, booting the kernel.
<clever> [ 0.000000] Booting Linux on physical CPU 0x0
<clever> that would be rpi-open-firmware booting nixos on an rpi3
<srk> cool!
<srk> do you know the name of the gpio expander chip?
<clever> yep, and i have a datasheet
<clever> crw------- 1 root root 89, 8 Jan 1 1970 /dev/i2c-8
<clever> srk: it goes up to 8, lol
<clever> 0/1/2 are the real i2c controllers
<clever> 3/4/5 are virtual devices under 0, mapping to different pairs of pins
<clever> 6/7/8 are also virtual, under 1
<clever> i2c-2 doesnt go thru the altmode mux, and is hard wired to the hdmi port for EDID use
<srk> :D
<clever> [root@rpi:~]# udevadm info -a -p /sys/bus/i2c/devices/i2c-3
<clever> ATTR{name}=="i2c-0-mux (chan_id 0)"
<srk> looks good
<clever> 318 pinctrl-names = "bus0", "cam0", "smps0";
<clever> but the dts file gives much clearer names
<srk> but no easy way to access them, I see
<clever> yeah
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 265 seconds]
<clever> /dev/mmcblk0p2 1.8G 1.7G 0 100% /
<clever> ok, that could be an issue
<srk> failed to resize?
<srk> or just that small?
<clever> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
<clever> mmcblk0 179:0 0 1.9G 0 disk
<srk> what's the sd card size?
<clever> 2gig
<srk> ah :)
<srk> my imx6 does a weird thing, after few dd runs with external reader it won't report correct size anymore until reboot
<srk> I have to scp to another computer instead :-x
<clever> 2020-05-01 14:35:53 < thefloweringash> The trick is to use: cc -x assembler-with-cpp -E
<clever> i think that works
<srk> cool, can you post the full command you use?
<clever> Error: /nix/store/8pp3i3hcp7bv0f8jllzqq7gcp9dbzvp9-glibc-2.27-dev/include/stdc-predef.h:0.90-91 syntax error
<clever> once it works
<srk> yesterday I was wondering how to test the dt-overlays thingie but didn't come up with a solution - if it's a test it would only run on aarch64 / armv7l and that looks too specific and a bit wasteful
<thefloweringash> cc -x assembler-with-cpp -nostdinc -E -I $(KDIR)/include -o $@ $<
<srk> the other idea was to expose attr that hydra would just build without running the vm
<srk> thefloweringash: thanks!
<clever> # 1 "/nix/store/8pp3i3hcp7bv0f8jllzqq7gcp9dbzvp9-glibc-2.27-dev/include/stdc-predef.h" 1 3 4
<clever> i think cc is adding comments that dtc cant parse
<srk> more preprocessing!
<srk> grep -v it :D
<clever> 179 builddtb() {
<clever> 183 rm temp temp2
<clever> 182 dtc temp2 -o $2
<clever> 181 egrep -v '^#' < temp > temp2
<clever> 180 cc -x assembler-with-cpp -E $1 -o temp
<clever> 184 }
<clever> srk: done
<srk> :))
<clever> ok, so if i deploy, and reboot, does it still boot...
<clever> [ 2109.103448] Reboot failed -- System halted
<clever> [ 2108.099575] reboot: Restarting system
<clever> srk: ok, so it still cant reboot itself...
<clever> panic(): "done testing"@utils.cc:226
<clever> and i just borked the firmware, lol
<srk> :D
alp has joined #nixos-aarch64
<clever> Fat 1.185383 BCM2708ArmControl::bridgeStart(): bridge init done, PM_PROC is now: 0x107F!
<clever> r12: 0x00000001 sp: 0x7eb4ca0c lr: 0x00462710 pc: 0x00000bce
<clever> panic(): "Fatal CPU exception!"@trap.cc:49
<clever> [nix-shell:~/apps/rpi/linux]$ arm-none-eabi-objdump -d /nix/store/gkgpdq1rr1m8w155r1ls6zfm5gw5100l-chainloader-arm-none-eabi/arm_chainloader.bin.elf
<clever> 00000b64 <add_new_area>:
<clever> bce: 685b ldr r3, [r3, #4]
<clever> tlsf/tlsf.c:size_t add_new_area(void *area, size_t area_size, void *mem_pool)
<clever> srk: something in my heap code is now invalid
<srk> tlsf is the allocator?
<clever> yeah
<srk> fun
<clever> but, i had recently built that in thumb mode
<clever> undoing it moves the error
<clever> r12: 0x00000001 sp: 0x7eb4ca0c lr: 0x00462710 pc: 0x00000ed4
<clever> 00000e88 <add_new_area>:
<clever> ed4: ebffff52 bl c24 <process_area>
<clever> all of the opcodes in here are now wider (arm, not thumb)
<clever> but it still failed in the same area...
<srk> heh
<clever> r12: 0x00000001 sp: 0x7eb4ca0c lr: 0x00462710 pc: 0x00000ed4
* srk gtg, will test openfw on pi4 tomorrow
<clever> wait a moment
<clever> that stack pointer....
<clever> mov sp, #(MEM_STACK_END)
<clever> arm_chainloader/memory_map.h:#define MEM_STACK_END (MEM_CODE_END + MEM_STACK_SIZE)
alp has quit [Remote host closed the connection]
<clever> 1b8: e3a0d909 mov sp, #147456 ; 0x24000
<clever> the stack appears to be corrupt
alp has joined #nixos-aarch64
<hexa-> ultrasonic sensor up and running
<hexa-> packaged gpio_next lib for python
webster23 has quit [Ping timeout: 260 seconds]
webster23 has joined #nixos-aarch64
webster23_ has joined #nixos-aarch64
webster23_ has quit [Read error: Connection reset by peer]
alp has quit [Ping timeout: 244 seconds]
webster23 has quit [Ping timeout: 260 seconds]
zupo_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Quit: Leaving]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo_ has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64