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.

U-boot PSP 3.21 breaks AISgen tool

Expert 2280 points
Other Parts Discussed in Thread: AM1808, OMAP-L138, AM1806

I've build u-boot for AM1808, with SDK 5.02 and PSP 3.21.0.4: the ELF file is no more recognized by AISgen tool (version 1.9).

I've tried to build it both with SDK 5.02 toolchain (Arago based), and with CodeSourcery 2009q1 toolchain too: same results.
The AISgen works fine with u-boot PSP 3.20.0.13 (SDK 4.0.1) built with CodeSourcery.

I have also some other issues with latest u-boot 3.21...

I'm not an expert of ELF format: is it ok that Type in ELF header is now "DYN (Shared object file)" and not "EXEC (Executable file)" as was previously?
The outputs of "readelf -e" are in the attached file if someone can provide help.

Thanks. Regards,
 Max

 

  • Max,

    What happens when you attempt to use the new u-boot ELF file in AISgen?  If you can provide us the specific error text, it could help debug the issue.  It may also help if you could attach the ELF file in question to this thread so we can try to reproduce the bug.

  • Hi Joe

    The AISgen requires to specify the load and entrypoint addresses, like for a binary file, so the ELF file is handled in a wrong way.

    I found that similar problem has already arisen some months ago; have a look at this thread: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/126000.aspx
    There are also some posts by Daniel Allred from TI, but unfortunately with no solution...

    I'm attaching the ELF file zipped. It's just U-boot PSP 3.21.0.4 SDK 5.02 built for AM1808.

    Thanks for your support.
    Regards,
    Max

     

     

    u-boot.3.21.elf.zip
  • The u-boot ELF file is identified as a Shared Object (Dynamic), statically linked executable. This is apparently because the are creating a Position Independent Executable (-fPIE linking option).  Looking into this a little more, I think the AIS tools should be updated to accept this input since it is statically linked with final addresses set (if that were not true, they wouldn't be able to create a binary file from it).

    But as I posted in the other thread, since the u-boot build procedures will generate a binary output of the u-boot image, you can use that.  Just to verify, I built the u-boot image from the AM180x 5.02 SDK and took the binary and created an AIS image from it, and was able to boot it on the EVM. I used the command-line tool, called HexAIS, instead of the AISGen GUI.  The command line I used was:

    HexAIS_OMAP-L138.exe -ini OMAP-L138.ini -o boot.ais -entrypoint 0xc1080000 u-boot.bin@0xc1080000

    The INI file I used is attached to this post.  The only thing I had to do differently from my typical use was to enable the UART2 LPSC (with the PSCCONFIG section in the INI file).  Otherwise the u-boot image would hang in the serial driver.  I guess u-boot expects the UART peripheral to be powered up already.

    If you are not familiar with the command line tool, you can get as part of the flash and boot utilities package.

    Regards, Daniel

    OMAP-L138.ini
  • Hi Daniel,

    First of all thanks so much for your support, I really appreciate it.

    Your INI file works fine. I've dug a little bit more to understand what was wrong in my AISgen GUI configuration, and the point was the UART2 LPSC missing configuration. Probably something has changed between U-boot PSP 3.20 and 3.21, because 3.20 works fine even with no LPSC configuration. Hope this can help other people too.

    You INI file is really interesting. I've noticed an [AIS_Set] section related to mDDR: is it possible to configure this parameters with AISgen GUI tool? What is exactly this configuration needed for? There are also other differences with respect to those files http://processors.wiki.ti.com/index.php/File:OMAP-L138_inifiles.zip that are linked at http://processors.wiki.ti.com/index.php/GSG:_DA8x/OMAP-L1/AM1x_DVEVM_Additional_Procedures#Flashing_Boot_Images_on_Linux_Without_CCS : I will study more...

    My 2 cents: HexAIS INI file syntax has good documentation, but some more files as example would simplify and speed-up understanding and usage of these tools. Moreover a board-specific INI file could be released for each EVM/Experimenter KIT product.  Finally it would be useful if HexAIS and AISgen-GUI will use the same syntax for ini/configuration file, to make comparison easier.

    Thanks again. Regards,
    Max

     

  • Max,

    It is possible use the AISgen GUI to do most of what Daniel did with HexAIS.  If you specify a binary file (instead of the ELF file) as the "ARM application file", you must also specify its load address with the "@<address>" syntax.  (By default, @0x80000000 will appear next to a binary file, so you would simply change this to the correct address.)  You must also specify the application entrypoint using a separate field on the "General" tab.  With these options, you can generate an AIS from the u-boot binary instead of trying to use the ELF.

    AISgen also has the ability to configure LPSC.  Simply check the "Configure PSC" option on the main screen and then navigate to the PSC tab.

    There are still a few things that HexAIS does that AISgen can't do.  One of these is the ability to write arbitrary fields to memory mapped registers (i.e. AIS_Set).  That said, AISgen will apply some appropriate settings like this when you tell it to configure mDDR.

  • Hi Joe

    Thanks for your further clarifications. My question was about this section of Daniel INI file:

    ; Set DDR_PDENA and CMOSEN in DDR_SLEW register of SYSCFG1 module
    ; This is needed when using mDDR memory
    [AIS_Set]
    TYPE = 0x00050403
    ADDRESS = 0x01E2C004
    DATA = 0x00000003
    SLEEP = 0x00000000

    This will generate the following AIS code that will set bits CMOSEN and DDR_PDENA in DDR_SLEW register (0x01E2C004):

    0x58535907,
    0x00050403,
    0x01E2C004,
    0x00000003,
    0x00000000,

    But using AISgen GUI tool, even if I select mDDR into DDR configuration tab, the generated code does not include anything like these lines. So debugging DDR_SLEW register with CCS, I can see that when I load file generated with Daniel INI bits 4 and 5 are set to 1, while when I load AISgen GUI generated file those bits are letf to 0.

    My main question is: do I need to set CMOSEN and DDR_PDENA or not?

    Tec. Ref. Manual seems to say yes, but things seem to work even without setting them.

    Moreover I've looked at behaviour of prebuilt UBL shipped with SDK 4.01 and 5.02: both of them set only CMOSEN bit and not DDR_PDENA. I've verified this also in UBL source code from armubl-03.20.00.14: only CMOSEN is set in DEVICE_mDDRConfig function. While I'm not been able to find any reference to DDR_SLEW register in UBL source code from flash-utils-03.21.00.04.

    Finally, also in AM1808 GEL file there is no reference of DDR_SLEW configuration.

    I'm little bit confused. Thanks for any clarification.

    Regards, Max

     

     

     

  • Qmax said:

    My main question is: do I need to set CMOSEN and DDR_PDENA or not?

    Tec. Ref. Manual seems to say yes, but things seem to work even without setting them.

    Our experience has been that using mDDR memory works fine without setting these bits (the DDR2/mDDR function in the ROM does not touch these bits), but the TRM documentation was recently brought to our attention by our internal DDR expert and we made updates to support that. The SET command in the ini file was an initial test of that, but we also updated the AISGen GUI code to insert the same SET command when mDDR is selected.  I do not think that new version of the AISGen program has been released yet - I'll have to check on that.

    When in doubt, the datasheet and TRM should be followed (though it would be nice if distributed examples in the GEL files and UBL source matched the documentation). To reemphasize, though I've never seen or heard of any issue when these bits were not set, I would still recommend following the documentation.

    Regards, Daniel

  • Guys, once again thanks for your prompt clarifications. Max

  • Hi Max, Here is some information about the UART2 LPSC configuration. With PSP 3.21 you need this due to a bug in u-boot (older versions of u-boot did the LPSC configuration correctly). This bug was fixed in u-boot v2011.12, see http://git.denx.de/?p=u-boot.git;a=commit;h=ae5c77dd908edaf55025fa3f41095bfb9cb1b973 Regards, Christian
  • Hi Christian,

    Thanks so much for you patch! I have a little question about it: now serial console starts to work just after board_init (I suppose because of pinmux and other configurations), and this happens even if it was already configured by UBL and working with it (I can see some UBL output in console). That means I cannot print and see anything before board_init, e.g. display banner. Would it be possible to move some other configurations to board_early_init_f to have console working from the very beginning?

    One more question: I had a quick look at other of your patches to u-boot, and some of them refer to AIS format. Is it possible to generate u-boot binary in AIS format from u-boot source code without any additional external tool? Is this feature available in u-boot mainline? Does mainline support all of the features of TI PSP 3.21.0.4 u-boot?

    Thanks for your time and hints.

    Regards,
    Max

  • Hi Max,
    Qmax said:

    Hi Christian,

    Thanks so much for you patch! I have a little question about it: now serial console starts to work just after board_init (I suppose because of pinmux and other configurations), and this happens even if it was already configured by UBL and working with it (I can see some UBL output in console). That means I cannot print and see anything before board_init, e.g. display banner. Would it be possible to move some other configurations to board_early_init_f to have console working from the very beginning?

    This is a u-boot question so I recommend you ask it in the u-boot mailing list. I think with a hack it is possible but I think there are also other debugging tools.
    Qmax said:

    One more question: I had a quick look at other of your patches to u-boot, and some of them refer to AIS format. Is it possible to generate u-boot binary in AIS format from u-boot source code without any additional external tool? Is this feature available in u-boot mainline? Does mainline support all of the features of TI PSP 3.21.0.4 u-boot?

    Thanks for your time and hints.

    Regards,
    Max

    Yes it is possible to generate AIS with the mkimage tool in u-boot. You'll need the most recent mainline u-boot from the git repository. Have a look at the doc/README.Davinci file. I am not sure but I think mainline does not yet support MMC.

    Regards, Christian

  • Daniel Allred said:

    My main question is: do I need to set CMOSEN and DDR_PDENA or not?

    Tec. Ref. Manual seems to say yes, but things seem to work even without setting them.

    Our experience has been that using mDDR memory works fine without setting these bits (the DDR2/mDDR function in the ROM does not touch these bits), but the TRM documentation was recently brought to our attention by our internal DDR expert and we made updates to support that. The SET command in the ini file was an initial test of that, but we also updated the AISGen GUI code to insert the same SET command when mDDR is selected.  I do not think that new version of the AISGen program has been released yet - I'll have to check on that.

    When in doubt, the datasheet and TRM should be followed (though it would be nice if distributed examples in the GEL files and UBL source matched the documentation). To reemphasize, though I've never seen or heard of any issue when these bits were not set, I would still recommend following the documentation.

    [/quote]

    Hello,

    We observed random freezes on our design especially running in lower temperatures. (+15 down to -30 C, ) Our design is based on AM1806 with mDDR memory.

    When we set CMOSEN and DDR_PDENA bits in DDR_SLEW register the problem is solved.

    For your information.

    Regards,

    Alper