|
|
|
#
|
|
|
|
# Copyright (C) 2015 Google. Inc
|
|
|
|
# Written by Simon Glass <sjg@chromium.org>
|
|
|
|
#
|
|
|
|
# SPDX-License-Identifier: GPL-2.0+
|
|
|
|
#
|
|
|
|
|
|
|
|
U-Boot on Rockchip
|
|
|
|
==================
|
|
|
|
|
|
|
|
There are several repositories available with versions of U-Boot that support
|
|
|
|
many Rockchip devices [1] [2].
|
|
|
|
|
|
|
|
The current mainline support is experimental only and is not useful for
|
|
|
|
anything. It should provide a base on which to build.
|
|
|
|
|
|
|
|
So far only support for the RK3288 and RK3036 is provided.
|
|
|
|
|
|
|
|
|
|
|
|
Prerequisites
|
|
|
|
=============
|
|
|
|
|
|
|
|
You will need:
|
|
|
|
|
|
|
|
- Firefly RK3288 board or something else with a supported RockChip SoC
|
|
|
|
- Power connection to 5V using the supplied micro-USB power cable
|
|
|
|
- Separate USB serial cable attached to your computer and the Firefly
|
|
|
|
(connect to the micro-USB connector below the logo)
|
|
|
|
- rkflashtool [3]
|
|
|
|
- openssl (sudo apt-get install openssl)
|
|
|
|
- Serial UART connection [4]
|
|
|
|
- Suitable ARM cross compiler, e.g.:
|
|
|
|
sudo apt-get install gcc-4.7-arm-linux-gnueabi
|
|
|
|
|
|
|
|
|
|
|
|
Building
|
|
|
|
========
|
|
|
|
|
|
|
|
At present nine RK3288 boards are supported:
|
|
|
|
|
|
|
|
- EVB RK3288 - use evb-rk3288 configuration
|
|
|
|
- Fennec RK3288 - use fennec-rk3288 configuration
|
|
|
|
- Firefly RK3288 - use firefly-rk3288 configuration
|
|
|
|
- Hisense Chromebook - use chromebook_jerry configuration
|
|
|
|
- MiQi RK3288 - use miqi-rk3288 configuration
|
|
|
|
- phyCORE-RK3288 RDK - use phycore-rk3288 configuration
|
|
|
|
- PopMetal RK3288 - use popmetal-rk3288 configuration
|
|
|
|
- Radxa Rock 2 - use rock2 configuration
|
|
|
|
- Tinker RK3288 - use tinker-rk3288 configuration
|
|
|
|
|
|
|
|
Two RK3036 board are supported:
|
|
|
|
|
|
|
|
- EVB RK3036 - use evb-rk3036 configuration
|
|
|
|
- Kylin - use kylin_rk3036 configuration
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
|
|
|
|
|
|
|
|
(or you can use another cross compiler if you prefer)
|
|
|
|
|
|
|
|
|
|
|
|
Writing to the board with USB
|
|
|
|
=============================
|
|
|
|
|
|
|
|
For USB to work you must get your board into ROM boot mode, either by erasing
|
|
|
|
your MMC or (perhaps) holding the recovery button when you boot the board.
|
|
|
|
To erase your MMC, you can boot into Linux and type (as root)
|
|
|
|
|
|
|
|
dd if=/dev/zero of=/dev/mmcblk0 bs=1M
|
|
|
|
|
|
|
|
Connect your board's OTG port to your computer.
|
|
|
|
|
|
|
|
To create a suitable image and write it to the board:
|
|
|
|
|
|
|
|
./firefly-rk3288/tools/mkimage -n rk3288 -T rkimage -d \
|
|
|
|
./firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
|
|
|
|
cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | rkflashtool l
|
|
|
|
|
|
|
|
If all goes well you should something like:
|
|
|
|
|
|
|
|
U-Boot SPL 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 10:06:49)
|
|
|
|
Card did not respond to voltage select!
|
|
|
|
spl: mmc init failed with error: -17
|
|
|
|
### ERROR ### Please RESET the board ###
|
|
|
|
|
|
|
|
You will need to reset the board before each time you try. Yes, that's all
|
|
|
|
it does so far. If support for the Rockchip USB protocol or DFU were added
|
|
|
|
in SPL then we could in principle load U-Boot and boot to a prompt from USB
|
|
|
|
as several other platforms do. However it does not seem to be possible to
|
|
|
|
use the existing boot ROM code from SPL.
|
|
|
|
|
|
|
|
|
|
|
|
Booting from an SD card
|
|
|
|
=======================
|
|
|
|
|
|
|
|
To write an image that boots from an SD card (assumed to be /dev/sdc):
|
|
|
|
|
|
|
|
./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
|
|
|
|
firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
|
|
|
|
sudo dd if=out of=/dev/sdc seek=64 && \
|
|
|
|
sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=16384
|
|
|
|
|
|
|
|
This puts the Rockchip header and SPL image first and then places the U-Boot
|
|
|
|
image at block 16384 (i.e. 8MB from the start of the SD card). This
|
|
|
|
corresponds with this setting in U-Boot:
|
|
|
|
|
|
|
|
#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x4000
|
|
|
|
|
|
|
|
Put this SD (or micro-SD) card into your board and reset it. You should see
|
|
|
|
something like:
|
|
|
|
|
|
|
|
U-Boot 2016.01-rc2-00309-ge5bad3b-dirty (Jan 02 2016 - 23:41:59 -0700)
|
|
|
|
|
|
|
|
Model: Radxa Rock 2 Square
|
|
|
|
DRAM: 2 GiB
|
|
|
|
MMC: dwmmc@ff0f0000: 0, dwmmc@ff0c0000: 1
|
|
|
|
*** Warning - bad CRC, using default environment
|
|
|
|
|
|
|
|
In: serial
|
|
|
|
Out: vop@ff940000.vidconsole
|
|
|
|
Err: serial
|
|
|
|
Net: Net Initialization Skipped
|
|
|
|
No ethernet found.
|
|
|
|
Hit any key to stop autoboot: 0
|
|
|
|
=>
|
|
|
|
|
|
|
|
The rockchip bootrom can load and boot an initial spl, then continue to
|
|
|
|
load a second-level bootloader(ie. U-BOOT) as soon as it returns to bootrom.
|
|
|
|
Therefore RK3288 has another loading sequence like RK3036. The option of
|
|
|
|
U-Boot is controlled with this setting in U-Boot:
|
|
|
|
|
|
|
|
#define CONFIG_SPL_ROCKCHIP_BACK_TO_BROM
|
|
|
|
|
|
|
|
You can create the image via the following operations:
|
|
|
|
|
|
|
|
./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
|
|
|
|
firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
|
|
|
|
cat firefly-rk3288/u-boot-dtb.bin >> out && \
|
|
|
|
sudo dd if=out of=/dev/sdc seek=64
|
|
|
|
|
|
|
|
If you have an HDMI cable attached you should see a video console.
|
|
|
|
|
|
|
|
For evb_rk3036 board:
|
|
|
|
./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d evb-rk3036/spl/u-boot-spl.bin out && \
|
|
|
|
cat evb-rk3036/u-boot-dtb.bin >> out && \
|
|
|
|
sudo dd if=out of=/dev/sdc seek=64
|
|
|
|
|
|
|
|
Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the
|
|
|
|
debug uart must be disabled
|
|
|
|
|
|
|
|
|
|
|
|
Booting from an SD card on RK3288 with TPL
|
|
|
|
==========================================
|
|
|
|
|
|
|
|
Since the size of SPL can't be exceeded 0x8000 bytes in RK3288, it is not possible add
|
|
|
|
new SPL features like Falcon mode or etc.
|
|
|
|
|
|
|
|
So introduce TPL so-that adding new features to SPL is possible because now TPL should
|
|
|
|
run minimal with code like DDR, clock etc and rest of new features in SPL.
|
|
|
|
|
|
|
|
As of now TPL is added on Vyasa-RK3288 board.
|
|
|
|
|
|
|
|
To write an image that boots from an SD card (assumed to be /dev/mmcblk0):
|
|
|
|
|
|
|
|
./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out &&
|
|
|
|
cat ./spl/u-boot-spl-dtb.bin >> out &&
|
|
|
|
sudo dd if=out of=/dev/mmcblk0 seek=64 &&
|
|
|
|
sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 seek=16384
|
|
|
|
|
|
|
|
Booting from an SD card on RK3188
|
|
|
|
=================================
|
|
|
|
|
|
|
|
For rk3188 boards the general storage onto the card stays the same as
|
|
|
|
described above, but the image creation needs a bit more care.
|
|
|
|
|
|
|
|
The bootrom of rk3188 expects to find a small 1kb loader which returns
|
|
|
|
control to the bootrom, after which it will load the real loader, which
|
|
|
|
can then be up to 29kb in size and does the regular ddr init. This is
|
|
|
|
handled by a single image (built as the SPL stage) that tests whether
|
|
|
|
it is handled for the first or second time via code executed from the
|
|
|
|
boot0-hook.
|
|
|
|
|
|
|
|
Additionally the rk3188 requires everything the bootrom loads to be
|
|
|
|
rc4-encrypted. Except for the very first stage the bootrom always reads
|
|
|
|
and decodes 2kb pages, so files should be sized accordingly.
|
|
|
|
|
|
|
|
# copy tpl, pad to 1020 bytes and append spl
|
|
|
|
tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
|
|
|
|
|
|
|
|
# truncate, encode and append u-boot.bin
|
|
|
|
truncate -s %2048 u-boot.bin
|
|
|
|
cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out
|
|
|
|
|
|
|
|
|
|
|
|
Using fastboot on rk3288
|
|
|
|
========================
|
|
|
|
- Write GPT partition layout to mmc device which fastboot want to use it to
|
|
|
|
store the image
|
|
|
|
|
|
|
|
=> gpt write mmc 1 $partitions
|
|
|
|
|
|
|
|
- Invoke fastboot command to prepare
|
|
|
|
|
|
|
|
=> fastboot 1
|
|
|
|
|
|
|
|
- Start fastboot request on PC
|
|
|
|
|
|
|
|
fastboot -i 0x2207 flash loader evb-rk3288/spl/u-boot-spl-dtb.bin
|
|
|
|
|
|
|
|
You should see something like:
|
|
|
|
|
|
|
|
=> fastboot 1
|
|
|
|
WARNING: unknown variable: partition-type:loader
|
|
|
|
Starting download of 357796 bytes
|
|
|
|
..
|
|
|
|
downloading of 357796 bytes finished
|
|
|
|
Flashing Raw Image
|
|
|
|
........ wrote 357888 bytes to 'loader'
|
|
|
|
|
|
|
|
Booting from SPI
|
|
|
|
================
|
|
|
|
|
|
|
|
To write an image that boots from SPI flash (e.g. for the Haier Chromebook):
|
|
|
|
|
|
|
|
./chromebook_jerry/tools/mkimage -n rk3288 -T rkspi \
|
|
|
|
-d chromebook_jerry/spl/u-boot-spl-dtb.bin spl.bin && \
|
|
|
|
dd if=spl.bin of=spl-out.bin bs=128K conv=sync && \
|
|
|
|
cat spl-out.bin chromebook_jerry/u-boot-dtb.img >out.bin && \
|
|
|
|
dd if=out.bin of=out.bin.pad bs=4M conv=sync
|
|
|
|
|
|
|
|
This converts the SPL image to the required SPI format by adding the Rockchip
|
|
|
|
header and skipping every 2KB block. Then the U-Boot image is written at
|
|
|
|
offset 128KB and the whole image is padded to 4MB which is the SPI flash size.
|
|
|
|
The position of U-Boot is controlled with this setting in U-Boot:
|
|
|
|
|
|
|
|
#define CONFIG_SYS_SPI_U_BOOT_OFFS (128 << 10)
|
|
|
|
|
|
|
|
If you have a Dediprog em100pro connected then you can write the image with:
|
|
|
|
|
|
|
|
sudo em100 -s -c GD25LQ32 -d out.bin.pad -r
|
|
|
|
|
|
|
|
When booting you should see something like:
|
|
|
|
|
|
|
|
U-Boot SPL 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32)
|
|
|
|
|
|
|
|
|
|
|
|
U-Boot 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32 -0600)
|
|
|
|
|
|
|
|
Model: Google Jerry
|
|
|
|
DRAM: 2 GiB
|
|
|
|
MMC:
|
|
|
|
Using default environment
|
|
|
|
|
|
|
|
In: serial@ff690000
|
|
|
|
Out: serial@ff690000
|
|
|
|
Err: serial@ff690000
|
|
|
|
=>
|
|
|
|
|
|
|
|
Future work
|
|
|
|
===========
|
|
|
|
|
|
|
|
Immediate priorities are:
|
|
|
|
|
|
|
|
- USB host
|
|
|
|
- USB device
|
|
|
|
- Run CPU at full speed (code exists but we only see ~60 DMIPS maximum)
|
|
|
|
- NAND flash
|
|
|
|
- Support for other Rockchip parts
|
|
|
|
- Boot U-Boot proper over USB OTG (at present only SPL works)
|
|
|
|
|
|
|
|
|
|
|
|
Development Notes
|
|
|
|
=================
|
|
|
|
|
|
|
|
There are plenty of patches in the links below to help with this work.
|
|
|
|
|
|
|
|
[1] https://github.com/rkchrome/uboot.git
|
|
|
|
[2] https://github.com/linux-rockchip/u-boot-rockchip.git branch u-boot-rk3288
|
|
|
|
[3] https://github.com/linux-rockchip/rkflashtool.git
|
|
|
|
[4] http://wiki.t-firefly.com/index.php/Firefly-RK3288/Serial_debug/en
|
|
|
|
|
|
|
|
rkimage
|
|
|
|
-------
|
|
|
|
|
|
|
|
rkimage.c produces an SPL image suitable for sending directly to the boot ROM
|
|
|
|
over USB OTG. This is a very simple format - just the string RK32 (as 4 bytes)
|
|
|
|
followed by u-boot-spl-dtb.bin.
|
|
|
|
|
|
|
|
The boot ROM loads image to 0xff704000 which is in the internal SRAM. The SRAM
|
|
|
|
starts at 0xff700000 and extends to 0xff718000 where we put the stack.
|
|
|
|
|
|
|
|
rksd
|
|
|
|
----
|
|
|
|
|
|
|
|
rksd.c produces an image consisting of 32KB of empty space, a header and
|
|
|
|
u-boot-spl-dtb.bin. The header is defined by 'struct header0_info' although
|
|
|
|
most of the fields are unused by U-Boot. We just need to specify the
|
|
|
|
signature, a flag and the block offset and size of the SPL image.
|
|
|
|
|
|
|
|
The header occupies a single block but we pad it out to 4 blocks. The header
|
|
|
|
is encoding using RC4 with the key 7c4e0304550509072d2c7b38170d1711. The SPL
|
|
|
|
image can be encoded too but we don't do that.
|
|
|
|
|
|
|
|
The maximum size of u-boot-spl-dtb.bin which the boot ROM will read is 32KB,
|
|
|
|
or 0x40 blocks. This is a severe and annoying limitation. There may be a way
|
|
|
|
around this limitation, since there is plenty of SRAM, but at present the
|
|
|
|
board refuses to boot if this limit is exceeded.
|
|
|
|
|
|
|
|
The image produced is padded up to a block boundary (512 bytes). It should be
|
|
|
|
written to the start of an SD card using dd.
|
|
|
|
|
|
|
|
Since this image is set to load U-Boot from the SD card at block offset,
|
|
|
|
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, dd should be used to write
|
|
|
|
u-boot-dtb.img to the SD card at that offset. See above for instructions.
|
|
|
|
|
|
|
|
rkspi
|
|
|
|
-----
|
|
|
|
|
|
|
|
rkspi.c produces an image consisting of a header and u-boot-spl-dtb.bin. The
|
|
|
|
resulting image is then spread out so that only the first 2KB of each 4KB
|
|
|
|
sector is used. The header is the same as with rksd and the maximum size is
|
|
|
|
also 32KB (before spreading). The image should be written to the start of
|
|
|
|
SPI flash.
|
|
|
|
|
|
|
|
See above for instructions on how to write a SPI image.
|
|
|
|
|
|
|
|
rkmux.py
|
|
|
|
--------
|
|
|
|
|
|
|
|
You can use this script to create #defines for SoC register access. See the
|
|
|
|
script for usage.
|
|
|
|
|
|
|
|
|
|
|
|
Device tree and driver model
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
Where possible driver model is used to provide a structure to the
|
|
|
|
functionality. Device tree is used for configuration. However these have an
|
|
|
|
overhead and in SPL with a 32KB size limit some shortcuts have been taken.
|
|
|
|
In general all Rockchip drivers should use these features, with SPL-specific
|
|
|
|
modifications where required.
|
|
|
|
|
|
|
|
GPT partition layout
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
Rockchip use a unified GPT partition layout in open source support.
|
|
|
|
With this GPT partition layout, uboot can be compatilbe with other components,
|
|
|
|
like miniloader, trusted-os, arm-trust-firmware.
|
|
|
|
|
|
|
|
There are some documents about partitions in the links below.
|
|
|
|
http://rockchip.wikidot.com/partitions
|
|
|
|
|
|
|
|
--
|
|
|
|
Simon Glass <sjg@chromium.org>
|
|
|
|
24 June 2015
|