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.

Starting up DM365 in SPI Boot Mode

Hi,

I have been looking at the DM365 chip and I am interested in the SPI Boot Mode,  Once we set BTSEL[2:0] to 101 the RBL will automatically try to copy a UBL to the internal memory of the ARM.  We want to connect a SPI Flash to the SPI0 interface of the DM365. 

1.) Where does the RBL begin to look for the UBL (in page 0)? 

2.) How does one initially place the UBL into the SPI Flash?

3.) From what I see, it seems that the UBL will be customized, to begin loading the Linux Montavista from the SPI Flash as well, is there  a document or procedure on how to get started in developing a proper uboot forthe DM365?

Thanks in advance.

  • NeeravPatel said:
    1.) Where does the RBL begin to look for the UBL (in page 0)? 

    The RBL checks for a UBL descriptor in the very beginning of the SPI flash, it reads the first byte in 24 bit mode to determine the address width of the flash so subsequent accesses will be 16 or 24 bit as necessary. This UBL descriptor also contains more than just the first byte of 16/24 bit determination, but also additional information about the UBL such as location in the SPI flash, size, and location where it should be executed, as well as entry point. Note that details on this will be available when the ARM subsystem guide (SPRUFG5) is released (the datasheet description of the RBL modes is largely incomplete).

    NeeravPatel said:
    2.) How does one initially place the UBL into the SPI Flash?

    Typically you would either have the flash programmed before mounting, or you would run an application loaded to the DM365 through a serial port or JTAG that is capible of burning the SPI flash. In the case of the EVM where we are booting from parallel NAND flash there is a utility application that can be loaded through JTAG to burn the initial UBL into the NAND.

    NeeravPatel said:
    3.) From what I see, it seems that the UBL will be customized, to begin loading the Linux Montavista from the SPI Flash as well, is there  a document or procedure on how to get started in developing a proper uboot forthe DM365?

    There will be a U-Boot with source included with the EVM that boots from the NAND flash, so you would probably want to start with this, however there is no real documentation or procedures on modifying it for other boot methods such as SPI that I know of.

  • when the ARM subsystem guide (SPRUFG5) is released

    Is there an ETA on that? Ditto its PRTCSS sibling (SPRUFJ0) ... I'll guess it's sometime before the EVM boards become generally available. 

    And while such unreleased stuff is in the air ... can it please use u-boot 2009.01 or something more recent than the u-boot v1.2.0 from the last LSP that I saw.  [;)]

  • Has SPI boot mode successfully been tested on DM365 EVM?

    thanks

  • DavidBrownell said:
    when the ARM subsystem guide (SPRUFG5) is released

    Is there an ETA on that?

    FYI, ARM Subsystem Guide is available already

  • SPI Mode has been tested; however, the software has not been productized yet and is likely to take some time before you see this available in our DVSDK releases.

  • Is it possible to get the software through our sales representative at least for our test?

    And how about EMAC boot mode? Is it tested?

    Thanks a lot.

     

  • You can certaily contact your sales rep and maybe they can pull some strings for you, but I cannot promise aything.

    I believe the EMAC question has been answered on a separate thread.

  • I read about SPI boot on sprufg5a.pdf (ARM Subsystem) pag 188, but I didn't find lots of informations.

    Paticularly I wold like to use a M25P10-A device: are there any problem?

    If I'm right I have to use as Chip Select to GIO25/SPI0_SCS[0] (ball T1) and Clock and data to GIO22/SPI0_SIMO (ball R2) GIO23/SPI0_SOMI (ball V2) GIO24/SPI0_SCLK (ball T3). Write protect pull_upped.