Friday, May 6, 2011

PandaBoard Networking with Fedora 13

With Fedora 13 booting on the PandaBoard, the next step is to bring up the network so I can install more useful software with yum.

The default configuration for the usb0 NIC is for DHCP:

[root@fedora-arm ~]# cat /etc/sysconfig/network-scripts/ifcfg-usb0
DEVICE=usb0
BOOTPROTO=dhcp
ONBOOT=no

But DHCP isn't working for me, it just hangs:

[root@fedora-arm ~]# ifup usb0

Determining IP information for usb0...Unknown HZ value! (94) Assume 100.

I think the Unknown HZ value message is unrelated to the DHCP problem.

I'm not sure what's going on with DHCP, so I will just try a static IP address for now. First, I need the MAC address of the interface:

[root@fedora-arm ~]# ifconfig usb0
usb0      Link encap:Ethernet HWaddr 4A:0B:B3:2A:3E:67
          ...

With the MAC address, I can create a config file for the NIC:

[root@fedora-arm ~]# cat /etc/sysconfig/network-scripts/ifcfg-usb0
DEVICE=usb0
BOOTPROTO=static
ONBOOT=yes
HWADDR=4A:0B:B3:2A:3E:67
TYPE=Ethernet
IPADDR=192.168.1.111
NETMASK=255.255.255.0
GATEWAY=192.168.1.254

Bring up the interface:

[root@fedora-arm network-scripts]# ifup usb0
[root@fedora-arm network-scripts]# ifconfig usb0
usb0      Link encap:Ethernet HWaddr 8A:F4:D3:E9:EB:1A
          inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
          ...

And ping the router:

[root@fedora-arm network-scripts]# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=255 time=6.80 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=255 time=0.794 ms
^C

Networking is up and running!

Finally, as a sanity check, I rebooted to make sure networking still comes up okay.

Wait, what's this?

[root@fedora-arm network-scripts]# reboot
...
Bringing up loopback interface: [ OK ]
Bringing up interface usb0: Device usb0 has different MAC address than expected
, ignoring.
[FAILED]
...

The MAC address is different? How is that possible?

Fedora release 13 (Goddard)
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)

fedora-arm login: root
Password:
Last login: Sat Jan 1 00:00:17 on console
[root@fedora-arm ~]# ifconfig usb0
usb0      Link encap:Ethernet HWaddr CA:70:56:5B:23:7A
          BROADCAST MULTICAST MTU:1492 Metric:1
          ...

Wow, that HWaddr is nothing like the address on the previous boot!

A quick Google search later and I learned the NIC on the PandaBoard does not have a MAC address stored in the EEPROM because it doesn't have an EEPROM!  Thus, it generates a new random MAC address on every boot. Argh.
http://lwn.net/Articles/435894/
https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/673504

The workaround for now is to pass in a MAC address of your choosing on the kernel command line, for example, smsc95xx.macaddr=01:02:03:04:05:06

So, I powered-down the the PandaBoard and moved the SD card over to my regular Linux workstation to create a new boot.scr file.

First, I had to yum install uboot-tools to get the mkimage command. Next, I created a boot.cmd file on the first partition of the SD card:

[root@localhost ~]# mount /dev/mmcblk0p2 /mnt/panda-rootfs
[root@localhost ~]# mount /dev/mmcblk0p1 /mnt/panda-rootfs/boot
[root@localhost ~]# cd /mnt/panda-rootfs/boot
[root@localhost boot]# vi boot.cmd
[root@localhost boot]# cat boot.cmd
fatload mmc 0:1 0x80000000 uImage
setenv bootargs 'ro elevator=noop vram=32M root=/dev/mmcblk0p2 fixrtc console=ttyO2,115200 mem=460M@0x80000000 mem=460M@0xA0000000 smsc95xx.macaddr=CA:BC:15:4D:B4:49'
bootm 0x80000000

And then I converted it into the boot script format with the mkimage command:

[root@localhost boot]# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Pandaboard boot script' -d boot.cmd boot.scr

Unmount the SD card and move it back to the Pandaboard and boot it.

fedora-arm login: root
Password:
Last login: Fri May 6 11:03:29 from 192.168.1.76
[root@fedora-arm ~]# ifconfig usb0
usb0      Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49
          ...

The MAC address looks good! Let's update the ifcfg-usb0 and set the HWADDR line again.

[root@fedora-arm ~]# vi /etc/sysconfig/network-scripts/ifcfg-usb0
[root@fedora-arm ~]# grep HWADDR /etc/sysconfig/network-scripts/ifcfg-usb0
HWADDR=CA:BC:15:4D:B4:49

And one more reboot just-to-be-sure:

...
Bringing up loopback interface: [ OK ]
Bringing up interface usb0: [ OK ]
...
Fedora release 13 (Goddard)
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)

fedora-arm login: root
Password:
Last login: Fri May 6 11:55:45 on console
[root@fedora-arm ~]# ifconfig usb0
usb0      Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49
          inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
          ...

Yay! It works!


One final note: in addition to the lack of EEPROM to store the MAC address, there also does not seem to be a system clock. Every time I boot, the system date is set to midnight, January 1, 2000. ntpdate and ntpd should help with that. I installed both and set the step-tickers (used by ntpdate) to:

[root@fedora-arm ~]# cat /etc/ntp/step-tickers
# List of servers used for initial synchronization.
0.fedora.pool.ntp.org
1.fedora.pool.ntp.org
2.fedora.pool.ntp.org

Then enable both ntpdate and ntpd with chkconfig:

[root@fedora-arm ~]# chkconfig ntpdate on
[root@fedora-arm ~]# chkconfig ntpd on

And now the date should be correct after a reboot.

[root@fedora-arm ~]# reboot

Broadcast message from root@fedora-arm
(/dev/console) at 12:17 ...
...
Starting sshd: [ OK ]
ntpdate: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]

Fedora release 13 (Goddard)
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)

fedora-arm login: root
Password:
Last login: Fri May 6 12:00:31 on console
[root@fedora-arm ~]# date
Fri May 6 12:18:38 CDT 2011

That looks better!

3 comments:

  1. Great blog! Certainly helping with my Panda bring-up. I'm working with the Android L27.12.1-P2 git kernel, which seems to have the patches for SMSC95xx driver, USB-EHCI and PHY clock. But dmesg shows link is not ready. Any ideas?

    ReplyDelete
  2. You're using the Android kernel with Fedora 13? Interesting, I'll have to try that. I was going to try the Ubuntu kernel with F13 and see if that has a persistent MAC address. I'm not sure about the link status.

    ReplyDelete
  3. Actually, I'm using a Debian rootfs I tweaked from my Linkstation project. In any case the Android kernel seems to be the most mature, albeit behind the Linaro one I'm evaluating now. Still muddling with the SMSC.

    ReplyDelete