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?

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.

|improve this answer|||||
  • See my EDIT. Now we are at least two with the same problem. That excludes a faulty setup. – Patrick B. Mar 27 '13 at 18:57
  • As an update, I got a hand on a rev 1.0 rpi-b that works just dandy with the same image. As far as I can see something must have changed in the usb hardware of the pi and the driver wasn't adapted (I ruled out a faulty one with a couple of others). – Max Apr 18 '13 at 6:56
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.

|improve this answer|||||
  • I'm using the exact same instance of tftpd with qemu and it works. – Patrick B. Mar 27 '13 at 14:35
  • @PatrickB.: But is this QEMU running on the same machine or on RaspberryPi? It isn't that much relevant now since you know that it's not TFTP issue but u-boot in general, though. – Krzysztof Adamski Mar 27 '13 at 18:58
  • QEMU is running on the host which hosts tftpd(-hpa). It accesses it with a tap-interface. – Patrick B. Mar 27 '13 at 19:00
-2

try to use this version u-boot .

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

|improve this answer|||||
  • 3
    Welcome to Raspberry Pi! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Steve Robillard Jul 3 '14 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.