This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335X TFTPBoot, MLO through TFTP (boot partition on TFTP only)?

I have a custom board based on the Beaglebone Black, I'm looking to do a "pure" boot over TFTP, that is, from no on-board boot partition (boot partition would be on the TFTP server), blank flash, and no SD card.

Is the MLO accessible from a TFTP server?

If I can do a "pure" boot over TFTP, can anyone direct me to some information on how to get this to work (Server is Ubuntu, client is Arago)? 

Thank you.

  • Brendan,

    I've been working on this page:

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

    It is not quite complete, but it should provide a good start for what you want to do.

    In short, yes, everything you want to do is possible and is a very efficient way to develop.

    Please let me know if you have any feedback or anything I should add.

  • You also might want to look at the Initialization chapter in the TRM at the differences between Memory Boot and Peripheral Boot. With Memory Boot (NAND, eMMC, SD/Card) you use the MLO file. The MLO is the u-boot-spl.bin file with a header attached that the boot ROM reads. With Peripheral Boot (USB, UART, EMAC) you use the u-boot-spl.bin file which is a flat binary.

    Steve K.

  • Hi,

    Thank you for the help. I'm trying your method to set-up the dhcp server, but I'm finding an error after changing the dhcpd.conf. I've copied and pasted the code (I had to add one bracket at the end), this is what I'm seeing when trying to restart the service:

    root@brendan-lp1:/etc/dhcp# /etc/init.d/isc-dhcp-server restart
    dhcpd self-test failed. Please fix /etc/dhcp/dhcpd.conf.
    The error was:
    Internet Systems Consortium DHCP Server 4.2.4
    Copyright 2004-2012 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/
    /etc/dhcp/dhcpd.conf line 113: expecting a parameter or declaration
    range dynamic-bootp 192.168.2.2 192.168.2.100;
                                                 ^
    Configuration file errors encountered -- exiting
    

    The config lines are here:

    subnet 192.168.2.0 netmask 255.255.255.0
    {
    range dynamic-bootp 192.168.2.2 192.168.2.100;
    {
      if substring (option vendor-class-identifier, 0, 10) = "AM335x ROM"
      {
        filename "u-boot-spl-restore.bin";
      }
      elsif substring (option vendor-class-identifier, 0, 10) = "DM814x ROM"
      {
        filename "u-boot-spl-restore.bin";
      }
      elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL"
      {
        filename "u-boot-restore.img";
      }
      else
      {
        filename "zImage";
      }
    
      range 192.168.2.101 192.168.2.199;
    }
    }
    

    Any idea what might be causing this?

  • Based on what I can see, there seems to be an extra closing brace? I only have one after the last range statement...

  • Hi Ron,

    I've taken out the closing brace I had added in there I get the following errors:

    root@brendan-lp1:/etc/dhcp# /etc/init.d/isc-dhcp-server start
    dhcpd self-test failed. Please fix /etc/dhcp/dhcpd.conf.
    The error was: 
    Internet Systems Consortium DHCP Server 4.2.4
    Copyright 2004-2012 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/
    /etc/dhcp/dhcpd.conf line 113: expecting a parameter or declaration
    range dynamic-bootp 192.168.2.2 192.168.2.10;
                                                 ^
    /etc/dhcp/dhcpd.conf line 133: unexpected end of file
    }
     ^
    Configuration file errors encountered -- exiting

  • I believe I've found the error, right after the command, range dynamic-bootp 192.168.2.2 192.168.2.100; there is an unnecessary opening brace. After taking the brace out, the isc-dhcp-server service restarted correctly. 

    I move on to making a network bootable image... Am I able to build a network bootable image that will be able to flash an on board eMMC? I haven't built an Image for the Beaglebone Black before, so any tips, or direction would be greatly appreciated!

    Thank you!

  • Hi Ron,

    Perhaps you can help me with trying to get my board to boot. So far I have it connecting the the DHCP, and TFTP servers, it begins to boot U-Boot SPL, but throws out an error:

    U-Boot SPL 2013.04-dirty (Jun 19 2013 - 09:57:14)
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0 
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Peripheral mode controller at 47401000 using PIO, IRQ 0
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0 
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Host mode controller at 47401800 using PIO, IRQ 0
    ### ERROR ### Please RESET the board ###

    I'm running a vanilla Angstrom distro right now, as it looks as though most of the configuration is in place to allow the board to boot via TFTP/DHCP. I belive that U-Boot SPL is not showing where u-boot.img is located, but I'm not sure...

    Thanks. 

  • Brendan,

    I'm sorry, I'm not familiar with Angstrom and it's configuration for U-Boot. I would search through the source looking for what causes that error. I suspect it doesn't have an appropriate configuration to continue.

    For example, in our SDK 7.0, you have to build U-Boot with a special build config to enable USB Device side networking. If you don't, you get a similar error.

  • HI Brendan,

    I am working on a beaglebone black design, and I am trying to build a correct flashing firmware that get u-boot and kernel through usb-ethernet. This is your case ? Because when the board start, I see only "CCCCC".

    Thanks in advance

    Mickael
  • I can succesfully load an MLO (in my case a small baremetal application) onto the beaglebone black by powering it on with sysboot[0] pulled up and sysboot[2] pulled down to select a boot order which includes ethernet (note that the sysboot pins are accessible via the P8 connector), and "dnsmasq" providing both DHCP/BOOTP and TFTP service.

    My /etc/dnsmasq.conf:

    # disable all DNS functions
    port=0
    
    # enable TFTP service
    enable-tftp
    tftp-root=/home/dev/tftp
    
    # uncomment to log lots of extra information about DHCP transactions.
    #log-dhcp
    
    # fixed dhcp entries (mac,ip,hostname)
    dhcp-host=c8:a0:30:c2:d8:04,192.168.1.38,barebone
    
    # ignore unknown hosts
    dhcp-ignore=tag:!known
    
    # tag requests from rom bootloader
    dhcp-vendorclass=set:bbrom,AM335x ROM
    
    # serve bootp to rom bootloader only
    dhcp-boot=tag:bbrom,/MLO/demo.bin
    dhcp-range=tag:bbrom,192.168.1.0,static
    

    Since this configuration is extremely selective about sending replies you can safely run it on a network with an existing DHCP server.

    The IP in "dhcp-range" line just needs to be in the right IP network. The path to the file given in the dhcp-boot line is relative to the TFTP root directory.

    Keep in mind that a boot image served via network boot should not have two-word (address,length) header that the MLO on an SD card has. The ROM bootloader will always download it to 0x402f0400 (and then jump to that address).

  • As addendum: if you hardcode an IP like this, make sure it's either outside the range of any DHCP server on your network or the IP is reserved for that particular device. If you want to avoid hardcoding MAC addresses or IPs you can also serve a normal dhcp range, but you'll need to make sure it doesn't overlap the range of any other DHCP server on the network.  One way to ensure this is by using a separate IP network altogether (which however requires you add an IP in that network to your ethernet interface). As long as you use the vendorclass-based tagging there's still no risk of conflict: dnsmasq will only respond to requests from the AM335x ROM bootloader (and the ROM bootloader will ignore replies from normal DHCP servers which do not include BOOTP information.)