I'm using UART boot mode to load the standard TI UBL image & a custom U-boot image via serial & program the 2 into NAND for initial production programming of our Am1705-based board. Once the 2 images are programmed, we switch to NAND boot mode & finish initialisation via U-boot - load Linux kernel, program filesystem, etc.
This has been working fine with the standard TI UBL (from DaVinci-PSP-SDK-03.20.00.14). As this is a new CPU to us, I had put a few low-level diagnostic functions into the serial UBL. Figuring that they would also be handy in the NAND UBL, I decided to create a new NAND UBL using the same codebase, with non-essential functions related to the serial UBL stripped out. Unfortunately, this has left the board unable to boot in NAND mode at all - no response via the UART at all - one of the very first things my UBL does once started.
My query relates to the stated RAM usage of the RBL. The documentation I've been using ("Using the AM17xx Bootloader - SPRABA4B–November 2010") says the RBL uses 16K of RAM starting at 0x80000000, so my linker command file is set up to put my UBL's data from 0x80004000 & up. However, looking at the binary dumps of the 2 NAND UBLs shows that the working TI one loads section data (via AIS Section Load command 0x58535901) to 0x80000000, 0x80000050, 0x80004394, then jumps to 0x80000000 to start; whereas my code loads at addresses 0x8000C000 & up (stack is 1st 16K at 0x8004000), finishing at 0x80014A7B, then execution jumps to 0x80013C6C. According to the documentation, the TI UBL's section data would obliterate whatever RAM the RBL might be using & would be more likely to crash, but my "well-behaved" code is the one that suffers, apparently.
I will try adjusting the load address of my code to fix the problem anyway, but it already seems as though the bootloader documentation may be wrong here?
