On 10.02.2020 20:41, Li Yang wrote: > On Mon, Feb 10, 2020 at 9:32 AM Olof Johansson wrote: >> >> On Mon, Feb 10, 2020 at 4:23 PM Russell King - ARM Linux admin >> wrote: >>> >>> On Mon, Feb 10, 2020 at 04:12:30PM +0100, Olof Johansson wrote: >>>> On Thu, Feb 6, 2020 at 11:57 AM Z.q. Hou wrote: >>>>> >>>>> Hi Olof, >>>>> >>>>> Thanks a lot for your comments! >>>>> And sorry for my delay respond! >>>> >>>> Actually, they apply with only minor conflicts on top of current -next. >>>> >>>> Bjorn, any chance we can get you to pick these up pretty soon? They >>>> enable full use of a promising ARM developer system, the SolidRun >>>> HoneyComb, and would be quite valuable for me and others to be able to >>>> use with mainline or -next without any additional patches applied -- >>>> which this patchset achieves. >>>> >>>> I know there are pending revisions based on feedback. I'll leave it up >>>> to you and others to determine if that can be done with incremental >>>> patches on top, or if it should be fixed before the initial patchset >>>> is applied. But all in all, it's holding up adaption by me and surely >>>> others of a very interesting platform -- I'm looking to replace my >>>> aging MacchiatoBin with one of these and would need PCIe/NVMe to work >>>> before I do. >>> >>> If you're going to be using NVMe, make sure you use a power-fail safe >>> version; I've already had one instance where ext4 failed to mount >>> because of a corrupted journal using an XPG SX8200 after the Honeycomb >>> Serror'd, and then I powered it down after a few hours before later >>> booting it back up. >>> >>> EXT4-fs (nvme0n1p2): INFO: recovery required on readonly filesystem >>> EXT4-fs (nvme0n1p2): write access will be enabled during recovery >>> JBD2: journal transaction 80849 on nvme0n1p2-8 is corrupt. >>> EXT4-fs (nvme0n1p2): error loading journal >> >> Hmm, using btrfs on mine, not sure if the exposure is similar or not. >> >> Do you know if the SErr was due to a known issue and/or if it's >> something that's fixed in production silicon? >> >> (I still can't enable SMMU since across a warm reboot it fails >> *completely*, with nothing coming up and working. NXP folks, you >> listening? :) > > This is a known issue about DPAA2 MC bus not working well with SMMU > based IO mapping. Adding Laurentiu to the chain who has been looking > into this issue. Yes, I'm closely following the issue. I actually have a workaround (attached) but haven't submitted as it will probably raise a lot of eyebrows. In the mean time I'm following some discussions [1][2][3] on the iommu list which seem to try to tackle what appears to be a similar issue but with framebuffers. My hope is that we will be able to leverage whatever turns out. In the mean time, can you try the workaround Leo suggested? [1] https://patchwork.kernel.org/patch/11327667/ [2] https://patchwork.kernel.org/patch/10967729/ [3] https://patchwork.kernel.org/cover/11279577/ --- Best Regards, Laurentiu