All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] FEC and EFI Simple Network
Date: Sun, 24 Feb 2019 05:48:43 +0100	[thread overview]
Message-ID: <77b4fa1d-582b-ecd2-32c4-d661788decc8@gmx.de> (raw)
In-Reply-To: <e89566d3-33ac-f0e5-4b4c-022eca0a6067@suse.de>

On 2/23/19 3:23 PM, Alexander Graf wrote:
> 
> 
> On 02.12.18 22:42, Alexander Graf wrote:
>>
>>
>> On 29.03.18 06:02, Joe Hershberger wrote:
>>> Hi Patrick,
>>>
>>> On Wed, Mar 28, 2018 at 4:54 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>> Adding Joe in case he has some ideas.
>>>>
>>>> On Tue, Mar 27, 2018 at 9:12 AM, Patrick Wildt <patrick@blueri.se> wrote:
>>>>> Hi,
>>>>>
>>>>> I have been debugging network issues when running an EFI Application
>>>>> that uses the EFI Simple Network protocol on an i.MX6 machine (FEC).
>>>>>
>>>>> The symptom is that u-boot's (FEC) internal RX ring index is reset to 0,
>>>>> while the controller is still at idx 3 (or something else).  This is
>>>>> caused by the following circumstances:
>>>>>
>>>>> The Simple Network protocol offers methods like Start(), Stop(),
>>>>> Initialize(), Shutdown(), Reset().  Also the protocol has a state.  The
>>>>> states are Stopped, Started, Initialized.  The transition is as follows:
>>>>>
>>>>> Stopped ---Start()---> Started ---Initialize()--> Initialized
>>>>>
>>>>> Start() does some initialization, Initialize() allocates the TX/RX
>>>>> descriptors and actually kicks off the network engine.
>>>>>
>>>>> So far, only Initialize() is implemented in our u-boot interface, and it
>>>>> calls eth_init() which in the end calls fec_init().  Our network state
>>>>> is _always_ Started.  This means that EFI Applications see that that the
>>>>> state is Started and then call Initialize() to start the actual network
>>>>> traffic.  There is no call to Stop()/Shutdown()/Reset() as it's supposed
>>>>> to be in a sane state.
>>>>>
>>>>> In my case the FEC is already initialized since I booted using network
>>>>> and the RX desc index is already non-zero.  Now the EFI Application sees
>>>>> that the state is Started, calls Initialize() which makes u-boot call
>>>>> eth_init() which then calls fec_init().
>>>>>
>>>>> fec_init() does not reset the controller so that the controller-internal
>>>>> RX desc index is not reset to zero.  fec_init() calls fec_open() which
>>>>> then resets the driver-internal RX desc index to zero.  Now they are out
>>>>> of sync, boom.
>>>
>>> Would it be reasonable for fec_init to use a state variable to keep
>>> track of if it (and the HW) is already initialized and not call
>>> fec_open in that case? Also, fec_halt would need to update that state
>>> as well.
>>
>> Ping? Is this still an issue?
> 
> Last Ping.
> 
> 
> Alex
> 

With commit 0c5d2a3dac01 ("efi_loader: completely initialize network")
we changed efi_net_initialize() from only calling eth_init() to execute
the following sequence:

        /* Setup packet buffers */
        net_init();
        /* Disable hardware and put it into the reset state */
        eth_halt();
        /* Set current device according to environment variables */
        eth_set_current();
        /* Get hardware ready for send and receive operations */
        ret = eth_init();

So I am wondering if our additional call to eth_halt() shouldn't have
fixed the problem that Patrick originally reported.

Best regards

Heinrich

      reply	other threads:[~2019-02-24  4:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 12:12 [U-Boot] FEC and EFI Simple Network Patrick Wildt
2018-03-28 21:54 ` Fabio Estevam
2018-03-29  4:02   ` Joe Hershberger
2018-12-02 21:42     ` Alexander Graf
2019-02-23 14:23       ` Alexander Graf
2019-02-24  4:48         ` Heinrich Schuchardt [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=77b4fa1d-582b-ecd2-32c4-d661788decc8@gmx.de \
    --to=xypron.glpk@gmx.de \
    --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.