From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: socfpga: Fix FPGA bitstream loading code
Date: Wed, 9 Oct 2019 20:06:21 +0200 [thread overview]
Message-ID: <27dcb43a-bb97-3292-85ee-3cc596a8a058@gmail.com> (raw)
In-Reply-To: <d7cefc63-92ee-628c-9244-5ecc90f47ed5@denx.de>
Marek,
Am 13.05.2019 um 15:12 schrieb Marek Vasut:
> On 5/13/19 2:58 PM, Chee, Tien Fong wrote:
>> On Thu, 2019-05-09 at 10:34 +0200, Marek Vasut wrote:
>>> On 5/9/19 5:57 AM, Chee, Tien Fong wrote:
>>>>
>>>> On Wed, 2019-05-08 at 14:55 +0200, Marek Vasut wrote:
>>>>>
>>>>> On 5/8/19 12:17 PM, Chee, Tien Fong wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, 2019-05-07 at 21:44 +0200, Marek Vasut wrote:
>>>>>>>
>>>>>>>
>>>>>>> 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@denx.de>
>>>>>>>>>>> Cc: Chin Liang See <chin.liang.see@intel.com>
>>>>>>>>>>> Cc: Dinh Nguyen <dinguyen@kernel.org>
>>>>>>>>>>> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.co
>>>>>>>>>>> m>
>>>>>>>>>>> Cc: Tien Fong Chee <tien.fong.chee@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 ?
>>>>>> I can't find any doc mention about "FPGA data must be written
>>>>>> in
>>>>>> non-
>>>>>> incremting address", but i saw there is a description about
>>>>>> configuration data is buffered in a 64 deep x 32 bits wide FIFO
>>>>>> in
>>>>>> the
>>>>>> FPGA Manager https://www.intel.com/content/dam/www/programmable
>>>>>> /us/
>>>>>> en/p
>>>>>> dfs/literature/hb/arria-10/a10_5v4.pdf (pg. 204)
>>>>> Well yes, it's a FIFO, but is the FIFO populated by writing to a
>>>>> single
>>>>> non-incrementing address or are we supposed to write to
>>>>> subsequent
>>>>> incrementing addresses ?
>>>>>
>>>>>>
>>>>>>
>>>>>> Based on my understand through this register
>>>>>> fpga_mgr_fpgamgrdata
>>>>>> address map (0xFFCFE400-0xFFCFE7FF) on pg. 207 , the 256 bytes
>>>>>> of
>>>>>> FIFO
>>>>>> buffer is mapping to above range addresses.
>>>>> 0xFFCFE7FF-0xFFCFE400 = 0x400 = 1024 Bytes , not 256 . Why ?
>>>> Finally, i have connected all scattered dot information from few
>>>> internal docs. The register fpga_mgr_fpgamgrdata is actually a
>>>> space in
>>>> memory, acting like a buffer for the FPGA data. Regardless of the
>>>> programming mode, data input from this buffer is translated into a
>>>> 32-
>>>> bit wide data path used by the configuration logic.
>>> Does that mean that a write anywhere in 0xFFCFE400..0xFFCFE7FF ends
>>> up
>>> in the same register / FIFO ? Does that mean that whole address range
>>> ignores the bottom 0x3ff MSbits ? Does it matter to which address in
>>> that range the CPU writes the data or not ?
>>
>> Sorry, that's all information i have. Anyway, i have already engaged
>> the HW engineer in the loop, and i will update you once i have more
>> details.
>
> Thanks, let's wait and see ...
Have you dropped this? It's assigned to me in patchwork (I'm going
through the list of old items assigned to me...).
Regards,
Simon
next prev parent reply other threads:[~2019-10-09 18:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 19:19 [U-Boot] [PATCH] ARM: socfpga: Fix FPGA bitstream loading code Marek Vasut
2019-05-07 19:36 ` Simon Goldschmidt
2019-05-07 19:41 ` Marek Vasut
2019-05-07 19:43 ` Simon Goldschmidt
2019-05-07 19:44 ` Marek Vasut
2019-05-08 3:51 ` Chee, Tien Fong
2019-05-08 10:17 ` Chee, Tien Fong
2019-05-08 12:55 ` Marek Vasut
2019-05-09 3:57 ` Chee, Tien Fong
2019-05-09 8:34 ` Marek Vasut
2019-05-13 12:58 ` Chee, Tien Fong
2019-05-13 13:12 ` Marek Vasut
2019-10-09 18:06 ` Simon Goldschmidt [this message]
2019-10-09 20:47 ` Marek Vasut
2019-10-10 5:15 ` Simon Goldschmidt
2019-10-10 7:21 ` Marek Vasut
2019-11-29 7:32 ` jérémy alcim
2019-12-01 20:02 ` Simon Goldschmidt
-- strict thread matches above, loose matches on Subject: below --
2019-03-22 14:29 Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27dcb43a-bb97-3292-85ee-3cc596a8a058@gmail.com \
--to=simon.k.r.goldschmidt@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox