How to boot FreeBSD installed on the sd card on the Khadas Edge-V instead of Android

Phishfry said:
You can then boot to u-boot and from USB run the FreeBSD aarch64 installer memstick and install FreeBSD onto eMMC.
Click to expand...
I just tried this method and it seemed to work well.
I had u-boot on eMMC. I booted up to FreeBSD 14.3-RELEASE aarch64 memstick installer. No problem. Attached HDMI worked. bsdinstaller worked great.
mmcsd0 was target drive.
Big problem was it left no offset.
So it overwrote u-boot on MMC and started EFI Partition at sector 40.

I would think the FreeBSD installer for ARM64 would take that into account. Leave enough room for U-Boot or EDK2.
So you have to manually format your eMMC. That makes the installer just about useless.
 
So the next method is take a copy of the ROCKPRO64 image for FreeBSD14-3-RELEASE and use memdisk to load it. Then Flash my custom u-boot to md0. This wipes the ROCKPRO64 u-boot.
Unload md0 and rename image file to suit.
Then copy the modified image file to the usb installer p2 (you need to expand disk) and use u-boot on microSD because MMC is blanked and usb-booting is not supported here on rk3399...
Go to Live Mode of installer and then dd your modified disk image to eMMC.
 
This is what I did. I've exchanged these components (removed them from the KHADAS Edge and used the same components taken from my RockPro RK3399) :

a) the userland (with the panfrost driver enabled)
b) the kernel and the modules

What I haven't touched on FreeBSD 13.0 for the Edge is the boot and the dtb directories.

How much stable is a system like this ? Judge by yourself :

Ubuntu Pastebin

pastebin.ubuntu.com pastebin.ubuntu.com

You will see that the kernel that I'm using (14.2) does not accept some important kernel modules,such as :

1) hms.ko : I can't move the mouse
2) hcons.ko
3) hsctrl.ko
4) dwwdt.ko
5) hsctrl.ko

is able to reach the login prompt,but can't be used.

I have no idea about how to recompile the kernel and the world without using the patches used by the author of FreeBSD 13. Without that patches,how can I recompile a new kernel that can accept the kernel modules that you see above ?

I'm not sure that everything will work if I use the source code of FreeBSD 14.3 from the mainline....

Please help.
 
I did :

Code: 
# dd if=idbloader.img of=/dev/da7 seek=64 conv=sync
# dd if=u-boot.itb of=/dev/da7 seek=16384 bs=512 conv=sync

I hope that the warning at the beginning of the log file will disappear :

Code: 
WARNING: DTB version is 5.9 while kernel expects 6.4, please update the DTB in the ESP

Anyway I think that I should find a more updated dtb files for the KHADAS than the versions used by FreeBSD 13...
Where can I find them,I don't know. Here u can find the dtbs for Linux :

github.com

GitHub - khadas/khadas-linux-kernel-dt-overlays: khadas-linux-kernel-dt-overlays

khadas-linux-kernel-dt-overlays. Contribute to khadas/khadas-linux-kernel-dt-overlays development by creating an account on GitHub.
github.com github.com

but we are interested in FreeBSD....
 
When you created your custom u-boot port 'khadis-edge-v' the port also generates a DTB file for you.

find /usr/ports/sysutils/u-boot-khadis-edge-v -name "*.dtb"
 
Do you think that it will work if I try to upgrade FreeBSD 13.0 to 14.2 like this ?

Code: 
# freebsd-update upgrade -r 14.2
 
I don't think FreeBSD ARM was Tier One for FreeBSD 13.0-RELEASE but I don't think it could hurt to try. Remember you must update the ESP/EFI partition manually.

Worst come to worst you have to re-write image to card. Nothing lost.

I would go to 13.5-RELEASE then on to 14.x
 
The problem is it will take forever and same with source based updating. Compiling on ARM is unpleasant. Especially running off microSD card.
Consider installing 13.0 image onto USB drive. u-boot only on microSD. You can do that by deleting all partitions on microSD card with 13.0 image.. u-boot will remain in first 16M untouched.
Their FreeBSD 13.0 image does not use boot.scr does it ?? Is it MBR or EFI based?
 
