• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 798 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

running DM365 without Flash and just Host Port interface

Eric16861
Prodigy 10 points


Hello, I am currently doing a product with DM365 with another host processor. Dm365 will be the slave.

The plan is to have the flash device only available to host processor. DM365 will just have its own DDR2 SDRAM. HPI (Host Port Interface) will be used to communicate between the two processors. In the DM365 HPI document, HPI is only available when boot selection is HPI boot. Is that right?

So the steps to boot DM365 through HPI will be as following:

1. load UBL to DM365 ARM;

2. Inside UBL, initialize RAM, then wait for the host to load u-boot via HPI, then transfer control to u-boot.

3. modify u-boot, wait for host processor to write bootable linux image into memory.

4. For the linux running on ARM, no flash file system can be used, such as YAFFS or JFFS2, instead, using a ram disk or RAMFS for root file system. However, with RAMFS or ram disk, is 128MB SDRAM still enough?

Am I right about the steps? any other suggestions?

I checked the flash_utils package, it contains a CCS project for the UBL code of DM365. I found out ONLY NAND/NOR/SD|MMC/UART are supported, is there any code for HPI UBL? or I have to write my own? If so, does the new UBL  have to be written and compiled within CCS? which version of CCS?

 

 

  • 0
    Prodigy 80 points

    Hello,

    I am currently attempting the exact same thing as addressed in this post from last year -- that is booting the DM365 via the HPI bus.

    I am trying a stepwise approach by first loading the standard "ubl_DM36x_nand.bin" UBL binary from board_utilities into the DM365 via the HPI bus and telling RBL to run it, expecting to see the signon prompt via the serial port and then it potentially crashing as it looks to load Uboot from flash, which of course is non-existent in an HPI environment.  Once I have this working, I intend to modify the UBL source to wait for my host processor to load Uboot and the Linux kernel into DRAM, then jump to Uboot.

    I have code for my host processor that loads the "ubl_DM36x_nand.bin" into the DM365 via the HPI bus, but am not certain as to where to load it into the DM365 internal memory space (I understand the base address of internal RAM is 0x10020) and what to specify to RBL as the entry point address.

    Are the fundamentals of my stepwise approach valid?   Should I expect the standard "ubl_DM36x_nand.bin" to run by loading it via HPI?

    Any help would be most appreciated.

    Thanks,

    Ron

  • 0 in reply to Ron Knollman51871
    TI__Mastermind 41665 points

    Just a note on the HPI on the DM365 EVM before jumping into this, the EVM does not have the HPI wired up in such a way that it is practical to use. The HPI connections on the EVM are shared with two flash devices and the on board CPLD, thus you are likely to get bus contention during various HPI access sequences. To use the HPI reliably on the DM365 would require either modifying the EVM or using a custom DM365 board. The first step would be to remove the socketed NAND, however as there are still two other devices on the same bus there is a risk of bus contention.

    Ron Knollman said:
    I am trying a stepwise approach by first loading the standard "ubl_DM36x_nand.bin" UBL binary from board_utilities into the DM365 via the HPI bus and telling RBL to run it, expecting to see the signon prompt via the serial port and then it potentially crashing as it looks to load Uboot from flash, which of course is non-existent in an HPI environment.  Once I have this working, I intend to modify the UBL source to wait for my host processor to load Uboot and the Linux kernel into DRAM, then jump to Uboot.

    This is one possible path, and as you suggest the NAND UBL would fail when it tries to access NAND if you have HPI enabled instead, however you can probably bypass the UBL entirely and go directly to loading the U-Boot image via HPI instead if you wanted to avoid UBL. Keep in mind the main reason the UBL exists is because U-Boot is too big to fit into internal memory, so when you boot out of a non volatile storage which is not capable of execute in place you need to have an intermediary boot step (a.k.a. UBL) which fits in internal memory that will configure the DDR so that you can load and run U-Boot. This being said, UBL should not be necessary for a HPI boot sequence, as with the HPI boot the host processor can take care of the steps that the UBL was going to have to do (configuring DDR, PLLs, and loading U-Boot). In general I would probably recommend not using UBL for the HPI boot, since it is likely easier for you to control and debug the boot process from the host processor and this might even save you a few initialization cycles of time.

    Ron Knollman said:
    I have code for my host processor that loads the "ubl_DM36x_nand.bin" into the DM365 via the HPI bus, but am not certain as to where to load it into the DM365 internal memory space (I understand the base address of internal RAM is 0x10020) and what to specify to RBL as the entry point address.

    If you were to use the UBL in your HPI boot process you would load it to the 0x10000 region, you can see the internal memory structure in table 2-3 of the DM365 datasheet. You would than set the ARM entry point to the equivalent location in the instruction space at 0x00000 which mirrors the data space at 0x10000.

    Ron Knollman said:
    Should I expect the standard "ubl_DM36x_nand.bin" to run by loading it via HPI?

    I would expect it to run but not successfully since it will fail when it tries to access the NAND.

  • 0 in reply to Bernie Thompson TI
    Prodigy 80 points

    Bernie,

     

    Thanks for the info.  This morning I have modified the CPLD code to DISABLE all possible EMIF (AKA HPI) bus contentions, and the same problem is occurring.

     

    Your info on the post indicating that the 0x0000 range is a mirror of the 0x10000 range was not clear in the data sheet.

    With this in mind, I changed the addresses that I write the magic number and entry address to 0x17fe0 and 0x17fe4 instead of 0x07fe0 and 0x07fe4 as detailed in the “HPI Boot Detailed Flow” (section 11.2.7.2 of the ARM Subsystem User Guide.  Using Code Composer "Verify Memory", I now verify that those values were properly written to those internal RAM addresses, and indeed they are mirrored when I use Code Composer to "View Memory" at 0x7fe0 and 0x7fe4.  I also changed the value that I write to 0x17fe4 as the entry point to 0x00120 to reflect the equivalent location in the instruction space at 0x00000  (I am loading the code image starting at 0x10020).  This still does not result in UBL execution (I am expecting to see the signon message to the console port, but see nothing).

    I have also tried setting the entry point to 0x00020, same result.

    Question:  Once I have the code loaded starting at 0x10020, how can I then use Code Composer debugger (which is already loaded and active, as this is what I am using to View memory) to start execution of that code to confirm that indeed I should see the signon message to the console?

    Thanks,

    Ron

  • 0 in reply to Ron Knollman51871
    TI__Mastermind 41665 points

    Ron Knollman said:
    This morning I have modified the CPLD code to DISABLE all possible EMIF (AKA HPI) bus contentions, and the same problem is occurring.

    There is also a soldered on OneNAND part on the EVM, I am not sure if that could be causing you trouble as well, so keep an eye out for contention from it.

    Ron Knollman said:
    Question:  Once I have the code loaded starting at 0x10020, how can I then use Code Composer debugger (which is already loaded and active, as this is what I am using to View memory) to start execution of that code to confirm that indeed I should see the signon message to the console?

    You should be able to right click on a location in a 'view assembly' window and be able to set the program counter to a specific location, though I have not tried this recently, or in this particular context. You might try setting a break point in the code some time after 0x00020 to see if you can hit it when you release the ARM from the host over HPI (load UBL from host, set breakpoint, then have host release DM365).

    It may also be worth doing a quick run without CCS connected, as there may be some contention between CCS and HPI accessing the device.

  • 0 in reply to Bernie Thompson TI
    Prodigy 80 points

    I disabled all of the chip select ouputs from the CPLD (including the OneNand) and disabled the CPLD from driving the data bus, so I believe any possible contention issues are behind me.

    Question:  Is the DM365 code position-independent?  After building the UBL project in Code Composer, the .MAP file shows the first item in the map being the "ARM_I_IVT" section, which I assume is the interrupt vector table, which I am loading into memory starting at 0x10020 which is mirrored to 0x00020, NOT 0x00000.  I tried loading the binary image starting at 0x10000, but this fails verification and indeed, the HPI Boot detail indicates the start of ARM DTCM RAM is 0x10020.  So I am not sure if loading code to 0x10020 (AKA 0x00020 is a relocation error.

    I think if you could tell me how RBL (in NAND Boot mode, for instance) loads the UBL image from flash  (where does it load it to) and to what address RBL branches to in order to start UBL, this would take me a long way towards understanding what I need to do across the HPI bus.

    Is the RBL source available?

    Thanks,

    Ron

     

  • 0 in reply to Ron Knollman51871
    Prodigy 80 points

    If the entire RBL source is not available, would the portions that handle NAND boot (moving UBL to internal RAM and branching to it) plus the portion that handles HPI boot be available?

    Ron

  • 0 in reply to Ron Knollman51871
    TI__Mastermind 41665 points

    Though I don't have the RBL sources available publicly, I think some good code to inspect for this is the NAND writer sources from /ti-dvsdk_dm365-evm_4_00_00_22/psp/board-utilities/DM36x/CCS/NANDWriter/src or similar. You can dig out some of how the RBL treats at least NAND images from this code, there is a LOCAL_writeHeaderAndData function that actually writes the header and the UBL image into the NAND. The interesting part here is that the entry point is defined at 0x100 in this file with a comment saying 'this fixed entry point will work with the UBLs'.

    As a general description of what the RBL does in NAND mode, it looks like it reads off the first page to extract the header data put in by that NAND flashing tool, than it reads the blocks and pages starting at the block and page defined in the header it read from the first page and copies them into internal ram starting from 0x00010020.

    Based on all this, it seems if you were to copy the UBL image into the DM365 starting at 0x00010020 and than start it out with the entry point at 0x100, you would be following the process used by the NAND boot.