From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sven Luther <sven.luther@wanadoo.fr>
Cc: linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: OF properties access ?
Date: Mon, 19 Jan 2004 20:01:33 +1100 [thread overview]
Message-ID: <1074502892.813.41.camel@gaston> (raw)
In-Reply-To: <20040118143225.GA6717@iliana>
On Mon, 2004-01-19 at 01:32, Sven Luther wrote:
> On Mon, Jan 19, 2004 at 10:21:36AM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Sun, 2004-01-18 at 23:07, Sven Luther wrote:
> > > On Sat, Jan 17, 2004 at 02:48:11PM +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > >
> > > > > But this doesn't reply me on why my attempts to read back integer values
> > > > > from OF property only result in the machine hanging, and since it is
> > > > > really early on, i don't even get serial console output to have an idea
> > > > > why :/
> > > > >
> > > > > in particular i cloned the code reading l2cr-value, and changed it to
> > > > > l2cr and instead of reading the value, i got only kernel silently dying.
> > > >
> > > > Show me the code and the relevant device-tree bits.
> > >
> > > Ok, here is the code that dies :
> > >
> > > void pegasos_set_l2cr(void) {
> >
> > Grrr... please put the { on a different line
>
> Ok. (altough i think this is a subject of philosophical debate :)
>
> > > struct device_node *root = find_path_device("/");
> > > char *machine;
> > > struct device_node *np;
> > >
> > > /* On Pegasos, enable the l2 cache if needed, as the OF forgets * it */
> >
> > Check if root isn't NULL...
>
> Ok.
>
> > > machine = get_property(root, "model", NULL);
> >
> > Check if machine isn't NULL...
>
> Ok.
>
> > > if (strncmp(machine, "Pegasos", 7) == 0) {
> > > /* Enable L2 cache if needed */
> > > np = find_devices ("cpus");
> > > if (np == 0)
> > > np = find_type_devices("cpu");
> > > if (np != 0) {
> > > unsigned int *l2cr = (unsigned int *)
> > > get_property (np, "l2cr", NULL);
> >
> > The above got you a _pointer_ to the value, the code below uses
> > that point directly as the value, which is obviously wrong
>
> Arg, i copied the wrong version.
>
> > > if (!(l2cr & 0x80000000)) {
> > > _set_L2CR(0);
> > > _set_L2CR(l2cr | 0x80000000);
> > > }
> >
> > The above should have been...
> >
> > if (l2cr && !((*l2cr) & L2CR_L2E)) {
> > _set_L2CR(0);
> > _set_L2CR((*l2cr) | L2CR_L2E);
> > }
>
> In reality, i had both the code using l2cr, and the one using *l2cr, and
> even a version like the pmac_setup code, which copied the content of the
> l2cr pointer to a l2cr_value int, but none worked.
>
> > Now that is said providing your algorithm is right, that is the
> > device-tree provides you with an "l2cr" property containing the
> > right settings but not the enable bit, and matching what your CPU
> > is doing. If the device-tree has L2E set but not the CPU, you
> > may want to do things differently...
>
> Well, i have bugged the OF people, and they have indeed set the L2E bit
> in future versions of the OF. Mostly what happens right now, is that L2E
> is not set (i get a something around 30% decrease in compilation time
> when doing the l2cr=0x80000000 thingy) and the l2cr property returns 0.
>
> I also have had similar troubles with the /proc/pci@C0000000/display
> bus_number property, altough it didn't die there.
Well... You can move that code to a later place where you can printk
and debug waht's up. It's also possible that the _set_L2CR routine
in the kernel you are working on isn't totally correct for your CPU
model... Do you have the 7447 recongnized at all in cputable ?
> > > $ hexdump /proc/device-tree/cpus/PowerPC,74x7/l2cr
> > > 0000000 0000 0000
> >
> > So you "l2cr" value is just 0... Setting it to 0x80000000 means enabled
> > without any setting bit... that might actually be correct for on-die L2
> > though, check the CPU spec anyway. It is correct for my 7455
>
> It is either a 7447 or a 750Cxe. It is correct for both, and we have
> been using the l2cr=0x80000000 option as kernel boot option since ages.
> It quickly becomes old to have to type this per hand each time though,
> as we have no boot loader (yet).
>
> Friendly,
>
> Sven Luther
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-01-19 9:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 11:46 OF properties access ? Sven Luther
2004-01-15 1:49 ` Benjamin Herrenschmidt
2004-01-15 7:44 ` Sven Luther
2004-01-17 3:48 ` Benjamin Herrenschmidt
2004-01-18 12:07 ` Sven Luther
2004-01-18 23:21 ` Benjamin Herrenschmidt
2004-01-18 14:32 ` Sven Luther
2004-01-18 14:51 ` Sven Luther
2004-01-18 15:05 ` Sven Luther
2004-01-19 9:05 ` Benjamin Herrenschmidt
2004-01-18 22:22 ` Sven Luther
2004-01-19 9:04 ` Benjamin Herrenschmidt
2004-01-19 1:35 ` Dan Malek
2004-01-19 9:01 ` Benjamin Herrenschmidt [this message]
2004-01-19 10:17 ` Sven Luther
2004-01-19 11:42 ` Benjamin Herrenschmidt
2004-01-19 12:06 ` Sven Luther
2004-01-19 21:36 ` Benjamin Herrenschmidt
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=1074502892.813.41.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=sven.luther@wanadoo.fr \
/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.