[Buildroot] Interested in board support for Radxa Rock 5b

[Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker]

Hello,

this is my first email on this mailing list (and almost the first on an
opensource mailinglist in general), so please forgive me and notify me about
any mistake I make ;)

I would love to use buildroot to create images for the Radxa Rock 5b. However,
I am not much experienced and have a few questions about it:

There exists a project on github from a user called flatmax, which provides
files to support building bootable images with buildroot for different boards
with Rockchip SoCs. Using this project, I was able to create a bootable image
for the Rock 5b.

However, I would rather like to see buildroot natively supporting the Rock 5b,
if possible.

From what I see, the project from flatmax uses a special Linux kernel and
u-boot, both provided by Radxa. In addition it also seems to need precompiled
ATF binaries, provided by Rockchip. According to a blogpost on the Radxa
forum, Rockchip does not provide the ATF sources for the particular SoC, but
only compiled ATF binaries.

Hence, my first question is: Is it in general ok to provide a board support
(i.e., a defconfig) to buildroot, which then uses such alternative sources
(e.g., Radxa kernel, Radxa u-boot, Rockchip ATF binaries)?

I also saw that someone from Collabora currently works on u-boot networking
support for the Rock 5b. I am particular interested in that, as I would love
to be able to setup a tftpboot. I was already successful in using the u-boot
version from Collabora to boot the kernel image and rootfs from the flatmax
buildroot via tftp and nfs. However, I built the Collabora u-boot seperately,
i.e., not as part of buildroot.

Hence my second question is, are there people interested in (or maybe even
currently working on) buildroot support for the Rock 5b and could help me? I
saw that the defconfigs of other boards with Rockchip SoCs were dropped in the
past due to lack of maintenance.


Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Giulio Benetti]

Hi Kilian,

On 07/06/23 20:59, Kilian Zinnecker wrote:
> Hello,
> 
> this is my first email on this mailing list (and almost the first on an
> opensource mailinglist in general), so please forgive me and notify me about
> any mistake I make ;)
> 
> I would love to use buildroot to create images for the Radxa Rock 5b. However,
> I am not much experienced and have a few questions about it:
> 
> There exists a project on github from a user called flatmax, which provides
> files to support building bootable images with buildroot for different boards
> with Rockchip SoCs. Using this project, I was able to create a bootable image
> for the Rock 5b.
> 
> However, I would rather like to see buildroot natively supporting the Rock 5b,
> if possible.

that would be good

>  From what I see, the project from flatmax uses a special Linux kernel and
> u-boot, both provided by Radxa. In addition it also seems to need precompiled
> ATF binaries, provided by Rockchip. According to a blogpost on the Radxa
> forum, Rockchip does not provide the ATF sources for the particular SoC, but
> only compiled ATF binaries.

It's ok to use pre-built ATF if there are no open source solutions.
Official ATF doesn't provide source for RK3588:
https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip
but the prebuilt binary is here:
https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35

It happens the same with GPU blobs or other closed-source blobs, so it's
not a problem.

> Hence, my first question is: Is it in general ok to provide a board support
> (i.e., a defconfig) to buildroot, which then uses such alternative sources
> (e.g., Radxa kernel, Radxa u-boot, Rockchip ATF binaries)?

Yes, even if possibly you should use mainline U-Boot, Linux, ATF.
In this case ATF is only provided as blob and maybe some driver has not
been mainlined for RK3588 on U-Boot or Linux.
You can take for example a look at i.MX family defconfigs.
Freescale(NXP) maintained Linux and U-Boot:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/freescale_imx6ullevk_defconfig
while mainlined defconfig is this:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/imx6ullevk_defconfig

> I also saw that someone from Collabora currently works on u-boot networking
> support for the Rock 5b. I am particular interested in that, as I would love
> to be able to setup a tftpboot. I was already successful in using the u-boot
> version from Collabora to boot the kernel image and rootfs from the flatmax
> buildroot via tftp and nfs. However, I built the Collabora u-boot seperately,
> i.e., not as part of buildroot.

If Collabora's U-Boot supports some feature not supported by Rockchip's 
one or Mainline U-Boot it could make sense.

