From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-09 14:24:42
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Makefile | 5 +++++
arch/powerpc/configs/book3s_32.config | 2 ++
2 files changed, 7 insertions(+)
create mode 100644 arch/powerpc/configs/book3s_32.config
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-09 14:24:43
Similarly as we just did for 32-bit, add phony targets for generating
a little endian and Book3E allmodconfig. These aren't covered by the
regular allmodconfig, which is big endian and Book3S due to the way
the Kconfig symbols are structured.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Makefile | 10 ++++++++++
1 file changed, 10 insertions(+)
On Mon, Jul 9, 2018 at 4:24 PM Michael Ellerman [off-list ref] wrote:
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-10 13:47:22
Mathieu Malaterre [off-list ref] writes:
On Mon, Jul 9, 2018 at 4:24 PM Michael Ellerman [off-list ref] wrote:
quoted
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Ok then.
That was just me taking a stab in the dark. You suggested we should
mimic the Debian config, what does that use?
I this a good time to update line 34 at the same time:
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
?
34 or 36?
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
else
KBUILD_DEFCONFIG := ppc64_defconfig
endif
Do you mean the else case?
cheers
On Tue, Jul 10, 2018 at 3:47 PM Michael Ellerman [off-list ref] wrote:
Mathieu Malaterre [off-list ref] writes:
quoted
On Mon, Jul 9, 2018 at 4:24 PM Michael Ellerman [off-list ref] wrote:
quoted
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Ok then.
That was just me taking a stab in the dark. You suggested we should
mimic the Debian config, what does that use?
Sorry got confused for a minute. This is the correct value (at least
the one used in Debian).
I this a good time to update line 34 at the same time:
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
?
34 or 36?
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
else
KBUILD_DEFCONFIG := ppc64_defconfig
endif
Do you mean the else case?
As far as I know uname -m on powerpc returns 'ppc' so the following
has always failed from a ppc32be machine:
$ make ARCH=powerpc defconfig
I was simply suggesting to mimic what was done for ppc64:
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := ppc32_defconfig
else
KBUILD_DEFCONFIG := ppc64_defconfig
endif
If I followed the discussion one would want the file `ppc32_defconfig`
to contains pretty much the same thing as the .config generated from
`book3s_32.config`, right ?
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-11 13:50:27
Mathieu Malaterre [off-list ref] writes:
On Tue, Jul 10, 2018 at 3:47 PM Michael Ellerman [off-list ref] wrote:
quoted
Mathieu Malaterre [off-list ref] writes:
quoted
On Mon, Jul 9, 2018 at 4:24 PM Michael Ellerman [off-list ref] wrote:
quoted
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Ok then.
That was just me taking a stab in the dark. You suggested we should
mimic the Debian config, what does that use?
Sorry got confused for a minute. This is the correct value (at least
the one used in Debian).
I this a good time to update line 34 at the same time:
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
?
34 or 36?
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
else
KBUILD_DEFCONFIG := ppc64_defconfig
endif
Do you mean the else case?
As far as I know uname -m on powerpc returns 'ppc' so the following
has always failed from a ppc32be machine:
Oh yep it does.
I've never built a kernel *on* a 32-bit machine ;)
$ make ARCH=powerpc defconfig
I was simply suggesting to mimic what was done for ppc64:
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := ppc32_defconfig
else
KBUILD_DEFCONFIG := ppc64_defconfig
endif
That wouldn't work, CROSS_COMPILE isn't a ppc/ppc64 thing.
In fact setting CROSS_COMPILE doesn't actually mean you're cross
compiling, it just means you're using a different toolchain. I do that
all the time, because I want to use a specific version of GCC, not the
distro one.
What about:
We obviously need a ppc32_defconfig to make that work.
If I followed the discussion one would want the file `ppc32_defconfig`
to contains pretty much the same thing as the .config generated from
`book3s_32.config`, right ?
Can you boot the resulting kernel if you build ppc32_allmodconfig ?
Maybe we should just make that be ppc32_defconfig.
cheers
From: Randy Dunlap <hidden> Date: 2018-07-14 01:59:51
On 07/09/2018 07:24 AM, Michael Ellerman wrote:
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most com
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Hi Michael,
Sorry for the delay. I was traveling (out in the boonies).
I'm trying to use 'make ppc32_allmodconfig'. Cross-building on x86_64
with crosstools from kernel.org. (gcc 8.1.0)
I'm getting build errors. Looks like it's missing a header file or 3.
I looked into that but it's a long and twisty maze of passages.
Any ideas?
CC arch/powerpc/mm/dump_linuxpagetables.o
In file included from ../arch/powerpc/include/asm/book3s/pgtable.h:8,
from ../arch/powerpc/include/asm/pgtable.h:18,
from ../include/linux/hugetlb.h:12,
from ../arch/powerpc/mm/dump_linuxpagetables.c:19:
../arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers':
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: error: 'PKMAP_BASE' undeclared (first use in this function); did you mean 'AT_BASE'?
#define KVIRT_TOP PKMAP_BASE
^~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of macro 'KVIRT_TOP'
#define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
^~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 'IOREMAP_TOP'
address_markers[i++].start_address = IOREMAP_TOP;
^~~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: note: each undeclared identifier is reported only once for each function it appears in
#define KVIRT_TOP PKMAP_BASE
^~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of macro 'KVIRT_TOP'
#define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
^~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 'IOREMAP_TOP'
address_markers[i++].start_address = IOREMAP_TOP;
^~~~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:464:39: error: implicit declaration of function 'PKMAP_ADDR'; did you mean 'PCI_IO_ADDR'? [-Werror=implicit-function-declaration]
address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
^~~~~~~~~~
PCI_IO_ADDR
../arch/powerpc/mm/dump_linuxpagetables.c:464:50: error: 'LAST_PKMAP' undeclared (first use in this function); did you mean 'LIST_HEAD'?
address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
^~~~~~~~~~
LIST_HEAD
Thanks.
From: Randy Dunlap <hidden> Date: 2018-07-14 04:35:43
On 07/09/2018 07:24 AM, Michael Ellerman wrote:
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Hi Michael,
ppc32_allmodconfig sets CONFIG_ISA=y (and other related symbols) and
CONFIG_PPC_CHRP=y. But my builds are failing because they are missing
the functions isa_bus_to_virt() and isa_virt_to_bus().
Any ideas?
Thanks.
From: Randy Dunlap <hidden> Date: 2018-07-15 19:40:51
On 07/09/18 07:24, Michael Ellerman wrote:
Similarly as we just did for 32-bit, add phony targets for generating
a little endian and Book3E allmodconfig. These aren't covered by the
regular allmodconfig, which is big endian and Book3S due to the way
the Kconfig symbols are structured.
[adding Felipe Balbi]
Is book3e allmodconfig not seen/used very much?
Besides the patches that I have already sent, I am seeing a build problem
with ppc64_book3e_allmodconfig, where we have:
CONFIG_USB_PHY=y
CONFIG_FSL_USB2_OTG=y
but
CONFIG_USB_OTG_FSM=m
In drivers/usb/phy/Kconfig, FSL_USB2_OTG depends on USB_OTG_FSM (among
other things), but! FSL_USB2_OTG is a bool symbol, depending on a
tristate symbol. This often causes problems. In this case it causes errors
with a builtin driver trying to use symbols that are built in a loadable module:
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_ioctl':
phy-fsl-usb.c:(.text.fsl_otg_ioctl+0xb4): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_start_srp':
phy-fsl-usb.c:(.text.fsl_otg_start_srp+0x4c): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_set_host':
phy-fsl-usb.c:(.text.fsl_otg_set_host+0xd0): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_start_hnp':
phy-fsl-usb.c:(.text.fsl_otg_start_hnp+0x68): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.show_fsl_usb2_otg_state':
phy-fsl-usb.c:(.text.show_fsl_usb2_otg_state+0x154): undefined reference to `.usb_otg_state_string'
drivers/usb/phy/phy-fsl-usb.o: In function `.a_wait_enum':
(.text.a_wait_enum+0x4c): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_set_peripheral':
phy-fsl-usb.c:(.text.fsl_otg_set_peripheral+0x84): undefined reference to `.usb_gadget_vbus_disconnect'
phy-fsl-usb.c:(.text.fsl_otg_set_peripheral+0x9c): undefined reference to `.otg_statemachine'
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-20 11:51:38
Hi Randy,
Randy Dunlap [off-list ref] writes:
On 07/09/18 07:24, Michael Ellerman wrote:
quoted
Similarly as we just did for 32-bit, add phony targets for generating
a little endian and Book3E allmodconfig. These aren't covered by the
regular allmodconfig, which is big endian and Book3S due to the way
the Kconfig symbols are structured.
[adding Felipe Balbi]
Is book3e allmodconfig not seen/used very much?
Seems so :)
Besides the patches that I have already sent, I am seeing a build problem
with ppc64_book3e_allmodconfig, where we have:
CONFIG_USB_PHY=y
CONFIG_FSL_USB2_OTG=y
but
CONFIG_USB_OTG_FSM=m
In drivers/usb/phy/Kconfig, FSL_USB2_OTG depends on USB_OTG_FSM (among
other things), but! FSL_USB2_OTG is a bool symbol, depending on a
tristate symbol. This often causes problems. In this case it causes errors
with a builtin driver trying to use symbols that are built in a loadable module:
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_ioctl':
phy-fsl-usb.c:(.text.fsl_otg_ioctl+0xb4): undefined reference to `.otg_statemachine'
@@ -21,7 +21,7 @@ config AB8500_USBconfigFSL_USB2_OTGbool"Freescale USB OTG Transceiver Driver"-depends onUSB_EHCI_FSL&&USB_FSL_USB2&&USB_OTG_FSM&&PM+depends onUSB_EHCI_FSL&&USB_FSL_USB2&&USB_OTG_FSM=y&&PMdepends onUSB_GADGET||!USB_GADGET# if USB_GADGET=m, this can't be 'y'selectUSB_PHYhelp
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-20 11:58:20
Randy Dunlap [off-list ref] writes:
On 07/09/2018 07:24 AM, Michael Ellerman wrote:
quoted
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most com
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Hi Michael,
Sorry for the delay. I was traveling (out in the boonies).
I'm trying to use 'make ppc32_allmodconfig'. Cross-building on x86_64
with crosstools from kernel.org. (gcc 8.1.0)
I'm getting build errors. Looks like it's missing a header file or 3.
I looked into that but it's a long and twisty maze of passages.
Any ideas?
Urk.
That code was really written for 64-bit and we haven't ever quite made
it fully generic, as you can see.
Christophe got it working for 8xx (a different 32-bit variant), but
clearly it doesn't work for this config.
This might be the solution for now:
@@ -362,6 +362,7 @@ config FAIL_IOMMUconfigPPC_PTDUMPbool"Export kernel pagetable layout to userspace via debugfs"depends onDEBUG_KERNEL&&DEBUG_FS+depends onPPC64||PPC_8xxhelpThisoptionexportsthestateofthekernelpagetablestoadebugfsfile.Thisisonlyusefulforkerneldeveloperswhoare
cheers
CC arch/powerpc/mm/dump_linuxpagetables.o
In file included from ../arch/powerpc/include/asm/book3s/pgtable.h:8,
from ../arch/powerpc/include/asm/pgtable.h:18,
from ../include/linux/hugetlb.h:12,
from ../arch/powerpc/mm/dump_linuxpagetables.c:19:
../arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers':
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: error: 'PKMAP_BASE' undeclared (first use in this function); did you mean 'AT_BASE'?
#define KVIRT_TOP PKMAP_BASE
^~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of macro 'KVIRT_TOP'
#define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
^~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 'IOREMAP_TOP'
address_markers[i++].start_address = IOREMAP_TOP;
^~~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: note: each undeclared identifier is reported only once for each function it appears in
#define KVIRT_TOP PKMAP_BASE
^~~~~~~~~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of macro 'KVIRT_TOP'
#define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
^~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 'IOREMAP_TOP'
address_markers[i++].start_address = IOREMAP_TOP;
^~~~~~~~~~~
../arch/powerpc/mm/dump_linuxpagetables.c:464:39: error: implicit declaration of function 'PKMAP_ADDR'; did you mean 'PCI_IO_ADDR'? [-Werror=implicit-function-declaration]
address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
^~~~~~~~~~
PCI_IO_ADDR
../arch/powerpc/mm/dump_linuxpagetables.c:464:50: error: 'LAST_PKMAP' undeclared (first use in this function); did you mean 'LIST_HEAD'?
address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
^~~~~~~~~~
LIST_HEAD
Thanks.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-07-20 12:18:24
Randy Dunlap [off-list ref] writes:
On 07/09/2018 07:24 AM, Michael Ellerman wrote:
quoted
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Hi Michael,
ppc32_allmodconfig sets CONFIG_ISA=y (and other related symbols) and
CONFIG_PPC_CHRP=y. But my builds are failing because they are missing
the functions isa_bus_to_virt() and isa_virt_to_bus().
Any ideas?
It's old legacy cruft that we've never implemented :)
I don't know if it's possible to implement it for CHRP, Ben implied it
might be, back in 2009:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073232.html
But of course nothing came of it.
It looks like there's only a handful of drivers left using them, we
should probably just mark them as not buildable on PPC.
Arnd did something similar for ARM in:
e9b106b8fbdb ("net: lance,ni64: don't build for ARM")
cheers
From: Michael Ellerman <hidden> Date: 2018-07-24 13:59:56
On Mon, 2018-07-09 at 14:24:25 UTC, Michael Ellerman wrote:
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has several mutually exclusive CPU types, we choose
the Book3S variants as that's what the help text in Kconfig says is
most common.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>