LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] boot: find initrd location from device-tree
From: Milton Miller @ 2007-06-18  6:08 UTC (permalink / raw)
  To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <4672EE95.3030407@freescale.com>

[replying to David and Scott the second sub-thread]

On Jun 15, 2007, at 2:55 PM, Scott Wood wrote:
> Milton Miller wrote:
>> The file name dtscan reflects the possibility that simiar functions
>> like the rmo_top might be added to the file.
> Aren't these kind of things what devtree.c is for?

Hmm... i guess .. I didn't need the fixups in that file, but I guess 
the xlate routines couuld be useful for find top of memory.

That file is for "not specific to device tree library (firmware 
callback vs flat tree)" utilities?

On Mon Jun 18 13:18:22 EST 2007, David Gibson wrote:
> On Fri, Jun 15, 2007 at 12:34:30PM -0500, Milton Miller wrote:
> >
> > The types.h header now includes libgcc limits.h for UINT_MAX.
> >


> > ---
> > The file name dtscan reflects the possibility that simiar functions
> > like the rmo_top might be added to the file.
>
> Hrm, not sure if it's worth creating a new file for this, it could
> probably go in devtree.c.

Ok, two votes.  I'll move it next post.

> > +void dt_find_initrd(void)
> > +{
> > +     int rc;
> > +     unsigned long long initrd_start, initrd_end;
> > +     void *devp;
> > +     static const char start_prop[] = "linux,initrd-start";
> > +     static const char end_prop[] = "linux,initrd-end";
>
> I see no point to using these constants, just use literals in the
> getprop() calls.

When I had them inline, the get-property and the printf calls exceeded 
80 characters, making lots of multi-line function calls.  And 
seperating them out out made the error printfs the same, so they could 
be collapsed by gcc.  Either isn't a real strong argument, so if you 
insist I will write it out, but I thought it was nicer this way.

>
> > +     devp = finddevice("/chosen");
> > +     if (! devp) {
> > +             return;
> > +     }
> > +
> > +     /* The properties had to be 8 bytes until 2.6.22  */
> > +     rc = getprop(devp, start_prop, &initrd_start, 
> sizeof(initrd_start));
> > +     if (rc < 0)
> > +             return;
> > +     if (rc == sizeof(unsigned long)) {
> > +             unsigned long tmp;
> > +             memcpy(&tmp, &initrd_start, rc);
> > +             initrd_start = tmp;
> > +     } else if (rc != sizeof(initrd_start)) {
> > +             printf("unexpected length of %s in /chosen!\n\r", 
> start_prop);
> > +             return;
> > +     }
> > +
> > +     rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
> > +     if (rc < 0) {
> > +             printf("chosen has %s but no %s!\n\r", start_prop, 
> end_prop);
> > +             return;
> > +     }
> > +     if (rc == sizeof(unsigned long)) {
> > +             unsigned long tmp;
> > +             memcpy(&tmp, &initrd_end, rc);
> > +             initrd_end = tmp;
> > +     } else if (rc != sizeof(initrd_end)) {
> > +             printf("unexpected length of %s in /chosen!\n\r", 
> end_prop);
> > +             return;
> > +     }
> > +
> > +     if (!initrd_start)
> > +             return;
> > +
> > +     /* if the initrd is above 4G, its untouchable in 32 bit mode */
> > +     if (initrd_end <= UINT_MAX && initrd_start < initrd_end) {
> > +             loader_info.initrd_addr = initrd_start;
> > +             loader_info.initrd_size  = initrd_end - initrd_start;
> > +     } else {
> > +             printf("ignoring loader supplied initrd parameters\n");
>
> Saying why might be helpful.

Hmm... well, that would mean seperating the && of the if; there are two 
possible reasons. (1) this 32-bit code can't handle such large 
addresses (in which case a 64-bit kernel may work), and (2) end is >= 
start (which means there really isn't any data.  I suppose I could 
reverse the sense of the if, use an else if, and make the final else 
the good path.



>
> > +     }
> > +}
...
> > Index: kernel/arch/powerpc/boot/types.h
> > ===================================================================
> > --- kernel.orig/arch/powerpc/boot/types.h     2007-06-15 
> 03:36:21.000000000 -0500
> > +++ kernel/arch/powerpc/boot/types.h  2007-06-15 03:44:34.000000000 
> -0500
> > @@ -1,6 +1,9 @@
> >  #ifndef _TYPES_H_
> >  #define _TYPES_H_
> >
> > +#define _LIBC_LIMITS_H_              /* don't recurse to system's 
> headers */
> > +#include <limits.h>          /* MAX_UINT, etc */
> > +
>
> I think it's really a bad idea to use any headers from outside the
> boot context here.  We're dealing with explicit sized ints, so we can
> safely define our own constants giving the limit values.

As I said in the patch changelog, the only headers picked up here are 
libgcc.  The compiler is part of the boot context, and we already pick 
up stdarg from there.   The flag there appears to be what libgcc 
expects the library to use.

I could change the comment to say /* get libgcc header only */ or 
something else you suggest.

milton

^ permalink raw reply

* Re: [PATCH] Wire up sys_sync_file_range() on powerpc
From: Paul Mackerras @ 2007-06-18  5:37 UTC (permalink / raw)
  To: David Woodhouse; +Cc: akpm, linuxppc-dev, torvalds, rmk, linux-arch
In-Reply-To: <1182018044.2808.75.camel@pmac.infradead.org>

David Woodhouse writes:

> Pants.

Ah.  Is that a naughty word in the UK?  If so I'll have to remember
that when I go to kernel summit. :)

