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

Thanks @[email protected] <[email protected]> : but I don't have the
knowledge to do it.

On Sat, Aug 9, 2025 at 2:27 PM Kamal R. Prasad <[email protected]> wrote:

> The error is in uefi firmware based on nature of input ie kernel image
> given to it. You need to investigate why uefi did not like the image.
>
> Thanks
> -kamal
>
>
> On Sat, 9 Aug 2025, 04:53 Mario Marietto, <[email protected]> wrote:
>
>> --> 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 <[email protected]> wrote:
>>
>>> On Aug 8, 2025, at 12:42, Mario Marietto <[email protected]> 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.
>>
>

-- 
Mario.