Open jhanmann opened 1 year ago
Does PCIE 2.0 (i.e. Ethernet and Wi-Fi) still work with this change?
I don't have WiFi. I'm not using any PCI-e modules. The built-in Ethernet works fine. This change is already in the linux-quartz64 GitHub repo although I didn't figure that out until after I had already debugged the problem myself. It did get rid of an error I was getting out of the PCI initialization.
p.s. I'm trying to get the new panfrost driver in the 6.2 (actually the in process 6.3 kernel) loading but it is currently crashing.
I'm actually using this kernel and it is working pretty well. I tried to use their proposed DTS that was going into 6.3 supposedly but it is missing too much stuff.
I will look at getting a WiFi module to test stuff out with but not immediately. I think it ought to be a safe change as an additional note. This is a new requirement of the most recent kernels from what I can tell.
If you mean pancsf, check out the pancsf-midstream branch.
Yes. I did mean pancsf. I should have checked for other branches in your repo but I obviously didn't. I had already integrated in pancsf and it compiles ok. When loading however it reports it can't find mali-csffw.bin even though it is in /lib/firmware and further more it causes a hard crash when loading rather than just failing to load reporting the missing binary and moving on. How much testing have you done with your pancsf branch? Is it loading ok at least? I can try (and probably will) try to build with your branch shortly.
Thanks for the heads-up.
It does load the firmware just fine on the branch.
I'm sure it is something stupid I am doing wrong, but I cannot get your kernel to build as part of armbian. Using either of your config files in arch/arm64/configs I get various build errors. The latest I've been fighting with is build errors on the synopsys designware bridge HDMI drivers. They are required by the Rockchip HDMI drivers so you can't really turn them off. My Linux skills are a bit rusty. It has been several years since I was an active kernel developer. A lot has changed since then. That is why I'm sure it is my fault. Still working on it but for whatever reason it doesn't just work out of the box.
It's not a big deal but for curiosity's sake, why won't you add in the "ranges;" to the gic definition? Is GIC ITS working on your kernel without it? I've been running with it for a while with no issues. USB and PCIe appear to be working fine with no instability.
The only thing I can't get working is mali/pancsf. I'm still struggling with that a bit although a lot of my struggles are more with the Armbian build process. Getting it to put the mali fw in the initramfs has been quite a challenge.
As a final FYI, I can see others have been able to build your kernel but I have had issues with building it under Armbian for whatever reason. I'm sure it's my fault somehow but I've given up again. I have switch to 6.3.0-RC1 which is running on my Rock-5b again without pancsf support yet.
OK. As of this morning I have pancsf loading as a module on 6.3.0-RC1 using the Armbian build process. I think it was your latest changes in pancsf-midstream.
This is with lunar so that might not be the best choice for testing out mali/mesa but I sort of was trying to go for broke with the latest kernel and the latest ubuntu release. It all seems to be working well so far. Since I just got it working it needs a lot more testing. And of course I need to now figure out how to build mesa and try to load that. I will try first with lunar and if that seems problematic will switch back to jammy. Since this is all integrated under Armbian it is pretty straightforward now.
Phew!!!
I don't have ITS working right now, however I suspect that's precisely why PCIE works in my kernel. Rockchip's ITS implementation has a nasty bug that makes it incompatible with drivers that expect a standards-compliant ITS (it can only access the low 4GB address space, and is subject to address translation, which is very explicitly forbidden by ARM GIC specs). This is why I need to exclude regressions to PCIE support before I attempt to enable ITS.
As I said, PCIe does seem to be working. The Realtek 2.5Gb controller is on PCIe and that works fine.
On Mar 10, 2023, Googulator @.***> wrote:
I don't have ITS working right now, however I suspect that's precisely why PCIE works in my kernel. Rockchip's ITS implementation has a nasty bug that makes it incompatible with drivers that expect a standards-compliant ITS (it can only access the low 4GB address space, and is subject to address translation, which is very explicitly forbidden by ARM GIC specs). This is why I need to exclude regressions to PCIE support before I attempt to enable ITS.
-- Sent with K-@ Mail - the evolution of emailing.
of_translate_address fails to successfully lookup and translate the GIC-ITS addresses. I don't know if this is some new requirement for the newer kernels or what but it works with this addition.