powerpc: compile kernel for linkstations optimized for size

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.
=20
Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

=20
=20

Signed-off-by Rog=E9rio Brito <[email protected]>

=20
---
=20
--- linux/arch/powerpc/configs/linkstation_defconfig.old=092008-10-13 00:=

+++ linux/arch/powerpc/configs/linkstation_defconfig=092008-10-13 01:11:2=

arch/powerpc/configs/linkstation_defconfig renamed from arch/powerpc/configs/linkstation_defconfig.old +2 -2

@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.27-rc4
-# Thu Aug 21 00:52:05 2008
+# Linux kernel version: 2.6.27
+# Mon Oct 13 01:11:21 2008
 #
 # CONFIG_PPC64 is not set

=20

arch/powerpc/configs/linkstation_defconfig renamed from arch/powerpc/configs/linkstation_defconfig.old +1 -2

@@ -101,7 +101,7 @@ CONFIG_HOTPLUG=3Dy
 CONFIG_PRINTK=3Dy
 CONFIG_BUG=3Dy
 CONFIG_ELF_CORE=3Dy
-CONFIG_COMPAT_BRK=3Dy
+# CONFIG_COMPAT_BRK is not set
 CONFIG_BASE_FULL=3Dy
 CONFIG_FUTEX=3Dy
 CONFIG_ANON_INODES=3Dy

@@ -1211,7 +1211,6 @@ CONFIG_USB_STORAGE=3Dm
 # CONFIG_USB_STORAGE_ALAUDA is not set
 # CONFIG_USB_STORAGE_ONETOUCH is not set
 # CONFIG_USB_STORAGE_KARMA is not set
-# CONFIG_USB_STORAGE_SIERRA is not set
 # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
 # CONFIG_USB_LIBUSUAL is not set

=20
=20
--=20

Rog=E9rio Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
=20

Quoted 3 lines · Rogério Brito

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.

Quoted 2 lines

Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

Same as the previous patch - this is one of options, that users select according to their needs. If any specific distribution enables this option by default in their kernels, they can do this too, don't think this is critical enough to patch the defconfig.

Quoted 6 lines · Guennadi Liakhovetski

On Mon, 13 Oct 2008, Rog=E9rio Brito wrote:
=20

Quoted 4 lines

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.
=20
Since some of these machines are facing the internet, it helps to hav=

Quoted 3 lines

Quoted 1 line

heap randomization enabled. This patch enables it.

=20
Same as the previous patch - this is one of options, that users select=

Quoted 1 line

according to their needs. If any specific distribution enables this opt=

Quoted 1 line

by default in their kernels, they can do this too, don't think this is=

Quoted 1 line

critical enough to patch the defconfig.

=20
Just because users/distros can change it doesn't mean it's pointless to discuss what default is sane, and make changes if the current default isn't.
=20
For security-related options it's usually best to default to the more secure state, especially since the option description talks about it being needed mainly for libc5 compatibility -- did libc5 ever even exist for powerpc? =20

The only reason it was turned on in the first place was likely the "default y", which in turn is there to avoid breaking old x86 distros.

Quoted 5 lines · Guennadi Liakhovetski

Quoted 3 lines · Rogério Brito

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.

Quoted 7 lines

Quoted 2 lines

Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

Same as the previous patch - this is one of options, that users select according to their needs. If any specific distribution enables this option by default in their kernels, they can do this too, don't think this is critical enough to patch the defconfig.

Just because users/distros can change it doesn't mean it's pointless to discuss what default is sane, and make changes if the current default isn't.

For security-related options it's usually best to default to the more secure state, especially since the option description talks about it being needed mainly for libc5 compatibility -- did libc5 ever even exist for powerpc?

The only reason it was turned on in the first place was likely the "default y", which in turn is there to avoid breaking old x86 distros.

Quoted 4 lines · Guennadi Liakhovetski

Quoted 3 lines · Rogério Brito

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.

Quoted 7 lines

Quoted 2 lines

Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

Same as the previous patch - this is one of options, that users select according to their needs. If any specific distribution enables this option by default in their kernels, they can do this too, don't think this is critical enough to patch the defconfig.

Just because users/distros can change it doesn't mean it's pointless to discuss what default is sane, and make changes if the current default isn't.

For security-related options it's usually best to default to the more secure state, especially since the option description talks about it being needed mainly for libc5 compatibility -- did libc5 ever even exist for powerpc?

The only reason it was turned on in the first place was likely the "default y", which in turn is there to avoid breaking old x86 distros.

And it seems that there is something not quite right for these embedded systems. Here is something that I get with a vanilla linkstation_defconfig:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I just saw that in the default config:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # CONFIG_PPC_CLOCK is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Maybe this should be enabled? I can iterate once more to see if this option would make any difference here.

systems. Here is something that I get with a vanilla linkstation_defconfi=

