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>
<jazza> klipper@pine64:~$ client_loop: send disconnect: Broken pipe what it is cause
<Armbian-Discord>
<Tenkawa> that can be caused by numerous things
<Armbian-Discord>
<Tenkawa> need more details as to your setup/what you were doing/etc
<Armbian-Discord>
<Tenkawa> need more info
<Armbian-Discord>
<Tenkawa> 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>
<Tenkawa> 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
<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>
<IgorPec> 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>
<IgorPec> 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>
<IgorPec> probably. like i said - regarding parameter name, you need to check in the code
<Armbian-Discord>
<IgorPec> 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>
<IgorPec> 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>
<IgorPec> this pci delay is known trouble here
<Armbian-Discord>
<IgorPec> sometimes causing that pci fails to inti
<Manouchehri>
IgorPec: but currently I have 0ms of delay, no...?
<Armbian-Discord>
<IgorPec> 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>
<IgorPec> well, i don't know which numbers are ok
<Armbian-Discord>
<IgorPec> this is on you to find ozut
<Armbian-Discord>
<Tenkawa> 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>
<Tenkawa> wouldn't be the first time its happened
<Armbian-Discord>
<Tenkawa> Manouchohri: just because its set doesn't mean the "hardware" knows
<Armbian-Discord>
<Tenkawa> and consistently communicates
<Armbian-Discord>
<Tenkawa> u-boot and devicetree add a layer of complexity
<Manouchehri>
isn't this a linux kernel parameter?
<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>
<Tenkawa> ok the other one is for 4.4 kernels so it can be ignored
<Armbian-Discord>
<Tenkawa> then yeah It definitely points back to your u-boot
<Armbian-Discord>
<Tenkawa> 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>
<ManoftheSea> 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
<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