• State Resolved
  • Locked Locked
  • Replies 31 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 3701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/AM3358: USB RNDIS boot fails

Matt Barclay9
Intellectual 795 points
Part Number: AM3358
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Linux

Hello,

We finally have our first AM3358 board.  I'm trying to bring it up using USB RNDIS boot.  The SYSBOOT pin strapping matches the beaglebone black.

When I power on the AM3358 board, it comes up in lsusb as:

Bus 001 Device 062: ID 0451:6141 Texas Instruments, Inc.

Running tcpdump on the USB ethernet interface, I see:

tcpdump -n -i $(ifconfig | grep enp0s20 | awk '{print $1}') port 67 or port 68 or port 69

08:53:47.197009 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364
08:53:47.200006 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300
08:54:06.729362 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364
08:54:06.731799 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300
08:54:30.167931 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364
08:54:30.189133 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300
08:55:16.672206 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364
08:55:16.673394 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300


One time, I actually saw the TFTP request for u-boot-spl.bin, but haven't been able to get it to happen again.

To validate my laptop configuration, if I wipe the eMMC of a beaglebone and plug in the USB, I see this:

08:57:51.275150 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:37, length 364
08:57:51.277373 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300
08:57:51.280269 IP 192.168.2.2.1234 > 192.168.2.1.69:  34 RRQ "u-boot-spl.bin" octet
08:57:54.472525 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
08:57:54.718783 IP 192.168.2.1.67 > 192.168.2.3.68: BOOTP/DHCP, Reply, length 300
08:57:54.719429 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
08:57:54.722467 IP 192.168.2.1.67 > 192.168.2.3.68: BOOTP/DHCP, Reply, length 300
08:57:54.742590 IP 192.168.2.3.4022 > 192.168.2.1.69:  53 RRQ "u-boot.img" octet timeout 5 blksize 1468

So I'm pretty confident that my laptop is configured properly for RNDIS boot.

How can I debug this issue?  Would connecting JTAG give me any feedback from the Boot ROM if it is encountering some error that prevents making the TFTP request?  Is there somewhere I can find the source code for the boot rom?