> It doesn't work because the 'flags' argument ends up in r9, and
> we can only use r3-r8 for syscall arguments. We'll need to do it the
> same way as ARM does, with the flags as the second argument.

Yes.  We'll need a wrapper for both 32-bit and for 32-on-64.

> Or is it? Can we ditch sys_sync_file_range now and implement a new
> sys_sync_file_range2 with the two 32-bit arguments first?

Would be nice...

Paul.

^ permalink raw reply

* Re: for-2.6.23 branch in powerpc.git created
From: Mohan Kumar M @ 2007-06-18  5:07 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>

On Fri, Jun 15, 2007 at 02:50:11PM +1000, Paul Mackerras wrote:
> The patches I put in are listed below.  If you have a patch that
> should go in but isn't listed, remind me about it.
>
Hi Paul,

Can you take this?

http://patchwork.ozlabs.org/linuxppc/patch?id=11676

Regards,
Mohan.

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-18  4:32 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list, Arnd Bergmann, Stephen Rothwell
In-Reply-To: <200706180109.11482.arnd@arndb.de>


On Jun 17, 2007, at 6:09 PM, Arnd Bergmann wrote:

> On Sunday 17 June 2007, Kumar Gala wrote:
>> I commented on some minor nits with the patches.  I'm probably ok
>> with patches 1-7 going in.  I'm not ready for 8 at this point, we
>> need to do more proper cleanup to get 85xx/cpm2 support into a
>> multiplatforms single kernel state.
>
> Ok, makes sense. I've fixed up the other patches according to
> your comments (did not change 8xx stuff though) and pushed
> it out to
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6 powerpc- 
> kconfig
>
> Paul, please pull from there, I'll remember not to try messing with
> 32 bit in the future but wanted to get this in after spending so
> much work on it.

Paul,

I'll pull these into my tree with a bunch of other ppc32/embedded  
related patches for you to pull all at once since I've got other  
changes that will depend on them.

- k

^ permalink raw reply

* RE: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-18  3:27 UTC (permalink / raw)
  To: Segher Boessenkool, Kumar Gala; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <2e7b08497aae9219233aed72628e46c6@kernel.crashing.org>

Hi, Kumar and Segher,=20

>
> > "..8641.." "..8641d.." "..8548.." "..8548e.." "..8543.."=20
> "..8543e.."=20
> > "..8572.." "..8572e.." "..8567.." "..8567e.." "..8568.." "..8568e.."
>=20
> You don't need to mention _all_ compatible devices in
> the "compatible" property, only the few that matter;
> typically the oldest one, and sometimes some intermediate
> device that has extra features over the original one.
>=20

The oldest one is difficult to find out sometime. Can we only set the
self name in dts, such as "fsl, rapidio-8641", and add this 'compatible'
property to the driver ids arrays? Such as:

static struct of_device_id of_rio_rpn_ids[] =3D {
	{ .compatible =3D "fsl, rapidio-8540",},
	{ .compatible =3D "fsl, rapidio-8560",},
	{ .compatible =3D "fsl, rapidio-8641",},
	{ .compatible =3D "fsl, rapidio-8548",},
	{},
};

How about that?

> It isn't useful to add "compatible" entries that no OS
> probes for.
>=20
> >> Concrete names are good.
> >
> > While I agree concrete names are good, we put these 'blocks' in so=20
> > many devices that using the device to match on is pointless.
>=20
> You *definitely* should put the device name for _this_
> device in there, in case it needs some special workaround.
>=20
> > I'm all for making up a name like 'Grande', 'Del',=20
> 'Janeiro'.  This is=20
> > effective what we did with gianfar.  The name gets picked up pretty=20
> > quickly by people.
>=20
> That can be used as the "base" name, yes.
>=20

Do you have the name list? I can change my codes according them.

How about 'Mercurary', 'Venus', 'Earth', 'Mars', 'Saturn', 'Jupiter',
'Uranus', 'Neptune',
Or 'Aries', 'Taurus', 'Gemini', 'Cancer', 'Leo', 'Virgo', 'Libra',
'Scorpius', 'Sagittarius', 'Capricornus', 'Aquarius', 'Pisces' ?

Thanks!
Wei.

^ permalink raw reply

* Re: [PATCH] boot: find initrd location from device-tree
From: David Gibson @ 2007-06-18  3:18 UTC (permalink / raw)
  To: Milton Miller; +Cc: linuxppc-dev, paulus
In-Reply-To: <11181928870643c98691.1714636915.tkfpda@attglobal.net>

On Fri, Jun 15, 2007 at 12:34:30PM -0500, Milton Miller wrote:
> Some platforms have a boot agent that can create or modifiy
> properties in the device-tree and load images into memory.
> Provide a helper to set the loader-info used by prep_initrd().
> 
> The code supports the 8-byte properties required by kernels
> before 2.6.22 and 4-byte properties generated by prep_initrd()
> and current 32 bit kernels (new kernels will read either size).
> 
> The types.h header now includes libgcc limits.h for UINT_MAX.
> 
> Signed-off-by: Milton Miller <miltonm@bga.com>
> --- 
> The file name dtscan reflects the possibility that simiar functions
> like the rmo_top might be added to the file.

Hrm, not sure if it's worth creating a new file for this, it could
probably go in devtree.c.  

> This is the first patch in a series of 18 that udpates and rediffs
> of my kexec zImage support against 2.6.22-rc4.  Unfornately I left
> the series file behind but I wanted to get this first patch sent
> for Matt to use.
> 
> Index: kernel/arch/powerpc/boot/dtscan.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ kernel/arch/powerpc/boot/dtscan.c	2007-06-15 03:45:16.000000000 -0500
> @@ -0,0 +1,86 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
> + *
> + * Copyright (C) 2007 IBM Corporation.
> + *
> + * Authors: Milton Miller <miltonm@bga.com>
> + *
> + */
> +
> +#include "ops.h"
> +#include "stdio.h"
> +
> +/**
> + * dt_find_initrd - set loader initrd location based on existing properties
> + *
> + * finds the linux,initrd-start and linux,initrd-end properties in
> + * the /chosen node and sets the loader initrd fields accordingly.
> + *
> + * Use this if your loader sets the properties to allow other code to
> + * relocate the tree and/or cause r3 and r4 to be set on true OF
> + * platforms.
> + */
> +
> +void dt_find_initrd(void)
> +{
> +	int rc;
> +	unsigned long long initrd_start, initrd_end;
> +	void *devp;
> +	static const char start_prop[] = "linux,initrd-start";
> +	static const char end_prop[] = "linux,initrd-end";

I see no point to using these constants, just use literals in the
getprop() calls.

> +	devp = finddevice("/chosen");
> +	if (! devp) {
> +		return;
> +	}
> +
> +	/* The properties had to be 8 bytes until 2.6.22  */
> +	rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
> +	if (rc < 0)
> +		return;
> +	if (rc == sizeof(unsigned long)) {
> +		unsigned long tmp;
> +		memcpy(&tmp, &initrd_start, rc);
> +		initrd_start = tmp;
> +	} else if (rc != sizeof(initrd_start)) {
> +		printf("unexpected length of %s in /chosen!\n\r", start_prop);
> +		return;
> +	}
> +
> +	rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
> +	if (rc < 0) {
> +		printf("chosen has %s but no %s!\n\r", start_prop, end_prop);
> +		return;
> +	}
> +	if (rc == sizeof(unsigned long)) {
> +		unsigned long tmp;
> +		memcpy(&tmp, &initrd_end, rc);
> +		initrd_end = tmp;
> +	} else if (rc != sizeof(initrd_end)) {
> +		printf("unexpected length of %s in /chosen!\n\r", end_prop);
> +		return;
> +	}
> +
> +	if (!initrd_start)
> +		return;
> +
> +	/* if the initrd is above 4G, its untouchable in 32 bit mode */
> +	if (initrd_end <= UINT_MAX && initrd_start < initrd_end) {
> +		loader_info.initrd_addr = initrd_start;
> +		loader_info.initrd_size  = initrd_end - initrd_start;
> +	} else {
> +		printf("ignoring loader supplied initrd parameters\n");

Saying why might be helpful.

> +	}
> +}
> Index: kernel/arch/powerpc/boot/ops.h
> ===================================================================
> --- kernel.orig/arch/powerpc/boot/ops.h	2007-06-15 03:43:36.000000000 -0500
> +++ kernel/arch/powerpc/boot/ops.h	2007-06-15 03:44:34.000000000 -0500
> @@ -151,6 +151,7 @@ static inline void *find_node_by_devtype
>  	return find_node_by_prop_value_str(prev, "device_type", type);
>  }
>  
> +void dt_find_initrd(void);
>  void dt_fixup_memory(u64 start, u64 size);
>  void dt_fixup_cpu_clocks(u32 cpufreq, u32 tbfreq, u32 busfreq);
>  void dt_fixup_clock(const char *path, u32 freq);
> Index: kernel/arch/powerpc/boot/Makefile
> ===================================================================
> --- kernel.orig/arch/powerpc/boot/Makefile	2007-06-15 03:43:36.000000000 -0500
> +++ kernel/arch/powerpc/boot/Makefile	2007-06-15 03:44:34.000000000 -0500
> @@ -43,7 +43,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
>  
>  src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
>  		ns16550.c serial.c simple_alloc.c div64.S util.S \
> -		gunzip_util.c elf_util.c $(zlib) devtree.c \
> +		gunzip_util.c elf_util.c $(zlib) devtree.c dtscan.c \
>  		44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c
>  src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
>  		cuboot-ebony.c treeboot-ebony.c prpmc2800.c
> Index: kernel/arch/powerpc/boot/types.h
> ===================================================================
> --- kernel.orig/arch/powerpc/boot/types.h	2007-06-15 03:36:21.000000000 -0500
> +++ kernel/arch/powerpc/boot/types.h	2007-06-15 03:44:34.000000000 -0500
> @@ -1,6 +1,9 @@
>  #ifndef _TYPES_H_
>  #define _TYPES_H_
>  
> +#define _LIBC_LIMITS_H_		/* don't recurse to system's headers */
> +#include <limits.h>		/* MAX_UINT, etc */
> +

I think it's really a bad idea to use any headers from outside the
boot context here.  We're dealing with explicit sized ints, so we can
safely define our own constants giving the limit values.