Phishfry said:
The problem is it will take forever and same with source based updating. Compiling on ARM is unpleasant. Especially running off microSD card.
Click to expand...

I know,but there are solutions for this.

1) the covacat Silicon Arm machine is powerful enough
2) the Hertzner VPS server
3) Cross compiling ?

the problem is that I don't have the patches used by SleepWalker. He never replied to me. I never seen him here as well.

Their FreeBSD 13.0 image does not use boot.scr does it ?? Is it MBR or EFI based ?
Click to expand...

It does not use boot.scr. I think that Sleepwalker used his own patches...It is EFI based.
 
Burn FreeBSD 13.0 image to microSD and then delete all partitions.
gpart delete /dev/da0p2
gpart delete /dev/da0p1

Then burn FreeBSD 13.0 image to a USB memstick drive. See if it boots up. If it does try to burn FreeBSD 14.3-RELEASE ROCKPRO64 to a USB stick.
 
try to burn FreeBSD 14.3-RELEASE ROCKPRO64 to a USB stick.
Click to expand...

This is what I have already did :

Istantanea_2025-07-16_23-06-30.webp


my RockPro RK3399 = FreeBSD 14.2-RELEASE for ROCKPRO64 RK3399.

and anyway,neither a generic image file will work :

Istantanea_2025-07-16_23-08-52.webp

I think SleepWalker heavily patched FreeBSD 13.0 for the RockPro64 for the chipset RK3399 to make it compatible for the KHADAS Edge-V.

Anyway I read that he released the source code of FreeBSD 13 for the KHADAS. The problem is that it has been already patched. So what's the utiity of having an already patched code,if we want to upgrade it to a major version ? Don't the pathes will be lost during the upgrade ?
 
Code: 
# freebsd-update upgrade -r 13.5

WARNING : This system is running a "expert" kernel,which is not a kernel configuration distributed 
as part of FreeBSD 13.0-RELEASE. This kernel will not be updated : you MUST update it manually 
before running freebsd-update install.
 
I'm still working on the khadas project,trying to install FreeBSD 14.2 or 14.3 on this board. Today I tried to boot FreeBSD 14.2 that I'd installed on the RockPro RK3399 (with the panfrost driver enabled) as is,without modifications on the sd card da1 :

Code: 
=>       40  384503728  da1  GPT  (183G)
         40      32728       - free -  (16M)
      32768     102400    1  efi  (50M)
     135168  368209920    2  freebsd-ufs  (176G)
  368345088   16154624    3  freebsd-swap  (7.7G)
  384499712       4056       - free -  (2.0M)

Surprisingly,the booting went enough well and it reached the login. I see only a very annoying problem. Randomly,the screen starts to tremble. And for this reason,without fixing this behavior,it can't be used. This is what I would like to try :

a) to make a backup of the 16M bootloading partition
b) try to install the khadas bootloader (u-boot-khadas-edge-v) overwriting the rockpro bootloader

I'm not sure if this will work,but I can try. Instead,I can't do nothing if the trembling depends about the fact that the rockpro kernel needs of some patches that has been added by SleepWalker....
 
ZioMario said:
a) to make a backup of the 16M bootloading partition
Click to expand...
OK this is a good starting place. Covered here:
Phishfry said:
What you can do is 'capture' the u-boot from FreeBSD 13.0 image flashed to microSD and re-use it on newer FreeBSD.
Click to expand...
Don't worry about re-using it yet. Get a microSD booting to u-boot khadas version. No OS.
_martin said:
dd if=/dev/da0 of=uboot.img bs=512 count=32768
Click to expand...
So burn FreeBSD 13.0 that works to microSD with USB adapter. Then 'backup' bootloader with dd.
Then you have uboot.img for re-use. Then you put this image on a microSD card and get it booting to u-boot. No offset needed for 'restoring'. just dd to card.

It will contain a Partition Scheme that lives in first 40 sectors on GPT Table. 64 sectors on MBR. This will be leftover from FreeBSD 13.0 .
This leftover fragment may need to be dealt with using 'gpart destroy -F' to delete partiton table. U-boot has no need for the partition table.
I would ignore the partition error and focus on getting uboot up.
 
