<samueldr> >> [ 5.898888] systemd[1]: Set hostname to <nixos>.
<samueldr> neat
<samueldr> so it's in stage-2 now
<samueldr> but still nothing on the display
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
rajivr has joined #nixos-aarch64
Mirrexagon has quit [Ping timeout: 264 seconds]
Mirrexagon has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
Mirrexagon has quit [Ping timeout: 256 seconds]
juliosueiras has quit [Ping timeout: 272 seconds]
Mirrexagon has joined #nixos-aarch64
knerten2 has quit [Remote host closed the connection]
<samueldr> oh neat, I don't know why I didn't try this earlier, looks like the usb gadget for networking is the standard gsi.rndis
<samueldr> finally, I can have a peek around!
justanotheruser has quit [Ping timeout: 272 seconds]
ninjin_ has quit [Ping timeout: 240 seconds]
ninjin_ has joined #nixos-aarch64
<lovesegfault> samueldr: alright, to close up the topic
<lovesegfault> (and with a cc. to clever)
<lovesegfault> Old bootloader + Kernel 4.9: Works
<lovesegfault> U-boot + Kernel 4.9: Doesn't work
<lovesegfault> U-boot + Kernel 5.4: Doesn't work
<lovesegfault> I suspect it's because of U-boot always enabling the UART which in turn jumbles the DPI-over-GPIO
<samueldr> highly probable
<lovesegfault> I'd like to try 5.4 + old bootloader
<lovesegfault> we'll see
<lovesegfault> Oh, also: `hardware.deviceTree` is _broken_ with the traditional bootloader
<samueldr> it would at least give a sample size of (1) to know about misc. hardwar
<samueldr> misc. hardware*
<lovesegfault> it may or may not work with uBoot, I couldn't find out because I could never get the screen to work
orivej has joined #nixos-aarch64
<lovesegfault> samueldr: is there some way I can dump a file in /boot via a NixOS config option?
<lovesegfault> almost like a `environment.etc` thing
<samueldr> not really
<lovesegfault> hm
<lovesegfault> that's a shame
<lovesegfault> basically means there is no way to package the hyperpixel anymore
<lovesegfault> since deviceTree is broken
<clever> lovesegfault: the uart is only on 2 DPI color pins
<clever> lovesegfault: so the DPI should still work, but the colors will be messed up
<lovesegfault> clever: Hmm, that doesn't match my observations :P
<lovesegfault> unless the colors are so messed up it's all black
<clever> na
<clever> does linux still boot?
<lovesegfault> Yeah, linux booted fine
<clever> cat /sys/kernel/debug/pinctrl/*.gpio-pinctrl-bcm2835/pins
<clever> pins ~0-27 should be in alt2 mode
<clever> some pins may be unused
<clever> compare what the pins file has, between working and broken
<lovesegfault> let me cook up another rpi image
<lovesegfault> I don't want to mess up this one that is working
<lovesegfault> this is what it looks like in a working system
<clever> 10/11, 18/19, 26/27 are holes in the mapping
<clever> that matches up with mode 6 in the documents
orivej has quit [Ping timeout: 272 seconds]
<lovesegfault> yep, I see that
<clever> the rest are all in alt2, so the DPI peripheral can control things
<lovesegfault> let's see what happens when I bake the image I was using previously
<clever> that also acts as a hint, on what i should do when trying to drive it
<lovesegfault> :D
<lovesegfault> flashing...
<lovesegfault> flashed
<lovesegfault> clever: any last log/data you want from the working system before I swap out sd cards?
<clever> yeeah, one sec
<clever> first, clone this on an x86 machine: https://github.com/librerpi/rpi-open-firmware
<clever> then nix-build -A arm7.utils
<clever> that will cross-compile some utils
<clever> then nix-copy-closure the path over to the pi, and run the pv_dumper
<lovesegfault> clever: this is the RPi4 again
<clever> that should be fine
<lovesegfault> I thought it was arm8?
<clever> it can still run arm7 code
<lovesegfault> Right, alright
<clever> as long as 32bit is enabled in the kernel
<clever> and nix deals with getting a compatible libc
<clever> so all of the other complications vanish
<lovesegfault> alright, I'm building those tools
<lovesegfault> done
<clever> pv_dumper will print all of the config for the graphics system
<clever> which would let you put the system into the same state again, without the drivers/firmware
<lovesegfault> :O
justanotheruser has joined #nixos-aarch64
<lovesegfault> nix copying to device
<lovesegfault> anything else before I reboot?
<clever> that looks good
<lovesegfault> going down
orivej has joined #nixos-aarch64
<lovesegfault> huh
<lovesegfault> the hyperpixel doesn't just go black when you `sudo shutdown now`
<lovesegfault> it slowly fades into a black backlight
<clever> sounds like the lcd driver wasnt turned off properly, but it just stopped refreshing
<clever> and the lcd was left to fade
alp has joined #nixos-aarch64
<lovesegfault> first boot successful, deploying config
<clever> pixel clock: XOSC / 1.687500 == 32.000000
<clever> i notice that the pi4 can use the crystal for DPI clock, because its 54mhz vs 19.2mhz
<clever> but its using fractional division, so it may have some dotcrawl
<lovesegfault> rebooting into new config
<samueldr> neat, confirmed that with DRM I can get something happening with the display
<samueldr> though not neat... it seems that whoever wrote the kernel drivers didn't need "old-school" framebuffer support
<samueldr> so the kernel doesn't support that AFAIK
<samueldr> so I guess I need to implement a DRM-backed version of the graphical tooling
zupo has joined #nixos-aarch64
<lovesegfault> clever: alright I'm in a baseline uBoot + 4.9 system. What would you like me to try?
<clever> lovesegfault: re-cat pins, and re-run pv_dumper, how do they differ?
<lovesegfault> pins are completely different, getting them into gist right now
<lovesegfault> mind you: I am making no effort to load the dtbo and have not set anything into the config.txt
<lovesegfault> so it's really vanilla
<lovesegfault> getting you the pv_dumper
<clever> ah, youll want to try and make it work, and see how closely it matches up
<lovesegfault> alright, I'll do that after the pv_dump
<lovesegfault> at least we'll have a baseline, even if useless
<clever> of note, pins shows that 14/15 is in alt5 mode
<clever> which is the aux uart
<lovesegfault> alright, next set of data will be as follows: no attempt to load DTBOs, but setting all of the expected things in the config.txt (manually)
<lovesegfault> here's what my config.txt looks like
<lovesegfault> rebooting
<lovesegfault> so, immediately: there is no output on the HDMI during early boot
<lovesegfault> after a few seconds HDMI displays the rainbow square
<lovesegfault> nothing on screen, which is expected. ssh'ing in...
<lovesegfault> well, maybe
<lovesegfault> it's gone into four flashes mode (rainbow on HDMI, green LED flashes four times every few seconds) which I have learned means "busted"
<lovesegfault> going to pop in the sd card and remove the dtoverlay lines, since those overlays aren't there to be loaded in the first place, and see if that helps
<clever> that means it cant find start4.elf on the fat32 partition
<lovesegfault> same
<lovesegfault> disabling all my additions
<lovesegfault> alright, with everything uncommented it boots fine again
<lovesegfault> so, something in that clause at the very bottom is causing issues
<clever> whats in that last clause?
<lovesegfault> this is what I added
<lovesegfault> which caused it to not even boot
<lovesegfault> removing the dtoverlay portions made no difference
<lovesegfault> so one of these makes it not boot
<clever> ah, not sure why those would break it
<clever> uart_2ndstage=1 and a uart adapter may give hints
<lovesegfault> we're back to me not having one (yet) :(
<clever> you can abuse a 2nd pi as a uart adapter
<clever> cross-link tx->rx, gnd<->gnd, and then enable_uart=1 on the "adapter" pi
<lovesegfault> let me see if I can find jumpers
<lovesegfault> Hm, no
<lovesegfault> any UART debugging will have to wait until later in the week
<lovesegfault> trying to add the dtbo's _and then_ enable those gpio_dpi things
<lovesegfault> heh
<lovesegfault> it doesn't crash
<lovesegfault> doesn't work but doesn't crash
<lovesegfault> current config
<lovesegfault> boots, nothing on display
<lovesegfault> reading pins
<clever> adding config, pins, and pv_dumper to the same gist can help
<lovesegfault> clever: you're right, I'll do that
<lovesegfault> combined
<lovesegfault> you can see the pins are in the _wrong_ state
<lovesegfault> s/state/mode/
<clever> yep, PV is configured, but altmodes are wrong
<clever> my theory, is that u-boot undid the dtoverlay=
<clever> so you have to setup the overlay with nix+uboot
<lovesegfault> let's try that as well
<lovesegfault> oh, wait, I forgot the init service!
<lovesegfault> let's see if that does anything
<clever> if you read the service, what does it do?
<lovesegfault> it runs a C thing, one second
<clever> looks like its writing some things over SPI
<clever> but if the pins are in the wrong altmode, it will never show an image
<clever> but there is no SPI controller on those pins
<lovesegfault> post init-service
<clever> so its having to bit-bang the SPI
<lovesegfault> now adding the dtbo's to Nix' deviceTree paraphernalia
<clever> that might also explain why my code never worked
<clever> it might be dpi with extra init
<lovesegfault> rebooting with the dtbo's applied via `hardware.deviceTree`
<lovesegfault> nope
<lovesegfault> gathering data
<lovesegfault> I swear this thing just doesn't apply the dtbo
<lovesegfault> going to try giving it the dts source
<clever> lets look at the source, what does hardware.deviceTree actually do?
<lovesegfault> clever: wait, I have an idea
<clever> modules/hardware/device-tree.nix: cfg = config.hardware.deviceTree;
<clever> 32 example = literalExample
<clever> 33 "[\"\${pkgs.deviceTree_rpi.overlays}/w1-gpio.dtbo\"]";
<clever> 36 A path containing device tree overlays (.dtbo) to be applied to all
<clever> 54 then pkgs.deviceTree.applyOverlays cfg.base cfg.overlays else cfg.base;
<clever> 53 hardware.deviceTree.package = if (cfg.overlays != [])
<clever> so the hardware.deviceTree.package will contain the result of applying the overlay
<clever> and it just runs fdtoverlay in a derivation, to apply each one
<clever> 10 for dtb in $(find ${base} -name "*.dtb" ); do
<clever> 11 outDtb=$out/$(realpath --relative-to "${base}" "$dtb")
<clever> and it will patch every dtb in the input
<clever> nixos/modules/system/activation/top-level.nix: ln -s ${config.hardware.deviceTree.package} $out/dtbs
<clever> lovesegfault: and it should then put the patched dtb in /run/current-system/dtbs, if you run dtc on one, you can view the source
<clever> boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh: echo " FDTDIR ../nixos/$(basename $dtbs)"
<lovesegfault> clever: check my PM to you
<clever> in
<clever> lovesegfault: checking the source above, it definitely wants a dtbo
<clever> lovesegfault: try another build, and lets look at the result
<lovesegfault> you can ./result (i.e. run) to deploy to the system
<clever> line 141 says what pins are part of dpi
<clever> so if something wants dpi_gpio0, it knows how to give it
* lovesegfault nods
<clever> 644 is 18bit dpi
<clever> instead of 24bit dpi
<lovesegfault> aha!
<clever> and aha, dpi is status="disabled";
<lovesegfault> why
<clever> which dtbo did you apply?
<lovesegfault> all three
<clever> none of those enable dpi
<lovesegfault> Huh
<lovesegfault> let me check something
<clever> i think whats happening, is that the enable_dpi_lcd=1 is doing its own overlays
<clever> which dont exist in any dtbo file
<clever> so you have to compare `dtc /proc/device-tree` between with&without, then write your own overlay to fix it
<samueldr> it's like they're trying to make it harder to use anything else than their secret sauce :(
<clever> samueldr: this is kind of what dtb was meant to do, and uboot is breaking stuff
<samueldr> that's totally orthogonal
<clever> dtb describes the hw, and the firmware is generating dtb that accurately describes the state
<clever> but then uboot goes "no, i know better" and uses its own dtb
<samueldr> why aren't those dtbo "sauces" available outside of the blackbox of the firmware?
<clever> yeah, that is still a good point
<samueldr> but yeah, I do agree that if u-boot was using the board-native FDT it'd be better
<clever> its probably just a complexity thing, a lot of this dtbo is dynamically generated based on config.txt
<samueldr> probably
<clever> so it would be rather complex to make a dtbo for every combination
<samueldr> though it'd be nice to have that state machine be publicly documented
<clever> yeah
<samueldr> because that's going to hurt mainline too
<lovesegfault> the screen flashes during early boot, which tells me something is kind of working
<clever> thats why i want better open source
<clever> so that whole mess is just plainly visible, and can be changed freely
<lovesegfault> clever: with & without uboot you mean?
<clever> lovesegfault: the firmware might setup DPI properly, but then linux takes over, and changes the unused pins to input
<lovesegfault> I see
<lovesegfault> let's do it! I'll pop in the working card
<samueldr> ugh, kind of stuck right now :| the fact that the razer phone 2 uses DRM is causing trouble
<clever> lovesegfault: yeah, compare `dtc /proc/device-tree` when its fully working, to how it looks with uboot and it partially working
<lovesegfault> or, actually, let me dump this one first
zupo has quit [Ping timeout: 260 seconds]
<samueldr> I guess the "better" way to solve it is to make the DRM-based framebuffer emulation work
<samueldr> as it's more universal and would allow framebuffer-only stuff to work
<clever> samueldr: which DRM? heh
<samueldr> the good stuff
<samueldr> Linux's direct rendering
<clever> ah
<clever> on the pi, thats what the legacy route did, just give linux a pointer and the w/h
<clever> and linux exposed it as /dev/fb0
<samueldr> there's already stuff in the kernel for fbdev emulation
<clever> but then you have no 2d accel, and when you get up to 4k, performance suffers
<lovesegfault> clever: popped in the working one
<samueldr> but it somehow doesn't seem to work here
<samueldr> which is what I'll need to investigate
<clever> lovesegfault: hping2 is also handy to know when its booted
<samueldr> but now that I've confirmed it _is_ that problem, I can at least move on and test
<samueldr> and gsi.rndis working is great, that means I can actually run things in stage-1 to test
<lovesegfault> clever: check out the diff
<clever> try `diff -u --color`
<clever> it makes it more readable
cole-h has joined #nixos-aarch64
<samueldr> oh, neat, also remembered why stage-2 ssh was broken
<clever> lovesegfault: reading...
<samueldr> a big leftover TODO if stage-1 sshd is running it'll trample on the port and not release it
<clever> model differs slightly, not an issue
<samueldr> !!
<clever> i see an i2c bus, with ft6236 nodes, for compatible=goodix,gt911
<lovesegfault> that's the touchscreen on this thing, I think
<clever> that should be present on both, if uboot was applying the overlay i saw earlier
<lovesegfault> which I haven't bothered testing yet
<clever> but if its touchscreen, we can ignore it or now
<lovesegfault> right
<lovesegfault> dpi18!
<lovesegfault> and uart as well
<clever> dpi18_pins is missing on one of them, yeah
<clever> and the uart is using different pins, *decodes*
<clever> > 0x1e
<{^_^}> attempt to call something which is not a function but an integer, at (string):324:1
<samueldr> turns out X11 tries hard
<clever> 30-33
<clever> which is bluetooth
<lovesegfault> that's in the RPi FW version
<lovesegfault> right?
* lovesegfault forgot the diff order
<clever> ah, but the difference is minor
<clever> its just the hw flow control
<clever> so bluetooth may suffer, but minor
<clever> the entire framebuffer node is missing, it was 800 x 480, which i think is your lcd?
<lovesegfault> yep
alp has quit [Ping timeout: 272 seconds]
<clever> and the address for that node is dynamic, so there is no way to ever make it with a dtbo
* lovesegfault chefs hands
<clever> it depends on where the gpu malloc() decided to put things
<clever> aha, and that linux,revision is a good hint
<clever> thats only done by the firmware (closed and open), but not uboot
<clever> .... so why is it in the reverse end of the diff! lol
<lovesegfault> lol
<clever> and the model, rev 1.2 feels like its done by the firmware
<lovesegfault> wait, there's another comaparison I want to run
<clever> that implies that uboot is adding the framebuffer, when the firmware wasnt
<clever> reading each dts seperately
<clever> ..... device-tree-working.dump has status="disabled"; on the dpi
<lovesegfault> compare device-tree-equal.dump
<lovesegfault> I removed the config.txt that disabled i2
<lovesegfault> *i2c
<lovesegfault> on uBoot
<lovesegfault> should look more similar
zupo has joined #nixos-aarch64
<clever> i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
<clever> lol
<lovesegfault> lol
<clever> yeah, now i'm just confused
<clever> these dumps say that the dpi is never enabled
<lovesegfault> well the big difference is this dpi18_pins clause
<clever> yeah, but nothing refers to it that i can see
<clever> oh right
<clever> phandle
<clever> dpi18_pins {
<clever> phandle = <0xc8>;
<clever> something should have a c8 in it...
<clever> rpi_backlight {
<clever> pinctrl-0 = <0xc8>;
<lovesegfault> ( samueldr let me know if you want a link to the tmate we're using to hack on )
zupo has quit [Ping timeout: 246 seconds]
<clever> dpi_18bit_gpio0 {
<clever> phandle = <0x88>;
<lovesegfault> wtf is mailbox
<clever> so only dpi18_pins is used, by rpi_backlight
<clever> mailbox is how the arm and vpu talk to eachother
<lovesegfault> Ah
<clever> basically, its just a pair of FIFO's
<clever> you write a 32bit sample to one end, and the other party can read the 32bit sample back out
<clever> the write side has flags to say if there is room to write more
<clever> the read side has flags to say if you can read, which can trigger an IRQ
<lovesegfault> all of the rpi_backlight is missing
<lovesegfault> but _why_
<clever> one sec
<clever> the gpios contains 15 and 19
<clever> that could either be absolute pin#'s, or offsets within the list for dpi18_pins
<clever> you would have to check the source of gpio-backlight to know for sure
<clever> pins may also act as a hint...
<lovesegfault> Where does that live even?
<clever> pin 15 (gpio15) function alt2 in hi; irq 0 (none)
<clever> pin 19 (gpio19) function gpio_out in hi; irq 0 (none)
<lovesegfault> right, in mode 6 pin 19 is unused
<clever> so 19 still being an output, implies its the backlight
<clever> can you ssh into the working card?
<clever> we can check something more on that angle
<lovesegfault> yep, one moment so I can swap out
<lovesegfault> booting
<lovesegfault> screen is working, FWIW
<clever> [root@aurelius:/sys/devices/platform/rpi_backlight/backlight/rpi_backlight]# cat brightness
<clever> 1
<clever> gone dark?
<lovesegfault> screen off
<clever> and if you hit it with a bright light, you should see image still?
<lovesegfault> trying
<clever> [root@aurelius:/sys/devices/platform/rpi_backlight/backlight/rpi_backlight]# echo 0 > brightness
<lovesegfault> try displaying something more interesting on the tty
<lovesegfault> like htop
<lovesegfault> might make it easier to eval
<clever> one sec
<clever> anything?
<lovesegfault> nope
polarfire has joined #nixos-aarch64
<lovesegfault> I can't see it at least
<lovesegfault> yep
<lovesegfault> it was there
<clever> i can confirm that 19 is changing when we turn it on/off
<clever> but the panel might be doing more then just backlight
<clever> it could be going into a low-power state and turning the lcd off too
<lovesegfault> Maybe
<ehmry> is there a trick to getting menuconfig working? instructions in the manual don't work
<clever> so in addition to the right pins being in alt2, you must also setup the gpio-backlight properly
<clever> ehmry: what error does it fail with?
<lovesegfault> FTR: with the non-working setup the backlight stays always-on
<lovesegfault> which matches our observations
<ehmry> ncurses
<clever> lovesegfault: most pins have a pullup, causing it to stick on
<lovesegfault> clever: maybe we need to force uBoot to load i2c_gpio and gpio_backlight early?
<lovesegfault> using like boot.initrd.kernelModules or w/e
<clever> lovesegfault: the order it loads in doesnt really matter much
<clever> ehmry: you have to mess with pkgconfig a bit, to get the host ncurses into scope
zupo has joined #nixos-aarch64
<lovesegfault> I wonder if in the non-working one gpio-backlight was loaded at all
<clever> lovesegfault: lets investigate how its working more...
<clever> [ 0.882374] bcm2708_fb soc:fb: FB found 1 display(s)
<clever> lovesegfault: ahhhh, thats why dpi is disabled in dtb
<lovesegfault> why does it find only one? I have HDMI plugged in
<clever> lovesegfault: your still using the legacy graphics api's
<lovesegfault> I am?
<clever> lovesegfault: hdmi only works if you set a config.txt to enable 2-screen mode
<lovesegfault> ah
<clever> [ 0.887215] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 480x800
<clever> because your using the legacy api, that makes a lot more sense
<clever> linux (and by extension uboot) should just not touch the altmode for most pins
<lovesegfault> can we make it use the non-legacy one and see?
<clever> and the backlight is the only thing in the dtb, so linux can do stuff a framebuffer cant
<clever> you then use the mailbox api (linked above) to ask the GPU firmware for the addr of a framebuffer
<clever> and the GPU does all of the work for you
<lovesegfault> Oh, this is probably b/c it's the old 4.9 kernel
<samueldr> thanks, nah, I'm fed up enough with my own display issues :)
<clever> i think you want `dtoverlay=vc4-fkms-v3d`
<clever> that will then properly describe everything in the dtb file
<clever> but its missing from your overlays folder, so you have to copy one over
<ehmry> clever: that works if I also set NIX_CFLAGS_LINK
<lovesegfault> clever: let's see, can I reboot?
<clever> lovesegfault: yep
<lovesegfault> coming up...
<clever> ehmry: yeah, thats how i fixed it in the past, but digging in, i found that linux is using pkgconfig to find the link flags on its own
<lovesegfault> screen is up
<samueldr> I found that there may be bugs in that implementation
<samueldr> version-dependent
<clever> [ 6.156009] vc4-drm soc:gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
<lovesegfault> noice
<clever> lovesegfault: your now using the firmware kms driver
<clever> [ 6.195224] vc4-drm soc:gpu: fb0: DRM emulated frame buffer device
<lovesegfault> awesome
<ehmry> whatever, the kernel is a shitfest
<clever> and then its emulating a framebuffer over kms!
zupo_ has joined #nixos-aarch64
<samueldr> but that nconf-cfg.sh script is not really good IIRC
polarfire has quit [Quit: WeeChat 2.7.1]
<clever> lovesegfault: ah yeah, pi4, the driver doesnt support direct control yet, so dpi will still be status = disabled
<lovesegfault> Hm
<clever> lovesegfault: dtoverlay=vc4-kms-v3d-pi4 would give linux more control, but that driver is currently unfinished
<clever> so i'm thinking the problem might be the uboot build
<clever> because linux is clearly leaving the unused pins alone
<clever> why is that changing?
<lovesegfault> Right, the only variable changing here is uBoot
<lovesegfault> well, ish
<clever> what was the storepath to the broken build? dont need to boot it
<lovesegfault> let me get it
<lovesegfault> can I close the nvim diff?
zupo has quit [Ping timeout: 256 seconds]
<clever> sure
<clever> system("/nix/store/3zm9jxia7wv8sgghrv3qfxg2pv09wgpa-extlinux-conf-builder.sh -g 20 -t 5 -c $out") == 0 or exit 1;
<clever> lovesegfault: this script gets ran to update /boot and build the rollback menu
* lovesegfault nods
<clever> samueldr: oh, but doesnt nixos ignore the uboot binary in /firmware/ ?
<samueldr> what do you mean?
<clever> nixos just updates cfg and never the uboot binary
<samueldr> yeah
<lovesegfault> AIUI if it's in /boot/firmware NixOS doesn't touch it
<clever> so how do we get the drv for the uboot binary, thats in this img?
<samueldr> well, there is something for the raspberry pi (only) that might update it
<lovesegfault> (in a u-boot configuration)
<clever> which attr path is it coming from
<clever> lovesegfault: and which nixpkgs are you building the img from?
<clever> lovesegfault: `niv show nixpkgs`
<lovesegfault> ubootRaspberryPi4_64bit
<clever> nix-repl> ubootRaspberryPi4_64bit
<clever> error: undefined variable 'ubootRaspberryPi4_64bit' at (string):1:1
<clever> lovesegfault: this nixpkgs lacks the pi4 uboot
<lovesegfault> ... but I updated it today
<clever> thats a commit from sept 15th
<lovesegfault> lol
<clever> now its on sept 10th!!
<lovesegfault> lol
<lovesegfault> WERE GOING BACK IN TIME
alp has joined #nixos-aarch64
<lovesegfault> ok, therest a sept. 19th commit right before
<clever> samueldr: whats the deal with nixpkgs-channels, do we still want to use that for the nixos-unstable branch?
<lovesegfault> I thought nixpkgs-channels was deprecated and we should just use nixpkgs now
<clever> lets just read master
<lovesegfault> are we going insane
<clever> samueldr: ubootRaspberryPi4_64bit isnt even in master.....
<clever> but it is in 3a13b44e862c0a6b86de975aa1a0c9dea1e4adc9!
<lovesegfault> what is happening
<lovesegfault> how can there be a commit that doesn't exist in any branches
<clever> your remotes, notice who is within them
<lovesegfault> lol
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ git fetch samueldr
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ gitk 3a13b44e862c0a6b86de975aa1a0c9dea1e4adc9
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ git branch --contains=3a13b44e862c0a6b86de975aa1a0c9dea1e4adc9 -a remotes/samueldr/feature/raspberrypi4-with-u-boot
<clever> lovesegfault: thre it is1
<clever> needed a -a on your contains
<lovesegfault> aha
<lovesegfault> rebase it onto `nixos-unstable`?
<clever> > pkgsCross.aarch64-multiplatform.ubootRaspberryPi4_64bit
<{^_^}> attribute 'ubootRaspberryPi4_64bit' missing, at (string):324:1
<clever> going to investigate from this one, starting in nixpkgs rev ee5ceca0b03072b0eb95a5216b5e4b0ffd04daf1
<clever> lovesegfault: your shell is breaking nix-shell, i cant run bash functions nix provides
<lovesegfault> clever: beware, there's a bug in my shell that if you nest nix-shells it hates you
<lovesegfault> let me disable that, one moment
<lovesegfault> building...
<lovesegfault> deploying...
<lovesegfault> going to restart tmate
<clever> kk
<lovesegfault> sent new onw
<lovesegfault> it will look similar, but won't be zsh
<clever> you could potentially also use that to detect it, and switch to bash only in nix-shell
<clever> IN_NIX_SHELL
<lovesegfault> I used this zsh plugin that tried to auto-do that
<lovesegfault> but it kind of sucked
<clever> viins ❯ nix show-derivation /nix/store/xcbmv7m9cf45wskh8qfzj4dz823rgrzr-uboot-rpi_4_defconfig-2020.07-aarch64-unknown-linux-gnu.drv
<lovesegfault> this is a good opportunity to get rid of it :P
<clever> ok, so we have some configure and cmake flags, we have a defconfig
<clever> we have some makeFlags and an installPhase
<clever> and a postPatch
<clever> and we have a configurePhase i missed somehow
<clever> so we must eval $configurePhase, not run configurePhase
<clever> viins ❯ phases="configurePhase" genericBuild
<clever> and thats a handy way to do it
<lovesegfault> is it doing something?
<clever> can you open another window again?
<clever> i dont use tmate hotkeys much, i use screen more
<lovesegfault> ctrl+a <release> "
<lovesegfault> or ctrl+a <release> %
<clever> and i'm already inside a screen session
<clever> so i have to ctrl+a a something
<lovesegfault> lol
<clever> id say just ctrl+c
<clever> take that l!
<lovesegfault> hahahaa
<clever> ok, so gpio, where is that...
<clever> 299 * If the firmware provided a valid FDT at boot time, let's expose it in
<clever> 300 * ${fdt_addr} so it may be passed unmodified to the kernel.
<clever> but thats not the problem anymore
<clever> the legacy framebuffer api should work even if uboot messes with dtb, you just loose backlight control
<lovesegfault> so, an interesting thing, if you try and apply the dtbo's to the 5.4 kernel you get an error about FDT_MAGIC
<clever> 344 eth_env_set_enetaddr("usbethaddr", msg->get_mac_address.body.resp.mac);
<clever> and this is something i also had to RE and reproduce
<clever> dynamic content that has to be added to dtb
<lovesegfault> yikes
<clever> basically, the network card in all pi's, lacks the rom for its mac addr
<lovesegfault> O.o
<clever> the firmware generates one based on the serial# of the CPU, and then puts it into the dtb
<clever> linux then respects that, and you get a predictable and static mac
orivej has quit [Ping timeout: 265 seconds]
<clever> then uboot throws it out and loads its own dtb, so it has to re-do that
<lovesegfault> lol
<clever> 484 * For now, we simply always add the simplefb DT node. Later, we
<clever> 485 * should be more intelligent, and e.g. only do this if no enabled DT
<clever> 486 * node exists for the "real" graphics driver.
<clever> aha, that explains the diff we saw before
<clever> 488 lcd_dt_simplefb_add_node(blob);
* lovesegfault nods
<clever> also, are your line#'s black on black? lol
<clever> i can only see them when i paste
<lovesegfault> light grey on dark grey :D
<lovesegfault> the tmate f's up my colorscheme for $reasons
<clever> ah
<clever> lowlevel_init.S is pretty simple, it just runs VERY early in uboot startup, to save the dtb addr
strikerlulu has joined #nixos-aarch64
<clever> so later code can reference it
<strikerlulu> hey
<clever> lovesegfault: ok, so bcm2835_gpio_direction_input and bcm2835_gpio_direction_output can modify the altmode...
<lovesegfault> yep
<lovesegfault> does that just always run?
<clever> lovesegfault: and nothing else can, so uboot isnt capable of setting it to a certain mode, only in or out
<clever> lovesegfault: and both are shoved into a dm_gpio_ops, and registered in the system
<strikerlulu> does nixos mobile has an telegram/discord group ?
<lovesegfault> samueldr ^
<clever> lovesegfault: and then drivers/pinctrl/broadcom/pinctrl-bcm283x.c has a copy of bcm283x_pinctrl_get_gpio_mux
<lovesegfault> so whenever uboot sets up pinctrl it's just overriding the altmode on the whole gpio?
<clever> lovesegfault: maybe, it might be setting everything to in...
<lovesegfault> right
<clever> and bcm2835_gpio_set_func_id can set the altmode, why did i not see that earlier...
<clever> its using BCM2835_GPIO_FSEL_BANK
<clever> ah, just didnt search right
<clever> lovesegfault: so bcm2835_gpio_set_func_id can also set it to alt2 for ex
<clever> lovesegfault: so it has a pinctrl driver to set altmodes, and then a gpio driver to set in/out and drive it as gpio
<lovesegfault> so it just steps on it's own toes?
<clever> lovesegfault: so the big question, what does it do with those on startup...
<clever> cmd/gpio.c: gpio_direction_input(gpio);
<clever> lovesegfault: there is a gpio cmd, so you can just drive things from the uboot script
<clever> post/post.c: gpio_direction_input(gpio);
<lovesegfault> fascinating
<lovesegfault> #gpio=0-25=a2
<lovesegfault> #gpio=19=op,dh
<lovesegfault> from someone's random config
<lovesegfault> matches what we expect?
<clever> that sounds like config.txt syntax, to set the modes we want, roughly
* lovesegfault nods
strikerlulu has left #nixos-aarch64 ["ERC (IRC client for Emacs 27.1)"]
<lovesegfault> want to try that out on the non-working sd-card?
<clever> post/post.c can only mess with a single pin, and only if CONFIG_SYS_POST_HOTKEYS_GPIO has been set
<clever> lovesegfault: uboot runs after config.txt, and would just break things again
cole-h has quit [Quit: Goodbye]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> lovesegfault: aha, pinctrl_config_one configures one pin, pinctrl_select_state_simple does something
<clever> pinctrl_select_state_full calls pinctrl_config_one in a loop
<lovesegfault> O.o
<clever> pinctrl_select_state then wraps it
<clever> i think this is to apply things like the dpi_18bit_gpio0 we saw before
<clever> pinctrl_select_state also does something
<clever> lovesegfault: yeah, i'm at a bit of a loss, all i can think of is the brute force solution, change the pins back from the CLI after booting
<lovesegfault> how hard is it to do that?
<clever> easy
<lovesegfault> let me boot the broken one
<clever> lovesegfault: hping is betetr then normal ping, but needs root
<clever> lovesegfault: hping2 192.168.2.5 -S -p 22
<clever> instead of sending icmp pings, it sends tcp SYN's to 22
<clever> so you can tell if 22 is open or closed
<lovesegfault> oh, nice
<clever> it can even ping a specific machine, behind a router
<clever> because the port forwarding relays it to the right box
<lovesegfault> screen is black with backlight on
<lovesegfault> it's interesting that they're not all hi nor all lo
zupo has joined #nixos-aarch64
<clever> ok, whats that CLI tool to manipulate gpio
<clever> it would have to be a pi specific one
<lovesegfault> trying to find it
<lovesegfault> there's libgpiod, and a python lib
<lovesegfault> idk if there's a cli
<lovesegfault> ah
Darkmatter66 has joined #nixos-aarch64
<clever> [nix-shell:~]# git clone https://github.com/WiringPi/WiringPi
Darkmatter66_ has quit [Ping timeout: 256 seconds]
<lovesegfault> you'll need a zillion -l's no?
<lovesegfault> every file needs another file :D
<clever> normally the makefile would handle it
<lovesegfault> right, is there no makefile?
<clever> but its broken and the helper scripts try to make install :P
<clever> and thats not the nix way
<lovesegfault> yikes
<lovesegfault> can we just patch out the make installs from the script?
<clever> shouldnt take too long to iterate this
* lovesegfault watches
<clever> this tool has way too many features, lol
<lovesegfault> it's bananas
<clever> [nix-shell:~/WiringPi/gpio]# gcc gpio.c -I ../wiringPi/ -I../devLib/ ../wiringPi/wiringPi.c readall.c ../devLib/gertboard.c ../devLib/piFace.c ../wiringPi/mcp*.c -lpthread -lm -lrt -lcrypt ../wiringPi/wiringPiI2C.c ../wiringPi/wiringPiSPI.c ../wiringPi/softPwm.c ../wiringPi/piHiPri.c ../wiringPi/softTone.c ../wiringPi/wpiExtensions.c ../wiringPi/sn3218.c ../wiringPi/htu21d.c ../wiringPi/bmp180.c ../wiringPi/sr595.c ../wiringPi/pcf8574.c ../wiringP
<lovesegfault> so close
<lovesegfault> clever: giving the adjective "maker" a whole new purpose
<clever> and of course, it doesnt work! lol
<lovesegfault> lol
<clever> the revision field is missing from cpuinfo, because your using the "wrong" kernel
<lovesegfault> b/c uBoot doesn't set the revision
<lovesegfault> the RPi fw does
<clever> ok, brute force answer :P
<lovesegfault> lol
<lovesegfault> If we get this to work I'm going to open my new scotch
<clever> now i have to ctrl+a a a S
<lovesegfault> SaaS soon enough
<lovesegfault> idk why nix-shell is so slow on this thing
<clever> network
<lovesegfault> ah
<lovesegfault> inb4 rpi explodes 🤣
<clever> ok, 0-9 should be alt2
<lovesegfault> something happened!!
<lovesegfault> I see text!!
<clever> messed up colors?
<lovesegfault> the colors are all jumped
<lovesegfault> *jumbled
<clever> because i didnt get all of the pins
<lovesegfault> it's all green
<lovesegfault> :D
<clever> i only set 0-9, so if we check the dpi readme
<clever> thats the blue channel only
<clever> but the pixel order may have swapped them around
<lovesegfault> so the background which should be black is green
<lovesegfault> the letters that should be white are blue
<clever> ah
<clever> next, we want 12-17
<lovesegfault> it looks right!
<clever> green should now be under our control
<clever> but not red
<lovesegfault> yes, red is wrong
<clever> 20-26 is red channel
<clever> now red is also setup
<lovesegfault> you wrote 21 instead of 26
<lovesegfault> YUSSSS
<lovesegfault> it looks perfect
<lovesegfault> all colorful garbage
<clever> how about now? lol
<lovesegfault> :D
lafa has joined #nixos-aarch64
<lovesegfault> I can just run this at boot, I think
<lovesegfault> and it should work
<lovesegfault> (as a systemd unit that runs right before hyperpixel4-init)
<clever> oh, build slaves
<lovesegfault> alright, let me add it to the overlay, deploy and we can see if it just works
<clever> it wont control the backlight yet, but there are other options for that
<clever> one sec
<clever> [root@aurelius:/sys/class/gpio]# echo 19 > export
<lovesegfault> black screen
<clever> [root@aurelius:/sys/class/gpio/gpio19]# echo out > direction
<lovesegfault> on
<lovesegfault> off
<lovesegfault> on
<clever> [root@aurelius:/sys/class/gpio/gpio19]# echo 0 > value
<clever> you can still manually tweak GPIO like this
<lovesegfault> sweet
<clever> a dtbo to re-add the backlight would be nicer, but not reqired
<lovesegfault> do I even need the dtbo's anymore?
<clever> only if you want touch
<lovesegfault> is touch working here?
<lovesegfault> I don't think it is
<clever> i think its missing from the overlays nixos gave uboot
<lovesegfault> shouldn't be ...
<clever> ft6236 goodix,gt911
<clever> lets search for those on the left
<clever> 404
<lovesegfault> hm
<lovesegfault> WHY
<clever> thats the current build its running
<clever> it hasnt changed since booting
* lovesegfault shrugs
<clever> i suspect you also dont need the hyperpixel4-init at all
<clever> try a cold boot without it?
<lovesegfault> I will, just want to add the C program to the overlay
<clever> full power cycle, to ensure the screen is reset
<lovesegfault> what's the fetcher for just a text file?
<clever> fetchurl can get it
<clever> but the unpackPhase will need a tweak
<lovesegfault> what's the tweak?
<clever> unpackPhase = "cp $src main.c ; sourceRoot=.";
<clever> the default expects a tar with a dir
<clever> then shove the rest into installPhase and/or buildPhase
<lovesegfault> lol
<lovesegfault> hackialization
<lovesegfault> YES
<clever> :D
<lovesegfault> ready for a reboot?
<clever> probably
<lovesegfault> hit it!
<lovesegfault> screen working during shutdown
<lovesegfault> coming up, still blank
<clever> you could also shove this into the initrd, to run it sooner
<lovesegfault> screen is blank
<clever> it ran after boot
<lovesegfault> yep
<lovesegfault> I think we do need that init thing
<clever> pins are in the right states
<lovesegfault> check it out
<lovesegfault> it will run on activation
<clever> yep
<lovesegfault> and we'll see if the screen somes up
<lovesegfault> screen is up
<clever> yeah, definitely needed
<lovesegfault> let's try a cold boot
<clever> thats why i couldnt get it to work with my kernel
<clever> i didnt know about that extra step
* lovesegfault nods
<lovesegfault> we can embed their init code into the hack
<lovesegfault> it's just C code anyway
<lovesegfault> screen is up and running!
<lovesegfault> let's see if the dtbo's need to be here at all
<lovesegfault> works :D
<clever> next thing would be to do the init sooner, in the initrd
<clever> one sec
<lovesegfault> hmm
<lovesegfault> actually I think if I save it like this it won't work
<lovesegfault> it'll refuse to boot
<lovesegfault> but let's try
<lovesegfault> works :D
<clever> ah, was on the wrong system, heh
<lovesegfault> :D
<lovesegfault> I love it when I reboot my laptop trying to reboot another system
<clever> earlyMountScript sounds like the earliest we can do it
<clever> i once implemented reboot in little-kernel
<clever> then i ran reboot, as NON ROOT, outside the serial terminal client
<clever> without any prompt, without even root, it rebooted, lol
<lovesegfault> the earliest I see is boot.initrd.postDeviceCommands?
<lovesegfault> lol, non-root reboot is evil
<clever> polkit
* lovesegfault nods
<clever> i logged in from a physical terminal, so i had special perms
<clever> ok, so now hyperpixel4-hack is in $PATH at initrd time
<lovesegfault> can we run init that early too?
<clever> postDeviceCommands is 241
<clever> earlyMountScript is 113
<lovesegfault> should be easy to embed into hack
<clever> yeah, easily
<clever> ah, but earlyMountScript is special
<clever> preDeviceCommands should work fine
<clever> i think that will do it
<lovesegfault> tempted to try an RIIR all of this later using https://github.com/rust-embedded/gpio-utils or https://github.com/rust-embedded/rust-sysfs-gpio
<clever> oh, that reminds me
<lovesegfault> :D
<lovesegfault> should I deploy it?
<clever> sure
<lovesegfault> let's see
<clever> you can also `ssh IP sudo reboot`
<lovesegfault> came up right before stage =
<lovesegfault> came up right before stage 1
<lovesegfault> working fine :D
<clever> line 219 is when it ran out init hack
<clever> 67 is when it says its in stage1
<lovesegfault> Maybe my eyes fooled me
<clever> but the print from 67 is likely still on the screen
<lovesegfault> right, that's it
<lovesegfault> do you want to see if it'll work with kernel 5.4? :D
<clever> sure!
<clever> 2 more builds for my haskell example to be ready
<clever> to even start the build, lol
<lovesegfault> fingers crossed!
<clever> note, this is all eval time builds for IFD, lol
<lovesegfault> it works!
<clever> nice
<lovesegfault> cc. samueldr
<clever> now the actual build can begin
<clever> 200 builds to go
<lovesegfault> send the builds up to stcg-us-0005-03
<clever> how?
<clever> ah, just copy-closure the drv over
* lovesegfault nods
<clever> you can still run `nix build` on a drv, to get the good UI
<clever> is that machine x86 or aarch64?
<lovesegfault> x86
<clever> good, ive not tested any native arm builds yet
<clever> one user tried to do an arm->vpu cross, and it broke horribly
<lovesegfault> this one is aarch64
<clever> rpi-open-firmware assumes your host is always x86
<lovesegfault> goes brrrr
<clever> :D
<clever> the closure of this build is rather bloated
<clever> i was more focused on having it work then having it build fast
<lovesegfault> well, hopefully this box helps with the speed part
<clever> the crazy thing i did in hs-gpio, is MMIO, from haskell
<clever> i think its building 2 ghc's now
<lovesegfault> oh no
<lovesegfault> ghc is _so_ slow to build
<clever> an x86 and an arm
<clever> its building them in parallel
<clever> lovesegfault: now up to qemu-user, for template haskell
* lovesegfault nods
<clever> lovesegfault: why do i prefer haskell over rust? lol
<lovesegfault> I do not know :P
<lovesegfault> do you want to hack on using https://github.com/rust-embedded/rust-sysfs-gpio in another window?
<clever> something else is coming up elsewhere
<lovesegfault> what does that mean?
<clever> distractions in another chat
<lovesegfault> Ah :D
<clever> i dont think the sysfs-gpio can do mode switching
<clever> only in/out
<lovesegfault> Oh, you're right
<lovesegfault> maybe it's this we want: https://github.com/rust-embedded/gpio-utils
<lovesegfault> nah
<lovesegfault> seems like that is even higher level
<clever> you either need something pi specific, or just direct MMIO
<lovesegfault> what are we using from bcm_host.h?
<clever> bcm_host_get_peripheral_address()
<clever> it tells you what addr to mmap, because it varies from model to model
<lovesegfault> alright, I'll just wrap that
<lovesegfault> I don't think I'm doing the right thing
<lovesegfault> how do I get an arm lib in a nix-shell?
<clever> pkgsCross.armsomething.stdenv.mkDerivation
<clever> you may instead want pkgsCross.armsomething.callPackage
<clever> so everything is arm
<lovesegfault> oh boy
<lovesegfault> is it building all of tust
<lovesegfault> rust
<lovesegfault> yes
<lovesegfault> it is
<lovesegfault> nope
<srk> :D
<srk> I'm trying to add ghc8.10.2-binary and it's pulling llvm 7..
<srk> I have 6, 9, 10 already built but not 7 :D
wrench[m] has left #nixos-aarch64 ["User left"]
<clever> lovesegfault: hows the build going for hs-gpio?
<lovesegfault> ghc still
<clever> and only 1 build, its hit a bottleneck
<lovesegfault> :(
<clever> lol
<lovesegfault> installPhase!!
<lovesegfault> it's past ghc
<clever> now its building haskell libs
<clever> in a cross manner
<clever> i prefer screen, because you can shuffle the tabs around
<clever> and watch both builds at once
<lovesegfault> I know tmux (which tmate is just a wrapper of) is super powerful, but I don't know how to use all of it
<clever> ah, brick is pretty late in the dep chain
<lovesegfault> lol
<lovesegfault> I don't know how to cross-dev rust with Nix
<clever> yep, done!
<clever> lovesegfault: now copy-closure that to the pi
<clever> then ssh into the pi, and run `nix-env -i` on it
<clever> this shows the altmode of each pin, in realtime
<lovesegfault> :D
<clever> brick can also accept input, so it could also allow changing modes, with some more code
<lovesegfault> I'm going to work on that Rust code this week
<clever> and that would let you quickly play around
<lovesegfault> and package it up nicely and then try an wrap it in a NixOS option
<lovesegfault> Thanks for all the help clever!
<lovesegfault> clever++
<{^_^}> clever's karma got increased to 510
<clever> yep
<clever> [detached (from session default)]
<lovesegfault> killed it
<lovesegfault> phew
<lovesegfault> 3 am
<lovesegfault> time to nap :D
<clever> 7am!
<lovesegfault> O.O
<lovesegfault> woah
<clever> # TZ=America/Moncton date
<clever> Tue Sep 22 07:18:09 ADT 2020
<clever> you can set TZ temporarily, to view the time in any given zone
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
quinn has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
quinn has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
zupo_ has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 256 seconds]
<Dandellion> I'm trying to build a u-boot arm image, but when I build it I get
<Dandellion> `You must set the option ‘boot.loader.grub.devices’ or 'boot.loader.grub.mirroredBoots' to make the system bootable.`
<Dandellion> even though grub.enable is false
juliosueiras has joined #nixos-aarch64
<sphalerite> Dandellion: maybe it's enabled elsewhere? Try setting it to lib.mkForce false instead of false
<Dandellion> yep, tried that too pretty confusing
juliosueiras has quit [Ping timeout: 260 seconds]
<Dandellion> here's a trace if that's helpful
<srk> Dandellion: and the input config?
Darkmatter66 has quit [Ping timeout: 260 seconds]
juliosueiras has joined #nixos-aarch64
<Dandellion> I'll share in a bit
<Dandellion> I moved some things around (which wasnt supposed to fix anything) and now it works
<Dandellion> ¯\_(ツ)_/¯
<srk> :)
alp has quit [Ping timeout: 272 seconds]
juliosueiras has quit [Ping timeout: 272 seconds]
superherointj has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
<veleiro> has anyone thought of routers with nixos as a base? running LuCi etc
<gchristensen> #nixos-on-your-router
<gchristensen> also I think vyos was looking at that
<clever> veleiro: i have a random dual-socket server mobo acting as my router, running nixos of course
<veleiro> yeah i could use nonrouter-specific board, of course
<veleiro> routers are definitely beefier than they use to be
<clever> veleiro: the router my ISP supplied, will mem-leak itself to death in 29.5 days (like clockwork) if you poll its status page once a minute
<Ke> if you get something like espressobin or macchiatobin, nixos should run just fine
<veleiro> lol
<veleiro> i have a turris omnia
<Ke> I run nixos in a vm on mcbin, though not doing routing
<veleiro> it does containers though, so i could do a nixos container
<veleiro> the openwrt-based distro is weak and made for small hardware for sure
<Ke> well if you have the storage, nixos is not absurdly heavy
<Ke> not starting everything under the sun by default helps a lot
<veleiro> not as light as busybox though
<veleiro> in this case, it doesnt need to be and that's why i ask
<veleiro> seems silly to use a container on top of a tiny-designed OS
<Ke> still anyway espressobin is not absurdly massive for home router
<Ke> and ISA compatible with aarch64
<veleiro> that's pretty cool. havent heard of it
<veleiro> good price
<srk> veleiro: omnia has one issue - no distro config support enabled for its u-boot
<clever> gchristensen: one crazy idea i had recently, using a CM4 (pi4 compute module) as the core of a router
<srk> and no easy way to fix that
<clever> the pi4 SoC uses RGMII to connect to its ethernet PHY
<clever> you can get a gigabit switch IC, that has 5 ethernet ports, 1 RGMII port, and vlan tagging support
<veleiro> ahhh, shame.
<veleiro> "open"
<clever> then you just vlan tag the WAN and LAN into seperate vlans, and make the RGMII a trunk port
<srk> like you can just build recent uboot with distro config enabled but it won't fit into SPL, the only way is to get some ancient ubuntu and build their own older u-boot with it
<Ke> clever: can you get such switches reasonably, I was looking, but most inxpensive and otherwise reasonable units were 100M
<Ke> is in not a enterprise grade rack switch
<Ke> as in
<clever> Ke: let me check my links...
<Ke> vlan switches with static config and reasonable size are common for video surveillance it seemed
<Ke> my mcbin is though currently in a state that does not warrant any extensions
<Ke> the hw maybe broken
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
zupo_ has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
<clever> Ke: this chip has 3 gigabit ports, 2 with builtin PHY, 1 with raw RGMII
<clever> "Full VLAN and QoS support"
juliosueiras has quit [Ping timeout: 240 seconds]
<Ke> right, but you need board and assembly for that
<clever> Ke: you would already need a custom board to use the CM4
<Ke> sure
<clever> so you would just make a custom host board for the CM4, that includes the above chip, and has 2 ethernet ports
cole-h has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<sphalerite> veleiro: at work, we use NixOS'd APU2 boards as routers for our smaller office and for off-site events.
<sphalerite> veleiro: one of my colleagues has duplicated that setup at home as well
<sphalerite> I think Ke was considering doing that too?
ar has quit [Quit: leaving]
ar has joined #nixos-aarch64
AmandaC has quit [Remote host closed the connection]
AmandaC has joined #nixos-aarch64
<makefu> hi all, what is the current status of cross-compiling a complete system (with configuration.nix). to be more precise, i would like to build a system derivation for my raspberrypi1. my idea was to start with the arm6 image from dezgeg and then cross-build every time i would like to change the system, then nix-copy-closure and switch-to-configuration. i am sure it has been done before me
<samueldr> if you wend up cross-compiling, you're better off just cross-compiling from the start
<samueldr> and results vary
<samueldr> the main important bits are the workarounds
<lovesegfault> samueldr: did you end up seeing the perversity me and clever arrived at to get that screen working?
<clever> ive found that a surprising number of shell scripts have the x86 bash in #! when i cross-compile all of nixos
<clever> but it somehow still boots, so i havent looked into it closely yet
<samueldr> lovesegfault: didn't read through any of it
<clever> samueldr: something (possibly uboot) is undoing the gpio mode config
<samueldr> highly likely
<clever> samueldr: that gist will revert things back to the correct modes
<samueldr> cool!
<lovesegfault> only took us a few hours :P
<samueldr> so does that allow configuring the display even without config.txt twiddling?
<lovesegfault> No
<clever> samueldr: you still need the config.txt entries, because of how dpi works on the 4
<lovesegfault> You don't need any dtbo's though
<clever> samueldr: with pi4, all video output goes via the firmware, due to incomplete linux drivers
<makefu> samueldr: awesome, exactly what i was looking for!
<clever> samueldr: so you must tell the firmware to configure DPI properly
<samueldr> makefu: it should work with a Nixpkgs from 10 days ago, if it doesn't from today
<samueldr> clever: okay
<makefu> :D
bennofs_ has quit [Read error: Connection reset by peer]
<samueldr> meanwhile I'm digging into the vendor kernel to see why fbdev emulation doesn't work, and there's already a pretty clear sign it tries to set it up but it fails
bennofs has joined #nixos-aarch64
<samueldr> so adding some logging until I can understand what's missing
<clever> samueldr: without any overlays, linux will use the legacy mailbox api to configure framebuffers, and the dpi stuff in config.txt causes the framebuffer to lead to dpi
<clever> but dpi only works if the pins remain in the correct mode
<clever> and the hyperpixel itself only shows an image if the init program is ran
<clever> gpio19 also acts as a toggle for the backlight and lcd driver
<clever> but without an overlay, linux wont know that
<clever> and its getting late here, i should get off to bed now
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
jumper149 has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
jumper149 has quit [Quit: WeeChat 2.9]
alp has joined #nixos-aarch64
kiren has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
juliosueiras has quit [Read error: Connection reset by peer]
juliosueiras has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
claudiii has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
jackdk has quit [Read error: Connection reset by peer]
jackdk has joined #nixos-aarch64
claudiii has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 260 seconds]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
Mirrexagon has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Mirrexagon has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
<lovesegfault> clever: rust code is coming along nicely :)