Linux on PPC

[David Hawkins]

>>If the vendor provided the VxWorks BSP, then hopefully they
>>also provided you with the physical memory map of the board.
>>This is what you really need to get another bootloader (eg. U-Boot)
>  
> This is *NOT* corect, and actually dangerous.

Thanks Wolfgang!

I did start the email with "I'm not an expert on this ...".

>>Step 1. Get the memory map of the board.
> 
> Never use any given memory map unreflected. At least *check* if  it's
> usable with Linux.
> 
> Many memory maps (especially those provides with some eval boards for
> demonstration purpose) will NOT work with Linux.  Remember  that  the
> memory  map  is  usually  not  cast  in  silicon,  but implemented in
> software, so you can change it as needed.

Right, thats I made sure to say; Physical Memory Map.

For example, on the Artesyn manual on their PrPMC they give a
physical memory map, and in the Yosemite board, there is a
physical memory map. I know many of the memory areas can be
redefined in hardware to have a different memory location, but
its still a physical address.

Now, when the bootloader loads, eg. U-Boot, it sets up the
memory management. Now this is where my understanding gets
shakey, since I haven't looked at much of the code, so perhaps
you can clarify. The translation unit (TLB) maps virtual addresses
(or should that be MMU output addresses) into physical addresses,
and for the Yosemite port the default translation
addresses appear to be identical to the physical addresses,
though obviously this doesn't have to be the case. Then on
top of that there is virtual memory addresses generated by
the core (input to the MMU if its enabled?), that then go
through the MMU/TLB and get mapped to physical addresses. If
I was going to do a port, obviously I'd take the time to
understand this fully :)  (I think the Linux Kernel Internals
book has a description, but its usually meaningless to me until
I play with the code).

What are the basic requirements for a Linux memory map then?

Cheers
Dave