mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: e1000 driver hangs during probe
Date: Fri, 10 Mar 2017 05:09:48 -0800	[thread overview]
Message-ID: <CAHQ1cqEZ=XMiXveOrD+hXYGz_4a83OAZthicMxgAEeGVDLeD_w@mail.gmail.com> (raw)
In-Reply-To: <1489137610.24921.2.camel@pengutronix.de>

On Fri, Mar 10, 2017 at 1:20 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Freitag, den 10.03.2017, 10:10 +0100 schrieb Uwe Kleine-König:
>> On Thu, Mar 09, 2017 at 08:04:08PM -0800, Andrey Smirnov wrote:
>> > On Thu, Mar 9, 2017 at 1:18 PM, Uwe Kleine-König
>> > <u.kleine-koenig@pengutronix.de> wrote:
>> > > Hello,
>> > >
>> > > I work with an i.MX6 based hardware that has an i210 pcie device with
>> > > barebox 2016.11.0 (but there didn't happen anything relevant since them
>> > > if I'm not mistaken). When enabling all necessary things to make the
>> > > e1000 bind, the driver seems to hang. The problem is the following code
>> > > in e1000_get_hw_eeprom_semaphore():
>> > >
>> > >         /* Get the FW semaphore. */
>> > >         timeout = hw->eeprom.word_size + 1;
>> > >         while (timeout) {
>> > >                 swsm = e1000_read_reg(hw, E1000_SWSM);
>> > >                 swsm |= E1000_SWSM_SWESMBI;
>> > >                 e1000_write_reg(hw, E1000_SWSM, swsm);
>> > >                 /* if we managed to set the bit we got the semaphore. */
>> > >                 swsm = e1000_read_reg(hw, E1000_SWSM);
>> > >                 if (swsm & E1000_SWSM_SWESMBI)
>> > >                         break;
>> > >
>> > >                 udelay(50);
>> > >                 timeout--;
>> > >         }
>> > >
>> > > together with the fact that hw->eeprom.word_size is either 0x200000 or
>> > > 0x400000. (I saw both values already in three runs) This value is setup
>> > > in e1000_init_eeprom_params() in the hw->mac_type == e1000_igb case.
>> > >
>> > > When waiting log enough the code finally terminates with a failure.
>> > >
>> > > In my case there is an 8Mb-Flash equipped on NVM_* that isn't programmed
>> > > yet. (M25PE80, Page size: 256 bytes, Subsector erase: 4KB, Sector erase: 64KB,
>> > > Bulk erase: 8Mb)
>> > >
>> > > Is someone able to shed some light on where the problem is?
>> > >
>> >
>> > This might be a long shot, but when I was working with that exact
>> > combination last year (this board
>> > https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/zii-imx6q-rdu2)
>> > I ran into an issue where while the reads to PCI configuration space
>> > would work and the card would enumerate, access to registers mapped
>> > via any of the BARs would return bogus values. Through trial and error
>> > I was able to come up with a empirical hack to "fix" the issue and was
>> > able to continue working with the driver.
>> >
>> > Several month later Lucas was asked to take a look at the issue and he
>> > was able to figure out the underlying cause and posted a series of
>> > patches fixing the problem:
>> >
>> > http://lists.infradead.org/pipermail/barebox/2016-November/028438.html
>> >
>> > For some reason I am not seeing that whole series even in the latest
>> > master, let alone 2016.11 codebase, so just to rule out you running
>> > into the same problem I did, I'd start by applying that whole series
>> > to your Barebox and seeing if that improves things.
>>
>> With these patches applied the problem is gone and I see:
>>
>>       e1000 pci-8086:1531.0: Unprogrammed Flash detected, limiting access to first 4KB
>>       0: EEPROM checksum is incorrect!
>>       0:   ...register was 0x0000, calculated 0xbaba
>>       e1000 pci-8086:1531.0: probe failed: Invalid argument
>>
>> and I have
>>
>>       / ls -l /dev/e1000-nor0
>>       crw-------           4096 /dev/e1000-nor0
>>
>> Thanks for your valuable hint.
>>
>> Sascha: If you want, interpret this as "Tested-by:".
>
> This series has already been applied for a long time. It found it's way
> into the v2017.01.0 release.

I wasn't looking at the right place for those patches in the master.
Ignore my comment about them not being there. Sorry for the false
alarm.

Thanks,
Andrey Smirnov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2017-03-10 13:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 21:18 Uwe Kleine-König
2017-03-10  4:04 ` Andrey Smirnov
2017-03-10  9:10   ` Uwe Kleine-König
2017-03-10  9:13     ` Uwe Kleine-König
2017-03-10  9:20     ` Lucas Stach
2017-03-10 13:09       ` Andrey Smirnov [this message]

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='CAHQ1cqEZ=XMiXveOrD+hXYGz_4a83OAZthicMxgAEeGVDLeD_w@mail.gmail.com' \
    --to=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=l.stach@pengutronix.de \
    --cc=u.kleine-koenig@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox