• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 1557 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.

Has arm UBL become useless for Omap-L138?

arthur14426
Intellectual 420 points
Other Parts Discussed in Thread: OMAP-L138, OMAP-L137, OMAPL138

Hi all,

http://elinux.org/Hawkboard#Signing_u-boot_for_NAND_boot

From the article above , I get that uboot can directly boot from NAND , so I wonder that if arm UBL become useless now for Omap-L138 ? Because AISgen tool can convert uboot( .out format ) to AIS format.

 

  • 0
    TI__Guru* 83705 points

    Arthur

    I believe that is technically true. I will let someone else correct me if I am wrong. The UBL is typically responsible for 1) Enabling the peripheral clocks 2) Enabling and configuring external memory 3) Waking up the DSP (if it is ARM+DSP device) and uboot load. I believe all of these can be comprehended using the AISGEN tools, and the uboot can also be loaded as a .out file.

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Intellectual 420 points

    Yes, maybe 138 armside ubl  is for omap-l137  compatibility . Because ,in booting process of 137 , ARM ubl is loaded by DSP ubl.

     

  • 0 in reply to arthur14426
    TI__Mastermind 24340 points

    Just a side note:

    - For OMAP-L137, the DSP boots first, and then it can wake up the ARM

    - For OMAP-L138, the ARM boots first, and then it can wake up the DSP

  • 0 in reply to Mariana
    TI__Guru* 83705 points

    Arthur

    Compatibility to other ARM+DSP devices , in general from a flow perspective could be another reason RBL-> UBL->uboot seems like the "common" flow. The functionality that you see offered on the AISGEN tools ( being able to configure the PLL, external memory) is also "new" compared to say Davinci line of devices. Infact, the initial version of the AIS tools did not support mDDR configuration completely, now they do , that was one reason to shy away from advertising eliminating the UBL etc.

    I did follow up with Linux PSP team on this post, my original response still holds good, the only caveat that they pointed out is , currently the ARM UBL supports changing the device OPP i.e. the I2C to PMIC interaction to change the CVDD , this is something that is not supported by AISGEN tools. It could possibly be done in uboot, but currently that is not supported. So that would be one use case for keeping the ARM UBL.

    Hope this helps

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Expert 2745 points

    So can I just load U-Boot on SPI Flash, instead of using UBL?  Is there a specific version of U-Boot to use and does it need to be compiled a certain way?

  • 0 in reply to Inderjit Bains
    TI__Expert 6385 points

    Hello,

    Inderjit Bains said:
    Is there a specific version of U-Boot to use and does it need to be compiled a certain way?

    No, the default U-Boot compilation results in a U-Boot elf file (just called u-boot and placed in the top directory). This is true with all versions of U-Boot.

    Thanks,

    Sekhar

  • 0 in reply to Sekhar Nori
    Expert 2745 points

    I thought the elf file was for debuging through JTAG.  Can I just program it at location 0 in SPI Flash?

  • 0 in reply to Inderjit Bains
    Expert 2745 points

    Follow-up to the above:  where is the SDRAM initilized in the U-Boot?  I have 128MB on my board, which uses 3 bank selects.  I'm not sure if updating PHYS_SDRAM_1_SIZE in da850evm.h will be enough.  Where are the timings set?

  • 0 in reply to Inderjit Bains
    Expert 2745 points

    Both D:>sfh_OMAP-L138.exe -flash_noubl -v u-boot and D:>sfh_OMAP-L138.exe -flash ubl_OMAPL138_SPI_MEM.bin u-boot.bin produce the same result:

    Attempting to connect to device COM1...
    Press any key to end this program at any time.

    (AIS Parse): Read magic word 0x41504954.
    (AIS Parse): Waiting for BOOTME... (power on or reset target now)
    (AIS Parse): BOOTME received!
    (AIS Parse): Performing Start-Word Sync...
    (AIS Parse): Performing Ping Opcode Sync...
    (AIS Parse): Processing command 0: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 8500-Byte section to address 0x80000000.
    (AIS Parse): Processing command 1: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 716-Byte section to address 0x80002134.
    (AIS Parse): Processing command 2: 0x58535906.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Performing jump and close...
    (AIS Parse): AIS complete. Jump to address 0x80000000.
    (AIS Parse): Waiting for DONE...
    (AIS Parse): Boot completed successfully.

    Waiting for SFT on the OMAP-L138...

  • 0 in reply to Inderjit Bains
    Expert 2745 points

    Even more on this:

    I tried  "D:>sfh_OMAP-L138.exe -erase" and got the same result.  I checked SP1_CLK (connected to CPU pin G19).  It goes high and stays high - there is never a clock signal on it.  I'm only using RX and TX for UART2.  CTS and RTS were not implemented.  Can this be an issue?