[ am1707 evm, UBL ] No magic number found

sorry:

2. Build UML and generate from UBL_SPI_MEM.out the UBL_SPI_MEM.bin with the "AISgen for D800K003" utility

Was the code working before you modified, or did you just add additional debug statements?

I would recommend using the UBL that comes from the PSP package as opposed to the one on the /UBL directory and see if that helps.

If that still doesn't work, add some additional debug lines to show what SPI block it is reading the gSpiMemBoot.magicNum from. The flashing tool should flash the UBL at block 0 and U-boot at block 1 with the header prepended.

Jeff

Hi All

I am having pretty much the same problem as above : I am trying to burn an out file which I debugged and works great in CCS into the board

I do the following :

A) HexAIS_OMAP-L137.exe -o OMAPL137-ARM-DOVe.bin  OMAPL137Demo.out

B)sfh_OMAP-L137.exe -v -targetType AM1707 -flash  ubl_AM1707_SPI_MEM.bin OMAPL137-ARM-DOVe.bin

The ubl_AM1707_SPI_MEM.bin  is from the "OMAP-L137_FlashAndBootUtils_2_40\OMAP-L137_FlashAndBootUtils_2_40\OMAP-L137\GNU\ubl"

I seems to burn all OK with the progress running finishing gracefully and then I see

        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: SENDING
        Target: Finished writing to SPI, now verifying.
        Target:    DONE
        Target:    DONE

Operation completed successfully.

When I set the pin back to boot mode and reset I get :

AM1707 initialization passed!
Booting TI User Boot Loader
        UBL Version: 1.65
        UBL Flashtype: SPI
Starting SPI Memory Copy...
No magic number found.
Looking for: 0x55424CBB, but read 0xFFFFFFFF.
SPI Memory Boot failed.
Aborting...

 Any Idea guys ?

I did a quick look at the version 2.40 dvflashutils at sourceforge. Should be the same as the OMAP-L137_FlashAndBootUtils_2_4, From what I can tell, sfh_OMAP-L137.exe will program the your app at 0x6000 but the UBL will scan every 0x10000. Could be wrong though, the code is beyond my abilities  You might have to rebuild either the CPU side of sfh_OMAP-L137.exe or the UBL with the addresses in agreement. If you have a JTAG pod, you can avoid the pobrlematic serial programmer. Build your own UBL and SPI flash writer.

-------
2_40\Common\sft\src\uartboot.c
static Uint32 LOCAL_SPIMEM_commands(Uint32 bootCmd)
...
      #if defined(AM1707)
        imageLocation = 0X6000;
      #else
        imageLocation = hSpiMemInfo->hMemParams->blockSize;
      #endif

-------
2_40\OMAP-L137\Common\src\device_spi.c
...
const SPI_MEM_ParamsObj DEVICE_SPI_MEM_params =
{
  SPI_MEM_TYPE_FLASH,
  24,                     // addrWidth
  256,                    // pageSize
  4096,                   // sectorSize
  64*1024,                // blockSize
  512*1024                // memorySize           
};

-------
2_40\Common\ubl\src\spi_memboot.c
Uint32 SPI_MEM_BOOT_copy()
...
  // Read data about Application starting at start of memory and searching
  // at the start of each memory block
  while (currMemAddr < hSpiMemInfo->hMemParams->memorySize)
  {
    currMemAddr += hSpiMemInfo->hMemParams->blockSize;
 
    SPI_MEM_readBytes(hSpiMemInfo, currMemAddr, sizeof(SPI_MEM_BOOT_HeaderObj), (Uint8 *) &gSpiMemBoot);
 
    if (gSpiMemBoot.magicNum == UBL_MAGIC_BINARY_BOOT)
    {
      // Valid magic number found
      DEBUG_printString("Valid magicnum, ");
      DEBUG_printHexInt(gSpiMemBoot.magicNum);
      DEBUG_printString(", found at offset ");
      DEBUG_printHexInt(currMemAddr);
      DEBUG_printString(".\r\n");
      break;
    }
  }

  if (currMemAddr >= hSpiMemInfo->hMemParams->memorySize)
  {
    DEBUG_printString("No magic number found.\r\n");
    DEBUG_printString("Looking for: ");
      DEBUG_printHexInt(UBL_MAGIC_BINARY_BOOT);
      DEBUG_printString(", but read ");
      DEBUG_printHexInt(gSpiMemBoot.magicNum);
      DEBUG_printString(".\r\n");
    return E_FAIL;
  }
...

Wong Thank you

Following your comment I have tried to check the location at which the application is being loaded to...

according to the application menu it seems to be 0xC1080000

