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-
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
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.
Although you asked TI, I think I can also give you some answers.
Tom Smith · 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 · 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 · 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.
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.
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
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)