> Hence my second question is, are there people interested in (or maybe even
> currently working on) buildroot support for the Rock 5b and could help me?

I think that ML and IRC can be the 2 place to find help to add support
for that board.

> I saw that > the defconfigs of other boards with Rockchip SoCs were dropped in the
> past due to lack of maintenance.

Sometimes it happens

Best regards
-- 
Giulio Benetti
CEO/CTO@Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker]

Hi Giulio,

thanks for your very helpful answer!

> 
> that would be good
>
 
I would like to try to use Collabora's U-Boot (and kernel) with the Rock 5b
support, for starters. And I would like to setup the defconfig such, that
buildroot fetches the sources from Github. Afaik this can be achieved by
properly setting the respective CUSTOM_REPO_URL and CUSTOM_REPO_VERSION of
the kernel and U-boot. However, Collabora's U-Boot needs two of the ATF
binaries during compilation. How could I fulfil this requirement in the
defconfig? I.e., how could I instruct buildroot to fetch both binaries, when
attempting to build U-Boot? If the binaries are present, I think I should be
able to use the CUSTOM_MAKEOPTS setting to tell U-Boot's makefile to use the
two binaries.

Also I would like to have a change to the used kernel config: I would like to
have ethernet driver support activated in the kernel (CONFIG_R8169=y). Radxa's
kernel version does feature a rockchip_linux_defconfig, which is also used by
flatmax. However, Collabora's kernel repository does not. If the kernel
defconfig was present in the kernel repository, I should be be able to use the
BR2_LINUX_KERNEL_DEFCONFIG setting in the buildroot board defconfig to
instruct buildroot to use that particular kernel defconfig, right? But since
that file is not present, what could I do? And even if it was present: How
could I introduce a change, i.e. activate the Realtek R8169 driver?

> 
> You can take for example a look at i.MX family defconfigs.
> Freescale(NXP) maintained Linux and U-Boot:
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/freescale_i
> mx6ullevk_defconfig while mainlined defconfig is this:
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/imx6ullevk_
> defconfig
>

I also have a question regarding the freescale imx defconfig, you mentioned:
There is a "call" command in the CUSTOM_TARBALL_LOCATION setting:

$(call github,nxp-imx,linux-imx,lf-<version>)/<some>.tar.gz

I suppose that this line results in buildroot downloading a particular tar
from the net. But how does this command work in particular? Does it create
some url from "github,nxp-imx,linux-imx,lf...."?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Giulio Benetti]

Hi Kilian,

On 08/06/23 17:09, Kilian Zinnecker wrote:
> Hi Giulio,
> 
> thanks for your very helpful answer!
> 
>>
>> that would be good
>>
>   
> I would like to try to use Collabora's U-Boot (and kernel) with the Rock 5b
> support, for starters.

To begin is ok, but I see U-Boot supports this board, this is the defconfig:
https://source.denx.de/u-boot/u-boot/-/blob/master/configs/rock5b-rk3588_defconfig
that uses this dts file:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3588-rock-5b.dts

So I would go with mainline uboot.

> And I would like to setup the defconfig such, that
> buildroot fetches the sources from Github.

Using mainline uboot is not needed but

> Afaik this can be achieved by
> properly setting the respective CUSTOM_REPO_URL and CUSTOM_REPO_VERSION of
> the kernel and U-boot.

Yes you can do it with those 2 variables

> However, Collabora's U-Boot needs two of the ATF
> binaries during compilation. How could I fulfil this requirement in the
> defconfig? 

If you refer to BL31 or something similar that should already be an
infrastructure in Buildroot for it. I suggest you to take a look at
other similar boards in buildroot/configs and filter what you need and
give a try.

> I.e., how could I instruct buildroot to fetch both binaries, when
> attempting to build U-Boot? If the binaries are present, I think I should be
> able to use the CUSTOM_MAKEOPTS setting to tell U-Boot's makefile to use the
> two binaries.

As pointed above I think there should already be everything you need,
it's only about to try to imitate what it's already been done.

For example there are already boards with RK3399 that is similar to
R3588. Take a look here at this defconfig:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/rockpro64_defconfig