=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =20
This gets me (with bootlogd enabled):
=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Wed Dec 31 21:00:15 1969: Cannot access the Hardware Clock via any known =

Wed Dec 31 21:00:15 1969: Use the --debug option to see the details of ou=

Wed Dec 31 21:00:15 1969: Unable to set System Clock to: Thu Jan 1 00:00:=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I just saw that in the default config:
=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # CONFIG_PPC_CLOCK is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(modified the cc-list somewhat)

Quoted 1 line · On Sat, 18 Oct 2008, Rog=E9rio Brito wrote:

systems. Here is something that I get with a vanilla linkstation_defconf=

Quoted 9 lines

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This gets me (with bootlogd enabled):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Wed Dec 31 21:00:15 1969: Cannot access the Hardware Clock via any known=

Quoted 1 line

Wed Dec 31 21:00:15 1969: Use the --debug option to see the details of o=

Quoted 1 line

Wed Dec 31 21:00:15 1969: Unable to set System Clock to: Thu Jan 1 00:00=

Quoted 1 line

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Yes, there seems to be a problem here now. The i2c adapter does not get probed, i.e., of-matching doesn't work. A quick look through other device-trees, using the same i2c driver, through git-logs of the i2c driver and the dts didn't bring me to a solution. Can anyone spot what's wrong with kuroboxHG.dts? lsprop output looks reasonable. Last working kernel was 2.6.25-rc6-ish.

Quoted 5 lines

I just saw that in the default config:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # CONFIG_PPC_CLOCK is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

No, kurobox uses generic RTC class.

Thanks for the report
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Quoted 8 lines · Guennadi Liakhovetski

Yes, there seems to be a problem here now. The i2c adapter does not get probed, i.e., of-matching doesn't work. A quick look through other device-trees, using the same i2c driver, through git-logs of the i2c driver and the dts didn't bring me to a solution. Can anyone spot what's wrong with kuroboxHG.dts? lsprop output looks reasonable. Last working kernel was 2.6.25-rc6-ish.

Quoted 7 lines

Quoted 5 lines

I just saw that in the default config:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # CONFIG_PPC_CLOCK is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

No, kurobox uses generic RTC class.

I don't see anything obviously wrong.

Is rtc-rs5c372 built into your kernel?

You may need to add some debug statements in drivers/of/of_i2c.c to figure out what is wrong.
It could be something like a _ not matching a -.

Quoted 2 lines

Yes, there seems to be a problem here now. The i2c adapter does not get probed, i.e., of-matching doesn't work. A quick look through other

Quoted 18 lines · Jon Smirl

Quoted 8 lines · Guennadi Liakhovetski

Yes, there seems to be a problem here now. The i2c adapter does not get probed, i.e., of-matching doesn't work. A quick look through other device-trees, using the same i2c driver, through git-logs of the i2c driver and the dts didn't bring me to a solution. Can anyone spot what's wrong with kuroboxHG.dts? lsprop output looks reasonable. Last working kernel was 2.6.25-rc6-ish.

Quoted 7 lines

Quoted 5 lines

I just saw that in the default config:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # CONFIG_PPC_CLOCK is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

No, kurobox uses generic RTC class.

Quoted 7 lines

I don't see anything obviously wrong.

Is rtc-rs5c372 built into your kernel?

You may need to add some debug statements in drivers/of/of_i2c.c to figure out what is wrong.
It could be something like a _ not matching a -.

Quoted 2 lines · Above I

Quoted 2 lines

Yes, there seems to be a problem here now. The i2c adapter does not get probed, i.e., of-matching doesn't work. A quick look through other

i.e., i2c-mpc is not matched against its fdt-node, not the rtc.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

i2c-mpc.c has:

static const struct of_device_id mpc_i2c_of_match[] = {
	{.compatible = "fsl-i2c",},
	{},
};

MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);

/* Structure for a device driver */

static struct of_platform_driver mpc_i2c_driver = {
	.match_table	= mpc_i2c_of_match,
	.probe		= fsl_i2c_probe,
	.remove		= __devexit_p(fsl_i2c_remove),
	.driver		= {
		.owner	= THIS_MODULE,
		.name	= DRV_NAME,
	},
};

That should match:

		i2c@80003000 {
			#address-cells = <1>;
			#size-cells = <0>;
			cell-index = <0>;
			compatible = "fsl-i2c";
			reg = <0x80003000 0x1000>;
			interrupts = <5 2>;
			interrupt-parent = <&mpic>;

			rtc@32 {
				device_type = "rtc";
				compatible = "ricoh,rs5c372a";
				reg = <0x32>;
			};
		};

This code works on my mpc5200 board.

Maybe fsl_i2c_probe() is failing?

Add some printks in i2c-mpc to help debug the problem. Any errors from i2c-mpc in dmesg?

