On 31 October 2016 at 22:56, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > On 10/31/2016 02:46 PM, Scott Branden wrote: >> A problem with reintroducing this change is that all imprecise data >> aborts are ignored, not just PCI. So if you don't actually use PCI in >> your system and want to debug other aborts you are unable to. I don't >> know if we care about such situation. > > Considering that any abort is pretty much fatal, the options are: > > - update the freaking bootloader to a version where there are no such > aborts generated, not an option on consumer devices, unclear which > version (if any) fixes that > > - fixups the aborts externally, via a boot wrapper, which is going to > take some time to develop, causes additional burden on the distributors > to provide instructions/build images on how to do it In practice updating bootloader is not possible (as you noticed) but I don't think it's even possible to fix this problem at bootloader / extra loader level. If this was a matter of hardware setup, we could handle it in kernel as well I believe. Ray actually verified it's controller limitation on Northstar platform. It sounds a bit like you're thinking about MMU and Dcache Northstar problem when writing that e-mail. > - fixups the aborts in the kernel, irrespective of where they come from, > simple and easy > > - fixups the aborts in the kernel, look where they come from, by using > some bit of magic, looking at PCIe registers and whatnot (provided that > is even possible), not too hard, but can take a while, and is error prone > > I can certainly advocate that option 3 is the one that gives a working > device, and this is what matters from a distribution perspective like > LEDE/OpenWrt. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