> 
> Also I would like to have a change to the used kernel config: I would like to
> have ethernet driver support activated in the kernel (CONFIG_R8169=y). Radxa's
> kernel version does feature a rockchip_linux_defconfig, which is also used by
> flatmax. However, Collabora's kernel repository does not. If the kernel
> defconfig was present in the kernel repository, I should be be able to use the
> BR2_LINUX_KERNEL_DEFCONFIG setting in the buildroot board defconfig to
> instruct buildroot to use that particular kernel defconfig, right?

Exactly

> But since
> that file is not present, what could I do? 

You can customize Linux in Buildroot like this:
$ make linux-menuconfig
then save it and:
$ cd output/build/linux.x.x/
$ make savedefconfig

the resulting defconfig is the defconfig you're looking for if you want 
something specific BUT in general in Buildroot we tend to keep
architecture default defconfig and...

> And even if it was present: How
> could I introduce a change, i.e. activate the Realtek R8169 driver?

enable what we want using fragment files. Take a look here:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/olimex_a20_olinuxino_lime2_defconfig#L29
and check the content of that .fragment file, you will see that you can
en/disable options you need

>>
>> You can take for example a look at i.MX family defconfigs.
>> Freescale(NXP) maintained Linux and U-Boot:
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/freescale_i
>> mx6ullevk_defconfig while mainlined defconfig is this:
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/imx6ullevk_
>> defconfig
>>
> 
> I also have a question regarding the freescale imx defconfig, you mentioned:
> There is a "call" command in the CUSTOM_TARBALL_LOCATION setting:
> 
> $(call github,nxp-imx,linux-imx,lf-<version>)/<some>.tar.gz
> 
> I suppose that this line results in buildroot downloading a particular tar
> from the net. But how does this command work in particular? Does it create
> some url from "github,nxp-imx,linux-imx,lf...."?

That is a very useful helper that does exist for gitlab too and it's
defined in:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-download.mk#L63

it takes 3 argument when called and return the URL referred to Github.
Same goes for Gitlab.

Best regards
-- 
CEO/CTO@Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker]

Hi Giulio

thanks again for your very helpful answer!

> To begin is ok, but I see U-Boot supports this board, this is the defconfig:
> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/rock5b-rk3588_defconfig
> that uses this dts file:
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3588-rock-5b.dts
>
> So I would go with mainline uboot.

Yes, absolutely correct, and the changes to support the Rock 5b's ethernet in
U-Boot are also mainline already:

https://source.denx.de/u-boot/u-boot/-/commit/
bcbb64b1990cc1f3f8137c05fbc49b13fcb320ff

Thank you, I actually did not realize this and used Collabora's gitlab
repository. I just compiled the mainline U-Boot and tested the tftpboot and it
works just fine!


> For example there are already boards with RK3399 that is similar to
> R3588. Take a look here at this defconfig:
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/
rockpro64_defconfig

As far as I see the rk3399 is actually a different case: For this particular
SoC the ATF is released as source and part of the ATF repository, see here:

https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/
rockchip.rst?plain=1#L12

This is different for the rk3588, which is the SoC on the Rock 5b: For the
rk3588 Rockchip did not release the ATF source code, hence one needs to use 2
ATF blobs for U-Boot, see also the U-Boot documentation about this:

https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/rockchip/
rockchip.rst?plain=1#L199-200

Both blobs are provided by the Rockchip, see here:

https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35

So currently it seems mandatory to me to setup Buildroot in some way, that
these two blobs are obtained from the rkbin repo and provided to U-Boot during
build.

> If you refer to BL31 or something similar that should already be an
> infrastructure in Buildroot for it. I suggest you to take a look at
> other similar boards in buildroot/configs and filter what you need and
> give a try.

As you suggested, I looked for Buildroot infrastructure to support such
requirements and came across the following two patches on the ML, adding some
similar support for IMX SoCs in the past:

https://lists.buildroot.org/pipermail/buildroot/2021-September/622642.html
https://lists.buildroot.org/pipermail/buildroot/2021-September/622643.html

In recent Buildroot the support seems to be implemented as option
BR2_TARGET_UBOOT_NEEDS_IMX_FIRMWARE here:

https://github.com/buildroot/buildroot/blob/master/boot/uboot/uboot.mk#L194-L208

