Pi Zero format boards that are supported.

Well RC2 does not have the files from the patch. I just checked the source tree under /usr/ports/sysutils/u-boot-radxa-zero3/work/u-boot-2025.07-rc2/drivers/video/rockchip/
.

Code:
Kconfig
Makefile
rk3288_hdmi.c
rk3288_mipi.c
rk3288_vop.c
rk3328_hdmi.c
rk3328_vop.c
rk3399_hdmi.c
rk3399_mipi.c
rk3399_vop.c
rk_edp.c
rk_hdmi.c
rk_hdmi.h
rk_lvds.c
rk_mipi.c
rk_mipi.h
rk_vop.c
dw_mipi_dsi_rockchip.c
 
OK Lets get started.

Move to u-boot ports MASTER directory for fixup.
cd /usr/ports/sysutils/u-boot-master

You need to remove the current distfile. It may be empty already if you have not compiled any u-boot ports.
rm distinfo

Edit the u-boot-master ports Makefile and 'Comment Out' one line and Add Another New Line. I used the next blank line @132

Starting at Line127 are the u-boot variables:

The relevant lines
Line 131 Comment Out
Code:
#UBOOT_VERSION?=    2025.04
DISTVERSION = 2025.07-rc2

So what I doing here is comment out UBOOT_VERSION and I add a line for DISTVERSION.

cd /usr/ports/sysutils/u-boot-radxa-zero3

So now you create checksum.
make makesum

I suggest downloading packages for all the dependencies.
make build-depends-list | cut -c 12- | xargs pkg install -A -y

Now you are ready to build your Zero3 u-boot port.
make install or make reinstall.
If you previously installed from packages or ports run make reinstall.

If successful you will have a file here:
/usr/ports/distfiles/u-boot/
And now you will have your own custom uboot work directory to harvest.

I haven't been lucky :


PS :

I had to comment this line to make it work :

#PORTVERSION= ${UBOOT_VERSION}

It says that I should pick only one between PORTVERSION or DISTVERSION and I picked the second.
 
I've installed Linux on the sd card that I have placed on the Radxa 3W and as you can see below,the HDMI signal works perfectly at 720x720 :

This_WhatsApp Image 2025-05-17 at 09.27.33.jpeg


This is how looks like the sd card where I have installed Linux :

Code:
=>       34  500006845  da1  GPT  (238G)
         34      32734       - free -  (16M)
      32768      32768    1  ms-basic-data  (16M)
      65536     614400    2  efi  (300M)
     679936  499326943    3  efi  (238G)

I would like to know into which partition the bootloaders are installed on ? Maybe from 34 to 32734 free (16M) ? Can I extract the code that's stored there,making an img file that I will reinstall on the sd card where I have installed FreeBSD ? How can I do this ? That free / 16M space is not properly a partition,in fact the first partition starts with /dev/da1p1 - ms-basic-data ; so I have no idea about how I can produce an image file from there. Please help me.

Instead,this is the sd card where I have installed FreeBSD 14.3-STABLE,where the HDMI works good only on my large monitor (1920x1080),but not on the 720x720 little display :

Code:
=>       40  249737136  da2  GPT  (119G)
         40         24       - free -  (12K)
         64      16320    1  linux-data  (8.0M)
      16384      16384    2  linux-data  (8.0M)
      32768      98304       - free -  (48M)
     131072      65536    3  efi  (32M)
     196608  249540568    4  freebsd-ufs  (119G)

In this case the (broken) bootloader is stored there ? ---> 32768 98304 - free - (48M)

So,what we should to ? copy this :

Code:
34      32734       - free -  (16M)

to this :

Code:
32768      98304       - free -  (48M)

? How ?
 
Let's take the sd card where is installed Ubuntu. It becomes :

free - (16M) : don't touch it ;
p1) ms-basic-data (16M) ; ---> (8.0M)
p2) efi (300M) ; ---> (8.0M)
free - (48M) : don't touch it ;
p3) efi (32M)
p4) freebsd-ufs

using gparted on Linux :

p1) reduction from ms-basic-data 16M to 8.0M
p2) reduction from efi (300M) to 8.0M
free - (48M) : don't touch it ;
p3) add efi (32M)

On the FreeBSD sd card :

