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>
index | next in thread | previous in thread | raw e-mail
May 19, 2020 11:36 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wrote: >> Looking at NetBSD code, we might need to implement support for the custom NXP0016 config device: >> >> https://github.com/NetBSD/src/commit/1a0fb037e62e4e3472966e33588957919b5e3a97 >> >> I'll have time to attempt a blind port of that code next week :D >> >> There is a way to get any stock OS (even Windows!) to work with this PCIe controller, >> but it involves awful hacks and legacy interrupts, unacceptable stuff: >> https://twitter.com/linux4kix/status/1260946442346205184 >> >> so you'll have to wait for now. > > I've waited this many months to finally get this far, another week is no problem :D > > Would you be able to share any patches and kernconfs you're working from so I have a frame of > reference? My own dev skills are certainly nowhere near yours, but I'd like to at least read > through the code you've applied to get us this far and maybe even learn something new along the > way. Most of what got you "far" is upgrading the firmware to the latest dev versions! :) I have linked to the SDHCI commit on my github, from there you can just navigate to all commits: https://github.com/myfreeweb/freebsd/commits/master Only SDHCI and I2C are relevant, everything else is general stuff in my fork, there's some optimizations pulled from phabricator, cleanup, minimal modular amd64 config, Pixelbook devices, various other WIPs and unmerged patches, etc. The changes relevant to ARM64 in general are: https://reviews.freebsd.org/D24423 https://reviews.freebsd.org/D21017 https://reviews.freebsd.org/D20974 https://reviews.freebsd.org/D20835 And what's not on github is this (for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552): --- i/sys/arm64/arm64/machdep.c +++ w/sys/arm64/arm64/machdep.c @@ -1007,9 +1007,14 @@ bus_probe(void) has_fdt = (OF_peer(0) != 0); #endif #ifdef DEV_ACPI - has_acpi = (acpi_find_table(ACPI_SIG_SPCR) != 0); + has_acpi = true; // (acpi_find_table(ACPI_SIG_DSDT) != 0); #endif + for (int i = 0; i < 4; i++) { + printf("spcr %lu\n", acpi_find_table(ACPI_SIG_SPCR)); + printf("dsdt %lu\n", acpi_find_table(ACPI_SIG_DSDT)); + } + env = kern_getenv("kern.cfg.order"); if (env != NULL) { order = env; but I'm not sure whether it's necessary on your machine (please test without again!) and it's odd that I haven't seen these printfs in your logs..help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86119565e5927716a9feebabcb611871>