The option is currently used in four defconfigs:

* imx8mn_bsh_smm_s2_defconfig
* imx8mn_bsh_smm_s2_pro_defconfig
* kontron_bl_imx8mm_defconfig
* kontron_pitx_imx8m_defconfig

However, the defconfigs don't set any option for some specific remote git
repository, from which the binaries can be obtained. Instead "firmware-imx" is
added to UBOOT_DEPENDENCIES in the uboot.mk. As I understand it, this
corresponds to the package "package/freescale-imx/firmware-imx".

So from my understanding, in order to set up the U-Boot build for the Rock 5b
in buildroot, I would have to do the following steps:

* Add a package "package/rockchip/firmware-rk" which fetches the rkbin
  repository properly, similar to "package/freescale-imx/firmware-imx"

* Implement the following targets in the uboot.mk similar to the IMX ones:
    BR2_TARGET_UBOOT_NEEDS_RK_FIRMWARE
    UBOOT_COPY_RK_FW_FILES
    and add UBOOT_COPY_RK_FW_FILES to UBOOT_PRE_BUILD_HOOKS

* Add a Rock 5b defconfig to buildroot with the BR2...UBOOT_NEEDS_RK_FIRMWARE
  option activated

What do you think? I would really like to do this! If I get it working it
actually would be my first opensource contribution. However, I am on a one
week vacation from tomorrow and will not have a laptop. So everybody who reads
this and does not urgently need Rock 5b boar support: Please be a bit patient
and let me do it in a week! ;)


> > And even if it was present: How
> > could I introduce a change, i.e. activate the Realtek R8169 driver?
>
> enable what we want using fragment files. Take a look here:
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/olimex_a20_
> olinuxino_lime2_defconfig#L29 and check the content of that .fragment file,
> you will see that you can en/disable options you need

> That is a very useful helper that does exist for gitlab too and it's
> defined in:
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-download.mk#L63
>
> it takes 3 argument when called and return the URL referred to Github.
> Same goes for Gitlab.

Thank you very much for the info!


Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Giulio Benetti]

Hi Kilian,

On 09/06/23 08:35, Kilian Zinnecker wrote:
> Hi Giulio
> 
> thanks again for your very helpful answer!
> 
>> To begin is ok, but I see U-Boot supports this board, this is the defconfig:
>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/rock5b-rk3588_defconfig
>> that uses this dts file:
>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3588-rock-5b.dts
>>
>> So I would go with mainline uboot.
> 
> Yes, absolutely correct, and the changes to support the Rock 5b's ethernet in
> U-Boot are also mainline already:
> 
> https://source.denx.de/u-boot/u-boot/-/commit/
> bcbb64b1990cc1f3f8137c05fbc49b13fcb320ff
> 
> Thank you, I actually did not realize this and used Collabora's gitlab
> repository. I just compiled the mainline U-Boot and tested the tftpboot and it
> works just fine!

very well

> 
>> For example there are already boards with RK3399 that is similar to
>> R3588. Take a look here at this defconfig:
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/
> rockpro64_defconfig
> 
> As far as I see the rk3399 is actually a different case: For this particular
> SoC the ATF is released as source and part of the ATF repository, see here:
> 
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/
> rockchip.rst?plain=1#L12
> 
> This is different for the rk3588, which is the SoC on the Rock 5b: For the
> rk3588 Rockchip did not release the ATF source code,

you're right

> hence one needs to use 2
> ATF blobs for U-Boot, see also the U-Boot documentation about this:
> 
> https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/rockchip/
> rockchip.rst?plain=1#L199-200
> 
> Both blobs are provided by the Rockchip, see here:
> 
> https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35
> 
> So currently it seems mandatory to me to setup Buildroot in some way, that
> these two blobs are obtained from the rkbin repo and provided to U-Boot during
> build.

totally

