All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Ping failure
@ 2018-11-05 17:07 Paul Nader
  2018-11-05 17:10 ` Paul Nader
  2018-11-06  9:45 ` Chris Packham
  0 siblings, 2 replies; 7+ messages in thread
From: Paul Nader @ 2018-11-05 17:07 UTC (permalink / raw)
  To: u-boot

Hi,

I'm trying to get an olinuxino-a64 board to boot using bootp but it failed
to send any DHCP packets so I reduced the problem to trying to get it to
ping another host but that fails as well.

I tried it both with 2018.09 and then the head of master given there were
some recent commits to the net area to fix handling asynchronous responses.

I'm testing this  by having the board ethernet connected to a switch and
another port of the switch to a host running wireshark snooping packets in
promiscuous mode.

If I let the board boot completely (ie start the kernel) and configure the
interface I can ping the host without any issues, so I assume the dtb is
ok.

However, if I interrupt the boot and try to ping tho host from within
u-boot I get:

U-Boot SPL 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1


U-Boot 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000) Allwinner
Technology

CPU:   Allwinner A64 (SUN50I)
Model: Olimex A64-Olinuxino
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet at 1c30000
starting USB...
No controllers found
Hit any key to stop autoboot:  0
=> setenv ipaddr 192.168.0.2
=> log level 10
=> setenv netmask 255.255.255.0
_do_env_set() Initial value for argc=3
_do_env_set() Final value for argc=3
=> ping 192.168.0.1
net_loop() --- net_loop Entry
net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
net_set_timeout_handler() --- net_loop timeout handler cancelled
_do_env_set() Initial value for argc=3
_do_env_set() Final value for argc=3
eth_init() Trying ethernet at 1c30000
net_set_state() --- NetState set to 0
net_loop() --- net_loop Init
Using ethernet at 1c30000 device
net_set_timeout_handler() --- net_loop timeout handler set
(000000007dfa4cf0)
ping_send() sending ARP for 192.168.0.1
arp_raw_request() ARP broadcast 1
arp_raw_request() ARP broadcast 2
arp_raw_request() ARP broadcast 3
arp_raw_request() ARP broadcast 4

ARP Retry count exceeded; starting again
net_set_state() --- NetState set to 3
net_set_state() --- NetState set to 3
net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
net_set_timeout_handler() --- net_loop timeout handler cancelled
net_loop() --- net_loop Fail!
net_set_state() --- NetState set to 0
ping failed; host 192.168.0.1 is not alive
cmd_call() Command failed, result=1
=>

The lines:
net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)

seem a bit odd to me but they may be correct.

I'm stuck and don't really know how to proceed. Any suggestions please?

Thanks

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
  2018-11-05 17:07 [U-Boot] Ping failure Paul Nader
@ 2018-11-05 17:10 ` Paul Nader
  2018-11-06  9:45 ` Chris Packham
  1 sibling, 0 replies; 7+ messages in thread
From: Paul Nader @ 2018-11-05 17:10 UTC (permalink / raw)
  To: u-boot

I forgot to add that the ethernet socket shows a green light and when
u-boot sends packets the other led flashes amber...

This puzzles me because wireshark doesn't capture any packets.

On Mon, Nov 5, 2018 at 5:07 PM Paul Nader <paul.nader@gmail.com> wrote:

