Re: Attempting to install on RPi4B w/ UEFI, having some problems

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 <[email protected]>:
>> 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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"