Thanks,
Matt

  • 0
    TI__Genius 15510 points
    The boot ROM source is not public. What you can do is use JTAG to look at the Tracing Vectors. Look for the bit definitions in section "26.1.14 Tracing". The show what failed during boot and what passed. They start at 0x4030CE40. More information can also be found in "Table 26-4 Tracing Data".

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    Hi Steve,

    I've connected my JTAG tool and downloaded the tracing vectors.  Here's the report output.  I still don't understand why the USB boot is failing.

    CONTROL: device_id = 0x2b94402e
      * AM335x family
      * Silicon Revision 2.1

    PRM_DEVICE: PRM_RSTST = 0x00000001
      * Bit 0 : GLOBAL_COLD_RST

    CONTROL: control_status = 0x0040031c
      * SYSBOOT[15:14] = 01b (24 MHz)
      * SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing
      * Device Type = General Purpose (GP)
      * SYSBOOT[7:6] = 00b MII (EMAC boot modes only)
      * SYSBOOT[5] = 0 CLKOUT1 disabled
      * Boot Sequence : MMC1 -> MMC0 -> UART0 -> USB0

    ROM: Current tracing vector, word 1 = 0x0000903f
      * Bit 0  : [General] Passed the public reset vector
      * Bit 1  : [General] Entered main function
      * Bit 2  : [General] Running after the cold reset
      * Bit 3  : [Boot] Main booting routine entered
      * Bit 4  : [Memory Boot] Memory booting started
      * Bit 5  : [Peripheral Boot] Peripheral booting started
      * Bit 12 : [Peripheral Boot] Device initialized
      * Bit 15 : [Peripheral Boot] Peripheral booting failed

    ROM: Current tracing vector, word 1 = 0x000000f0
      * Bit 4  : [USB] USB connect
      * Bit 5  : [USB] USB configured state
      * Bit 6  : [USB] USB VBUS valid
      * Bit 7  : [USB] USB session valid

    ROM: Current tracing vector, word 1 = 0x00111000
      * Bit 12 : Memory booting device SPI
      * Bit 16 : Peripheral booting device UART0
      * Bit 20 : [Peripheral Boot] Peripheral booting device USB

    ROM: Current copy of PRM_RSTST = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000001
      * Bit 0  : [Memory Boot] Memory booting device NULL

    Cortex A8 Program Counter = 0x0002862c

    ROM Exception Vectors
      * 0x4030CE04 Undefined
      * 0x4030CE08 SWI
      * 0x4030CE0C Pre-fetch abort
      * 0x4030CE10 Data abort
      * 0x4030CE14 Unused
      * 0x4030CE18 IRQ
      * 0x4030CE1C FIQ

    ROM Dead Loops
      * 0x00020080 Undefined exception default handler
      * 0x00020084 SWI exception default handler
      * 0x00020088 Pre-fetch abort exception default handler
      * 0x0002008C Data exception default handler
      * 0x00020090 Unused exception default handler
      * 0x00020094 IRQ exception default handler
      * 0x00020098 FIQ exception default handler
      * 0x0002009C Validation test PASS
      * 0x000200A0 Validation test FAIL
      * 0x000200A4 Reserved
      * 0x000200A8 Image not executed or returned
      * 0x000200AC Reserved
      * 0x000200B0 Reserved
      * 0x000200B4 Reserved
      * 0x000200B8 Reserved
      * 0x000200BC Reserved



  • 0 in reply to Matt Barclay9
    Intellectual 795 points
    To add to this, I've set breakpoints at the various ROM exceptions and Dead Loops. I've seen:

    0x4030CE10 Data abort

    0x0002008C Data exception default handler


    But I don't hit them consistently. It's rare that I hit them actually. Most of the time I can leave the processor booting and never hit any exceptions.
  • 0
    Intellectual 795 points

    Part Number: AM3358

    Tool/software: Linux

    This is a continuation of this thread:

    I can successfully boot the Beaglebone Black using RNDIS.  On our AM3358 custom board, I am attempting to boot but it never requests the SPL image.  I am using Linux for the DHCP server and TFTP, but I have also tested this using Uniflash 3.x on Windows.  In both environments, my custom board will request an IP address, but fail to download the SPL.

    I have connected JTAG and set break points on the various Exception and Dead Loop vectors.  I was once able to get a "0x0002008C Data exception default handler", but I haven't been able to reproduce that again.  Normally, the processor just keeps requesting DHCP addresses.

    A report generated from am553x-boot.dss can be found here:

    What would cause the Boot ROM to only request IP addresses and never request the SPL over TFTP?

  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Can you run tcpdump and save all output to a file and attach the file? Or run Wireshark and save the capture to a file (it gets saved in tcpdump format). I'd like to look at all the packets and see if I can find anything in there that is suspicious.

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    This thread was marked resolved, so I thought I had to create a new one.  The new one is here:

    You can delete that or do whatever housekeeping needs to be done!

    Here are the tcpdumps:

    Using my AM3358 Custom board:

    Fullscreen am3358_custom.tcpdump.txt Download 
    �ò����O[0^��������t႖��E�@xf����DCt^@t႖��c�Sc<
AM335x ROM=Q�@!	�=7���O[��VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org���O[G���������t႖��E�@wf����DCt^@t႖��c�Sc<
AM335x ROM=Q�@!	�=7����O[�VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org��O[=�
��������t႖��E�@vf����DCt^@t႖��c�Sc<
AM335x ROM=Q�@!	�=7���O[��
VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org��O[���������t႖��E�@uf����DCt^@t႖��c�Sc<
AM335x ROM=Q�@!	�=7���O[��VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org�&�O[M���������t႖��E�@tf����DCt^@t႖��c�Sc<
AM335x ROM=Q�@!	�=7��&�O[�VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org�

    $ sudo tcpdump -i enp0s8 -n port 67 or port 68 or port 69

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes

    18:29:04.155184 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364

    18:29:04.190202 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300

    18:29:11.968775 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364

    18:29:11.968984 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300

    18:29:23.689725 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364

    18:29:23.691637 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300

    18:29:39.321536 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364

    18:29:39.321765 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300

    18:29:58.846925 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:96:9c:b4, length 364

    18:29:58.847116 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300

     

     

    Using my Beaglebone Black:

    Fullscreen BBB.tcpdump.txt Download 
    ��_�O[��������t�t7E�@xf����DCt��t�t7c�Sc<
AM335x ROM=Q�@!	�=7��_�O[�VVt�t7'��MEH��A����CD4�_����t�t7innov8-idl-interface/u-boot-spl.binc�Sc���example.org�_�O[�8VV'��Mt�t7EH@�Q�����E4��innov8-idl-interface/u-boot-spl.binocteta�O[�VV������t�t9EH@�z�����DC4�t'�t�t9c�Sc59@]^<AM335x U-Boot SPL7�b�O[E�VV������t�t9EH@�z�����DC4�t(�t�t9c�Sc59@]^<AM335x U-Boot SPL7�b�O[�3VV������t�t9EH@�z�����DC4�t*�t�t9c�Sc59@]^<AM335x U-Boot SPL7�b�O[��VVt�t9'��MEH��@����CD4o��t'�����t�t9innov8-idl-interface/u-boot.imgc�Sc56��3X����b�O[.�VV������t�t9EH@�z�����DC4�t'�t�t9c�Sc59@6��2��]^<AM335x U-Boot SPL7�b�O[�VVt�t9'��MEH��@����CD4l��t'�����t�t9innov8-idl-interface/u-boot.imgc�Sc56��3X����c�O[W ii'��Mt�t9E[@��8����YEGinnov8-idl-interface/u-boot.imgoctettimeout5blksize1468

    $ sudo tcpdump -i enp0s8 -n port 67 or port 68 or port 69
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
    18:30:55.268561 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:37, length 364
    18:30:55.268753 IP 192.168.2.1.67 > 192.168.2.2.68: BOOTP/DHCP, Reply, length 300
    18:30:55.276633 IP 192.168.2.2.1234 > 192.168.2.1.69:  44 RRQ "innov8-idl-interface/u-boot-spl.bin" octet
    18:30:57.977951 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
    18:30:58.231749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
    18:30:58.734114 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
    18:30:58.978831 IP 192.168.2.1.67 > 192.168.2.3.68: BOOTP/DHCP, Reply, length 300
    18:30:58.981294 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:e1:82:74:1f:39, length 300
    18:30:58.984486 IP 192.168.2.1.67 > 192.168.2.3.68: BOOTP/DHCP, Reply, length 300
    18:30:59.008279 IP 192.168.2.3.1113 > 192.168.2.1.69:  63 RRQ "innov8-idl-interface/u-boot.img" octet timeout 5 blksize 1468

     

     

     

  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    On your custom board, can you boot to Linux for some other media, like mmc? If so see if your USB works under Linux. I was talking with our USB expert and he said it sounds like a hardware problem. Booting to Linux to test this could help.

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    I am unable to boot from any other media.  Our plan was to do the initial dataload through the USB RNDIS interface.  This board just came in, so in parallel I'm testing the DDR3 timings and any other peripherals I can access through CCS and the XDS200.

    This is our USB Implementation.  Please let me know any feedback you have:

  • 0 in reply to Matt Barclay9
    Intellectual 795 points

    FYI - R324 is not populated on my board.

    Here are the USB signals on a scope:

  • 0 in reply to Matt Barclay9
    TI__Guru**** 393215 points
    Matt,

    On the schematic: Is the USB ID pin floating when you try to boot? Which USB port are you using?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 795 points

    Using USB0

    USB ID is floating and reads 0v when the board is powered on.

  • 0 in reply to Steve Kipisz
    Intellectual 795 points


    I was able to use CCS and JTAG to verify my DDR3 timings using the "Sitara Linux Training: Tuning the DDR3 Timings on BeagleBoneBlack". Worked great!

    I'm also using JTAG to download the u-boot-spl.bin file per the "Sitara Linux Training: uboot linux debug with ccsv5" article.

    In that article, when downloading u-boot-spl.bin, CCS6 has a File Type drop down menu. I've been selecting "TI Raw Data". Is that correct? Or should it be something else?

    I'm trying to trace the SPL over JTAG, but not getting consistent results. Each run ends up in at 0x402f0440 in the _fiq() handler. It seems to happen randomly. Sometimes I'll be in i2c0 setup and it will jump to fiq(), other times inside clock enable routines. Not sure what's causing the fiq().

    I'm not executing the full boot ROM in this case. I power on the board, then have CCS6 connect, then load the u-boot-spl, set CSPR.T = 0, then set PC = 0x402f0400.
  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Select Binary instead of TI Raw Data. The CCS colleague said for SPL debugging you should use Binary.

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    What does it mean when the code keeps jumping into the FIQ() loop?

    I've tried using the stock Beaglebone u-boot-spl.bin and must customized version.  It randomly seems to end up in the Dead Loop:

  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    That is strange. Can you try using "Load Program..." and chose the ELF version u-boot-spl and see what happens?

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    Here's what I get when using Run -> Load ->  Load Program...

    CortxA8: Trouble Writing Memory Block at 0x402f0094 on Page 0 of Length 0x7ff0: (Error -1065 @ 0x3D5A) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.27.9)
    CortxA8: File Loader: Verification failed: Target failed to write 0x402F0094
    CortxA8: GEL: File: /home/mbarclay/Downloads/TI/ti-processor-sdk-linux-am335x-evm-04.03.00.05/board-support/u-boot-2017.01+gitAUTOINC+c68ed086bd-gc68ed086bd/spl/u-boot-spl: Load failed.

    That's the image that I use to "Load Symbols".

    Something interesting I discovered:

    I've got 3 Beaglebones on my desk and I can reproduce this issue on two of them.  The 3rd one works fine.

    I've installed JTAG headers on the working Beaglebone and one of the non-working Beaglebones.

    On the "good" Beaglebone - I can USB RNDIS boot and it downloads u-boot-spl.bin then downloads u-boot.img.   But if I load that same u-boot-spl.bin file over JTAG to 0x402F0400, set CPSR.T = 0, then hit run, it only prints this to the console:

    U-Boot SPL 2017.01-g340fb36f04 (Jul 19 2018 - 16:37:31)
    SPL: Unsupported Boot Device!
    SPL: failed to boot from all boot devices
    ### ERROR ### Please RESET the board ###

    However, if I let the Boot ROM execute until it has brought up the USB Interface, then I can download that same u-boot-spl.bin over JTAG and execute it normally.  The Boot ROM obviously must do critical USB initialization that u-boot-spl is expecting.

    Doing a similar procedure on the "Bad" beaglebone, I only ever get:

    U-Boot SPL 2017.01-g340fb36f04 (Jul 19 2018 - 16:37:31)
    SPL: failed to boot from all boot devices
    ### ERROR ### Please RESET the board ###

    Is it possible there's a bug in the Boot ROM preventing these boards from completing RNDIS boot?

    Trying to look at Boot Rom difference between the beaglebones, I used the Tools -> "Save Memory" to download from address 0x20000 , length 0xBFFF

    The resulting boot rom binaries differ at byte 541 and again at 32751.  I'm not sure if that's significant or if I even downloaded the memory properly.  Perhaps you can suggest the correct procedure if I did it wrong.

  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Hi Matt,
    First, the error you see is expected when you load SPL from JTAG. After the boot ROM reads all of SPL into internal RAM, it creates a booting parameters structure where one byte in there tells exactly what SPL was booted from. This is where SPL looks for u-boot. Before jumping to SPL, r0 is loaded with a pointer to that structure. When you use JTAG, r0 has random data in it so SPL does not know where to find u-boot so it prints that error. There isn't a bug in the boot ROM since we have lots of customers using USB RNDIS.

    I'm wondering if your custom board might have older silicon on it since you see a boot ROM difference. With JTAG on your board, can use dump 0x44e10600? See section "1.1.2 Device Identification" for how to interpret the register. Beaglebone Black should have Silicon Revision 2.1 so I wonder what revision your board has. It should be 2.1.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points
    Ah, that makes sense. It must have grabbed the SPL and setup r0 before I could hit pause in CCS.

    In the Device ID register, I get: 0x2B94402E - which should be Silicon 2.1
  • 0 in reply to Steve Kipisz
    Intellectual 795 points
    So to summarize where I'm at right now. There are two big issues preventing my custom board from working:

    1) USB RNDIS boot fails after DHCP request.

    2) SPL run over JTAG randomly jumps into fiq() Dead loop.


    I am working on building the StarterWare examples for Beaglebone first to verify they work. Then will try running uartEcho, gpioLED, etc on my custom board.

    Regarding RNDIS boot, is there anyone you can consult with who would know what the Boot ROM is doing in between DHCP Request and TFTP request? Are there specific hardware blocks in the sitara that are being used. We are going to have our board X-Rayed on Monday to see if there are any solder issues with the BGA.

    Thanks,
    Matt
  • 0 in reply to Matt Barclay9
    Intellectual 795 points
    I manged to get the StarterWare UART echo built for UART1 following this post:

    e2e.ti.com/.../1446814

    I'm still hitting a dead loop when executing this code or any code that accesses UART1 registers:

    HWREG(baseAdd + UART_SYSC) |= (UART_SYSC_SOFTRESET);

    Where baseAdd = 0x48022000
    UART_SYSC = 0x54
    UART_SYSC_SOFTRESET = 0x2

    If I configure that code to use UART0, it will run without any dead loops. But UART0 isn't brought out in my design, so I can't confirm communication over UART0. On the Beaglebone, it does work.

    What kind of hardware design or manufacturing defect would allow access to UART0, but cause an Abort dead loop when reading/writing UART1 registers?
  • 0 in reply to Matt Barclay9
    Intellectual 795 points
    Well, maybe that example code above is just buggy. Running it for UART1 on the BeagleBone causes the same kind of dead loop as I see on my custom board when accessing the UART1 registers....
  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Hi Matt,
    Do you have the UART1 clock enabled? And have you done the pin-mux for UART1?

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points

    Hi Steve,

    I did have UART1 clock and pinmux setup.  However, I noticed over the weekend that UART0 was brought out to test points, so I rewired the board to abandon UART1 and use UART0.

    Now I see the "C" character printed to console.

    The code gets further now.  It prints the U-Boot SPL Banner: "U-Boot SPL 2017.01-00443-g340fb36-dirty (Jul 23 2018 - 15:41:18)"

    The last character of the banner is a '\n' which the SPL code uses to trigger a Watchdog Reset.  The code crashes at that point as it did when UART1 was enabled - i.e. Gets stuck in the _fiq() routine.

  • 0 in reply to Matt Barclay9
    Intellectual 795 points




    Would you guys take a look at the schematic here and let me know if you see anything? We're getting pretty desperate to solve this issue.

    www.dropbox.com/.../am335x_design.pdf

    Thanks,
    Matt
  • 0 in reply to Matt Barclay9
    Intellectual 795 points
    Is there a way to run the pre-compiled MLO-am335x-evm from the Processor SDK using UART boot or through JTAG? I've tried doing "Load Memory" to 0x402f0400 and I've tried sending it over UART boot, but doesn't seem to work.

    I think my development environment is OK because I can build & run software on the Beaglebone, but if I can eliminate one more variable...

    Or do you have a u-boot-spl.bin that is known working that you can send me for testing? My DDR3 on the custom board is virtually identical to the DDR3 on the Beaglebone.
  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Hi Matt,
    The MLO is u-boot-spl.bin with a header so you cannot use that one. What gets loaded over UART is a flat binary so use u-boot-spl.bin-am335x-evm from the prebuilt files.

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points
    OK, I see that file now. It works on the Beaglebone and doesn't work on my custom board. Custom board ends up with PC = 0x402f0400 just like the u-boot-spl images that I built.
  • 0 in reply to Matt Barclay9
    TI__Genius 15510 points
    Can you use JTAG and look at memory to make sure the download was successful? After the download completes, the boot ROM jumps to the code at 0x402f0400. Can you look at what was downloaded?

    Steve K.
  • 0 in reply to Steve Kipisz
    Intellectual 795 points
    Data looks good - I think. I can load the SPL over UART, then use JTAG to "Save Memory" to a file. I'm not sure how many words to read out, but when I do a compare, the first 109046 bytes are correct:

    $ cmp /tmp/u-boot-spl.bin u-boot-spl.bin-am335x-evm
    /tmp/u-boot-spl.bin u-boot-spl.bin-am335x-evm differ: byte 109046, line 783
  • 0 in reply to Matt Barclay9
    Intellectual 795 points


    Turns out we had major power sequencing problems with our design. The EE's spent the last couple of weeks sorting them out so now the power sequencing matches the Beaglebone. I can run the SPL over UART without any issues now, and even load u-boot.img over the UART. In u-boot, I can use USB to download the zImage kernel.

    USB RNDIS in the boot rom, however, still does not work.

    I see the Boot ROM bring up an RNDIS device and it sends the DHCP request. A DHCP response is sent from my laptop. Does the Boot ROM see the response? I don't know. None of the tracing vectors are set. IF the boot rom saw the DHCP response, it should issue an ARP for my laptop. That never happens.

    My custom board does not work with Uniflash either. It appears to never request send a tftp request - but it's hard to tell what's going on behind the scenes with Windows.

    Beaglebone works in both environments - my laptop and a Windows laptop with uniflash.

    Any ideas???
  • 0 in reply to Matt Barclay9
    TI__Mastermind 30506 points
    Matt,

    It's been a few days since we've heard back from you. Have you been able to make any progress?

    This is indeed puzzling. Have you compared the DHCP Responses sent by your Host to see if they are similar and what you'd expect?