[U-Boot-Users] MMU and Linux kernel booting
Hi all,
I have a couple of questions regarding the MMU. I'm working with a custom hardware based on Cirrus Logic EP9315 processor. As the on-chip SDRAM controller is unable to map the memory in contiguous regions, I have to use the MMU to do that. On the other hand Linux requires that MMU is off when it boots (http://www.arm.linux.org.uk/developer/booting.php). 1) In my understanding the function cleanup_before_linux (cpu/arm920t/cpu.c) is supposed to perform this opearation but it does not. Is this the right place to turn MMU off? 2) The second questions refers to memory tags. They should describe _physical_ mapping, right? If this is correct, the bd->bi_dram fields should be extended in order to describe both physical and virtual regions. Does it make sense?
Thanks in advance,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
In message 6.0.1.1.0.20041207154508.01efa490@192.168.2.1 you wrote:
I'm working with a custom hardware based on Cirrus Logic EP9315 processor. As the on-chip SDRAM controller is unable to map the memory in contiguous regions, I have to use the MMU to do that.
... if you need it. Maybe one bank of memory is sufficient for the operation of U-Boot?
- In my understanding the function cleanup_before_linux
(cpu/arm920t/cpu.c) is supposed to perform this opearation but it does not. Is this the right place to turn MMU off?
Yes.
- The second questions refers to memory tags. They should describe _physical_
mapping, right? If this is correct, the bd->bi_dram fields should be extended
Right.
in order to describe both physical and virtual regions. Does it make sense?
Why would you need virtual addresses? U-Boot does not need these for operation, and Linux will not use these anyway.
Best regards,
Wolfgang Denk
I'm working with a custom hardware based on Cirrus Logic EP9315 processor. As the on-chip SDRAM controller is unable to map the memory in contiguous regions, I have to use the MMU to do that.
... if you need it. Maybe one bank of memory is sufficient for the operation of U-Boot?
It is definitively sufficient for U-Boot/Linux but I think it is not for (please don't blame me) WindowsCE (brrrrr!).
- The second questions refers to memory tags. They should describe
_physical_
mapping, right? If this is correct, the bd->bi_dram fields should be
extended
Right.
in order to describe both physical and virtual regions. Does it make sense?
Why would you need virtual addresses? U-Boot does not need these for operation, and Linux will not use these anyway.
For example U-Boot should let the user to use one virtual and contiguous memory region (for this purpose I suggest to introduce something like bd->bi_dram_v). For "regular" operations, it could use the existing bd->bi_dram fields (for example to set up the memory tags for the kernel).
Regards,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
In message 6.0.1.1.0.20041207170247.03f5a280@192.168.2.1 you wrote:
... if you need it. Maybe one bank of memory is sufficient for the operation of U-Boot?
It is definitively sufficient for U-Boot/Linux but I think it is not for (please don't blame me) WindowsCE (brrrrr!).
OK - but then there is no need to bother with this problem in U-Boot.
Why would you need virtual addresses? U-Boot does not need these for operation, and Linux will not use these anyway.
For example U-Boot should let the user to use one virtual and contiguous memory region (for this purpose I suggest to introduce something like bd->bi_dram_v). For "regular" operations, it could use the existing bd->bi_dram fields (for example to set up the memory tags for the kernel).
In U-Boot, the user does not need to make any difference between physical or virtual RAM addresses. Just provide one mapping that works. For exmaple, map all your RAM banks as one big (virtually) contiguous area to (virtual) address 0x0000. Then just run U-Boot as if it were a physical mapping. Nobody will even notice.
Then turn off the MMU when booting your OS. Of course the OS will have to know where to find it's memory and how to map it.
Best regards,
Wolfgang Denk
For example U-Boot should let the user to use one virtual and contiguous memory region (for this purpose I suggest to introduce something like bd->bi_dram_v). For "regular" operations, it could use the existing bd->bi_dram fields (for example to set up the memory tags for the kernel).
In U-Boot, the user does not need to make any difference between physical or virtual RAM addresses. Just provide one mapping that works. For exmaple, map all your RAM banks as one big (virtually) contiguous area to (virtual) address 0x0000. Then just run U-Boot as if it were a physical mapping. Nobody will even notice.
Then turn off the MMU when booting your OS. Of course the OS will have to know where to find it's memory and how to map it.
Yes, this is exactly what I meant.
Thanks,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
participants (2)
-
llandre -
Wolfgang Denk