> Hi,
>
> I'm trying to get an olinuxino-a64 board to boot using bootp but it failed
> to send any DHCP packets so I reduced the problem to trying to get it to
> ping another host but that fails as well.
>
> I tried it both with 2018.09 and then the head of master given there were
> some recent commits to the net area to fix handling asynchronous responses.
>
> I'm testing this  by having the board ethernet connected to a switch and
> another port of the switch to a host running wireshark snooping packets in
> promiscuous mode.
>
> If I let the board boot completely (ie start the kernel) and configure the
> interface I can ping the host without any issues, so I assume the dtb is
> ok.
>
> However, if I interrupt the boot and try to ping tho host from within
> u-boot I get:
>
> U-Boot SPL 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
>
>
> U-Boot 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000) Allwinner
> Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Olimex A64-Olinuxino
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet at 1c30000
> starting USB...
> No controllers found
> Hit any key to stop autoboot:  0
> => setenv ipaddr 192.168.0.2
> => log level 10
> => setenv netmask 255.255.255.0
> _do_env_set() Initial value for argc=3
> _do_env_set() Final value for argc=3
> => ping 192.168.0.1
> net_loop() --- net_loop Entry
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
> net_set_timeout_handler() --- net_loop timeout handler cancelled
> _do_env_set() Initial value for argc=3
> _do_env_set() Final value for argc=3
> eth_init() Trying ethernet at 1c30000
> net_set_state() --- NetState set to 0
> net_loop() --- net_loop Init
> Using ethernet at 1c30000 device
> net_set_timeout_handler() --- net_loop timeout handler set
> (000000007dfa4cf0)
> ping_send() sending ARP for 192.168.0.1
> arp_raw_request() ARP broadcast 1
> arp_raw_request() ARP broadcast 2
> arp_raw_request() ARP broadcast 3
> arp_raw_request() ARP broadcast 4
>
> ARP Retry count exceeded; starting again
> net_set_state() --- NetState set to 3
> net_set_state() --- NetState set to 3
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
> net_set_timeout_handler() --- net_loop timeout handler cancelled
> net_loop() --- net_loop Fail!
> net_set_state() --- NetState set to 0
> ping failed; host 192.168.0.1 is not alive
> cmd_call() Command failed, result=1
> =>
>
> The lines:
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
>
> seem a bit odd to me but they may be correct.
>
> I'm stuck and don't really know how to proceed. Any suggestions please?
>
> Thanks
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
  2018-11-05 17:07 [U-Boot] Ping failure Paul Nader
  2018-11-05 17:10 ` Paul Nader
@ 2018-11-06  9:45 ` Chris Packham
       [not found]   ` <CAD3v2COOAoJfVBdaAZ0BpdcftcX+W4OJbA1EPObAviRK59d+Zg@mail.gmail.com>
  1 sibling, 1 reply; 7+ messages in thread
From: Chris Packham @ 2018-11-06  9:45 UTC (permalink / raw)
  To: u-boot

On Tue, 6 Nov 2018, 6:09 AM Paul Nader <paul.nader@gmail.com wrote:

> Hi,
>
> I'm trying to get an olinuxino-a64 board to boot using bootp but it failed
> to send any DHCP packets so I reduced the problem to trying to get it to
> ping another host but that fails as well.
>
> I tried it both with 2018.09 and then the head of master given there were
> some recent commits to the net area to fix handling asynchronous responses.
>
> I'm testing this  by having the board ethernet connected to a switch and
> another port of the switch to a host running wireshark snooping packets in
> promiscuous mode.
>

Could the switch be dropping the packets? Are the ports in the same vlan?
Is your monitoring host the same host you're trying to ping? (if not you'll
need to configure your switch for mirroring)


> If I let the board boot completely (ie start the kernel) and configure the
> interface I can ping the host without any issues, so I assume the dtb is
> ok.
>
> However, if I interrupt the boot and try to ping tho host from within
> u-boot I get:
>
> U-Boot SPL 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
>
>
> U-Boot 2018.11-rc3-g5ef76e5 (Nov 05 2018 - 16:39:47 +0000) Allwinner
> Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Olimex A64-Olinuxino
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet at 1c30000
> starting USB...
> No controllers found
> Hit any key to stop autoboot:  0
> => setenv ipaddr 192.168.0.2
> => log level 10
> => setenv netmask 255.255.255.0
>

What do you end up with for a mac address? I'm not familiar with the
olinuxino hardware does it have an eeprom for the mac or does it just come
from the environment.

_do_env_set() Initial value for argc=3
> _do_env_set() Final value for argc=3
> => ping 192.168.0.1
> net_loop() --- net_loop Entry
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
> net_set_timeout_handler() --- net_loop timeout handler cancelled
> _do_env_set() Initial value for argc=3
> _do_env_set() Final value for argc=3
> eth_init() Trying ethernet at 1c30000
> net_set_state() --- NetState set to 0
> net_loop() --- net_loop Init
> Using ethernet at 1c30000 device
> net_set_timeout_handler() --- net_loop timeout handler set
> (000000007dfa4cf0)
> ping_send() sending ARP for 192.168.0.1
> arp_raw_request() ARP broadcast 1
> arp_raw_request() ARP broadcast 2
> arp_raw_request() ARP broadcast 3
> arp_raw_request() ARP broadcast 4
>
> ARP Retry count exceeded; starting again
> net_set_state() --- NetState set to 3
> net_set_state() --- NetState set to 3
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
> net_set_timeout_handler() --- net_loop timeout handler cancelled
> net_loop() --- net_loop Fail!
> net_set_state() --- NetState set to 0
> ping failed; host 192.168.0.1 is not alive
> cmd_call() Command failed, result=1
> =>
>
> The lines:
> net_set_udp_handler() --- net_loop UDP handler set (0000000000000000)
> net_set_arp_handler() --- net_loop ARP handler set (0000000000000000)
>
> seem a bit odd to me but they may be correct.
>
> I'm stuck and don't really know how to proceed. Any suggestions please?
>
> Thanks
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
       [not found]   ` <CAD3v2COOAoJfVBdaAZ0BpdcftcX+W4OJbA1EPObAviRK59d+Zg@mail.gmail.com>
