Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

On Fri, 21 Jun 2024 at 09:56, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> > > rk3568 is now upstream, there was a PR upstream for this for some
> > > time, similar to rk3588, albeit not as long as rk56x. In some cases
> > > the issue here is the speed of review of upstream ATF. I don't think
> > > that means it should go into something like this.
> > >
> >
> > If the BL31 blob doesn't go into boot-firmware, I don't see the benefit
> > of boot-firmware for Rockchip platforms to be honest. Instead of telling
> > people to get their firmware from github.com/rockchip-linux/rkbin we'll
> > tell them to get one from rkbin and the other from boot-firmware. And I
> > have a feeling that if that's how it'll go that the vendor will just not
> > care about boot-firmware as they would anyway need to keep updating
> > rkbin as well.
>
> Well it could go there, but I currently build ATF for all Rockchip
> platforms we support.
>
> > It doesn't matter whose fault it is for not being upstreamed earlier,
>
> I agree. There's also  no reason something can't be included and then
> dropped at a later time when things land upstream in appropriate
> places.
>
> > the fact is, we still don't have a **merged** open-source BL31 for
> > RK3588 2 and half years after the Rock5B from Radxa was announced. So in
> > that whole timeframe, we have to work with blobs (or maintain your own
> > forked TF-A whenever patches are posted and hope it works well enough).
>
> Agreed, the rk356x has *finally* been merged[1], it was sent as a PR
> around 2 years before. I have highlighted this to Linaro/arm in the
> past that this delay really isn't good enough.

Also I don't believe this repository should be used as a band-aid for
other problems.

> [1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip/rk3568
>
> The point I was trying to make, and I clearly didn't was. In the case
> where there's open source code do we want to include vendor binaries?
>
> > >> FYI, the DDR bin is printing stuff on the console, so we had to modify
> > >> it (with a tool from Rockchip) to remove the gibberish breaking the
> > >> terminal by setting the appropriate controller, mux and baudrate (for
> > >> our products, there's no one size fits all :) ). The question is how to
> > >> handle this since we cannot realistically store every possible
> > >> permutation of that binary for each UART controller, mux of UART
> > >> controller and baudrate (the only parameters **we** modify, but there
> > >> are tons of others).
> > >
> > > I think those sort of things should be mostly quiet TBH.
> >
> > Mostly != fully. The console doesn't break consistently so I assume that
> > if it even prints a tiny bit of info it would still be able to break
> > stuff. I assume we could have binman run some logic to replace the uart
> > controller, mux and baudrate. Not sure we want that but we could.
>
> Adjusting binaries on the fly sounds problematic to me. Is the process
> open or something that's NDA between rockchip and their customers?
>
> > Also, the DDR bin is passing the console info to the BL31 binary through
> > ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the
> > BL31 will also not be fixed.
>
> Ultimately we should work with the vendor to fix those so they're
> consistent? Why do you're products have issues, are they using
> baudrate that is different to all the other rockchip devices?