From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Thu, 02 Oct 2014 08:13:07 +0200 Subject: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset In-Reply-To: <20141001230754.GA1529@amd> References: <1412176391-24475-1-git-send-email-sr@denx.de> <1412176391-24475-5-git-send-email-sr@denx.de> <201410012025.55937.marex@denx.de> <542C4E8B.7000807@denx.de> <542C5518.7090801@denx.de> <20141001230754.GA1529@amd> Message-ID: <542CECF3.1090204@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 02.10.2014 01:07, Pavel Machek wrote: > On Wed 2014-10-01 21:25:12, Stefan Roese wrote: >> On 01.10.2014 21:04, Jagan Teki wrote: >>>>>> This is needed for the SoCFPGA booting from SPI NOR flash >>>>>> e.g. (N25Q256A). With these changes, the SoCrates can boot and >>>>>> re-boot (reset) from SPI NOR flash without any problems. >>>>> >>>>> >>>>> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to >>>>> your >>>>> board please? >>>>> >>>>> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot >>>> >>>> >>>> Yes. This seems to be that case. But I can't change it right now. So this >>>> "solution" with the soft-reset is better than nothing. >>> >>> If this is some think that must require, any possibility to this >>> resetting prior to u-boot? >>> like preloader or in first stage boot loader or something. >> >> Perhaps I was not clear with the intention of this patch. Its more to show >> how the problem with SPI flash on this platform / board (SoCrates in this >> case) can be solved. So that others have a reference. Thats why I marked it >> as RFC. Its not really meant for inclusion into mainline. >> >> The real solution is a board rework. If not possible, the preloader should >> be changed. As I don't have access to the preloader code right now, this >> "solution" (I know, its more a hack) didn't seem too bad. > > For the record, I do not think preloader is good place for such > workaround. Preloader works with SDRAM, and should load real u-boot as > fast as possible. If it does not need to touch SPI (it does not, > right?) it should not need to work around bugs there. In this case, where the board boots from SPI NOR flash, the Preloader (SPL U-Boot version) does use SPI. To load the main U-Boot image from the SPI NOR flash. My current best guess is that this define in the Preloader (older SPL U-Boot version) causes these problems: #define CONFIG_SPI_FLASH_QUAD (1) Once I have full access to the Preloader source (in a few days hopefully) I can verify this. Thanks, Stefan