>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>  
>  typedef unsigned char		u8;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Arnd Bergmann @ 2007-06-17 23:09 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <4E0AC3E6-98F8-40BD-BA85-60766E097E4A@kernel.crashing.org>

On Sunday 17 June 2007, Kumar Gala wrote:
> I commented on some minor nits with the patches. =A0I'm probably ok =A0
> with patches 1-7 going in. =A0I'm not ready for 8 at this point, we =A0
> need to do more proper cleanup to get 85xx/cpm2 support into a =A0
> multiplatforms single kernel state.

Ok, makes sense. I've fixed up the other patches according to
your comments (did not change 8xx stuff though) and pushed
it out to
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6 powerpc-kconfig

Paul, please pull from there, I'll remember not to try messing with
32 bit in the future but wanted to get this in after spending so
much work on it.

	Arnd <><

^ permalink raw reply

* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Segher Boessenkool @ 2007-06-17 17:46 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200706171920.10898.arnd@arndb.de>

>> Is there a reason we don't distinguish between 7400/7410 and 74{4,5}
>> x?  Is it because we dont have any discrete systems with just a 7400
>> on it?
>
> No, I just didn't know that there was a difference. I had looked at the
> gcc source and found that gcc produces the same instruction for both,
> but I didn't bother to look at the optimizations. From all I can
> tell, -mcpu=7400 is identical to -mcpu=7450 -mtune=750.

7400 is pretty much like a 750 + AltiVec and a few deeper
queues.  The "FP full" stall is also gone IIRC, or maybe
that was not before the 7450.  Nothing that GCC knows how
to model, anyway.

>> Also I'd suggest we have the config options be a 1:1 matching for the
>> -mcpu/-mtune options in gcc for the following cases:
>>
>>> +	default "-mcpu=750" if CPU_7xx
>>> +	default "-mcpu=7450" if CPU_74xx
>>> +	default "-mcpu=860" if PPC_8xx
>>> +	default "-mcpu=8540" if PPC_85xx
>>
>> So if in the future we have code scheduling for 8599 or some other
>> variant we don't have to go change the Kconfig just add to it.
>
> I'm not sure I understand what you would like to see this, would you
> like them to be simply renamed to CPU_750/CPU_7450/CPU_860/CPU_8540
> or rather add more options for 740/801/821/823/8548, which are
> treated as aliases of the others?

GCC treats many of those as aliases, too.


Segher

^ permalink raw reply

* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Arnd Bergmann @ 2007-06-17 17:20 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <91EBCC0C-48B7-4748-A936-E74CEB7685E0@kernel.crashing.org>

On Sunday 17 June 2007, you wrote:
> 
> On Jun 15, 2007, at 7:05 PM, arnd@arndb.de wrote:
> 
> > We can choose the -mcpu= gcc flags for compiling the kernel
> > based on the platform that we build for. In case of multiplatform
> > kernels, this chooses a setting for a common subset.
> >
> > When using a platform type that can use different CPUs, a
> > new option CONFIG_PPC_CPU_SELECTION can be enabled to select
> > more specifically which CPUs the kernel will be able to
> > run on.
> >
> > This replaces the CONFIG_POWER4_ONLY option with an much more
> > generic approach.
> >
> > Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible
> > to select a CPU to tune for by means of the -mtune= option.
> >
> > I tried to be very careful when coding the specific rules into
> > the Kconfig language, but it would be good to have a few
> > people sanity-checking them.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Is there a reason we don't distinguish between 7400/7410 and 74{4,5} 
> x?  Is it because we dont have any discrete systems with just a 7400  
> on it?

No, I just didn't know that there was a difference. I had looked at the
gcc source and found that gcc produces the same instruction for both,
but I didn't bother to look at the optimizations. From all I can
tell, -mcpu=7400 is identical to -mcpu=7450 -mtune=750.

Can you look through the patch again to see which of the platforms
that have a 7400 instead of 7450 type CPUs?

> Also I'd suggest we have the config options be a 1:1 matching for the  
> -mcpu/-mtune options in gcc for the following cases:
> 
> > +	default "-mcpu=750" if CPU_7xx
> > +	default "-mcpu=7450" if CPU_74xx
> > +	default "-mcpu=860" if PPC_8xx
> > +	default "-mcpu=8540" if PPC_85xx
> 
> So if in the future we have code scheduling for 8599 or some other  
> variant we don't have to go change the Kconfig just add to it.

I'm not sure I understand what you would like to see this, would you
like them to be simply renamed to CPU_750/CPU_7450/CPU_860/CPU_8540
or rather add more options for 740/801/821/823/8548, which are
treated as aliases of the others?

For 74xx, I guess you already convinced me and for 85xx, I'll trust
your word if you think that we will need future flags in the future.

I'm not so sure about 7xx and 8xx though. I could not find any
code in gcc that knows about the difference between the CPUs in
either family, and it doesn't seem like anyone is working on
changing that. Anything I missed there?

	Arnd <><

^ permalink raw reply

* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Segher Boessenkool @ 2007-06-17 16:11 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <91EBCC0C-48B7-4748-A936-E74CEB7685E0@kernel.crashing.org>

> Is there a reason we don't distinguish between 7400/7410 and 74{4,5}
> x?  Is it because we dont have any discrete systems with just a 7400
> on it?

It's quite important for 74[01]0 systems to not run
code tuned for 7450.  Older Macs have such CPUs, the
user should have the option to tune for it.

