From: David Hawkins <dwh@ovro.caltech.edu>
To: Wolfgang Denk <wd@denx.de>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux on PPC
Date: Fri, 03 Mar 2006 08:53:07 -0800 [thread overview]
Message-ID: <44087473.6020905@ovro.caltech.edu> (raw)
In-Reply-To: <20060303160434.3886335261F@atlas.denx.de>
>>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
next prev parent reply other threads:[~2006-03-03 16:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 2:01 Linux on PPC rtos
2006-03-03 2:23 ` Frank
2006-03-03 5:09 ` nreddy
2006-03-03 16:00 ` Wolfgang Denk
2006-03-03 5:10 ` David Hawkins
2006-03-03 9:33 ` Adrian Cox
2006-03-03 16:04 ` Wolfgang Denk
2006-03-03 16:53 ` David Hawkins [this message]
2006-03-04 2:05 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2006-03-03 19:39 Rune Torgersen
2006-03-03 20:06 ` David Hawkins
2006-03-04 2:09 ` Wolfgang Denk
2006-03-04 2:51 ` David Hawkins
2006-03-03 20:28 Steve Strublic
2006-03-03 20:31 Rune Torgersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44087473.6020905@ovro.caltech.edu \
--to=dwh@ovro.caltech.edu \
--cc=linuxppc-embedded@ozlabs.org \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.