dd if=/dev/da2p1 of=linux-data-da2p1
dd if=/dev/da2p2 of=linux-data-da2p2

p4) add freebsd-ufs until the end of the sd card
 
I used Quarterly for my package settings.

Why are you resizing partition p1, p2? Why two EFI directories?

I dont think the bootloader can be at that 48M Free Space address.

I like to use this for a verifying. Look at disk structure. At address 8000 you must start rockchip bootloader. It shows up as text "RKNS"

dd if=/dev/da0 | hexdump -C | more

Code:
00008000  52 4b 4e 53 00 00 00 00  80 01 02 00 01 00 00 00  |RKNS............|
 
A patch from January is still not in u-boot RELEASE. That is pretty lame unless it is broken. The RK356X is probably 4 years old now.
 
What I wonder about is the U-Boot support for HDMI enough for FreeBSD to "Just Work" with HDMI output or does it need some support too?

I should mention HDMI signaling is quite complex in the background with i2c used for handshaking.
 
So is that when Linux is kicking in the HDMI display. When they fire up the FB it detects HDMI or something like that...

What about rockchip MIPI/DSI displays. I see support in u-boot for them. What makes them work over Framebuffer? Would that 'just work' on FreeBSD? (with proper DTB and Device Tree Bindings)
 
I used Quarterly for my package settings.

I have compiled the source code of U-boot and of the radxa bootloaders on FreeBSD 14.2-RELEASE with latest packages and I've got some compilation errors. But you are using quarterly and you didn't get them. So nice.

Why are you resizing partition p1, p2? Why two EFI directories ?

because,let's give a look at this partition scheme. Inside this sd card I have installed FreeBSD 14.3-Stable and the HDMI works good on my big monitor. So,I don't want to change too much this layout.

Code:
=>       40  249737136  da1  GPT  (119G)
         40         24       - free -  (12K)
         64      16320    1  linux-data  (8.0M)
      16384      16384    2  linux-data  (8.0M)
      32768      98304       - free -  (48M)
     131072      65536    3  efi  (32M)
     196608  249540568    4  freebsd-ufs  (119G)

at the same time,give a look at this partition scheme,used by Ubuntu 24.04 installed on the sd card. In this case the HDMI works good even on my little display with 720x720 resolution. So,I want to take this layout as a secure layout,the layout that works for sure and I want to preserve the space of the sd card where is stored the bootloader code. I don't care of the rest :

Code:
=>       34  500006845  da2  GPT  (238G)
         34      32734       - free -  (16M)
      32768      32768    1  ms-basic-data  (16M)
      65536     614400    2  efi  (300M)
     679936  499326943    3  efi  (238G)

The idea here is to do something like this :

a) with gparted on linux,reduce ms-basic-data (16M) to 8M and efi from 300M to 8M
b) dd if=/dev/da1p1 of=linux-data-1.img ;
c) dd if=/dev/da1p2 of=linux-data-2.img ;
d) dd if=linux-data-1.img of=/dev/da2p1 : the idea is to be able to perfectly overwrite the old partition because they have the same size...
e) dd if=linux-data-2.img of=/dev/da2p2 : same as d

in this way Im also able to preserve this space ----> "34 32734 - free - (16M)" on /dev/da2

Consider that the sd card where is installed FreeBSD where the HDMI works on my big monitor should have 4 partitions. They are hardcoded inside the bootloader installed at the beginning of the sd card. I'm not able to modify this setting.
To do this I should study the E2DK code of Jared mc neil and it's a mess....:

 
So is that when Linux is kicking in the HDMI display. When they fire up the FB it detects HDMI or something like that...

What about rockchip MIPI/DSI displays. I see support in u-boot for them. What makes them work over Framebuffer? Would that 'just work' on FreeBSD? (with proper DTB and Device Tree Bindings)

I know nothing about the MIPI/DSI display and how to configure it. I can't do anything on this area because it is too advanced for me.
 
I've grabbed two log files that I have attached here.

The log called "log-big-monitor" comes from the monitor that I'm using right now at 1920x1080 resolution connected to the RadXA 3w via HDMI. HDMI works great there.

The log called "log-720 x 720-display" comes from the HDMI / 4x4 inches display that I've bought to use with the smartphone that I want to create.

