Pi Zero format boards that are supported.

Rockchip DRM will be an asset. Right now all you have is scfb driver for ARM X11 video. Rockchip DRM is like i915drm. It provides drivers to on chip vid accel functions.

So you can use what is built into chip for video driver. More than one video stream possible. Sizes to 4K etc....

I know. But if without DRM works decently I could buy it anyway,waiting for future improvements.
 
HDMI does not work that I know of on Rock 3. I tried alot of RK3568 boards...

It might just be a matter of an overlay. I really did not dig too deep.

I encourage you to try the Zero 3E. For the price it is very powerful. I have not tried Zero3E HDMI since -CURRENT at beginning of year.
 
On 2022 it worked...

Screenshot_2025-04-19_16-19-59.jpg
 
These posts are related to EDK2 UEFI BIOS and not u-boot.

There is a EDK2 UEFI for Rock Zero 3W. It might work on Zero 3E I dunno.

HDMI does work with EDK2 UEFI
 
It actually brings ACPI features in so that is a good thing.

But the negative is you need a different BIOS for every board (just like u-boot).

The support for the EDK2 UEFI on RK356x is not as great as the RK3588 work.

So this is EDK2 for RK356x.

Compared to RK3588 EDK2

I wish there were binaries for the Rock Zero3W. I would like to test it.
The build tree gave me problems.
 
He is the down and dirty. If you try and build the RK356x/Raxda Rock3W github by the instructions it fails.

The problem is the stuff is linked to the upstream EDK2 repository and there was an issue there but fixed. The RK356x repository points to the old version that is broke.
It was fixed and the project needs to rebase. I am not git aware.

Notice the last commit was 11 months ago. It was broke 4 months ago when I tried.

This is Mr. Jared ONeils repository and then a new person was added. (github user:Manawyrm)
They also did the work for the last board added. The Raxda Zero3W.

So maybe you could bug them and get us a binary to test. I wanted to build a board profile for Raxda Rock Zero3E but couldnt even build for Zero3W. Not as easy as I thought.

Heck I should have made a github issue to say it is broken. I am bashful and ignorant. It may be me....
 
Bro,what do you suggest me more to buy between the Radxa ZERO 2 Pro and the Radxa ZERO 3W ? Where are the best chances that the HDMI works between the two ?
 
what do you suggest me more to buy between the Radxa ZERO 2 Pro
This is AMLogic based CPU and will not work.

and the Radxa ZERO 3W
Not supported but could work. Depends what services you need.

Where are the best chances that the HDMI works between the two ?
I can't answer that. 0% for both? I think you could try OpenBSD where they have RockchipDRM driver already. They are in a more advanced state on Rock boards.
 
This is AMLogic based CPU and will not work.


Not supported but could work. Depends what services you need.


I can't answer that. 0% for both? I think you could try OpenBSD where they have RockchipDRM driver already. They are in a more advanced state on Rock boards.

Even if FreeBSD does not support DRM,the display can still turn on ?
 
If you used RK3399 it would. HDMI enabled there not on RK356x. I don't know the details why.
Obviously u-boot has something to do with it. No yello submarine - uboot logo on HDMI screen like RK3399.
But EDK2 works on RK356x with HDMI......
 
what do you think about this one :


it is based on the chipset RK3399...so the HDMI should work I presume...

NanoPi R4S​



Removing the ETH ports we have a slim profile....to connect to the net I will use an adapter from USB to ETH.
 
Hello.

I've just got my Radxa 3W board to my home and I've immediately tried to boot the image that you gave me by attaching it to my default HDMI large monitor. Yeah,it is recognized. Unfortunately the image is not usable. I get a kernel panic. Can you help me to make it usable ?
I have no idea about the reasons why it does not reach the prompt.

Senza titolo.jpeg


The error is : "no usable event timer found". Is there a fix for this bug that I can apply ?
 
I've immediately tried to boot the image that you gave me
Not me? Perhaps you mean a link to a post I provided where Soran posted his 14.2-STABLE work on eqos ethernet driver.
From your screenshot that is my best guess.

Did you flash the Zero3W u-boot to the sd-card? This is a must do with any FreeBSD Arm image. Flash the appropriate u-boot.

