ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
norwich_ has joined #armbian
norwich has quit [Ping timeout: 252 seconds]
norwich_ is now known as norwich
gabes9 has joined #armbian
kolla has quit [Quit: %fog relay%]
gabes has quit [Ping timeout: 248 seconds]
gabes9 is now known as gabes
kolla has joined #armbian
lyri has quit [Remote host closed the connection]
Malditron has quit [Quit: Konversation terminated!]
DarkG has quit [*.net *.split]
hook has quit [*.net *.split]
s1b1 has quit [*.net *.split]
Fleck has quit [*.net *.split]
ikmaak has quit [Write error: Connection reset by peer]
DarkG has joined #armbian
hook has joined #armbian
ikmaak has joined #armbian
Fleck has joined #armbian
s1b1 has joined #armbian
indy has quit [Ping timeout: 260 seconds]
indy has joined #armbian
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #armbian
marco44 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
marco44 has joined #armbian
willmore has quit [Remote host closed the connection]
LanDi has joined #armbian
LanDi has quit [Client Quit]
LanDi has joined #armbian
LanDi has quit [Remote host closed the connection]
DarkL0rd has joined #armbian
chewitt has joined #armbian
flyback has quit [Quit: Leaving]
flyback has joined #armbian
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #armbian
alekksander has joined #armbian
phenom has quit [Ping timeout: 252 seconds]
MrFixIt has joined #armbian
<Armbian-Discord> <j​azza> klipper@pine64:~$ client_loop: send disconnect: Broken pipe what it is cause
<Armbian-Discord> <T​enkawa> that can be caused by numerous things
<Armbian-Discord> <T​enkawa> need more details as to your setup/what you were doing/etc
<Armbian-Discord> <T​enkawa> need more info
<Armbian-Discord> <T​enkawa> if your machine rebooted and you had remote connections logged in.. one that machine reboots that's usually what will also apppear as soon as any standard input is put on that tty if you try to type on the existing connection
<Armbian-Discord> <T​enkawa> but the message itself is too generic without more debug info
phenom has joined #armbian
willmore has joined #armbian
chewitt_ has joined #armbian
chewitt has quit [Ping timeout: 252 seconds]
chewitt_ has quit [Quit: Zzz..]
lyri has joined #armbian
<Manouchehri> CosmicDJ: hmm, so I shouldn't have both?
archetech has joined #armbian
<Manouchehri> [ 2.262466] rockchip-pcie f8000000.pcie: no bus scan delay, default to 0 ms
<Manouchehri> but... cat /sys/module/pcie_rockchip_host/parameters/bus_scan_delay
<Manouchehri> 1000
<Manouchehri> running 5.19.15
<ArmbianHelper> ^ How to change PCIe Bus Scan Delay without building Kernel - Beginners - Armbian Community Forums
<Manouchehri> thank Armbian-Discord
<Manouchehri> erm * ArmbianHelper
lyri has quit [Remote host closed the connection]
lyri has joined #armbian
<Armbian-Discord> <I​gorPec> you can supply a parameter to the kernel by adding a line to /boot/armbianEnv.txt extraargs=pcie_rockchip_host bus_scan_delay=1000
<Armbian-Discord> <I​gorPec> not sure if parameter name is correct, but this is how its done
<Manouchehri> IgorPec: shouldn't it be: extraargs=pcie_rockchip_host.bus_scan_delay=1000 ?
<Armbian-Discord> <I​gorPec> probably. like i said - regarding parameter name, you need to check in the code
<Armbian-Discord> <I​gorPec> i don't know which is right name
<Manouchehri> IgorPec: /sys/module/pcie_rockchip_host/parameters/bus_scan_delay is showing that I've set it
<Manouchehri> but I still end up with no delay: [ 2.303221] rockchip-pcie f8000000.pcie: no bus scan delay, default to 0 ms
<Armbian-Discord> <I​gorPec> which kernel you use?
<Manouchehri> Linux nanopi-r4s 5.19.15-rockchip64 #trunk SMP PREEMPT Fri Oct 14 15:39:06 EDT 2022 aarch64 aarch64 aarch64 GNU/Linux
<Armbian-Discord> <I​gorPec> this pci delay is known trouble here
<Armbian-Discord> <I​gorPec> sometimes causing that pci fails to inti
<Manouchehri> IgorPec: but currently I have 0ms of delay, no...?
<Armbian-Discord> <I​gorPec> try changing some other parameter to see if this parameters are working
<Manouchehri> I currently have extraargs=net.ifnames=0 pcie_rockchip_host.bus_scan_delay=1000
<Armbian-Discord> <I​gorPec> well, i don't know which numbers are ok
<Armbian-Discord> <I​gorPec> this is on you to find ozut
<Manouchehri> do you mean like less than 1000?
<ArmbianHelper> ^ build/rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch at master · armbian/build · GitHub
alekksander has quit [Ping timeout: 264 seconds]
<Manouchehri> IgorPec: sorry, which numbers are you referring to? like the delay value or...?
alekksander has joined #armbian
Masterphi has quit [Ping timeout: 248 seconds]
<Armbian-Discord> <I​gorPec> yes
<Manouchehri> so my /proc/cmdline is
<Manouchehri> root=UUID=0e4eda04-626d-4eaf-a8a0-e6e4ae9d9638 rootwait rootfstype=f2fs splash=verbose console=ttyS2,1500000 consoleblank=0 loglevel=1 ubootpart=35fb151f-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u net.ifnames=0 pcie_rockchip_host.bus_scan_delay=100 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
<Armbian-Discord> <I​gorPec> looks good
<Manouchehri> root@nanopi-r4s:~# cat /sys/module/pcie_rockchip_host/parameters/bus_scan_delay
<Manouchehri> 100
<Armbian-Discord> <I​gorPec> correct
<Manouchehri> root@nanopi-r4s:~# dmesg | grep 'bus scan delay'
<Manouchehri> [ 2.261821] rockchip-pcie f8000000.pcie: no bus scan delay, default to 0 ms
<Manouchehri> see why I'm pulling my hair out? :P
LanDi has joined #armbian
<Armbian-Discord> <I​gorPec> aha, its not readed out
<Manouchehri> but... pcie_rockchip_host's parameter shows up correctly in sysfs
LanDi has quit [Quit: LanDi]
<Manouchehri> IgorPec: I don't get how it wouldn't be read out
<Armbian-Discord> <I​gorPec> looking into the code, setting some debug prints ?
<ArmbianHelper> ^ gist:eda47477d3428d4ce3fbae69d674af40 · GitHub
<Manouchehri> does that look fine to add to userpatches/customize-image.sh?
alekksander has quit [Quit: Konversation terminated!]
<Manouchehri> and
<Manouchehri> echo "CONFIG_PCIE_ROCKCHIP_HOST=m" > userpatches/sources/rockchip64.conf
<Manouchehri> Failed to enable unit, unit /etc/systemd/system/systemd-networkd.service is masked.
bfcoqg has joined #armbian
<CosmicDJ> Manouchehri: the default is NetworkManager, you have to install/enable systemd-networkd to use it
<Manouchehri> CosmicDJ: I just unmasked it, lemme see if it works now.
bfcoqg has left #armbian [#armbian]
<CosmicDJ> Manouchehri: you have to disable NetworkManager, too https://www.xmodulo.com/switch-from-networkmanager-to-systemd-networkd.html
<ArmbianHelper> ^ How to switch from Network Manager to systemd-networkd on Linux
<CosmicDJ> Manouchehri: also, shouldn't you fix one thing at a time? turning too many knobs is not helpful
CosmicDJ has quit [Quit: reboot]
<Manouchehri> CosmicDJ: Got it working with networkd, thanks :)
archetech has quit [Quit: Konversation terminated!]
indy has quit [Ping timeout: 252 seconds]
<Manouchehri> How can I override CONFIG_PCIE_ROCKCHIP_HOST=m instead of CONFIG_PCIE_ROCKCHIP_HOST=y?
<Armbian-Discord> <T​enkawa> unless you know how its interacting with the rest of the kernel... simple answer is don't
CosmicDJ has joined #armbian
<Manouchehri> Tenkawa: well currently it's failing to find any PCIe devices
<Manouchehri> so it's interacting poorly : P
<Armbian-Discord> <T​enkawa> which device?
<Armbian-Discord> <T​enkawa> SoC
<Armbian-Discord> <T​enkawa> ?
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
<Manouchehri> Tenkawa: RK3399
<Manouchehri> NanoPi R4S[e]
<Armbian-Discord> <T​enkawa> oh the R4S
<Armbian-Discord> <T​enkawa> oh that thing is a pain
crabbedhaloablut has joined #armbian
<Manouchehri> why?
<Armbian-Discord> <T​enkawa> it has a few "differences" from the RK3399 that make it a bit annoying to work with
<Armbian-Discord> <T​enkawa> likely you have some devicetree adjustments needed too
<Manouchehri> so it works fine
<Manouchehri> but often the PCIe ethernet does not work
<Manouchehri> [ 2.789258] rockchip-pcie: probe of f8000000.pcie failed with error -110
<Manouchehri> [ 2.789212] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
<Armbian-Discord> <T​enkawa> Yeah... it just needs adjustments/patches to stop that from what I remember
<Armbian-Discord> <T​enkawa> There's a whole group of people with that unit
<Armbian-Discord> <T​enkawa> unfortunately the person that could tell me where the info might be awat from keyboard at the moment
<Armbian-Discord> <T​enkawa> Last status I remember is they finally had it all working 100%
<Manouchehri> WAIT
<Manouchehri> I see it sometimes works
<Manouchehri> [Wed Oct 19 18:28:10 2022] rockchip-pcie f8000000.pcie: wait 1000 ms (from command-line) before bus scan
<Manouchehri> on a reboot, it doesn't!
<[TheBug]> yeah probably because uboot isn't patched in the same way...
<[TheBug]> hmm
<Armbian-Discord> <T​enkawa> @TheBug we ran into a whole crew of those units and they all needed tweaks
<Manouchehri> [TheBug]: but then why is sysfs fine?
<[TheBug]> ah, I would imagine its reset on reboot to 0 and then not reinitialized without power off, likely to do with what Tenkawa is saying there
<Manouchehri> root@nanopi-r4s:~# cat /proc/cmdline
<Manouchehri> root=UUID=efd35bda-e273-466b-9f9d-affb8db9358b rootwait rootfstype=f2fs splash=verbose console=ttyS2,1500000 consoleblank=0 loglevel=1 ubootpart=b1f26560-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u net.ifnames=0 pcie_rockchip_host.bus_scan_delay=1000 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
<Armbian-Discord> <T​enkawa> Manouchehri: its a multilayered problem where the u-boot can't do proper dts communication all the way through to the kernel probably
<Manouchehri> [TheBug]: but pcie_rockchip_host.bus_scan_delay=1000 is clearly set in /proc/cmdline
<Armbian-Discord> <T​enkawa> wouldn't be the first time its happened
<Armbian-Discord> <T​enkawa> Manouchohri: just because its set doesn't mean the "hardware" knows
<Armbian-Discord> <T​enkawa> and consistently communicates
<Armbian-Discord> <T​enkawa> u-boot and devicetree add a layer of complexity
<Manouchehri> isn't this a linux kernel parameter?
<Armbian-Discord> <T​enkawa> Found the patch..
<ArmbianHelper> ^ build/rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch at master · armbian/build · GitHub
<Manouchehri> not this I assume?
<Armbian-Discord> <T​enkawa> unfortunately yeah that one and this one are the 2 me merged pci-host-rockchip-0000-scan-bus-fix-from-rockchip64.patch
<Manouchehri> erm, don't I already obviously have that patch in? :P
<Armbian-Discord> <T​enkawa> no
<Armbian-Discord> <T​enkawa> nothing is "obvious"
<Armbian-Discord> <T​enkawa> I just scanned through my patch repo for the function calls
<Armbian-Discord> <T​enkawa> that one came back
<Armbian-Discord> <T​enkawa> We use a different build than Armbian
<Armbian-Discord> <T​enkawa> but patches from several soures
<Manouchehri> root@nanopi-r4s:~# dmesg | grep 'bus scan'
<Manouchehri> [ 2.288472] rockchip-pcie f8000000.pcie: no bus scan delay, default to 0 ms
<ArmbianHelper> ^ build/rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch at master · armbian/build · GitHub
<Manouchehri> that string only exists in the patch
<Manouchehri> afaik?
<Armbian-Discord> <T​enkawa> ok the other one is for 4.4 kernels so it can be ignored
<Armbian-Discord> <T​enkawa> then yeah It definitely points back to your u-boot
<Armbian-Discord> <T​enkawa> did you update it with your image?
<Manouchehri> Tenkawa: isn't uboot on the same microsd card? Is there a different patch for uboot?
<[TheBug]> Manouchehri: Tenkawa and I were chatting some and the way it acts, it seems like the driver is in ther kernel but not uboot and I personally think when you boot it cold and it works you are literally getting lucky where it just happens to come up in time on some occasion
<[TheBug]> but it would explain why you shut it down and then it never re-initis
<[TheBug]> cause it is never reset by uboot
<[TheBug]> Manouchehri: maybe this idea will help you in some case -- uboot is like bios, you have to configure the bios for it to know where things are -- uboot is the warm gooey center between the arm cores and Linux
<[TheBug]> if the bios doesn't know how to manage the hardware then weird things happen
<[TheBug]> in this case it seems it won't reset pci cause it doesn't know about it
<Manouchehri> [TheBug]: I thought armbian was using it's own uboot, not rockchip's?
<Armbian-Discord> <M​anoftheSea> even still, if uboot doesn't know how to manage the hardware: weirdness
<Manouchehri> [TheBug]: I still don't understand why the kernel is ignoring the cmdline though
<CosmicDJ> Manouchehri: I don't understand why you need this? Isn't it for external PCIe devices? I doubt the NanoPI R4S even has a PCIe slot
<Manouchehri> CosmicDJ: the second ethernet port is attached via PCIe
lemonzest has quit [Quit: WeeChat 3.6]
<CosmicDJ> Manouchehri: and it's not found when you boot your r4s?
<Manouchehri> correct, not after a reboot
<Manouchehri> oh wait
<Manouchehri> this isn't an issue on my R4S
<Manouchehri> only the R4SE
<Manouchehri> I can reboot the R4S and it doesn't need anything beyond stock to work fine
<ArmbianHelper> ^ NanoPi R4s, enp1s0 ethernet device not showed up after reboot - Beginners - Armbian Community Forums
<Manouchehri> http://ix.io/3WJk
<ArmbianHelper> ^ [text/plain]
<Manouchehri> [ 2.588012] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
<Manouchehri> same problem
<Manouchehri> hmm yeah it fails sometimes on a cold boot too
Masterphi has joined #armbian
<Manouchehri> I feel like if I could modprobe pcie_rockchip_host, it would be much easier to troubleshoot
<Manouchehri> but I can't, since it's built in
<Manouchehri> ended up doing the UI rebuild
pablocastellanos has quit [Ping timeout: 252 seconds]
<Manouchehri> alright so, if I want to update my kernel, which *.debs should I install?
<Manouchehri> just linux-image-current-rockchip64_22.11.0-trunk_arm64.deb?
pablocastellanos has joined #armbian
<[TheBug]> so I don't know your answer BUT if I had to guess, the most basic answer is if your using DTB for R4S on R4SE which may not be pin to pin same on how it connects things the port or something about pcie bring-up or enable is different between the two boards and likely to fix this you will need to modify the dtb in the correct way to enable it on the right port/ config
<[TheBug]> so maybe terms you search for are like: R4SE pcie uboot enable
<Manouchehri> hang on though, if that was the case, the PCIe port should *never* work, not just sometimes
<[TheBug]> look about 15:53 in time above, you will see I mention why this could be the case
<[TheBug]> I mention you Tenkawa and I were talking about it and said my best guess to why that is
<[TheBug]> won't change that for best stability it may need enabled correct in uboot
<[TheBug]> if you are using image for R4S on R4SE then dtb could be different and contributing to this issue
<[TheBug]> next from that, I would suggest you post on the forum about your issue
<Manouchehri> brb dinner, thanks for the advice so far :)
<[TheBug]> that way community can also try and help
<[TheBug]> not always will someone be here
<ArmbianHelper> ^ NanoPi R4s, enp1s0 ethernet device not showed up after reboot - Beginners - Armbian Community Forums
<Manouchehri> installing my =m kernel now to test :)
<Manouchehri> modprobe -r pcie_rockchip_host ; sleep 1 ; modprobe pcie_rockchip_host
<Manouchehri> yep, it works now
<Manouchehri> if it fails at boot, just removing the module and trying it again does the trick
<Manouchehri> [TheBug] / CosmicDJ: so if it this was a uboot issue, why does my fix of compiling pcie_rockchip_host as a module and reloading it work?
<Armbian-Discord> <M​anoftheSea> what would be different between loading the module with boot and loading it later?
<Manouchehri> ManoftheSea: currently, what I know is: loading the module later works, loading it at boot usually doesn't
<Manouchehri> I currently have 100% success rate with the reloading trick
<stipa> sounds like a nasty hack
<Manouchehri> it is
<Manouchehri> but nobody believed me that it was related to loading pcie_rockchip_host too early :P
<ArmbianHelper> ^ gist:a2258f1541707f8d5dc4c23e8e1d1109 · GitHub
<Manouchehri> this is with me reloading
<ArmbianHelper> ^ [Invalid] - (Partially) Fixed PCIe training problem - Libre Renegade - Armbian Community Forums
<ArmbianHelper> ^ linux/pcie-rockchip-host.c at master · torvalds/linux · GitHub
<ArmbianHelper> ^ What is the Linux built-in driver load order? - Stack Overflow
<Manouchehri> stipa: not yet; I'm increasing the timeout for the PCIe training to 1500ms first to see if that fixes it
<stipa> Manouchehri: right, if you bodge something nice propose a patch to the appropriate place on github
<ArmbianHelper> ^ Armbian · GitHub
<ArmbianHelper> ^ build/patch/kernel/archive/rockchip64-5.19 at master · armbian/build · GitHub
<stipa> i dunno, that you'll have to talk to some of the devs, in a nut shell the fix should be in the next version of the armbian for that board
<stipa> but, it could be the place, there are some patches
<Manouchehri> nope, still a timeout at 1500ms
<stipa> if you can probe the driver when the linux boots it could be some timing issue on boot
<ArmbianHelper> ^ gist:182e865a76fbe04e1c3c0c17befb8236 · GitHub
<Manouchehri> not much seems to happen between the first failure, and me
<stipa> Manouchehri: interesting thing i see from the log is that r8169 never tires to load on boot
<stipa> tries*