From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 12 Mar 2020 12:34:18 +0100 Subject: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg() In-Reply-To: References: <7107092b-4025-88a5-079b-9ea1002ca677@denx.de> <87a2193e-dfed-8c78-5e4a-01a4cb36545a@ic-automation.de> <5a684d24-0e60-bed3-a7c0-d53fcd54b7e4@denx.de> <7e87eb65-6fcc-d9a5-e36b-193f5bba9e3d@denx.de> <061dc254-934d-53d5-1446-cdcf16a85e5e@denx.de> <515836a3-d276-da15-616b-679ad87408ff@denx.de> <984eb7aa-f14a-02a3-6c3b-8da0c32f5ddf@denx.de> Message-ID: <3ba24f4d-91ac-b9c7-c0b8-6ae19a549603@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 3/12/20 10:31 AM, Ley Foon Tan wrote: > On Wed, Mar 11, 2020 at 5:58 PM Marek Vasut wrote: >> >> On 3/11/20 10:54 AM, Ley Foon Tan wrote: >>> On Mon, Mar 9, 2020 at 10:10 PM Simon Goldschmidt >>> wrote: >>>> >>>> On Mon, Mar 9, 2020 at 1:57 PM Marek Vasut wrote: >>>>> >>> >>>>>>> >>>>>> >>>>>> I can reproduce the issue if without setting applycfg bit. Access to >>>>>> F2sdram interface will cause system hang. >>>>>> >>>>>> From the Cyclone 5 Soc datasheet: >>>>>> applycfg - Write with this bit set to apply all the settings loaded in >>>>>> SDR registers to the memory interface. This bit is write-only and >>>>>> always returns 0 if read. >>>>>> >>>>>> Software should set applycfg bit if change any register under SDR >>>>>> register range. SW is allowed to set this bit multiple times, the only >>>>>> condition is SDRAM need to be idle. >>>>>> My suggestion is we add back socfpga_sdram_apply_static_cfg(), but >>>>>> change the sequence to below: >>>>>> writel(iswgrp_handoff[3], &sdr_ctrl->fpgaport_rst); >>>>>> socfpga_sdram_apply_static_cfg(); >>>>>> >>>>>> Marek and Simon, are you okay with this? If yes, I will submit patch for this. >>>>> >>>>> The problem was that this was causing weird sporadic hangs on Gen5, >>>>> which is why it was removed. So until there is an explanation for those >>>>> hangs, I'm not really OK with this. >>>> >>>> These sporadic hangs you saw were on devices without an FPGA image directly >>>> accessing the SDRAM ports, right? >>>> >>>>> >>>>> Maybe the application of static config should happen in SPL, before the >>>>> DRAM is running, or something like that ? >>>> >>>> Thinking this further, limiting it to applying in SPL is not a good idea since >>>> that prevents us from implementing different FPGA images/configs by loading a >>>> config later in the boot (i.e. in U-Boot from a FIT-image). >>>> >>>> Would it work to make setting this optional, i.e. only write the bit if an FPGA >>>> config actually uses these ports? Then it couldn't lead to problems on other >>>> hardware... >>> >>> If the sporadic hangs issue happen on FPGA image that doesn't connect >>> to f2sdram interface, we can add the checking to only apply static cfg >>> when it has f2sdram port enabled. >>> It can send a patch with this checking for you to try if want. >> Well, what could cause that sporadic hang ? >> Yes, the hang happens on image which doesn't access the SDRAM IIRC. >> > Do you remember if the hang happen when run bridge enable/disable > command? Or other flow? FPGA bitstream was loaded via the fpga command , and then during the bridge enable it got stuck. > I have tested the following sequence 500 times with FPGA image that > doesn't contains fs2dram bridge, but didn't see the hang. > - program fpga image > - bridge enable > - write to h2f bridge > - read from h2f bridge > - bridge disable > - repeat step 1 The test we did also contained booting Linux inbetween, and then reboot through U-Boot, which loaded the bitstream , enabled bridges , started Linux, reboot etc. -- Best regards, Marek Vasut