Issues with different Boot Modes (USB0 and SPI0)

Update on issue 1:

I've try to connect with JTAG when board does not boot anymore: it seems it is looped in running some come in the internal RAM (addresses 0x402F...). So it is able to load Bootloader from SPI Flash, and start to run it, but then it loops.

I confirm that the only workaround to restore board to work is to select a Boot Sequence where MMC0 Boot Mode is tried before SPI0 one, and put in a valid MMC. After booting using MMC0, I can turn off the board, remove MMC, turn on, and SPI0 boot works again.

Max

Update on Issue 2:

It seems something goes wrong on ethernet-over-usb network layer. Sometimes PC Linux receive a single packet, and after a while transmitting on usb0 cause only TX errors. Other times DHCP negotiation goes fine, and TFTP download starts, but, again, after a while, transmission seems not working anymore (TX errors). I've used this Linux PC with other RNDIS USB devices (based on g_ether and g_multi Linux kernel gadget) with no problem, so I do not expect it's a PC or Linux problem.

usb0      Link encap:Ethernet  HWaddr 9a:1f:85:1c:3d:0e  
          inet addr:192.168.0.140  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::981f:85ff:fe1c:3d0e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:4 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:392 (392.0 B)  TX bytes:1954 (1.9 KB)

usb0      Link encap:Ethernet  HWaddr 9a:1f:85:1c:3d:0e  
          inet addr:192.168.0.140  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::981f:85ff:fe1c:3d0e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33 errors:12 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1017 (1.0 KB)  TX bytes:9751 (9.7 KB)

>>boot.bin

Might be a "shot in the dark" but are you sure that is the right  format for the file?

Reason is that I was stuck on UART boot (getting stuck partway through) as described here for a while:

http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Boot_Over_UART

>>The systems seems to starve and not other boot mode is used

Exactly what was seeing until I realized I was using the wrong bin file and not spl/u-boot-spl.bin as prescribed.  UART log posted below (to get uboot).

Have you tried UART boot as a sanity check?

>>A couple of times it boots with success: after downloading Starterware bootloader

Of course that makes it sound like the format is not the problem.  But where does this file come from?

Even the following link talks about different formats:

http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing#AM335X_Flashing_And_Booting

Log below:

CCCCCCCCCCC

U-Boot SPL 2011.09 (Feb 22 2012 - 18:28:58) Texas Instruments Revision detection unimplemented CCCCCxyzModem - CRC mode, 2(SOH)/226(STX)/0(CAN) packets, 7 retries Loaded 231320 bytes

 U-Boot 2011.09 (Dec 15 2011 - 12:55:25)

 I2C:   ready

DRAM:  256 MiB

WARNING: Caches not enabled

Found a daughter card connected

NAND:  HW ECC Hamming Code selected

256 MiB

MMC:   OMAP SD/MMC: 0

*** Warning - bad CRC, using default environment

 Net:   cpsw

Hit any key to stop autoboot:  0

Card did not respond to voltage select!

Booting from nand ...

HW ECC BCH8 Selected

 NAND read: device 0 offset 0x280000, size 0x500000  5242880 bytes read: OK Wrong Image Format for bootm command

ERROR: can't get kernel image!

U-Boot#

U-Boot#

U-Boot# help

?       - alias for 'help'

askenv  - get environment variables from stdin

base    - print or set address offset

bdinfo  - print Board Info structure

boot    - boot default, i.e., run 'bootcmd'

bootd   - boot default, i.e., run 'bootcmd'

bootm   - boot application image from memory

bootp   - boot image via network using BOOTP/TFTP protocol

cmp     - memory compare

coninfo - print console devices and information

cp      - memory copy

crc32   - checksum calculation

dcache  - enable or disable data cache

dhcp    - boot image via network using DHCP/TFTP protocol

echo    - echo args to console

editenv - edit environment variable

env     - environment handling commands

exit    - exit script

ext2load- load binary file from a Ext2 filesystem ext2ls  - list files in a directory (default /)

false   - do nothing, unsuccessfully

fatinfo - print information about filesystem fatload - load binary file from a dos filesystem

fatls   - list files in a directory (default /)

go      - start application at address 'addr'

help    - print command description/usage

i2c     - I2C sub-system

icache  - enable or disable instruction cache iminfo  - print header information for application image

imxtract- extract a part of a multi-image

itest   - return true/false on integer compare

loadb   - load binary file over serial line (kermit mode)

