From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Wed, 6 Apr 2016 12:45:28 +0800 Subject: [U-Boot] [PATCH 2/2] mx6slevk: imximage.cfg: update to fix tINIT3 and tIH-CA violations In-Reply-To: <20160405134311.GD23166@bill-the-cat> References: <1459547691-7462-1-git-send-email-trini@konsulko.com> <1459547691-7462-3-git-send-email-trini@konsulko.com> <57015156.7000902@denx.de> <20160403180605.GL23166@bill-the-cat> <20160405085326.GA30800@linux-7smt.suse> <20160405134311.GD23166@bill-the-cat> Message-ID: <20160406044526.GA9630@linux-7smt.suse> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On Tue, Apr 05, 2016 at 09:43:11AM -0400, Tom Rini wrote: >On Tue, Apr 05, 2016 at 04:53:28PM +0800, Peng Fan wrote: >> Hi Tom, >> >> I know this already merged to i.mx tree. I still have a question for the >> tIH-CA violation. > >It's not in mainline 'tho so it can always come out :) > >> In my side, the value is ok. clk is 400MHz. >> (0x30 * 256.0) * (1000000000000.0/400000000.0) = 468.75ps. >> And according to spec, to 800M date rate, the minimum tIH value is 290ps. >> >> So I wonder how in your side it is tIH-CA violation. > >The board we measured this on is based on the mx6slevk and this >particular part of the board (layout, etc) is unchanged. Micron put the >board under analysis and measured these violations (along with that we >don't issue a reset before configuring CS1, I still might try and push >that change up for the EVK at least, not armadillo tho). I have no way to measure the signals (:. So just formula computing: If setting the value to 0x40, then tIH is (0x40 / 256.0) * (1000000000000.0/400000000.0) = 625ps. If setting the value to 0x30, then tIH is (0x30 / 256.0) * (1000000000000.0/400000000.0) = 468.75ps. Both value does not violate the LPDDR2 spec, bigger that 290ps which 800M date rate requires the minimum value. I can not say which value is better. Anyway different board may have different value. since you measured the signals, and value 0x30 is not good, I am ok with your change. Regards, Peng. > >-- >Tom