| Message ID | 20231001130803.18662-4-twoerner@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | rock-pi-s | expand |
Hi Trevor, On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote: > ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit > quad core processor, USB, ethernet, wireless connectivity, and voice > detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes > 256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some > versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of > SLC NAND flash. > > "S" stands for "small square" since the total board size of the rock-pi-s is > 1.7-inches square. > > This BSP assumes booting from sdmmc, and using ttyS0 for the serial console > (similar to Raspberry Pi). > > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > README | 1 + > conf/machine/include/rk3308.inc | 18 ++++++++++++++++++ > conf/machine/rock-pi-s.conf | 11 +++++++++++ > recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +++++++++++++++++ > recipes-bsp/u-boot/u-boot%.bbappend | 11 +++++++++++ > recipes-kernel/linux/linux-yocto_%.bbappend | 1 + > 6 files changed, 59 insertions(+) > create mode 100644 conf/machine/include/rk3308.inc > create mode 100644 conf/machine/rock-pi-s.conf > > diff --git a/README b/README > index d4576d73c636..e815fb47ff5f 100644 > --- a/README > +++ b/README > @@ -31,6 +31,7 @@ Status of supported boards: > firefly-rk3288 > nanopi-r4s > rock-5b > + rock-pi-s > builds: > marsboard-rk3066 > radxarock > diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc > new file mode 100644 > index 000000000000..19cabafdfac0 > --- /dev/null > +++ b/conf/machine/include/rk3308.inc > @@ -0,0 +1,18 @@ > +SOC_FAMILY = "rk3308" > + > +DEFAULTTUNE ?= "cortexa35-crypto" > + > +require conf/machine/include/soc-family.inc > +require conf/machine/include/arm/armv8a/tune-cortexa35.inc > +require conf/machine/include/rockchip-defaults.inc > +require conf/machine/include/rockchip-wic.inc > + > +SERIAL_CONSOLES = "1500000;ttyS0" > + > +KBUILD_DEFCONFIG ?= "defconfig" > +KERNEL_FEATURES:append:rk3308 = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" I'm starting to wonder if we shouldn't make this a pn-linux-yocto (and other flavors) override as well because we would make it difficult for other people to NOT include this. e.g. if they have their own recipe where KERNEL_FEATURES is used for example. Anyway, not specific to this SoC include file so not a blocker. > +KERNEL_CLASSES = "kernel-fitimage" > +KERNEL_IMAGETYPE = "fitImage" > + > +UBOOT_SUFFIX ?= "itb" > +UBOOT_ENTRYPOINT ?= "0x06000000" > diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf > new file mode 100644 > index 000000000000..79ea73c6b47e > --- /dev/null > +++ b/conf/machine/rock-pi-s.conf > @@ -0,0 +1,11 @@ > +#@TYPE: Machine > +#@NAME: Radxa Rock Pi S > +#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for "small square" > +#https://wiki.radxa.com/RockpiS > + > +require conf/machine/include/rk3308.inc > + > +KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb" > +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" > + > +UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig" > diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > index 7fefb017053b..49e1e682eb7d 100644 > --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb > +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > @@ -1,9 +1,12 @@ > DESCRIPTION = "Rockchip Firmware and Tool Binaries" > LICENSE = "Proprietary" > +LICENSE:rk3308 = "CLOSED" > LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" > +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" > > SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" > SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" > +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" > Could you please say a few words about this change? It seems that there are still binaries for it in the SRCREV we already point to. I assume newer should be better (though it's not always the case), so wondering what's prompted this change? Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure it's a good idea to stay on a old blob version just for that? I assume you should only be missing the uart in TPL but the moment you reach the SPL the console should appear, doesn't it? > PROVIDES += "trusted-firmware-a" > PROVIDES += "optee-os" > @@ -14,6 +17,7 @@ S = "${WORKDIR}/git" > > COMPATIBLE_MACHINE = "" > COMPATIBLE_MACHINE:rk3588s = "rk3588s" > +COMPATIBLE_MACHINE:rk3308 = "rk3308" > > PACKAGE_ARCH = "${MACHINE_ARCH}" > > @@ -26,6 +30,19 @@ PACKAGES = "${PN}" > ALLOW_EMPTY:${PN} = "1" > > do_deploy() { > + : > +} > + > +do_deploy:append:rk3308() { > + # Prebuilt TF-A > + install -m 644 ${S}/bin/rk33/rk3308_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3308.elf > + # Prebuilt OPTEE-OS > + install -m 644 ${S}/bin/rk33/rk3308_bl32_v*.bin ${DEPLOYDIR}/tee-rk3308.bin > + # prebuilt tpl > + install -m 644 ${S}/bin/rk33/rk3308_ddr_589MHz_uart0_m0_v*.bin ${DEPLOYDIR}/ddr-rk3308.bin > +} > + > +do_deploy:append:rk3588s() { > # Prebuilt TF-A > install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3588.elf > # Prebuilt OPTEE-OS > diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend > index e79c471cf5ce..54f0b7406dd7 100644 > --- a/recipes-bsp/u-boot/u-boot%.bbappend > +++ b/recipes-bsp/u-boot/u-boot%.bbappend > @@ -1,8 +1,13 @@ > +SRCREV:rk3308 = "2173c4a990664d8228d4dadd814bd64fdc12948f" > +SRC_URI:rk3308 = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" > + NACK. You have to remember that u-boot%.bbappend applies to ALL u-boot **prefixed** recipes, including in other layers. At this point, I would suggest to create your own recipe? Or at the very least have a u-boot_%.bbappend instead? Considering that v2023.10 was released a couple hours ago and it seems to be what you're targeting here.... Maybe wait for it to be added to the master branch of oe-core or add it yourself? Then no need to do anything in meta-rockchip :) > # various machines require the pyelftools library for parsing dtb files > DEPENDS:append = " python3-pyelftools-native" > +DEPENDS:append:rk3308 = " u-boot-tools-native" > DEPENDS:append:rock-pi-4 = " gnutls-native" > > EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf" > +EXTRA_OEMAKE:append:rk3308 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3308.elf" > EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf" > EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf" > EXTRA_OEMAKE:append:rk3588s = " \ > @@ -12,6 +17,7 @@ EXTRA_OEMAKE:append:rk3588s = " \ > > INIT_FIRMWARE_DEPENDS ??= "" > INIT_FIRMWARE_DEPENDS:px30 = " trusted-firmware-a:do_deploy" > +INIT_FIRMWARE_DEPENDS:rk3308 = " rockchip-rkbin:do_deploy" > INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy" > INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy" > INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy" > @@ -23,3 +29,8 @@ do_compile:append:rock2-square () { > cp ${B}/spl/${SPL_BINARY} ${B} > fi > } > + > +do_compile:append:rk3308() { > + mkimage -n rk3308 -T rksd -d ${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin ${B}/idbloader.img > + cat ${B}/spl/u-boot-spl.bin >> ${B}/idbloader.img > +} NACK. Same reason as the SRCREV/SRC_URI override. Also... This should be handled by upstream U-Boot already and if it's not, we should patch it. I believe what's needed is simply: ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin added to EXTRA_OEMAKE, the same way it was done for rk3588s? Cheers, Quentin
On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote: > Hi Trevor, > > On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote: > > ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit > > quad core processor, USB, ethernet, wireless connectivity, and voice > > detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes > > 256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some > > versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of > > SLC NAND flash. > > > > "S" stands for "small square" since the total board size of the rock-pi-s is > > 1.7-inches square. > > > > This BSP assumes booting from sdmmc, and using ttyS0 for the serial console > > (similar to Raspberry Pi). > > > > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > > --- > > README | 1 + > > conf/machine/include/rk3308.inc | 18 ++++++++++++++++++ > > conf/machine/rock-pi-s.conf | 11 +++++++++++ > > recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +++++++++++++++++ > > recipes-bsp/u-boot/u-boot%.bbappend | 11 +++++++++++ > > recipes-kernel/linux/linux-yocto_%.bbappend | 1 + > > 6 files changed, 59 insertions(+) > > create mode 100644 conf/machine/include/rk3308.inc > > create mode 100644 conf/machine/rock-pi-s.conf > > > > diff --git a/README b/README > > index d4576d73c636..e815fb47ff5f 100644 > > --- a/README > > +++ b/README > > @@ -31,6 +31,7 @@ Status of supported boards: > > firefly-rk3288 > > nanopi-r4s > > rock-5b > > + rock-pi-s > > builds: > > marsboard-rk3066 > > radxarock > > diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc > > new file mode 100644 > > index 000000000000..19cabafdfac0 > > --- /dev/null > > +++ b/conf/machine/include/rk3308.inc > > @@ -0,0 +1,18 @@ > > +SOC_FAMILY = "rk3308" > > + > > +DEFAULTTUNE ?= "cortexa35-crypto" > > + > > +require conf/machine/include/soc-family.inc > > +require conf/machine/include/arm/armv8a/tune-cortexa35.inc > > +require conf/machine/include/rockchip-defaults.inc > > +require conf/machine/include/rockchip-wic.inc > > + > > +SERIAL_CONSOLES = "1500000;ttyS0" > > + > > +KBUILD_DEFCONFIG ?= "defconfig" > > +KERNEL_FEATURES:append:rk3308 = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" > > I'm starting to wonder if we shouldn't make this a pn-linux-yocto (and other > flavors) override as well because we would make it difficult for other > people to NOT include this. e.g. if they have their own recipe where > KERNEL_FEATURES is used for example. Anyway, not specific to this SoC > include file so not a blocker. I'm not 100% sure what you're recommending, but if there's a better way that is more flexible for the users, it sounds good to me. > > > +KERNEL_CLASSES = "kernel-fitimage" > > +KERNEL_IMAGETYPE = "fitImage" > > + > > +UBOOT_SUFFIX ?= "itb" > > +UBOOT_ENTRYPOINT ?= "0x06000000" > > diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf > > new file mode 100644 > > index 000000000000..79ea73c6b47e > > --- /dev/null > > +++ b/conf/machine/rock-pi-s.conf > > @@ -0,0 +1,11 @@ > > +#@TYPE: Machine > > +#@NAME: Radxa Rock Pi S > > +#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for "small square" > > +#https://wiki.radxa.com/RockpiS > > + > > +require conf/machine/include/rk3308.inc > > + > > +KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb" > > +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" > > + > > +UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig" > > diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > index 7fefb017053b..49e1e682eb7d 100644 > > --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > @@ -1,9 +1,12 @@ > > DESCRIPTION = "Rockchip Firmware and Tool Binaries" > > LICENSE = "Proprietary" > > +LICENSE:rk3308 = "CLOSED" > > LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" > > +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" > > SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" > > SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" > > +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" > > Could you please say a few words about this change? It seems that there are > still binaries for it in the SRCREV we already point to. I assume newer > should be better (though it's not always the case), so wondering what's > prompted this change? > > > Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure > it's a good idea to stay on a old blob version just for that? I assume you > should only be missing the uart in TPL but the moment you reach the SPL the > console should appear, doesn't it? Exactly, I would prefer to be able to capture all of the console output all in one place. It's annoying they randomly decided to change uarts for every other update. As far as I'm concerned one binary blob is a good (or bad) as the next, and if this one gives me diagnostic info in the console, then it wins :-) Any idea what the m0 vs m1 stands for? I'll try the newer ones and see if they work. I fiddled with this quite a bit between the two rk3308-based boards that I have, and this was the first combination that worked. I probably just stopped at that point. > > > PROVIDES += "trusted-firmware-a" > > PROVIDES += "optee-os" > > @@ -14,6 +17,7 @@ S = "${WORKDIR}/git" > > COMPATIBLE_MACHINE = "" > > COMPATIBLE_MACHINE:rk3588s = "rk3588s" > > +COMPATIBLE_MACHINE:rk3308 = "rk3308" > > PACKAGE_ARCH = "${MACHINE_ARCH}" > > @@ -26,6 +30,19 @@ PACKAGES = "${PN}" > > ALLOW_EMPTY:${PN} = "1" > > do_deploy() { > > + : > > +} > > + > > +do_deploy:append:rk3308() { > > + # Prebuilt TF-A > > + install -m 644 ${S}/bin/rk33/rk3308_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3308.elf > > + # Prebuilt OPTEE-OS > > + install -m 644 ${S}/bin/rk33/rk3308_bl32_v*.bin ${DEPLOYDIR}/tee-rk3308.bin > > + # prebuilt tpl > > + install -m 644 ${S}/bin/rk33/rk3308_ddr_589MHz_uart0_m0_v*.bin ${DEPLOYDIR}/ddr-rk3308.bin > > +} > > + > > +do_deploy:append:rk3588s() { > > # Prebuilt TF-A > > install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3588.elf > > # Prebuilt OPTEE-OS > > diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend > > index e79c471cf5ce..54f0b7406dd7 100644 > > --- a/recipes-bsp/u-boot/u-boot%.bbappend > > +++ b/recipes-bsp/u-boot/u-boot%.bbappend > > @@ -1,8 +1,13 @@ > > +SRCREV:rk3308 = "2173c4a990664d8228d4dadd814bd64fdc12948f" > > +SRC_URI:rk3308 = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" > > + > > NACK. > > You have to remember that u-boot%.bbappend applies to ALL u-boot > **prefixed** recipes, including in other layers. At this point, I would > suggest to create your own recipe? Or at the very least have a > u-boot_%.bbappend instead? I think I suggested the recipe name change last week (perhaps not in a patch specifically)? Doesn't the ":rk3308" OVERRIDE protect us here? > Considering that v2023.10 was released a couple hours ago and it seems to be > what you're targeting here.... Maybe wait for it to be added to the master > branch of oe-core or add it yourself? Then no need to do anything in > meta-rockchip :) I guess... :-) > > # various machines require the pyelftools library for parsing dtb files > > DEPENDS:append = " python3-pyelftools-native" > > +DEPENDS:append:rk3308 = " u-boot-tools-native" > > DEPENDS:append:rock-pi-4 = " gnutls-native" > > EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf" > > +EXTRA_OEMAKE:append:rk3308 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3308.elf" > > EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf" > > EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf" > > EXTRA_OEMAKE:append:rk3588s = " \ > > @@ -12,6 +17,7 @@ EXTRA_OEMAKE:append:rk3588s = " \ > > INIT_FIRMWARE_DEPENDS ??= "" > > INIT_FIRMWARE_DEPENDS:px30 = " trusted-firmware-a:do_deploy" > > +INIT_FIRMWARE_DEPENDS:rk3308 = " rockchip-rkbin:do_deploy" > > INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy" > > INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy" > > INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy" > > @@ -23,3 +29,8 @@ do_compile:append:rock2-square () { > > cp ${B}/spl/${SPL_BINARY} ${B} > > fi > > } > > + > > +do_compile:append:rk3308() { > > + mkimage -n rk3308 -T rksd -d ${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin ${B}/idbloader.img > > + cat ${B}/spl/u-boot-spl.bin >> ${B}/idbloader.img > > +} > > NACK. Same reason as the SRCREV/SRC_URI override. Doesn't the ":rk3308" protect us here? > Also... This should be handled by upstream U-Boot already and if it's not, > we should patch it. I believe what's needed is simply: > > ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin > > added to EXTRA_OEMAKE, the same way it was done for rk3588s? I'm just following the U-Boot documentation: https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip#L40 Perhaps the U-Boot build already does the mkimage part, but the cat'ing part is definitely not done by U-Boot's build and is required to work. Best regards, Trevor
Hi Trevor, On 10/3/23 15:56, Trevor Woerner wrote: > On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote: >> Hi Trevor, >> >> On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote: >>> ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit >>> quad core processor, USB, ethernet, wireless connectivity, and voice >>> detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes >>> 256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some >>> versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of >>> SLC NAND flash. >>> >>> "S" stands for "small square" since the total board size of the rock-pi-s is >>> 1.7-inches square. >>> >>> This BSP assumes booting from sdmmc, and using ttyS0 for the serial console >>> (similar to Raspberry Pi). >>> >>> Signed-off-by: Trevor Woerner <twoerner@gmail.com> >>> --- >>> README | 1 + >>> conf/machine/include/rk3308.inc | 18 ++++++++++++++++++ >>> conf/machine/rock-pi-s.conf | 11 +++++++++++ >>> recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +++++++++++++++++ >>> recipes-bsp/u-boot/u-boot%.bbappend | 11 +++++++++++ >>> recipes-kernel/linux/linux-yocto_%.bbappend | 1 + >>> 6 files changed, 59 insertions(+) >>> create mode 100644 conf/machine/include/rk3308.inc >>> create mode 100644 conf/machine/rock-pi-s.conf >>> >>> diff --git a/README b/README >>> index d4576d73c636..e815fb47ff5f 100644 >>> --- a/README >>> +++ b/README >>> @@ -31,6 +31,7 @@ Status of supported boards: >>> firefly-rk3288 >>> nanopi-r4s >>> rock-5b >>> + rock-pi-s >>> builds: >>> marsboard-rk3066 >>> radxarock >>> diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc >>> new file mode 100644 >>> index 000000000000..19cabafdfac0 >>> --- /dev/null >>> +++ b/conf/machine/include/rk3308.inc >>> @@ -0,0 +1,18 @@ >>> +SOC_FAMILY = "rk3308" >>> + >>> +DEFAULTTUNE ?= "cortexa35-crypto" >>> + >>> +require conf/machine/include/soc-family.inc >>> +require conf/machine/include/arm/armv8a/tune-cortexa35.inc >>> +require conf/machine/include/rockchip-defaults.inc >>> +require conf/machine/include/rockchip-wic.inc >>> + >>> +SERIAL_CONSOLES = "1500000;ttyS0" >>> + >>> +KBUILD_DEFCONFIG ?= "defconfig" >>> +KERNEL_FEATURES:append:rk3308 = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" >> >> I'm starting to wonder if we shouldn't make this a pn-linux-yocto (and other >> flavors) override as well because we would make it difficult for other >> people to NOT include this. e.g. if they have their own recipe where >> KERNEL_FEATURES is used for example. Anyway, not specific to this SoC >> include file so not a blocker. > > I'm not 100% sure what you're recommending, but if there's a better way that > is more flexible for the users, it sounds good to me. > KERNEL_FEATURES:append:rk3308:pn-linux-yocto = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" KERNEL_FEATURES:append:rk3308:pn-linux-yocto-rt = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" KERNEL_FEATURES:append:rk3308:pn-linux-yocto-tiny = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" KERNEL_FEATURES:append:rk3308:pn-linux-yocto-dev = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" for example would only apply to linux-yocto recipes and nothing else. Not THAT important we need to fix it up now :) >> >>> +KERNEL_CLASSES = "kernel-fitimage" >>> +KERNEL_IMAGETYPE = "fitImage" >>> + >>> +UBOOT_SUFFIX ?= "itb" >>> +UBOOT_ENTRYPOINT ?= "0x06000000" >>> diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf >>> new file mode 100644 >>> index 000000000000..79ea73c6b47e >>> --- /dev/null >>> +++ b/conf/machine/rock-pi-s.conf >>> @@ -0,0 +1,11 @@ >>> +#@TYPE: Machine >>> +#@NAME: Radxa Rock Pi S >>> +#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for "small square" >>> +#https://wiki.radxa.com/RockpiS >>> + >>> +require conf/machine/include/rk3308.inc >>> + >>> +KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb" >>> +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" >>> + >>> +UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig" >>> diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>> index 7fefb017053b..49e1e682eb7d 100644 >>> --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>> +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>> @@ -1,9 +1,12 @@ >>> DESCRIPTION = "Rockchip Firmware and Tool Binaries" >>> LICENSE = "Proprietary" >>> +LICENSE:rk3308 = "CLOSED" >>> LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" >>> +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" >>> SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" >>> SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" >>> +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" >> >> Could you please say a few words about this change? It seems that there are >> still binaries for it in the SRCREV we already point to. I assume newer >> should be better (though it's not always the case), so wondering what's >> prompted this change? >> >> >> Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure >> it's a good idea to stay on a old blob version just for that? I assume you >> should only be missing the uart in TPL but the moment you reach the SPL the >> console should appear, doesn't it? > > Exactly, I would prefer to be able to capture all of the console output all in > one place. It's annoying they randomly decided to change uarts for every other > update. As far as I'm concerned one binary blob is a good (or bad) as the > next, and if this one gives me diagnostic info in the console, then it wins > :-) > I think this is a bit too much to hope for :) In the commit logs for ddr-bin updates in rkbin, I've seen a few mentions to DDR init stability/reliability for example. So saying it's all the same is probably incorrect. > Any idea what the m0 vs m1 stands for? > Yes, so a pin can be muxed for different functions, e.g. UART from a specific controller, GPIO, SPI, etc... this is what most people are used to. But there are also muxes for the UART function for that specific controller. E.g. the UART0 controller can expose the same function (e.g. RX) on different pins so you need to pick on which one. It's a bit messed up though because you can technically have the same function exposed to two or more pins at the same time but this won't work very well (we've accidentally done this for UART during development :) ) Ignoring this last pedantic detail, I like to model this with __ GPIO1C3 -------- | | SPI0M0 TX -------- | | --- PIN A13 on SoC physical ball ___ | | | | --- UART0M0 RX ------- |__| UART0 RX ---| | --- UART0M1 RX --... |___| --- UART0M2 RX --... So basically, they just stopped creating a binary where the debug console is exposed on UART0 sadly. And this actually made me think we may need a way around all this. e.g. if a ddr-bin is bad in SRCREV decaf but bl31 is good and ddr-bin is good in SRCREV caffe and bl31 is bad in it, it's not great to only have one recipe for that. Maybe we should have: 1) rockchip-rkbin-ddr 2) rockchip-rkbin-trusted-firmware-a 3) rockchip-rkbin-tee This would allow: 1) have different SRCREV for each recipe 2) allow to have ddr-bin coming from rockchip-rkbin-ddr and bl31 from rockchip-rkbin-trusted-firmware-a OR 2) allow to have ddr-bin coming from rockchip-rkbin-ddr and bl31 from trusted-firmware-a, changed with PREFERRED_PROVIDER in the machine conf file and not have to go through hacks in the different recipes > I'll try the newer ones and see if they work. I fiddled with this quite a bit > between the two rk3308-based boards that I have, and this was the first > combination that worked. I probably just stopped at that point. > >> >>> PROVIDES += "trusted-firmware-a" >>> PROVIDES += "optee-os" >>> @@ -14,6 +17,7 @@ S = "${WORKDIR}/git" >>> COMPATIBLE_MACHINE = "" >>> COMPATIBLE_MACHINE:rk3588s = "rk3588s" >>> +COMPATIBLE_MACHINE:rk3308 = "rk3308" >>> PACKAGE_ARCH = "${MACHINE_ARCH}" >>> @@ -26,6 +30,19 @@ PACKAGES = "${PN}" >>> ALLOW_EMPTY:${PN} = "1" >>> do_deploy() { >>> + : >>> +} >>> + >>> +do_deploy:append:rk3308() { >>> + # Prebuilt TF-A >>> + install -m 644 ${S}/bin/rk33/rk3308_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3308.elf >>> + # Prebuilt OPTEE-OS >>> + install -m 644 ${S}/bin/rk33/rk3308_bl32_v*.bin ${DEPLOYDIR}/tee-rk3308.bin >>> + # prebuilt tpl >>> + install -m 644 ${S}/bin/rk33/rk3308_ddr_589MHz_uart0_m0_v*.bin ${DEPLOYDIR}/ddr-rk3308.bin >>> +} >>> + >>> +do_deploy:append:rk3588s() { >>> # Prebuilt TF-A >>> install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3588.elf >>> # Prebuilt OPTEE-OS >>> diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend >>> index e79c471cf5ce..54f0b7406dd7 100644 >>> --- a/recipes-bsp/u-boot/u-boot%.bbappend >>> +++ b/recipes-bsp/u-boot/u-boot%.bbappend >>> @@ -1,8 +1,13 @@ >>> +SRCREV:rk3308 = "2173c4a990664d8228d4dadd814bd64fdc12948f" >>> +SRC_URI:rk3308 = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" >>> + >> >> NACK. >> >> You have to remember that u-boot%.bbappend applies to ALL u-boot >> **prefixed** recipes, including in other layers. At this point, I would >> suggest to create your own recipe? Or at the very least have a >> u-boot_%.bbappend instead? > > I think I suggested the recipe name change last week (perhaps not in a patch > specifically)? > We can have both bbappend, one u-boot%.bbappend and one u-boot_%.bbappend The current content of u-boot%.bbappend is probably fine-ish because we are only setting extra variables in EXTRA_OEMAKE. They can be overridden by passing it a second time IIRC. We anyway need trusted-firmware-a or rockchip-rkbin to even have a bootable image so the INIT_FIRMWARE_DEPENDS thingy seems fine as well. The DEPENDS:append are more arguable. But changing the SRCREV and SRC_URI in %.bbappend means that you force all u-boot recipes of all layers for an rk3308 board to use that SRCREV and SRC_URI. For example, I have a downstream vendor U-Boot I wrote a recipe for, with that, it's overridden if I don't use an override that has a strongest override than rk3308 (so likely only the MACHINE name will be able to), which is a bit surprising. An example for a Linux kernel recipe only supported by one of our modules based on RK3399 https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/tree/recipes-kernel/linux/linux-tsd_4.4.bb. > Doesn't the ":rk3308" OVERRIDE protect us here? > Only for other SoCs but not for boards with the same SoC. >> Considering that v2023.10 was released a couple hours ago and it seems to be >> what you're targeting here.... Maybe wait for it to be added to the master >> branch of oe-core or add it yourself? Then no need to do anything in >> meta-rockchip :) > > I guess... :-) > >>> # various machines require the pyelftools library for parsing dtb files >>> DEPENDS:append = " python3-pyelftools-native" >>> +DEPENDS:append:rk3308 = " u-boot-tools-native" >>> DEPENDS:append:rock-pi-4 = " gnutls-native" >>> EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf" >>> +EXTRA_OEMAKE:append:rk3308 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3308.elf" >>> EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf" >>> EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf" >>> EXTRA_OEMAKE:append:rk3588s = " \ >>> @@ -12,6 +17,7 @@ EXTRA_OEMAKE:append:rk3588s = " \ >>> INIT_FIRMWARE_DEPENDS ??= "" >>> INIT_FIRMWARE_DEPENDS:px30 = " trusted-firmware-a:do_deploy" >>> +INIT_FIRMWARE_DEPENDS:rk3308 = " rockchip-rkbin:do_deploy" >>> INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy" >>> INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy" >>> INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy" >>> @@ -23,3 +29,8 @@ do_compile:append:rock2-square () { >>> cp ${B}/spl/${SPL_BINARY} ${B} >>> fi >>> } >>> + >>> +do_compile:append:rk3308() { >>> + mkimage -n rk3308 -T rksd -d ${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin ${B}/idbloader.img >>> + cat ${B}/spl/u-boot-spl.bin >> ${B}/idbloader.img >>> +} >> >> NACK. Same reason as the SRCREV/SRC_URI override. > > Doesn't the ":rk3308" protect us here? > Only for other SoCs but not for boards with the same SoC. >> Also... This should be handled by upstream U-Boot already and if it's not, >> we should patch it. I believe what's needed is simply: >> >> ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin >> >> added to EXTRA_OEMAKE, the same way it was done for rk3588s? > > I'm just following the U-Boot documentation: > https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip#L40 > > Perhaps the U-Boot build already does the mkimage part, but the cat'ing part > is definitely not done by U-Boot's build and is required to work. > AFAIK, all Aarch64 SoCs from Rockchip are using the new mechanism (binman). You should have a u-boot-rockchip.bin at the end of the compilation step with everything needed in there. It seems the TPL isn't enabled for RK3308 and also the sdram driver is very minimal and probably doesn't do any DRAM init, hence I think you do need the blob from rkbin. Surprisingly enough, CONFIG_ROCKCHIP_EXTERNAL_TPL isn't selected in Kconfig for rock-pi-s but should, based on that fact. This then allows binman to take the blob from ROCKCHIP_TPL variable and create an already valid u-boot-rockchip.bin without needing any additional work. The doc/README.rockchip is very outdated though and predates the transition to using binman for the entire process.... We should probably fix this. But I guess those aren't the kind of patches we should be interested in maintaining in meta-rockchip so fine :) Cheers, Quentin
On Wed 2023-10-04 @ 04:23:31 PM, Quentin Schulz wrote: > On 10/3/23 15:56, Trevor Woerner wrote: > > On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote: > > > > diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > > > index 7fefb017053b..49e1e682eb7d 100644 > > > > --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > > > +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb > > > > @@ -1,9 +1,12 @@ > > > > DESCRIPTION = "Rockchip Firmware and Tool Binaries" > > > > LICENSE = "Proprietary" > > > > +LICENSE:rk3308 = "CLOSED" > > > > LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" > > > > +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" > > > > SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" > > > > SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" > > > > +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" > > > > > > Could you please say a few words about this change? It seems that there are > > > still binaries for it in the SRCREV we already point to. I assume newer > > > should be better (though it's not always the case), so wondering what's > > > prompted this change? > > > > > > > > > Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure > > > it's a good idea to stay on a old blob version just for that? I assume you > > > should only be missing the uart in TPL but the moment you reach the SPL the > > > console should appear, doesn't it? > > > > Exactly, I would prefer to be able to capture all of the console output all in > > one place. It's annoying they randomly decided to change uarts for every other > > update. As far as I'm concerned one binary blob is a good (or bad) as the > > next, and if this one gives me diagnostic info in the console, then it wins > > :-) > > > > I think this is a bit too much to hope for :) In the commit logs for ddr-bin > updates in rkbin, I've seen a few mentions to DDR init stability/reliability > for example. So saying it's all the same is probably incorrect. I did a test with the rk3308 binaries from the latest commit of rkbin that don't support uart0. Specifically I tested with rk3308_ddr_589MHz_uart4_m0_v2.07.bin: this also works. Also, it's a lot less hassle to build (rather than rolling back to a release that has a uart0 console for the rk3308). However, even though the console is set to uart4, this binary also outputs a lot of data to uart0. I've tried both 1,500,000 baud (the standard rockchip baud) and 115,200 baud: neither are able to interpret the data. U-Boot, apparently, doesn't try to reset the serial port either, because the garbage output continues until the Linux kernel finally takes over. Or perhaps maybe the gibberish that I'm seeing is from U-Boot outputting to an uninitialized serial port? Roll back to older rkbin checkout: PRO: - supports console on uart0 (same as linux kernel) and all messages from rkbin, u-boot, linux kernel, and console appear legibly on the terminal CON: - more cumbersome to build (recipe requires a bunch of rk3308-based overrides), perhaps a separate rkbin recipe would be better? - uses older ddr initialization code Use latest rkbin: PRO: - simpler recipe, no overrides necessary, simpler build - uses the latest code (might include bug fixes or other improvements?) CON: - spews a bunch of gibberish to the serial console (from rkbin? from u-boot? from both?) - the first legible messages only start once the linux kernel takes over, therefore the user can't interact with U-Boot (should they so wish)
Hi Trevor, On 10/30/23 18:26, Trevor Woerner wrote: > On Wed 2023-10-04 @ 04:23:31 PM, Quentin Schulz wrote: >> On 10/3/23 15:56, Trevor Woerner wrote: >>> On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote: >>>>> diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>>>> index 7fefb017053b..49e1e682eb7d 100644 >>>>> --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>>>> +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb >>>>> @@ -1,9 +1,12 @@ >>>>> DESCRIPTION = "Rockchip Firmware and Tool Binaries" >>>>> LICENSE = "Proprietary" >>>>> +LICENSE:rk3308 = "CLOSED" >>>>> LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" >>>>> +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" >>>>> SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" >>>>> SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" >>>>> +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" >>>> >>>> Could you please say a few words about this change? It seems that there are >>>> still binaries for it in the SRCREV we already point to. I assume newer >>>> should be better (though it's not always the case), so wondering what's >>>> prompted this change? >>>> >>>> >>>> Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure >>>> it's a good idea to stay on a old blob version just for that? I assume you >>>> should only be missing the uart in TPL but the moment you reach the SPL the >>>> console should appear, doesn't it? >>> >>> Exactly, I would prefer to be able to capture all of the console output all in >>> one place. It's annoying they randomly decided to change uarts for every other >>> update. As far as I'm concerned one binary blob is a good (or bad) as the >>> next, and if this one gives me diagnostic info in the console, then it wins >>> :-) >>> >> >> I think this is a bit too much to hope for :) In the commit logs for ddr-bin >> updates in rkbin, I've seen a few mentions to DDR init stability/reliability >> for example. So saying it's all the same is probably incorrect. > > I did a test with the rk3308 binaries from the latest commit of rkbin that > don't support uart0. Specifically I tested with rk3308_ddr_589MHz_uart4_m0_v2.07.bin: > this also works. > > Also, it's a lot less hassle to build (rather than rolling back to a release > that has a uart0 console for the rk3308). However, even though the console is > set to uart4, this binary also outputs a lot of data to uart0. I've tried both > 1,500,000 baud (the standard rockchip baud) and 115,200 baud: neither are able > to interpret the data. U-Boot, apparently, doesn't try to reset the serial > port either, because the garbage output continues until the Linux kernel > finally takes over. Or perhaps maybe the gibberish that I'm seeing is from > U-Boot outputting to an uninitialized serial port? > So, the TPL (ddr.bin) we get from rockchip-rkbin isn't configurable and it outputs something on some UART controller for the user to be able to debug stuff. Then, if U-Boot isn't properly supported (which is sadly often the case in the beginning or, for poorly supported SoCs... forever), it just simply does nothing for configuring the debug serial (or initializes the "wrong" one). I don't remember exactly if U-Boot does something with the serial device defined as main output in the DTB used by U-Boot or if it just expects the SPL to properly set up everything. I think this should be fixed in U-Boot itself in any case. See what I had to do for PX30 a year ago for example: https://source.denx.de/u-boot/u-boot/-/commit/d0af506625ff909b123a298e435a95ae1b8ee3e7 I haven't looked into it in depth, but it seems only UART2 is supported currently on RK3308, c.f. https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/rk3308/rk3308.c?ref_type=heads#L178 > Roll back to older rkbin checkout: > PRO: > - supports console on uart0 (same as linux kernel) and all messages from > rkbin, u-boot, linux kernel, and console appear legibly on the terminal > CON: > - more cumbersome to build (recipe requires a bunch of rk3308-based > overrides), perhaps a separate rkbin recipe would be better? > - uses older ddr initialization code > > Use latest rkbin: > PRO: > - simpler recipe, no overrides necessary, simpler build > - uses the latest code (might include bug fixes or other improvements?) > CON: > - spews a bunch of gibberish to the serial console (from rkbin? from u-boot? > from both?) > - the first legible messages only start once the linux kernel takes over, > therefore the user can't interact with U-Boot (should they so wish) This would be a blocker to me if I were to use this board, so I second your decision of going for older rkbin for now. Cheers, Quentin
diff --git a/README b/README index d4576d73c636..e815fb47ff5f 100644 --- a/README +++ b/README @@ -31,6 +31,7 @@ Status of supported boards: firefly-rk3288 nanopi-r4s rock-5b + rock-pi-s builds: marsboard-rk3066 radxarock diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc new file mode 100644 index 000000000000..19cabafdfac0 --- /dev/null +++ b/conf/machine/include/rk3308.inc @@ -0,0 +1,18 @@ +SOC_FAMILY = "rk3308" + +DEFAULTTUNE ?= "cortexa35-crypto" + +require conf/machine/include/soc-family.inc +require conf/machine/include/arm/armv8a/tune-cortexa35.inc +require conf/machine/include/rockchip-defaults.inc +require conf/machine/include/rockchip-wic.inc + +SERIAL_CONSOLES = "1500000;ttyS0" + +KBUILD_DEFCONFIG ?= "defconfig" +KERNEL_FEATURES:append:rk3308 = " bsp/rockchip/remove-non-rockchip-arch-arm64.scc" +KERNEL_CLASSES = "kernel-fitimage" +KERNEL_IMAGETYPE = "fitImage" + +UBOOT_SUFFIX ?= "itb" +UBOOT_ENTRYPOINT ?= "0x06000000" diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf new file mode 100644 index 000000000000..79ea73c6b47e --- /dev/null +++ b/conf/machine/rock-pi-s.conf @@ -0,0 +1,11 @@ +#@TYPE: Machine +#@NAME: Radxa Rock Pi S +#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for "small square" +#https://wiki.radxa.com/RockpiS + +require conf/machine/include/rk3308.inc + +KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb" +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" + +UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig" diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb index 7fefb017053b..49e1e682eb7d 100644 --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb @@ -1,9 +1,12 @@ DESCRIPTION = "Rockchip Firmware and Tool Binaries" LICENSE = "Proprietary" +LICENSE:rk3308 = "CLOSED" LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62" +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95" SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master" SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23" +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2" PROVIDES += "trusted-firmware-a" PROVIDES += "optee-os" @@ -14,6 +17,7 @@ S = "${WORKDIR}/git" COMPATIBLE_MACHINE = "" COMPATIBLE_MACHINE:rk3588s = "rk3588s" +COMPATIBLE_MACHINE:rk3308 = "rk3308" PACKAGE_ARCH = "${MACHINE_ARCH}" @@ -26,6 +30,19 @@ PACKAGES = "${PN}" ALLOW_EMPTY:${PN} = "1" do_deploy() { + : +} + +do_deploy:append:rk3308() { + # Prebuilt TF-A + install -m 644 ${S}/bin/rk33/rk3308_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3308.elf + # Prebuilt OPTEE-OS + install -m 644 ${S}/bin/rk33/rk3308_bl32_v*.bin ${DEPLOYDIR}/tee-rk3308.bin + # prebuilt tpl + install -m 644 ${S}/bin/rk33/rk3308_ddr_589MHz_uart0_m0_v*.bin ${DEPLOYDIR}/ddr-rk3308.bin +} + +do_deploy:append:rk3588s() { # Prebuilt TF-A install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf ${DEPLOYDIR}/bl31-rk3588.elf # Prebuilt OPTEE-OS diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend index e79c471cf5ce..54f0b7406dd7 100644 --- a/recipes-bsp/u-boot/u-boot%.bbappend +++ b/recipes-bsp/u-boot/u-boot%.bbappend @@ -1,8 +1,13 @@ +SRCREV:rk3308 = "2173c4a990664d8228d4dadd814bd64fdc12948f" +SRC_URI:rk3308 = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" + # various machines require the pyelftools library for parsing dtb files DEPENDS:append = " python3-pyelftools-native" +DEPENDS:append:rk3308 = " u-boot-tools-native" DEPENDS:append:rock-pi-4 = " gnutls-native" EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf" +EXTRA_OEMAKE:append:rk3308 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3308.elf" EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf" EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf" EXTRA_OEMAKE:append:rk3588s = " \ @@ -12,6 +17,7 @@ EXTRA_OEMAKE:append:rk3588s = " \ INIT_FIRMWARE_DEPENDS ??= "" INIT_FIRMWARE_DEPENDS:px30 = " trusted-firmware-a:do_deploy" +INIT_FIRMWARE_DEPENDS:rk3308 = " rockchip-rkbin:do_deploy" INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy" INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy" INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy" @@ -23,3 +29,8 @@ do_compile:append:rock2-square () { cp ${B}/spl/${SPL_BINARY} ${B} fi } + +do_compile:append:rk3308() { + mkimage -n rk3308 -T rksd -d ${DEPLOY_DIR_IMAGE}/ddr-rk3308.bin ${B}/idbloader.img + cat ${B}/spl/u-boot-spl.bin >> ${B}/idbloader.img +} diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend index 53833f1cc3f4..61c89f70d8dc 100644 --- a/recipes-kernel/linux/linux-yocto_%.bbappend +++ b/recipes-kernel/linux/linux-yocto_%.bbappend @@ -13,6 +13,7 @@ COMPATIBLE_MACHINE:nanopi-m4-2gb = "nanopi-m4-2gb" COMPATIBLE_MACHINE:rock64 = "rock64" COMPATIBLE_MACHINE:rock-pi-e = "rock-pi-e" COMPATIBLE_MACHINE:nanopi-r4s = "nanopi-r4s" +COMPATIBLE_MACHINE:rock-pi-s = "rock-pi-s" SRC_URI:append = " file://rockchip-kmeta;type=kmeta;name=rockchip-kmeta;destsuffix=rockchip-kmeta" SRC_URI:append:nanopi-r4s = " file://nanopi-r4s.scc"
ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit quad core processor, USB, ethernet, wireless connectivity, and voice detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes 256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of SLC NAND flash. "S" stands for "small square" since the total board size of the rock-pi-s is 1.7-inches square. This BSP assumes booting from sdmmc, and using ttyS0 for the serial console (similar to Raspberry Pi). Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- README | 1 + conf/machine/include/rk3308.inc | 18 ++++++++++++++++++ conf/machine/rock-pi-s.conf | 11 +++++++++++ recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +++++++++++++++++ recipes-bsp/u-boot/u-boot%.bbappend | 11 +++++++++++ recipes-kernel/linux/linux-yocto_%.bbappend | 1 + 6 files changed, 59 insertions(+) create mode 100644 conf/machine/include/rk3308.inc create mode 100644 conf/machine/rock-pi-s.conf