• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 374 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.

AM5746: PDK driver write to section

rei
Mastermind 6155 points
Part Number: AM5746

Hi,

My customers are developing an application using AM5746.

Customer has made a program that checks the "program area" on SDRAM during program execution and detects unexpected writes such as garbled SDRAM.

Customer has made program that checks "program area" on SDRAM during program execution and detects unexpected writes such as garbled SDRAM. They target [.text] and [.rodata] sections on memory map.

Now customers are worried about [.rodata] being written by PDK driver.

For example, USB_open() of pdk,
USB_config[] array is rewritten, -> data in [.rodata] section is changed -> false detection.

There is a method that doesn't use "const" of USB_config[], but we are looking for another method because we don't know the effect of this change.

Question 1:
Is there a good way?

Question 2:
Is there any other driver that write [.rodata] or [.text] section_ They are looking for countermeasures as well as Q1.

AM574x
CCS v8
GCC GNU v6.3.1(Linaro)
HW AM57 Custom Board
SW pdk_am57xx_1_0_11
bios_6_76_00_08
XDCTools 3.50.3.33

  • 0
    TI__Genius 14680 points

    rei,

    Can you clarify the question? Are you looking for a mechanism to protect against/detect errant accesses to memory in the application, or you are concerned specifically about the USB LLD in the PDK having a memory initialization problem?

  • 0 in reply to Dave Bell
    Mastermind 6155 points

    Hi Dave,

    Thank you for your reply. I'm checking what customers want.

    Regard, Rei

  • 0 in reply to rei
    TI__Genius 14680 points

    Rei,

    Just checking in. Is there further clarity to the request?

    Best regards,

    Dave

  • 0 in reply to Dave Bell
    Mastermind 6155 points

    Hi Dave,

    I'm sorry for the delayed reply. Customers are working on another issue. Please wait for a little while longer.

    Regards, Rei

  • 0 in reply to rei
    Mastermind 6155 points

    Hi Dave,

    I asked the customer.

    Customer want to prevent PDK USB driver from rewriting the [rodate] section.

     

    Customer application check that [rodate] and [text] areas have not been rewritten incorrectly.

    The data placed in [rodate] section should generally be "Read only".

    Therefore, customers are dissatisfied with the behavior of the USB driver that rewrites [rodate].

     

    Question 1:

    Is there a way to improve these?

    Question 2:

    Do the following drivers rewrite the [rodate] section as well as the USB driver?

    emac / gpio / i2c / icss_emac / mmcsd / pcie / spi / uart / usb / edma / fatfs

     

    Regards, Rei

  • 0 in reply to rei
    Mastermind 6155 points

    Could you please update me about this?

  • 0 in reply to rei
    TI__Genius 14680 points

    rei,

    USB_config[] has driver level config details. In normal default cases it is expected to be static and hence it is even declared as constant. However, we have a way for the application to update the config used by driver by calling USB_getConfig() API and updating.

    Can you confirm if you are making any change in application context? In that case the type should not be const.

    Best regards,

    Dave

     

  • 0 in reply to Dave Bell
    Mastermind 6155 points

    Hi Dave,

     

    Thank you for your reply.

    -Can you confirm if you are making any change in application context? In that case the type should not be const.

    What exactly do you mean by that? Do we confirm if USB_getConfig () API is used in the application?

     

    Regards, Rei

  • 0 in reply to rei
    TI__Genius 14680 points

    rei,


    The USB example applications do write to the USB_Config if it needs to change some configuration for the USB drivers. Examples of those could be dma option, or if USB3.0 is enabled, or if the USB instance have been opened and configured.


    So for USB, the USB config shouldn’t be constant.

    Best regards,

    Dave

  • 0 in reply to Dave Bell
    Mastermind 6155 points

    Thank you for your reply. I almost understood the meaning!

     

    As mentioned in my first post, customers app seems to have changed USB_config.

     

    Question 1:

    If so, is it correct for customers to remove "const"?

    What kind of effect will it have when removed? (Is there something wrong?)

     

    Question 2:

    Do these drivers change const variables due to DMA or other settings?

     

    emac / gpio / i2c / icss_emac / mmcsd / pcie / spi / uart / usb / edma / fatfs

  • 0 in reply to rei
    TI__Genius 14680 points

    rei,

    For USB, USB_config[] can be changed from const. The customer is correct that the data is being modified, per the driver operation, so it would be more appropriate to be in a rw region.

    This looks to be constrained to the USB and we don't expect that there is a broader issue with const.

    Best regards,

    Dave