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.

Uniflash Problem booting with BOOTP

Other Parts Discussed in Thread: UNIFLASH

I have a custom board based on the BBB with a AM3558. I've been programming the boards successfully in Linux over USB for a while now, however it's time to move the programming off of my desk and into manufacturing where they only use Windows. I'm having issues programming for Uniflash in windows 7. The first Bootp request seems to work from the ROM but fails from the SPL. I saw some similar posts: http://e2e.ti.com/support/embedded/linux/f/354/t/417510 but the patches mentioned in that are from 2014 and the code looks different now (I'm using Processor SDK 2.0.1.7).

From the serial terminal on the board I see that Uboot SPL gets downloaded and started but that fails to get an IP address:

U-Boot SPL 2015.07-00085-gb63d5ca (Jun 07 2016 - 14:23:25) 

Using default environment

usb_ether
Error: usb_ether address not set.

using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 54:4a:16:f4:fc:53
HOST MAC de:ad:be:af:00:00
RNDIS ready
musb-hdrc: peripheral reset irq lost!
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
ERROR: The remote end did not respond in time.
at ../drivers/usb/gadget/ether.c:2361/usb_eth_init()
Problem booting with BOOTP

I saw some posts that mentioned issues with XP but again I'm using windows 7. I've made sure to go through:

http://processors.wiki.ti.com/index.php/Sitara_Flashtool_Quick_Start_Guide

http://processors.wiki.ti.com/index.php/Sitara_Uniflash_Quick_Start_Guide

Oh and I'm using Uniflash 3.4.1.00012 and I've made sure I'm using the latest RNDIS driver.

  • I tried another PC (this one running windows 10) and it works but poorly. It downloads everything but very slowly, there are a few retries on when downloading the kernel and device tree. Also the DHCP assigns different IP addresses as seeming each time BOOTP gets called, so the status has no hope of keeping track of how far along it is. Gets to 27% then jumps to a new IP address and stays at 0%, then jumps to yet another IP address but it does seem to finish. The biggest problem is that I was hoping they wouldn't need to plug into the serial terminal.
  • I will ask the software team to help on this.
  • I have just been using my personal linux machine to program my boards for now but I really need to get this working on Windows to get the process moved to the manufacturing area. What I noticed this time that I hadn't last time is that each time the board goes down and comes back up during the programming process it comes up as a different MAC address, which explains why it was getting different IP addresses. Can you give me any ideas how to make sure the USB Ethernet connection always gives the same MAC address?

    Thanks

  • Sorry about this, it has sunk down the queue and I have missed following up on it. I have escalated to the software team just now. If you don't get a reply from them in a day or two, please post here.
  • Matt,

    You can use the "usbnet_devaddr" environment variable to override the programmed MAC address. This should keep it from switching and allow the programming to go more smoothly.

    If this doesn't work, you could hack the code in board.c that reads the eeprom from the board and programs the MAC addresses. Either set your own for your flasher routine, or change the code so it doesn't switch between SPL and U-Boot.