February 7, 2022

Orange Pi 4 (Rockchip 3399) rkdeveloptool

I run it (see notes below on building it) and get:
Help:			-h or --help
Version:		-v or --version
ListDevice:		ld
DownloadBoot:		db 
UpgradeLoader:		ul 
ReadLBA:		rl    
WriteLBA:		wl   
WriteLBA:		wlx   
WriteGPT:		gpt 
WriteParameter:		prm 
PrintPartition:		ppt
EraseFlash:		ef
TestDevice:		td
ResetDevice:		rd [subcode]
ReadFlashID:		rid
ReadFlashInfo:		rfi
ReadChipInfo:		rci
ReadCapability:		rcb
PackBootLoader:		pack
UnpackBootLoader:	unpack 
TagSPL:			tagspl  

Get brave and try it

I connect my RK3399 "Orange Pi 4" via a USB-C cable:
rkdeveloptool ld
DevNo=1	Vid=0x2207,Pid=0x330c,LocationID=304	Maskrom
td
Test Device quit, creating comm object failed!
su ; rkdeveloptool td
Test Device failed!
The "comm object fail" is because I am not running as root.
This is both interesting and disappointing, but let's try something else.
cp /u1/Projects/Rockchip/rkbin/bin/rk33/rk3399_miniloader_v1.26.bin .
rkdeveloptool db rk3399_miniloader_v1.26.bin
Opening loader failed, exiting download boot!

unpack a loader

rkdeveloptool unpack rk3399_loader_v1.08.106.bin
471 num:1, 472 num:1, loader num:2
entry num: 4
entry: t=1, name=rk3399_ddr_800MHz_v, off=330, size=67584
unpacking entry (rk3399_ddr_800MHz_v)
entry: t=2, name=rk3399_usbplug_v1.0, off=67914, size=51200
unpacking entry (rk3399_usbplug_v1.0)
entry: t=4, name=FlashData, off=119114, size=67584
unpacking entry (FlashData)
entry: t=4, name=FlashBoot, off=186698, size=73728
unpacking entry (FlashBoot)
done

Learn more

Given the above, we could start digging into the source to find out what we can learn from the messages so far. Some searching yields the following: He uses this command
rkdeveloptool db rk3399_loader_v1.08.106.bin
I download this exact loader. It says it is downloading it, but it never returns. I try a later version of their loader that they indicate for the "type C" Rock960 boards and it works.

Who knows why one version hangs and the other works. It might be instructive to find out though. I will note that both of these loaders begin with "BOOT", whereas the miniloader from the rkbin collection begins with something else. And RSAK at offset 8.

rkdeveloptool db rk3399_loader_v1.08.106.bin
Downloading bootloader...
...
rkdeveloptool db rk3399_loader_v1.12.112.bin
Downloading bootloader succeeded.
rkdeveloptool td
Test Device OK.
rkdeveloptool rci
Chip Info:  43 30 33 33 FF FF FF FF FF FF FF FF FF FF FF FF
rkdeveloptool rfi
Flash Info:
	Manufacturer: SAMSUNG, value=00
	Flash Size: 0 MB
	Flash Size: 0 Sectors
	Block Size: 512 KB
	Page Size: 2 KB
	ECC Bits: 0
	Access Time: 40
	Flash CS:
rkdeveloptool]# rkdeveloptool rid
Flash ID: 45 4D 4D 43 20
rkdeveloptool]# rkdeveloptool rcb
Capability:07 00 00 00 00 00 00 00
Direct LBA:	enabled
Vendor Storage:	enabled
First 4m Access:	enabled
Read Com Log:	enabled

Build rkdeveloptool

Thank goodness this is open source! It is 7799 lines of C++ and header files.

I found a fixed a bug in this. P_RC4 was being asked to encrypt buffers larger than 65535 bytes, but the size was given as an unsigned short, which would not hold the size of some files I found in loaders I was working with. This was an easy fix, but tricky to find.

I did this 1-26-2022 on a Fedora 34 linux system.

git clone https://github.com/rockchip-linux/rkdeveloptool.git
cd rkdeveloptool
autoreconf -i
./configure
make
make install
I get a compile error from main.cpp about a snprintf statement targetting a buffer that is too small. I increase the size of the buffer from 5 to 1024 bytes. This allows the build to complete as follows.
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
mv -f .deps/main.Tpo .deps/main.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT crc.o -MD -MP -MF .deps/crc.Tpo -c -o crc.o crc.cpp
mv -f .deps/crc.Tpo .deps/crc.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKBoot.o -MD -MP -MF .deps/RKBoot.Tpo -c -o RKBoot.o RKBoot.cpp
mv -f .deps/RKBoot.Tpo .deps/RKBoot.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKComm.o -MD -MP -MF .deps/RKComm.Tpo -c -o RKComm.o RKComm.cpp
mv -f .deps/RKComm.Tpo .deps/RKComm.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKDevice.o -MD -MP -MF .deps/RKDevice.Tpo -c -o RKDevice.o RKDevice.cpp
mv -f .deps/RKDevice.Tpo .deps/RKDevice.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKImage.o -MD -MP -MF .deps/RKImage.Tpo -c -o RKImage.o RKImage.cpp
mv -f .deps/RKImage.Tpo .deps/RKImage.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKLog.o -MD -MP -MF .deps/RKLog.Tpo -c -o RKLog.o RKLog.cpp
mv -f .deps/RKLog.Tpo .deps/RKLog.Po
g++ -DHAVE_CONFIG_H -I. -I./cfg  -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/usr/include/libusb-1.0    -g -O2 -MT RKScan.o -MD -MP -MF .deps/RKScan.Tpo -c -o RKScan.o RKScan.cpp
mv -f .deps/RKScan.Tpo .deps/RKScan.Po
g++  -g -O2   -o rkdeveloptool main.o crc.o RKBoot.o RKComm.o RKDevice.o RKImage.o RKLog.o RKScan.o -lusb-1.0
make[1]: Leaving directory '/u1/Projects/OrangePi/Rockchip/rkdeveloptool'
The "make install" does this:
/usr/bin/mkdir -p '/usr/local/bin'
/usr/bin/install -c rkdeveloptool '/usr/local/bin'
I already have a /usr/local/bin directory, and it is writeable by me, so this works fine.


Have any comments? Questions? Drop me a line!

Tom's electronics pages / [email protected]