> Also I'd suggest we have the config options be a 1:1 matching for the
> -mcpu/-mtune options in gcc for the following cases:
>
>> +	default "-mcpu=750" if CPU_7xx
>> +	default "-mcpu=7450" if CPU_74xx
>> +	default "-mcpu=860" if PPC_8xx
>> +	default "-mcpu=8540" if PPC_85xx

It would be good to do that for all cases, unfortunately
GCC doesn't recognise all CPU/core names as -mcpu options.


Segher

^ permalink raw reply

* Re: [patch 5/9] kill isa_{io,mem}_base definitions for !PCI
From: Arnd Bergmann @ 2007-06-17 15:32 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <43F789E2-BBB2-4382-9DA2-619357E9E006@kernel.crashing.org>

On Sunday 17 June 2007, Kumar Gala wrote:
> > -#ifndef CONFIG_PCI
> > -isa_io_base =3D MPC7448_HPC2_ISA_IO_BASE;
> > -isa_mem_base =3D MPC7448_HPC2_ISA_MEM_BASE;
> > -pci_dram_offset =3D MPC7448_HPC2_PCI_MEM_OFFSET;
> > -#endif
> > -
> > =A0extern void _nmask_and_or_msr(unsigned long nmask, unsigned long =A0
> > or_val);
>=20
> can you remove the defines in mpc7448_hpc2.h since they are appear to =A0
> only be used here.

Ok, good idea.

^ permalink raw reply

* Re: [patch 7/9] disallow building powermac and tsi108 without PCI
From: Arnd Bergmann @ 2007-06-17 15:32 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <A9EC5456-63EF-4563-A175-ECFDE1B58912@kernel.crashing.org>

On Sunday 17 June 2007, Kumar Gala wrote:
> > @@ -31,6 +32,7 @@ config PPC_HOLLY
> > =A0=A0=A0=A0=A0=A0select TSI108_BRIDGE
> > =A0=A0=A0=A0=A0=A0select PPC_UDBG_16550
> > =A0=A0=A0=A0=A0=A0select CPU_7xx
> > +=A0=A0=A0=A0=A0select PCI
> > =A0=A0=A0=A0=A0=A0help
> > =A0=A0=A0=A0=A0=A0 =A0Select PPC_HOLLY if configuring for an IBM 750GX/=
CL Eval
> > =A0=A0=A0=A0=A0=A0 =A0Board with TSI108/9 bridge (Hickory/Holly)
>=20
> Any reason we just don't add the select to the config TSI108_BRIDGE =A0
> so any future TSI108 based systems get it as well?
>=20

Sounds good, I'll update the patch.

I also noticed that part of the TSI108 code appears to be written
so support !PCI configurations, so in theory it should be possible
fix up the problems with that. The reason I didn't was that it
ended up as quite a big number of changes that I couldn't properly
test.
The other question is of course whether it's useful to allow it.

	Arnd <><

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-17 14:46 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <200706170214.11247.arnd@arndb.de>


On Jun 16, 2007, at 7:14 PM, Arnd Bergmann wrote:

> On Sunday 17 June 2007, Kumar Gala wrote:
>>> For the 'at least one option selected' argument, I'm not sure how
>>> important that is, IMHO it falls into the same category as any
>>> other essential option that you can disable.
>>
>> People have run into the issue so I think it desires at least a
>> little concern.  See: http://marc.info/?t=117529164800005&r=1&w=2
>
> But isn't the reported problem just a bug in the build system?
> My impression was that the user did not complain about the fact
> that the kernel he was trying to build would not boot on any
> platform, but rather that the kernel tried to build a zImage
> that was not defined, resulting in a build error.
>
> Obviously, any configuration that can be selected by the user
> should be able to compile and link without errors, even if it's
> not particularly useful.
>
> Aside from the multiplatform enabling patches, are you happy with
> the patches 1-8 from my fourth version of the patch set?

I commented on some minor nits with the patches.  I'm probably ok  
with patches 1-7 going in.  I'm not ready for 8 at this point, we  
need to do more proper cleanup to get 85xx/cpm2 support into a  
multiplatforms single kernel state.

- k

^ permalink raw reply

* Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
From: Kumar Gala @ 2007-06-17 14:42 UTC (permalink / raw)
  To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070616000618.183462070@arndb.de>


On Jun 15, 2007, at 7:05 PM, arnd@arndb.de wrote:

> The cores used in the MPC82xx/83xx/86xx embedded controllers are  
> very similar
> to those in the 32 bit general-purpose processors, so it makes  
> sense to
> treat them as the same CPU family.
>
> Choosing between the embedded platforms and the multiplatform code is
> now done in the platform menu, but functionally everything stays the
> same.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Index: linux-2.6/arch/powerpc/platforms/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/Kconfig
> +++ linux-2.6/arch/powerpc/platforms/Kconfig
> @@ -2,7 +2,7 @@ menu "Platform support"
>
>  choice
>  	prompt "Machine type"
> -	depends on PPC64 || CLASSIC32
> +	depends on PPC64 || 6xx
>  	default PPC_MULTIPLATFORM
>
>  config PPC_MULTIPLATFORM
> @@ -16,8 +16,31 @@ config EMBEDDED6xx
>  	bool "Embedded 6xx/7xx/7xxx-based board"
>  	depends on PPC32 && (BROKEN||BROKEN_ON_SMP)
>
> +config PPC_82xx
> +	bool "Freescale 82xx"
> +	depends on 6xx
> +
> +config PPC_83xx
> +	bool "Freescale 83xx"
> +	depends on 6xx
> +	select FSL_SOC
> +	select 83xx
> +	select WANT_DEVICE_TREE
> +
> +config PPC_86xx
> +	bool "Freescale 86xx"
> +	depends on 6xx
> +	select FSL_SOC
> +	select FSL_PCIE
> +	select ALTIVEC
> +	help
> +	  The Freescale E600 SoCs have 74xx cores.
>  endchoice

