Am335x U-boot User 39;s Guide

[Ailene Goldhirsh]

Iam using am335x based custom board. I have only uart port for loading images to memory. I was able to get u-boot working. What are the load addresses for the linux kernel and the dts file. What will be boot command for running the loaded kernel from memory.

The DDR on Am335x starts at address 0x80000000. The ending address depends on the size of your DDR RAM. For a 128MB RAM, you have the last addres at 0x88000000 So you can load your kernel anywhere. Make sure you load the device tree blob toward the end of the RAM and set the following for u-bootsetenv fdt_high 0x88000000This ensures that fdt is not relocated outside the max address of your ram.Your basic bootargs will beconsole=ttyO0,115200n8 earlyprintk=serial mem=128mAnything else depends on your rootfs which can be on mmc or sd.

"If clients on a subnet are to be assigned addresses dynamically, a range declaration must appear within the subnetdeclaration. For clients with statically assigned addresses, or for installations where only known clients will be served, each such client must have a host declaration."

"In order for a BOOTP client to be recognized, its network hardware address must be declared using a hardware clause in the host statement. hardware-type must be the name of a physical hardware interface type."

Using the dynamic conf example, I am able to have the Sitara come up, broadcast, and receive the u-boot-spl.bin file via tftp. But I seem to have network errors after the network interfaces goes down after the SPL file is transferred. It looks to me like the Sitara can not connect back to the Linux server. (I aslo cannot figure out how to keep wireshark up at that time, so I can't see what is going on, but that is probably a different topic)

Is the issue that I am not using the hardware statement in the dhcp.conf? My Sitara BOOTP client seems to be recognized initialy, but not after receiving the SPL file. Maybe my most basic question is: what does the statement "in order for a BOOTP client to be recognized" mean in the context of booting the Sitara over USB?

Thanks Biser. I should have mentioned that I started with the Sitara Linux Program the eMMC on Beaglebone Black wiki. It has been invaluable. It links to the Ubuntu 12.04 Set Up to Network Boot an AM335x Based Platform wiki mentioned in my post. It does not answer my question, or at least I can't find the answer.

Maybe a better first question is this: Why are the example snippets for dhpcd.conf from the Ubuntu 12.04 Set Up to Network Boot an AM335x Based Platform wiki and the AM335x U-Boot User's Guide different?

They both appear to have the same purpose, to provide the name of the files to the dhcp server. The file names are different, but from my understanding, that is not important. It only matters that the name matches the file in the /tftpboot directory (or which ever directory that was specified when the SDK was installed.

Thank you for pointing that out! I did not realize that I was reading the obsolete U-BOOT guide! The Sitara Linux Program the eMMC on Beaglebone Black wiki does link to the correct Linux Core U-Boot User's Guide. I must have navigated to the obsolete version in my searching.

I'm still trying to figure out why the two TI sources seem to provide different examples of how to configure the isc-dhcp-server and also trying to figure out why my USB peripheral boot is not working. I started with a fresh install of Ubuntu 16.04 this time and followed the instructions identically as before with one additional step. I added this to /etc/default/grub

That got me back to my original problem of SPL not being able to get the U-Boot IMG (I think). I had problems earlier of SPL not being tftpd and the Sitara trying to UART boot instead. That was solved in this post. So now with my new 16.04 set up I got this:

Thinking back to my dhcp.conf question in this post, I tried a few iterations of changes in the dhcp.conf file using the "host" with "hardware" example in the U-Boot User's Guide. I got that trying to tftp, but now I could see on wireshark that "File not found" on the host when the same request was made. So I restored the old dhcp.conf file, but I'm seeing the same result. This makes no sense to me.

I did not touch anything relating to tftp (not directly or knowingly anyway). I have triple checked file names and permissions. I can't for the life of me figure out why I just can't go back to the dhcp.conf that was working a few hours ago. Any advice where to look? I'm back to getting the 'C's, on my terminal which tells me USB boot failed and the processor moved on to UART.

My tftp problem was a result of Ubuntu 16.04 using systemd. In 14.04 I followed the TI wiki instructions and configured tftpd-hpa to be started by xinetd. In 16.04, systmed starts tftp-hpa at startup (by default it seems). The first time I tried my 16.04 set up, tftp worked because I had not restarted Ubuntu after installing tftpd-hpa. After a restart, the uboot-spl-restore.bin file could not be tftp'd because systemd brought up tftpd-hpa at startup with the wrong parameters (the location of the files for one). I updated /etc/default/tftpd-hpa to have the configuration settings that I had previously used in /etc/xinetd/tftp and then deleted the tftp file. I am back to being able to get the uboot-spl-restore.bin over to the beaglebone black every time.

We assume that a GCC-based toolchain has already been installed and theserial port for the board has been configured. We also assume that aLinux Kernel has already been built (or has been provided) as well as anappropriate filesystem image. Installing and setting up DHCP or TFTPservers is also outside of the scope of this document, but snippets ofinformation are provided to show how to use a specific feature, whenneeded.

A note about device trees. With this LCPD release all boards arerequired to use a device tree to boot. To facilitate this in Sitarafamily devices, within U-Boot we have a command in the environment namedfindfdt that will set the fdtfile variable to the name of thedevice tree to use, as found with the kernel sources. In the Keystone-2family devices (K2H/K/E/L/G), it is specified by name_fdt variablefor each platform. The device tree is expected to be loaded from thesame media as the kernel, and from the same relative path.

We strongly recommend the use of separate object directories whenbuilding. This is done with O= parameter to make. We also recommend thatyou use an output directory name that is identical to the configurationtarget name. That way if you are working with multiple configurationtargets it is very easy to know which folder contains the u-bootbinaries that you are interested in.

Building of both u-boot and SPL is done at the same time. You musthowever first configure the build for the board you are working with.Use the following table to determine what defconfig to use to configurewith:

Please note that on many boards we modify the environment during systemstart for a variety of variables such as board_name and if unset,ethaddr. When we restore defaults some variables will become unset,and this can lead to other things not working such as findfdt thatrely on these run-time set variables.

It is possible to reset the set of U-Boot environment variables to theirdefaults and if desired, save them to where the environment is stored,if applicable. It is also required to restore the default setting whenu-boot version changes from an upgrade or downgrade. To do so, issue thefollowing commands:

The default behavior of U-Boot is to utilize all information that a DHCPserver passes to us when the user issues the dhcp command. This willinclude the dhcp parameter next-server which indicates where to fetchfiles from via TFTP. There may be times however where the dhcp server onyour network provides incorrect information and you are unable to modifythe server. In this case the following steps can be helpful:

After booting, U-Boot relocates itself (along with its various reservedRAM areas) and places itself at end of available RAM (starting atrelocaddr in bdinfo output above). Only the stack is locatedjust before that area. The address of top of the stack is insp start in bdinfo output and it grows downwards. Users shouldreserve at least about 1MB for stack, so in the example output above,RAM in the range of [0x80000000, 0xFCE00000] is safely available foruse.

When working with USB Device Firmware Upgrade (DFU), regardless of themedium to be written to and of the board being used, there are somegeneral things to keep in mind. First of all, you will need to get acopy of the dfu-util program installed on your host. If yourdistribution does not provide this package you will need to build itfrom source. Second, the examples that follow assume a single board isplugged into the host PC. If you have more than one device plugged inyou will need to use the options that dfu-util provides forspecifying a single device to work with. Finally, to program via DFU fora given storage device see the section for the storage device you areworking with.

This section documents how to configure the network and use it to loadfiles and then boot the Linux Kernel using a root filesystem mountedover NFS. At this time, no special builds of U-Boot are required toperform these operations on the supported hardware.

In some cases we support loading SPL and U-Boot over the network becauseof ROM support. In some cases, a special build of U-Boot may berequired. In addition, the DHCP server is needed to reply to the targetwith the file to fetch via tftp. In order to facilitate this, thevendor-class-identifier DHCP field is filled out by the ROM and thevalues are listed in the table below. Finally, you will need to use thespl/u-boot-spl.bin and u-boot.img files to boot.

3a8082e126