Date: Tue, 19 May 2020 20:57:59 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "Marcin Wojtas" <mw@semihalf.com>, "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <86119565e5927716a9feebabcb611871@unrelenting.technology> In-Reply-To: <JXdx2L0dNn6BmD5KjF5iCCkc-z3xUH-gPmRZGiF4TCDESdw2lmPGWJNuOQWsxoE9Eumz8bFoXkrgr0rxkm9RCxCIw6fF3NrwSQFvsLtOSsY=@a9development.com> References: <JXdx2L0dNn6BmD5KjF5iCCkc-z3xUH-gPmRZGiF4TCDESdw2lmPGWJNuOQWsxoE9Eumz8bFoXkrgr0rxkm9RCxCIw6fF3NrwSQFvsLtOSsY=@a9development.com> <Ax3PRJg04l7bMoKmAlH13VNwNlBXYcDTSDYgnxJmZpTX5TQVgvpdQ_BNoqm136KK3iefGdUeCrvnOseWeRVUYK2Ly2n8Umio1yGAlg1ToU4=@a9development.com> <0012917d629a48e9fcd8589f4f002e1b@unrelenting.technology> <947c2f9bfaad823a2b104b8741502b40@unrelenting.technology> <c88780825e96fe583b32adf86416706e@unrelenting.technology> <d709b1aae3d33f49fadcce9817cb102a@unrelenting.technology> <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> <b04385d558850dc1dfa60fc398c9ac6c@unrelenting.technology> <CAPv3WKdyOzegfK4NJjKzXQTp9jGV9VkDRWxY%2BhDudzWQKkRfEQ@mail.gmail.com> <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
May 19, 2020 11:36 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wr= ote:=0A=0A>> Looking at NetBSD code, we might need to implement support f= or the custom NXP0016 config device:=0A>> =0A>> https://github.com/NetBSD= /src/commit/1a0fb037e62e4e3472966e33588957919b5e3a97=0A>> =0A>> I'll have= time to attempt a blind port of that code next week :D=0A>> =0A>> There = is a way to get any stock OS (even Windows!) to work with this PCIe contr= oller,=0A>> but it involves awful hacks and legacy interrupts, unacceptab= le stuff:=0A>> https://twitter.com/linux4kix/status/1260946442346205184= =0A>> =0A>> so you'll have to wait for now.=0A> =0A> I've waited this man= y months to finally get this far, another week is no problem :D=0A> =0A> = Would you be able to share any patches and kernconfs you're working from = so I have a frame of=0A> reference? My own dev skills are certainly nowhe= re near yours, but I'd like to at least read=0A> through the code you've = applied to get us this far and maybe even learn something new along the= =0A> way.=0A=0AMost of what got you "far" is upgrading the firmware to th= e latest dev versions! :)=0A=0AI have linked to the SDHCI commit on my gi= thub, from there you can just navigate to all commits:=0Ahttps://github.c= om/myfreeweb/freebsd/commits/master=0A=0AOnly SDHCI and I2C are relevant,= everything else is general stuff in my fork,=0Athere's some optimization= s pulled from phabricator, cleanup, minimal modular amd64 config,=0APixel= book devices, various other WIPs and unmerged patches, etc.=0A=0AThe chan= ges relevant to ARM64 in general are:=0Ahttps://reviews.freebsd.org/D2442= 3=0Ahttps://reviews.freebsd.org/D21017=0Ahttps://reviews.freebsd.org/D209= 74=0Ahttps://reviews.freebsd.org/D20835=0A=0AAnd what's not on github is = this (for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246552):=0A= =0A--- i/sys/arm64/arm64/machdep.c=0A+++ w/sys/arm64/arm64/machdep.c=0A@@= -1007,9 +1007,14 @@ bus_probe(void)=0A has_fdt =3D (OF_peer(0) != =3D 0);=0A #endif=0A #ifdef DEV_ACPI=0A- has_acpi =3D (acpi_find_ta= ble(ACPI_SIG_SPCR) !=3D 0);=0A+ has_acpi =3D true; // (acpi_find_ta= ble(ACPI_SIG_DSDT) !=3D 0);=0A #endif=0A=0A+ for (int i =3D 0; i < = 4; i++) {=0A+ printf("spcr %lu\n", acpi_find_table(ACPI_SIG_SPCR));= =0A+ printf("dsdt %lu\n", acpi_find_table(ACPI_SIG_DSDT));=0A+ = }=0A+=0A env =3D kern_getenv("kern.cfg.order");=0A if (en= v !=3D NULL) {=0A order =3D env;=0A=0Abut I'm not sure whe= ther it's necessary on your machine (please test without again!)=0Aand it= 's odd that I haven't seen these printfs in your logs..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86119565e5927716a9feebabcb611871>