Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jul 2020 10:57:35 +0000
From:      Dan Kotowski <dan.kotowski@a9development.com>
To:        Dan Kotowski <dan.kotowski@a9development.com>
Cc:        "greg@unrelenting.technology" <greg@unrelenting.technology>, freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: FreeBSD on Layerscape/QorIQ LX2160X
Message-ID:  <Dbb0H9XmRRNwLZy0rCesyF4olNGVg9QM2ruZt5GTn5b82hxDK2_zttetcv5UlAPWjEigFZWBay2I08FATGLeJrDBbMpKh5mMpCOHWlDBslA=@a9development.com>
In-Reply-To: <HwL1YHc3qPA3Pzugqlg2GKfOfgbCXwCcLCIqkWf7MHrjxVZVTreIOIgcTa1NUW1oxWvnh99sKzczZPaAMMHfCZEPZkL7Zt9AlJ5GNizm_Zk=@a9development.com>
References:  =?us-ascii?Q?<82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej=5FPPtiv=5Fps9vROdUI529pKfxp4lbs=3D@a9development.com>_<kkodEYp=5F933GKBWBelm63luHcdDwaJ9WtfRtjVABbaYbQRXhH1W3w45T4PALvtMXXo6NNWbB7pgRdYZxJDNUHFKibY1FuHqIpPjiXZBAnxs=3D@a9development.com>_<NkmJNP=3D5FBMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7=3D5FVHb9=3D5FeTIMaLAIeAici=3D5Fqpz2UyIrBWzXR4mvE=3D3D@a9development.com>=5F<D2780D27-20F4-4706-9956-7E188AD73F62@unrelenting.technology>=5F<iIPsVK-flf-29Ti4agFHulCx5v1aEOVnPY6tyxErDGGxUlRvonYC7xCUGxHNgH64ZOpBLbwzAubg8gARrYPgd8qLOVfFk1PmcxSp0QNB=3D5Fjs=3D3D@a9development.com>=5F<BE2611FE-FC83-4E3D-9977-E502DE8537A7@unrelenting.technology>=5F<z-iiKTafA-iirmiH=3D5FwVWUM9BHEa9uhccyljIc5=3D5FbuK8CgCdzAXdUgQuViiaULImI0BVmx9N3lKO=3D5F9=3D5FNN9IHfSYCv1H9W9P8n98ltXG02MT4=3D3D@a9development.com>=5F<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_<A16FE19C-C34D-4100-9229-99FD098F8DE4@unrelenting.technology>_<aG=5FBP2g5oB3XsAIQof?= =?us-ascii?Q?WKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v=5F4RrmRWyPOtO6jQlAzE=3D@a9development.com>_<C4EFD0F3-FFD0-4789-B976-3DBA00395CCC@unrelenting.technology>_<8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology>_<a5b8fd2df391c4c4da914f5f425ef23f@unrelenting.technology>_<NjCT8lw8ervuOZE15IDG1EmZ0REgf1C9jafUcNgi7DG0Wt-OaynULhaEpdhAgrNmI8I81GjAEkC=5Fi4NiWRjwmsWp=5FFur4M-YyGtZfbkb7NQ=3D@a9development.com>_<HwL1YHc3qPA3Pzugqlg2GKfOfgbCXwCcLCIqkWf7MHrjxVZVTreIOIgcTa1NUW1oxWvnh99sKzczZPaAMMHfCZEPZkL7Zt9AlJ5GNizm=5FZk=3D@a9development.com>?=

next in thread | previous in thread | raw e-mail | index | archive | help

> > > > > What patches are we applying right now? I think some new builds w=
ould be good, including one with
> > > > > all the stuff we've fixed - like AHCI - but with the NXP PCIe cod=
e 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 imp=
rovements :)
> > > > >
> > > > > -   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/c1ea44aa33b29f74daed89eee8=
2b3dfeb105d376.patch
> > > > > If we haven't tried it + acpi_iort fix before, which is quite lik=
ely, maybe that's a combination
> > > > > that would work.
> > > > > (I remember when we tried it only, there was only the same interr=
upt problem as usual..)
> > > > > It's honestly kinda weird that "old" FW requires the custom contr=
oller 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/6cee1596c05e8a9ab64812444627b=
61c584ca6bc/sys/arm64/acpica/acpi_iort.c#L169
> > >
> >
> > Well, at least we're stable enough to buildworld and buildkernel on-sys=
tem! :partyparrot:
> > Waiting on a new SSD, but building on a USB uSD:
> >
> > > > > World build completed on Wed Jul 8 02:47:59 UTC 2020
> > > > > World built in 6897 seconds, ncpu: 16, make -j16
> >
> > Forgot to copy off the buildkernel time, but it was just under 900 seco=
nds.
> > Interestingly, we have real temp readouts from thermal zones, which is =
new. Did I add something back in that we had previously removed?
>
> Here's something:https://gist.github.com/agrajag9/11efe00514513100232999e=
0a9ec612c
>
> NVMe is working. It mapped an interrupt. I have no idea what changed to m=
ake this work other than compiling my own kernel. I applied the 7 patches a=
bove and added a bunch of my own debug printfs (dmesg.boot lines beginning =
with A9DEBUG), but it's the same POC ECAM firmware we've been using for a w=
hile. I'll test with the HBA later this week - it's currently in use elsehw=
ere in my homelab doing zfs send|receive things.

PCIe slot is confirmed working as well!

https://gist.github.com/agrajag9/9958d04d647fdddaf0d5865618f47130

@Marcin - any update on the fsl_sdhci driver rework you mentioned in May? I=
s the plan to keep the separate driver or merge it into the generic sdhci a=
nd use quirks? I dove in this past weekend comparing ours with NetBSDs and =
they're just using quirks.

https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021709.html

There's also a copy of the DSDT here with both onboard uSD and eMMC:

https://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platform=
s/tree/Platform/NXP/LX2160aRdbPkg/AcpiTables/Dsdt/Esdhc.asl?h=3DLX2160_UEFI=
_ACPI_EAR3



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Dbb0H9XmRRNwLZy0rCesyF4olNGVg9QM2ruZt5GTn5b82hxDK2_zttetcv5UlAPWjEigFZWBay2I08FATGLeJrDBbMpKh5mMpCOHWlDBslA=>