>> If you refer to BL31 or something similar that should already be an
>> infrastructure in Buildroot for it. I suggest you to take a look at
>> other similar boards in buildroot/configs and filter what you need and
>> give a try.
> 
> As you suggested, I looked for Buildroot infrastructure to support such
> requirements and came across the following two patches on the ML, adding some
> similar support for IMX SoCs in the past:
> 
> https://lists.buildroot.org/pipermail/buildroot/2021-September/622642.html
> https://lists.buildroot.org/pipermail/buildroot/2021-September/622643.html
> 
> In recent Buildroot the support seems to be implemented as option
> BR2_TARGET_UBOOT_NEEDS_IMX_FIRMWARE here:
> 
> https://github.com/buildroot/buildroot/blob/master/boot/uboot/uboot.mk#L194-L208

yes

> The option is currently used in four defconfigs:
> 
> * imx8mn_bsh_smm_s2_defconfig
> * imx8mn_bsh_smm_s2_pro_defconfig
> * kontron_bl_imx8mm_defconfig
> * kontron_pitx_imx8m_defconfig
> 
> However, the defconfigs don't set any option for some specific remote git
> repository, from which the binaries can be obtained. Instead "firmware-imx" is
> added to UBOOT_DEPENDENCIES in the uboot.mk. As I understand it, this
> corresponds to the package "package/freescale-imx/firmware-imx".

exactly, "firmware-imx" is defined in package/freescale-imx/Config.in

> So from my understanding, in order to set up the U-Boot build for the Rock 5b
> in buildroot, I would have to do the following steps:
> 
> * Add a package "package/rockchip/firmware-rk" which fetches the rkbin
>    repository properly, similar to "package/freescale-imx/firmware-imx"
> 
> * Implement the following targets in the uboot.mk similar to the IMX ones:
>      BR2_TARGET_UBOOT_NEEDS_RK_FIRMWARE
>      UBOOT_COPY_RK_FW_FILES
>      and add UBOOT_COPY_RK_FW_FILES to UBOOT_PRE_BUILD_HOOKS
> 
> * Add a Rock 5b defconfig to buildroot with the BR2...UBOOT_NEEDS_RK_FIRMWARE
>    option activated
> 
> What do you think?

It works for me, so this way you follow what's already been done for imx.

> I would really like to do this! If I get it working it
> actually would be my first opensource contribution. However, I am on a one
> week vacation from tomorrow and will not have a laptop. So everybody who reads
> this and does not urgently need Rock 5b boar support: Please be a bit patient
> and let me do it in a week! ;)

Usually board patches take long time to be committed and they don't show
up everyday in the Mailing List :-)

So I wait for you upcoming patch to review it.

By the way, as a second step you could enable GPU acceleration. 
Rockchip-mali package is already there and needs some adjustment to 
point to a specific Mali model. I see here [1] that Valhalla G610 is
supported and package mali-driver is available in Buildroot even if I
still have to fix it with Linux 6.2 :-/
Even if while writing it came to my mind that Valhalla Mali driver is
probably not compatible with Midgard/Bifrost. But that is other work
that can be done later.

Best regards
-- 
Giulio Benetti
CEO/CTO@Benetti Engineering sas

> 
>>> And even if it was present: How
>>> could I introduce a change, i.e. activate the Realtek R8169 driver?
>>
>> enable what we want using fragment files. Take a look here:
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/olimex_a20_
>> olinuxino_lime2_defconfig#L29 and check the content of that .fragment file,
>> you will see that you can en/disable options you need
> 
>> That is a very useful helper that does exist for gitlab too and it's
>> defined in:
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-download.mk#L63
>>
>> it takes 3 argument when called and return the URL referred to Github.
>> Same goes for Gitlab.
> 
> Thank you very much for the info!
> 
> 
> Best regards,
> Kilian
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker via buildroot]

Hi Giulio,

I am a little bit stuck at the moment. This is my defconfig so far:

BR2_aarch64=y
BR2_cortex_a76_a55=y
BR2_KERNEL_HEADERS_5_10=y
BR2_DL_DIR="$(BASE_DIR)/../../buildroot.dl"
BR2_TARGET_GENERIC_HOSTNAME="rock5b"
BR2_TARGET_GENERIC_ISSUE="Welcome to the rock5b board"
BR2_SYSTEM_DHCP="eth0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/radxa/kernel.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="52f51a2b5ba178f331af62260d2da86d7472c14b"
BR2_LINUX_KERNEL_DEFCONFIG="rockchip_linux"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="rockchip/rk3588-rock-5b"
BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT=y
BR2_PACKAGE_AVAHI=y
BR2_PACKAGE_AVAHI_DAEMON=y
BR2_PACKAGE_OPENSSH=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="250M"
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2023.07-rc4"
BR2_PACKAGE_ROCKCHIP_RKBIN=y
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rock5b-rk3588"
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_DTC=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y
BR2_PACKAGE_HOST_UBOOT_TOOLS=y


