Hi 2017-02-19 16:31 GMT+08:00 Jacob Chen <jacob2.c...@rock-chips.com>:
> Hi all, > > Eddie Cai wrote on 2017年02月19日 14:32: > > Hi Trevor > > 2017-02-19 10:43 GMT+08:00 Trevor Woerner <twoer...@gmail.com>: > > This bbclass was taken from the Rockchip team's work at > > https://github.com/rockchip-linux/meta-rockchip/commit/ > 53d2e2e474a3014e3013d0059fd1da773fb0e2b7 > > It was mostly written by Jacob Chen <jacob-c...@iotwrt.com>. I've made > some > > small modifications and added it. > > > > Older images used (what Rockchip calls) the "rk-boot" format. Newer > images use > We call it legacy parameter format > > u-boot and a GPT partitioning scheme. This class allows the build to > generate > > a gpt-img file that can either be flashed to eMMC or written to an > SDcard (the > > same image is used for both). > gpt-img is much better than previous one. I like this name. > > > > This is the new image format used for rk3288 SoCs (e.g. the Firefly > board). > > > > Signed-off-by: Trevor Woerner <twoer...@gmail.com> > > --- > > classes/rockchip-gpt-img.bbclass | 132 ++++++++++++++++++++++++++++++ > +++++++++ > > 1 file changed, 132 insertions(+) > > create mode 100644 classes/rockchip-gpt-img.bbclass > > > > diff --git a/classes/rockchip-gpt-img.bbclass > b/classes/rockchip-gpt-img.bbclass > > new file mode 100644 > > index 0000000..fd80625 > > --- /dev/null > > +++ b/classes/rockchip-gpt-img.bbclass > > @@ -0,0 +1,132 @@ > > +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd > > +# Copyright (C) 2017 Trevor Woerner <twoer...@gmail.com> > > +# Released under the MIT license (see COPYING.MIT for the terms) > > + > > +inherit image_types > > + > > +# Use an uncompressed ext4 by default as rootfs > > +IMG_ROOTFS_TYPE = "ext4" > > +IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}" > > + > > +# This image depends on the rootfs image > > +IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}" > > + > > +GPTIMG_SUFFIX = "gpt-img" > > +GPTIMG = "${IMAGE_NAME}.${GPTIMG_SUFFIX}" > > +GPTIMG_SIZE ?= "4096" > This should be GPT size in sectors which is 64 sectors. The name > GPTIMG_SIZE is not clear enough. People may think it is whole gpt image. > What about call it GPT_SIZE? > > > It's whole gpt image. > OK, my mistake. So that look good to me. > > > > +BOOT_IMG = "boot.img" > > +MINILOADER = "loader.bin" > > +UBOOT = "u-boot.out" > > +TRUST = "trust.out" > > +GPTIMG_APPEND ?= "console=tty1 console=ttyS2,115200n8 rw > root=/dev/mmcblk2p7 rootfstype=ext4 init=/sbin/init" > > + > > +# default partitions [in Sectors] > > +# More info at http://rockchip.wikidot.com/partitions > > +LOADER1_SIZE = "8000" > > +RESERVED1_SIZE = "128" > > +RESERVED2_SIZE = "8192" > > +LOADER2_SIZE = "8192" > > +ATF_SIZE = "8192" > > +BOOT_SIZE = "229376" > > + > > +IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \ > > + u-boot-mkimage-native \ > > + mtools-native \ > > + dosfstools-native \ > > + virtual/kernel:do_deploy \ > > + virtual/bootloader:do_deploy" > > + > > +PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_image" > This is not just for rk3288. in fact, it can be used for all the Rockchip > SoC. > > > There're many differences between Chips. > Some chips didn't implement SPL support and have to use rk-miniloader to > create u-boot blob. (e.g. previous rk3399, rk3229) > all the chips supported by uboot-rockchip and upstream u-boot have SPL support . The legacy should go to use legacy update image intead. > Some chips didn't use "spl_back_to_brom" so their tpl have a different > offset.(e.g. previous rk3288) > The back_to_brom is not chip configuration. It is board configuration. Actually all the rk3288 board in uboot-rockchip and upstream u-boot support it now. > > The name "generate_load1" can't express it clearly. > Sorry, should be generate_loader1 which is the partition name shows in http://rockchip.wikidot.com/partitions > > > > + > > +IMAGE_CMD_rockchip-gpt-img () { > > + # Change to image directory > > + cd ${DEPLOY_DIR_IMAGE} > > + > > + # Remove the exist image > > + rm -rf *${GPTIMG_SUFFIX} > ${IMAGE_NAME} is derived using the IMAGE_BASENAME, MACHINE, and DATETIME > variables. So we don't need to delete previous one to avoid mistake. > > + > > + create_rk_image > > + > > + ${PER_CHIP_IMG_GENERATION_COMMAND} > > + > > + cd ${DEPLOY_DIR_IMAGE} > > + ln -s ${GPTIMG} "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}" > > +} > > + > > +create_rk_image () { > > + > > + # Initialize sdcard image file > > + dd if=/dev/zero of=${GPTIMG} bs=1M count=0 seek=${GPTIMG_SIZE} > > + > > + # Create partition table > > + parted -s ${GPTIMG} mklabel gpt > > + > > + # Create vendor defined partitions > > + LOADER1_START=64 > > + RESERVED1_START=`expr ${LOADER1_START} + ${LOADER1_SIZE}` > > + RESERVED2_START=`expr ${RESERVED1_START} + ${RESERVED1_SIZE}` > > + LOADER2_START=`expr ${RESERVED2_START} + ${RESERVED2_SIZE}` > > + ATF_START=`expr ${LOADER2_START} + ${LOADER2_SIZE}` > > + BOOT_START=`expr ${ATF_START} + ${ATF_SIZE}` > > + ROOTFS_START=`expr ${BOOT_START} + ${BOOT_SIZE}` > > + > > + parted -s ${GPTIMG} unit s mkpart loader1 ${LOADER1_START} `expr > ${RESERVED1_START} - 1` > > + parted -s ${GPTIMG} unit s mkpart reserved1 ${RESERVED1_START} > `expr ${RESERVED2_START} - 1` > > + parted -s ${GPTIMG} unit s mkpart reserved2 ${RESERVED2_START} > `expr ${LOADER2_START} - 1` > > + parted -s ${GPTIMG} unit s mkpart loader2 ${LOADER2_START} `expr > ${ATF_START} - 1` > > + parted -s ${GPTIMG} unit s mkpart atf ${ATF_START} `expr > ${BOOT_START} - 1` > > + > > + # Create boot partition and mark it as bootable > > + parted -s ${GPTIMG} unit s mkpart boot ${BOOT_START} `expr > ${ROOTFS_START} - 1` > > + parted -s ${GPTIMG} set 6 boot on > > + > > + # Create rootfs partition > > + parted -s ${GPTIMG} unit s mkpart root ${ROOTFS_START} 100% > > + > > + parted ${GPTIMG} print > > + > > + # Delete the boot image to avoid trouble with the build cache > > + rm -f ${WORKDIR}/${BOOT_IMG} > what about use BOOT_IMG = "boot-${MACHINE}-${DATETIME}.img" instead? That > will leave the previous build for debug and avoid trouble. > > > BOOT_IMG seems will not be deleted automatically so i delete it in here. > If we leave the previous build, it will make a mess. > Can you try to fix it instead of just delete it? I believe add a timestamp can help. > > > > > + > > + # Create boot partition image > > + BOOT_BLOCKS=$(LC_ALL=C parted -s ${GPTIMG} unit b print | awk '/ > 6 / { print substr($4, 1, length($4 -1)) / 512 /2 }') > > + BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63` > > + > > + mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS > > + mcopy -i ${WORKDIR}/${BOOT_IMG} -s > > ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin > ::${KERNEL_IMAGETYPE} > > + > > + DEVICETREE_DEFAULT="" > > + for DTS_FILE in ${KERNEL_DEVICETREE}; do > > + [ -n "${DEVICETREE_DEFAULT}"] && > DEVICETREE_DEFAULT="${DTS_FILE}" > > + mcopy -i ${WORKDIR}/${BOOT_IMG} -s > ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTS_FILE} ::${DTS_FILE} > > + done > > + > > + # Create extlinux config file > > + cat > ${WORKDIR}/extlinux.conf <<EOF > > +default yocto > > + > > +label yocto > > + kernel /${KERNEL_IMAGETYPE} > > + devicetree /${DEVICETREE_DEFAULT} > > + append ${GPTIMG_APPEND} > > +EOF > > + > > + mmd -i ${WORKDIR}/${BOOT_IMG} ::/extlinux > > + mcopy -i ${WORKDIR}/${BOOT_IMG} -s ${WORKDIR}/extlinux.conf > ::/extlinux/ > > + > > + # Burn Boot Partition > > + dd if=${WORKDIR}/${BOOT_IMG} of=${GPTIMG} conv=notrunc,fsync > seek=${BOOT_START} > > + > > + # Burn Rootfs Partition > > + dd if=${IMG_ROOTFS} of=${GPTIMG} seek=${ROOTFS_START} > > + > > +} > > + > > +generate_rk3288_image () { > It is not only for rk3288. In fact, This function is for create load1 > partition. So what about using generate_load1 or create_loader1 ? > > + > > + # Burn bootloader > > + mkimage -n rk3288 -T rksd -d ${DEPLOY_DIR_IMAGE}/${SPL_BINARY} > ${WORKDIR}/${UBOOT} > > + cat ${DEPLOY_DIR_IMAGE}/u-boot-${MACHINE}.bin >> > ${WORKDIR}/${UBOOT} > > + dd if=${WORKDIR}/${UBOOT} of=${GPTIMG} conv=notrunc,fsync seek=64 > > + > > +} > > -- > > 2.12.0.rc1.48.g076c053 > > > > -- > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > It looks good, Reviewed-by: Jacob Chen <jacob-c...@iotwrt.com> > <jacob-c...@iotwrt.com> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
