Hi folks,
I am trying to boot the BBB using the tftpboot procedure and I used the yocto openembedded build .
When I tried to transfer the image file using the tftp command in the uboot prompt , I get the following output.
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.43.130; our IP address is 192.168.43.10
Filename ‘uImage’.
Load address: 0x80200000
Loading: T T T T T T T T T T T T T T T T T T T T
Retry count exceeded; starting again
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 90:59:af:62:d3:1b
HOST MAC de:ad:be:af:00:00
RNDIS ready
ERROR: The remote end did not respond in time.
at drivers/usb/gadget/ether.c:2388/usb_eth_init()
Any valuable suggestions or tips on this is helpful
Regards,
Gibson
Gibson, which distro are you using on the tftp host, and which tftp server are you using ?
You also tested local to the host to make sure the file is actually getting out ?
Also very odd that this post did not show up on the groups until 2 days later. Unless this was a new user “thing”.
It is a non-member thing.
Gerald
Hi William,
I am using Yocto 1.6 (daisy) and i could get the file out using the get command, but still having the same error!!!
I use the Debian as the host machine. I am very new to the tftp stuff so just want to get a hold on it and followed the steps from the internet. Tested with the local to get the file and it works perfectly fine.
Regards,
Gibson
Your bbb isn't connecting to the server or the file uImage doesn't exist on
the server. Have you tried connecting to your server using tftp on your
local machine? Make a file called test in your tftp folder and run the
following commands in another folder
tftp 192.168.43.130
get test
quit
There shouldn't be any errors and you should get the file test in the
folder you were in.
Gibson,
Here is a blog post I made last year getting netboot working on the BBB using debian as the tftp server.
http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-network-boot/
Scroll down to “Installing, and configuring TFTP” and see if you can remember if you’ve done all that. The rest of the article is not important.
Hi William and Alfredo,
tftpboot problems
Observation with Yocto 1.6 :
Below are the following observation after i executed the get uImage.
tftp 192.168.95.130
get uImage
Received 5076896 bytes in 1.1 seconds
Do I have to transfer the uImage or zImage? I do not find any zImage in the "/build/tmp/deploy/images/beaglebone$ "
Observation with the Debian image :
If I try the with the Debian image I get the “Bad Linux ARM zImage magic” any clue on this ?
Regards,
Gibson
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
So searching these groups for “John Syn” and uEnv.txt may yield working results for you. Sorry but I do not remember the post topic. Also, just as a FYI, I think you’ll find Angstrom on the BBB to be a dead end.
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
I have attached my uEnv.txt that works with the latest u-boot and Linux Kernel V3.15
Regards,
John
uEnv.txt (3.07 KB)
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
One more thing, make sure you update the am335x-boneblack.dtb file from the kernel you choose. If you don’t, you will get all kinds of issue like bad magic number, kernel just hangs, etc.
Regards,
John
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
BTW, I use a small SDCard with only a 100MB fat partition and I only have MLO, u-boot.img and uEnv.txt files present. Everything else gets loaded from my TFTP server and then I mount an NFS rootfs. This is great for development because I can make whatever changes I want on my “targetNFS” folder on my desktop and then just reboot my BBB. Very fast turnaround because I don’t have to program SDCards or flash eMMC.
Regards,
John
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
I attached a new copy of uEnv.txt because the previous copy included a kernel directive to print initcall_debug which adds a lot of noise to your dmesg. Also, you will notice that I haven’t enabled systemd and that is because on Linux Kernel V3.15, systemd doesn’t shutdown correctly. It disconnects the network before shutting down NFS so the shutdown stops because it cannot access the NFS server. On Linux Kernel V3.8, systemd cause kernel panic on sudo halt.
Regards,
John
uEnv.txt (3.07 KB)
Supposedly you’re supposed to be able to tftp zImage’s now days, I’ve only ever used uImage. Lately I’ve stopped using tftp, and only use NFS for the rootfs.
John Syn recently made a post on these groups saying zImage does work, and I’ve read the same a while back from somewhere else. But, I have not tried or tested it personally. Anyway John gave a supposedly working uEnv,txt setup, but again “supposedly” because I have not tried or tested it myself.
Try again. uEnv.txt without initcall_debug.
Regards,
John
uEnv.txt (3.07 KB)
Hi William and John ,
Thanks for reply!!!
The uEnv.txt that you have shared across uses the kernel_file=zImage and initrd_file=initrd.img but after the compilation of the yocto distro 1.6 instead of zImage I get the uImage. How to obtain the zImage ?and where can I find the initrd.img???
Regards,
Gibson
Hi,
Hi William and John ,
Thanks for reply!!!
The uEnv.txt that you have shared across uses the kernel_file=zImage and initrd_file=initrd.img but after the compilation of the yocto distro 1.6 instead of zImage I get the uImage. How to obtain the zImage ?and where can I find the initrd.img???
Regards,
Gibson
I am a bit confused what you are trying to do.
I assume you made a standard Yocto build for the beagle bone black. Do you want to load the kernel and flat device tree over tftp and the rootfs over nfs?
Yocto should spit our a uImage and a fdt. [1]
I am not sure networking and nfs support is compiled into the uImage.
This uEnv.txt [2] might help with the right kernel config
Do you still have the problem with loading over tftp?
Can you ping the machine which runs your tftp server from u-boot?
Can you manually load uImage from u-boot?
tftp 0x80300000 <full_path_to_u-boot_where_tftp_exports_it>
in my case:
tftp 0x80300000 beagle-bone-black/uImage
[1] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf?id=c4f1f0f491f988901bfd6965f7d10f60cb94a76f
[2] https://github.com/RobertBerger/meta-mainline/blob/daisy-training-v3.14.x/beagle-bone-black-ml/recipes-bsp/u-boot/u-boot/tftp-nfs-uEnv-beagle-bone-black.txt
Hi,
Hi William and John ,
Thanks for reply!!!
The uEnv.txt that you have shared across uses the kernel_file=zImage and initrd_file=initrd.img but after the compilation of the yocto distro 1.6 instead of zImage I get the uImage. How to obtain the zImage ?and where can I find the initrd.img???
You can load uImage if you want, just change bootz to bootm in your uEnv.txt file.
Regards,
Gibson
I am a bit confused what you are trying to do.
I assume you made a standard Yocto build for the beagle bone black. Do you want to load the kernel and flat device tree over tftp and the rootfs over nfs?
Yocto should spit our a uImage and a fdt. [1]
I am not sure networking and nfs support is compiled into the uImage.
When building the Linux Kernel, you have to disable Initrd in the kernel config.
Regards,
John
Hi
Thanks for your replies !!!
I did a tftpboot for BBB with the Yocto images
step-1 : I copied the uImage and uImage-am335x-boneblack.dtb in the /home/gibson/tftpboot
U-Boot# setenv autoload no
U-Boot# setenv serverip 192.168.95.134
U-Boot# setenv ipaddr 192.168.95.130
U-Boot# tftp 0x80200000 uImage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.95.134; our IP address is 192.168.95.130
Filename 'uImage'.
Load address: 0x80200000
Loading: T T T T T T T T T T T T T T T T T T T T
Retry count exceeded; starting again
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 90:59:af:62:d3:1b
HOST MAC de:ad:be:af:00:00
RNDIS ready
ERROR: The remote end did not respond in time.
at drivers/usb/gadget/ether.c:2388/usb_eth_init()
``
Any clue on this why the tftpboot is not working??
Thank for your suggestions!!!
``
Hi,
U-Boot# setenv autoload no
U-Boot# setenv serverip 192.168.95.134
U-Boot# setenv ipaddr 192.168.95.130
try here:
ping ${serverip}
does this work?
Regards,
Robert