• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 102 subscribers
  • Views 893 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM335x WEC 7: Where is this physical address,0x8C000000, pointing to?

Marlon Jose Masbad
Intellectual 740 points

Hi,

We are using TI's AM33x WEC 7 BSP on our custom AM335x-based device and we have modified the bootloader to add a feature that is writing sort file table of around 5K bytes in size. However, we observed that the system is having random slowness or sometimes random unmounting of NAND volumes are happening at as well.

I started debugging this and one thing that caught my attention is that in the EBOOT code our vendor is hard coding the location of the file table to this physical address, 0x8C000000.

i.e.

fileTable = (UINT32*)OALPAtoUA(0x8C000000);

He mentioned that this physical address is direct to the RAM and should not corrupt anything on the system. Well I'm not really a fan of doing such memory hard coding unless that physical address is memory map for a driver and it is the driver code were making. So I would to seek second opinion if this is really the a safe way.

My doubt is that hard coding a physical address in the RAM might actually be pointing an address that will later by used as RAMDisk for the NK.bin. Or if this not actual RAM physical address it could be corrupting something else because this memory is then memset to 0 in the code.

I think the better goal here is to store this file table somewhere in our NAND but I'm not too familiar how to do this. If you can share as well how to modify the EBOOT code to store something to the NAND, I would be grateful if you can share as well. Thanks

  • 0
    Expert 1450 points

    Marlon,

    I wholeheartedly agree, hard-coding memory addresses like that is a bad practice.

    It's bad because it is not immediately apparent what's located at that address, making it more difficult to understand what the code is doing, and its potential effects on other parts of the system.

    And it's bad because if one day you decide to modify the hardware, or change the way memory and peripherals are mapped, something like that can easily slip under the radar and lead to bugs.

    If your platform supports warm boot, where the object store contents and/or other data is expected to retain integrity across reboots, then you will need to ensure that the CE system does not attempt to store anything there. One way to achieve this is by modifying config.bib to include a MEMORY entry marked as RESERVED to prevent the CE system from using that part of the memory.

    It shouldn't be necessary to store the data in NAND, unless of course you need persistence in the event of a power failure or the like, but it doesn't sound like that's the case. If you decide to go down that route, remember that you will need to handle things like bad blocks, error detection and correction, wear leveling, and obviously you need to be careful not to corrupt other data in flash as well.

    Best regards,
    Carsten

  • 0
    Genius 5470 points

    As Carsten hints modifying the .bib file with a RESERVED block Is the proper way to allocate a block of memory. Be sure to reserve the same space in all three bib files, the xldr, the eboot and the os's. As long as it is tagged RESERVED the memory management unit will never allocate anything to it.