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

> Am 12.09.2020 um 01:00 schrieb Mark Millard <[email protected]>:
> 
> 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….

No problem, Mark, although being just lower class  Tier2-people here :-) , we work pretty well together and get amazing results ….

https://www.freebsd.org/platforms/
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html
Although boring study it's extremely important to compare Tier 1 to Tier 2 .
My friend from the Netherlands in the Fbsd-forums has broken his hand from writing the same 
sentence 500 times a day: 
"Tier2: get out of my face and do it yourself"." 
.. just kidding.. 


> the status
> for ACPI+DTB.

For rpi4-uefi-dev: 
„Tier 3: get out of my …“  ;-)

> 
> 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.

Rpi4-uefi -dev „booted“  FreeBSD from the first day on without writing one line of code in Fbsd-src and without using any sysutils..
(booted means: into Last stage[https://www.freebsd.org/doc/handbook/boot-introduction.html] ) .. and than it was hanging..
The ONLY line of code ever written in fbsd specially for RPI4-UEFI-compat is the patches of „myfreeweb“-GregV.
While in this case you would be right if you tell me, that the following is just a „guess“ :
I guess you can completely forget and ignore the edkII in sysutils.. while I’m only guessing(guessing is now my favorite term ;-)  :
It’s probably just a bulk-import of edkII without any intention to target and support  RPI4…
I did NEVER guess in the Wiki(only I do this one guess here  and  only once) :-)

Since I personally will not support rpi4-uefi-dev by code or administration and I would be more interested in supporting RPI4-u-boot- fdt (if finding the time),
I leave this discussion and would suggested that you, Mark, team up with Robert Clausecker(if he is interested in) & others
to research and support this topic for the future. Good luck !

For readers not familiar with it: RPI4-uefi-dev is a cool project with great programmers which are  extremely friendly and responsive,
but the project is totally unsupported by FreeBSD for now.

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