Did you try something like (with a valid ip address):

ip addr add 192.168.50.5 dev eth0

Then try to ping it? can you ping the loopback? ping the router?
You need to
 set up a gateway for it to get out if you can get to the router. 

here is a cheatsheet
http://www.tecmint.com/ip-command-examples/


The Mac address did change,
I am guessing the one with 
brd ff:ff:ff:ff:ff:ff at the end is the correct one. :) 





 


On Thursday, September 4, 2014 2:19 PM, Robert Moskowitz <r...@htt-consult.com> 
wrote:
 

>
>
>
>On 09/04/2014 01:59 PM, Robert Moskowitz wrote:
>> I have gone back to the 8/31 build and still no working ethernet on 
>> the Cubietruck.  I tried:
>>
>> ip link set eth0 up
>>
>>
 and nothing.  Now looking back on my Cubieboard notes, I had ethernet 
>> problems with that, and Hans said, of course, the uboot provided is 
>> only for the Cubietruck, and if I want to work with my Cubieboard2, 
>> here is how to build your own uboot.
>>
>> So first, why is the ethernet not working?  I can put in my F19 SDcard 
>> and boot this system right up with ethernet access.  And I have 
>> Cubieboard2 running the F21 code.
>>
>> And second, I will see if I can build a uboot from the git provided 
>> from Hans for the Cubietruck and see if that gets things working.
>
>This did not work:
>
>u-boot-sunxi]# make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
>#
># configuration written to .config
>#
>#
># configuration written to spl/.config
>#
>u-boot-sunxi]# make -j4 CROSS_COMPILE=arm-linux-gnu-
>make: *** No rule to make target 
>`/home/rgm/arm/u-boot-sunxi/include/common.h', needed by 
>`include/config/auto.conf'.  Stop.
>
>So no F21 testing on a Cubietruck until I am told how to get
 the 
>ethernet working.
>
>>
>> On 09/04/2014 12:49 PM, Robert Moskowitz wrote:
>>> Same problem on Fedora-Minimal-armhfp-21-20140901-sda.raw.xz
>>>
>>> But a different MAC addr!
>>>
>>> Fedora release 21 (Twenty One)
>>> Kernel 3.16.1-301.fc21.armv7hl on an armv7l (ttyS0)
>>>
>>> localhost login: root
>>> Password:
>>> [root@localhost ~]# ip addr show
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
>>> group default
>>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>     inet 127.0.0.1/8 scope host lo
>>>        valid_lft forever preferred_lft forever
>>>     inet6 ::1/128 scope host
>>>        valid_lft forever preferred_lft forever
>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
>>> state UP group default qlen 1000
>>>     link/ether
 b6:f8:b8:3c:d5:5f brd ff:ff:ff:ff:ff:ff
>>>
>>> I will keep going back to earlier builds and hopefully I will get to 
>>> one that brings up eth0.
>>>
>>> Um This SHOULD be automatic?  I did not have to do it for my F21 
>>> testing on the Cubieboard2 or any of my F19 or F20 testing.
>>>
>>> On 09/04/2014 11:54 AM, Robert Moskowitz wrote:
>>>>
>>>> On 09/04/2014 11:15 AM, Peter Robinson wrote:
>>>>> On Thu, Sep 4, 2014 at 3:33 PM, Robert Moskowitz 
>>>>> <r...@htt-consult.com> wrote:
>>>>>> On a Cubietruck -
>>>>>>
>>>>>> # yum install  policycoreutils-python --nogpgcheck
>>>>> All packages should now be signed so you can drop the --nogpgcheck
>>>>>
>>>>>>   One of the configured repositories failed (Fedora 21 - armhfp),
>>>>>>   and yum doesn't have enough cached data to continue. At this 
>>>>>> point the only
>>>>>>   safe thing yum can do is fail. There are a few
 ways to work 
>>>>>> "fix" this:
>>>>> Is your date/time correct?
>>>>
>>>> I think it might be worst than date/time.  I found the SDcard I was 
>>>> working with and booted up.  No IP addresses on eth0, so no ntp, and 
>>>> why THAT yum message?  Because date/time was essentially ZERO?
>>>>
>>>> I never thought to check on the ethernet.  I have only started 
>>>> working on my 1 Cubietruck, after getting 5 Cubieboard2 systems put 
>>>> into production.  4 running Redsleeve (with F19 uboot), and 1 F20. I 
>>>> have run F19 on this Cubietruck with no problems with ethernet. So 
>>>> something is broken on the Cubietruck uboot support.
>>>>
>>>> Here is what I am seeing on ethernet on the serial console:
>>>>
>>>> [   36.360611] eth0: device MAC address 56:bb:b8:7a:b2:d6
>>>> [   36.386336]  No MAC Management Counters available
>>>> [   36.455808]  No MAC Management Counters available
>>>> [   36.473714] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>> [   40.418888] stmmaceth 1c50000.ethernet eth0: Link
 is Up - 10
>>>> 0Mbps/Full - flow control off
>>>> [   40.433554] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>>
>>>> Last login: Thu Jan  1 00:00:49 on ttyS0
>>>> [root@localhost ~]# ip addr show
>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
>>>> group default
>>>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>>     inet 127.0.0.1/8 scope host lo
>>>>        valid_lft forever preferred_lft forever
>>>>     inet6 ::1/128 scope host
>>>>        valid_lft forever preferred_lft forever
>>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
>>>> state UP group default qlen 1000
>>>>     link/ether 56:bb:b8:7a:b2:d6 brd ff:ff:ff:ff:ff:ff
>>>>
>>>>
>>>
>>> _______________________________________________
>>> arm mailing list
>>> arm@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/arm
>
>>
>> _______________________________________________
>> arm mailing list
>> arm@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/arm
>
>_______________________________________________
>arm mailing list
>arm@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/arm
>
>
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Reply via email to