loads   - load S-Record file over serial line

loady   - load binary file over serial line (ymodem mode)

loop    - infinite loop on address range

md      - memory display

mm      - memory modify (auto-incrementing address)

mmc     - MMC sub system

mmcinfo - display MMC info

mtest   - simple RAM read/write test

mw      - memory write (fill)

nand    - NAND sub-system

nandecc - Switch NAND ECC calculation algorithm b/w hardware and software

nboot   - boot from NAND device

nfs     - boot image via network using NFS protocol

nm      - memory modify (constant address)

ping    - send ICMP ECHO_REQUEST to network host

printenv- print environment variables

reset   - Perform RESET of the CPU

run     - run commands in an environment variable

saveenv - save environment variables to persistent storage setenv  - set environment variables

sf      - SPI flash sub-system

showvar - print local hushshell variables

sleep   - delay execution for some time

source  - run script from memory

test    - minimal test like /bin/sh

tftpboot- boot image via network using TFTP protocol

true    - do nothing, successfully

version - print monitor, compiler and linker version U-Boot#

Hi Joe

Thanks for your answer. UART Boot Mode works fine: I've tested it both wih TeraTerm on Windows and with minicom on Linux, and loading u-boot-spl.bin (SItara SDK) or boot.bin (Starterware) I had 100% case of success. In my previous tests I've always used boot.bin built with gcc on Linux host from Starterware package.

I know that bootloader image for non-XIP memory boot modes require additional 8 bytes header (with load address and file size), that must not be present in images for peripheral boot modes, like USB0 and UART. By the way I've verified that MLO has an additional 512 bytes header: what they are used for?

Of course it cannot be a file format issues because sometimes it boots with success. Moreover in case of USB0 Boot Mode, it cannot complete download so it is the RBL that got stuck before running SPL. In any case thanks for you suggestions.

Did anybody in TI or customer run USB0 boot with no failure?

Best regards,

Max

I have the exact same issue. I verified the file with UART/XMODEM boot and it works fine.

I debugged the USB connection using usbmon a bit and it seems that the last URBs are being finished with -ENOTCONN so it looks the USB connection drops somehow, I would guess the EVM stops responding but does not disconnect (SOFTCONN bit in MUSB). I cannot verify this without a proper USB analyzer however.

My configuration is a bit convoluted as I run Linux in a VM on a Windows platform and the USB connection is fed through to the VM. I will try to repeat in Windows-only.

Another thing I'm going to try is to firewall the USB connection very carefully so no other packets than BOOTP and TFTP reach the EVM, just in case it fails due to broadcast/multicast traffic.

Yours,

Juha

Are you seeing something similar to this post?:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/157668.aspx

We have not pursued any farther thinking we will wait for the updated Flashtool mentioned here:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/159131.aspx

Yes, that first thread describes pretty much the steps I went through. It seems the TFTP transfer fails for them too.

I am using the u-boot-spl.bin file and I have verified that it loads and boots successfully over UART/XMODEM.

To elaborate:

1. I am running Linux in VMware
2. I have configured the SUBARCTIC USB device to be passed through to the VM
3. In Linux I have configured DHCPD to accept BOOTP requests, give an IP address, next-server and filename options in the reply
4. I am running a TFTP server with u-boot-spl.bin file
5. I see the DHCP/BOOTP request and subsequent TFTP transfer on wireshark
6. TFTP transfer stops after 4 - 30 packets

Hi guys,

In this thread http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/167540.aspx, more than a moth ago, Michael T told me he was working on upgrading the Flash Tool to support AM335x UART and USB0 too. I asked for the due date, but with no answer.

Joe, do you have any info about when the tool will be probably available?

Juha, I've not been able to setup the environment to test USB0 booting using a Windows PC on the USB host side: please, let me know if you are able to do it and if this setup make USB0 boot working fine, thanks.

I think there are several advantages in having RNDIS implemented in USB0 ROM code instead CDC-ACM. First of all you can adopt a point-to-multipoint strategy in mass production flash programming, as when you use any type of network interface, while serial interface must be handled in a point-to-point way. Then ROM code has already BOOTP and TFTP support for Ethernet boot mode. You do not need any further special tool/software running on the host side, just a BOOTP/TFTP server anywhere in the network.

Yeah, I agree: having USB peripheral support in U-Boot would be really useful.

Regards,

Max

Hi.

I experience the same problem, when trying to boot through usb0, on the BeagleBone.

