For what it’s worth, I would also send you this link, as I experienced some of the same issues with my Rock 4 SE.
There are many “heavy” pages on Radxa that don’t lead anywhere, but through their github, I found this download page as well with these images. 
and if you want an extra image to your bookmark collection, here is openSUSE tumbleweed…
HCL:ROCK Pi 4 - openSUSE Wiki and Portal:Arm - openSUSE Wiki
It used to work in the past, but seems to have been broken with a recent U-Boot update: Rock 4 SE not booting - Rockchip - Armbian Community Forums
Looks like it was broken on purpose, but without fixing the information on the website: Rock 4SE: change uboot defconfig by lanefu · Pull Request #5612 · armbian/build · GitHub
There was a ROCK 4SE config added, but it looks like it results in another 4B-only build: build/config/boards/rock-4se.csc at f9c3b6ce3d68509767ef8a388ac8a6856b0deae8 · armbian/build · GitHub
At least the device tree is wrong and for the bootloader it looks wrong. But it is a different version with different DDR blob than the one for ROCK 4B, so maybe it does work.
I’ll do two thinkgs:
rock-4se-rk3399_defconfig and in case build a bootloader with this being used.Build is running: DietPi-Build · MichaIng/DietPi@682dfdb · GitHub
@webfinder42 would be great if you could test the image, which will be available in ~30 minutes here: Index of /downloads/images/testing
U-Boot TPL 2022.07-armbian (Feb 10 2024 - 01:23:47)
Channel 0: col error
Cap error!
Channel 1: col error
Cap error!
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
Noup. Still the same. I can see new bootloader date.
As on another path I was able to run radxa bullseye image and then upgrade installation to bookworm and even activate 6.5 kernel.
New build running with specific ROCK 4 SE bootloader: DietPi-Build · MichaIng/DietPi@f1fa83c · GitHub
Great, thanks for testing. I am not happy about the fact that we need to provide two dedicated images now, but at least it can be generated without much hassle: ROCK 4 | Fix support for ROCK 4 SE by MichaIng · Pull Request #6912 · MichaIng/DietPi · GitHub
Well… these are RK3399 vs RK3399-T chips, which seems like basically the same chip, but interestingly the description on memory support is what differentiates in datasheet, so probably memory initialization is a bit different. As all memory support (DDR3/DDR3L/DDR4 etc) and channels are all software configurable, it becomes a thing.
RK3399:
RK3399-T:
And sure enought it boots with 666Mhz memory:
DDR Version 1.30 20230417
In
soft reset
SRX
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0x13
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0x13
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0x13
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0x13
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 666MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 666MHZ, ctl_index 1
support 416 328 666 MHz, current 666MHz
OUT
U-Boot SPL 2023.10-rc2-armbian (Aug 22 2023 - 15:24:08 +0000)
Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE: BL31: v1.3(release):8f40012ab
NOTICE: BL31: Built : 14:20:53, Feb 16 2023
NOTICE: BL31: Rockchip release version: v1.1
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: plat_rockchip_pmu_init(1203): pd status 3e
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9
ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2023.10-rc2-armbian (Aug 22 2023 - 15:24:08 +0000)
SoC: Rockchip rk3399
Reset cause: RST
Model: Radxa ROCK Pi 4A
DRAM: 4 GiB (effective 3.9 GiB)
PMIC: RK808
Core: 288 devices, 30 uclasses, devicetree: separate
MMC: mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment
In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
Model: Radxa ROCK Pi 4A
Card did not respond to voltage select! : -110
Unable to get mmc desc
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
** Booting bootflow 'mmc@fe320000.bootdev.part_1' with script
303 bytes read in 5 ms (58.6 KiB/s)
29729280 bytes read in 1259 ms (22.5 MiB/s)
12706791 bytes read in 543 ms (22.3 MiB/s)
79666 bytes read in 13 ms (5.8 MiB/s)
Working FDT set to 1f00000
Moving Image from 0x2080000 to 0x2200000, end=3f00000
## Loading init Ramdisk from Legacy Image at 06000000 ...
-T runs on 1.5/1.0Ghz vs 1.8/1.4G on non-T. That seems all the diff I can see for now.
Two problems I quickly looked at :
root@DietPi:~# cat /proc/device-tree/model
Radxa ROCK Pi 4Aroot@DietPi:~#
In radxa fw it correctly reports as “Radxa ROCK 4SE”. We use this for device identification between Radxa, Orangepi, Raspberry
root@rock-4se:~# cat /proc/device-tree/model
Radxa ROCK 4SEroot@rock-4se:~#
Oh, I was expecting the “ROCK 4 SE” U-Boot build to define the “ROCK 4 SE” device tree as default, but obviously it does not. We need to set it in /boot/dietpiEnv.txt then, with the fdtfile= variable.
EDIT: Oh, the kernel/dtb package shipped by Armbian via their APT repo does not contain the ROCK 4 SE device tree yet. Probably it works when just updating the kernel. @janno can you test this:
cd /tmp
wget https://dietpi.com/downloads/binaries/linux-{image,dtb}-current-rockchip64.deb
dpkg -i linux-{image,dtb}-current-rockchip64.deb
rm linux-{image,dtb}-current-rockchip64.deb
reboot
If not, then after above:
G_CONFIG_INJECT 'fdtfile=' 'fdtfile=rockchip/rk3399-rock-4se.dtb' /boot/dietpiEnv.txt
reboot
I also just triggered a new image build with both above things done, but I am still curious whether the bootloader picks the correct device tree automatically, when it exists.
I haven’t encountered any booting issues with my current DietPi image; however, I had some challenges have with older Radxa images, particularly as Janno’s mentioned reinstallation of the Radxa firmware… as he posed the github link for the once that work.
I apologize for lack of clarity in my communication. 
Allow me to provide the specifications of my current setup using DietPi on the Rock 4 SE:
dietpi@cube2:~$ cat /proc/device-tree/model
Radxa ROCK Pi 4B
Do you still want to test https://dietpi.com/downloads/images/testing/DietPi_ROCK4SE-ARMv8-Bookworm.img.xz ?
It’s just a hunch, but it seems like Janno might be using a Rock Pi 4A. They seem to have success booting from RK3399 images but run into trouble with RK3399-T images.
I think i missed the comment that the new image is ready to use. I already sent all units out, but i need 2 more , so will buy them tomorrow and test it out.
I’m not running Rock4A. It’s clearly 4SE
Will check back soon.
Jep, we generated new images for ROCK 4 SE on particular, available on our download page on the ROCK 4 tile.
I downloaded the image from official link under download page and I can confirm that it reports now “Radxa ROCK 4SE” under device-tree. It still does report as 4A in uboot, but i don’t think thats an issue.
Now it also seems to run with correct clocks of 1Ghz/1.5Ghz. Before it was running same clocks as 4A (1.4Ghz/1.8Ghz, so we were kinda overlclocking it.
Great, thanks for testing and feedback. I guess U-Boot gives all ROCK 4 systems the same name, as they are all built with a generic ROCK 4 config: build/config/boards/rock-4se.csc at 40d9c0b6101cde3205661b86961dd3f78d307d63 · armbian/build · GitHub
The ROCK 4 SE specific U-Boot config is broken, respectively was half a year ago: Rock 4SE: change uboot defconfig by lanefu · Pull Request #5612 · armbian/build · GitHub
We could test an own U-Boot build with rock-4se-rk3399_defconfig being used, if you have time and mood. Probably it does work now. I don’t think there won’t be any real benefits, aside of probably some DHCP/TFTP boot cases, if something changed regarding the Ethernet adapters. But it would tell the correct device name at least 
.
Well , it’s fine by me to make tests. I have now total of 10 units as it’s usable device with thin linux.
Does onboard WiFi work for you? We have a case where it does not work: Onboard wifi not detected, no hotspot possible ROCK 4SE · Issue #6943 · MichaIng/DietPi · GitHub
Since the device tree defines the WiFi device, generally pretty similar to 4B, the only explanation I have is that it uses a different chip which has no driver in the kernel, or where it needs to be enabled explicitly. As the log in the linked issue does not contain any firmware loading error, I guess missing firmware is not the issue, but indeed no driver.
Are you refering to latest build?
I have already stated that wifi does not work in my prev post. I can retest it in next 24h if you think it’s changed.:
There seems to be two possible wifis on the SE https://github.com/MichaIng/DietPi/issues/6943#issuecomment-1975457184
At that time, you used the wrong device tree. Did you install the new kernel and enforce the correct device tree as I suggested here?
Sorry about that. I think i red your post as soon as you wrote it and later on my brain filtered edit out.
So testing it out:
Seems no go. I did step one and no wifi. After that step two, but it said it already existed.
If it’s not too much to ask , could the limit of “one embedded image per post” be removed so I don’t have to photoshop them all together.
Also one minor but kinda useful thing - on stock fw it has blue heartbeat led. It’s currently not lighting up or not doing anything to show that OS is booted.
I have the opposite here, led blinking but no wlan detected