Quoted 22 lines · Jon Smirl

i2c-mpc.c has:

static const struct of_device_id mpc_i2c_of_match[] = {
      {.compatible = "fsl-i2c",},
      {},
};

MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);

/* Structure for a device driver */
static struct of_platform_driver mpc_i2c_driver = {

      .match_table    = mpc_i2c_of_match,
      .probe          = fsl_i2c_probe,
      .remove         = __devexit_p(fsl_i2c_remove),
      .driver         = {
              .owner  = THIS_MODULE,
              .name   = DRV_NAME,
      },
};

That should match:

Quoted 15 lines

              i2c@80003000 {
                      #address-cells = <1>;
                      #size-cells = <0>;
                      cell-index = <0>;
                      compatible = "fsl-i2c";
                      reg = <0x80003000 0x1000>;
                      interrupts = <5 2>;
                      interrupt-parent = <&mpic>;

                      rtc@32 {
                              device_type = "rtc";
                              compatible = "ricoh,rs5c372a";
                              reg = <0x32>;
                      };
              };

It should, but it doesn't.

Quoted 1 line

This code works on my mpc5200 board.

Don't know which 5200 board you have, but, for example lite5200 has

                       compatible = "fsl,mpc5200-i2c","fsl-i2c";

see the difference?

Quoted 1 line

Maybe fsl_i2c_probe() is failing?

