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

[Marek Vasut]

On 5/7/19 9:43 PM, Simon Goldschmidt wrote:
> 
> 
> 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?

That could indeed be, maybe someone on the CC list can take a look into
it and crosscheck it with internal docs ?

-- 
Best regards,
Marek Vasut