On Fri, 21 Jun 2024 at 09:56, Peter Robinson <pbrobin...@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?
