Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 May 2020 14:14:28 +0000
From:      Robert Crowston <crowston@protonmail.com>
To:        myfreeweb <greg@unrelenting.technology>
Cc:        =?UTF-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: rpi4-uefi.dev  Re: RaspberryPi 4B 8G model not boot
Message-ID:  <D0paXIwfCujmpp_O4lxNga4qaTaL9IUPZipaaYopip3F8rjx42RXMIt84VYttOWLCgG9-noiBoHG8zPMc5z3gflITvzXR_2GW52eJhI--kM=@protonmail.com>
In-Reply-To: <53680CD3-4FE9-42C9-A534-416A71263A08@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> <83980CE0-276E-4DD9-B035-5ED2B561324B@googlemail.com> <53680CD3-4FE9-42C9-A534-416A71263A08@unrelenting.technology>

next in thread | previous in thread | raw e-mail | index | archive | help
> pcie isn`t exposed ( to the OS) in RPI4UEFI-dev , that=E2=80=99s what @An=
drejWarkentin told us =E2=80=A6

Something about this doesn't make sense, because there is a PCI-E driver fo=
r OpenBSD that was written specifically for the Rpi4 UEFI.



=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, 31 May 2020 01:49, myfreeweb <greg@unrelenting.technology> wrote=
:

>
>
> On May 30, 2020 9:37:22 PM UTC, "Klaus K=C3=BCchemann"maciphone2@googlema=
il.com wrote:
>
> > .. O.K., why do we do an acpi-split if there=E2=80=99s nothing else tha=
n PNP0D10 in it ?
> > NetBSD & OpenBSD don=E2=80=99t do that file-split , afaik
>
> They don't have driver inheritance. We do, so the usual pattern for devic=
es available with both acpi and fdt is to have them inherit from a common d=
river that doesn't attach.
>
> > > Looks like the problem is that the PCIe controller isn't getting init=
ialized,
> > > 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 under=
stand ;-)
>
> Yep. Something has to initialize the actual controller though, that's wha=
t _INI does. So the OS runs the AML bytecode and initializes PCIe without e=
ven knowing PCIe exists.
>
> I'll maybe look into this again soon.
>
> > ( attention : QWord )
> > cutoff of an OpenBSD-file :
> > xhci_acpi_parse_resources
>
> That looks like just OpenBSD weirdness, the resources should be handled b=
y generic acpi code.
>
> > 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, af=
aik
>
> Screw uSD, I just put the OS on a USB stick and only the firmware on uSD.
>
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"





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