I've installed xfce4 on FreeBSD 14.3-Stable on that display,but it goes round and round like a carousel.

From the log you will see that it thinks that the display is 1280x720 (720p) and that is wrong and will likely cause the display to not understand what it gets delivered…

Someone should tweak EDK2 to use a 720x720 resolution. I don't have the skills to do this. Can someone alter the resolution that's embedded inside the code ?

The EDK2 code is here : https://github.com/jaredmcneill/quartz64_uefi
 

Attachments

Hello bro.

can you give a look at this ?


now I know what's wrong with the code that's used for making work the HDMI on the Radxa 3W. The very experienced dudes here at the FreeBSD forums helped me a lot.

Now I know what's wrong and I need to hire a C programmer who can write or fix what's missing. I'm actively looking for someone who wants to be hired,but for the moment no one replied. Unfortunately I'm not a programmer. I will continue asking.

Or,the part that's missing or broken on the Jared code can be found on the code that has been written for the driver which works for Linux,because the HDMI on Linux works perfectly on my 720x720 display.

But I have no idea where I can get the ED2K code for the Radxa 3W which works for Linux. And even if I find it,I'm not able to integrate the part of the code that works inside the Jared code.

Are you a C programmer ?
 
But I have no idea where I can get the ED2K code for the Radxa 3W which works for Linux. And even if I find it,I'm not able to integrate the part of the code that works inside the Jared code.
Jared has another branch inside his repository that was added roughly 12 months ago. github username: "Man0rwymn" or something like that. They added source code to Jareds tree for Zero3W.

So if you want to consult the expert instead of throwing offers around then find out who github helper was and ply him with an offer. Maybe its out of their league. I don't know that github offers the developers email or contact info. But that is where I would start. Trying to use quartz64/other boards UEFI will only go so far. SO like I asked earlier.
Contact this person and ask for the binary of their work. This means a ready to use bootrom. Not source code. They will probably be happy to provide it. Then ask about your screen size dilemma.
Many developers don't want money but sending them hardware sure would help. If you send them money then they are committed. It is no longer fun but a job. Just my opinion here.

No I am not a programmer of any kind of software.
 
If you cannot track down the helper just contact Jared himself and ask for contact info or to pass on the request.
Tell him you need a compiled bootrom for Rock Zero3E just like his releases for Quartz and ROC boards.
Perhaps he knows something about screen sizes.
 
Jared has another branch inside his repository that was added roughly 12 months ago. github username: "Man0rwymn" or something like that. They added source code to Jareds tree for Zero3W.

Can you share the full name of the repository ? I'm not able to find it. I don't see evidences for "Man0rwymn" ; maybe you wrote it not correctly....
 
If you cannot track down the helper just contact Jared himself and ask for contact info or to pass on the request.
Tell him you need a compiled bootrom for Rock Zero3E just like his releases for Quartz and ROC boards.
Perhaps he knows something about screen sizes.

Jared does not offer help for his code since years (it seems 2023). Give a look at his github. I've created a bug request,but I doubt he will reply in a reasonable amount of time. Not easy to find his active email address. Low chances to get a reply.
 
Phishfry and T-Aoki : Looking inside the Jared's code,are you able to tell me if a display with a different resolution,something like this one :


is accepted without the needing to modify a single bit of it ? I'm thinking that maybe I will spend less money buying it than asking to a developer to modify the code.
 
TL;DR
I have no experience with Rasberry Pi including Pi Zero and not at all know about Jared code. But assuming it's about X11 and the display provides proper EDID via HDMI and Pi Zero's HDMI port properly passes obtained EDID data to the driver, it would be (hopefully) handled properly.
 
TL;DR
I have no experience with Rasberry Pi including Pi Zero and not at all know about Jared code. But assuming it's about X11 and the display provides proper EDID via HDMI and Pi Zero's HDMI port properly passes obtained EDID data to the driver, it would be (hopefully) handled properly.

I'm not sure that it will work. I mean,at 720x720 it does not work,so there is an high chance that it does not work even at 960x544.

Anyway,the answer is inside the "STATIC HDMI_DISPLAY_TIMING mDefaultTimings" that's stored inside the code below :


 
Back
Top
OSZAR »