Attempting to install on RPi4B w/ UEFI, having some problems
Mark Millard
marklmi at yahoo.com
Fri Sep 11 23:00:34 UTC 2020
On 2020-Sep-11, at 14:14, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
> Lol :-)
>
>>
>>
>>>>
>> On 2020-Sep-11, at 04:42, Robert Clausecker <fuz at fuz.su> wrote:
>>>
>>> The Wiki page (arm/Raspberry Pi) does say explicitly:
>>>
>>>> RPI4-UEFI, allows us to triple-boot FreeBSD on the RPi4 from either
>>>> Device Tree or ACPI or ACPI&Device-tree(both).
>
>> Am 11.09.2020 um 20:25 schrieb Mark Millard via freebsd-arm <freebsd-arm at 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.
>
> Mark, you joker :-) lol Ha Ha
>
> I assume you know the RP4-Wiki-page is maintained by me and
> I assume that (from my last knowledge)
> NOBODY is implementing anything for RPI4-UEFI-dev- compatibility
> at the moment (except GregV who’s work was published by me in the Wiki).
> While not everybody knows that it’s a dev`s Wiki and not a release-information-website for working environments
> 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’s 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
> 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’t even boot to the root-prompt in FreeBSD in ACPI-mode.
> Again: the Wiki ISN`T a user’s support-site for working environments but I’m happy if it expands
> 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) .
>
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} == rpi4
PLAT= rpi4
PLAT_ARCH= AARCH64
PLAT_ARGS= -D X64EMU_ENABLE=FALSE -D CAPSULE_ENABLE=FALSE
PLAT_TARGET= RELEASE
PLATFILE= Platform/RaspberryPi/RPi4/RPi4.dsc
PLAT_RESULT= RPi4/${PLAT_TARGET}_GCC5/FV/RPI_EFI.fd
PLAT_FILENAME= 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):
• This firmware was built from the official EDK2 repository, with the following extra patch applied:
• 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.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list