From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3D0F5C32771 for ; Fri, 19 Aug 2022 09:30:27 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DE11084B0B; Fri, 19 Aug 2022 11:30:25 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="QpVIhUKX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B14D784B0B; Fri, 19 Aug 2022 11:30:23 +0200 (CEST) Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 0F94584AFA for ; Fri, 19 Aug 2022 11:30:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=nm@ti.com Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 27J9UHP0071139; Fri, 19 Aug 2022 04:30:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1660901417; bh=XFTT114JmCnW6plrs54h2lLDFDCQLFh+wQ/m/73IKXM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=QpVIhUKXrWy09Y+2QIj/c8w80Va+hdTRKQ1PAgF4owwY9gSr7WafPUQS8KX4nO8kg f/49tB7AK0DQDMe2hGKOKufnYKN5shzEKx08jD35JWk+iJbuIkBO7YAplQOtB271+V PU2a0cSAYbib1MfSjxxWS4tce7tUBg0Drsu4aa+k= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 27J9UHS4097235 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Aug 2022 04:30:17 -0500 Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Fri, 19 Aug 2022 04:30:16 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Fri, 19 Aug 2022 04:30:16 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 27J9UG68109469; Fri, 19 Aug 2022 04:30:16 -0500 Date: Fri, 19 Aug 2022 04:30:16 -0500 From: Nishanth Menon To: "Matwey V. Kornilov" CC: , , Subject: Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf Message-ID: <20220819093016.diyfagg7hds7tbwv@reoccupy> References: <20220818082805.6575-1-matwey.kornilov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20220818082805.6575-1-matwey.kornilov@gmail.com> User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On 11:28-20220818, Matwey V. Kornilov wrote: > I've played a little and now I believe that the issue is that EEPROM read addr > pointer is somehow corrupted due to 1-byte address write. The EEPROM is > definitely have two-byte read address accoring the datasheet. > I've failed to unravel exact rule what is happening when only one address byte > is set, but was able to read random places of EEPROM. > > > However, the following diff makes the board bootable. > > > diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c > index ed34991377..26edddccc6 100644 > --- a/board/ti/common/board_detect.c > +++ b/board/ti/common/board_detect.c > @@ -86,7 +86,6 @@ __weak void gpi2c_init(void) > static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr, > u32 header, u32 size, uint8_t *ep) > { > - u32 hdr_read = 0xdeadbeef; > int rc; > > #if CONFIG_IS_ENABLED(DM_I2C) > @@ -113,10 +112,10 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr, > * We must allow for fall through to check the data if 2 byte > * addressing works > */ > - (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4); > + rc = dm_i2c_read(dev, 0, ep, size); > > /* Corrupted data??? */ > - if (hdr_read != header) { > + if (rc || (*((u32*)ep) != header)) { > /* > * read the eeprom header using i2c again, but use only a > * 2 byte address (some newer boards need this..) > @@ -125,16 +124,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr, > if (rc) > return rc; > > - rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4); > + rc = dm_i2c_read(dev, 0, ep, size); > if (rc) > return rc; > } > - if (hdr_read != header) > + if (*((u32*)ep) != header) > return -1; > > - rc = dm_i2c_read(dev, 0, ep, size); > - if (rc) > - return rc; > #else > u32 byte; This does work. I tested a few variations of boards to check this concept out.. but anyways.. on beaglebone black (element 14 boards): NOTE: This will improve detection times for 1 byte eeprom based boot, since there is no retry.. However for boards with 2 byte addressing eeproms: master branch: https://pasteboard.co/n3P8yhSq6pem.png Time from first attempt to read eeprom to actual trigger of final eeprom read attempt: ~4ms With this patch: https://pasteboard.co/IVQzHwMuhc4p.png Time from first attempt to read eeprom to actual trigger of final eeprom read attempt: ~18ms IMHO, 14ms penalty is'nt a bad deal for dealing with variations of eeproms we are seeing in the wild. You can find the data (analog+digital capture) here: https://github.com/nmenon/data-captures/tree/main/i2c-eeprom-1byte-captures Tool used to capture (and view): https://www.saleae.com/downloads/ Tom, Robert, folks: what do you folks think? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D