1

I installed a u-boot.bin on my boot-parition and adapted everything to make it work and boot the kernel over tftp.

I'm using the current (6709570c) revision from here (Gonzo) and followed the wiki on http://elinux.org/RPi_U-Boot.

I installed a tfpd-server on my host and run the following command on u-boot:

usb start
setenv serverip 192.168.2.1
setenv ipaddr 192.168.2.2
tftpboot uImage

and this is what I get: 

## Executing script at 00200000
(Re)start USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage'.
Load address: 0x200000
Loading: *

One time I have seen some # appearing but it stopped after a 8 or 10.

Where is the problem? Can I have more verbose information from u-boot?

EDIT:

In fact it is not a problem of TFTP but a network problem in general in u-boot for RPi. In fact each network command wants to bring up the ethernet and I can see this message everytime (even in the same session) I do ping or tftpboot:

Waiting for Ethernet connection... done.
Using sms0 device

If I do a ping, I'm getting those two lines and then it blocks. Until I ping back the device from the host. It then prints

host 192.168.2.1 is alive

or not alive - this is not deterministic.

A consecutive tftpboot works always a little bit. Sometimes it boots and mounts the nfsroot, sometimes it crashes during the tftp-load (where it prints the #). Somtimes in between.

My current assumption is that the the ethernet driver for the RPi is not yet very stable. Maybe I'm wrong. Does anyone has a clue on this?

Patrick B.
  • 312
  • 1
  • 8
  • 23

3 Answers3

1

I am doing similar things as you and unfortunately I already see these and worse problems.

I used bootp, dhcp (which is the same in the u-boot case), pxe and boot over nfs/tftp up to now and I've seen each and everyone of them hang so far, with and without traffic of the sort corresponding to the current stage to be seen on the adapter.

Unfortunately I don't have a serial adapter to see if the pi/u-boot freezes, but that's my best guess atm. For all I can tell the usb implementation for the raspberry pi, that gonzo put together isn't really fully realiable.

The fact that you are seeing # means you actually get traffic through (T signifies timeout whereas # is a data packet) but you never get the full kernel over.

Max
  • 217
  • 2
  • 10
0

First thing that you should do is to ensure your TFTP server is actually working and ensure it is configured for logging. This way you can check if RPi TFTP requests where received by TFTP deamon. TFTP uses UDP and so is not really reliable. You can debug it by capturing the network traffic on your TFTP host using tcpdump or wireshark:

For tcpdump, you can use something like (you can termianate it by CTRL+C)

sudo -i tcpdump host 192.168.2.2

Where 192.168.2.2 is your RPi IP address. You should see all the network packages sent to/from RPi. This way you can see if TFTP packages are sent at all.

NOTE: You may need to use -i interface (before word host) option to specify interface other than default if you have more than one on your server.

NOTE2: You can add and port tftp at the end of your command to only limit network traffic to TFTP packages.

Krzysztof Adamski
  • 9,605
  • 1
  • 38
  • 53
-2

try to use this version u-boot .

git clone git://github.com/swarren/u-boot.git -b rpi_dev

d1y2j3
  • 1
  • 1