It has a printk at each error case (ok, except kzalloc, but I don't think that is the case), I see none of them.

Quoted 2 lines

Add some printks in i2c-mpc to help debug the problem. Any errors from i2c-mpc in dmesg?

None, and, as I said, there are no error messages from it, so, it doesn't get called at all. To be quite sure I added a printk at the entry - as expected it didn't get printed.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Is i2c-mpc built into your kernel? It's not going to module auto-load because the names don't match - fsl-i2c and i2c-mpc.

But a message on init and make sure it is loading. static int __init fsl_i2c_init(void)

{
	int rv;

	rv = of_register_platform_driver(&mpc_i2c_driver);
	if (rv)
		printk(KERN_ERR DRV_NAME
		       " of_register_platform_driver failed (%i)\n", rv);
	return rv;
}

Quoted 1 line

Quoted 6 lines

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Signature · 2 lines

Jon Smirl
[email protected]

Quoted 2 lines · Jon Smirl

Is i2c-mpc built into your kernel? It's not going to module auto-load because the names don't match - fsl-i2c and i2c-mpc.

It is built into the kernel.

Thanks
Guennadi

Quoted 23 lines

But a message on init and make sure it is loading. static int __init fsl_i2c_init(void)

{
      int rv;

      rv = of_register_platform_driver(&mpc_i2c_driver);
      if (rv)
              printk(KERN_ERR DRV_NAME
                     " of_register_platform_driver failed (%i)\n", rv);
      return rv;
}

Quoted 7 lines

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Quoted 4 lines

--
Jon Smirl
[email protected]

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Quoted 6 lines · Guennadi Liakhovetski

Quoted 2 lines · Jon Smirl

Is i2c-mpc built into your kernel? It's not going to module auto-load because the names don't match - fsl-i2c and i2c-mpc.

It is built into the kernel.

Put a printk in it's init function to make sure it is initializing.

Next thing I do is put printks over in arch/powerpc/.. to tell me which strings from the device tree are being looked for.

You can also look in /proc/device_tree and make sure fsl-i2c is in there.

When you find the problem is will probably be something simple like a mismatch between _ and -. I have been down this path before and spent a day figuring out why a module wouldn't load and it was a simple typo.

Quoted 1 line · Jon Smirl

Put a printk in it's init function to make sure it is initializing.

I don't need that, I see it here:

/sys/bus/of_platform/drivers/mpc-i2c

Quoted 4 lines

Next thing I do is put printks over in arch/powerpc/.. to tell me which strings from the device tree are being looked for.

You can also look in /proc/device_tree and make sure fsl-i2c is in there.

Quoted 11 lines · Jon Smirl

That should match:

		i2c@80003000 {
			#address-cells = <1>;
			#size-cells = <0>;
			cell-index = <0>;
			compatible = "fsl-i2c";
			reg = <0x80003000 0x1000>;
			interrupts = <5 2>;
			interrupt-parent = <&mpic>;

Quoted 6 lines

			rtc@32 {
				device_type = "rtc";
				compatible = "ricoh,rs5c372a";
				reg = <0x32>;
			};
		};

It should, but it doesn't.

Quoted 19 lines · Guennadi Liakhovetski

Quoted 17 lines · Jon Smirl

That should match:

		i2c@80003000 {
			#address-cells = <1>;
			#size-cells = <0>;
			cell-index = <0>;
			compatible = "fsl-i2c";
			reg = <0x80003000 0x1000>;
			interrupts = <5 2>;
			interrupt-parent = <&mpic>;

			rtc@32 {
				device_type = "rtc";
				compatible = "ricoh,rs5c372a";
				reg = <0x32>;
			};
		};

Quoted 1 line

It should, but it doesn't.

Is the parent of the i2c node covered by the list passed to of_platform_bus_probe() on this board?

static __initdata struct of_device_id storcenter_of_bus[] = {
        { .name = "soc", },
        {},
};

static int __init storcenter_device_probe(void)

{
        of_platform_bus_probe(NULL, storcenter_of_bus, NULL);
        return 0;
}

machine_device_initcall(storcenter, storcenter_device_probe);

? No, linkstation doesn't do that. Somehow, as this API has been introduced, linkstation has been left aside:-(

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.

Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

Signed-off-by Rogério Brito <[email protected]>

---

arch/powerpc/configs/linkstation_defconfig renamed from arch/powerpc/configs/linkstation_defconfig.old +3 -4

@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.27-rc4
-# Thu Aug 21 00:52:05 2008
+# Linux kernel version: 2.6.27
+# Mon Oct 13 01:11:21 2008
 #
 # CONFIG_PPC64 is not set
 

@@ -101,7 +101,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-CONFIG_COMPAT_BRK=y
+# CONFIG_COMPAT_BRK is not set
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y

@@ -1211,7 +1211,6 @@ CONFIG_USB_STORAGE=m
 # CONFIG_USB_STORAGE_ALAUDA is not set
 # CONFIG_USB_STORAGE_ONETOUCH is not set
 # CONFIG_USB_STORAGE_KARMA is not set
-# CONFIG_USB_STORAGE_SIERRA is not set
 # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
 # CONFIG_USB_LIBUSUAL is not set
 

Signature · 4 lines

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

The current defconfig for Linkstation/Kuroboxes has the "Disable Heap Randomization" option enabled.

Since some of these machines are facing the internet, it helps to have heap randomization enabled. This patch enables it.

Signed-off-by Rog=E9rio Brito <[email protected]>

---

From: Rog=E9rio Brito <[email protected]>
=20
Since Linkstations and Kuroboxes often have *very* little memory (as they are embedded systems), it is desirable to get their kernels compiled optimized for size.
=20

Signed-off-by Rog=E9rio Brito <[email protected]>

=20
---
=20
I have been using kernels optimized for size on my Kurobox (standard) for many different releases and I have experienced no problem with this option enabled. Thus, this patch.

=20
--- linux/arch/powerpc/configs/linkstation_defconfig.old=092008-10-13 00:=

+++ linux/arch/powerpc/configs/linkstation_defconfig=092008-10-13 00:38:5=

(quoted diff) +1 -1

@@ -90,7 +90,7 @@ CONFIG_NAMESPACES=3Dy
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=3Dy
 CONFIG_INITRAMFS_SOURCE=3D""
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=3Dy
 CONFIG_SYSCTL=3Dy
 # CONFIG_EMBEDDED is not set
 CONFIG_SYSCTL_SYSCALL=3Dy

=20
=20
--=20

Rog=E9rio Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
=20

Quoted 10 lines · Rogério Brito

From: Rogério Brito <[email protected]>

Since Linkstations and Kuroboxes often have *very* little memory (as they are embedded systems), it is desirable to get their kernels compiled optimized for size.

Signed-off-by Rogério Brito <[email protected]>

---

Quoted 3 lines

I have been using kernels optimized for size on my Kurobox (standard) for many different releases and I have experienced no problem with this option enabled. Thus, this patch.

The comment for this option says: "watch out for broken compilers," if this doesn't hold any more, it should be remove, if it still holds, I wouldn't turn this on by default, as I don't think we can test all

possible (cross- or native-) compilers users might want to use. In any case this is one of options that users can select themselves, if it suits them.

From: Rogério Brito <[email protected]>

Since Linkstations and Kuroboxes often have *very* little memory (as they are embedded systems), it is desirable to get their kernels compiled optimized for size.

Signed-off-by Rogério Brito <[email protected]>

---

I have been using kernels optimized for size on my Kurobox (standard) for many different releases and I have experienced no problem with this option enabled. Thus, this patch.

arch/powerpc/configs/linkstation_defconfig renamed from arch/powerpc/configs/linkstation_defconfig.old +1 -1

@@ -90,7 +90,7 @@ CONFIG_NAMESPACES=y
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_SYSCTL=y
 # CONFIG_EMBEDDED is not set
 CONFIG_SYSCTL_SYSCALL=y

Signature · 4 lines

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

From: Rog=E9rio Brito <[email protected]>

Since Linkstations and Kuroboxes often have *very* little memory (as they are embedded systems), it is desirable to get their kernels compiled optimized for size.

Signed-off-by Rog=E9rio Brito <[email protected]>

---