This already properly checks out the uboot version and the Rock 5B uboot 
defconfig.
Next I want to properly setup the package for the rkbin repository (containing 
the Rockchip blobs). I therefore created the folder package/rockchip-rkbin and 
added an entry to package/Config.in:

diff --git a/package/Config.in b/package/Config.in
index ad438667d2..ccdec3b49d 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -580,6 +580,7 @@ endmenu
        source "package/read-edid/Config.in"
        source "package/rng-tools/Config.in"
        source "package/rockchip-mali/Config.in"
+       source "package/rockchip-rkbin/Config.in"
        source "package/rpi-userland/Config.in"
        source "package/rs485conf/Config.in"
        source "package/rtc-tools/Config.in"


I also added a package/rockchip-rkbin/Config.in:


config BR2_PACKAGE_ROCKCHIP_RKBIN
        bool "Rockchip RKBIN binary blobs"
        depends on BR2_arm || BR2_aarch64
        help
          Those packages provide binary blobs for the Rockchip RK
          SoCs.

if BR2_PACKAGE_ROCKCHIP_RKBIN
choice
        prompt "Rockchip RK platform"

config BR2_PACKAGE_ROCKCHIP_RK_PLATFORM_RK3588
        bool "rk3588"
endchoice

config BR2_PACKAGE_ROCKCHIP_RK_PLATFORM
        string
        default "RK3588" if BR2_PACKAGE_ROCKCHIP_RK_PLATFORM_RK3588
endif

However, I am struggling a bit with the makefile package/rockchip-rkbin/
rockchip-rkbin.mk. It currently has (uncomplete) contents:

################################################################################
#
# firmware-rk
#
################################################################################

FIRMWARE_RKBIN_VERSION = d6ccfe401ca84a98ca3b85c12b9554a1a43a166c
FIRMWARE_RKBIN_SITE = https://github.com/rockchip-linux/rkbin.git
FIRMWARE_RKBIN_SITE_METHOD = git

FIRMWARE_RKBIN_INSTALL_IMAGES = YES
FIRMWARE_RKBIN_INSTALL_STAGING = YES
FIRMWARE_RKBIN_INSTALL_TARGET = YES

$(eval $(generic-package))


Of course this is not yet sufficient. However, I am struggling with the makefile. 
As a first step, I only want buildroot to download the repository. However, if 
I execute "make rockchip-rkbin-dirclean" followed by "make rockchip-rkbin-
rebuild", it only creates an (almost) empty output/build/rockchip-rkbin 
folder, only containing stamp files. Also no rockchip-rkbin folder gets created 
in my buildroot.dl download folder. It looks like buildroot does not download 
the rockchip-linux/rkbin.git repository at all. Do you have a suggestion, what 
I might be doing wrong here? Do I have to implement some hooks in order for 
the git to be downloaded?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Arnout Vandecappelle via buildroot]

On 26/06/2023 18:01, Kilian Zinnecker via buildroot wrote:
> Hi Giulio,
> 
> I am a little bit stuck at the moment. 
[snip]
> I also added a package/rockchip-rkbin/Config.in:
> 
> 
> config BR2_PACKAGE_ROCKCHIP_RKBIN
>          bool "Rockchip RKBIN binary blobs"
>          depends on BR2_arm || BR2_aarch64
>          help
>            Those packages provide binary blobs for the Rockchip RK
>            SoCs.
> 
> if BR2_PACKAGE_ROCKCHIP_RKBIN
> choice
>          prompt "Rockchip RK platform"
> 
> config BR2_PACKAGE_ROCKCHIP_RK_PLATFORM_RK3588

  This should be BR2_PACKAGE_ROCKCHIP_RKBIN_PLATFORM_RK3588 - it'll work without 
the BIN, but it's not consistent.