Several people have seen this now on both BeagleBone and the EVM, using Linux, Windows and Linux through a VM on Windows.
It would be really nice if someone from TI would look into it.

I am running on an Ubuntu 10.04 machine using dhcp3-server.
Using wireshark I can see that the first few packages are acknowledged from the BeagleBone but then it seems like the connection is lost.

br.
\nikolaj

Hi

Apologies for posting on an old thread, but this may be of use to someone who lands here from google in the future.

I was having similar problems booting via USB0 on the BeagleBone using Ubuntu 12.04 as the host. Looking at tcpdump I noticed that as soon as the USB/Ethernet interface came up there was a lot of non-bootp traffic. This was largely mDNS chatter from avahi, and stopping avahi-daemon (sudo service avahi-daemon stop) got rid of it and made the bootp/tftp much more reliable.

My suspicion is that the RBL doesn't like all the extraneous traffic (particularly the IPv6 packets).

Hope that helps,

Jonathan

It's not the extra traffic. There is a ROM code bug that prevents USB boot. See this thread http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/p/202483/719161.aspx#719161.

Steve K.

Hi Steve,

Thanks for the info - I look forward to the updated errata.

It's worth pointing out that the post you link to is about Windows RNDIS driver problems which I haven't experienced.

Also I have managed to boot from USB, so it is possible, although presumably only in specific circumstances.

Jonathan

As a clarification the if you are referring to the RNDIS mentioned on p. 16 of AM335x_errata_sprz360b.pdf (Advisory 1.0.13), it  had NOTHING to do with Windows RNDIS driver (from what I understand.  I just found out yesterday).  Rather it is a reference to the USB peripheral mode well documented in Chapter 15 of the TRM (spruh73f_AM335x_TRM.pdf). 

This term has caused much confusion in general.

Just to clarify a little bit more:

Jonathan, your success is really interesting: which hw revision of beaglebone are you using? Can I ask you the am335x chip part number? In the tests I run several months ago there was no extraneous traffic, but they always failed. What did RBL load via USB? An SPL (aka MLO/UBL) or something else?

Steve, would it be possible to have some more details about this ROM code bug before new silicon errata doc will be available? Does it affect just some part numbers?

Joe, I think advisory 1.0.13 is not this case: it refers to DMA and multiple EPs usage, while the comment by Paul (outlined by Steve) is about something that will be published in a new future revision of silicon errata. By the way the "generic RNDIS mode" mentioned there refers to a DMA channel configuration mode, and has (almost) nothing to do with USB RNDIS (Windows proprietary) CDC, as you have already pointed out.

Regards,

Max

Hi Max,

I'm using a Rev A5 BeagleBone using an AM3359ZCZ.

The file loaded was a very simple test program (following instructions on http://www.embedded-bits.co.uk/2011/writeanmlo/) and I was using CodeComposer to verify it was running.

Interestingly when I tried to load something more substantial (StarterWare) it didn't work. Some quick tests suggest that once the file gets above 8KB in size things stop working. This may explain your lack of success.

I'd second the request for more information on the ROM code bug. Between this and the problems with network boot on RMII interfaces (advisory 1.0.18) I'm starting to run out of automated boot options for my project!

Jonathan

The USB boot problem was not seen during initial testing with small files.  So you may find it works with some small files.

This issue is the same for all AM335x revision 1.0 devices.

The following Advisory will be added to the next revision of the AM335x Silicon Errata.

**************

Advisory 1.0.TBD              Boot: USB Boot ROM Code is Overlapping Data in the TXFIFO and RXFIFO

Revision(s) Affected:       1.0

Details:                         The USB boot ROM code is overlapping data in the TXFIFO and RXFIFO which leads to data corruption.  This data corruption causes a data abort and prevents USB boot from working.

Workaround:                  There is no workaround for this issue.

**************

Regards,
Paul

My comment about small file sizes has caused some confusion and would like to add some additional comments to resolve the confusion.

The TXFIFO and RXFIFO overlapping issue occurs randomly based on several system constraints and may occur during a file transfer of any size.  The probability is less for smaller file sizes so that is why some people have occasionally had it work for small file sizes.  I only mentioned the file size in the above reply to explain why there have been cases were USB boot worked.

Therefore, USB boot can not be supported for any file size on AM335x silicon revision 1.0.

Regards,
Paul 

Thanks Paul - that information fits in with what I've been seeing.