@ 2018-11-06 10:54     ` Paul Nader
  2018-11-08 20:19       ` Paul Nader
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Nader @ 2018-11-06 10:54 UTC (permalink / raw)
  To: u-boot

I'll try without the switch using a crossover cable to link the board and
the host running wireshark directly and let you know.

On Tue, Nov 6, 2018 at 10:19 AM Paul Nader <paul.nader@gmail.com> wrote:

>
>
> On Tue, Nov 6, 2018 at 9:45 AM Chris Packham <judge.packham@gmail.com>
> wrote:
>
>>
>>
>> On Tue, 6 Nov 2018, 6:09 AM Paul Nader <paul.nader@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I'm trying to get an olinuxino-a64 board to boot using bootp but it
>>> failed
>>> to send any DHCP packets so I reduced the problem to trying to get it to
>>> ping another host but that fails as well.
>>>
>>> I tried it both with 2018.09 and then the head of master given there were
>>> some recent commits to the net area to fix handling asynchronous
>>> responses.
>>>
>>> I'm testing this  by having the board ethernet connected to a switch and
>>> another port of the switch to a host running wireshark snooping packets
>>> in
>>> promiscuous mode.
>>>
>>
>> Could the switch be dropping the packets? Are the ports in the same vlan?
>> Is your monitoring host the same host you're trying to ping? (if not you'll
>> need to configure your switch for mirroring)
>>
>
>
> The switch is a unmanaged TP-Link SG105
> <https://www.tp-link.com/uk/products/details/cat-42_TL-SG105.html> which
> as far as I can tell has no configuration.
>
> The host I am pinging is the same host that is running wireshark.
>
>
>>
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   phy interface7
>>> eth0: ethernet at 1c30000
>>> starting USB...
>>> No controllers found
>>> Hit any key to stop autoboot:  0
>>> => setenv ipaddr 192.168.0.2
>>> => log level 10
>>> => setenv netmask 255.255.255.0
>>>
>>
>> What do you end up with for a mac address? I'm not familiar with the
>> olinuxino hardware does it have an eeprom for the mac or does it just come
>> from the environment.
>>
>>>
>>>
> I tried overwriting the mac address using setenv but it wouldn't allow it
> so I think it is coming from an eeprom. I didn't set it up in the u-boot
> environment.
>
> Also, just to reiterate, this all works fine once the kernel has booted. I
> can configure the interface within linux and ping the host without any
> problems.
>
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
  2018-11-06 10:54     ` Paul Nader
@ 2018-11-08 20:19       ` Paul Nader
  2018-11-15 19:47         ` Alexander Weidinger
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Nader @ 2018-11-08 20:19 UTC (permalink / raw)
  To: u-boot

Hi,

I tried with x-over cable and the results were practically the same - no
pings.

I increased the tx-delay-ps to 700ps and then I started getting the
occasional arp being responded to. Below that I wouldn't see any. Here is
the relevant potion of my DT (attached):

&emac {
        pinctrl-names = "default";
        pinctrl-0 = <&rgmii_pins>;
        phy-mode = "rgmii";
        phy-handle = <&ext_rgmii_phy>;
        phy-supply = <&reg_dcdc1>;
        allwinner,tx-delay-ps = <700>;
        status = "okay";
};

&mdio {
        ext_rgmii_phy: ethernet-phy at 1 {
                compatible = "ethernet-phy-ieee802.3-c22";
                reg = <1>;
        };
};

Below is a the trace for a ping (I've added some more code trace statements
myself). Here the first ARP request times out, but the second one is
responded to.
I see the requests and responses in wireshark on the development host
(attached to email).
The host doing the ping is 192.168.0.2 (02:ba:7b:d5:c6:6f), the one suposed
to respond is 192.168.0.1 (94:de:80:7e:84:9c)

DEBUG.none,net/net.c:412-net_loop() --- net_loop Entry
DEBUG.none,net/eth-uclass.c:272-eth_init() Trying ethernet at 1c30000
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
DEBUG.none,net/net.c:438-net_loop() --- net_loop Init
Using ethernet at 1c30000 device
DEBUG.none,net/net.c:795-net_set_timeout_handler() --- net_loop timeout
handler set (000000007dfa4ea8)
DEBUG.none,net/ping.c:44-ping_send() sending ARP for 192.168.0.1
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 1
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/arp.c:109-arp_timeout_check() ARP Timeout expired: 669957
5000
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 2
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:1087-net_process_received_packet() packet received
DEBUG.none,net/net.c:1159-net_process_received_packet() Receive from
protocol 0x806
DEBUG.none,net/arp.c:140-arp_receive() Got ARP
DEBUG.none,net/arp.c:196-arp_receive() Got ARP REPLY
DEBUG.none,net/arp.c:212-arp_receive() Got ARP REPLY, set eth addr
(94:de:80:7e:84:9c)
DEBUG.none,net/arp.c:226-arp_receive() Sending tx_packet
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:622-net_loop() --- net_loop timeout
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 3
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 3
DEBUG.none,net/net.c:759-net_set_udp_handler() --- net_loop UDP handler set
(0000000000000000)
DEBUG.none,net/net.c:773-net_set_arp_handler() --- net_loop ARP handler set
(0000000000000000)
DEBUG.none,net/net.c:791-net_set_timeout_handler() --- net_loop timeout
handler cancelled
DEBUG.none,net/net.c:659-net_loop() --- net_loop Fail!
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
ping failed; host 192.168.0.1 is not alive
DEBUG.none,common/command.c:501-cmd_call() Command failed, result=1
DEBUG.none,net/net.c:412-net_loop() --- net_loop Entry
DEBUG.none,net/eth-uclass.c:272-eth_init() Trying ethernet at 1c30000
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
DEBUG.none,net/net.c:438-net_loop() --- net_loop Init
Using ethernet at 1c30000 device
DEBUG.none,net/net.c:795-net_set_timeout_handler() --- net_loop timeout
handler set (000000007dfa4ea8)
DEBUG.none,net/ping.c:44-ping_send() sending ARP for 192.168.0.1
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 1
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:759-net_set_udp_handler() --- net_loop UDP handler set
(0000000000000000)
DEBUG.none,net/net.c:773-net_set_arp_handler() --- net_loop ARP handler set
(0000000000000000)
DEBUG.none,net/net.c:791-net_set_timeout_handler() --- net_loop timeout
handler cancelled

Even though _sun8i_emac_eth_send() is called to send the ICMP ping packet I
never see it arrive at the host. After that net loop times out at
net/net.c:622

Any suggestions on how to proceed next?

Paul

On Tue, Nov 6, 2018 at 10:54 AM Paul Nader <paul.nader@gmail.com> wrote:

> I'll try without the switch using a crossover cable to link the board and
> the host running wireshark directly and let you know.
>
> On Tue, Nov 6, 2018 at 10:19 AM Paul Nader <paul.nader@gmail.com> wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 9:45 AM Chris Packham <judge.packham@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, 6 Nov 2018, 6:09 AM Paul Nader <paul.nader@gmail.com wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to get an olinuxino-a64 board to boot using bootp but it
>>>> failed
>>>> to send any DHCP packets so I reduced the problem to trying to get it to
>>>> ping another host but that fails as well.
>>>>
>>>> I tried it both with 2018.09 and then the head of master given there
>>>> were
>>>> some recent commits to the net area to fix handling asynchronous
>>>> responses.
>>>>
>>>> I'm testing this  by having the board ethernet connected to a switch and
>>>> another port of the switch to a host running wireshark snooping packets
>>>> in
>>>> promiscuous mode.
>>>>
>>>
>>> Could the switch be dropping the packets? Are the ports in the same
>>> vlan? Is your monitoring host the same host you're trying to ping? (if not
>>> you'll need to configure your switch for mirroring)
>>>
>>
>>
>> The switch is a unmanaged TP-Link SG105
>> <https://www.tp-link.com/uk/products/details/cat-42_TL-SG105.html> which
>> as far as I can tell has no configuration.
>>
>> The host I am pinging is the same host that is running wireshark.
>>
>>
>>>
>>>> In:    serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Net:   phy interface7
>>>> eth0: ethernet at 1c30000
>>>> starting USB...
>>>> No controllers found
>>>> Hit any key to stop autoboot:  0
>>>> => setenv ipaddr 192.168.0.2
>>>> => log level 10
>>>> => setenv netmask 255.255.255.0
>>>>
>>>
>>> What do you end up with for a mac address? I'm not familiar with the
>>> olinuxino hardware does it have an eeprom for the mac or does it just come
>>> from the environment.
>>>
>>>>
>>>>
>> I tried overwriting the mac address using setenv but it wouldn't allow it
>> so I think it is coming from an eeprom. I didn't set it up in the u-boot
>> environment.
>>
>> Also, just to reiterate, this all works fine once the kernel has booted.
>> I can configure the interface within linux and ping the host without any
>> problems.
>>
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireshark_eth0_20181108164511_scCpYP.pdf
Type: application/pdf
Size: 21570 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181108/185e1144/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sun50i-a64-olinuxino.dts
Type: audio/vnd.dts
Size: 6107 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181108/185e1144/attachment.bin>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
  2018-11-08 20:19       ` Paul Nader
