TFTP from u-boot: slow and buggy

[l...@ansync.com]

I have a setup that loads u-boot onto the BBB over the serial port, and then tells u-boot to load the .dtb and kernel from a local TFTP server. Loading the small .dtb file works perfectly (although slowly), and succeeds. Loading the kernel takes too long, causes lots of retries, and finally errors out. If I manually get the kernel from that same TFTP server onto my laptop, it loads in about 11 seconds--over wifi--so the server is working fine. It's just u-boot's TFTP client that seems to be causing the errors. I have seen other messages around the net advising changing the server's block size to 1468, which I did, and telling u-boot to turn dcache off, which isn't an option anymore, but it still fails.

Has anyone actually got this working? Which tftp server are you using, and what parameters? Is there a patch to u-boot that might fix its client?

[Jack Mitchell]

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Which version of u-boot are you using? Could it not also be the ethernet
drivers? I would try updating to the latest u-boot version and see if
you're still having issues.

Cheers,

--
Jack Mitchell (ja...@embed.me.uk)
Embedded Systems Engineer
Cambridgeshire, UK
http://www.embed.me.uk
--

[William Hermans]

http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-network-boot/

The above link is an article I wrote in the subject of network booting. uboot, MLO, and uEnv.txt are on an SD card, but the kernel, and device tree overlay  is pulled in via TFTP, finally rootfs over NFS.

This works fine, and might be a little slow, but nothing like what you're explaining in your post. I am just using the standard package that comes with Debian wheezy stable, and I have never experienced these problems you're mentioning here.

[l...@ansync.com]

Thanks, and I'd seen that article, but you're right--I'm doing something different. I have a BBB-based development board, and I'm writing a script that loads a full distribution onto it starting from a blank slate--i.e., nothing in the eMMC, no SD card. Most of it is working.

I think Jack is right--it's a network driver issue. When I revert to the stock u-boot v2013.10, the tftp works better.

[William Hermans]

Any information you're willing to share as to how you load files via serial would be awesome. Personally, I love reading about this sort of thing . ..

[Vaibhav Bedia]

On Wed, Jan 8, 2014 at 2:31 PM, William Hermans <yyr...@gmail.com> wrote:

Any information you're willing to share as to how you load files via serial would be awesome. Personally, I love reading about this sort of thing . ..

The steps are outlined here...

http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide

It's for the AM335x EVM but it should be easy enough to adapt it to any AM335x system.

[liyaoshi]

umm

With serial download，I prefer to set the baudrate up to 921600 , if you use a usb converter to uart .

2014/1/9 Vaibhav Bedia <vaibha...@gmail.com>

[William Hermans]

Thanks, and I wonder how i missed that page. I seem to have every other page bookmarked except that one .  .

[Vaibhav Bedia]

On Thu, Jan 9, 2014 at 4:46 PM, William Hermans <yyr...@gmail.com> wrote:

Thanks, and I wonder how i missed that page. I seem to have every other page bookmarked except that one .  .

If you are bookmarking something i would suggest the following:

http://processors.wiki.ti.com/index.php/AM335x_PSP_User%27s_Guide

http://processors.wiki.ti.com/index.php/AMSDK_Linux_User's_Guide

Granted, it's the "evil vendor tree" but the basic stuff never changes.

[Tom Rini]

On Wednesday, January 8, 2014 2:43:41 PM UTC-5, Vaibhav wrote:

On Wed, Jan 8, 2014 at 2:31 PM, William Hermans <yyr...@gmail.com> wrote:

Any information you're willing to share as to how you load files via serial would be awesome. Personally, I love reading about this sort of thing . ..

The steps are outlined here...

http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide

It's for the AM335x EVM but it should be easy enough to adapt it to any AM335x system.

Please note that the link above is for UART loading of MLO and U-Boot and not loading files in U-Boot itself via serial.  To do this in U-Boot the command is 'loady address'.

--
Tom

[Tom Rini]

On Wednesday, January 8, 2014 11:47:12 AM UTC-5, l...@ansync.com wrote:

I have a setup that loads u-boot onto the BBB over the serial port, and then tells u-boot to load the .dtb and kernel from a local TFTP server. Loading the small .dtb file works perfectly (although slowly), and succeeds. Loading the kernel takes too long, causes lots of retries, and finally errors out. If I manually get the kernel from that same TFTP server onto my laptop, it loads in about 11 seconds--over wifi--so the server is working fine. It's just u-boot's TFTP client that seems to be causing the errors. I have seen other messages around the net advising changing the server's block size to 1468, which I did, and telling u-boot to turn dcache off, which isn't an option anymore, but it still fails.

Please note that (by accident) dcache isn't enabled for am335x targets until the upcoming release and turning off dcache will give slower, not faster, downloads.

Has anyone actually got this working? Which tftp server are you using, and what parameters? Is there a patch to u-boot that might fix its client?

 
I'm slightly curious as to what / whose binary you were using that was failing to work so badly that it turned out to not be a cable issue (as I was thinking it might be, on starting to read this thread).

--
Tom

[Brendan Bleker]

Have you got this to work?

I've been working on a very similar thing, only I'm trying to load u-boot through TFTP. You may find the following TI wiki useful:

http://processors.wiki.ti.com/index.php/Ubuntu_12.04_Set_Up_to_Network_Boot_an_AM335x_Based_Platform

At this point I have not got a Network Bootable img file, that is where I'm stuck...

[John Syn]