For example yesterday I downloaded FreeBSD 14.3-STABLE for aarch64 to test on Zero3E. I used the ROCKPRO image and flashed it to microsd-card.
Then I flash u-boot to it.
You must build u-boot on FreeBSD or use some other ROCK3W u-boot and flash it to microSD card. Including the dtb file as well on EFI.

That is how FreeBSD ARM64 images work.
 
I'm having serious troubles by configuring the resolution for the smaller display (720x720) that I want to use for the FreeBSD phone that I'm trying to build. The display is flickering. I think that it "thinks" that it is 1280x720 (720p) and that is wrong and will likely cause the display to not understand what it gets delivered…
 
I was looking at some really long/narrow HDMI screens for a dashboard and I as worried about resolutions supported by scfb.

Are your troubles on command line or X11?
 
Back to u-boot topic... Didn't we chat about getting binaries for ZERO3W for UEFI EDK2 booting? Did you ever contact that github developer?

UEFI EDK2 bootrom with 14.3 stable would be a good approach for HDMI working. There are a few clocks missing on RK356X but it seems usable.

I can provide instructions for building a custom FreeBSD port for zero3w u-boot if you want. That second best behind EDK2. Not that hard.

Using Armbian you delete the Linux Partition and you are left with u-boot on sd-card. Debian provides some flashable binaries. This method is least desirable.
They are looking for linux kernel so you can change the env and then saveenv.
 
Have you tried telling loader what to use?

/boot/loader.conf
kern.vt.fb.default_mode="720x720"

I did that,but nothing is changed. FreeBSD seems not involved in setting up the display mode on these chips, its all done in the EDK2 bootloader.

Just setting the mode hard in the EDK2 config did not help apparently.

The code in EDK2 should be studied to figure out what can be done to pick up the resolution correctly which apparently might be an issue, of hardwire things for this exact display.

All the Linux/Raspi info is nice but does not apply in anyway to FreeBSD/EDK2…

I can provide instructions for building a custom FreeBSD port for zero3w u-boot if you want. That second best behind EDK2. Not that hard.
Using Armbian you delete the Linux Partition and you are left with u-boot on sd-card. Debian provides some flashable binaries.
This method is least desirable. They are looking for linux kernel so you can change the env and then saveenv.

ok. Let's try this route. I've installed ubuntu jammy that I've got from here :


on the sd card,that now looks like this :

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

Instead,this is the sd card where I have installed FreeBSD 14.2 :

Code:
=>     40  2097072  da2  GPT  (119G) [CORRUPT]
       40       24       - free -  (12K)
       64    16320    1  linux-data  (8.0M) ---> p1
    16384    16384    2  linux-data  (8.0M) ---> p2
    32768    98304       - free -  (48M)
   131072    65536    3  efi  (32M) ---> p3
   196608  1900504    4  freebsd-ufs  (928M) ---> p4

If I have understood well what u want to do,I should do :

Code:
dd if=/dev/da1p3 of=/dev/da2p3

that's right ? help me to understand what to do. Very thanks.
 
What I would use is gpart delete to delete all partitions. You might want to mount ms-basic-data partition and scrape Zero3W DTB out before deleting everything.

Code:
gpart delete -i1 /dev/da1
gpart delete -i2 /dev/da1
gpart delete -i3 /dev/da1
You can keep the Partition Table if GPT scheme is OK.
The "free 16M" you have marked as P1 is actually where the bootloader resides. That is what you are trying to preserve.

Next recreate your FreeBSD disk structure...
Make sure you don't overwrite u-boot. You need to offset the first partition.
gpart add -t fat32 -s 50M -b 32768 da1

An alternative method is to dd just Ububtu Jammy u-boot sectors to file. Then use rockpro64 image and flash your captured u-boot to it.
 
This time da2 is the disk recognized as the disk where I have installed Ubuntu Jammy for the Radxa. This is the starting partition table :

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)

this is what I did :

Code:
marietto# gpart delete -i1 /dev/da2
da2p1 deleted

marietto# gpart delete -i2 /dev/da2
da2p2 deleted

marietto# gpart delete -i3 /dev/da2
da2p3 deleted

Now,this is how looks like the disk structure after the previous commands :

Code:
=>       34  500006845  da2  GPT  (238G)
         34  500006845       - free -  (238G)

and now,I have issued the final command :

Code:
marietto# gpart add -t fat32 -s 50M -b 32768 da2
gpart: Invalid argument
 
Back
Top