• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1421 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.

DDR and other initialization in kernel

Dennis McLeod
Intellectual 925 points

Other Parts Discussed in Thread: AM3871, AM3874

My company has developed a product using the AM3874 (soon to be AM3871). I have gotten familiar with the sources for u-boot and the kernel using the psp04.04.00.01 BSP and have now got u-boot flashed into NOR flash and booting on startup. I am now digging into the kernel and one of the major differences between our platform and the TI8148_EVM mistral board is that we only have 1G of DDR3 instead of 2GB. So u-boot initializes the ddr configs and the memory windows are 0x80000000-0x9fffffff (bank 1) and 0xa0000000-0xbfffffff (bank 2). It seems the kernel has many places where it assumes it will be copied to 0xc0000000 (during decompression?) and that is outside the range of my DDR window.  I saw some references online that said that 0xc0000000 was a virtual address and not a physical one. So now I'm even more confused. As of right now, I have uImage flashed to NOR at 0x08060000 and it obviously crashes sometime shortly after decompressing itself into DDR. What and where do i make changes to make the kernel work with my memory config? At what point in the process does the MMU become involved? 

I have read the page at http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map and it looks like that default memory map fits.. but I will eventually be straying from that as well, as our production processor is the AM3871 with none of that video and audio fluff. For now, I am only trying to get the default kernel to stay within my restricted memory size. 

Thanks in advance! 

Dennis

  • 0
    Guru 31670 points

    Dennis,

    Dont worry about the virtual address 0xC000_0000. Even if your code is running from 0x8000_0000 offset (physical address) during bootup the kernel startup code will setup a page table where the virtual addresses in the 0xC000_0000 range will get mapped to the PA range 0x8000_0000 according to your code layout. 

    So, eventually you can map any physical address to the virtual address 0xC000_0000. No matter wherever you SDRAM is located, you can get a kernel image layout starting from 0xC000_0000. This is the fundamental of multi programming using virtual memory.

  • 0 in reply to Renjith Thomas
    Intellectual 925 points

    There must be somewhere that I need to tell it the actual amount of ram is not 2GB but only 1GB.. no? 

    Also, the decompression stub at the beginning of uImage.. what is the process?  In NOR's u-boot, i do `bootm 0x08060000` which is the location of uImage in NOR flash. That must execute in place at least at first, but then what? Does it copy the compressed image to some place (where?) in DDR, then decompress itself to some *other* location in DDR (where?).  OR, does the compressed uImage remain in NOR flash and the decompression stub decompresses straight into DDR (again, where?)

  • 0 in reply to Dennis McLeod
    Guru 26430 points

    Maybe try using the bootarg mem. Add "mem=512M" to your bootargs. No familiar with the AM387x platform. All that audio and video stuff might use DSPLINK or SYSLInk that will use memory above the region allocated to Linux. I can't remember how the codecs are assigned their memory. Possible that it is hard-coded to the upper 1GB in the compiled codec. You might have to remove the audio/video stuff to get a clean boot.

    EDIT: Missing words.

  • 0 in reply to Dennis McLeod
    Guru 31670 points

    As Norman suggested you can use the mem= bootarg to reduce the memory available to kernel. In your case while decompressing, it will read from NOR and uncompress and write to DDR. These addresses are not really important, as the startup code is position independent code and it can run from any where. Once MMU is setup, it will take care of the mapping by using the current PC.