is it feasible to have 83xx/86xx go 'multiplatform' but not 82xx?   
There are more annoyances about CPM2 support that are not clean such  
that you couldn't build support for different 82xx systems into the  
same kernel.  Today we only support one 82xx system in ARCH=powerpc,  
but I'd rather we not move it until we clean up those issues.  (the  
same is true of 85xx).

- k

^ permalink raw reply

* Re: [patch 7/9] disallow building powermac and tsi108 without PCI
From: Kumar Gala @ 2007-06-17 14:35 UTC (permalink / raw)
  To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070616000618.965439750@arndb.de>


On Jun 15, 2007, at 7:05 PM, arnd@arndb.de wrote:

> The TSI108 code and the 32 bit powermac and chrp platforms
> have dependency on PCI that is not easy or desirable to get rid
> of.
>
> The easiest fix is to always select CONFIG_PCI if one of those
> platforms is enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -18,6 +18,7 @@ config LINKSTATION
>
>  config MPC7448HPC2
>  	bool "Freescale MPC7448HPC2(Taiga)"
> +	select PCI
>  	select TSI108_BRIDGE
>  	select DEFAULT_UIMAGE
>  	select PPC_UDBG_16550
> @@ -31,6 +32,7 @@ config PPC_HOLLY
>  	select TSI108_BRIDGE
>  	select PPC_UDBG_16550
>  	select CPU_7xx
> +	select PCI
>  	help
>  	  Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval
>  	  Board with TSI108/9 bridge (Hickory/Holly)

Any reason we just don't add the select to the config TSI108_BRIDGE  
so any future TSI108 based systems get it as well?

- k

^ permalink raw reply

* Re: [patch 5/9] kill isa_{io,mem}_base definitions for !PCI
From: Kumar Gala @ 2007-06-17 14:33 UTC (permalink / raw)
  To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070616000618.706193913@arndb.de>


On Jun 15, 2007, at 7:05 PM, arnd@arndb.de wrote:

> When CONFIG_PCI is disabled, the definitions for isa_io_base,
> isa_mem_base and pci_dram_offset are entirely unused, but they
> can result in link failure because they are defined in multiple
> places.
>
> The easiest fix is to just remove all these definitions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

[snip]


> Index: linux-2.6/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
> +++ linux-2.6/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
> @@ -54,12 +54,6 @@
>
>  #define MPC7448HPC2_PCI_CFG_PHYS 0xfb000000
>
> -#ifndef CONFIG_PCI
> -isa_io_base = MPC7448_HPC2_ISA_IO_BASE;
> -isa_mem_base = MPC7448_HPC2_ISA_MEM_BASE;
> -pci_dram_offset = MPC7448_HPC2_PCI_MEM_OFFSET;
> -#endif
> -
>  extern void _nmask_and_or_msr(unsigned long nmask, unsigned long  
> or_val);

can you remove the defines in mpc7448_hpc2.h since they are appear to  
only be used here.

[snip]

- k

^ permalink raw reply

* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Kumar Gala @ 2007-06-17 14:29 UTC (permalink / raw)
  To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070616000618.314570319@arndb.de>


On Jun 15, 2007, at 7:05 PM, arnd@arndb.de wrote:

> We can choose the -mcpu= gcc flags for compiling the kernel
> based on the platform that we build for. In case of multiplatform
> kernels, this chooses a setting for a common subset.
>
> When using a platform type that can use different CPUs, a
> new option CONFIG_PPC_CPU_SELECTION can be enabled to select
> more specifically which CPUs the kernel will be able to
> run on.
>
> This replaces the CONFIG_POWER4_ONLY option with an much more
> generic approach.
>
> Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible
> to select a CPU to tune for by means of the -mtune= option.
>
> I tried to be very careful when coding the specific rules into
> the Kconfig language, but it would be good to have a few
> people sanity-checking them.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Is there a reason we don't distinguish between 7400/7410 and 74{4,5} 
x?  Is it because we dont have any discrete systems with just a 7400  
on it?

Also I'd suggest we have the config options be a 1:1 matching for the  
-mcpu/-mtune options in gcc for the following cases:

> +	default "-mcpu=750" if CPU_7xx
> +	default "-mcpu=7450" if CPU_74xx
> +	default "-mcpu=860" if PPC_8xx
> +	default "-mcpu=8540" if PPC_85xx

So if in the future we have code scheduling for 8599 or some other  
variant we don't have to go change the Kconfig just add to it.

- k

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Segher Boessenkool @ 2007-06-17  0:22 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <200706170214.11247.arnd@arndb.de>

>> People have run into the issue so I think it desires at least a =A0
>> little concern. =A0See: http://marc.info/?t=3D117529164800005&r=3D1&w=3D=
2
>
> But isn't the reported problem just a bug in the build system?

