Date: Mon, 06 Jul 2020 17:00:22 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <a5b8fd2df391c4c4da914f5f425ef23f@unrelenting.technology> In-Reply-To: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> References: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> <kkodEYp_933GKBWBelm63luHcdDwaJ9WtfRtjVABbaYbQRXhH1W3w45T4PALvtMXXo6NNWbB7pgRdYZxJDNUHFKibY1FuHqIpPjiXZBAnxs=@a9development.com> <NkmJNP=5FBMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7=5FVHb9=5FeTIMaLAIeAici=5Fqpz2UyIrBWzXR4mvE=3D@a9development.com>_<D2780D27-20F4-4706-9956-7E188AD73F62@unrelenting.technology>_<iIPsVK-flf-29Ti4agFHulCx5v1aEOVnPY6tyxErDGGxUlRvonYC7xCUGxHNgH64ZOpBLbwzAubg8gARrYPgd8qLOVfFk1PmcxSp0QNB=5Fjs=3D@a9development.com>_<BE2611FE-FC83-4E3D-9977-E502DE8537A7@unrelenting.technology>_<z-iiKTafA-iirmiH=5FwVWUM9BHEa9uhccyljIc5=5FbuK8CgCdzAXdUgQuViiaULImI0BVmx9N3lKO=5F9=5FNN9IHfSYCv1H9W9P8n98ltXG02MT4=3D@a9development.com>_<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> <I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=@a9development.com> <A16FE19C-C34D-4100-9229-99FD098F8DE4@unrelenting.technology> <aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=@a9development.com> <C4EFD0F3-FFD0-4789-B976-3DBA00395CCC@unrelenting.technology> <8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
July 6, 2020 7:07 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wrote: >> In the old firmware, under the Root Complex Nodes, `Output reference: 0x30` points to the ITS Node >> with node offset 0x30. >> Then in the new firmware, under the Root Copmlex Nodes, `Output reference: 0x48` points to the SMMU >> with node offset 0x48. >> Is this what you meant when you said everything is "behind the SMMU"? >> >> Yes. >> >> What patches are we applying right now? I think some new builds would be good, including one with >> all the stuff we've fixed - like AHCI - but with the NXP PCIe code so I can test on the old >> firmware. If I'm keeping track correctly, this includes: >> >> - D20835: enable tagged pointers >> - D20974: Port sbsawdt drive from NetBSD >> - D21017: armv8crypto: add AES-XTS support >> - D24423: arm/pmu: add ACPI attachment, more FDT names >> >> These are not directly related to running on NXP, just random improvements :) >> >> - D25145: acpi_resource: support multiple IRQs >> - D25157: ahci_generic: add quirk for NXP0004 >> - D25179: acpi_iort: fix mapping end calculation >> >> Yes, these three. >> >> Here's the pci_layerscape patch: >> >> https://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b3dfeb105d376.patch >> >> If we haven't tried it + acpi_iort fix before, which is quite likely, maybe that's a combination >> that would work. >> (I remember when we tried it only, there was only the same interrupt problem as usual..) >> >> It's honestly kinda weird that "old" FW requires the custom controller access while "new" FW >> requires not doing it >_< > > Any tips on where to add verbosity to dmesg during boot? You had a handful of extras in there to > print things things from the IORT. That thing is here: https://github.com/freebsd/freebsd/blob/6cee1596c05e8a9ab64812444627b61c584ca6bc/sys/arm64/acpica/acpi_iort.c#L169 > Also seeing that NVMe hangs in nvme_ctrlr_start_config_hook, > maybe we want to add some verbosity to sys/dev/nvme/nvme_ctrlr.c to see what it's waiting for? We know it's an interrupt.. everything is waiting for an interrupt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a5b8fd2df391c4c4da914f5f425ef23f>