All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hawkins <dwh@ovro.caltech.edu>
To: Rune Torgersen <runet@innovsys.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux on PPC
Date: Fri, 03 Mar 2006 12:06:43 -0800	[thread overview]
Message-ID: <4408A1D3.8010506@ovro.caltech.edu> (raw)
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B8595AC@ismail.innsys.innovsys.com>


>>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.
>>
> 
> Still not right. Even the physical memory is software settable. What
> matters is what chip-select things are hooked up to, and then map those
> chip selects correctly (size, base address, access with and so on)

Hi Rune,

Thanks for responding.

Thats what I meant with 'redefined in hardware'. But yes, redefined
up to the limit of the wiring on the board of course (chip-selects
and bus widths). That's where having the board schematic is
invaluable.

But ok, I'm pretty sure I get the point, and hopefully the
original poster understands a bit more too.

Given a board that you expect to run Linux on, I would imagine
you would select hardware settings consistent with making
Linux happy, i.e., defining 'in software' (the bootloader)
the physical address map (eg. like the Embedded Planet reference
manual for the 440EP Yosemite board), and then setup U-Boot and
Linux to program the TLBs to translate to those same addresses.

When looking at the Yosemite board, I booted U-Boot and compared
device dcr settings to the recommended ones in the EP manual. Then
when I booted Linux, I took a look and found that on the whole, Linux
didn't touch too much of the things setup by U-Boot, i.e., the
responsibility for setting up the Linux environment was mainly
the job of the bootloader.

So, if I had a board with a custom bootloader, I would be
concerned that the bootloader might not know enough about
Linux, to setup the hardware correctly.

Does that sound right?

Dave

  reply	other threads:[~2006-03-03 20:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-03 19:39 Linux on PPC Rune Torgersen
2006-03-03 20:06 ` David Hawkins [this message]
2006-03-04  2:09   ` Wolfgang Denk
2006-03-04  2:51     ` David Hawkins
  -- strict thread matches above, loose matches on Subject: below --
2006-03-03 20:31 Rune Torgersen
2006-03-03 20:28 Steve Strublic
2006-03-03  2:01 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
2006-03-04  2:05       ` Wolfgang Denk

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=4408A1D3.8010506@ovro.caltech.edu \
    --to=dwh@ovro.caltech.edu \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=runet@innovsys.com \
    /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.