Yes, that's a completely separate bug.

> My impression was that the user did not complain about the fact
> that the kernel he was trying to build would not boot on any
> platform, but rather that the kernel tried to build a zImage
> that was not defined, resulting in a build error.

It's the only valid complaint, anyway :-)

> Obviously, any configuration that can be selected by the user
> should be able to compile and link without errors, even if it's
> not particularly useful.

Yes.


Segher

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Segher Boessenkool @ 2007-06-17  0:19 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Stephen Rothwell, arnd, linuxppc-dev, Paul Mackerras,
	Sam Ravnborg
In-Reply-To: <AB18F3F9-C844-4ECE-8EE3-7B05DDD5669E@kernel.crashing.org>

>> I would much
>> prefer the CONFIG_xxx_ONLY_ONE be -generated- by the multiple choice
>> menu if only one choice has been selected.
>>
>> That could be an optional argument to the menu stuff to set that.
>
> That was my intent, that the Kconfig system would help in telling us
> only one choice was selected and we could optimize based on that.  In
> addition, to ensure that at least one choice was selected.  I believe
> Rob Landley came across an issue that exists today with MULTIPLATFORM
> support in that we can attempt to build a kernel w/o any system.

Each of the CPU options is set to either "y" or "", so:


options-$(option1)$(option2)$(option3) := y

ifeq ($(options)-,y)
	$(error blablabla)
endif

CONFIG_POWERPC_ONLY_ONE_CPU := $(options-y)


or some variant on this will do just fine.


Segher

^ permalink raw reply

* Re: Regarding MPC8540 IRQ Issue
From: Bhupender Saharan @ 2007-06-17  0:16 UTC (permalink / raw)
  To: sudheer; +Cc: linuxppc-embedded
In-Reply-To: <4673AD08.1080800@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

Hi Sudhir,

>From the PCI dump it looks like IRQ PIN register is 0. During enumeration
when BIOS sees that IRQ PIN register is 0, it would not allocate any
interrupt for this card and that's why you are seeing IRQ Line register also
as 0 value.

We need to do some work around for this.

 IN the driver you need to register for all the pci vectors( INTA,B,C and
D). You would be called for any interrupt happening on the bus. you have to
check if the interrupt is for you and then claim it otherwise return that
interrupt is not for you.


Regards
Bhupi


On 6/16/07, sudheer <urwithsudheer@gmail.com> wrote:
>
> Hello All
>
> I am working on MPC8540 board placing it in the PCI slot of the x86
> system.
> After system bootup , i could see the powerpc board detected and pci
> config space configured.
> But i could not find any IRQ assigned for it.
>
> SetUp:
> Host: x86 System- Linux-2.6.9
> HOST PCI Slot is 64-bit, 66MHz
> Agent: MPC8540 Board.
>
> Here is dump of "lspci -vx " for this device.
>
> 04:03.0 Power PC: Motorola MPC8540 (rev 20) (prog-if 01)
>         Flags: bus master, 66Mhz, fast devsel, latency 64
>         Memory at dee00000 (32-bit, non-prefetchable) [size=1M]
>         Capabilities: [60] #00 [0000]
> 00: 57 10 08 00 46 01 b0 00 20 01 20 0b 00 40 00 00
> 10: 00 00 e0 de 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00
>
> From the above dump - IRQ Pin & Line of config space shows zeroes.
>
> I tried writing a small module and probing for IRQ generating a message
> interrupt. Though i could see in the 8540 message status register that
> interrupt is generated, i could not get any IRQ when i do the probe. For
> this trial,  i have configured the PIC message enable register, message
> vector/priority and destination registers, processor current task
> priority register (CPTR).
>
> Can anyone give me some suggestions to try out.
>
> Thanks
> Sudheer
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