@ 2018-11-15 19:47         ` Alexander Weidinger
  2018-11-15 20:03           ` Marek Vasut
  0 siblings, 1 reply; 7+ messages in thread
From: Alexander Weidinger @ 2018-11-15 19:47 UTC (permalink / raw)
  To: u-boot

Hi Paul, hi everyone,

we had the same problem with our olinuxino-a64, but we were able to
solve it by using an old patch series proposed by Icenowy Zheng.

We extended the *.dts with content of the current torvalds/Linux master
branch to contain an emac configuration, which basically results in the
same changes you did. [0]
Additionally We adapted the patch series from [1] for the current
v2018.11-rc3 branch of denx/U-Boot. [2]
When not applying the patch series, the 'tx-delay-ps' option seems to
have no effect on the driver - at least we didn't find reference for
this in the code.

After this we are able to use DHCP and boot our board via TFTP.

The patch series is in the state 'Changes Requested' and it seems there
was no activity for quite some time. Nonetheless this seems to fix the
problem for us.
As a side note - this patch series seems also to be necessary for the
BananaPi-M3, which uses the same Ethernet driver but a different PHY
(Realtek instead of Micrel).

Best regards

Alexander Weidinger

[0]:
https://github.com/argos-research/u-boot/commit/546105fe859a5199b9533fbc0137b9328935bdba
[1]:
https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=71295&state=*&q=emac&archive=both&delegate=
[2]:
https://github.com/argos-research/u-boot/commit/f2a8eda9432c2d785ae446509f104de8b1492dd6

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Ping failure
  2018-11-15 19:47         ` Alexander Weidinger
@ 2018-11-15 20:03           ` Marek Vasut
  0 siblings, 0 replies; 7+ messages in thread
