Re: KHADAS EDGE V booting hangs if I install UEFI instead of u-boot

--> No FreeBSD kernel work has been done for the "Edge V Khadas Rockchip
RK3399" as far as I can see. No sysutils/u-boot-* work has been done for
such either.

I may be wrong,but sleepwalker did it until FreeBSD 13. For this reason I'm
trying to upgrade it to 14.x
He has also released the UEFI-RK3399 files here :

https://personalbsd.org/download/UEFI-RK3399/

Why should I not hope that they will also work on the KHADAS ? Because it
is also based on RK3399.

And what I'm trying to do to remove the trembling, is to install that
version of UEFI (it says that it almost works,not that it does not work at
all) instead of the u-boot used by the official FreeBSD version for the
RockPro64.

I'm trying to update FreeBSD 13 to 14.2,but the procedure is failing. At
the moment I don't have a clear idea about the reason(s) :

root@khadas-edge:/usr/local/etc/pkg/repos # freebsd-update fetch

Looking up update.FreeBSD.org mirrors... 3 mirrors found.

Fetching metadata signature for 13.0-RELEASE from update1.freebsd.org...
done.
Fetching metadata index... done.

Fetching 1 metadata files... failed.

root@khadas-edge:/usr/local/etc/pkg/repos # freebsd-update upgrade -r 14.2

Looking up update.FreeBSD.org mirrors... 3 mirrors found.

Fetching metadata signature for 13.0-RELEASE from update2.freebsd.org...
done.
Fetching metadata index... done.

Fetching 1 metadata files... failed.

Some suggestions to offer ?


On Fri, Aug 8, 2025 at 11:05 PM Mark Millard <marklmi@yahoo.com> wrote:

> On Aug 8, 2025, at 12:42, Mario Marietto <marietto2008@gmail.com> wrote:
>
> > >with the fully working 13.0 FreeBSD running on the KHADAS board is
> beyond your abilities? Getting the file content to pastebin is beyond your
> abilities ?
> >
> > Enabling the panfrost driver on FreeBSD 13 goes beyond your abilities. I
> can do "sysctl hw.clock >somefile.txt. But without the pan frost
> enabled,you could confound the log messages ? What is causing what ?
>
> Ahh. Got it.
>
> > >This is a problem in the uefi firmware. You need to look into the uefi
> code base.
> >
> > ok,but why doesn't it happen when I boot FreeBSD 14.2 on the RockPro64 ?
> In my experiments I'm using the same kernel and userland for RockPro64 and
> Khadas.
>
> SOC support is not sufficient for board support
> generally. DeviceTrees and U-Boot instances and
> EDK2 instances are normally board specific in
> various ways.
>
> A list of some RK3399 (SOC) based boards:
>
> Edge V Khadas Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Edge Khadas Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Ficus 96boards Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Firefly-RK3399 Firefly Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Leez P720 Lenovo Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Nano Pi M4 FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Nano Pi M4 (2 GB) FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Nano Pi M4 B FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Nano Pi Neo4 FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Nano Pi R4S FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> NanoPC-T4 FriendlyElec Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Orange Pi rk3399 Xunlong Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Pinebook Pro Pine64 Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> RK3399 EVB Rockchip Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROC-RK3399-PC Firefly Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROCK 4 SE Radxa Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROCK 4B Radxa Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROCK 4C Radxa Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROCK 4C+ Radxa Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> Rock960 96boards Rockchip RK3399 ARM Cortex A72/A53 (armv8)
> ROCKPro64 Pine64 Rockchip RK3399 ARM Cortex A72/A53 (armv8)
>
> To expect all those to work well based on just ROCKPRo64
> materials would be an incorrect expectation, as I
> understand. To expect that just substituting a different
> .dtb file would be sufficient need not be a correct
> expectation either.
>
> There are different sysutils/u-boot-*'s for various of
> those (those that have/had official FreeBSD support):
>
> u-boot-firefly-rk3399
> u-boot-nanopi-r4s
> u-boot-pinebookpro
> u-boot-rockpro64
>
> (Other RK3399 based boards have no official FreeBSD
> support, up to any errors I made forming the above
> list.)
>
> Some of those 4 likely had kernel work done as
> well to handle material in the matching upstream
> linux .dtb file that was not common with the other
> 3, not just u-boot creations. After all that work,
> all 4 are supported (for whatever aspects are
> supported). But earlier than that such support
> as exists was unlikely to be automatic, as I
> understand. (FreeBSD normally does not try to
> provide an EDK2 instance or analogous. So examples
> are uncommon.)
>
> EDK2 builds are also normally board specific,
> even for the same SOC. And EDK2/DeviceTree
> builds have all the same DeviceTree issues
> that U-Boot EFI/DeviceTree builds do for
> how automatic support is (or is not).
>
> It is true that for EDK2/ACPI, if the EDK2/ACPI
> exists, it may be more likely for FreeBSD to
> already support as much as the EDK2/ACPI
> supports. But EDK2/ACPI likely supports less
> than the DeviceTree contexts allow. (Closer
> to what Servers are likely to support.)
>
> Device Trees tend to have board specific
> content that is not in common with other boards
> for the same SOC. DeviceTrees do not provide
> an executable abstraction. They provide a
> description of what is present vs. not. It
> takes work adding support for all the
> combinations of things to the kernel before
> the range of things covered grows.
>
> No FreeBSD kernel work has been done for the "Edge
> V Khadas Rockchip RK3399" as far as I can see. No
> sysutils/u-boot-* work has been done for such
> either. Nor has FreeBSD provided an EDK2/ACPI.
>
> Even the EDK2/ACPI on github for the Edge
> V Khadas Rockchip RK3399 that you referenced
> reported that its USB support was not yet
> working, as I remember. Development apparently
> stopped before that was completed.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Mario.