>          bool "rk3588"
> endchoice
> 
> config BR2_PACKAGE_ROCKCHIP_RK_PLATFORM
>          string
>          default "RK3588" if BR2_PACKAGE_ROCKCHIP_RK_PLATFORM_RK3588
> endif
> 
> However, I am struggling a bit with the makefile package/rockchip-rkbin/
> rockchip-rkbin.mk. It currently has (uncomplete) contents:
> 
> ################################################################################
> #
> # firmware-rk
> #
> ################################################################################
> 
> FIRMWARE_RKBIN_VERSION = d6ccfe401ca84a98ca3b85c12b9554a1a43a166c

  All the variables have to be ROCKCHIP_RKBIN_ otherwise they don't get used.

> FIRMWARE_RKBIN_SITE = https://github.com/rockchip-linux/rkbin.git
> FIRMWARE_RKBIN_SITE_METHOD = git
> 
> FIRMWARE_RKBIN_INSTALL_IMAGES = YES
> FIRMWARE_RKBIN_INSTALL_STAGING = YES
> FIRMWARE_RKBIN_INSTALL_TARGET = YES
> 
> $(eval $(generic-package))
> 
> 
> Of course this is not yet sufficient. However, I am struggling with the makefile.
> As a first step, I only want buildroot to download the repository. However, if
> I execute "make rockchip-rkbin-dirclean" followed by "make rockchip-rkbin-
> rebuild", it only creates an (almost) empty output/build/rockchip-rkbin
> folder, only containing stamp files. 

  Yes, you didn't define a _SITE to download from (because of the wrong naming).

  Regards,
  Arnout

> Also no rockchip-rkbin folder gets created
> in my buildroot.dl download folder. It looks like buildroot does not download
> the rockchip-linux/rkbin.git repository at all. Do you have a suggestion, what
> I might be doing wrong here? Do I have to implement some hooks in order for
> the git to be downloaded?
> 
> Best regards,
> Kilian
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker via buildroot]

Hello Arnout,

>   All the variables have to be ROCKCHIP_RKBIN_ otherwise they don't get
> used.

thanks alot! I actually knew that the names should match from reading the 
documentation, however for some reason I still got i wrong. Maybe because I 
was taking the firmware-imx makefile as basis and didn't take enough care ...


Thanks to your help I now got it working, that the rkbin is properly 
downloaded. I implemented the makefile such, that the needed binaries are 
copied into $(BINARIES_DIR), i.e., buildroot/output/images. I don't know, 
whether this is best practise? I also adjusted the uboot settings in the 
buildroot board defconfig, so that uboot uses the binaries from rkbin. Building 
uboot works now, when manually running "make rockchip-rkbin-dirclean rockchip-
rkbin-rebuild" and afterwards "make uboot-dirclean uboot-rebuild". I could not 
test it any further yet.

Here are my uboot relevant defconfig settings:

BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2023.07-rc4"
BR2_PACKAGE_ROCKCHIP_RKBIN=y
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rock5b-rk3588"
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS=y
BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="BL31=$(BINARIES_DIR)/rk3588_bl31_v1.38.elf 
ROCKCHIP_TPL=$(BINARIES_DIR)/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin"
BR2_PACKAGE_ROCKCHIP_RKBIN=y


And here patches to add the rockchip-rkbin package:


diff --git a/package/Config.in b/package/Config.in
index ad438667d2..ccdec3b49d 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -580,6 +580,7 @@ endmenu
 	source "package/read-edid/Config.in"
 	source "package/rng-tools/Config.in"
 	source "package/rockchip-mali/Config.in"
+	source "package/rockchip-rkbin/Config.in"
 	source "package/rpi-userland/Config.in"
 	source "package/rs485conf/Config.in"
 	source "package/rtc-tools/Config.in"
