On Fri 31 Dec 09:05 PST 2021, Bryan O'Donoghue wrote: > Hi. > > I've been poking a problem on an ipq6018 board I have. Specifically it > pertains to the address range for GPIO # 20, touching any address in the > range 0x14000 - 0x14FFC results in data-abort. > This problem exists on pretty much all Qualcomm platforms. > I initially encountered this with the upstream kernel here: > https://paste.debian.net/1225390/ > > and assumed that I was doing something wrong, so went hunting for evidence > that the downstream kernel touched the registers in that range, my > assumption that something extra was happening the downstream kernel to make > the register read kosher, turned out to be wrong, assuming something like > the transition from arm32 to arm64 or a trustzone setting getting in the > way. > > Downstream doesn't touch that register with the default drivers and shipping > DTS files. > Iirc the change that introduced this "regression" is 3edfb7bd76bd ("gpiolib: Show correct direction from the beginning"), which seems to have been introduced in 4.20. So any downstream older than that will typically boot just fine. But I believe cat /sys/kernel/debug/gpio will crash the system still. > Modifying the downstream kernel to do a simple read of each ctrl_reg makes > downstream choke on the address too. > > This is the only bootable version of the downstream kernel reading every > ctrl_reg in the range of gpio0 - gpio79 - skipping gpio20 since even > downstream the address range 0x14000 - 0x14FFC is broken. > > In other words I can prove the problem is only with the physical range > 0x01014000 - 0x01014FFC > > gpio19 @ 01013000 - 01013FFC is fine > gpio21 @ 01015000 - 01015FFC is fine > > the issue is limited to gpio20 @ 0x01014000 - 0x01014FFC > > Downstream kernel: > https://paste.debian.net/1225388/ > > This is also the case when doing a dumb dump in u-boot > Stock u-boot: > > https://paste.debian.net/1225389/ > https://paste.debian.net/1225396/ > > Is there a sku of this SoC which perhaps reserves 0x14000 - 0x14FFC or a > version of the firmware that does so ? > > I've already discussed this offline with Baruch who suggested firmware > versions based on previous feedback working with this part, however the > firmware version on the board is newer than what was suggested here > > https://lore.kernel.org/all/5ba36dcd7c50b640e0bdaf5b9c2248f3@xxxxxxxxxxxxxx/ > > "Please try with TZ version >= TZ.WNS.5.1-00084." > The reason for seeing this issue is typically that the pins are related to some I2C bus that is used for some secure application, i.e. they are reserved for TZ to use. As such I don't think you can use the >= comparator to determine if the firmware exposes you to this problem or not, because it will depend on if the particular release branch has such features enabled or not. > admin@OpenWrt:~$ cat /proc/device-tree/tz_version > CRM-TZ.WNS.5.1-00113 > admin@OpenWrt:~$ cat /proc/device-tree/tz_version > CRM-TZ.WNS.5.1-00113 > admin@OpenWrt:~$ cat /proc/device-tree/rpm_version > CRM-RPM.BF.2.4.1-00089 > admin@OpenWrt:~$ cat /proc/device-tree/boot_version > crm-ubuntu47-BOOT.XF.0.3-00090-IPQ60xxLZB-2 > > I'm not far off writing a patch based on a "compatible" string to mark gpio > # 20 as bad - any other ideas or insights welcome though. > Unfortunately I don't know how to determine the list of protected GPIOs, other than trial and error. But once you have the list, you can use "gpio-reserved-ranges" (a series of offset, count pairs) in the TLMM DT node to mark off these gpios as reserved. Regards, Bjorn
