e1000 driver hangs during probe

Andrey Smirnov andrew.smirnov at gmail.com
Thu Mar 9 20:04:08 PST 2017


On Thu, Mar 9, 2017 at 1:18 PM, Uwe Kleine-König
<u.kleine-koenig at 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.

Sascha, was that series intentionally ignored or did it just slip
thought the cracks?

Unfortunately I have a very mediocre memory and, besides that obscure
anecdote, I don't think I'd be able to recall any details pertaining
to how i210's flash access IP works, so I hope this helps.

Thanks,
Andrey Smirnov



More information about the barebox mailing list