diff --git a/package/rockchip-rkbin/Config.in b/package/rockchip-rkbin/Config.in
new file mode 100644
index 0000000000..be106a6bb0
--- /dev/null
+++ b/package/rockchip-rkbin/Config.in
@@ -0,0 +1,20 @@
+config BR2_PACKAGE_ROCKCHIP_RKBIN
+	bool "Rockchip RKBIN binary blobs"
+	depends on BR2_arm || BR2_aarch64
+	help
+	  Those packages provide binary blobs for the Rockchip RK
+          SoCs.
+
+if BR2_PACKAGE_ROCKCHIP_RKBIN
+choice
+	prompt "Rockchip RK platform"
+
+config BR2_PACKAGE_ROCKCHIP_RKBIN_PLATFORM_RK3588
+	bool "rk3588"
+endchoice
+
+config BR2_PACKAGE_ROCKCHIP_RKBIN_PLATFORM
+	string
+	default "RK3588" if BR2_PACKAGE_ROCKCHIP_RKBIN_PLATFORM_RK3588
+
+endif
diff --git a/package/rockchip-rkbin/rockchip-rkbin.mk b/package/rockchip-rkbin/
rockchip-rkbin.mk
new file mode 100644
index 0000000000..5bdc5607ce
--- /dev/null
+++ b/package/rockchip-rkbin/rockchip-rkbin.mk
@@ -0,0 +1,19 @@
+################################################################################
+#
+# firmware-rk
+#
+################################################################################
+
+
+ROCKCHIP_RKBIN_VERSION = d6ccfe401ca84a98ca3b85c12b9554a1a43a166c
+ROCKCHIP_RKBIN_SITE = https://github.com/rockchip-linux/rkbin.git
+ROCKCHIP_RKBIN_SITE_METHOD = git
+
+ROCKCHIP_RKBIN_INSTALL_STAGING = YES
+
+define ROCKCHIP_RKBIN_INSTALL_STAGING_CMDS
+	cp $(@D)/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin $
(BINARIES_DIR)/
+	cp $(@D)/bin/rk35/rk3588_bl31_v1.38.elf $(BINARIES_DIR)/
+endef
+
+$(eval $(generic-package))


I guess I should no setup uboot such, that rockchip-rkbin becomes an optional 
dependency and then set the corresponding option in the buildroot rock5b 
defconfig?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Interested in board support for Radxa Rock 5b

[Kilian Zinnecker via buildroot]

Hello,

I now created a linux config fragment file containing CONFIG_R8169=y to enable 
the ethernet support and added BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/
radxa/rock5b/linux.fragment" to the defconfig, so that the fragment file is 
applied. After a rebuild I was then able to boot the kernel via tftp (rootfs 
via nfs). So that seems to work now.

I now want to create a proper post-image script to create a bootable image for 
an SD card. I therefore created a post-image.sh and a genimage.cfg, by taking 
existing ones from buildroot as template, and the following rock5b.its:

/dts-v1/;

/ {
	description = "Rock 5B FIT Image";
	#address-cells = <1>;

	images {
		kernel {
			description = "Kernel";
			data = /incbin/("Image.gz");
			type = "kernel";
			arch = "arm64";
			os = "linux";
			compression = "gzip";
			load = <0x0a200000>;
			entry = <0x0a200000>;
			hash {
				algo = "sha256";
			};
		};
		fdt {
			description = "Device Tree";
			data = /incbin/("rk3588-rock-5b.dtb");
			type = "flat_dt";
			arch = "arm64";
			compression = "none";
			load = <0x0e000000>;
			entry = <0x0e000000>;
			hash {
				algo = "sha256";
			};
		};
	};

	configurations {
		default = "bootconfig";
		bootconfig {
			description = "Boot configuration";
			kernel = "kernel";
			fdt = "fdt";
			hash {
				algo = "sha256";
			};
		};
	};
};


When I use this its-file manually (i.e., "mkimage -f rock5b.its image.itb"), it 
creates the fit image correctly: I can load the image.itb via tftpboot and boot 
it successfully. Hence, in the post-image.sh I use the line:

mkimage -f board/radxa/rock5b/rock5b.its ${BINARIES_DIR}/image.itb

However, when buildroot executes the post-image.sh the mkimage command 
suddenly throws the following error:

mkimage: unsupported type Flat Device Tree

Unfortunately I don't find any hints on the internet what is going wrong here. 
I only find one old buildroot ml thread, but this only reports the same error 
and does not give any clue what is going wrong. Does somebody have a hint for 
me, what may be going wrong?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot