All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] setup.c: introduce __pa_symbol() and get ride of CPHYSADDR()
Date: Mon, 9 Oct 2006 15:58:17 +0100	[thread overview]
Message-ID: <20061009145817.GB18308@networkno.de> (raw)
In-Reply-To: <452A5BEA.2060500@innova-card.com>

Franck Bui-Huu wrote:
[snip]
> >> If so could you explain the choice of these values
> >> because I fail to understand it.
> > 
> > It allows to load a 64-bit kernel in KSEG0,
> 
> sorry to be ignorant of 64 bit kernels, but what's the point
> to load them in KSEG0.

Smaller code with better performance.

> > and use short 2-instruction symbol references there.
> 
> do you mean "it allows to use only 2 'lui' instructions to load
> a symbol address into a register" ?

It allows a 2-instruction "lui ; addiu" sequence instead of a
6-instruction "lui ; lui ; addiu ; addiu ; dsll32 ; addu" sequence.

> Futhermore I don't see how some part of the kernel convert virtual
> address into a physical one with such values. For example in setup.c,
> the function resource_init() does:
> 
> 	code_resource.start = virt_to_phys(&_text);
> 	code_resource.end = virt_to_phys(&_etext) - 1;
> 	data_resource.start = virt_to_phys(&_etext);
> 	data_resource.end = virt_to_phys(&_edata) - 1;
> 
> How does it work in this case ?

Those are addresses in 64-bit space, no special handling is needed
there.

The same doesn't hold for the initrd addresses supplied by the (32-bit)
firmware. The firmware doesn't convert the kernel parameters to 64-bit
values because the O2 kernel used to allow a pure 32-bit build, and the
firmware can't find out what's actually inside the object file.


Thiemo

  reply	other threads:[~2006-10-09 14:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 13:36 [PATCH] setup.c: introduce __pa_symbol() and get ride of CPHYSADDR() Franck Bui-Huu
2006-10-06 17:21 ` Thiemo Seufer
2006-10-09 11:58   ` Franck Bui-Huu
2006-10-09 13:21     ` Thiemo Seufer
2006-10-09 14:25       ` Franck Bui-Huu
2006-10-09 14:58         ` Thiemo Seufer [this message]
2006-10-09 15:30           ` Franck Bui-Huu
2006-10-09 15:51           ` Atsushi Nemoto
2006-10-09 16:59             ` Thiemo Seufer
2006-10-10  8:49               ` Atsushi Nemoto
2006-10-10 13:49                 ` Franck Bui-Huu
2006-10-10 14:19                   ` Atsushi Nemoto
2006-10-10 15:01                     ` Franck Bui-Huu
2006-10-10 15:29                       ` Atsushi Nemoto
2006-10-10 16:04                         ` Franck Bui-Huu
2006-10-10 16:16                           ` Franck Bui-Huu
2006-10-10 21:51                           ` Ralf Baechle
2006-10-11  3:11                             ` Atsushi Nemoto
2006-10-11  9:37                             ` Franck Bui-Huu

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=20061009145817.GB18308@networkno.de \
    --to=ths@networkno.de \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=vagabon.xyz@gmail.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.