From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Wed, 27 Sep 2017 13:33:46 +0530 Subject: [U-Boot] [PATCH v2] sf: bar: Clean BA24 Bank Address Register bit after read/write/erase operation In-Reply-To: References: <1506336008-21852-1-git-send-email-lukma@denx.de> <1b652f54-0783-12bb-5d89-0038d2bdde0f@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Wed, Sep 27, 2017 at 1:24 PM, Łukasz Majewski wrote: > Hi Jagan, > > >> On Tue, Sep 26, 2017 at 12:37 PM, Łukasz Majewski wrote: >>> >>> On 09/26/2017 07:40 AM, Jagan Teki wrote: >>>> >>>> >>>> On Mon, Sep 25, 2017 at 4:10 PM, Lukasz Majewski wrote: >>>>> >>>>> >>>>> The content of Bank Address Register (BAR) is volatile. It is cleared >>>>> after power cycle or reset command (RESET F0h). >>>>> >>>>> Some memories (like e.g. s25fl256s) use it to access memory larger than >>>>> 0x1000000 (16 MiB). >>>>> >>>>> The problem shows up when one: >>>>> >>>>> 1. Reads/writes/erases memory > 16 MiB >>>>> 2. Calls "reset" u-boot command (which is not causing BAR to be >>>>> cleared) >>>>> >>>>> In the above scenario, the SoC ROM sends 0x000000 address to read SPL. >>>>> Unfortunately, the BA24 bit is still set and hence it receives content >>>>> from 0x1000000 (16 MiB) memory address. >>>>> As a result the SoC aborts and we hang. Only power cycle can take the >>>>> SoC out of this state. >>>>> >>>>> How to reproduce/test: >>>>> >>>>> sf probe; sf erase 0x1200000 0x800000; reset >>>>> sf probe; sf erase 0x1200000 0x800000; sf write 0x11000000 0x1200000 >>>>> 0x800000; reset >>>>> sf probe; sf read 0x11000000 0x1200000 0x800000; reset >>>> >>>> >>>> >>>> Sorry, I didn't follow this test.. are you writing on at 18MiB offset >>>> and doing reset how it will reproduce? >>> >>> >>> >>> Please start with erase test case first. >>> >>> The problem shows up when you try to access SPI-NOR memory > 16 MiB. >>> It works with current code, since BAR is adjusted properly. >>> >>> Then after this access (without removing power), please type 'reset' >>> command. >>> >>> You will observe, that the board will not boot (if SPI-NOR is a booting >>> device). >>> >>> The problem is that ROM bootloader tries to access 0x0 address, but BA24 >>> (in >>> the SPI-NOR controller) is programmed from last operation (to 0x1). >>> Hence, >>> the ROM Boot reads from 0x1000000 address. >>> >>> >>>> because we can write it 0x0 and >>>> after reset the ROM look for 16MiB on this flash this is what you >>>> concern about right? >> >> >> Yes, I understand ROM look at 16MiB, but the test-case you have erase >> is from 18MiB right, it should be 0x0 on the test case right? > > > No it is correct. > > The value 0x12000000 must only be > 16 MiB. After accessing this location, > the BA24 bit is set. > > Then after "reset" the BA24 is still set and hence BOOT ROM reads from wrong > address. OK, I was thinking in other way around even that has similar issue. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.