zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 258 seconds]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
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…]
tilpner has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<clever> samueldr: next time your pi4 is hooked up to the network, can you pastebin the output of `cat /sys/kernel/debug/clk/clk_summary` ?
<clever> distro shouldnt matter
<clever> nvm, got it from someone else
<clever> samueldr: https://imgur.com/a/2GX75kM
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
<samueldr> your spoon^W SPI flash is too big
<clever> samueldr: i can confirm that my own recovery.bin is ignored
<clever> samueldr: but, the official recovery.bin, is also ignored!
<samueldr> good, there was still a shred of doubt that I could have goofed up
<clever> i must be doing something wrong
<samueldr> hmmm
<samueldr> that's weird!
<samueldr> maybe it needs the SPI to be actually broken?
<samueldr> though that doesn't make sense
<clever> yeah
<clever> i could brick a pi by just writing a valid blink binary to spi
<samueldr> boot code in SPI broken to a while true; do nothing; loop would brick the device
<clever> and then it would never boot again
<clever> given that even the official recovery.bin doesnt work, we must be doing something wrong
<clever> samueldr: i have also made decent progress figuring out the PLL stuff in the pi's
<clever> samueldr: which is a requirement, to fix the clocks on the pi4
<clever> the pi3 has a few 2ghz clocks floating around within it
<clever> but those are mostly divided down, to make other clocks
ZoomZoomZoom has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
Irenes[m] is now known as Guest13147
Irenes has joined #nixos-aarch64
Irenes has quit [Quit: WeeChat 2.6]
Guest13147 has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : issued !quit command"]
orivej has joined #nixos-aarch64
Irenes[m] has joined #nixos-aarch64
<bennofs[m]> my pi 3b suddenly doesn't boot anymore. earlycon works, but switching to the full console appears to fail with `bcm2835-aux-uart 3f215040.serial: unable to register 8250 port - -28` (no serial output after that). I use earlycon=uart8250,mmio32,0x3f215040, console=serial0,115200 as kernel cmd. Any idea how to get a working serial output?
<bennofs[m]> also, how do I apply device tree overlays in NixOS on RPi 3? does dt-overlay in config.txt work?
* clever looks
<clever> 0x3e21_5000 AUX_IO_BASE
<samueldr> using the generic images, u-boot loads a device tree, which I assume overrides anything config.txt does
<clever> bennofs[m]: 0x3f215040 is the mini/aux-uart...
<samueldr> dtbos can be built into device trees loaded by u-boot using those options https://nixos.org/nixos/options.html#devicetree
<samueldr> bennofs[m]: it's possible the serial port pi-side changed its identifier at some point with the mainline kernel
<bennofs[m]> clever: yeah, but mini/aux-uart should be what I get on port 4,6,8 right?
<clever> bennofs[m]: depends on what the alt functions are set to
<clever> bennofs[m]: which the config.txt normally manages
<bennofs[m]> so, that specification for earlycon works
<clever> ah yeah, if earlycon is working, then its already in the right alt mode
<bennofs[m]> I get "bootconsole [uart8250] disabled" at the end
<samueldr> if you're already using ttyS1, try S0 or S2, I don't remember
* samueldr digs in irc logs
<bennofs[m]> console=uart8250,mmio32,0x3f215040 should make it figure out the right one I think
<clever> also of note, serial0 is an alias that only works with start.elf, it doesnt work with u-boot (as far as i know)
<clever> start.elf will replace serial0 with ttyAMA0 or something else, based on which uart it routed to linux
<bennofs[m]> but that gives the same error. I also tried ttyS0, ttyS1, ttyAMA0 and ttyS2
<bennofs[m]> wait, maybe I didn't try ttyS2...
<samueldr> probably isn't ttyS2, but eh
<bennofs[m]> but if I use ttyAMA0, that error does not appear, so I think it picks up the right con
* samueldr can't find citation
<samueldr> bennofs[m]: this comes after a kernel upgrade?
<clever> bennofs[m]: ttyAMA0 is the primary uart
<clever> bennofs[m]: the alt functions dont have that one exposed
<clever> GPIO14/15 are the uart on the header that i always use
<clever> ALT0 mode connects them to TXD0/RXD0 (ttyAMA0, the pl011 device)
<clever> ALT5 mode connects those pins to TXD1/RXD1 (the mini/aux uart)
<bennofs[m]> hmm, the UART i have right now is on 6/8 (gnd on 4)
<clever> the internal gpio numbering doesnt match the connector numbering
<clever> all of these list 4 as being 5v, not gnd
<bennofs[m]> oh, yeah, actually it's connected to 6/8/10
<bennofs[m]> so how do I switch to ALT0?
<clever> yeah, so thats GPIO14/GPIO15
<clever> i think its `enable_uart=1` in config.txt?
<bennofs[m]> i have that
<clever> digging thru docs...
<samueldr> bennofs[m]: did this come after a kernel upgrade, and do you have a previous generation to check?
<samueldr> alternatively/additionally, do you have another SD card to test a fresh image?
<bennofs[m]> no prev generation, didn't reboot in a long time :/
<samueldr> aye
<bennofs[m]> so probably kernel upgrade
<samueldr> none at all?
<samueldr> I thought for sure that you couldn't collect the currently running one
<clever> the docs for config.txt are missing...
<bennofs[m]> https://github.com/raspberrypi/linux/issues/3312 sounds like the issue
<{^_^}> raspberrypi/linux#3312 (by stevep-korg, 7 weeks ago, open): UART1 can not be made available on CM3/CM3+ running 4.19.66 built in master branch
<bennofs[m]> but I don't do any dtoverlay things
<samueldr> bennofs[m]: are you using the raspberry pi kernel fork or mainline linux?
<samueldr> this changes everything :)
<bennofs[m]> boot.kernelPackages = pkgs.linuxPackages_rpi3;
<bennofs[m]> sorry, should've mentioned that
<samueldr> ah. so disregard my previous bits about serial interface name changing, that was (if true) for mainline
<bennofs[m]> isn't there some way to tell linux to just keep the working earlycon? why does it need to disable it :(
<samueldr> I don't know much about their kernel and setup, so I can't say what's up
<clever> bennofs[m]: do you also have loglevel=7?
<bennofs[m]> loglevel=8
<samueldr> I think earlycon is an extremely naïve implementation of serial, so they want to graduate as early as possible to their true stack
<clever> [ 0.204489] pl011_console_setup
<clever> [ 0.207712] console [ttyAMA0] enabled
<clever> [ 0.215074] bootconsole [earlycon0] disabled
<clever> [ 0.215074] bootconsole [earlycon0] disabled
<clever> [ 0.207712] console [ttyAMA0] enabled
<clever> [ 0.263910] bcm2835-dma 3f007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
<clever> it prints this when it transitions from earlycon to normalcon
<samueldr> though it would indeed be useful to allow keeping earlycone as /dev/ttyearlycon
<clever> it will first print the new console, to all of them (including the new), so you know where your console vanished to
<clever> and then it prints the disabling to all
<clever> then actually disables
<clever> pl011_console_setup is a custom msg i had added
<bennofs[m]> it's interesting that it only prints the disable message when I have console=ttyAMA0 (i.e. not the correct one)
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
<bennofs[m]> otherwise, it gives the error but doesn't say anything about disabling (though it is at the same point in the log)
<clever> it should print the enable before the disable
<clever> so that would imply ttyAMA0 wasnt found
<bennofs[m]> it does print the enable for ttyAMA0
<bennofs[m]> but not for the "real" one I want to use, serial0/ttyS1
<clever> serial0 doesnt really exist
<clever> the firmware does a string replace against your cmdline.txt, which u-boot is likely blocking
<clever> can you pastebin the entire console output?
<bennofs[m]> http://ix.io/24Xw
<samueldr> bennofs[m]: just checking, it is indeed a 3B, and not a 3B+, right?
<samueldr> for a small while using 3B stuff on 3B+ worked
<bennofs[m]> oh, how do I find out? :)
<samueldr> check on the board what's written
<bennofs[m]> uboot says 3b, but maybe i use the wrong uboot
<bennofs[m]> B v1.2
<samueldr> alright, then not that issue
<samueldr> yeah, that u-boot would work on a 3B+ IIRC even though the 3B+ wasn't known for it
<samueldr> 2019.09, that is
<clever> 261 [ 3.095504] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 66, base_baud = 0) is a PL011 rev2
<clever> 262 [ 3.105447] bcm2835-aux-uart 3f215040.serial: unable to register 8250 port - -28
<clever> bennofs[m]: looks like it is detecting ttyAMA0, but its not clear which pins its routed to
<bennofs[m]> ttyAMA0, according to documentation I read, is routed to the bluetooth chip
<samueldr> yeah
<clever> this shows an example of the clock stuff the docs mention
<clever> the primary uart is fed from the 500mhz PLLD_PER clock, with a divisor to cut it down to 47,999,625hz i think
<clever> while the aux uart is fed from the 250mhz VPU clock, and has no divisor, so it runs at the full 250mhz
<clever> each uart, then divides that clock down further, to get the baud rate
pbb has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 260 seconds]
pbb has joined #nixos-aarch64
<clever> disable-bt disables the Bluetooth device and restores UART0/ttyAMA0 to GPIOs 14 and 15. It is also necessary to disable the system service that initialises the modem so it doesn't use the UART: sudo systemctl disable hciuart.
<clever> bennofs[m]: from the uart page you linked
<bennofs[m]> clever: not sure if the config.txt command to load that overlay works on my setup? Also, what happens to the existing miniuart on that port when this option is enabled?
<clever> bennofs[m]: the command does 2 different things
<clever> bennofs[m]: first, it tells the firmware to mess with the ALT modes on the pins, to match the expected setup
lovesegfault has joined #nixos-aarch64
<clever> bennofs[m]: second, it tells the firmware to load a given overlay when executing kernel.img (which may be u-boot?)
<clever> given that ttyAMA0 is already routed to linux (for bluetooth), you dont need to worry much about the DT area
* clever heads off to bed
pbb has quit [Ping timeout: 246 seconds]
pbb has joined #nixos-aarch64
ZoomZoomZoom has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Ping timeout: 265 seconds]
lovesegfault has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<bennofs[m]> i finally managed to get a serial con by copying kernel & initramfs from an old aarch64 nixos install image i had lying around
<bennofs[m]> now I can see why my system failed to boot, unexpected inconsistency during ext4 fsck which requires manually intervention. Reminder to self: run fsck on SDCARD when trying to debug boot fails
<bennofs[m]> actually, it's a newer version (4.19.80) which works. whatever
<samueldr> mainline vs. foundation I presume
lovesegfault has quit [Quit: WeeChat 2.7]
lovesegfault has joined #nixos-aarch64
pbb has quit [Read error: Connection reset by peer]
pbb has joined #nixos-aarch64
pbb has quit [Ping timeout: 246 seconds]