Fix the problem that large physical address support cannot be
disabled when some platforms which only provides 36-bit support
are selected. According to the philosophy of kernel config
enabling a platform support doesn't mean the kernel is only
running on that platform. Remove the auto selection of PHYS_64BIT
option for these platforms. They will need to use a 36bit default
config that selects PHYS_64BIT explicitly.
The reason why we need to keep PHYS_64BIT option configurable is
that enabling it cause negative performance impact on various
aspects like TLB miss and physical address manipulating. We should
not enable it unless really needed, e.g. use large memory of 4GB
or bigger.
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/platforms/85xx/Kconfig | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
This default config should be used by platforms that only
provides 36-bit software support in tree, such as P3041DS,
P3060QDS, P4080DS, P5020DS, and etc.
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/configs/corenet36_smp_defconfig | 185 ++++++++++++++++++++++++++
1 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/corenet36_smp_defconfig
@@ -0,0 +1,185 @@+CONFIG_PPC_85xx=y+CONFIG_PHYS_64BIT=y+CONFIG_SMP=y+CONFIG_NR_CPUS=8+CONFIG_EXPERIMENTAL=y+CONFIG_SYSVIPC=y+CONFIG_POSIX_MQUEUE=y+CONFIG_BSD_PROCESS_ACCT=y+CONFIG_AUDIT=y+CONFIG_SPARSE_IRQ=y+CONFIG_RCU_TRACE=y+CONFIG_IKCONFIG=y+CONFIG_IKCONFIG_PROC=y+CONFIG_LOG_BUF_SHIFT=14+CONFIG_BLK_DEV_INITRD=y+CONFIG_KALLSYMS_ALL=y+CONFIG_EMBEDDED=y+CONFIG_PERF_EVENTS=y+CONFIG_SLAB=y+CONFIG_MODULES=y+CONFIG_MODULE_UNLOAD=y+CONFIG_MODULE_FORCE_UNLOAD=y+CONFIG_MODVERSIONS=y+# CONFIG_BLK_DEV_BSG is not set+CONFIG_P2041_RDB=y+CONFIG_P3041_DS=y+CONFIG_P3060_QDS=y+CONFIG_P4080_DS=y+CONFIG_P5020_DS=y+CONFIG_HIGHMEM=y+CONFIG_NO_HZ=y+CONFIG_HIGH_RES_TIMERS=y+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set+CONFIG_BINFMT_MISC=m+CONFIG_KEXEC=y+CONFIG_FORCE_MAX_ZONEORDER=13+CONFIG_FSL_LBC=y+CONFIG_PCI=y+CONFIG_PCIEPORTBUS=y+# CONFIG_PCIEASPM is not set+CONFIG_RAPIDIO=y+CONFIG_FSL_RIO=y+CONFIG_NET=y+CONFIG_PACKET=y+CONFIG_UNIX=y+CONFIG_XFRM_USER=y+CONFIG_XFRM_SUB_POLICY=y+CONFIG_XFRM_STATISTICS=y+CONFIG_NET_KEY=y+CONFIG_NET_KEY_MIGRATE=y+CONFIG_INET=y+CONFIG_IP_MULTICAST=y+CONFIG_IP_ADVANCED_ROUTER=y+CONFIG_IP_MULTIPLE_TABLES=y+CONFIG_IP_ROUTE_MULTIPATH=y+CONFIG_IP_ROUTE_VERBOSE=y+CONFIG_IP_PNP=y+CONFIG_IP_PNP_DHCP=y+CONFIG_IP_PNP_BOOTP=y+CONFIG_IP_PNP_RARP=y+CONFIG_NET_IPIP=y+CONFIG_IP_MROUTE=y+CONFIG_IP_PIMSM_V1=y+CONFIG_IP_PIMSM_V2=y+CONFIG_ARPD=y+CONFIG_INET_AH=y+CONFIG_INET_ESP=y+CONFIG_INET_IPCOMP=y+# CONFIG_INET_LRO is not set+CONFIG_IPV6=y+CONFIG_IP_SCTP=m+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"+CONFIG_MTD=y+CONFIG_MTD_CMDLINE_PARTS=y+CONFIG_MTD_CHAR=y+CONFIG_MTD_BLOCK=y+CONFIG_MTD_CFI=y+CONFIG_MTD_CFI_AMDSTD=y+CONFIG_MTD_PHYSMAP_OF=y+CONFIG_MTD_M25P80=y+CONFIG_PROC_DEVICETREE=y+CONFIG_BLK_DEV_LOOP=y+CONFIG_BLK_DEV_RAM=y+CONFIG_BLK_DEV_RAM_SIZE=131072+CONFIG_MISC_DEVICES=y+CONFIG_BLK_DEV_SD=y+CONFIG_CHR_DEV_ST=y+CONFIG_BLK_DEV_SR=y+CONFIG_CHR_DEV_SG=y+CONFIG_SCSI_MULTI_LUN=y+CONFIG_SCSI_LOGGING=y+CONFIG_SCSI_SYM53C8XX_2=y+CONFIG_ATA=y+CONFIG_SATA_AHCI=y+CONFIG_SATA_FSL=y+CONFIG_SATA_SIL24=y+CONFIG_SATA_SIL=y+CONFIG_PATA_SIL680=y+CONFIG_NETDEVICES=y+CONFIG_FSL_PQ_MDIO=y+CONFIG_E1000=y+CONFIG_E1000E=y+CONFIG_VITESSE_PHY=y+CONFIG_FIXED_PHY=y+# CONFIG_INPUT_MOUSEDEV is not set+# CONFIG_INPUT_KEYBOARD is not set+# CONFIG_INPUT_MOUSE is not set+CONFIG_SERIO_LIBPS2=y+# CONFIG_LEGACY_PTYS is not set+CONFIG_PPC_EPAPR_HV_BYTECHAN=y+CONFIG_SERIAL_8250=y+CONFIG_SERIAL_8250_CONSOLE=y+CONFIG_SERIAL_8250_EXTENDED=y+CONFIG_SERIAL_8250_MANY_PORTS=y+CONFIG_SERIAL_8250_DETECT_IRQ=y+CONFIG_SERIAL_8250_RSA=y+CONFIG_HW_RANDOM=y+CONFIG_NVRAM=y+CONFIG_I2C=y+CONFIG_I2C_MPC=y+CONFIG_SPI=y+CONFIG_SPI_GPIO=y+CONFIG_SPI_FSL_SPI=y+CONFIG_SPI_FSL_ESPI=y+# CONFIG_HWMON is not set+CONFIG_VIDEO_OUTPUT_CONTROL=y+CONFIG_USB_HID=m+CONFIG_USB=y+CONFIG_USB_DEVICEFS=y+CONFIG_USB_MON=y+CONFIG_USB_EHCI_HCD=y+CONFIG_USB_EHCI_FSL=y+CONFIG_USB_OHCI_HCD=y+CONFIG_USB_OHCI_HCD_PPC_OF_BE=y+CONFIG_USB_OHCI_HCD_PPC_OF_LE=y+CONFIG_USB_STORAGE=y+CONFIG_MMC=y+CONFIG_MMC_SDHCI=y+CONFIG_EDAC=y+CONFIG_EDAC_MM_EDAC=y+CONFIG_EDAC_MPC85XX=y+CONFIG_RTC_CLASS=y+CONFIG_RTC_DRV_DS3232=y+CONFIG_RTC_DRV_CMOS=y+CONFIG_UIO=y+CONFIG_STAGING=y+CONFIG_VIRT_DRIVERS=y+CONFIG_FSL_HV_MANAGER=y+CONFIG_EXT2_FS=y+CONFIG_EXT3_FS=y+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set+CONFIG_ISO9660_FS=m+CONFIG_JOLIET=y+CONFIG_ZISOFS=y+CONFIG_UDF_FS=m+CONFIG_MSDOS_FS=m+CONFIG_VFAT_FS=y+CONFIG_NTFS_FS=y+CONFIG_PROC_KCORE=y+CONFIG_TMPFS=y+CONFIG_HUGETLBFS=y+CONFIG_JFFS2_FS=y+CONFIG_CRAMFS=y+CONFIG_NFS_FS=y+CONFIG_NFS_V3=y+CONFIG_NFS_V4=y+CONFIG_ROOT_NFS=y+CONFIG_NFSD=m+CONFIG_PARTITION_ADVANCED=y+CONFIG_MAC_PARTITION=y+CONFIG_NLS_ISO8859_1=y+CONFIG_NLS_UTF8=m+CONFIG_MAGIC_SYSRQ=y+CONFIG_DEBUG_SHIRQ=y+CONFIG_DETECT_HUNG_TASK=y+CONFIG_DEBUG_INFO=y+CONFIG_SYSCTL_SYSCALL_CHECK=y+CONFIG_CRYPTO_NULL=y+CONFIG_CRYPTO_PCBC=m+CONFIG_CRYPTO_MD4=y+CONFIG_CRYPTO_SHA256=y+CONFIG_CRYPTO_SHA512=y+CONFIG_CRYPTO_AES=y+# CONFIG_CRYPTO_ANSI_CPRNG is not set+CONFIG_CRYPTO_DEV_FSL_CAAM=y
From: Tabi Timur-B04825 <hidden> Date: 2012-02-16 15:58:04
On Thu, Feb 16, 2012 at 9:56 AM, Tabi Timur-B04825 [off-list ref] w=
rote:
I think we should make 36-bit the only option for the upstream
defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
then we provide that on the SDK only.
Oops, I meant to post this as a reply to "powerpc/85xx: add a 36-bit
corenet default config".
--=20
Timur Tabi
Linux kernel developer at Freescale=
From: Tabi Timur-B04825 <hidden> Date: 2012-02-16 15:58:42
On Thu, Feb 16, 2012 at 6:10 AM, Li Yang [off-list ref] wrote:
The reason why we need to keep PHYS_64BIT option configurable is
that enabling it cause negative performance impact on various
aspects like TLB miss and physical address manipulating. =A0We should
not enable it unless really needed, e.g. use large memory of 4GB
or bigger.
I think we should make 36-bit the only option for the upstream
defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
then we provide that on the SDK only.
--=20
Timur Tabi
Linux kernel developer at Freescale=
From: Kumar Gala <hidden> Date: 2012-02-17 01:27:46
On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
Fix the problem that large physical address support cannot be
disabled when some platforms which only provides 36-bit support
are selected. According to the philosophy of kernel config
enabling a platform support doesn't mean the kernel is only
running on that platform. Remove the auto selection of PHYS_64BIT
option for these platforms. They will need to use a 36bit default
config that selects PHYS_64BIT explicitly.
=20
The reason why we need to keep PHYS_64BIT option configurable is
that enabling it cause negative performance impact on various
aspects like TLB miss and physical address manipulating. We should
not enable it unless really needed, e.g. use large memory of 4GB
or bigger.
=20
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/platforms/85xx/Kconfig | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
Nak, this isn't correct.
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and =
the device tree. This was a decision that was made to NOT support =
32-bit address map for these boards and accept the performance =
implication of it to reduce the # of builds, etc.
Additionally, outside of maybe P2041RDB I believe the majority of these =
boards ship with 4G of DDR (but that off the top of my head) and thus =
require the 36-bit / PHYS_64BIT support to be enabled.
- k
From: Li Yang-R58472 <hidden> Date: 2012-02-17 04:33:01
Subject: Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents
PHYS_64BIT from configurable
On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
quoted
Fix the problem that large physical address support cannot be disabled
when some platforms which only provides 36-bit support are selected.
According to the philosophy of kernel config enabling a platform
support doesn't mean the kernel is only running on that platform.
Remove the auto selection of PHYS_64BIT option for these platforms.
They will need to use a 36bit default config that selects PHYS_64BIT
explicitly.
The reason why we need to keep PHYS_64BIT option configurable is that
enabling it cause negative performance impact on various aspects like
TLB miss and physical address manipulating. We should not enable it
unless really needed, e.g. use large memory of 4GB or bigger.
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/platforms/85xx/Kconfig | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
Nak, this isn't correct.
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, &
P5020DS only a 36-bit physical address map is supported by u-boot and the
device tree. This was a decision that was made to NOT support 32-bit
address map for these boards and accept the performance implication of it
to reduce the # of builds, etc.
Ok. Although personally I don't think # of builds matters that much.
Additionally, outside of maybe P2041RDB I believe the majority of these
boards ship with 4G of DDR (but that off the top of my head) and thus
require the 36-bit / PHYS_64BIT support to be enabled.
I know that current support of DPAA boards requires 36-bit. But I don't th=
ink they need to select the PHYS_64BIT option directly and make it not conf=
igurable. It's conflicting with the logic that enabling a platform support=
doesn't mean the kernel is only running on that platform. Btw: what's you=
r recommendations on solving this?
- Leo
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-02-17 08:42:35
On Thu, 2012-02-16 at 20:10 +0800, Li Yang wrote:
Fix the problem that large physical address support cannot be
disabled when some platforms which only provides 36-bit support
are selected. According to the philosophy of kernel config
enabling a platform support doesn't mean the kernel is only
running on that platform. Remove the auto selection of PHYS_64BIT
option for these platforms. They will need to use a 36bit default
config that selects PHYS_64BIT explicitly.
No, but unless I'm wrong, with your patch, enabling those platforms will
build the code ... but they won't work unless you -also- enable
PHYS_64BIT one way or another. I thus disagree.
If I enable CONFIG_P1022_DS, I expect those boards to work.
If that's going to negatively impact perfs on other boards that I also
enabled, then so be it (and we should document it in the help text).
Cheers,
Ben.
quoted hunk
The reason why we need to keep PHYS_64BIT option configurable is
that enabling it cause negative performance impact on various
aspects like TLB miss and physical address manipulating. We should
not enable it unless really needed, e.g. use large memory of 4GB
or bigger.
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/platforms/85xx/Kconfig | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-02-17 08:43:43
On Fri, 2012-02-17 at 04:32 +0000, Li Yang-R58472 wrote:
quoted
Additionally, outside of maybe P2041RDB I believe the majority of
these
quoted
boards ship with 4G of DDR (but that off the top of my head) and thus
require the 36-bit / PHYS_64BIT support to be enabled.
I know that current support of DPAA boards requires 36-bit. But I
don't think they need to select the PHYS_64BIT option directly and
make it not configurable. It's conflicting with the logic that
enabling a platform support doesn't mean the kernel is only running on
that platform. Btw: what's your recommendations on solving this?
But selecting PHYS_64BIT shouldn't prevent running on the other
platforms. If it does, then this needs to be fixed.
Cheers,
Ben.
From: Tabi Timur-B04825 <hidden> Date: 2012-02-17 16:22:31
On Thu, Feb 16, 2012 at 7:27 PM, Kumar Gala [off-list ref] wro=
te:
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and the d=
evice tree. =A0This was a decision that was made to NOT support 32-bit addr=
ess map for these boards and accept the performance implication of it to re=
duce the # of builds, etc.
Was this a Freescale internal decision, or is this a generic 85xx decision?
For the record, I'm in favor in leaving out support for 32-bit address
map in the upstream kernel, and having it be an option on the SDK
only. However, in order to do that, we cannot have "select
PHYS_64BIT" in the Kconfigs. It needs to be in the defconfigs
instead. Putting it in the defconfig will eliminate the need to have
it in every Kconfig block, so I think that's an improvement.
Then the SDK can include a defconfig that does not have PHYS_64BIT
defined. And the SDK can include 32-bit U-Boots and 32-bit device
trees for any board where Freescale determines there is a need.
I think Leo's patch simplifies things for everyone.
--=20
Timur Tabi
Linux kernel developer at Freescale=
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-02-17 21:10:48
On Fri, 2012-02-17 at 16:22 +0000, Tabi Timur-B04825 wrote:
Was this a Freescale internal decision, or is this a generic 85xx
decision?
For the record, I'm in favor in leaving out support for 32-bit address
map in the upstream kernel, and having it be an option on the SDK
only. However, in order to do that, we cannot have "select
PHYS_64BIT" in the Kconfigs. It needs to be in the defconfigs
instead. Putting it in the defconfig will eliminate the need to have
it in every Kconfig block, so I think that's an improvement.
Then the SDK can include a defconfig that does not have PHYS_64BIT
defined. And the SDK can include 32-bit U-Boots and 32-bit device
trees for any board where Freescale determines there is a need.
I think Leo's patch simplifies things for everyone.
Sorry, I fail to see how... it basically makes all those boards
non-functional even when enabled...
What's wrong with the current scheme ?
Ben.
From: Timur Tabi <hidden> Date: 2012-02-17 21:18:04
Benjamin Herrenschmidt wrote:
Sorry, I fail to see how... it basically makes all those boards
non-functional even when enabled...
So you're saying that if we allow 32-bit address spacing for a particular
board, then we must provide a 32-bit DTS to go with it?
I was hoping to use the defconfig to force 36-bit, so that we can have a
32-bit option if we want. Just because we don't put a 32-bit DTS in the
upstream kernel, that doesn't mean that no one is allowed to have a 32-bit
kernel.
What's wrong with the current scheme ?
It prevents the possibility of creating an "optimized" 32-bit address
environment, for people who have <= 2GB of DDR on the board. If we want
to ship a 32-bit DTS and 32-bit U-Boot on our BSP, then we'll need to
patch the Kconfig to remove the "select" line.
--
Timur Tabi
Linux kernel developer at Freescale
From: Timur Tabi <hidden> Date: 2012-02-17 23:01:16
So I noticed something else. PHYS_64BIT is not defined in
mpc85xx_smp_defconfig. This means that if we want to build a 36-bit
kernel, we need to have "select PHYS_64BIT" in the Kconfig for that board.
This is what we have today for the P1022DS.
However, that select statement also means that we can't build a 32-bit
kernel. This is a problem for mpc85xx_defconfig, because that defconfig
includes support for the MPC8540ADS. The 8540 has an e500v1 core which
doesn't support MAS7 (i.e. no 36-bit physical addresses).
So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
board must also turn on that option in the defconfig. The patches from me
and Leo don't do that.
--
Timur Tabi
Linux kernel developer at Freescale
From: Scott Wood <hidden> Date: 2012-02-18 00:56:34
On 02/17/2012 05:01 PM, Timur Tabi wrote:
So I noticed something else. PHYS_64BIT is not defined in
mpc85xx_smp_defconfig.
It couldn't have been, since it was selected by another kconfig option.
defconfigs only hold non-default options.
However, that select statement also means that we can't build a 32-bit
kernel. This is a problem for mpc85xx_defconfig, because that defconfig
includes support for the MPC8540ADS. The 8540 has an e500v1 core which
doesn't support MAS7 (i.e. no 36-bit physical addresses).
It's not a problem for 8540, just lost optimization potential.
So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
board must also turn on that option in the defconfig. The patches from me
and Leo don't do that.
Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.
The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.
-Scott
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-02-18 02:20:36
On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.
The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.
Don't we have CONFIG_EMBEDDED to make that sort of option visible ?
Cheers,
Ben.
From: Scott Wood <hidden> Date: 2012-02-20 20:30:40
On 02/17/2012 08:19 PM, Benjamin Herrenschmidt wrote:
On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
quoted
Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.
The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.
Don't we have CONFIG_EMBEDDED to make that sort of option visible ?
OK, so:
config WANT_PHYS_64BIT
select PHYS_64BIT if !EMBEDDED
config PHYS_64BIT
default y if WANT_PHYS_64BIT
...and "select WANT_PHYS_64BIT" on boards that normally have 36-bit
address maps?
What about 86xx? It looks like PHYS_64BIT can't be enabled if it's
sharing a kernel image with 82xx or 83xx (why these specific SoCs but
not 603 in general?).
-Scott