Date: Sat, 30 May 2020 23:37:22 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: myfreeweb <greg@unrelenting.technology>, freebsd-arm@freebsd.org Subject: Re: rpi4-uefi.dev Re: RaspberryPi 4B 8G model not boot Message-ID: <83980CE0-276E-4DD9-B035-5ED2B561324B@googlemail.com> In-Reply-To: <20C49D55-9940-422F-9699-4C56CFCF281B@unrelenting.technology> References: <20200530.130909.120260481726933388.shigeru@os-hackers.jp> <D174CF68-09DC-48E0-A25A-321D2018908D@googlemail.com> <50DC156A-CA39-4809-85B7-02A5180DAB63@yahoo.com> <F3909CAB-488C-4315-ADFD-E769CD91C8B9@googlemail.com> <2DE76C92-8F4B-4658-94E4-FB7C7B7C6135@googlemail.com> <0AD80BEF-AA71-41F0-AD71-DF8516B790D9@yahoo.com> <67808784-29A6-4BC2-9B25-E31DE6DA862A@googlemail.com> <20C49D55-9940-422F-9699-4C56CFCF281B@unrelenting.technology>
index | next in thread | previous in thread | raw e-mail
> Am 30.05.2020 um 22:58 schrieb myfreeweb <greg@unrelenting.technology>: > > > > On May 30, 2020 7:46:37 PM UTC, "Klaus Küchemann via freebsd-arm" <freebsd-arm@freebsd.org> wrote: >> >> rpi4-uefi.dev has a stunning support-team(including@jmcneill of NetBSD and OpenBSD-hacker @kettenis ) >> and they are absolutely interested in FreeBSD and willing to help, >> but 1st we have to repair generic_xhci_acpi … >> looking closely into that file we will see that quite „nothing" is inside it :-) > > Yeah, there shouldn't be anything else in generic_xhci_acpi and there's nothing wrong with it. I was sure you will answer,, Hi and thanks for stepping in this discussion :-), .. O.K., why do we do an acpi-split if there’s nothing else than PNP0D10 in it ? NetBSD & OpenBSD don’t do that file-split , afaik > > Looks like the problem is that the PCIe controller isn't getting initialized, pcie isn`t exposed ( to the OS) in RPI4UEFI-dev , that’s what @AndrejWarkentin told us … And he told us what to do (in general, while not the easiest to understand ;-) > which is why xhci device memory is all 0xdead. The _INI or whatever ACPI method on that does the initialization probably isn't working correctly under FreeBSD. It does run, I have seen its debug message when I built an acpi_debug kernel. But it's not accomplishing its goal?? Maybe the memory regions it writes to aren't mapped correctly or something. Yep, look here(you’ve seen that already) : https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/AcpiTables/Xhci.asl#L118 ( attention : QWord ) > > Silly debug idea: log all memory access initiated by acpi in FreeBSD and NetBSD and compare :) > > Less silly idea: can someone who's really really familiar with FreeBSD's acpica integration take a look at the RPi4 dsdt already?? Please?? see: https://github.com/openbsd/src/blob/master/sys/dev/acpi/dsdt.c -- cutoff of an OpenBSD-file : xhci_acpi_parse_resources(int crsidx, union acpi_resource *crs, void *arg) { struct xhci_acpi_softc *sc = arg; int type = AML_CRSTYPE(crs); switch (type) { case LR_MEM32FIXED: /* XHCI registers are specified by the first resource. */ if (sc->sc_size == 0) { sc->sc_addr = crs->lr_m32fixed._bas; sc->sc_size = crs->lr_m32fixed._len; } break; case LR_QWORD: /* XHCI registers are specified by the first resource. */ if (sc->sc_size == 0) { sc->sc_addr = crs->lr_qword._min; sc->sc_size = crs->lr_qword._len; } break; case LR_EXTIRQ: sc->sc_irq = crs->lr_extirq.irq[0]; sc->sc_irq_flags = crs->lr_extirq.flags; break; } return 0; } !! the QWord-thing belongs to the RPI4 !! — to anticipate it: if we have solved this problem, we will probably end up on vfs_mountroot because the uSD driver is not recognized under acpi, afaik … Regardshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83980CE0-276E-4DD9-B035-5ED2B561324B>