Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Sep 2020 16:00:29 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Klaus Cucinauomo <maciphone2@googlemail.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Attempting to install on RPi4B w/ UEFI, having some problems
Message-ID:  <F5C5D292-0935-412E-883D-BB03378683DD@yahoo.com>
In-Reply-To: <C258C039-27BF-4D02-BA56-988CD9CCA535@googlemail.com>
References:  <20200910201146.GA99827@fuz.su> <0E3AD53C-AA47-491B-B1C3-931C559CDC10@yahoo.com> <20200911114214.GA56507@fuz.su> <9E14D44F-2F16-486E-ACFB-EC189A345D5B@yahoo.com> <C258C039-27BF-4D02-BA56-988CD9CCA535@googlemail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 2020-Sep-11, at 14:14, Klaus Cucinauomo <maciphone2 at =
googlemail.com> wrote:

> Lol :-)=20
>=20
>>=20
>>=20
>>>>=20
>> On 2020-Sep-11, at 04:42, Robert Clausecker <fuz at fuz.su> wrote:
>>>=20
>>> The Wiki page (arm/Raspberry Pi) does say explicitly:
>>>=20
>>>> RPI4-UEFI, allows us to triple-boot FreeBSD on the RPi4 from either
>>>> Device Tree or ACPI or ACPI&Device-tree(both).=20
>=20
>> Am 11.09.2020 um 20:25 schrieb Mark Millard via freebsd-arm =
<freebsd-arm@freebsd.org>:
>> Ahh. I do not expect that the Wiki is being maintained by
>> someone involved in implementing such things. So somewhat
>> more guess work is involved in the WIki's production.=20
>=20
> Mark, you joker :-) lol Ha Ha=20
>=20
> I assume you know the RP4-Wiki-page is maintained by me and=20
> I assume that (from my last knowledge)=20
> NOBODY is implementing anything for RPI4-UEFI-dev- compatibility=20
> at the moment (except GregV who=E2=80=99s work was published by me in =
the Wiki).=20
> While not everybody knows that it=E2=80=99s a dev`s Wiki and not a =
release-information-website for working environments=20
> and user-support, it should be clear that things being in =
development(or not) are NOT marked as production ready in the Wiki.
> Aarch64 will hold it=E2=80=99s Tier2-status in Fbsd 13, so many devs =
are busy on Tier1 or other platforms & things.
> I know since months that RPI-UEFI-dev has a triple boot-option and =
that=20
> A lot oft things(including the kernel hang if booted(it boots!) in =
DeviceTree mode) DO NOT WORK.
> At the time I wrote about rpi4-uefi-dev  RPI4-UEFI-dev didn=E2=80=99t =
even boot to the root-prompt in FreeBSD in ACPI-mode.
> Again: the Wiki ISN`T a user=E2=80=99s support-site for working =
environments but I=E2=80=99m happy if it expands=20
> it`s popularity for all kind of users/devs, for everybody. (in best =
case people who want to help in developing or even of course in =
extending the Wiki) .
>=20

My note is nothing against you. For example: I've no clue if
FeeBSD has any example context of a supported/somewhat-working
ACPI+DTB context for any tier level system. I do know that
FreeBSD has various examples of ACPI support (no DTB) and
various examples of u-boot based DTB support (no ACPI). I've
no implementation knowledge that would indicate the status
for ACPI+DTB.

In other words: If I were editing such text I'd also be
guessing the intended vs actual status.

As for uefi/ACPI for the RPi4: It may well stay limited
to things that happen to work currently, not adding device
types or other such: The edk2 side of things does not have
the full responsibility for enabling things. I do know that
sysutils/edk2 was created that has in its Makefile :

.if ${FLAVOR} =3D=3D rpi4
PLAT=3D           rpi4
PLAT_ARCH=3D      AARCH64
PLAT_ARGS=3D      -D X64EMU_ENABLE=3DFALSE -D CAPSULE_ENABLE=3DFALSE
PLAT_TARGET=3D    RELEASE
PLATFILE=3D       Platform/RaspberryPi/RPi4/RPi4.dsc
PLAT_RESULT=3D    RPi4/${PLAT_TARGET}_GCC5/FV/RPI_EFI.fd
PLAT_FILENAME=3D  RPI_EFI.fd
.endif

so someone might experiment with port-based edk2 uefi builds.

But pftf/RPi4 is no longer strictly based on just edk2 (and
some Raspberry Pi firmware files of sufficient vintage):

	=E2=80=A2 This firmware was built from the official EDK2 =
repository, with the following extra patch applied:

		=E2=80=A2 =
0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch, so that =
the Graphical console is set as default.

It also looks messy to try to use sysutils/edk2 to pick out
the same edk2 materials as used in an a specific pftf/RPi4
release (ignoring the patch issue). A local distinfo update
would appear to be needed and the content to be substituted
would have to be researched.

(There would seem to be a similar status for each of:
macchiatobin and rpi3 . If I understand right, the
uefi/ACPI's in use with FreeBSD on MACCHIATObin Double
Shots are not based on pure edk2 materials: edk2 has some
linux biases in its implementation for the MACCHIATObin's.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F5C5D292-0935-412E-883D-BB03378683DD>