All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>,
	Dan Malek <dan@embeddededge.com>
Subject: Re: [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
Date: Thu, 29 Dec 2005 18:42:29 -0200	[thread overview]
Message-ID: <20051229204229.GB9751@dmt.cnet> (raw)
In-Reply-To: <20051222195221.GA9494@dmt.cnet>

On Thu, Dec 22, 2005 at 05:52:21PM -0200, Marcelo Tosatti wrote:
> Hi,
> 
> The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx. 
> 
> The first entry is written with the same virtual/physical address, which
> renders it invalid:
> 
> BDI>rms 792 0x00001e00
> BDI>rms 824 1
> BDI>rds 824
> SPR  824 : 0xc08000c0  -1065353024
> BDI>rds 825
> SPR  825 : 0xc0800de0  -1065349664
> BDI>rds 826
> SPR  826 : 0x00000000            0
> 
> And the second entry, in addition, does not have its TLB index set
> correctly.
> 
> Dan, I'm afraid that, with this problem fixed, the issue you mentioned
> before with relation to conflicts with the vmalloc space becomes real.
> 
> * only pin available RAM at initial_mmu, the pinned mappings pointing
> beyond the end of physical RAM cause conflicts with vmalloc() space.
> 
> Is there any way to know the RAM size at this point in boot? The bd_t
> structure is board-specific, so no chance at offseting bd_t to reach the
> "mem_size" field.

None of this is necessary, we only need to define VMALLOC_START such
that it won't conflict with pinned space, as the Book-E 44x port already
does.

      reply	other threads:[~2005-12-29 20:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22 19:52 [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set Marcelo Tosatti
2005-12-29 20:42 ` Marcelo Tosatti [this message]

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=20051229204229.GB9751@dmt.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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.