[U-Boot] [PATCH] ARM SOCFPGA: add resetmgr command so reset can be deasserted in bootcmd (for example on peripheral dma interfaces after fpga has been programmed).

[Marek Vasut]

On 12/15/2017 06:07 PM, Frank Mori Hess wrote:

Please always CC the list. Do NOT top-post.

> Would you consider it more worthwhile if it included the
> reset_config.h generated by Quartus (currently ignored by mainline
> u-boot) and figured out which reset lines needed to be deasserted on
> its own?

What is your goal here ?

> Or, what if that function was integrated into the "bridge"
> command?

No, that's for controlling the bridges.

> Are you against defining commands?

I am against polluting U-Boot with ad-hoc commands without any concept.

> If so, why does the
> "bridge" command exist anyways, wasn't there a bridge_enable_handoff
> in the u-boot env before that did the same thing?

Because that one didn't work. Notice that the bridge command runs some
assembly locked to cacheline.

> The current
> situation is poor, if you have anything in your fpga that uses dma
> then reset_config.h is ignored and the dma simply doesn't work.  It is
> up to the end user to figure out why.  The altera version of u-boot
> has a reset_deassert_peripherals_handoff which handles this stuff, I'm
> not sure what the rationale was for dropping it although it did seem
> to get called way too early as far as the dma reset deassert goes.

Going back to my initial question -- what is your usecase and your aim
here ? Usually you use FPGA manager in Linux to load the FPGA.

> On Fri, Dec 15, 2017 at 2:14 AM, Marek Vasut <marex at denx.de> wrote:
>> On 12/14/2017 10:03 PM, Frank Mori Hess wrote:
>>
>> Commit message is missing, SoB line is missing etc
>> https://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules
>>
>> But you can really just do mw to the correct address or create a U-Boot
>> script , so this command is not really needed, is it ?
>>


-- 
Best regards,
Marek Vasut