Phishfry said:
dd if=/dev/da0 | hexdump -C | grep RK
Click to expand...
Don't forget this post from above. After stripping off parts you can still verify u-boot is intact.

Address 8000 seems to vary some on different RK3399. I see 8800 address for 'RK' on Firefly. It is best to verify address before 'backup' from microSD.

Phishfry said:
You are looking for the bootloader with the text RKNS in the right hand panel.
Click to expand...
This is also variable. Some u-boot it is called RK33 (for RK3399) and I have seen RK35 for RK3568 u-boot.
The beginning of u-boot is this "RK" text from what I can tell.
 
What I did is the opposite. I've exchanged the kernel directory which belong to FreeBSD 14.2 for the RockPro with the kernel directory which belong to FreeBSD 13.0 for the Khadas board. And as I had suspected ,the screen does not flicker. The cause of the flickering is inside the kernel. We are stuck with the kernel 13.x patched by SleepWalker. Plus : now I have the kernel 13.0 + the userland of FreeBSD 14.2 and at a certain point this is what happens :

Untitled.jpg


I think that the latest kernel version which work is the 13.5. There is no way to use the kernel 14.x because on the 13.x we can use the patches already applied,but for the 14.x we can't.
 
I want to try an experiment. I want to install the UEFI Firmware on the KHADAS RK3399 board,instead of u-boot. My goal is the same. Try to see if I can fix the trembling of the screen. This is the content of the package :


Screenshot_2025-07-30_07-06-10.jpg


and this is the README file :

Code: 
# Rockchip RK3399 UEFI Firmware

Now with ACPI...and (almost working) USB!

## Flashing the UEFI firmware

  How to put this together? You need a GPT disk. SD card will be fine, or
  you can use rkdeveloptool to modify the eMMC.

  The start/end sectors are important!

    Number  Start (sector)    End (sector)  Size       Code  Name
       1              64            8063   3.9 MiB     FFFF  loader1   <-- Rk3399Pkg/Tools/Bin/idbloader.bin
       2            8064            8191   64.0 KiB    FFFF  reserved1
       3            8192           16383   4.0 MiB     FFFF  reserved2
       4           16384           24575   4.0 MiB     FFFF  loader2   <-- RK3399_SDK_UEFI.img
       5           24576           32767   4.0 MiB     FFFF  atf       <-- Rk3399Pkg/Tools/Bin/trust.img
       6           32768          262143   112.0 MiB   EF00  efi esp

I have a little sd card where I can write all the bootloaders and see how it goes. What I'm not sure of is how to do it :

Code: 
=>      40  62333872  da1  GPT  (30G)
        40     32728       - free -  (16M)
     32768    102400    1  efi  (50M)
    135168    524288    2  freebsd-swap  (256M)
    659456  61673472    3  freebsd-ufs  (29G)
  62332928       984       - free -  (492K)

To do something like this does not work :

Code: 
# dd if=idbloader.img of=/dev/da1
# dd if=RK3399_SDK_UEFI.img of=/dev/da1
# dd if=trust.img of=/dev/da1

This is what happens to the sd card after having issued those commands :

Code: 
=>      40  62333872  da1  GPT  (30G) [CORRUPT]
        40     32728       - free -  (16M)
     32768    102400    1  efi  (50M)
    135168    524288    2  freebsd-swap  (256M)
    659456  61673472    3  freebsd-ufs  (29G)
  62332928       984       - free -  (492K)

The sd card gets corrupted.

Can you give me some useful suggestion to understand how to proceed ? This kind of explanation :

How to put this together? You need a GPT disk. SD card will be fine, or you can use rkdeveloptool to modify the eMMC.
Click to expand...

is not enough explanatory for me. I don't know where to start.

Thanks.
 
Start with a wiped card instead of trying to shoehorn it to disk.

You need to use count
For example when you flash u-boot:

count=32768

Everything has to stack neatly.

The key dd options needed are bs (bitsector) and count/seek along with scr and dest.

ZioMario said:
# dd if=idbloader.img of=/dev/da1
# dd if=RK3399_SDK_UEFI.img of=/dev/da1
# dd if=trust.img of=/dev/da1
Click to expand...
This is the right path but you need seek= and bs=.
You just overwrote the same disk area three times. You need to OFFSET the writes with seek.

