Hi All,
I am newbie of processors.
I have few doubts in MPC8641D. here they are
1. If two cores uses differenct OS (AMP) and if Low offset memory mode is selected, Can two cores still access/address 64GB?( or they see only 32GB?).
2. Boot ROM location range is from 0x0_FF80_0000 to 0x0_FFFF_FFFF. But, Boot flash/ROM will be connected through LBC.
Then, address range from 0x0_FF80_0000 to 0x0_FFFF_FFFF should be mapped to LBC. How is the actual process? How booting of MPC happens initially?
3. What is the difference of mapping performed by ATMU's and LAW's?
Pls reply...
Thank You.
Vinod
已解决! 转到解答。
> If YES, What will the other space contain (from 5Kbytes 512 bytes location to 256
> Mbyte location)? If No, inform me the other usages.
It contains anything you want it to contain. It is there to allow you to design your software and address mapping to make something that works.
The address space is so big it isn't worth mapping tiny areas the size of the vector area. The chip decodes only enough address lines to remap that 256M.
Tom
I'm new to the MPC8641 and the E600 and have only looked at the manual in response to your question.
This device is very complicated. I wouldn't recomment a "newbie" going anywhere near it, but to get experience on something a lot simpler first. I would also recommend buying a working operating system for it rather than try to have it run in a "bare metal" mode. Power chips usually need a complicated MMU set up (or at least the BATs programmed) before you can even turn the cache on.
The "Chapter 2 Memory Map" section seems to describe the system pretty well.
It might help to think of the LAWs as "very flexible programmable chip select decoders". They do simple and normal things like determining where the RAM appears in the address space, but also more complicated things like where the memory spaces provided by the PCI Express and RapidIO appear to the CPU core.
The ATMUs are an extra level of address mapping between "external address spaces" (PCI Express and RapidIO) and the ones the CPU is using. So the LAW may map a PCI space to (say) 1G in the CPU's address space, but the CPU needs to generate addresses in the PCI space at 10G, 20G and 50G. So the LAW maps the CPU to the PCI, and then there would be three ATMUs mapping parts of that space out to 10, 20 and 50G. It gets very complicated very fast.
Start by drawing pictures. That's the only way I can keep track of this sort of stuff.
"Low Offset Memory Mode" only looks to remap the first 256M on Core 1 to 256M-512M.
The E600 is a 32-bit PPC core with 32 bit virtual addresses. The MMU or BATs have to be used to generate the 36-bit addresses that get you to 64G. Didn't we go through this nightmare in the 1980's when 16 bit CPUs started sprouting different sorts of "page registers" to get over the 64k boundary?
Tom
Hello Tom,
Tthanks for your reply.
You mentioned {"Low Offset Memory Mode" only looks to remap the first 256M on Core 1 to 256M-512M.} , but as per the MPC8641D data sheet, if this mode is enabled it remaps the every address of the CORE1 by adding 256Mbytes of offset addresss.
My assumption is for all address given by CORE1, MCM will add 256MByte offset to the address. Except for some exception handler routines.
Can you confirm whether my assumotion is correct? If its not correct, please explain about it one more time?
Thank you,
Vinod
2.1.1 Low Memory Offset ModeTo facilitate this, the device provides the ability totranslate (remap) a range of addresses starting at address0x_0000_0000 for e600 core 1 through a low memory offsetfeature. (No translation capability is provided fore600 core 0.) A configuration signal sampled at power-onreset enables this capability. (See Section 4.4.3.5,“e600 Core 1 Low Memory Offset Mode,” for a detaileddescription of this bit.) The range corresponds toa fixed 256-Mbyte window.
My reading of "The range corresponds to a fixed 256-Mbyte window.".
If you follow the section link in the above section it states again:
4.4.3.5 e600 Core 1 Low Memory Offset ModeAs described in Section 2.1.1, “Low Memory Offset Mode,”the device provides the capability for accesses to thelowest 256 Mbytes of real addresses from e600 core 1to be offset in order to provide each core with aunique and private address space in actual memory.
"accesses to the lowest 256 Mbytes", meaning the other 64G-256M isn't remapped.
Tom
Hi Tom,
Thank you for your quick reply.
I understood Low memory offset mode functionality (need some clarity still).
In datasheet, mentioned
[In certain dual core, dual operating system applications, each processor must see a distinct and private
physical address space for a range of addresses starting at address 0x0_0000_0000. For example, in the
e600 core, address translation is disabled for both instruction fetches and data accesses beginning with the
first instruction of an exception-handler routine. As the exception vectors are located at fixed addresses
(ranging from 0x0_0000_0100 to 0x0_0000_1600 for the e600 core) and as each OS may wish to point to
unique exception handler routines, a means must be provided for each core to see these real addresses in
separate physical address spaces. Other system considerations may also necessitate creation of a private
range of addresses in some range of low memory.]
Exception handler routines are stating at 256 bytes to 5Kbytes 512 bytes location.
Do this mode is only used/developed because the processors need to see a differenct space for exception handler routines?
Is this the only reason for devolping that mode? If YES, What will the other space contain (from 5Kbytes 512 bytes location to 256 Mbyte location)? If No, inform me the other usages.
Thanks
Vinod
> If YES, What will the other space contain (from 5Kbytes 512 bytes location to 256
> Mbyte location)? If No, inform me the other usages.
It contains anything you want it to contain. It is there to allow you to design your software and address mapping to make something that works.
The address space is so big it isn't worth mapping tiny areas the size of the vector area. The chip decodes only enough address lines to remap that 256M.
Tom