No Description

Giulio 41ed23bd2e Minor formatting 6 months ago
bootrom 867a3b4cc3 First doc draft 6 months ago
datasheets 867a3b4cc3 First doc draft 6 months ago
images 867a3b4cc3 First doc draft 6 months ago
Readme.md 41ed23bd2e Minor formatting 6 months ago

Readme.md

Pinebook Pro info & experiments

RK3399 Datasheets

Datasheets are available at rockchip.fr. A backup of the relevant datasheets can be found in this repo in the dedicated folder.

UART Interface

Self building the serial to 3.5mm cable is an easy task (even without a proper tester):

The baudrate for the rk3399 SoC is 1500000 or 1.5Mmbps. Note that not every serial adapter does support this kind of rate. If if it does, there might be driver issues. Furthermore, not every console software supports that baudrate: for instance GNU screen used to had problems. picocom is a well tested and working solution that supports capture.

Serial adapters:

  • CP2102 does not support the baudrate
  • CH340 in a serial DB9 cable does not work due to the voltage of 5V
  • PL011 is built in in all generations of Raspberry Pi and does work
  • CH340/CH340G with 3.3V are reported working

The bootrom does not provide any output.

3.5mm Jack Colors Raspberry Pi as UART adapter

U-Boot build

The following build process builds everything from sources, using the latest ATF.

git clone https://github.com/ARM-software/arm-trusted-firmware.git atf
git clone https://gitlab.com/pine64-org/u-boot
cd atf
CROSS_COMPILE=aarch64-linux-gnu- make -j12 PLAT=rk3399 CFLAGS='-gdwarf-2'
cd ../u-boot
CROSS_COMPILE=aarch64-linux-gnu- make -j12 BL31=../atf/build/rk3399/release/bl31/bl31.elf

Write it on sd

dd if=u-boot/idbloader.img of=/dev/mmcblk2 seek=64
dd if=u-boot/u-boot.itb of=/dev/mmcblk2 seek=16384

Bootrom dumping

This is not a security issue and does not exploit any hole. Since the Pinebook Pro is a developer board, it is fully unlocked and thus we can run any code we want by patching the SPL stage of U-Boot which run at Secure Level 3 and thus has the highest privileges.

The bootrom should follow the following logical flow:

  1. Do basic hardware initialization
  2. Test and attempt to boot from the SPI NOR
  3. Test and attempt to boot from the eMMC
  4. Test and attempt to boot from the SD
  5. In case all attempts above fails, enter MaskRom/Recvoery mode
  6. If in Maskrom mode, attempt recovery via USB OTG

The bootrom can be dumped easily, in the file u-boot/arch/arm/mach-rockchip/bootrom.c replace the function back_to_bootrom with the following code:

void back_to_bootrom(enum rockchip_bootrom_cmd brom_cmd) {
#if CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT)
    char * p = (void *)0xffff0000;

    int level;
    level = current_el();

    printf("Running in level: %d\n", level);
    puts("Dumping 32k at 0xffff0000\n");
    for (int i=0; i<32768; i++) {
        printf("%02x ", p[i]);
    puts("Returning to boot ROM...\n");
#endif
    _back_to_bootrom(brom_cmd);
}

Then build u-boot, install it on the boot media in use and save a log from the serial console output.

The bootrom ha a magic ASCII signature at the end C03361028110001V.

Tasks

  • bootrom re?
  • U-boot from SPI?

  • Coreboot?

Links