Re: Linux on PPC

2 messages, 2 authors, 2006-03-03 · open the first message on its own page

Re: Linux on PPC

From: Wolfgang Denk <hidden>
Date: 2006-03-03 16:04:36

In message [off-list ref] you wrote:
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.
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.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
                            - Peter Curran in [off-list ref]

Re: Linux on PPC

From: David Hawkins <hidden>
Date: 2006-03-03 16:53:44

quoted
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 ...".
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help