OF properties access ?

OF properties access ?

[Sven Luther]

Hello,

I am a bit in doubt about how to go around of accessing the OF
properties.

There seem to be various get_properties functions available, but is
there any documentation on how they work ?

In particular, i have in OF, a /cpus/PowerPC,74x7. when doing
.properties there, i have a l2cr property (which 0x0 (0)).

In the same vein, i have a /pci@C0000000, which contains a
pci-bridge-number i would like to read (which contains 0x1 (1)).

For the l2cr thingy, i have based myself on some pmac_setup.c code which
does :

        /* Checks "l2cr-value" property in the registry */
        np = find_devices("cpus");
        if (np == 0)
                np = find_type_devices("cpu");
        if (np != 0) {
                unsigned int *l2cr = (unsigned int *)
                        get_property(np, "l2cr-value", NULL);
                if (l2cr != 0) {
                        seq_printf(m, "l2cr override\t: 0x%x\n", *l2cr);
                }
        }

But, the pmac OF (at least on the powerbook i got someone to check for
me), does have a l2cr property, not a l2cr-value one. The same goes on
for voltaire.debian.org, which is a dual G4 500MHz.

Does this mean that the -value appended is for looking at the content of
l2cr, or something such ?

Friendly,

Sven Luther


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

> But, the pmac OF (at least on the powerbook i got someone to check for
> me), does have a l2cr property, not a l2cr-value one. The same goes on
> for voltaire.debian.org, which is a dual G4 500MHz.
>
> Does this mean that the -value appended is for looking at the content of
> l2cr, or something such ?

No. The L2 is assumed to be set by the firmware. That "l2cr-value" is just
an optional thing that BootX can set before booting the kernel to force
a different L2 setup, typically used with G3 upgrade cards.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Thu, Jan 15, 2004 at 12:49:47PM +1100, Benjamin Herrenschmidt wrote:
>
> > But, the pmac OF (at least on the powerbook i got someone to check for
> > me), does have a l2cr property, not a l2cr-value one. The same goes on
> > for voltaire.debian.org, which is a dual G4 500MHz.
> >
> > Does this mean that the -value appended is for looking at the content of
> > l2cr, or something such ?
>
> No. The L2 is assumed to be set by the firmware. That "l2cr-value" is just
> an optional thing that BootX can set before booting the kernel to force
> a different L2 setup, typically used with G3 upgrade cards.

Ok.

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.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

>
> 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.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

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) {
        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 */
        machine = get_property(root, "model", NULL);
        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);
                        if (!(l2cr & 0x80000000)) {
                                _set_L2CR(0);
                                _set_L2CR(l2cr | 0x80000000);
                        }
                }
        }
}

Called from just after chrp_find_bridges in chrp_setup_arch.

This has been mirrored from the code in pmac_setup_artch, in pmac_setup.c :

        /* Checks "l2cr-value" property in the registry */
        if (cur_cpu_spec[0]->cpu_features & CPU_FTR_L2CR) {
                struct device_node *np = find_devices("cpus");
                if (np == 0)
                        np = find_type_devices("cpu");
                if (np != 0) {
                        unsigned int *l2cr = (unsigned int *)
                                get_property(np, "l2cr-value", NULL);
                        if (l2cr != 0) {
                                ppc_override_l2cr = 1;
                                ppc_override_l2cr_value = *l2cr;
                                _set_L2CR(0);
                                _set_L2CR(ppc_override_l2cr_value);
                        }
                }
        }

Launching a kernel with this small changes only results with him dying
silently, without syncing back to the fbdev console and providing
output, nor showing anything on the serial console, but this is to be
expected given the place where it happens.

A, yes, you wanted the device-tree bit also, i have (from linux) :

$ ls /proc/device-tree/cpus/PowerPC,74x7
altivec             d-cache-sets  external-control    i-tlb-sets	name                      tlb-size
available           d-cache-size  general-purpose     i-tlb-size	performance-monitor       tlb-split
bus-frequency       d-tlb-sets    graphics            l2-cache  	reg translations
clock-frequency     d-tlb-size    i-cache-block-size  l2cr		reservation-granule-size
cpu-version         data-streams  i-cache-line-size   l3-cache		state
d-cache-block-size  device_type   i-cache-sets        l3cr		timebase-frequency
d-cache-line-size   existing      i-cache-size        linux,phandle	tlb-sets

And :

$ ls -l /proc/device-tree/cpus/PowerPC,74x7/l2cr
-r--r--r--    1 root     root            4 Jan 18 13:06 /proc/device-tree/cpus/PowerPC,74x7/l2cr

And finally :

$ hexdump /proc/device-tree/cpus/PowerPC,74x7/l2cr
0000000 0000 0000
0000004

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

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.

> > $ 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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Sun, Jan 18, 2004 at 03:32:25PM +0100, 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, the following version :

void pegasos_set_l2cr(void)
{
        struct device_node *root = find_path_device("/");
        char *machine;
        struct device_node *np;
        int l2cr_value;

        /* On Pegasos, enable the l2 cache if needed, as the OF forgets * it */
        if (root == NULL) return;
        machine = get_property(root, "model", NULL);
        if (machine == NULL) return;
        if (strncmp(machine, "Pegasos", 7) == 0) {
                /* Enable L2 cache if needed */
                np = find_devices ("cpus");
                if (np == NULL)
                        np = find_type_devices("cpu");
                if (np != NULL) {
                        unsigned int *l2cr = (unsigned int *)
                                get_property (np, "l2cr", NULL);
                        if (l2cr == NULL) return;
                        l2cr_value = *l2cr;
                        if (!(l2cr_value & 0x80000000)) {
                                _set_L2CR(0);
                                _set_L2CR(l2cr_value | 0x80000000);
                        }
                }
        }
}

Does not die, but also does not seem to enable the l2cr thingy, but
then, i don't know how fiable the info from /proc/sys/kernel/l2cr is :

0x00000000:  L2 disabled, no parity, no instn only, no data only,
default replacement

Friendly,

Sven Luther


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Sun, Jan 18, 2004 at 03:51:58PM +0100, Sven Luther wrote:
> void pegasos_set_l2cr(void)
> {
>         struct device_node *root = find_path_device("/");
>         char *machine;
>         struct device_node *np;
>         int l2cr_value;
>
>         /* On Pegasos, enable the l2 cache if needed, as the OF forgets * it */
>         if (root == NULL) return;
>         machine = get_property(root, "model", NULL);
>         if (machine == NULL) return;
>         if (strncmp(machine, "Pegasos", 7) == 0) {
>                 /* Enable L2 cache if needed */
>                 np = find_devices ("cpus");
>                 if (np == NULL)
>                         np = find_type_devices("cpu");
>                 if (np != NULL) {
>                         unsigned int *l2cr = (unsigned int *)
>                                 get_property (np, "l2cr", NULL);
>                         if (l2cr == NULL) return;
>                         l2cr_value = *l2cr;
>                         if (!(l2cr_value & 0x80000000)) {
>                                 _set_L2CR(0);
>                                 _set_L2CR(l2cr_value | 0x80000000);
>                         }
>                 }
>         }
> }

Further tests show me that it is the if (l2cr == NULL) return; tests
which aborts the test.

Any idea what is going on here. Clearly we did read the right cpus, but
it is not possible to read the "l2cr" property.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Mon, Jan 19, 2004 at 08:05:18PM +1100, Benjamin Herrenschmidt wrote:
>
> > Further tests show me that it is the if (l2cr == NULL) return; tests
> > which aborts the test.
> >
> > Any idea what is going on here. Clearly we did read the right cpus, but
> > it is not possible to read the "l2cr" property.
>
> I think you read the "cpus" parent node and not the child node of
> the CPU itself. You can always printk np->full_name to be sure.

Ok, will try. Thanks.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

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

>         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...

>         machine = get_property(root, "model", NULL);

Check if machine isn't NULL...

>         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

>                         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);
			}

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...

>                 }
>         }
> }

> And finally :
>
> $ 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

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Dan Malek]

Sven Luther wrote:

> Ok. (altough i think this is a subject of philosophical debate :)

It was debated for the Linux kernel ages ago.

Read Documentation/CodingStyle and please follow it.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

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/

Re: OF properties access ?

[Benjamin Herrenschmidt]