From: Brendan Bleker <bbl...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Wednesday, July 23, 2014 at 1:02 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: [beagleboard] Re: TFTP from u-boot: slow and buggy

Have you got this to work?

I've been working on a very similar thing, only I'm trying to load u-boot through TFTP. You may find the following TI wiki useful:

http://processors.wiki.ti.com/index.php/Ubuntu_12.04_Set_Up_to_Network_Boot_an_AM335x_Based_Platform

At this point I have not got a Network Bootable img file, that is where I'm stuck...

William’s instructions are much easier to follow:

http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-nfs-root/

Robert describes the uEnv.txt setup which works great for me.

http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#nfs_support

Regards,

John

On Wednesday, January 8, 2014 8:47:12 AM UTC-8, Lee Crocker wrote:

I have a setup that loads u-boot onto the BBB over the serial port, and then tells u-boot to load the .dtb and kernel from a local TFTP server. Loading the small .dtb file works perfectly (although slowly), and succeeds. Loading the kernel takes too long, causes lots of retries, and finally errors out. If I manually get the kernel from that same TFTP server onto my laptop, it loads in about 11 seconds--over wifi--so the server is working fine. It's just u-boot's TFTP client that seems to be causing the errors. I have seen other messages around the net advising changing the server's block size to 1468, which I did, and telling u-boot to turn dcache off, which isn't an option anymore, but it still fails.

Has anyone actually got this working? Which tftp server are you using, and what parameters? Is there a patch to u-boot that might fix its client?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Yeah, but I'm not loading uboot over the network. Just the kernel and file system. Plus that is a guide using Ubuntu for which my instructions wont work on. As I used Debian.

One curious thing however, and perhaps I am wrong for loading uboot via a network. I do not use or need a dhcp server for my instructions, and am thinking a dhcp server is not necessary if you use static IP's. But I am not 100% sure where, or how uboot would get its IP from if you're loading it via network.

Anyhow, having multiple dhcp servers on the same network can cause problems which may be difficult to trace down. Even if they are technically on different subnets, Hence why I do not use a BOOTP/DHCP server.

[John Syn]

From: William Hermans <yyr...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Wednesday, July 23, 2014 at 1:24 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: TFTP from u-boot: slow and buggy

Yeah, but I'm not loading uboot over the network. Just the kernel and file system. Plus that is a guide using Ubuntu for which my instructions wont work on. As I used Debian.

One curious thing however, and perhaps I am wrong for loading uboot via a network. I do not use or need a dhcp server for my instructions, and am thinking a dhcp server is not necessary if you use static IP's. But I am not 100% sure where, or how uboot would get its IP from if you're loading it via network.

Anyhow, having multiple dhcp servers on the same network can cause problems which may be difficult to trace down. Even if they are technically on different subnets, Hence why I do not use a BOOTP/DHCP server.

You’re right, since we use u-boot to do TFTP, I’m not sure what Brendan is trying to do. On my SDCard, I have MLO, u-boot.img and uEnv.txt.

Regards,

John

[William Hermans]

I should amend my previous comment to: "We already have a DHCP server on our network". So adding yet another DHCP server would play havoc on our network.

[Tom Rini]

On Wednesday, July 23, 2014 4:02:42 PM UTC-4, Brendan Bleker wrote:

Have you got this to work?

I've been working on a very similar thing, only I'm trying to load u-boot through TFTP. You may find the following TI wiki useful:

http://processors.wiki.ti.com/index.php/Ubuntu_12.04_Set_Up_to_Network_Boot_an_AM335x_Based_Platform

At this point I have not got a Network Bootable img file, that is where I'm stuck...

Using mainline U-Boot you will want to build for 'am335x_evm_usbspl' and use the 'spl/u-boot-spl.bin' and 'u-boot.img' files as what your TFTP server sends out in reply to the BOOTP requests.  The trickiest part here, generally, is having the host machine bring up USB networking in time as that is when you need to start working with Network Manager or similar and I've had reports, but not had time to dig up a fresh installed box or VM, that what's on the TI wiki page isn't quite right anymore.
 
--
Tom

[Tom Rini]

On Wednesday, July 23, 2014 4:25:03 PM UTC-4, William Hermans wrote:

Yeah, but I'm not loading uboot over the network. Just the kernel and file system. Plus that is a guide using Ubuntu for which my instructions wont work on. As I used Debian.

One curious thing however, and perhaps I am wrong for loading uboot via a network. I do not use or need a dhcp server for my instructions, and am thinking a dhcp server is not necessary if you use static IP's. But I am not 100% sure where, or how uboot would get its IP from if you're loading it via network.

Yes, if you set 'serverip' and 'ipaddr' you do not need to run dhcp once U-Boot is running.  When AM335x SoCs boot from the network (which is the case for when it's a USB gadget device) a DHCP server _is_ required.
 

Anyhow, having multiple dhcp servers on the same network can cause problems which may be difficult to trace down. Even if they are technically on different subnets, Hence why I do not use a BOOTP/DHCP server.

This is not true, if you configure the dhcp server on your host correctly (which is to say, not to do anything on your normal eth interfaces and only look at the usb network device).

--
Tom

[William Hermans]

This is not true, if you configure the dhcp server on your host correctly (which is to say, not to do anything on your normal eth interfaces and only look at the usb network device).

Tom, whats the point of having a PC on a network that you can't access ? Anyhow, what I stated is *fact*, but do not take my word for it, give it a try yourself..

--