The first write offsets the MBR table with seek. For GPT you would seek=40
dd if=idbloader.img of=/dev/da1 seek=64 bs=512 conv=sync
 
Your instructions are a little bit vague for me,so I found this post :

ZioMario

Post in thread 'Pi Zero format boards that are supported.'

# fdisk /dev/sdj

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Comando (m per richiamare la guida): I

Enter script file name: uno

Created a new GPT disklabel (GUID: 07D2637F-2E74-11F0-832C-F1B721F986A1).
Created a new partition 1 of type 'Linux filesystem' and of size 10 MiB.
Created a new partition 2 of type 'Linux filesystem' and of size 5 MiB.
Created a new partition 3 of type 'EFI System' and of size 32 MiB.
Created a new partition 4 of type 'FreeBSD UFS' and of size 119 GiB...

that can help me. This is what I did in Linux with gparted :

Code: 
fdisk /dev/sdi
type O (capital letter o)
enter a filename to save
then q

This is the result :

Code: 
label: gpt
label-id: 6265BE94-368D-4AF4-B4B7-A866CF8B2CD9
device: /dev/sdi
unit: sectors
first-lba: 34
last-lba: 249737182
sector-size: 512

and this is what I have added,following the logic :

Code: 
/dev/sdi1 : start=       64, size=   8063, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="loader1"
/dev/sdi2 : start=     8064, size=   8191, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="reserved1"
/dev/sdi3 : start=     8192, size=  16383, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="reserved2"
/dev/sdi4 : start=    16384, size=  24575, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="loader2"
/dev/sdi5 : start=    24576, size=  32767, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="atf"
/dev/sdi6 : start=    32768, size= 262143, type=7, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="efi esp"

it should be good,except for the type. I've used type= 7,but the README says that I should use CODE = FFFF and EF00.
ok. If CODE should be FFFF,type = ? if CODE should be EF00,type = ?

very thanks.
 
Code: 
label: gpt
label-id: 6265BE94-368D-4AF4-B4B7-A866CF8B2CD9
device: /dev/sdi
unit: sectors
first-lba: 34
last-lba: 249737182
sector-size: 512

/dev/sdi1 : start=       64, size=   8063, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="loader1"

/dev/sdi2 : start=     8064, size=   8191, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="reserved1"

/dev/sdi3 : start=     8192, size=  16383, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="reserved2"

/dev/sdi4 : start=    16384, size=  24575, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="loader2"

/dev/sdi5 : start=    24576, size=  32767, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="atf"

/dev/sdi6 : start=    32768, size= 262143, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=07D35DA3-2E74-11F0-832C-F1B721F986A1, name="efi esp"

# fdisk /dev/sdi 

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m per richiamare la guida): I

Enter script file name: layout

Created a new GPT disklabel (GUID: 6265BE94-368D-4AF4-B4B7-A866CF8B2CD9).
Created a new partition 1 of type 'Linux filesystem' and of size 3.9 MiB.
Sector 8064 already used.
Failed to apply script layout
Resetting fdisk!
 
ZioMario said:
and this is what I have added,following the logic :
Click to expand...
All that looks fine but I am back to the same nitpick. Why do you need EFI partition for UEFI-EDK2. You do not need it.

Get the microSD card booting with just UEFI-EDK2 bits. Strip the problem back to the basics.

Once you have a microSD card that boots to UEFI-EDK2 you can use any ARM64 USB memstick and bootup.
 
Phishfry said:
All that looks fine
Click to expand...

it does not seem to me. I get this error :

Sector 8064 already used.

but I am back to the same nitpick. Why do you need EFI partition for UEFI-EDK2. You do not need it.

Get the microSD card booting with just UEFI-EDK2 bits. Strip the problem back to the basics.

Once you have a microSD card that boots to UEFI-EDK2 you can use any ARM64 USB memstick and bootup.
Click to expand...

Sorry. I don't understand you ; I don't understand what I should I do.
 
you have the sizes wrong (have to subtract start from end)
this is the correct data
1 64 8000
2 8064 128
3 8192 8192
4 16384 8192
5 24576 8192
6 32768 229376

this is pos/start/size and start and size are in sectors
 
You must log in or register to reply here.
Back
Top