• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 1443 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.

DM3730 boot issue

Tom Smith
Expert 2930 points
Other Parts Discussed in Thread: DM3730, OMAP3530

Customer inquiry;

I am trying to get the 3730 to boot via its UART3.  Just after power-up, the Boot ROM correctly sends its ASIC ID, and we respond with the image file size (32-bits Little-Endian) followed by the x-load.bin raw image file.  That much goes smoothly, but the 3730 never comes up (even though booting from NAND with the same x-load.bin works fine).  We suspect that the contents of x-load.bin need to be tweaked to make this work, and have heard that slight x-load.bin build differences are needed to distinguish the USB peripheral boot version, UART3 peripheral boot version and the NAND boot version.

                We have noticed that the TEXT_BASE address is important (used in start.S, platform.S and signGP.c), and that the TI documentation says that the UART3 x-load.bin will be copied to internal SRAM at 0x40200000, whereas the NAND boot version (culled from BeagleBoard examples) sets this address at 0x40200800.  We don’t understand why the difference, nor whether this difference is special to BeagleBoard builds vs. necessary to our custom builds.  I have tried and failed to boot the 3730 using both addresses.

                Our main questions are:

·         Is the DM3730 known to be bootable via UART3?  USB?

·         If it is, what linker settings (e.g. TEXT_BASE, and perhaps others) are needed to support peripheral booting?

·         Is there available DM3730 example code for x-load.bin that will run after being downloaded via  UART3?

·         Are there any discussion threads (say on e2e.ti.com) which discuss DM3730 peripheral boot problems?

·         Are there any TI engineers who have direct expertise in 3730 peripheral booting?

-Tom-

  • 0
    Intellectual 500 points

    We would like to do the same but by USB, it woudl be really great if there was a tool for the host pc (windows or linux) that could download the image to the board, I'd assuem that it could supply xload/uboot and a kerenel and then have xload and uboot recognise the boot process so that they use the image from memory,

    Anyone done this?

    David

  • 0 in reply to david atkins
    Intellectual 500 points

    Just realised that one other thing would be with this is that would we need to force the id pin low or high to make it work, would be inconvent as we would then want to add a ethernet device on the same usb device which would need  the dm3730 in host mode, but to boot does the dm3730 need to signal device more rather than host?

    I'm assuming that this all got tested and indeed is still tested and that there must be some TO tools for doing this.

    David

  • 0
    Intellectual 330 points

    Although you asked TI, I think I can also give you some answers.

    Tom Smith said:

    ·         Is the DM3730 known to be bootable via UART3?  USB?

    UART3 works fine if you have the right tools and a working image. We have not tried USB boot.

    Tom Smith said:

    ·         Is there available DM3730 example code for x-load.bin that will run after being downloaded via  UART3?

    Yes, please look here: http://projects.goldelico.com/p/gta04-main/page/SerialBoot/

    Th file uart-loader.bin (we did choose a different name to distinguish) is known to work on OMAP3530 and DM3730. Unfortunately we have lost the correct source codes and exact build settings. But I think it was mainly based on the first step of this: http://elinux.org/BeagleBoardRecovery#UART_recovery We just modified some Pinmux settings.

    Tom Smith said:

    ·         If it is, what linker settings (e.g. TEXT_BASE, and perhaps others) are needed to support peripheral booting?

    That is what I as trying to find out as well, but did not succeed. I was also wondering why the TEXT_BASE is not 0x40200000.

  • 0 in reply to Nikolaus Schaller
    Intellectual 330 points

    I think I have found the difference by trying to understand start.S and disassembling the working binary (arm-linux-gnueabi-objdump -D -b binary -m arm uart-loader.bin).

    The TEXT_BASE is 0x40208800.

    There is some code at the beginning that copies the x-loader to the correct TEXT_BASE. This code is initially loaded to 0x40200000 but knows about the 0x40208800 address because a pointer is stored. According to my understanding, this copying process is skipped if TEXT_BASE ix 0x40200000.

    Maybe, the X-Loader code assumes that the first 32 kByte of SDRAM are available for other purposes.

  • 0 in reply to Nikolaus Schaller
    Prodigy 10 points

    I have followed the way of this web  http://projects.goldelico.com/p/gta04-main/page/SerialBoot/   and downloaded the s-load.bin by pserial.exe. When I downloaded the u-boot.bin through ukermit.exe.I got some errors. Sometimes the error is  Downloading file: 0.080% completed <800/999856> bytes.then it stoped downloading.Sometimes the error is  Downloading file: 0.080% completed <800/999856> bytes > Failed after 4 retries in sequence 8 - success send = 800 bytes.

    So I don't know where error is. I guess that maybe the s-load.bin doesn't match with our board(the board of mine is dm3730), or the u-boot doesn't match with our board. So I want to know where I can get the source code of s-load.bin or u-boot.bin.

    Chandy

  • 0 in reply to chunjing xu
    Intellectual 330 points

    The GTA04 also uses the DM3730. So this is not the issue.

    The s-load.bin is relatively independent on specific hardware - but it may need configuration if you have different SDRAM. There may be differences in PinMUX and some peripherals starting and influencing.

    The errors you get indicate that the SDRAM connected to the DM3730 is not working properly. You may try to directly connect to the s-load.bin after pserial.exe through a terminal program instead of running ukermit. Issue a "M" and it should respond with a $ (this is a non-standard command line interpreter we have added). Then, do a "rt" + Return (RAM Test). It may (or may not) work and indicate if SDRAM is working.

    Sources of our x-loader/s-load.bin branch can be found here, but there is some official project on gitorius I don't know the link:

    http://git.goldelico.com/?p=gta04-xloader.git;a=tree

    You have to compile with different configs (with enabling MMC for MLO, with NAND only for X-Loader, with neither for s-load.bin)