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?
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,
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.
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.
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 . …
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.
umm
With serial download，I prefer to set the baudrate up to 921600 , if you use a usb converter to uart .
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’s_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.
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’.
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).
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…
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
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.
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
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.
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.
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).
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…