On 7/10/23 17:50, Marek Vasut wrote:
On 7/10/23 17:47, Simon Glass wrote:
Hi,
On Mon, 10 Jul 2023 at 09:15, Taedcke, Christian
<[email protected]> wrote:
Am 10.07.2023 um 15:44 schrieb Marek Vasut:
On 7/10/23 15:02, Taedcke, Christian wrote:
Am 10.07.2023 um 13:41 schrieb Michal Simek:
On 6/27/23 11:04, [email protected] wrote:
From: Christian Taedcke <[email protected]>
This way custom logic can be implemented per board after the fpga
image is uploaded.
What do you want to do there?
I have 2 use-cases for this:
1. Clear the RAM which contained the bitstream (memset to zero). This
should happen independed of the result of the upload operation.
Is this some "secure-boot" related item ?
Not directly. This only helps reducing the time the decrypted bitstream
is stored in RAM.
2. Control a LED based on the upload result. So in case the upload
failed, i want to enable some error LED.
One issue is that the return values of spl_fit_load_fpga() or
spl_fit_upload_fpga() are not evaluated in common/spl
/spl_fit.c. So this error is not propagated to higher layers.
I my use-case uploading the bitstream is mandatory before starting
u-boot.
I expect Simon won't like that it is another weak function.
I did not find another way to implement the above use-cases. Maybe i
missed something.
Based on the above, probably make a weak wrapper around the fpga_load()
call, make it call fpga_load() by default and override it in some board
specific manner if needed.
So instead of the implemented function in this patch, i add
__weak int fpga_load_wrapper(int devnum, const void *buf, size_t bsize,
bitstream_type bstype, int flags) {
return fpga_load(devnum, buf, bsize, bstype, flags);
}
in the file common/spl/spl_fit.c and call this instead of fpga_load()?
This way only the logic for loading the fpga bitstream in the spl from a
fit image would change, but not anywhere else (which is ok for me).
Firstly we should not be using devnum but a struct udevice. Really the
FPGA subsystem needs to be converted to use drivel model properly.
Maybe Xilinx can help here as they are the maintainer of the FPGA framework ?
:-) I will add it to our list. And maybe USB maintainer can keep DWC3 and other
parts taken from Linux kernel aligned with latest version too.
M
