|
Posted at 2/15/2018 18:38:17
Last edited by peda In 2/15/2018 18:42 Editor
Hi!
I'm trying to build my own kernel and run that with some debian distribution. After some searching I started with the guide at http://rockchip.wikidot.com/linux-user-guide but these directions seem to fail for me. Here's what I do:
mkdir rk-linux
cd rk-linux
repo init -u https://github.com/rockchip-linux/manifests
repo sync
build/mk-kernel.sh rk3288-firefly
build/mk-uboot.sh rk3288-firefly
build/mk-image.sh -c rk3288 -t boot
build/mk-image.sh -c rk3288 -t system -r linaro-rootfs.img
build/flash_tool.sh -p system -i out/system.img
This is not exactly as described in the linux-user-guide, since it has a "-s 3000" on the second mk-image.sh invocation, but the provided mk-image.sh does not support -s so the guide is clearly wrong (or perhaps just out of date). The above is however consistent with the top README.md after syncing the repo manifest.
Before running flash_tool.sh, I put the device in MaskRom mode, and the flashing seems to work fine. I get this output:
PARTITIONS OFFSET: 0 sectors.
Downloading bootloader succeeded.
Write LBA from file (100%)
Reset Device OK.
After that the board is restarted automatically (as indicated) and I get this on the serial console:
U-Boot SPL 2017.09-g515bbbdeca (Feb 15 2018 - 09:30:26)
Returning to boot ROM...
U-Boot 2017.09-g515bbbdeca (Feb 15 2018 - 09:30:26 +0100)
Model: Firefly-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
*** Warning - bad CRC, using default environment
And then nothing happens. I got the linaro-rootfs.img file from a tar-ball named "rootfs-debian-20171225(fix a stupid mistake, affect performance since 20170901).tar.gz" that I got from some rockchip site, but that seems unlikely to matter when the problem appears to be that u-boot can't find the dtb and/or the kernel.
At one point I thought that the boot.img that is built with the first mk-image.sh invocation wasn't flashed, but looking in the mk-image.sh script for how out/system.img is generated in the second mk-image.sh invocation, boot.img is indeed added to the system.img so that's not it.
What am I doing wrong?
Cheers,
Peter
|
|