sfh_OMAP-L137 <Command> [-targetType <Target>] [-flashType <FlashType>] [<Options>] [<InputFiles]
        <Command> is required and can be one of the following:
                -erase          Global erase of the flash memory device (no input files)
                -flash_noubl    Place single bootable image in the flash memory device (single input file)
                -flash          Place a secondary user boot loader (UBL) and application image in the
                                flash memory device (first input file is UBL binary, second input
                                file is the binary application image)
                -flash_dsp      Place a DSP secondary user boot loader (UBL), an ARM secondary user boot loader
                                and the application image in the flash memory device (first input file is DSP
                                UBL binary, the second file is ARM UBL binary, and the third input file is
                                the binary application image). This is only used for OMAP-L137 devices.

        -targetType <Target>    Specify the exact target type within the OMAP-L137 family.
                <Target>                One of OMAPL137_v2, OMAPL137_v1, C6747, AM1707 (default is OMAPL137_v2)

        -flashType <Flash>      Specify exact flash type among supported types for the platform.
                <Flash>                 One of SPI_MEM, NAND, NOR (default is SPI_MEM)

        <Options> can be the following:
                -h                      Display this help screen.
                -v                      Display more verbose output returned from the target device
                -p <PortName>           Use <PortName> as the serial port (e.g. COM2, /dev/ttyS1).
                -baud <BaudRate>        Uses <BaudRate> as the serial port baud rate (defaults to 115200)
                -appStartAddr           <Application entry point address>  Specify in hex (defaults to 0xC1080000)
                -appLoadAddr            <Application image load address>  Specify in hex (defaults to 0xC1080000)
                -appFlashBlock          <Block to flash application image> Specify in decimal (default depends on device)

I have tried changing this to 0x10000 as below but still no succses still BAD MAGIC

sfh_OMAP-L137.exe -v -appLoadAddr 0x10000 -appStartAddr 0x10000 -targetType AM1707 -flash  ubl_AM1707_SPI_MEM.bin OMAPL137-ARM-DOVe.bin

Any other suggestion to try ??

 Best regards

Yehuda

Those are RAM addresses. I don't think the RAM addresses are the problem. It's the ROM addresses in the SPI flash memory that don't match.

Some guesses on my part. The sfh program consists of two parts, a host and a target. The host part is an executable on the PC and thats the one that you run. The target part is AISgen'ed binary image that runs on the board. It is loaded into the board by the host. The host sends address and data to the target to be programmed into SPI flash. The problem is that the target program has a hard-coded value of 0x6000 that overrides any address that the host sends over. So the option "-appFlashBlock" is ignored. The address of 0x6000 would be okay if the UBL looked for your application at 0x6000. But it does not. It appear to scan through memory 0x10000 at time looking for the magic number, ie. addresses 0x10000, 0x20000, 0x30000, etc.

I would guess that TI made an error for the AM1707 and never fixed it. I think you have to rebuild either the sfh target part or the UBL part or both to have the same SPI flash address. I don't think there is any way to work-around it with command line arguments. You might be able to chose a different target that would get around that hard-coded value. That might the consequence of improperly initializing the HW, eg. wrong clock, wrong GPIO , wrong CPU type, etc.

Another thought. I think your usage of bin files is not quite right. HexAIS is used for the UBL. The tool to convert from .out to .bin is hex470. Steps would then be:

1) hex470.exe secondary_bl.cmd -o=OMAPL137-ARM-DOVe.bin OMAPL137Demo.out

2) sfh_OMAP-L137.exe -v -targetType AM1707 -flash ubl_AM1707_SPI_MEM.bin OMAPL137-ARM-DOVe.bin

See http://processors.wiki.ti.com/index.php/Secondary_Bootloaders_on_OMAP-L1x. However you would still have the SPI flash address mismatch problem.

You could skip the UBL and have the ROM bootloader load your app directly:

1) HexAIS_OMAP-L137.exe -o OMAPL137-ARM-DOVe.bin OMAPL137Demo.out

2) sfh_OMAP-L137.exe -v -targetType AM1707 -flash_noubl OMAPL137-ARM-DOVe.bin

This could get around the SPI flash address mismatch. I would assume that your OMAPL137Demo.out does not use DDR. Unsure if HexAIS_OMAP-L137.exe will setup DDR and clocks. The AISGEN utility will allow you to tell the ROM bootloader to set all that up before loading your image.

I think the original intent of the UBL was to load up u-boot which then loaded linux. My guess is that UBL comes from processors that are DSP boot and the UBL is transition from the DSP to the ARM.  Since the AM1707 is ARM boot there has been amove to skip the UBL and boot to u-boot directly. Perhaps the UBL has been not updated for that reason.