Re: [ptxdist] [PATCH v5 2/5] add package for rockchip firmware binaries

[Michael Riesch <michael.riesch@wolfvision.net>]

Hi again,

On 1/28/22 13:59, Michael Olbrich wrote:
> On Fri, Jan 28, 2022 at 01:46:25PM +0100, Michael Riesch wrote:
>> On 1/28/22 13:31, Michael Olbrich wrote:
>>> On Mon, Jan 24, 2022 at 01:09:39PM +0100, Michael Riesch wrote:
>>>> Rockchip provides the SDRAM initialization as well as BL31/BL32
>>>> firmware for their SoCs in binary form. Add a package that downloads
>>>> those binaries for further use in e.g., barebox.
>>>>
>>>> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
>>>> [revised and extended Kconfig]
>>>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
>>>> ---
>>>>  platforms/firmware-rockchip.in | 41 +++++++++++++++++++
>>>>  rules/firmware-rockchip.make   | 74 ++++++++++++++++++++++++++++++++++
>>>>  2 files changed, 115 insertions(+)
>>>>  create mode 100644 platforms/firmware-rockchip.in
>>>>  create mode 100644 rules/firmware-rockchip.make
>>>>
>>>> diff --git a/platforms/firmware-rockchip.in b/platforms/firmware-rockchip.in
>>>> new file mode 100644
>>>> index 000000000..aa702416d
>>>> --- /dev/null
>>>> +++ b/platforms/firmware-rockchip.in
>>>> @@ -0,0 +1,41 @@
>>>> +## SECTION=non_free_firmware
>>>> +
>>>> +menuconfig FIRMWARE_ROCKCHIP
>>>> +	bool
>>>> +	prompt "Rockchip firmware binaries    "
>>>> +	help
>>>> +	  Rockchip prebuilt SDRAM initialization and TF-A binaries.
>>>> +
>>>> +if FIRMWARE_ROCKCHIP
>>>> +
>>>> +config FIRMWARE_ROCKCHIP_RK3566_SDRAM
>>>
>>> I still don't like the sub-options here. But I'm still thinking about
>>> whether this part should go into PTXdist itself, so no need to touch this
>>> for now.
>>
>> Care to give us some insight in your current state of reasoning as to
>> whether or not this should enter ptxdist?
> 
> It's still somewhat unclear to me, but it seems that all of these files are
> only useful for one specific board. I'm reluctant to add it just for that.

OK, let me emphasize once more that the same OP-TEE/TF-A binaries are
currently used to kick-start
 - the Rockchip RK3568 EVB1
 - the Pine64 Quartz64 board (RK3566)
 - the BananaPi R2 Pro (RK3568)
and possibly more, so that's at least more than one ;-) As I already
stated in [0] there are no alternatives at the moment, so any RK356x
board is bound to require this until Rockchip finally opens up their
TF-A magic.

Eventually the RK356x boards will not need this package anymore, but I
would guess for the promised-for-some-years-and-finally-to-be-released
RK3588 the situation will be quite similar. I believe the package can be
extended to provide those binaries once they are available, as Rockchip
tends to provide the binaries for all SoCs in the same GitHub repository.

The SDRAM init blobs are more specific, but in some form they will
always be required (unless someone really brave steps up and
reverse-engineers the SDRAM initialization, which I don't see coming).
Then it would be nice to provide a rule file that downloads the binaries
and puts them into sysroot. Other rule files can use them subsequently.

Convinced? ;-)

Best regards,
Michael

> 
> But it could also serve as an example for this whole infrastructure...
> 
> Michael
> 

[0]
https://lore.ptxdist.org/ptxdist/b2e89ae2-0ad6-4ac5-5355-3fa64ebde78c@wolfvision.net/

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de