Date: Sat, 12 Sep 2020 03:23:57 +0200 From: Klaus Cucinauomo <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org Subject: Re: Attempting to install on RPi4B w/ UEFI, having some problems Message-ID: <D98391E8-0AC1-4D95-836C-FEF6BB7AA991@googlemail.com> In-Reply-To: <F5C5D292-0935-412E-883D-BB03378683DD@yahoo.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> <F5C5D292-0935-412E-883D-BB03378683DD@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 12.09.2020 um 01:00 schrieb Mark Millard <marklmi@yahoo.com>: >=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=E2=80=A6. No problem, Mark, although being just lower class Tier2-people here :-) = , we work pretty well together and get amazing results =E2=80=A6. https://www.freebsd.org/platforms/ = https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/arch= s.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=20 sentence 500 times a day:=20 "Tier2: get out of my face and do it yourself"."=20 .. just kidding..=20 > the status > for ACPI+DTB. For rpi4-uefi-dev:=20 =E2=80=9ETier 3: get out of my =E2=80=A6=E2=80=9C ;-) >=20 > In other words: If I were editing such text I'd also be > guessing the intended vs actual status. >=20 > 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 : >=20 > .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 >=20 > so someone might experiment with port-based edk2 uefi builds. >=20 > But pftf/RPi4 is no longer strictly based on just edk2 (and > some Raspberry Pi firmware files of sufficient vintage): >=20 > =E2=80=A2 This firmware was built from the official EDK2 = repository, with the following extra patch applied: >=20 > =E2=80=A2 = 0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch, so that = the Graphical console is set as default. >=20 > 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 =E2=80=9Ebooted=E2=80=9C 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 =E2=80=9Emyfreeweb=E2=80=9C-GregV. While in this case you would be right if you tell me, that the following = is just a =E2=80=9Eguess=E2=80=9C : I guess you can completely forget and ignore the edkII in sysutils.. = while I=E2=80=99m only guessing(guessing is now my favorite term ;-) : It=E2=80=99s probably just a bulk-import of edkII without any intention = to target and support RPI4=E2=80=A6 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D98391E8-0AC1-4D95-836C-FEF6BB7AA991>