[U-Boot] FEC and EFI Simple Network
Heinrich Schuchardt
xypron.glpk at gmx.de
Sun Feb 24 04:48:43 UTC 2019
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 at gmail.com> wrote:
>>>> Adding Joe in case he has some ideas.
>>>>
>>>> On Tue, Mar 27, 2018 at 9:12 AM, Patrick Wildt <patrick at 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
More information about the U-Boot
mailing list