* Re: [RFC] Adding MTD to device tree
From: Segher Boessenkool @ 2006-08-12 9:58 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <1155347601.3108.7.camel@vader.jdub.homelinux.org>
>> Required properties:
>> - device_type : one of "nand-flash", "nor-flash", or "rom".
>
> There are more than just those kinds of MTDs. There's dataflash,
> AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be
> called
> "flash". See more below.
Existing firmwares call it "rom", "nvram", "flash". All of those
are easy; and I have really no opinion how all the weirdo nand-flash
etc. interfaces should be handled.
device_type communicates to the device-tree consumer what other
properties to expect in this node -- it does not indicate the exact
programming model of the device itself.
I suspect for most nand-flash you can get away with a device_type
of "nand-flash"; for some you might have to specify something more
detailed.
>> - model : an identifier for the actual controller chip used.
>
> Meaning what exactly? Lots of NOR flash doesn't have a "controller".
Lots of those chips from different vendors are pin-compatible as well,
so you cannot really hardcode one specific model number. I don't see
this information being very useful anyway. Instead, in most cases, the
information you're really after is the programming interface for the
device. And that goes...
>> - compatible : Should be the name of the MTD driver. For
>> type "rom", this is most likely "physmap".
>
> This I agree with, but Sergei already had this. And since you're
> specifying the name of the MTD driver, that typically already knows
> what
> type of chip it's talking to.
"compatible" contains a list, most specific first. So for example
for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot.
(Btw: no comma's, but 0-chars in the actual properties!)
Segher
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-12 11:35 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608112250q551c98f5j328183c31eebaf77@mail.gmail.com>
Albert Cahalan writes:
> I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.
What gcc version, what binutils version, what kernel version?
Paul.
^ permalink raw reply
* Re: PCI driver on EB8347
From: Rajan Rai @ 2006-08-12 12:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar K.-galak, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <94857DB0-ABC7-4AA5-BE5B-1CBEAA09D906@kernel.crashing.org>
Thanks IRQ problem is resolved. As pointed out it was problem
with IRQ IDSEL mapping. Mapping needs to be different on Eval board I'm
using and our custom design. But my driver is still not working on our
custom design. PCI device doesn't receive any messages from MPC8347 on
our custom design mother board which uses pci-bridge where as it works
fine on Eval board which doesn't use PCI bridge.
I guess problem lies at the kernel level and
not the driver. Any tips apart from IDSEL IRQ settings at kernel level
what else I need to change when I move from 1 mother board to another.
My PCI devices do get base address 0 and 1 allocated properly by the
OS. But when I try to write any messages on those addresses PCI device
doesn't see them
Regards,
-Rajan
Kumar Gala wrote:
>
> On Aug 11, 2006, at 4:15 AM, rajan rai wrote:
>
>>
>> I'm using polling mechanism and not interrupts
>> in my driver. Although I'm not using polling I see strange behavior
>> When I do lspci -v I don't see any interrupts being allocated to PCI
>> device behind PCI bridge !!!! But when I use same card directly on
>> primary bus I do see interrupt being allocated to PCI device. Any
>> advise why IRQ's being not allocated in case its attached to PCI
>> bridge ?
>>
>> Do I need to take care of any extra
>> configuration in case of PCI card is attached to PCI bridge ?
>
> You need to make sure that the pci_map_irq/mpc83xx_map_irq function
> handles the right swizziling for the P2P bridge for your setup. If
> you are just connected directly its pretty straight forward. However
> IRQ assignment behind the bridge can be very board specific and so you
> need to make sure that the code is doing the right think for you.
>
> What ever strangeness do you see from lspci?
>
> - k
>
>
^ permalink raw reply
* Re: PCI driver on EB8347
From: Kumar Gala @ 2006-08-12 13:54 UTC (permalink / raw)
To: Rajan Rai; +Cc: Gala Kumar K.-galak, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <44DDCAB8.80106@ingenient.com>
On Aug 12, 2006, at 7:34 AM, Rajan Rai wrote:
>
>
> Thanks IRQ problem is resolved. As pointed out it was
> problem with IRQ IDSEL mapping. Mapping needs to be different on
> Eval board I'm using and our custom design. But my driver is still
> not working on our custom design. PCI device doesn't receive any
> messages from MPC8347 on our custom design mother board which uses
> pci-bridge where as it works fine on Eval board which doesn't use
> PCI bridge.
>
> I guess problem lies at the kernel level
> and not the driver. Any tips apart from IDSEL IRQ settings at
> kernel level what else I need to change when I move from 1 mother
> board to another. My PCI devices do get base address 0 and 1
> allocated properly by the OS. But when I try to write any messages
> on those addresses PCI device doesn't see them
Is the bridge getting configured correctly? An lspci output would be
helpful from your system with the P2P bridge.
- kumar
^ permalink raw reply
* Re: [PATCH 0/6] POWERPC: Add support for CPM2 peripherals and 8560 eval board
From: Kumar Gala @ 2006-08-12 13:56 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060812000655.6186.42738.stgit@localhost.localdomain>
On Aug 11, 2006, at 6:42 PM, Vitaly Bordug wrote:
> The following series implements the generic cpm2 infrastructure port,
> mpc8560 board-specific bits, and an attempt to overhaul and get rid
> of some stuff moved along from the 2.4 times.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Can you post the .dts for 8560 you are using. I'd like to look at it
before reviewing the patchset.
thanks
- kumar
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-12 14:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17629.48408.564322.747132@cargo.ozlabs.ibm.com>
On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.
>
> What gcc version, what binutils version, what kernel version?
My gcc claims to be:
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
I suppose binutils can be determined by ld:
GNU ld version 2.16.91 20060413 Debian GNU/Linux
The kernel version was reported:
Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux
^ permalink raw reply
* RE: PCI driver on EB8347
From: rajan rai @ 2006-08-12 16:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar K.-galak, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <D9682BD5-FBDF-4D6C-BC82-6EF375DB6F46@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]
Kumar,
Here is lspci -v from my P2P system. In case you have any suggestion do let me know. I appreciate your help
00:11.0 PCI bridge: Texas Instruments PCI2050 PCI-to-PCI Bridge (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-0000ffff
Memory behind bridge: 9e000000-9fffffff
Prefetchable memory behind bridge: 000000009df00000-000000009df00000
Capabilities: [dc] Power Management version 2
01:01.0 Non-VGA unclassified device: Texas Instruments: Unknown device 9065 (rev 01)
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 18
Memory at 9fc00000 (32-bit, prefetchable) [size=4M]
Memory at 9f000000 (32-bit, non-prefetchable) [size=8M]
I/O ports at 3ffffff0 [size=16]
Capabilities: [40] Power Management version 2
01:02.0 Non-VGA unclassified device: Texas Instruments: Unknown device 9065 (rev 01)
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 19
Memory at 9ec00000 (32-bit, prefetchable) [size=4M]
Memory at 9e000000 (32-bit, non-prefetchable) [size=8M]
I/O ports at 3fffffe0 [size=16]
Capabilities: [40] Power Management version 2
Regards
-Rajan Rai
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Sat 8/12/2006 8:54 AM
To: rajan rai
Cc: Liu Dave-r63238; Gala Kumar K.-galak; linuxppc-embedded@ozlabs.org
Subject: Re: PCI driver on EB8347
On Aug 12, 2006, at 7:34 AM, Rajan Rai wrote:
>
>
> Thanks IRQ problem is resolved. As pointed out it was
> problem with IRQ IDSEL mapping. Mapping needs to be different on
> Eval board I'm using and our custom design. But my driver is still
> not working on our custom design. PCI device doesn't receive any
> messages from MPC8347 on our custom design mother board which uses
> pci-bridge where as it works fine on Eval board which doesn't use
> PCI bridge.
>
> I guess problem lies at the kernel level
> and not the driver. Any tips apart from IDSEL IRQ settings at
> kernel level what else I need to change when I move from 1 mother
> board to another. My PCI devices do get base address 0 and 1
> allocated properly by the OS. But when I try to write any messages
> on those addresses PCI device doesn't see them
Is the bridge getting configured correctly? An lspci output would be
helpful from your system with the P2P bridge.
- kumar
[-- Attachment #2: Type: text/html, Size: 4198 bytes --]
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Sergei Shtylyov @ 2006-08-12 16:19 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <001C3287-87E7-4DF9-AB4E-E1448EC20518@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>> Required properties:
>>> - device_type : one of "nand-flash", "nor-flash", or "rom".
I thought about having the separate device types initially, then I decided
that all the differences can be handled on the driver level...
>>There are more than just those kinds of MTDs. There's dataflash,
>>AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be
>>called "flash". See more below.
> Existing firmwares call it "rom", "nvram", "flash". All of those
> are easy; and I have really no opinion how all the weirdo nand-flash
> etc. interfaces should be handled.
> device_type communicates to the device-tree consumer what other
> properties to expect in this node -- it does not indicate the exact
> programming model of the device itself.
Erm, IIUC the exact set of properties is defined by the node name (or the
"compatible" property). The device type defines some mandatory set of
properties/methods but there may be some specific...
> I suspect for most nand-flash you can get away with a device_type
> of "nand-flash"; for some you might have to specify something more
> detailed.
Hm, not sure that you need to be so much detailed with the device type.
The original OF spec. had device type "block" signifying any kind of blocked
storage device.
>>> - model : an identifier for the actual controller chip used.
>>Meaning what exactly? Lots of NOR flash doesn't have a "controller".
> Lots of those chips from different vendors are pin-compatible as well,
> so you cannot really hardcode one specific model number. I don't see
> this information being very useful anyway. Instead, in most cases, the
> information you're really after is the programming interface for the
> device. And that goes...
This property might be marked optional still.
>>> - compatible : Should be the name of the MTD driver. For
>>> type "rom", this is most likely "physmap".
>>This I agree with, but Sergei already had this. And since you're
>>specifying the name of the MTD driver, that typically already knows
>>what
>>type of chip it's talking to.
> "compatible" contains a list, most specific first. So for example
> for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot.
> (Btw: no comma's, but 0-chars in the actual properties!)
The "compatible" prop (as well as "name") should define which driver to
select according to spec. (the Generic Names spec. delegates this role solely
to the "compatible" prop). While specifying the flash interface (JEDEC in this
case) is indeed useful (however, the current 'platform_device' based 'physmap'
implementation doesn't allow to pass the probe type to the driver), the prop
in the form suggested doesn't really help with selecting the MTD map driver
(without which you can't support a NOR flash). A reference to 'physmap' should
still be present in the node in one or another form...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/6] ehea: queue management
From: Thomas Klein @ 2006-08-12 16:37 UTC (permalink / raw)
To: Anton Blanchard, Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811215225.GH479@krispykreme>
Anton Blanchard wrote:
> Hi,
>
>
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_ethtool.c 1969-12-31
>>
>
>
>> +static void netdev_get_pauseparam(struct net_device *dev,
>> + struct ethtool_pauseparam *pauseparam)
>> +{
>> + printk("get pauseparam\n");
>> +}
>>
>
> There are a number of stubbed out ethtool functions like this. Best not
> to implement them and allow the upper layers to return a correct error.
>
> Anton
>
I agree, stubbs were removed.
Thomas
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Thomas Klein @ 2006-08-12 16:40 UTC (permalink / raw)
To: Anton Blanchard, Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811220728.GI479@krispykreme>
Anton Blanchard wrote:
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
>>
>
>
>> +extern void exit(int);
>>
>
> Should be able to remove that prototype :)
>
> Anton
>
Indeed :-) It's gone.
Thomas
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Sergei Shtylyov @ 2006-08-12 17:43 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-mtd, arnd, linuxppc-embedded
In-Reply-To: <311553550076b8b45674.846930886.miltonm@bga.com>
Hello.
Milton Miller wrote:
>>>+ h) MTD nodes
>>>+
>>>+ Memory Technology Devices are flash, ROM, and similar chips, often used
>>>+ for solid state file systems on embedded devices.
>>>+
>>>+ Required properties:
>>>+
>>>+ - device_type : has to be "mtd"
>>>+ - compatible : Should be the name of the MTD driver. Currently, this is
>>>+ most likely to be "physmap".
>>>+ - reg : Offset and length of the register set for the device.
>>I would prefer to call them something different in the device tree.
>>The name 'mtd' is very specific to Linux, but the device tree
>>is a more generic concept.
"Memory type devices" are specific to Linux? Doubt it. :-)
In fact, device type "flash" sounds too restrictive.
>>I understand that the booting-without-of.txt file is by definition
>>Linux specific as well, but we should be prepared for making parts
>>of it a OS independent binding at the point where we put the same
>>device nodes into actual OF implementations that able to boot
>>different operating systems.
>>I would prefer a naming that has
>> Required properties:
>> - device_type : one of "nand-flash", "nor-flash", or "rom".
>> - model : an identifier for the actual controller chip used.
>> - compatible : Should be the name of the MTD driver. For
>> type "rom", this is most likely "physmap".
> I'm with your suggestion for device_type and model, but not
> compatable. "physmap"? What kind of device is that? A
Directly mapped NOR flash or ROM I think.
> command set name, maybe with a width, would be
That'd be pretty useless if you don't let Linux know which MTD *map*
driver to use. And I have specified the "bank-width" prop.
> appropriate. Physmap is the name of another linux driver.
And the role of the "compatible" prop is exactly to help OS in selecting
the driver.
> Something like direct or linear might be appropriate for a rom,
> where just address and length appear.
I agree that "linear" or "direct" may be better variants.
> Even rom would be better than physmap.
Doubt it since the ROM is the only one thing (and even the least probable)
that we're going to support.
> milton
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/6] POWERPC: move the generic cpm2 stuff to the powerpc
From: Sergei Shtylyov @ 2006-08-12 18:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060812001013.6186.41337.stgit@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
> This moves the cpm2 common code and PIC stuff to the powerpc. Most of the files
> were just copied from ppc/, with minor tuning to make it compile, and, subsequently, work.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
[...]
> diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
> index f6a7ff0..876974e 100644
> --- a/include/asm-ppc/cpm2.h
> +++ b/include/asm-ppc/cpm2.h
[...]
> @@ -1186,7 +1190,7 @@ #define PC3_DIRC1 (PC3_TXDAT)
> #define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
> #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
> #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
> -#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
> +#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
>
> #endif /* __CPM2__ */
> #endif /* __KERNEL__ */
Alas, this last hunk doesn't apply to powerpc.git. Shouldn't it be in some
other patch instead?
WBR, Sergei
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Segher Boessenkool @ 2006-08-12 18:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <44DDFF94.3090402@ru.mvista.com>
>>>> - device_type : one of "nand-flash", "nor-flash", or "rom".
>
> I thought about having the separate device types initially, then
> I decided that all the differences can be handled on the driver
> level...
Not necessarily on all OSes.
>>> There are more than just those kinds of MTDs. There's dataflash,
>>> AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be
>>> called "flash". See more below.
>
>> Existing firmwares call it "rom", "nvram", "flash". All of those
>> are easy; and I have really no opinion how all the weirdo nand-flash
>> etc. interfaces should be handled.
>
>> device_type communicates to the device-tree consumer what other
>> properties to expect in this node -- it does not indicate the exact
>> programming model of the device itself.
>
> Erm, IIUC the exact set of properties is defined by the node
> name (or the "compatible" property). The device type defines some
> mandatory set of properties/methods but there may be some specific...
Exact set of properties isn't defined anywhere. "device_type" defines a
pretty generic interface, mostly saying what methods will be there (but
you don't care for that for a flattened tree); "compatible" communicates
to the OS what this device is exactly (so it can select a device driver
to use, for example). "name" should not be used by anything but humans
normally.
>> I suspect for most nand-flash you can get away with a device_type
>> of "nand-flash"; for some you might have to specify something more
>> detailed.
>
> Hm, not sure that you need to be so much detailed with the
> device type.
> The original OF spec. had device type "block" signifying any kind
> of blocked storage device.
But memory devices aren't really block devices, for example, NOR-flash
is random access for everything but erase operations.
>>>> - model : an identifier for the actual controller chip used.
> This property might be marked optional still.
Then there's no reason to include it in the binding; "model" is
already defined in the base spec.
>> "compatible" contains a list, most specific first. So for example
>> for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot.
>> (Btw: no comma's, but 0-chars in the actual properties!)
>
> The "compatible" prop (as well as "name") should define which
> driver to select according to spec. (the Generic Names spec.
> delegates this role solely to the "compatible" prop). While
> specifying the flash interface (JEDEC in this case) is indeed
> useful (however, the current 'platform_device' based 'physmap'
> implementation doesn't allow to pass the probe type to the driver),
> the prop in the form suggested doesn't really help with selecting
> the MTD map driver (without which you can't support a NOR flash). A
> reference to 'physmap' should still be present in the node in one
> or another form...
"compatible" denotes the device's specific programming interface,
_not_ the
name of the device's driver in some random OS. If you don't care for
the
detailed interface (because your driver will probe for it itself for
example,
as you said), you can take the next-less-specific entry from
"compatible" and
use that instead. Although it would be better to just probe for the few
specific interfaces defined (jedec-flash, cfi-flash, and a few more
perhaps).
Segher
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Segher Boessenkool @ 2006-08-12 18:48 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, linux-mtd, arnd, Milton Miller, linuxppc-embedded
In-Reply-To: <44DE1357.5010703@ru.mvista.com>
>>> I would prefer to call them something different in the device tree.
>>> The name 'mtd' is very specific to Linux, but the device tree
>>> is a more generic concept.
>
> "Memory type devices" are specific to Linux? Doubt it. :-)
The name "mtd" is.
> In fact, device type "flash" sounds too restrictive.
But we can't call it "memory", that one is taken already.
>> 'm with your suggestion for device_type and model, but not
>> compatable. "physmap"? What kind of device is that? A
>
> Directly mapped NOR flash or ROM I think.
So use "flash" and "rom" as device_type (and as name, heh).
>> appropriate. Physmap is the name of another linux driver.
>
> And the role of the "compatible" prop is exactly to help OS in
> selecting
> the driver.
But it *cannot* do that by just naming the driver. Not every OS
calls this driver "physmap", you know.
Segher
^ permalink raw reply
* Re: [PATCH 6/6] [RFC] POWERPC: generic CPM2 peripherals rehaul with cpm2_map mechanism
From: Sergei Shtylyov @ 2006-08-12 20:18 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060812001029.6186.18474.stgit@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
> Incorporating the new way of cpm2 immr access, introduced in the previous
> patch, into CPM2 peripheral devices (fs_enet and cpm_uart). Both ppc and
> powerpc approved working( real actions taken in powerpc only, ppc just
> has a wrapper to keep init stuff consistent).
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Hm, I got 4 rejects here. :-/
> diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
> index 2a35fe2..d5d36c3 100644
> --- a/arch/ppc/platforms/mpc8272ads_setup.c
> +++ b/arch/ppc/platforms/mpc8272ads_setup.c
> @@ -103,7 +103,7 @@ static struct fs_platform_info mpc82xx_e
> },
> };
>
> -static void init_fcc1_ioports(void)
> +static void init_fcc1_ioports(struct fs_platform_info*)
> {
> struct io_port *io;
> u32 tempval;
This one get rejected as well.
> diff --git a/arch/ppc/platforms/mpc866ads_setup.c b/arch/ppc/platforms/mpc866ads_setup.c
> index e12cece..5f130dc 100644
> --- a/arch/ppc/platforms/mpc866ads_setup.c
> +++ b/arch/ppc/platforms/mpc866ads_setup.c
[...]
> @@ -194,7 +194,7 @@ static void setup_scc1_ioports(void)
>
> }
>
> -static void setup_smc1_ioports(void)
> +static void setup_smc1_ioports(struct fs_uart_platform_info*)
> {
> immap_t *immap = (immap_t *) IMAP_ADDR;
> unsigned *bcsr_io;
And this one...
> diff --git a/arch/ppc/platforms/mpc885ads_setup.c b/arch/ppc/platforms/mpc885ads_setup.c
> index 5dfa4e6..bf388ed 100644
> --- a/arch/ppc/platforms/mpc885ads_setup.c
> +++ b/arch/ppc/platforms/mpc885ads_setup.c
[...]
> @@ -315,7 +315,7 @@ static void __init mpc885ads_fixup_scc_e
> mpc885ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
> }
>
> -static void setup_smc1_ioports(void)
> +static void setup_smc1_ioports(struct fs_uart_platform_info*)
> {
> immap_t *immap = (immap_t *) IMAP_ADDR;
> unsigned *bcsr_io;
And this...
> diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
> index bd6623a..220cc2d 100644
> --- a/include/asm-ppc/cpm2.h
> +++ b/include/asm-ppc/cpm2.h
> @@ -1196,5 +1196,58 @@ #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0
> #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
> #define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
>
> +/* Clocks and GRG's */
> +
> +enum cpm_clk_dir {
> + CPM_CLK_RX,
> + CPM_CLK_TX,
> + CPM_CLK_RTX
> +};
> +
> +enum cpm_clk_target {
> + CPM_CLK_SCC1,
> + CPM_CLK_SCC2,
> + CPM_CLK_SCC3,
> + CPM_CLK_SCC4,
> + CPM_CLK_FCC1,
> + CPM_CLK_FCC2,
> + CPM_CLK_FCC3
> +};
> +
> +enum cpm_clk {
> + CPM_CLK_NONE = 0,
> + CPM_BRG1, /* Baud Rate Generator 1 */
> + CPM_BRG2, /* Baud Rate Generator 2 */
> + CPM_BRG3, /* Baud Rate Generator 3 */
> + CPM_BRG4, /* Baud Rate Generator 4 */
> + CPM_BRG5, /* Baud Rate Generator 5 */
> + CPM_BRG6, /* Baud Rate Generator 6 */
> + CPM_BRG7, /* Baud Rate Generator 7 */
> + CPM_BRG8, /* Baud Rate Generator 8 */
> + CPM_CLK1, /* Clock 1 */
> + CPM_CLK2, /* Clock 2 */
> + CPM_CLK3, /* Clock 3 */
> + CPM_CLK4, /* Clock 4 */
> + CPM_CLK5, /* Clock 5 */
> + CPM_CLK6, /* Clock 6 */
> + CPM_CLK7, /* Clock 7 */
> + CPM_CLK8, /* Clock 8 */
> + CPM_CLK9, /* Clock 9 */
> + CPM_CLK10, /* Clock 10 */
> + CPM_CLK11, /* Clock 11 */
> + CPM_CLK12, /* Clock 12 */
> + CPM_CLK13, /* Clock 13 */
> + CPM_CLK14, /* Clock 14 */
> + CPM_CLK15, /* Clock 15 */
> + CPM_CLK16, /* Clock 16 */
> + CPM_CLK17, /* Clock 17 */
> + CPM_CLK18, /* Clock 18 */
> + CPM_CLK19, /* Clock 19 */
> + CPM_CLK20, /* Clock 20 */
> + CPM_CLK_DUMMY
> +};
> +
> +extern int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode);
> +
> #endif /* __CPM2__ */
> #endif /* __KERNEL__ */
And this file refuses to be patched altogether...
With these rejects fixed, everything seems fine, though.
WBR, Sergei
^ permalink raw reply
* (no subject)
From: Thane McGregor @ 2006-08-12 21:00 UTC (permalink / raw)
To: linuxppc-dev
thanemc@gmail.com
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Milton Miller @ 2006-08-12 21:15 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <44DE1357.5010703@ru.mvista.com>
On Aug 12, 2006, at 12:43 PM, Sergei Shtylyov wrote:
> Hello.
>
> Milton Miller wrote:
>
>>>> + h) MTD nodes
>>>> +
>>>> + Memory Technology Devices are flash, ROM, and similar chips,
>>>> often used
>>>> + for solid state file systems on embedded devices.
>>>> +
>>>> + Required properties:
>>>> +
>>>> + - device_type : has to be "mtd"
>>>> + - compatible : Should be the name of the MTD driver.
>>>> Currently, this is
>>>> + most likely to be "physmap".
>>>> + - reg : Offset and length of the register set for the device.
>
>>> I would prefer to call them something different in the device tree.
>>> The name 'mtd' is very specific to Linux, but the device tree
>>> is a more generic concept.
>
> "Memory type devices" are specific to Linux? Doubt it. :-)
> In fact, device type "flash" sounds too restrictive.
First of all, I was only quoting that.
Second, no, memory type devices are not specific to Linux. But the
term MTD
probably is[1]. If you don't want to call it flash, then call it rom.
The
fact that its programable rom is a detail.
>>> I understand that the booting-without-of.txt file is by definition
>>> Linux specific as well, but we should be prepared for making parts
>>> of it a OS independent binding at the point where we put the same
>>> device nodes into actual OF implementations that able to boot
>>> different operating systems.
>
>>> I would prefer a naming that has
>
>>> Required properties:
>>> - device_type : one of "nand-flash", "nor-flash", or "rom".
>>> - model : an identifier for the actual controller chip used.
>>> - compatible : Should be the name of the MTD driver. For
>>> type "rom", this is most likely "physmap".
>
>> I'm with your suggestion for device_type and model, but not
>> compatable.
>> "physmap"? What kind of device is that? A
>
> Directly mapped NOR flash or ROM I think.
I don't know how you got there, without your linux implementation
knowledge.
>> command set name, maybe with a width, would be
>
> That'd be pretty useless if you don't let Linux know which MTD
> *map* driver
> to use. And I have specified the "bank-width" prop.
The fact that its directly mapped should be evident from its location in
the device tree and its properties such as reg.
I think you are getting caught up the layering of the linux mtd
subsystem, and not
thinking about describing the hardware.
>> appropriate. Physmap is the name of another linux driver.
>
> And the role of the "compatible" prop is exactly to help OS in
> selecting the driver.
Yes, help select. But not say "here is the name of the driver to use."
Its to specify
the programing interface.
We don't say "use the ohci driver" but "this device has pci class
0C0310" and the
ohci-pci driver says "I handle devices that are pci class serial
subclass usb and
programming interface ohci".
Putting "cfi-xxx", "cfi", "rom" would show that it should be probed by
cfi
instead of by jedec for example.
Are we still talking about doing a driver that calls physmap with the
appropriate
address gathered from of_device? It would be the one to select the
nodes compatable
nodes, finds the relevant parms, and calls the mtd layer.
>> Something like direct or linear might be appropriate for a rom, where
>> just address
>> and length appear.
>
> I agree that "linear" or "direct" may be better variants.
Yea.
>> Even rom would be better than physmap.
>
> Doubt it since the ROM is the only one thing (and even the least
> probable) that we're
> going to support.
But it would make sense to be a later compatible entry ... we can treat
the flash as a
true read-only memory and it will work, we just will not have the
feature of writing
to it.
As segher pointed out, compatible is a (specific to generic) list of
hints to the
programming interface.
I'll admit I'm not that familiar with the mtd subsystem. But I did go
and browse the
redboot, ebony, and ocetea map drivers, along with physmap. With the
addresses filled
out, they would appear to collapse into one driver, with multiple
device nodes for each
one. Except for the partitioning information.
Ok that brings up partitions: if you need partitions, and don't have a
table system
like redboot, then we need some way to convey that in the device tree.
My
first instinct is that would be via device nodes under the map device
in the tree.
The nodes would get a reg with relative address and size, and the name
would be
the name of the partition. We could also do it in properties on the
mtd node, but
then would not not have a good place to put the name. (Well, we could
do a list of
strings and a parallel list of partition sizes. I would prefer we not
encode both
in one property). Yes, we can rely on cmdline partitioning ... but
that means a long
argument in your device tree you don't want edited.
milton
[1] Google seems to confirm this: the first several hits are for a
power equipment
manufacturer, and then linux-mtd site by itself, without other os's
"mtd" projects
in the first 4 pages of hits.
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Sergei Shtylyov @ 2006-08-12 22:00 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <91f1d0619c8ff22cf70404059d514857@bga.com>
Hello.
Milton Miller wrote:
>>>>> + h) MTD nodes
>>>>> +
>>>>> + Memory Technology Devices are flash, ROM, and similar chips,
>>>>> often used
>>>>> + for solid state file systems on embedded devices.
>>>>> +
>>>>> + Required properties:
>>>>> +
>>>>> + - device_type : has to be "mtd"
>>>>> + - compatible : Should be the name of the MTD driver.
>>>>> Currently, this is
>>>>> + most likely to be "physmap".
>>>>> + - reg : Offset and length of the register set for the device.
>>>> I would prefer to call them something different in the device tree.
>>>> The name 'mtd' is very specific to Linux, but the device tree
>>>> is a more generic concept.
>> "Memory type devices" are specific to Linux? Doubt it. :-)
>> In fact, device type "flash" sounds too restrictive.
> First of all, I was only quoting that.
I'm not ascribing them to you. :-)
> Second, no, memory type devices are not specific to Linux. But the term
> MTD
> probably is[1].
I doubt Google based conslusions qualify here.
> If you don't want to call it flash, then call it rom. The
> fact that its programable rom is a detail.
Important detail, I'd say.
>>>> I understand that the booting-without-of.txt file is by definition
>>>> Linux specific as well, but we should be prepared for making parts
>>>> of it a OS independent binding at the point where we put the same
>>>> device nodes into actual OF implementations that able to boot
>>>> different operating systems.
>>>> I would prefer a naming that has
>>>> Required properties:
>>>> - device_type : one of "nand-flash", "nor-flash", or "rom".
>>>> - model : an identifier for the actual controller chip used.
>>>> - compatible : Should be the name of the MTD driver. For
>>>> type "rom", this is most likely "physmap".
>>> I'm with your suggestion for device_type and model, but not compatable.
>>> "physmap"? What kind of device is that? A
>> Directly mapped NOR flash or ROM I think.
> I don't know how you got there, without your linux implementation
> knowledge.
Indeed, this was compeletely Linux specific name.
>>> command set name, maybe with a width, would be
>> That'd be pretty useless if you don't let Linux know which MTD
>> *map* driver
>> to use. And I have specified the "bank-width" prop.
> The fact that its directly mapped should be evident from its location in
> the device tree and its properties such as reg.
Nohow. The flash could be be indirectly accessible and still have the reg
prop in the device node. It also may need nasty byte swapping tricks (in which
case it's not physmap compatible).
> I think you are getting caught up the layering of the linux mtd
> subsystem, and not
> thinking about describing the hardware.
If we end up with the node spec that is correct from the point of
description the hardware but absolutely useless when it comes to selectiong
the proper driver, what use it would be?
>>> appropriate. Physmap is the name of another linux driver.
>> And the role of the "compatible" prop is exactly to help OS in
>> selecting the driver.
> Yes, help select. But not say "here is the name of the driver to use."
> Its to specify the programing interface.
Well, you may be wrong here. See below. :-)
> Putting "cfi-xxx", "cfi", "rom" would show that it should be probed by cfi
> instead of by jedec for example.
Yes. But that's just no use with the current platform_device base
implementation of physmap. So we'd either need to extend this implementation
or make physmap parse all that from the device tree by itself.
> Are we still talking about doing a driver that calls physmap with the
> appropriate
> address gathered from of_device?
Well, this would not exactly be a driver then.
> It would be the one to select the nodes compatable
> nodes, finds the relevant parms, and calls the mtd layer.
In fact, I indended to probe the MTD/PPC people which way they like best:
sticking with platform_device still, or making physmap of_device aware by
itself (although we'd still need to register the flash device somewhere in
arch/powerpc/, since there's not code anywhere that register *all* devices
found in the device tree)...
>>> Even rom would be better than physmap.
>> Doubt it since the ROM is the only one thing (and even the least
>> probable) that we're
>> going to support.
> But it would make sense to be a later compatible entry ... we can treat
> the flash as a
> true read-only memory and it will work, we just will not have the
> feature of writing
> to it.
Indeed, if "compatible" incorporated the chip interfaces (probe types for
MTD/physmap drivers), that'd have made sense. Alas, with platform_device based
approach, we have no way of passing this info to MTD subsys currently.
> As segher pointed out, compatible is a (specific to generic) list of
> hints to the
> programming interface.
If you look into the OF specs, "compatible" and "name" are treated as the
*driver* names here. There are whole passages there warning about not
selecting too generic driver names like "network".
> I'll admit I'm not that familiar with the mtd subsystem. But I did go
> and browse the
> redboot, ebony, and ocetea map drivers, along with physmap. With the
> addresses filled
> out, they would appear to collapse into one driver, with multiple device
> nodes for each
> one. Except for the partitioning information.
Then they should have indeed collapsed into it. The thing is physmap
driver might be actually newer than those ones, so they're kept for historical
reasons (and for the partition info which actually should move into the
platform setup code).
> Ok that brings up partitions: if you need partitions, and don't have a
> table system
> like redboot, then we need some way to convey that in the device tree. My
> first instinct is that would be via device nodes under the map device in
> the tree.
Erm, what map device?
> The nodes would get a reg with relative address and size, and the name
> would be
> the name of the partition.
MTD partitions are *not* devices, so I guess the first instinct is wrong
(I had to struggle with it too :-).
> We could also do it in properties on the
> mtd node, but
> then would not not have a good place to put the name. (Well, we could
> do a list of
> strings and a parallel list of partition sizes. I would prefer we not
> encode both
> in one property).
'dtc' wouldn't able to chew it anyway although the OF spec. promised
multi-type properties.
Sorry, have you bothered looking into my node spec? :-)
> Yes, we can rely on cmdline partitioning ... but that
> means a long
> argument in your device tree you don't want edited.
I finally decided that if we have the ability to store it in the device
tree, this is better than have user to type and store the bootargs (or worse
yet, rebuild U-Boot changing the default value of this env. var.).
> milton
> [1] Google seems to confirm this: the first several hits are for a power
> equipment
> manufacturer, and then linux-mtd site by itself, without other os's
> "mtd" projects
> in the first 4 pages of hits.
Hm, MTD is a short for "memory type device", what Linux has to do with it
at all? However, let the MTD experts correct me...
WBR, Sergei
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-12 23:54 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608120736n1ba0bc03jccf2964bf7ebb1d5@mail.gmail.com>
Albert Cahalan writes:
> gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
OK, so I think that version should have the new -msecure-plt flag,
which changes the ppc32 ABI so that the PLT no longer has to be
writable and executable. Previously the dynamic linker would rewrite
each PLT entry, the first time it is used, to jump directly to the
target routine. That was the reason why the heap had to be
executable.
To get the full benefit of -msecure-plt, every object file in your
executable has to be compiled with it, and I think every shared
library the program uses has to be compiled with it too. On a system
where everything has been compiled with -msecure-plt, I believe the
heap and stack will automatically be made non-executable.
Of course, that won't make all that much difference on your Cube,
because the G4 CPU doesn't have hardware support for non-executable
pages (any readable page is executable). The G5 does, as do the 4xx
and Book E 32-bit CPUs, and any 64-bit CPU from POWER4 on.
As for the randomization, I'm surprised we got no stack randomization,
since that appears to be handled generically (randomize_stack_stop()
in fs/binfmt_elf.c). What does cat /proc/sys/kernel/randomize_va_space
give you? (i386 also does arch-specific randomization of some low
bits of the stack pointer, which we could do too.)
Shared library randomization is a glibc thing, I assume. (It is
incompatible with prelink, of course.) I don't believe we can do
ET_EXEC address randomization, and I don't think x86 can do it either.
Paul.
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Wolfgang Denk @ 2006-08-13 0:20 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Arnd Bergmann, Milton Miller, linuxppc-dev, linux-mtd,
linuxppc-embedded
In-Reply-To: <44DE4F84.9030802@ru.mvista.com>
In message <44DE4F84.9030802@ru.mvista.com> you wrote:
>
> Hm, MTD is a short for "memory type device", what Linux has to do with it
Memory Technology Device.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to
be assimilated.
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Wolfgang Denk @ 2006-08-13 0:20 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-mtd, Arnd Bergmann, linuxppc-embedded
In-Reply-To: <91f1d0619c8ff22cf70404059d514857@bga.com>
In message <91f1d0619c8ff22cf70404059d514857@bga.com> you wrote:
>
> Second, no, memory type devices are not specific to Linux. But the
> term MTD
> probably is[1]. If you don't want to call it flash, then call it rom.
No, it is not. It has been used by other RTOS as well, and probably
before Linux.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A conservative is a man who believes that nothing should be done for
the first time. - Alfred E. Wiggam
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-13 2:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17630.27174.711916.643790@cargo.ozlabs.ibm.com>
On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
>
> OK, so I think that version should have the new -msecure-plt flag,
The flag matters not, even with the very latest binutils
that Debian offers, version 2.17-2:
$ md5sum default m*
5f8398f47793ae0eee635989825c8e6b default
5f8398f47793ae0eee635989825c8e6b mbss-plt
5f8398f47793ae0eee635989825c8e6b msecure-plt
(the default needs to be secure of course, so that
all the Debian packages get it)
> To get the full benefit of -msecure-plt, every object file in your
> executable has to be compiled with it, and I think every shared
> library the program uses has to be compiled with it too. On a system
> where everything has been compiled with -msecure-plt, I believe the
> heap and stack will automatically be made non-executable.
VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
default is important for security. If gcc on PowerPC ever
does generate code which puts trampolines on the stack,
then that can be fixed by converting to legal C code or
by adding the fragile marking to the defective executables.
Did gcc ever generate such code on PowerPC? If not,
then there is no reason to ever allow an executable stack.
In any case, I see no markings:
$ eu-readelf -n /lib/libc-2.3.6.so
Note segment of 32 bytes at offset 0x174:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.4.1
$ eu-readelf -n a.out
Note segment of 32 bytes at offset 0x124:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.4.1
> Of course, that won't make all that much difference on your Cube,
> because the G4 CPU doesn't have hardware support for non-executable
> pages (any readable page is executable).
No. Look in the segment registers. The granularity
isn't great, but the stack can be protected at least.
With a decent memory layout, as is done for using
the CS segment limit on i386, all but the bottom
256 MiB should be non-execute.
Counting executable pages per segment is reasonable.
I believe this is what OpenBSD does.
A better way would be to frequently mark the segments
as non-execute. (upon every context switch, mapping
change, or sleep) Then, upon taking a fault, only enable
execute in the segment if the instruction pointer is in an
area which is really supposed to be executable.
> As for the randomization, I'm surprised we got no stack randomization,
> since that appears to be handled generically (randomize_stack_stop()
> in fs/binfmt_elf.c). What does cat /proc/sys/kernel/randomize_va_space
> give you? (i386 also does arch-specific randomization of some low
> bits of the stack pointer, which we could do too.)
I get a 1.
> Shared library randomization is a glibc thing, I assume. (It is
> incompatible with prelink, of course.)
It seems that glibc often asks for specific addresses,
which is bad. The rest of the time this is a kernel issue.
> I don't believe we can do
> ET_EXEC address randomization, and I don't think x86 can do it either.
Sure, but I just tried the other type (should be default)
and didn't get any improvement.
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-13 3:23 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608121948rad24dc7le834f1b499543ace@mail.gmail.com>
Albert Cahalan writes:
> VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> default is important for security. If gcc on PowerPC ever
> does generate code which puts trampolines on the stack,
> then that can be fixed by converting to legal C code or
> by adding the fragile marking to the defective executables.
> Did gcc ever generate such code on PowerPC? If not,
> then there is no reason to ever allow an executable stack.
I believe it did for nested procedures in C.
Now that we have the VDSO and use it for signal trampolines, we
probably could change the default stack protections.
> No. Look in the segment registers. The granularity
> isn't great, but the stack can be protected at least.
No, ld.so tends to go just below the stack:
f7fe6000-f7fff000 r-xp 00000000 08:05 17069 /lib/ld-2.3.6.so
f800e000-f800f000 r--p 00018000 08:05 17069 /lib/ld-2.3.6.so
f800f000-f8010000 rwxp 00019000 08:05 17069 /lib/ld-2.3.6.so
ffe67000-ffe7c000 rw-p ffe67000 00:00 0 [stack]
Paul.
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-13 4:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17630.39716.551115.850057@cargo.ozlabs.ibm.com>
On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > default is important for security. If gcc on PowerPC ever
> > does generate code which puts trampolines on the stack,
> > then that can be fixed by converting to legal C code or
> > by adding the fragile marking to the defective executables.
> > Did gcc ever generate such code on PowerPC? If not,
> > then there is no reason to ever allow an executable stack.
>
> I believe it did for nested procedures in C.
I just disassembled libgcc. You're right. Eeeeeew.
I filed a bug describing two better methods for this.
> Now that we have the VDSO and use it for signal trampolines, we
> probably could change the default stack protections.
Heh. I though i386 was the only one to ever do that.
The obvious method is to set the return address to
be a special value which will fault, like -3.
> > No. Look in the segment registers. The granularity
> > isn't great, but the stack can be protected at least.
>
> No, ld.so tends to go just below the stack:
>
> f7fe6000-f7fff000 r-xp 00000000 08:05 17069 /lib/ld-2.3.6.so
> f800e000-f800f000 r--p 00018000 08:05 17069 /lib/ld-2.3.6.so
> f800f000-f8010000 rwxp 00019000 08:05 17069 /lib/ld-2.3.6.so
> ffe67000-ffe7c000 rw-p ffe67000 00:00 0 [stack]
That looks like a 64-bit system, which doesn't have
the granularity problem anyway. 32-bit powerpc seems
to be decent. The heap shares with the executable
itself, and of course there is the yucky 2 GB limit.
$ cat /proc/self/maps
00100000-00103000 r-xp 00100000 00:00 0
0fe8b000-0ffd4000 r-xp 00000000 03:0d 2081203 /lib/tls/libc-2.3.6.so
0ffd4000-0ffe3000 ---p 00149000 03:0d 2081203 /lib/tls/libc-2.3.6.so
0ffe3000-0ffea000 r--p 00148000 03:0d 2081203 /lib/tls/libc-2.3.6.so
0ffea000-0ffee000 rwxp 0014f000 03:0d 2081203 /lib/tls/libc-2.3.6.so
0ffee000-0fff0000 rwxp 0ffee000 00:00 0
10000000-10005000 r-xp 00000000 03:0d 1327891 /bin/cat
10014000-10015000 rwxp 00004000 03:0d 1327891 /bin/cat
10015000-10036000 rwxp 10015000 00:00 0 [heap]
30000000-30019000 r-xp 00000000 03:0d 2080939 /lib/ld-2.3.6.so
30019000-3001b000 rw-p 30019000 00:00 0
30028000-30029000 r--p 00018000 03:0d 2080939 /lib/ld-2.3.6.so
30029000-3002a000 rwxp 00019000 03:0d 2080939 /lib/ld-2.3.6.so
7fa45000-7fa5a000 rw-p 7fa45000 00:00 0 [stack]
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Alan Modra @ 2006-08-13 3:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Albert Cahalan, linuxppc-dev, debian-powerpc
In-Reply-To: <17630.27174.711916.643790@cargo.ozlabs.ibm.com>
On Sun, Aug 13, 2006 at 09:54:14AM +1000, Paul Mackerras wrote:
> To get the full benefit of -msecure-plt, every object file in your
> executable has to be compiled with it
Yes. In particular, glibc startup files need to be compiled with
-msecure-plt. If ld links any object file that uses the old scheme
requiring an executable .got into the executable, then the old layout is
forced.
>, and I think every shared
> library the program uses has to be compiled with it too.
No, this isn't necessary.
> On a system
> where everything has been compiled with -msecure-plt, I believe the
> heap and stack will automatically be made non-executable.
Exec stack is a separate issue from the plt/got layout. You need a
kernel that sets non-exec stack by default and respects PT_GNU_STACK
program header.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox