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 <ma...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot