Yeah from what it looks like the 512MB patch adjusts the max / limits where these cleanups happen
it will take long time for openwrt to adopt 5.15 so it's really to check if newer kernel magically fix problems
(openwrt will first have to branch for a new stable version)
Think the only way is extent the BAR or reduce the allocation from the driver... But again could be that the space si actually not used at all.
Well, you can only change the DTS to extended the MEM space but I dont know if thats possible, no idea what memory after is used for
in ipq806x I had to modify the include in the generic target as there was a max set. (But the change was rejected)
Another thing to check would be if the mem size is correct... Could be that it was wrong from the start
Well, If I understand how ATF is assigning the memory then they are wasting a 1M of space as in the DTS size is set to 0xf00000 while ATF assigns 0x1000000
But for whatever reason ATF also assigns 2 more windows to PEX2 (The one I am using).
And those are quite large:
/* PEX2_X1 window */
{0x00000000f8000000, 0x1000000, PEX2_TID},
{0x00000000c0000000, 0x30000000, PEX2_TID},
{0x0000000800000000, 0x100000000, PEX2_TID},
You cant extend the range to even 0x1000000:
[ 1.092162] armada8k-pcie f2640000.pcie: host bridge /cp0/pcie@f2640000 ranges:
[ 1.104972] armada8k-pcie f2640000.pcie: MEM 0x0001000000..0x0001ffffff -> 0x00f8000000
[ 1.113462] armada8k-pcie f2640000.pcie: resource collision: [mem 0x01000000-0x01ffffff] conflicts with System RAM [mem 0x00000000-0x03ffffff]
[ 1.126298] armada8k-pcie f2640000.pcie: failed to initialize host: -12
[ 1.133007] armada8k-pcie: probe of f2640000.pcie failed with error -12
Any idea if we have some documentation to understand the available memory? (sorry for stupid question...)
I mean it would be good to understand if we are not just limited by the SoC
Not the public kind, I have the SoC specs and the datasheet but its really crypticly written no idea what 90% of it means
Wonder if it can be just as easy as searching the initial reg and check if there is some reference of where it does end.
If it only were that easy, there is nothing in the datasheet when searching for f8000000 which is the PCI MEM base.
Lets try IPQ4019 again
The strage thing is that the bar size set is ""very"" small... considering armada 8k have one of 128M
Yeah, like the old Armada 3k has 128M.
IPQ4019 has MEM mapped at 0x40200000, no idea whats actually after that as its not RAM.
Its part of the PCIe controller itself, so I dont know if it can be extended
Wonder if recent qsdk have different settings for the ranges
linux-msm hasnt changed, they only added a ipq4019-mhi.dtsi though
https://source.codeaurora.org/quic/cc-qrdk/oss/kernel/linux-msm/tree/arch/arm/boot/dts/qcom-ipq4019-mhi.dtsi?h=NHSS.QSDK.11.5
Oh, actually the ranges are different, its now 0x10000000 which is like 256M.
Now that cant be right
1 Like
The damn 0.... You get confused so easily
Yeah, but like how could it be 256M?
The DTS hasn't changed in ages
https://source.codeaurora.org/quic/cc-qrdk/oss/kernel/linux-msm/tree/arch/arm/boot/dts/qcom-ipq4019.dtsi?h=NHSS.QSDK.11.5#n425
Haha, changing it to the QSDK values works.
Now it assigns BAR-s and fails only on MSI vectors(Which I expected as it currently requires 32 of them but there is a patch set to only use one)
From what I notice in patches and all, the bar size is never set to the Max from the start but only to a sane value...
So if the OEM enlarges is we can be sure it won't be problematic.
Yeah, but not even the base address is the same
Ok that's strange lol...
Can anybody please post /etc/fw_env.config from AX3600 (maybe even AX6 if they have identical partitioning?) running on Robi's FW?
Somewhy I found myself to not have it on my firmware (so not able to switch the parttions) 