[-- Attachment #2: Type: text/html, Size: 2793 bytes --]

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Arnd Bergmann @ 2007-06-17  0:14 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras
In-Reply-To: <21B37470-5341-4AC7-9334-B58F0BCFAAC9@kernel.crashing.org>

On Sunday 17 June 2007, Kumar Gala wrote:
> > For the 'at least one option selected' argument, I'm not sure how
> > important that is, IMHO it falls into the same category as any
> > other essential option that you can disable.
>=20
> People have run into the issue so I think it desires at least a =A0
> little concern. =A0See: http://marc.info/?t=3D117529164800005&r=3D1&w=3D2

But isn't the reported problem just a bug in the build system?
My impression was that the user did not complain about the fact
that the kernel he was trying to build would not boot on any
platform, but rather that the kernel tried to build a zImage
that was not defined, resulting in a build error.

Obviously, any configuration that can be selected by the user
should be able to compile and link without errors, even if it's
not particularly useful.

Aside from the multiplatform enabling patches, are you happy with
the patches 1-8 from my fourth version of the patch set?

	Arnd <><

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-16 23:52 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Stephen Rothwell
In-Reply-To: <200706150151.40056.arnd@arndb.de>


On Jun 14, 2007, at 6:51 PM, Arnd Bergmann wrote:

> On Thursday 14 June 2007, Kumar Gala wrote:
>> I'm a little hesitant to move the embedded ppc's over to
>> multiplatform quite yet.  One feature I wanted was in Kconfig a way
>> to enforce the selection of at least one choice, as well as being
>> able to optimize things since we only had one choice selected.
>
> What would such a potential optimization be like? Are you thinking
> of turning the 'platform_is(foo)' check into a compile-time choice,
> or are there more places where you can imagine an optimization?
> I'd like to understand better what you want to achieve there,
> maybe I can find a way to do that in the same series.

Sort of, in that if we were built with the  
CONFIG_ONLY_HAD_ONE_MACHINE we could optimize the machine_is() checks  
away.

> For the 'at least one option selected' argument, I'm not sure how
> important that is, IMHO it falls into the same category as any
> other essential option that you can disable.

People have run into the issue so I think it desires at least a  
little concern.  See: http://marc.info/?t=117529164800005&r=1&w=2

- k

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-16 23:48 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-dev, paulus, arnd, sfr
In-Reply-To: <20070615132803.00e43768.kim.phillips@freescale.com>


On Jun 15, 2007, at 1:28 PM, Kim Phillips wrote:

> On Thu, 14 Jun 2007 08:33:19 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>
>> On Jun 13, 2007, at 8:46 PM, Paul Mackerras wrote:
>>
>>> Most of this series of patches touch 8xxx or 5xxx stuff in one  
>>> way or
>>> another, so I'll leave it to Kumar to make the decision about them.
>>> I'll put in 1/13.
>>
>> Arnd,
>>
>> I'm a little hesitant to move the embedded ppc's over to
>> multiplatform quite yet.  One feature I wanted was in Kconfig a way
>> to enforce the selection of at least one choice, as well as being
>> able to optimize things since we only had one choice selected.
>>
>> See the following thread for discussion I had with Sam & Roman on the
>> subject:
>>
>> http://marc.info/?t=117156757000002&r=1&w=2
>>
>
> FWIW, this patchseries tests ok on 83xx, and I didn't have a problem
> selecting at least one choice ;)

Its not an issue with selecting just one, its ability to select zero  
that I have issue with.

- k

^ permalink raw reply

* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-16 23:47 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Sam Ravnborg, linuxppc-dev, Paul Mackerras, arnd,
	Stephen Rothwell
In-Reply-To: <1181954800.26853.103.camel@localhost.localdomain>


On Jun 15, 2007, at 7:46 PM, Benjamin Herrenschmidt wrote:

> On Thu, 2007-06-14 at 08:33 -0500, Kumar Gala wrote:
>> On Jun 13, 2007, at 8:46 PM, Paul Mackerras wrote:
>>
>>> Most of this series of patches touch 8xxx or 5xxx stuff in one  
>>> way or
>>> another, so I'll leave it to Kumar to make the decision about them.
>>> I'll put in 1/13.
>>
>> Arnd,
>>
>> I'm a little hesitant to move the embedded ppc's over to
>> multiplatform quite yet.  One feature I wanted was in Kconfig a way
>> to enforce the selection of at least one choice, as well as being
>> able to optimize things since we only had one choice selected.
>>
>> See the following thread for discussion I had with Sam & Roman on the
>> subject:
>>
>> http://marc.info/?t=117156757000002&r=1&w=2
>
> I missed that discussion... but without actually reading it (yet),  
> I can
> already tell that I don't like the way you propose it. I would much
> prefer the CONFIG_xxx_ONLY_ONE be -generated- by the multiple choice
> menu if only one choice has been selected.
>
> That could be an optional argument to the menu stuff to set that.

That was my intent, that the Kconfig system would help in telling us  
only one choice was selected and we could optimize based on that.  In  
addition, to ensure that at least one choice was selected.  I believe  
Rob Landley came across an issue that exists today with MULTIPLATFORM  
support in that we can attempt to build a kernel w/o any system.

http://marc.info/?t=117529164800005&r=1&w=2

- k

^ permalink raw reply

* Re: [PATCH] Wire up sys_sync_file_range() on powerpc
From: David Woodhouse @ 2007-06-16 18:20 UTC (permalink / raw)
  To: paulus; +Cc: akpm, linuxppc-dev, torvalds, rmk, linux-arch
In-Reply-To: <1181992681.25228.683.camel@pmac.infradead.org>

On Sat, 2007-06-16 at 12:18 +0100, David Woodhouse wrote:
> Every time I build a ppc kernel it bitches at me that
> sys_sync_file_range is unimplemented. Shut it up...
> 
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> 
> ---
> The compat bit is untested although the assembly looks right, when
> compared with 32-bit calls to sys_sync_file_range(). Test kernel
> building now, although I leave for the airport within 24 hours and may
> not get round to actually testing it. 

+asmlinkage long compat_sys_sync_file_range(int fd, int dummy,
+                                  unsigned offset_hi, unsigned offset_lo,
+                                  unsigned nbytes_hi, unsigned nbytes_lo,
+                                  int flags)

Pants. It doesn't work because the 'flags' argument ends up in r9, and
we can only use r3-r8 for syscall arguments. We'll need to do it the
same way as ARM does, with the flags as the second argument.

I _wish_ people would remember that not all the world's an i386 when
they add new syscalls.

And I wish Linus would refuse to merge anything which just says "I wired
it up on i386" without even thinking about 32-on-64 compatibility.
Once we've merged it, it's too late to change the ABI to be sane.

Or is it? Can we ditch sys_sync_file_range now and implement a new
sys_sync_file_range2 with the two 32-bit arguments first?

-- 
dwmw2

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox