[U-Boot-Users] still confused about configuration of memory
It's embarrassing to be the fool who asks all the stupid questions, but I actually can't help it... The task is the following:
I have a custom board. I've 64 MB SDRAM on CS#1 and 16MB flash on CS#0. I want to port the U-Boot to boot Linux.
So what I read out of the README and documentation is:
1. To setup the SDRAM is my own task. My <NAME>.c of my own custom U-Boot port implements a function initdram() that will take care of this. 2. I have to map the SDRAM to 0x0, as the U-Boot wants me to do that. 3. As the SDRAM must be at 0x0, I must map the Flash that was there before somewhere else. 4. In case I have "split" the U-Boot code into parts for I have other important information in the first sectors of my flash, I can have a CFG_MONITOR_BASE that is different from CFG_FLASH_BASE.
Are these assumptions right?
Unfortunately that was only the first question:
How does the U-Boot know which memory banks I use and which type of memory there is? Is it possible it doesn't know?
Especially I didn't understand why one would need to preliminary map some memory bank somewhere else. What reason could be there not to map the memory to it's final location in the first place? The comment in the cpu/mpc8xx/cpu_init.c (line 116 ff.) confused me even more when I was looking for answers there.
Peter Asemann
In message 429C7DF0.9080600@web.de you wrote:
- To setup the SDRAM is my own task. My <NAME>.c of my own custom
U-Boot port implements a function initdram() that will take care of this.
Right.
- I have to map the SDRAM to 0x0, as the U-Boot wants me to do that.
Wrong. It's not primarily U-bOot, but Linux - on PowerPC systems - which usually needs to have SDRAM starting at physical address 0.
- As the SDRAM must be at 0x0, I must map the Flash that was there
before somewhere else.
Right.
- In case I have "split" the U-Boot code into parts for I have other
important information in the first sectors of my flash, I can have a CFG_MONITOR_BASE that is different from CFG_FLASH_BASE.
Wrong. CFG_MONITOR_BASE is where U-Boot begins. If you split it up the base does not (necessarily) change.
Unfortunately that was only the first question:
Wrong again. These were 4 questions already.
How does the U-Boot know which memory banks I use and which type of memory there is? Is it possible it doesn't know?
You write the code to initialize the memory controller, so you tell it.
Especially I didn't understand why one would need to preliminary map some memory bank somewhere else. What reason could be there not to map the memory to it's final location in the first place? The comment in the
Assume you have more than one bank of RAM or flash, and you want to map them such that they form a contiguous area of memory. To do this, you need to know their size. To determine, you must run some test code which probes the memory sizes. To access the memory it must have it mapped somewhere. So what do you do? You will have to use some preliminary mapping (at least for the second and any further banks).
Assume you have only one bank of flash memory, which needs to be mapped at the end of the address space (so that the last byte of flash memory is at 0xFFFFFFFF). In this case, you need to know the size of the device to compute the start address. ... see above.
cpu/mpc8xx/cpu_init.c (line 116 ff.) confused me even more when I was looking for answers there.
Well, read the comment again, and read the memory controller section of the MPC8xx User's manual. Repeat until you understand.
Best regards,
Wolfgang Denk
participants (2)
-
Peter Asemann -
Wolfgang Denk