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>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 30.05.2020 um 22:58 schrieb myfreeweb = <greg@unrelenting.technology>: >=20 >=20 >=20 > On May 30, 2020 7:46:37 PM UTC, "Klaus K=C3=BCchemann via freebsd-arm" = <freebsd-arm@freebsd.org> wrote: >>=20 >> 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 =E2=80=A6 >> looking closely into that file we will see that quite =E2=80=9Enothing"= is inside it :-) >=20 > 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 :-),=20 .. O.K., why do we do an acpi-split if there=E2=80=99s nothing else than = PNP0D10 in it ?=20 NetBSD & OpenBSD don=E2=80=99t do that file-split , afaik >=20 > Looks like the problem is that the PCIe controller isn't getting = initialized, pcie isn`t exposed ( to the OS) in RPI4UEFI-dev , that=E2=80=99s what = @AndrejWarkentin told us =E2=80=A6 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=E2=80=99ve seen that already) : = https://github.com/tianocore/edk2-platforms/blob/master/Platform/Raspberry= Pi/AcpiTables/Xhci.asl#L118 ( attention : QWord ) >=20 > Silly debug idea: log all memory access initiated by acpi in FreeBSD = and NetBSD and compare :) >=20 > 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 =3D arg; int type =3D AML_CRSTYPE(crs); switch (type) { case LR_MEM32FIXED: /* XHCI registers are specified by the first resource. = */ if (sc->sc_size =3D=3D 0) { sc->sc_addr =3D crs->lr_m32fixed._bas; sc->sc_size =3D crs->lr_m32fixed._len; } break; case LR_QWORD: /* XHCI registers are specified by the first resource. = */ if (sc->sc_size =3D=3D 0) { sc->sc_addr =3D crs->lr_qword._min; sc->sc_size =3D crs->lr_qword._len; } break; case LR_EXTIRQ: sc->sc_irq =3D crs->lr_extirq.irq[0]; sc->sc_irq_flags =3D crs->lr_extirq.flags; break; } return 0; } !! the QWord-thing belongs to the RPI4 !! =E2=80=94 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 =E2=80=A6 Regards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83980CE0-276E-4DD9-B035-5ED2B561324B>