[U-Boot] [PATCH] ARM: socfpga: Fix FPGA bitstream loading code

Simon Goldschmidt simon.k.r.goldschmidt at gmail.com
Tue May 7 19:43:55 UTC 2019



On 07.05.19 21:41, Marek Vasut wrote:
> On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
>>
>>
>> On 07.05.19 21:19, Marek Vasut wrote:
>>> According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
>>> (Chapter 5, FPGA Manager, data register) and Arria10 datasheet
>>> rev.2017.07.22 page 211 (Chapter 5.4.1.2, FPGA Manager, img_data_w
>>> register), the FPGA data register must be written with writes with
>>> non-incrementing address.
>>>
>>> The current code increments the address in 32-byte bursts. Fix the
>>> code so it does not increment the address and writes the register
>>> repeatedly instead. >
>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>> Cc: Chin Liang See <chin.liang.see at intel.com>
>>> Cc: Dinh Nguyen <dinguyen at kernel.org>
>>> Cc: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
>>> Cc: Tien Fong Chee <tien.fong.chee at intel.com>
>>> ---
>>>    drivers/fpga/socfpga.c | 3 +--
>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
>>> index 685957626b..6ecea771ce 100644
>>> --- a/drivers/fpga/socfpga.c
>>> +++ b/drivers/fpga/socfpga.c
>>> @@ -55,8 +55,7 @@ void fpgamgr_program_write(const void *rbf_data,
>>> size_t rbf_size)
>>>            "    cmp    %2,    #0\n"
>>>            "    beq    2f\n"
>>>            "1:    ldmia    %0!,    {r0-r7}\n"
>>> -        "    stmia    %1!,    {r0-r7}\n"
>>> -        "    sub    %1,    #32\n"
>>> +        "    stmia    %1,    {r0-r7}\n"
>>
>> Iirc, stmia without the "!" still stores the registers to different
>> addresses, it just does not change %1 any more if you leave away the
>> "!"? So this would save on opcode, but not change anything?
> 
> Uh oh, you're right. Do we have a bigger problem here then ? Or is the
> socfpga ignoring the bottom 5 bits of this register address ?

Well, bitsream programming works for me very well (we're loading all our 
FGPAs in U-Boot from a FIT image), so maybe it's the documentation that 
has a problem?

Regards,
Simon


More information about the U-Boot mailing list