Booting a bare 3530 board

John F. said:

After looking at the Initialization chapter in the Tech Ref Manual, I get the sense that I could load a binary image in internal SRAM at 0x40200000 via JTAG, set the PC, and continue.  Are there other things that the internal boot ROM code, or x-loader must do before u-boot can run?

This is true, however the problem is that U-Boot is typically too large to fit in ARM internal SRAM, which is why you will usually have an x-loader that runs before u-boot which fits in internal SRAM easily. To answer your question more directly, the x-loader must configure the DDR interface so you can access external memory properly before you load/run U-Boot. It is also possible that the ROM boot loader and x-loader do other configuration that U-Boot is expecting to be handled, but the baseline would be having the DDR configured, probably also the PLL so you are running at a normal clock frequency. Note that from a CCS perspective this kind of initialization can be handled by your GEL file in CCS setup.  

John F. said:

If the boot ROM needs to do initialization, is there a location at which a breakpoint should be set before it starts looking for code?  I'd like to simulate a raw board on an EVM which has a bootloader, by stopping before it tries to load from NAND.

I am not sure that you can actually set a breakpoint within the ROM code, as a typical software breakpoint requires writing to the location in memory that the breakpoint will reside, I suspect this would be possible using a hardware breakpoint but it is not something that I have tried (at least not with the RBL in the OMAP3). In general it would be easiest to just let the ROM code detect the image and load it up, such that you set the breakpoint at the beginning of your own code (i.e. entry of U-Boot or x-loader).

If you want to simulate a raw board with no boot loader on the EVM you could simply wipe the NAND flash from within U-Boot, however this does mean your EVM would not longer boot on its own and you would need a recovery utility such as the serial boot utility discussed in the getting started guide or bootable SD card to get back into working order. For an open source alternative to serially boot your own custom boards take a look here.

Bernie Thompson said:

I am not sure that you can actually set a breakpoint within the ROM code, as a typical software breakpoint requires writing to the location in memory that the breakpoint will reside, I suspect this would be possible using a hardware breakpoint but it is not something that I have tried (at least not with the RBL in the OMAP3). In general it would be easiest to just let the ROM code detect the image and load it up, such that you set the breakpoint at the beginning of your own code (i.e. entry of U-Boot or x-loader).

If you want to simulate a raw board with no boot loader on the EVM you could simply wipe the NAND flash from within U-Boot, however this does mean your EVM would not longer boot on its own and you would need a recovery utility such as the serial boot utility discussed in the getting started guide or bootable SD card to get back into working order. For an open source alternative to serially boot your own custom boards take a look here.

I have set a hardware breakpoint in ROM using a JTAG debugger, but it would be nice to know a bit more about the ROM code versus the high-level layout of figure 25-7 in the Ref. Manual.

I see that only x-loader fits in internal SRAM, and I've heard that on a bare board, after x-loader fails to find code in NAND and hangs (similar to ROM deadloop?), you can interrupt it, then load u-boot into external DDR RAM which at that point is accessable.  If you want to load code via JTAG, it seems a bit odd to let x-loader run into a wall, but maybe external booting (UART3/SD/USB) is the more usual way to go.

Thanks for the pserial link.

,

John

John F. said:

I have set a hardware breakpoint in ROM using a JTAG debugger

That is good to hear, it has been a while since I worked with such breakpoints.

John F. said:

but it would be nice to know a bit more about the ROM code versus the high-level layout of figure 25-7 in the Ref. Manual.

Unfortunately the TRM contains the best description of the RBL that I know of, I have not even seen the source for this one myself.

John F. said:

I see that only x-loader fits in internal SRAM, and I've heard that on a bare board, after x-loader fails to find code in NAND and hangs (similar to ROM deadloop?), you can interrupt it, then load u-boot into external DDR RAM which at that point is accessable. If you want to load code via JTAG, it seems a bit odd to let x-loader run into a wall,

I suspect this would work but typically when working with CCS (Code Composer Studio which I assume you are using for JTAG) you would not need to deal with letting the X-loader run and fail, since you can define a GEL file that will configure the DDR for you, as well as other various initializations. This being said, I would agree that it is a bit odd, but it should work if you had no GEL file enabled in CCS.

John F. said:

but maybe external booting (UART3/SD/USB) is the more usual way to go.

 I do see this as the most typical for the OMAP3, a lot of folks use a bootable SD card as this is how it is typically done in the Beagle community, though other boards will typically boot from UART, particularly if no SD interface is available on the particular hardware they are bringing up. UART also tends to be more standard as it is what would often be used in production setups for our other ARM parts as it is more scaleable than a JTAG solution (i..e you can have many PCs running a UART boot/flash script with only a UART cable as hardware and no CCS license).

Putting the JTAG option on hold, I've been trying to use the pserial utility from omap-boot-utils under Linux and it seems to download the u-boot image, but I get nothing on UART1 after download is complete.  I noticed in the the Mistral serial downloader that there's another file dnld_startup_omap3_evm.bin which is discussed here http://e2e.ti.com/forums/p/2478/9340.aspx, so I'm missing this initialization step.  Since I can't use the Mistral downloader with my custom board (ASIC ID is different) I wonder what the process would be for using pserial and both dnld_startup_omap3_evm.bin and u-boot.bin versus the Mistral downloader.

Thanks,

John

I've had slightly better luck following this: http://elinux.org/BeagleBoardRecovery#UART_recovery using pserial to load x-loader enabled for serial download, then using ukermit to transfer u-boot.  The process gets me to a u-boot prompt on an EVM, but not yet on my board.