All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: "Matwey V. Kornilov" <matwey.kornilov@gmail.com>
Cc: <u-boot@lists.denx.de>, <robertcnelson@gmail.com>, <trini@konsulko.com>
Subject: Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
Date: Fri, 19 Aug 2022 04:30:16 -0500	[thread overview]
Message-ID: <20220819093016.diyfagg7hds7tbwv@reoccupy> (raw)
In-Reply-To: <20220818082805.6575-1-matwey.kornilov@gmail.com>

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

  reply	other threads:[~2022-08-19  9:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 16:20 [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf Matwey V. Kornilov
2022-07-29 16:32 ` Tom Rini
2022-07-29 16:38   ` Matwey V. Kornilov
2022-07-29 16:46     ` Tom Rini
2022-07-29 17:06       ` Matwey V. Kornilov
2022-08-02  7:46         ` Matwey V. Kornilov
2022-08-05 15:00         ` Robert Nelson
2022-08-07  8:40           ` Matwey V. Kornilov
2022-08-10 22:52             ` Nishanth Menon
2022-08-11  6:56               ` Matwey V. Kornilov
2022-08-11  7:47                 ` Matwey V. Kornilov
2022-08-11 12:46                   ` Tom Rini
2022-08-11 12:53                     ` Alex Kiernan
2022-08-11 16:11                       ` Matwey V. Kornilov
2022-08-13 15:31                         ` Matwey V. Kornilov
2022-08-13 15:42                           ` Tom Rini
2022-08-13 15:50               ` Matwey V. Kornilov
     [not found]                 ` <20220815121657.nvjae4zjjftfo4gb@matcher>
2022-08-15 17:30                   ` Matwey V. Kornilov
2022-08-15 17:53                     ` Nishanth Menon
2022-08-15 18:12                       ` Matwey V. Kornilov
     [not found]                         ` <20220815195644.l6or6z6hg5igxzzm@humbly>
     [not found]                           ` <CAJs94EbKW3OLKXxTUX7PANWkY5QEOC0DREfhxP6fTOVEFydbdA@mail.gmail.com>
     [not found]                             ` <CAJs94Ea-2n56j-=gu4VyjQMro9nQFCj7JtRQVTGSSoAc+CqbVw@mail.gmail.com>
     [not found]                               ` <CAJs94EbReuKoq_28jrdrdHQDmpAn9zW0YS=9s20yS=p_mF5pNA@mail.gmail.com>
     [not found]                                 ` <20220816012722.bt2xcizturouc4fi@nursing>
2022-08-16 14:18                                   ` Matwey V. Kornilov
2022-08-18  8:28                                     ` Matwey V. Kornilov
2022-08-19  9:30                                       ` Nishanth Menon [this message]
2022-08-19 13:56                                         ` Robert Nelson
2022-08-23  3:54                                           ` Nishanth Menon
2022-08-23  5:47                                             ` Matwey V. Kornilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220819093016.diyfagg7hds7tbwv@reoccupy \
    --to=nm@ti.com \
    --cc=matwey.kornilov@gmail.com \
    --cc=robertcnelson@gmail.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.