>
> void pegasos_set_l2cr(void)
> {
>         struct device_node *root = find_path_device("/");
>         char *machine;
>         struct device_node *np;
>         int l2cr_value;

What about "unsigned int" above and not doing int/unsigned int
conversions and such ? (Dunno if it explains your problem at
this point but it's worth fixing anyway)

>         /* On Pegasos, enable the l2 cache if needed, as the OF forgets * it */
>         if (root == NULL) return;
>         machine = get_property(root, "model", NULL);
>         if (machine == NULL) return;
>         if (strncmp(machine, "Pegasos", 7) == 0) {
>                 /* Enable L2 cache if needed */
>                 np = find_devices ("cpus");
>                 if (np == NULL)
>                         np = find_type_devices("cpu");
>                 if (np != NULL) {
>                         unsigned int *l2cr = (unsigned int *)
>                                 get_property (np, "l2cr", NULL);
>                         if (l2cr == NULL) return;
>                         l2cr_value = *l2cr;
>                         if (!(l2cr_value & 0x80000000)) {
>                                 _set_L2CR(0);
>                                 _set_L2CR(l2cr_value | 0x80000000);
>                         }
>                 }
>         }
> }
>
> Does not die, but also does not seem to enable the l2cr thingy, but
> then, i don't know how fiable the info from /proc/sys/kernel/l2cr is :
>
> 0x00000000:  L2 disabled, no parity, no instn only, no data only,
> default replacement

The value is reliable, the text explanation of the bits isn't on this
CPU.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

> Further tests show me that it is the if (l2cr == NULL) return; tests
> which aborts the test.
>
> Any idea what is going on here. Clearly we did read the right cpus, but
> it is not possible to read the "l2cr" property.

I think you read the "cpus" parent node and not the child node of
the CPU itself. You can always printk np->full_name to be sure.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Mon, Jan 19, 2004 at 08:01:33PM +1100, Benjamin Herrenschmidt wrote:
> 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 ?

Mmm, i have :

    {   /* 7457 */
        0xffff0000, 0x80020000, "7457",
        CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | CPU_FTR_CAN_NAP |
        CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR |
        CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_NAP_DISABLE_L2_PR |
        CPU_FTR_HAS_HIGH_BATS,
        COMMON_PPC | PPC_FEATURE_HAS_ALTIVEC,
        32, 32,
        __setup_cpu_745x
    },

Which should be ok, since there seem to be no way to distinguish a 7447
from a 7457 anyway (apart from maybe L2 cache probing or such).

And indeed, the problem seems to be that i get /cpus, and not
/cpus/PowerPC,74x7. I thought that the /cpus should give the cpu per
default or something such. What should i do here, i can go look for a
PowerPC,74x7, but the board can also come with other CPUs (the 750Cxe
for now). Maybe i could remove the cpus checking code completely, and go
looking for the cpu type directly.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

> And indeed, the problem seems to be that i get /cpus, and not
> /cpus/PowerPC,74x7. I thought that the /cpus should give the cpu per
> default or something such. What should i do here, i can go look for a
> PowerPC,74x7, but the board can also come with other CPUs (the 750Cxe
> for now). Maybe i could remove the cpus checking code completely, and go
> looking for the cpu type directly.

For the "cpus" case, just get to the first child

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Sven Luther]

On Mon, Jan 19, 2004 at 10:42:05PM +1100, Benjamin Herrenschmidt wrote:
>
> > And indeed, the problem seems to be that i get /cpus, and not
> > /cpus/PowerPC,74x7. I thought that the /cpus should give the cpu per
> > default or something such. What should i do here, i can go look for a
> > PowerPC,74x7, but the board can also come with other CPUs (the 750Cxe
> > for now). Maybe i could remove the cpus checking code completely, and go
> > looking for the cpu type directly.
>
> For the "cpus" case, just get to the first child

Doing only : np = find_type_devices("cpu"); worked fine. I guess this
will catch any cpus in the system, and be ok. There are not yet
multi-cpu pegasos boxes, so i think it is ok to just check the first CPU
and enable the L2 cache there, i will make sure the OF of future
multi-cpu systems will set the L2 cache properly.

Or is it better to go for the first child of cpus ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF properties access ?

[Benjamin Herrenschmidt]

> Doing only : np = find_type_devices("cpu"); worked fine. I guess this
> will catch any cpus in the system, and be ok. There are not yet
> multi-cpu pegasos boxes, so i think it is ok to just check the first CPU
> and enable the L2 cache there, i will make sure the OF of future
> multi-cpu systems will set the L2 cache properly.
>
> Or is it better to go for the first child of cpus ?

What you do should be fine.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/