From: Marek Vasut @ 2018-11-15 20:03 UTC (permalink / raw)
  To: u-boot

On 11/15/2018 08:47 PM, Alexander Weidinger wrote:
> Hi Paul, hi everyone,
> 
> we had the same problem with our olinuxino-a64, but we were able to
> solve it by using an old patch series proposed by Icenowy Zheng.
> 
> We extended the *.dts with content of the current torvalds/Linux master
> branch to contain an emac configuration, which basically results in the
> same changes you did. [0]
> Additionally We adapted the patch series from [1] for the current
> v2018.11-rc3 branch of denx/U-Boot. [2]
> When not applying the patch series, the 'tx-delay-ps' option seems to
> have no effect on the driver - at least we didn't find reference for
> this in the code.
> 
> After this we are able to use DHCP and boot our board via TFTP.
> 
> The patch series is in the state 'Changes Requested' and it seems there
> was no activity for quite some time. Nonetheless this seems to fix the
> problem for us.
> As a side note - this patch series seems also to be necessary for the
> BananaPi-M3, which uses the same Ethernet driver but a different PHY
> (Realtek instead of Micrel).

Can you repost the series ?

> Best regards
> 
> Alexander Weidinger
> 
> [0]:
> https://github.com/argos-research/u-boot/commit/546105fe859a5199b9533fbc0137b9328935bdba
> [1]:
> https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=71295&state=*&q=emac&archive=both&delegate=
> [2]:
> https://github.com/argos-research/u-boot/commit/f2a8eda9432c2d785ae446509f104de8b1492dd6
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-11-15 20:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-05 17:07 [U-Boot] Ping failure Paul Nader
2018-11-05 17:10 ` Paul Nader
2018-11-06  9:45 ` Chris Packham
     [not found]   ` <CAD3v2COOAoJfVBdaAZ0BpdcftcX+W4OJbA1EPObAviRK59d+Zg@mail.gmail.com>
2018-11-06 10:54     ` Paul Nader
2018-11-08 20:19       ` Paul Nader
2018-11-15 19:47         ` Alexander Weidinger
2018-11-15 20:03           ` Marek Vasut

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.