Re: [PATCH v4 1/2] binfmt_flat: allow not offsetting data start
On 17/4/21 2:54 pm, Damien Le Moal wrote:
On 2021/04/17 13:52, Greg Ungerer wrote:
On 17/4/21 11:10 am, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request no data start offset to allow for
contiguous text and data sections for binaries flagged with
FLAT_FLAG_RAM, introduce the new config option
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET. Using this new option, the
macro DATA_START_OFFSET_WORDS is conditionally defined in binfmt_flat.c
to MAX_SHARED_LIBS for architectures tolerating or needing the data
start offset (CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET disabled case)
and to 0 when CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET is enabled.
DATA_START_OFFSET_WORDS is used in load_flat_file() to calculate the
data section length and start position.
Signed-off-by: Damien Le Moal
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..06fb7a93a1bd 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_DATA_START_OFFSET
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..1dc68dfba3e0 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET
+#define DATA_START_OFFSET_WORDS(0)
+#else
+#define DATA_START_OFFSET_WORDS(MAX_SHARED_LIBS)
+#endif
+
struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -560,6 +566,7 @@ static int load_flat_file(struct linux_binprm *bprm,
* it all together.
*/
if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+
Random white space change...
Don't worry about re-spinning though, I will just edit this chunk out.
Oops. Sorry about that. I should have better checked :)
/*
* this should give us a ROM ptr, but if it doesn't we don't
* really care
@@ -576,7 +583,8 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
+ len = data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -591,7 +599,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(unsigned long),
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long),
FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
@@ -622,7 +630,8 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
+ len = text_len + data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm,
realdatastart = textpos + ntohl(hdr->data_start);
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(u32),
+ DATA_START_OFFSET_WORDS * sizeof(u32),
FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
@@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm,
ret = result;
pr_err("Unable to read code+data+bss, errno %d\n", ret);
vm_munmap(textpos, text_len + data_len + ext
Re: [PATCH v4 2/2] riscv: Disable data start offset in flat binaries
On 17/4/21 11:10 am, Damien Le Moal wrote: uclibc/gcc combined with elf2flt riscv linker file fully resolve the PC relative __global_pointer$ value at compile time and do not generate a relocation entry to set a correct value of the gp register at runtime. As a result, if the flatbin loader offsets the start of the data section, the relative position change between the text and data sections compared to the compile time positions results in an incorrect gp value being used. This causes flatbin executables to crash. Avoid this problem by enabling CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET automatically when CONFIG_RISCV is enabled and CONFIG_MMU is disabled. Signed-off-by: Damien Le Moal Acked-by: Palmer Dabbelt Acked-by: Greg Ungerer Palmer do you want me to take this via my tree with 1/2 in the series, or are you going to pick it up? Regards Greg --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 4515a10c5d22..add528eb9235 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -33,6 +33,7 @@ config RISCV select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU select ARCH_WANT_FRAME_POINTERS select ARCH_WANT_HUGE_PMD_SHARE if 64BIT + select BINFMT_FLAT_NO_DATA_START_OFFSET if !MMU select CLONE_BACKWARDS select CLINT_TIMER if !MMU select COMMON_CLK
Re: [PATCH v4 1/2] binfmt_flat: allow not offsetting data start
On 17/4/21 11:10 am, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request no data start offset to allow for
contiguous text and data sections for binaries flagged with
FLAT_FLAG_RAM, introduce the new config option
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET. Using this new option, the
macro DATA_START_OFFSET_WORDS is conditionally defined in binfmt_flat.c
to MAX_SHARED_LIBS for architectures tolerating or needing the data
start offset (CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET disabled case)
and to 0 when CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET is enabled.
DATA_START_OFFSET_WORDS is used in load_flat_file() to calculate the
data section length and start position.
Signed-off-by: Damien Le Moal
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..06fb7a93a1bd 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_DATA_START_OFFSET
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..1dc68dfba3e0 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET
+#define DATA_START_OFFSET_WORDS(0)
+#else
+#define DATA_START_OFFSET_WORDS(MAX_SHARED_LIBS)
+#endif
+
struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -560,6 +566,7 @@ static int load_flat_file(struct linux_binprm *bprm,
* it all together.
*/
if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+
Random white space change...
Don't worry about re-spinning though, I will just edit this chunk out.
/*
* this should give us a ROM ptr, but if it doesn't we don't
* really care
@@ -576,7 +583,8 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
+ len = data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -591,7 +599,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(unsigned long),
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long),
FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
@@ -622,7 +630,8 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
+ len = text_len + data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm,
realdatastart = textpos + ntohl(hdr->data_start);
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(u32),
+ DATA_START_OFFSET_WORDS * sizeof(u32),
FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
@@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm,
ret = result;
pr_err("Unable to read code+data+bss, errno %d\n", ret);
vm_munmap(textpos, text_len + data_len + extra +
- MAX_SHARED_LIBS * sizeof(u32));
+ DATA_START_OFFSET_WORDS * sizeof(u32));
goto err;
}
}
Thanks, otherwi
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On 16/4/21 10:26 am, Damien Le Moal wrote:
On 2021/04/16 9:22, Al Viro wrote:
On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
binfmt_flat tends to go through Greg's uclinux tree, adding him and
the list.
FWIW, my involvement with binfmt_flat had been pretty much nil -
the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()
should be able to fail" about 4 years ago and that fell out of hunting
for places where __get_user() had been used without checking error values.
It's in fs/*, but I've no way to test it and I have pretty much
zero familiarity with the guts of that one, so I can't give any useful
feedback on that series. So consider the Christoph's comment seconded -
you want it reviewed by gerg et.al., and it probably ought to go via
gerg/uclinux.git tree.
I'm reasonably familiar with binfmt_{elf,misc,script}; anything
else gets touched as part of larger series and only with sanity checks
from other folks, if the changes are not entirely trivial.
Al,
Thanks for the clarification. Would it make sense to have an entry in
MAINTAINERS file pointing to Greg and the uclinux tree for binfmt_flat.c ?
Greg ?
Yep, looks like it does need that.
Regards
Greg
Re: [PATCH v3 1/2] binfmt_flat: allow not offsetting data start
On 16/4/21 9:22 am, Damien Le Moal wrote:
On 2021/04/15 23:04, Greg Ungerer wrote:
Hi Damien,
On 15/4/21 4:15 pm, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request contiguous text and data sections,
introduce the config option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP.
Using this new option, the macro DATA_GAP_WORDS is conditionally
defined in binfmt_flat.c to MAX_SHARED_LIBS for architectures
tolerating the text-to-data gap (CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
disabled case) and to 0 when CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP is
enabled. DATA_GAP_WORDS is used in load_flat_file() to calculate the
data section length and start position.
An architecture enabling CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP also
prevents the use of the separate text/data load case (when the flat file
header flags FLAT_FLAG_RAM and FLAT_FLAG_GZIP are not set with NOMMU
kernels) and forces the use of a single RAM region for loading
(equivalent to FLAT_FLAG_RAM being set).
So is it the case that a flat format file on RISC-V will never have
relocations?
No, it does have relocations. But there is no entry for the global pointer
(__global_pointer$) location. This is because the loading of that value in the
gp register in the C-library crt1.S is done using a PC-relative instruction. The
value for it is resolved at compile time and does not get a relocation table
entry. Other functions calls and symbol references do have relocation table
entries, so the binary can be loaded anywhere. The missing relocation for the
global pointer mandates that text and data be loaded at the same positions
relative to each other that the linker file defines. Otherwise, loading of
__global_pointer$ into the gp register (first thing that C libraries crt1.S do)
result in a garbage value being loaded.
I tried some tricks with the linker file and changing uclibc crt1.S to have the
gp loading done using a symbol address instead of a PC-relative offset. I could
then see a relocation table entry for that symbol. That still did not work as I
was probably doing something wrong. Anyway, such solution requires changing a
lot of things in C libraries loading assembler that is common between NOMMU and
MMU code. Changing it would break MMU enabled programs.
Signed-off-by: Damien Le Moal
Acked-by: Palmer Dabbelt
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 21 +++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..c6df931d5d45 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_TEXT_DATA_GAP
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..2be29bb964b8 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
+#define DATA_GAP_WORDS (0)
+#else
+#define DATA_GAP_WORDS (MAX_SHARED_LIBS)
+#endif
+> struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -559,7 +565,10 @@ static int load_flat_file(struct linux_binprm *bprm,
* case, and then the fully copied to RAM case which lumps
* it all together.
*/
- if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+ if (!IS_ENABLED(CONFIG_MMU) &&
+ !IS_ENABLED(CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP) &&
If RISC-V flat format files must always be loaded to RAM then why don't
they set the FLAT_FLAG_RAM when compiled/generated?
That is done. The patch I have for elf2flt sets it. Coding it like this here is
I think safer (whatever the userspace toolchain did, the kernel assumes
FLAT_FLAG_RAM). And it also has the nice side effect to suppress the first part
of the if () in the final binary. Smaller code size :)
My concern here is that CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GA being
enabled doesn't just in itself mean you need to force a RAM load.
It is just in the RISC-V case it currently does.
And it may change in the future. The considerable RAM savings
you get from supporting a separate data segment to code segment
means there is motivation to cr
Re: [PATCH v3 1/2] binfmt_flat: allow not offsetting data start
Hi Damien,
On 15/4/21 4:15 pm, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request contiguous text and data sections,
introduce the config option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP.
Using this new option, the macro DATA_GAP_WORDS is conditionally
defined in binfmt_flat.c to MAX_SHARED_LIBS for architectures
tolerating the text-to-data gap (CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
disabled case) and to 0 when CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP is
enabled. DATA_GAP_WORDS is used in load_flat_file() to calculate the
data section length and start position.
An architecture enabling CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP also
prevents the use of the separate text/data load case (when the flat file
header flags FLAT_FLAG_RAM and FLAT_FLAG_GZIP are not set with NOMMU
kernels) and forces the use of a single RAM region for loading
(equivalent to FLAT_FLAG_RAM being set).
So is it the case that a flat format file on RISC-V will never have
relocations?
Signed-off-by: Damien Le Moal
Acked-by: Palmer Dabbelt
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 21 +++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..c6df931d5d45 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_TEXT_DATA_GAP
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..2be29bb964b8 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP
+#define DATA_GAP_WORDS (0)
+#else
+#define DATA_GAP_WORDS (MAX_SHARED_LIBS)
+#endif
+> struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -559,7 +565,10 @@ static int load_flat_file(struct linux_binprm *bprm,
* case, and then the fully copied to RAM case which lumps
* it all together.
*/
- if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+ if (!IS_ENABLED(CONFIG_MMU) &&
+ !IS_ENABLED(CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP) &&
If RISC-V flat format files must always be loaded to RAM then why don't
they set the FLAT_FLAG_RAM when compiled/generated?
Regards
Greg
+ !(flags & (FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+
/*
* this should give us a ROM ptr, but if it doesn't we don't
* really care
@@ -576,7 +585,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
+ len = data_len + extra + DATA_GAP_WORDS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -591,7 +600,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(unsigned long),
+ DATA_GAP_WORDS * sizeof(unsigned long),
FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
@@ -622,7 +631,7 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
+ len = text_len + data_len + extra + DATA_GAP_WORDS *
sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm,
realdatastart = textpos + ntohl(hdr->data_start);
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(u32),
+ DATA_GAP_WORDS * sizeof(u32),
FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
@@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm,
[git pull] m68knommu fix for v5.12-rc7
Hi Linus, Please pull the m68knommu tree for-linus branch. It contains a single regression fix. Some m68k platforms with non-zero memory base fail to boot with recent flatmem changes. Sorry for getting this to you so late. I have been out on vacation and this slipped through the cracks. Regards Greg The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef: Linux 5.12-rc7 (2021-04-11 15:16:13 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.12-rc7 for you to fetch changes up to d2bd44c4c05d043fb65cfdf26c54e6d8b94a4b41: m68k: fix flatmem memory model setup (2021-04-12 09:34:26 +1000) Single regression fix: . fix pfn offset (stops booting on some platforms) Angelo Dureghello (1): m68k: fix flatmem memory model setup arch/m68k/include/asm/page_mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH 1/3] arm64: dts: ls1046a: mark crypto engine dma coherent
On 8/3/21 6:47 am, Horia Geantă wrote:
Crypto engine (CAAM) on LS1046A platform is configured HW-coherent,
mark accordingly the DT node.
As reported by Greg and Sascha, and explained by Robin, lack of
"dma-coherent" property for an IP that is configured HW-coherent
can lead to problems, e.g. on v5.11:
kernel BUG at drivers/crypto/caam/jr.c:247!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.11.0-20210225-3-00039-g434215968816-dirty #12
Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (C300) board (DT)
pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
pc : caam_jr_dequeue+0x98/0x57c
lr : caam_jr_dequeue+0x98/0x57c
sp : 800010003d50
x29: 800010003d50 x28: 8000118d4000
x27: 8000118d4328 x26: 01f0
x25: 0008022be480 x24: 0008022c6410
x23: 01f1 x22: 8000118d4329
x21: 4d80 x20: 01f1
x19: 0001 x18: 0020
x17: x16: 0015
x15: 800011690230 x14: 2e2e2e2e2e2e2e2e
x13: 2e2e2e2e2e2e2020 x12: 3030303030303030
x11: 800011700a38 x10: f000
x9 : 8000100ada30 x8 : 8000116a8a38
x7 : 0001 x6 :
x5 : x4 :
x3 : x2 :
x1 : x0 : 1800
Call trace:
caam_jr_dequeue+0x98/0x57c
tasklet_action_common.constprop.0+0x164/0x18c
tasklet_action+0x44/0x54
__do_softirq+0x160/0x454
__irq_exit_rcu+0x164/0x16c
irq_exit+0x1c/0x30
__handle_domain_irq+0xc0/0x13c
gic_handle_irq+0x5c/0xf0
el1_irq+0xb4/0x180
arch_cpu_idle+0x18/0x30
default_idle_call+0x3c/0x1c0
do_idle+0x23c/0x274
cpu_startup_entry+0x34/0x70
rest_init+0xdc/0xec
arch_call_rest_init+0x1c/0x28
start_kernel+0x4ac/0x4e4
Code: 91392021 912c2000 d377d8c6 97f24d96 (d421)
Cc: # v4.10+
Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
Link:
https://lore.kernel.org/linux-crypto/fe6faa24-d8f7-d18f-adfa-44fa0caa1...@arm.com
Reported-by: Greg Ungerer
Reported-by: Sascha Hauer
Tested-by: Sascha Hauer
Signed-off-by: Horia Geantă
Acked-by: Greg Ungerer
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index f581a6d1f881..37fec474673a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -354,6 +354,7 @@
ranges = <0x0 0x00 0x170 0x10>;
reg = <0x00 0x170 0x0 0x10>;
interrupts = ;
+ dma-coherent;
sec_jr0: jr@1 {
compatible = "fsl,sec-v5.4-job-ring",
[git pull] m68knommu changes for v5.12
Hi Linus, Please pull the m68knommu changes for v5.12. Only a single change. NULL parameter check in the local ColdFire clocking code. Regards Greg The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.12 for you to fetch changes up to c1fb1bf64bb63a1d6ae3311a9a3581a527c1f185: m68k: let clk_enable() return immediately if clk is NULL (2021-02-08 08:15:17 +1000) m68knommu: updates for v5.12 - NULL clk parameter check in clk_enable() Defang Bo (1): m68k: let clk_enable() return immediately if clk is NULL arch/m68k/coldfire/clk.c | 4 1 file changed, 4 insertions(+)
Re: [PATCH] m68k: Fix virt_addr_valid() W=1 compiler warnings
On 23/2/21 8:49 pm, Geert Uytterhoeven wrote:
If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
include/linux/scatterlist.h: In function ‘sg_set_buf’:
arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET
&& (void *)(kaddr) < high_memory)
| ^~
or CONFIG_MMU=n:
include/linux/scatterlist.h: In function ‘sg_set_buf’:
arch/m68k/include/asm/page_no.h:33:50: warning: ordered comparison of
pointer with null pointer [-Wextra]
33 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void *)PAGE_OFFSET)
&& \
| ^~
Fix this by doing the comparison in the "unsigned long" instead of the
"void *" domain.
Note that for now this is only seen when compiling btrfs, due to commit
e9aa7c285d20a69c ("btrfs: enable W=1 checks for btrfs"), but as people
are doing more W=1 compile testing, it will start to show up elsewhere,
too.
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
---
Probably we want this as a fix for v5.12, to avoid the build bots
nagging about it all the time?
arch/m68k/include/asm/page_mm.h | 2 +-
arch/m68k/include/asm/page_no.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
index 7f5912af2a52ea0a..9b1672f9b2e22cdf 100644
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -171,7 +171,7 @@ static inline __attribute_const__ int
__virt_to_node_shift(void)
#include
#endif
-#define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory)
+#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET &&
((unsigned long)kaddr) < (unsigned long)high_memory)
#define pfn_valid(pfn)virt_addr_valid(pfn_to_virt(pfn))
#endif /* __ASSEMBLY__ */
diff --git a/arch/m68k/include/asm/page_no.h b/arch/m68k/include/asm/page_no.h
index 6bbe52025de3c5c6..8d0f862ee9d79532 100644
--- a/arch/m68k/include/asm/page_no.h
+++ b/arch/m68k/include/asm/page_no.h
@@ -30,8 +30,8 @@ extern unsigned long memory_end;
#define page_to_pfn(page) virt_to_pfn(page_to_virt(page))
#define pfn_valid(pfn)((pfn) < max_mapnr)
-#define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void *)PAGE_OFFSET) && \
- ((void *)(kaddr) < (void *)memory_end))
+#definevirt_addr_valid(kaddr) (((unsigned long)(kaddr) >= PAGE_OFFSET)
&& \
+ ((unsigned long)(kaddr) < memory_end))
#endif /* __ASSEMBLY__ */
Re: [SPAM?]Re: arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared
Hi Geert,
On 17/2/21 9:42 pm, Geert Uytterhoeven wrote:
Hi Greg,
On Wed, Feb 17, 2021 at 5:59 AM Greg Ungerer wrote:
On 12/2/21 8:05 pm, Arnd Bergmann wrote:
On Fri, Feb 12, 2021 at 6:48 AM kernel test robot wrote:
FYI, the error/warning still remains.
| ^~~~
arch/m68k/68000/dragen2.c: In function 'init_dragen2':
arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared (first use in
this function)
73 | LSSA = (long) screen_bits;
|^~~
arch/m68k/68000/dragen2.c:73:16: note: each undeclared identifier is
reported only once for each function it appears in
This problem existed before my patch, I just moved the line to another file.
To fix it, one needs to test on real hardware and figure out what is supposed
to go in there.
The bug was apparently introduced in linux-2.5.70 in this commit:
>
commit 2b1a7e97c8c2d6330a432cbcaf83a0ef5fab848e
Author: gerg
Date: Mon May 26 16:45:57 2003 +
[PATCH] fix m68knommu DragonEngine2 target setup code
Numerous fixes for the m68knommu DragonEngine2 setup code.
It was out of date relative to more recent kernels. Original patches
from Georges Menie.
BKrev: 3ed244c5dPVeFKP63b4kkeS_rEshag
Digging around a bit I think the screen_bits data structure was
originally in a screen.h file that was generated from a screen.xbm file.
That was removed in commit 0c0e6db80683 ("m68k: drop unused parts of
68VZ328 Makefile").
Obviously no one seems to be using this, that has been broken for a long
time now.
I could restore the generated screen.h here, so this could compile at
least. I don't have any of the hardware supported in the arch/m68k/68000
directory, so I can't test anything we fix in there.
Do you have the generated screen.h?
Looks like both the tool (xbm2lcd.pl) and the source (screen.xbm)
never made it upstream?
I have the tool (xbm2lcd.pl) and screen.xbm from a really old uClinux
distribution, and I can run it to generate the screen.h.
So yes, I have a screen.h now.
The other option is to remove the dragen code altogether.
Just remove the part protected by checks for CONFIG_INIT_LCD?
Yeah, or even all the dragen support if no one wants it anymore.
Easy enough to add the screen.h (probably rename it, since it is
dragen specific). And include that in dragen2.c.
Regards
Greg
Re: [SPAM?]Re: arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared
Hi Arnd,
On 12/2/21 8:05 pm, Arnd Bergmann wrote:
On Fri, Feb 12, 2021 at 6:48 AM kernel test robot wrote:
FYI, the error/warning still remains.
| ^~~~
arch/m68k/68000/dragen2.c: In function 'init_dragen2':
arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared (first use in
this function)
73 | LSSA = (long) screen_bits;
|^~~
arch/m68k/68000/dragen2.c:73:16: note: each undeclared identifier is
reported only once for each function it appears in
This problem existed before my patch, I just moved the line to another file.
To fix it, one needs to test on real hardware and figure out what is supposed
to go in there.
The bug was apparently introduced in linux-2.5.70 in this commit:
>
commit 2b1a7e97c8c2d6330a432cbcaf83a0ef5fab848e
Author: gerg
Date: Mon May 26 16:45:57 2003 +
[PATCH] fix m68knommu DragonEngine2 target setup code
Numerous fixes for the m68knommu DragonEngine2 setup code.
It was out of date relative to more recent kernels. Original patches
from Georges Menie.
BKrev: 3ed244c5dPVeFKP63b4kkeS_rEshag
Digging around a bit I think the screen_bits data structure was
originally in a screen.h file that was generated from a screen.xbm file.
That was removed in commit 0c0e6db80683 ("m68k: drop unused parts of
68VZ328 Makefile").
Obviously no one seems to be using this, that has been broken for a long
time now.
I could restore the generated screen.h here, so this could compile at
least. I don't have any of the hardware supported in the arch/m68k/68000
directory, so I can't test anything we fix in there.
The other option is to remove the dragen code altogether.
Regards
Greg
Re: [PATCH] m68k: let clk_enable() return immediately if clk is NULL
Hi Defang,
On 28/12/20 12:07 pm, Defang Bo wrote:
Similar to commit<742859adc721>("m68k: let clk_disable() return immediately if clk
is NULL").
there should be a check for clk to prevent NULL pointer dereference.
Signed-off-by: Defang Bo
I have applied this to the m68knommu git tree, for-next branch -
with blank line added as per Geert's suggestion.
Regards
Greg
---
arch/m68k/coldfire/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e..6decd11 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
int clk_enable(struct clk *clk)
{
unsigned long flags;
+ if (!clk)
+ return -EINVAL;
+
spin_lock_irqsave(_lock, flags);
if ((clk->enabled++ == 0) && clk->clk_ops)
clk->clk_ops->enable(clk);
Re: Old platforms: bring out your dead
On 11/1/21 7:36 pm, Geert Uytterhoeven wrote: Hi Adrian, On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz wrote: On 1/11/21 10:20 AM, Geert Uytterhoeven wrote: Sounds interesting. Do these SoCs come with an MMU? And do they use the ColdFire instruction set or do they run plain 68k code? No MMU, plain m68k code. 68328 Soc = 68000 core + some peripherals, 68360 SoC = CPU32 core (based on 68020 + some peripherals. OK, I guess that would be useful for the NoMMU Linux port. Note that 68360 support was removed from the kernel in 2016, as Arnd said. And that 68360 was bit rotten for a very long time before that. Nobody ever seemed to show much interest in it. Keep in mind that the 68328 family of parts are pretty slow too... Anyone working on integrating m68k (and SPARC and MIPS?) softcores in LiteX? ;-) I'm personally waiting for the Vampire to gain support for the real 68851 as the hardware in general looks very attractive [1]. The 68851 is way too complex for what's needed (who needs support for 256 byte pages (https://lwn.net/Articles/839746/)?). They'd be better off implementing something simpler, like 68040 MMU support, or perhaps even a software-controlled TLB like most RISC architectures (incl. ColdFire?). The latter would require more changes to Linux, though. Yep, the ColdFire MMU is a software controlled TLB. Regards Greg
Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)
Hi John, On 7/1/21 7:02 pm, John Ogness wrote: On 2021-01-06, Vineet Gupta wrote: This breaks ARC booting (no output on console). Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now. I can show an example for m68knommu which this change breaks too (with no console output on boot). All the ColdFire dev board targets (arch/m68k/configs/m5*) have a compiled in boot argument which is "root=/dev/mtdblock0". They have no real mechanism to pass boot arguments from their boot loader, so it is compiled in. The default mcf serial driver is the console on these and no "console=ttyS0" argument was required in the past. Regards Greg
[git pull] m68knommu changes for v5.11
Hi Linus, Please pull the m68knommu changes for v5.11. Regards Greg The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f: Linux 5.10-rc7 (2020-12-06 14:25:12 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.11 for you to fetch changes up to 8b22820efb35f93d98638563b0a8f4094e8ee399: m68k: m68328: remove duplicate code (2020-12-07 09:37:58 +1000) Fixes include: . cleanup of 68328 code . align BSS section to 32bit Arnd Bergmann (2): m68k: m68328: move platform code to separate files m68k: m68328: remove duplicate code Greg Ungerer (1): m68knommu: align BSS section to 4-byte boundaries arch/m68k/68000/Makefile | 9 +- arch/m68k/68000/dragen2.c | 100 arch/m68k/68000/m68328.c | 32 --- arch/m68k/68000/m68328.h | 5 + arch/m68k/68000/m68EZ328.c | 77 --- arch/m68k/68000/m68VZ328.c | 189 - arch/m68k/68000/ucsimm.c | 38 arch/m68k/Kconfig.cpu | 8 +- arch/m68k/Kconfig.machine | 16 ++-- arch/m68k/kernel/setup_no.c| 9 ++ arch/m68k/kernel/vmlinux-nommu.lds | 2 +- 11 files changed, 192 insertions(+), 293 deletions(-) create mode 100644 arch/m68k/68000/dragen2.c create mode 100644 arch/m68k/68000/m68328.h delete mode 100644 arch/m68k/68000/m68EZ328.c delete mode 100644 arch/m68k/68000/m68VZ328.c create mode 100644 arch/m68k/68000/ucsimm.c
Re: [PATCH v2 1/2] m68k: m68328: move platform code to separate files
On 31/10/20 12:26 am, Arnd Bergmann wrote:
From: Arnd Bergmann
The dragen2 and ucsimm/ucdimm files require a bit of
custom code compared to the other dragonball platforms,
move them into separate files as a preparation for a
build fix.
Signed-off-by: Arnd Bergmann
---
Just a small cleanup after I ran into some issue during build
testing my timer patches, the second patch contains the
actual bugfix but relies on this preparation patch.
Thanks Arnd,
Pushed into the for-next branch of the m68knommu git tree.
Regards
Greg
---
arch/m68k/68000/Makefile | 4 ++
arch/m68k/68000/dragen2.c | 100 +++
arch/m68k/68000/m68328.c | 3 +-
arch/m68k/68000/m68328.h | 5 ++
arch/m68k/68000/m68EZ328.c | 23 +--
arch/m68k/68000/m68VZ328.c | 136 ++---
arch/m68k/68000/ucsimm.c | 38 +++
7 files changed, 158 insertions(+), 151 deletions(-)
create mode 100644 arch/m68k/68000/dragen2.c
create mode 100644 arch/m68k/68000/m68328.h
create mode 100644 arch/m68k/68000/ucsimm.c
diff --git a/arch/m68k/68000/Makefile b/arch/m68k/68000/Makefile
index 4f7d4b45a46f..ce0b26d6580d 100644
--- a/arch/m68k/68000/Makefile
+++ b/arch/m68k/68000/Makefile
@@ -16,4 +16,8 @@ obj-$(CONFIG_M68EZ328)+= m68EZ328.o
obj-$(CONFIG_M68VZ328)+= m68VZ328.o
obj-$(CONFIG_ROM) += romvec.o
+obj-$(CONFIG_DRAGEN2) += dragen2.o
+obj-$(CONFIG_UCSIMM) += ucsimm.o
+obj-$(CONFIG_UCDIMM) += ucsimm.o
+
extra-y := head.o
diff --git a/arch/m68k/68000/dragen2.c b/arch/m68k/68000/dragen2.c
new file mode 100644
index ..584893c57c37
--- /dev/null
+++ b/arch/m68k/68000/dragen2.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 1993 Hamish Macdonald
+ * Copyright (C) 1999 D. Jeff Dionne
+ * Copyright (C) 2001 Georges Menie, Ken Desmet
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+#include
+#include
+#include
+
+/***/
+/*Init Drangon Engine hardware */
+/***/
+
+static void dragen2_reset(void)
+{
+ local_irq_disable();
+
+#ifdef CONFIG_INIT_LCD
+ PBDATA |= 0x20; /* disable CCFL light */
+ PKDATA |= 0x4; /* disable LCD controller */
+ LCKCON = 0;
+#endif
+
+ __asm__ __volatile__(
+ "reset\n\t"
+ "moveal #0x0400, %a0\n\t"
+ "moveal 0(%a0), %sp\n\t"
+ "moveal 4(%a0), %a0\n\t"
+ "jmp (%a0)"
+ );
+}
+
+void __init init_dragen2(char *command, int size)
+{
+ mach_reset = dragen2_reset;
+
+#ifdef CONFIG_DIRECT_IO_ACCESS
+ SCR = 0x10; /* allow user access to
internal registers */
+#endif
+
+ /* CSGB Init */
+ CSGBB = 0x4000;
+ CSB = 0x1a1;
+
+ /* CS8900 init */
+ /* PK3: hardware sleep function pin, active low */
+ PKSEL |= PK(3); /* select pin as I/O */
+ PKDIR |= PK(3); /* select pin as output */
+ PKDATA |= PK(3);/* set pin high */
+
+ /* PF5: hardware reset function pin, active high */
+ PFSEL |= PF(5); /* select pin as I/O */
+ PFDIR |= PF(5); /* select pin as output */
+ PFDATA &= ~PF(5); /* set pin low */
+
+ /* cs8900 hardware reset */
+ PFDATA |= PF(5);
+ { int i; for (i = 0; i < 32000; ++i); }
+ PFDATA &= ~PF(5);
+
+ /* INT1 enable (cs8900 IRQ) */
+ PDPOL &= ~PD(1);/* active high signal */
+ PDIQEG &= ~PD(1);
+ PDIRQEN |= PD(1); /* IRQ enabled */
+
+#ifdef CONFIG_INIT_LCD
+ /* initialize LCD controller */
+ LSSA = (long) screen_bits;
+ LVPW = 0x14;
+ LXMAX = 0x140;
+ LYMAX = 0xef;
+ LRRA = 0;
+ LPXCD = 3;
+ LPICF = 0x08;
+ LPOLCF = 0;
+ LCKCON = 0x80;
+ PCPDEN = 0xff;
+ PCSEL = 0;
+
+ /* Enable LCD controller */
+ PKDIR |= 0x4;
+ PKSEL |= 0x4;
+ PKDATA &= ~0x4;
+
+ /* Enable CCFL backlighting circuit */
+ PBDIR |= 0x20;
+ PBSEL |= 0x20;
+ PBDATA &= ~0x20;
+
+ /* contrast control register */
+ PFDIR |= 0x1;
+ PFSEL &= ~0x1;
+ PWMR = 0x037F;
+#endif
+}
diff --git a/arch/m68k/68000/m68328.c b/arch/m68k/68000/m68328.c
index 419751b15ec8..6a5cfc977150 100644
--- a/arch/m68k/68000/m68328.c
+++ b/arch/m68k/68000/m68328.c
@@ -25,9 +25,10 @@
#include "bootlogo.h"
#endif
+#include "m68328.h"
+
Re: [PATCH 2/2] m68k: m68328: remove duplicate code
Hi Arnd, On 31/10/20 12:25 am, Arnd Bergmann wrote: On Mon, Oct 19, 2020 at 2:06 PM Arnd Bergmann wrote: On Mon, Oct 19, 2020 at 1:45 AM Greg Ungerer wrote: On 15/10/20 10:32 pm, Arnd Bergmann wrote: diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine index 17e8c3a292d7..1851c66e8667 100644 --- a/arch/m68k/Kconfig.machine +++ b/arch/m68k/Kconfig.machine @@ -136,14 +136,13 @@ config SUN3 If you don't want to compile a kernel exclusively for a Sun 3, say N. -endif # M68KCLASSIC - config PILOT bool config PILOT3 bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support" - depends on M68328 + depends on !MMU + select M68328 Given that M68328 depends on !MMU do you also need or want that here? Yes, that is exactly the reason: if M68328 depends on !MMU and gets selected by something that lacks the !MMU dependency, we'd get a Kconfig warning and a failed build when enabling PILOT3 with MMU enabled. It looks like my reply never made it out because of mail server issues. I hope the above answers your question. I'm rebasing this series (along with some others) now, and will resend in a bit. Ok, no worries. Otherwise looked good. I will review v2 and most likely push into the m68knommu git tree. Regards Greg
Re: [RFC 13/13] m68k: mac: convert to generic clockevent
On 30/10/20 10:41 am, Finn Thain wrote:
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
On Sun, Oct 18, 2020 at 2:55 AM Finn Thain wrote:
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote:
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
That configuration still produces the same 5 KiB of bloat. I see that
kernel/time/Kconfig has this --
# Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
# only related to the tick functionality. Oneshot clockevent devices
# are supported independent of this.
config TICK_ONESHOT
bool
But my question was really about both kinds of dead code (oneshot
device support and oneshot tick support). Anyway, after playing with
the code for a bit I don't see any easy way to reduce the growth in
text size.
Did you look more deeply into where those 5KB are? Is this just the code
in kernel/time/{clockevents,tick-common}.c and the added platform
specific bits, or is there something more?
What I did was to list the relevant functions using scripts/bloat-o-meter
and tried stubbing out some code related to oneshot clockevent devices. I
didn't find any low fruit and don't plan to pursue that without the help
of LTO.
I suppose the sysfs interface and the clockevents_update_freq() logic
are not really needed on m68k, but it wouldn't make much sense to split
those out either.
How does the 5KB bloat compare to the average bloat we get from one
release to the next? Geert has been collecting statistics for this.
Perhaps that 5 KB is justified by gaining the hrtimers feature... hard to
say; it's never been available on these platforms. I can see the value in
it though.
Yes, makes sense. I think the one remaining problem with the
periodic mode in this driver is that it can drop timer ticks when
interrupts are disabled for too long, while in oneshot mode there
may be a way to know how much time has passed since the last tick as
long as the counter does not overflow.
Is there any benefit from adopting a oneshot tick (rather than
periodic) if no clocksource is consulted when calculating the next
interval? (I'm assuming NO_HZ is not in use, for reasons discussed
below.)
If the clocksource does not set CLOCK_SOURCE_IS_CONTINOUS, the kernel
will keep using periodic timers and not allow hrtimers.
IIUC, when HIGH_RES_TIMERS=y, the kernel will enable hrtimers only if the
platform provides both a continuous clocksource device and a oneshot
clockevent device. However, the "jiffies" clocksource does not set
CLOCK_SOURCE_IS_CONTINOUS and neither does the one in
arch/arm/mach-rpc/time.c.
When HIGH_RES_TIMERS=n and NO_HZ_COMMON=n (which is presently the case for
all platforms with GENERIC_CLOCKEVENTS=n) there's no use for a oneshot
clockevent device, right?
It seems likely that NO_HZ_COMMON=n because the clocksources on these
platforms produce a periodic interrupt regardless (e.g.
clocksource/i8253.c, arm/rpc, m68k platform timers etc.).
Finally, HIGH_RES_TIMERS=n seems likely if the only clocksource is
unreliable (e.g. because it loses time due to interrupt priorities). There
may be a few of platforms in this category (Mac, Atari?).
I would agree that despite this oneshot mode is probably worse
overall for timekeeping if the register accesses introduce
systematic errors.
It probably has to be tried. But consulting a VIA clocksource on every
tick would be expensive on this platform, so if that was the only way
to avoid cumulative errors, I'd probably just stick with the periodic
tick.
I'm sure there is a tradeoff somewhere. Without hrtimers, some events
will take longer when they have to wait for the next tick, and using
NO_HZ_FULL can help help make things faster on some workloads.
Yes, such a tradeoff is discussed in drivers/iio/adc/ep93xx_adc.c.
But OTOH, Documentation/timers/timers-howto.rst says,
On slower systems, (embedded, OR perhaps a speed-stepped PC!) the
overhead of setting up the hrtimers for usleep *may* not be worth it
I guess it has to be tried.
...
The other 11 platforms in that category also have 'synthetic'
clocksources derived from a timer reload interrupt. In 3 cases, the
clocksource read method does not (or can not) check for a pending
counter reload interrupt. For these also, I see no practical
alternative to the approach you've taken in your RFC patch:
arch/m68k/68000/timers.c
arch/m68k/atari/time.c
arch/m68k/coldfire/timers.c
Agreed. It's possible there is a way, but I don't see one either.
For arch/m68k/68000/timers.c, I suppose we may be able to check for the
TMR1 bit in the Interrupt Status Register at 0xF30C or the COMP bit in
the Timer Status Register at 0xF60A. But testing that patch could be
difficult.
I expect that equivalent flags are available in Coldfire registers, making
it possible to improve upon mcftmr_read_clk() and m68328_read_clk() if
need be -- that is, if it turns out that the clocksource interrupt was
subject to higher priority IRQs
Re: [PATCH 2/2] i2c: imx: remove id_table entry
On 24/10/20 1:28 am, Krzysztof Kozlowski wrote:
On Fri, Oct 23, 2020 at 04:18:23PM +0800, peng@nxp.com wrote:
From: Peng Fan
The legacy platform device code has been removed under arch/arm/mach-imx,
so we no need id_table entry here.
Cc: Greg, Geert, Angelo,
Aren't you breaking Coldfire platforms?
Well spotted Krzysztof. It is used by quite a few of the ColdFire parts.
Regards
Greg
Best regards,
Krzysztof
Signed-off-by: Peng Fan
---
drivers/i2c/busses/i2c-imx.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index ba9d639223ec..7ea36a78abb0 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -233,19 +233,6 @@ static struct imx_i2c_hwdata vf610_i2c_hwdata = {
};
-static const struct platform_device_id imx_i2c_devtype[] = {
- {
- .name = "imx1-i2c",
- .driver_data = (kernel_ulong_t)_i2c_hwdata,
- }, {
[git pull] m68knommu changes for v5.10
Hi Linus,
Please pull the m68knommu changes for v5.10.
I expect you will get a merge conflict on a27bc11f4b7c ("m68knommu: switch
to using asm-generic/uaccess.h") in arch/m68k/Kconfig. The resolution is
strait forward, you just need to add the single line:
select UACCESS_MEMCPY if !MMU
as per the that commit. Geert ordered that list alphabetically, so it
now needs to go near the end of that list of selects, jut above
"select VIRT_TO_BUS".
Regards
Greg
The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50:
Linux 5.9-rc8 (2020-10-04 16:04:34 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
tags/m68knommu-for-v5.10
for you to fetch changes up to 9f5fd809d7a02e32c2e044acb9f6aed1c79a699b:
serial: mcf: add sysrq capability (2020-10-07 21:58:36 +1000)
m68knommu: collection of fixes for 5.10
Fixes include:
. switch to using asm-generic uaccess code
. fix sparse warnings in signal code
. fix compilation of ColdFire MMC support
. support sysrq in ColdFire serial driver
Angelo Dureghello (1):
serial: mcf: add sysrq capability
Greg Ungerer (3):
m68knommu: switch to using asm-generic/uaccess.h
m68knommu: fix sparse warnings in signal code
m68knommu: include SDHC support only when hardware has it
arch/m68k/Kconfig | 1 +
arch/m68k/coldfire/device.c| 6 +-
arch/m68k/include/asm/uaccess.h| 398 -
arch/m68k/include/asm/uaccess_mm.h | 390
arch/m68k/include/asm/uaccess_no.h | 160 ---
arch/m68k/kernel/signal.c | 6 +-
drivers/tty/serial/mcf.c | 1 +
7 files changed, 403 insertions(+), 559 deletions(-)
delete mode 100644 arch/m68k/include/asm/uaccess_mm.h
delete mode 100644 arch/m68k/include/asm/uaccess_no.h
Re: [PATCH 2/2] m68k: m68328: remove duplicate code
Hi Arnd, Overall looks good. On 15/10/20 10:32 pm, Arnd Bergmann wrote: [snip] diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 694c4fca9f5d..a65ce7618232 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -35,7 +35,7 @@ endchoice if M68KCLASSIC config M68000 - bool "MC68000" + bool depends on !MMU select CPU_HAS_NO_BITFIELDS select CPU_HAS_NO_MULDIV64 @@ -102,21 +102,21 @@ config M68060 processor, say Y. Otherwise, say N. config M68328 - bool "MC68328" + bool depends on !MMU select M68000 help Motorola 68328 processor support. config M68EZ328 - bool "MC68EZ328" + bool depends on !MMU select M68000 help Motorola 68EX328 processor support. config M68VZ328 - bool "MC68VZ328" + bool depends on !MMU select M68000 help diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine index 17e8c3a292d7..1851c66e8667 100644 --- a/arch/m68k/Kconfig.machine +++ b/arch/m68k/Kconfig.machine @@ -136,14 +136,13 @@ config SUN3 If you don't want to compile a kernel exclusively for a Sun 3, say N. -endif # M68KCLASSIC - config PILOT bool config PILOT3 bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support" - depends on M68328 + depends on !MMU + select M68328 Given that M68328 depends on !MMU do you also need or want that here? Regards Greg
Re: [PATCH 05/13] m68k: coldfire: use legacy_timer_tick()
Hi Arnd, On 9/10/20 1:46 am, Arnd Bergmann wrote: Replace the indirect function calls in the timer code with direct calls to the newly added legacy_timer_tick() helper for those that have not yet been converted to generic clockevents. This makes the timer code a little more self-contained. Signed-off-by: Arnd Bergmann I tested this series on a couple of different ColdFire parts (5208 and 5475) and under QEMU emulating the 5208. All checked out good, all worked as expected. So for the ColdFire changes: Tested-by: Greg Ungerer Regards Greg --- arch/m68k/Kconfig.cpu | 35 +-- arch/m68k/coldfire/Makefile | 32 ++-- arch/m68k/coldfire/sltimers.c | 6 ++ arch/m68k/coldfire/timers.c | 6 ++ 4 files changed, 51 insertions(+), 28 deletions(-) diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 694c4fca9f5d..322a35ef14c6 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -137,6 +137,7 @@ config M5206 bool "MCF5206" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_MBAR select CPU_NO_EFFICIENT_FFS help @@ -146,6 +147,7 @@ config M5206e bool "MCF5206e" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_MBAR select CPU_NO_EFFICIENT_FFS help @@ -154,7 +156,7 @@ config M5206e config M520x bool "MCF520x" depends on !MMU - select GENERIC_CLOCKEVENTS + select COLDFIRE_PIT_TIMER select HAVE_CACHE_SPLIT help Freescale Coldfire 5207/5208 processor support. @@ -162,7 +164,7 @@ config M520x config M523x bool "MCF523x" depends on !MMU - select GENERIC_CLOCKEVENTS + select COLDFIRE_PIT_TIMER select HAVE_CACHE_SPLIT select HAVE_IPSBAR help @@ -172,6 +174,7 @@ config M5249 bool "MCF5249" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_MBAR select CPU_NO_EFFICIENT_FFS help @@ -181,6 +184,7 @@ config M525x bool "MCF525x" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_MBAR select CPU_NO_EFFICIENT_FFS help @@ -189,10 +193,10 @@ config M525x config M5271 bool "MCF5271" depends on !MMU + select COLDFIRE_PIT_TIMER select M527x select HAVE_CACHE_SPLIT select HAVE_IPSBAR - select GENERIC_CLOCKEVENTS help Freescale (Motorola) ColdFire 5270/5271 processor support. @@ -200,6 +204,7 @@ config M5272 bool "MCF5272" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_MBAR select CPU_NO_EFFICIENT_FFS help @@ -208,17 +213,17 @@ config M5272 config M5275 bool "MCF5275" depends on !MMU + select COLDFIRE_PIT_TIMER select M527x select HAVE_CACHE_SPLIT select HAVE_IPSBAR - select GENERIC_CLOCKEVENTS help Freescale (Motorola) ColdFire 5274/5275 processor support. config M528x bool "MCF528x" depends on !MMU - select GENERIC_CLOCKEVENTS + select COLDFIRE_PIT_TIMER select HAVE_CACHE_SPLIT select HAVE_IPSBAR help @@ -227,6 +232,7 @@ config M528x config M5307 bool "MCF5307" depends on !MMU + select COLDFIRE_TIMERS select COLDFIRE_SW_A7 select HAVE_CACHE_CB select HAVE_MBAR @@ -237,6 +243,7 @@ config M5307 config M532x bool "MCF532x" depends on !MMU + select COLDFIRE_TIMERS select M53xx select HAVE_CACHE_CB help @@ -245,6 +252,7 @@ config M532x config M537x bool "MCF537x" depends on !MMU + select COLDFIRE_TIMERS select M53xx select HAVE_CACHE_CB help @@ -254,6 +262,7 @@ config M5407 bool "MCF5407" depends on !MMU select COLDFIRE_SW_A7 + select COLDFIRE_TIMERS select HAVE_CACHE_CB select HAVE_MBAR select CPU_NO_EFFICIENT_FFS @@ -263,6 +272,7 @@ config M5407 config M547x bool "MCF547x" select M54xx + select COLDFIRE_SLTIMERS select MMU_COLDFIRE if MMU select FPU if MMU select HAVE_CACHE_CB @@ -273,6 +283,7 @@ config M547x config M548x bool "MCF548x" + select COLDFIRE_SLTIMERS select MMU_COLDFIRE if MMU select FPU if MMU select M54xx @@ -284,8 +295,8 @@ config M548x config M5441x bool "MCF5441x" + select COLDFIRE_PIT_TIMER select MMU_COLDFIRE if MMU -
Re: [PATCH] m68k: Revive _TIF_* masks
Hi Geert,
On 26/8/20 10:29 pm, Geert Uytterhoeven wrote:
While the core m68k code does not use the _TIF_* masks anymore, there
exists generic code that relies on their presence. Fortunately none of
that code is used on m68k, currently.
Re-add the various _TIF_* masks, which were removed in commit
cddafa3500fde4a0 ("m68k/m68knommu: merge MMU and non-MMU
thread_info.h"), to avoid future nasty surprises.
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Regards
Greg
arch/m68k/include/asm/thread_info.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/m68k/include/asm/thread_info.h
b/arch/m68k/include/asm/thread_info.h
index 015f1ca383053a39..3689c6718c883d23 100644
--- a/arch/m68k/include/asm/thread_info.h
+++ b/arch/m68k/include/asm/thread_info.h
@@ -68,4 +68,12 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_MEMDIE16 /* is terminating due to OOM killer */
#define TIF_RESTORE_SIGMASK 18 /* restore signal mask in do_signal */
+#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
+#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
+#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
+#define _TIF_DELAYED_TRACE (1 << TIF_DELAYED_TRACE)
+#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
+#define _TIF_MEMDIE(1 << TIF_MEMDIE)
+#define _TIF_RESTORE_SIGMASK (1 << TIF_RESTORE_SIGMASK)
+
#endif/* _ASM_M68K_THREAD_INFO_H */
Re: [PATCH] m68k: mm: Remove superfluous memblock_alloc*() casts
Hi Geert,
On 26/8/20 11:04 pm, Geert Uytterhoeven wrote:
The return type of memblock_alloc*() is a void pointer, so there is no
need to cast it to "void *" or some other pointer type, before assigning
it to a pointer variable.
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Regards
Greg
arch/m68k/mm/mcfmmu.c | 2 +-
arch/m68k/mm/motorola.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 2b9cb4a622811390..eac9dde65193443e 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,7 +42,7 @@ void __init paging_init(void)
unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
int i;
- empty_zero_page = (void *) memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
if (!empty_zero_page)
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
__func__, PAGE_SIZE, PAGE_SIZE);
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index a9bdde54ca350197..3a653f0a4188d4af 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -227,7 +227,7 @@ static pte_t * __init kernel_page_table(void)
pte_t *pte_table = last_pte_table;
if (PAGE_ALIGNED(last_pte_table)) {
- pte_table = (pte_t *)memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
+ pte_table = memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
if (!pte_table) {
panic("%s: Failed to allocate %lu bytes align=%lx\n",
__func__, PAGE_SIZE, PAGE_SIZE);
@@ -275,8 +275,7 @@ static pmd_t * __init kernel_ptr_table(void)
last_pmd_table += PTRS_PER_PMD;
if (PAGE_ALIGNED(last_pmd_table)) {
- last_pmd_table = (pmd_t *)memblock_alloc_low(PAGE_SIZE,
- PAGE_SIZE);
+ last_pmd_table = memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
if (!last_pmd_table)
panic("%s: Failed to allocate %lu bytes align=%lx\n",
__func__, PAGE_SIZE, PAGE_SIZE);
[git pull] m68knommu changes for v5.9-rc3
Hi Linus, Please pull the m68knommu changes for v5.9-rc3. Only a single fix for the binfmt_flat loader (reverting a recent change). Regards Greg The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.9-rc3 for you to fetch changes up to 2217b982624680d19a80ebb4600d05c8586c4f96: binfmt_flat: revert "binfmt_flat: don't offset the data start" (2020-08-24 08:49:13 +1000) m68knommu: fixes for 5.9-rc3 Fixes include: . revert binfmt_flat data offset removal Max Filippov (1): binfmt_flat: revert "binfmt_flat: don't offset the data start" fs/binfmt_flat.c | 20 1 file changed, 12 insertions(+), 8 deletions(-)
Re: [PATCH] binfmt_flat: revert "binfmt_flat: don't offset the data start"
Hi Max,
On 9/8/20 4:37 am, Max Filippov wrote:
binfmt_flat loader uses the gap between text and data to store data
segment pointers for the libraries. Even in the absence of shared
libraries it stores at least one pointer to the executable's own data
segment. Text and data can go back to back in the flat binary image and
without offsetting data segment last few instructions in the text
segment may get corrupted by the data segment pointer.
Yep, your right, it does.
I will push this into the m68knommu git tree next week (once the merge
window is closed), and make sure it gets to Linus for rc series soon
after that.
Thanks
Greg
Fix it by reverting commit a2357223c50a ("binfmt_flat: don't offset the
data start").
Cc: sta...@vger.kernel.org
Fixes: a2357223c50a ("binfmt_flat: don't offset the data start")
Signed-off-by: Max Filippov
---
fs/binfmt_flat.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f2f9086ebe98..b9c658e0548e 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -576,7 +576,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra;
+ len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned
long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -590,7 +590,9 @@ static int load_flat_file(struct linux_binprm *bprm,
vm_munmap(textpos, text_len);
goto err;
}
- datapos = ALIGN(realdatastart, FLAT_DATA_ALIGN);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
data_len + bss_len + stack_len, datapos);
@@ -620,7 +622,7 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra;
+ len = text_len + data_len + extra + MAX_SHARED_LIBS *
sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -635,7 +637,9 @@ static int load_flat_file(struct linux_binprm *bprm,
}
realdatastart = textpos + ntohl(hdr->data_start);
- datapos = ALIGN(realdatastart, FLAT_DATA_ALIGN);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(u32),
+ FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
(datapos + (ntohl(hdr->reloc_start) - text_len));
@@ -652,9 +656,8 @@ static int load_flat_file(struct linux_binprm *bprm,
(text_len + full_data
- sizeof(struct flat_hdr)),
0);
- if (datapos != realdatastart)
- memmove((void *)datapos, (void *)realdatastart,
- full_data);
+ memmove((void *) datapos, (void *) realdatastart,
+ full_data);
#else
/*
* This is used on MMU systems mainly for testing.
@@ -710,7 +713,8 @@ static int load_flat_file(struct linux_binprm *bprm,
if (IS_ERR_VALUE(result)) {
ret = result;
pr_err("Unable to read code+data+bss, errno %d\n", ret);
- vm_munmap(textpos, text_len + data_len + extra);
+ vm_munmap(textpos, text_len + data_len + extra +
+ MAX_SHARED_LIBS * sizeof(u32));
goto err;
}
}
[git pull] m68knommu changes for v5.9
Hi Linus, Please pull the m68knommu changes for v5.9. Regards Greg The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.9 for you to fetch changes up to fde87ebf1daa8d96e4412aa06536da4b55103e02: m68k: stmark2: enable edma support for dspi (2020-07-27 12:32:00 +1000) m68knommu: collection of fixes for v5.9 Fixes include: . cleanup compiler warnings (IO access functions and unused variables) . ColdFire v3 cache control fix . ColdFire MMU comment cleanup . switch to using asm-generic cmpxchg_local() . stmark platform updates Angelo Dureghello (2): m68k: stmark2: defconfig updates m68k: stmark2: enable edma support for dspi Greg Ungerer (5): m68knommu: __force type casts for raw IO access m68knommu: fix use of cpu_to_le() on IO access m68k: fix ColdFire mmu init compile warning m68knommu: fix overwriting of bits in ColdFire V3 cache control m68k: use asm-generic cmpxchg_local() Mike Rapoport (1): m68k: mcfmmu: remove stale part of comment about steal_context arch/m68k/coldfire/stmark2.c| 5 arch/m68k/configs/stmark2_defconfig | 47 + arch/m68k/include/asm/cmpxchg.h | 8 --- arch/m68k/include/asm/io_no.h | 20 arch/m68k/include/asm/m53xxacr.h| 6 ++--- arch/m68k/mm/mcfmmu.c | 6 - 6 files changed, 45 insertions(+), 47 deletions(-)
[git pull] m68knommu changes for v5.8-rc4
Hi Linus, Please pull important m68knommu fixes for v5.8-rc4 Regards Greg The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68: Linux 5.8-rc3 (2020-06-28 15:00:24 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.8-rc4 for you to fetch changes up to c43e55796dd4d13f4855971a4d7970ce2cd94db4: m68k: mm: fix node memblock init (2020-06-29 23:58:05 +1000) m68knommu: mm fixes needed for v5.8 Two critical mm related fixes that affect booting of m68k/ColdFire devices. Both fix problems caused by recent system init memblock changes. Angelo Dureghello (1): m68k: mm: fix node memblock init Mike Rapoport (1): m68k: nommu: register start of the memory with memblock arch/m68k/kernel/setup_no.c | 3 ++- arch/m68k/mm/mcfmmu.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock
Hi Mike,
On 29/6/20 2:14 pm, Mike Rapoport wrote:
On Mon, Jun 29, 2020 at 11:10:16AM +1000, Greg Ungerer wrote:
On 17/6/20 10:33 pm, Greg Ungerer wrote:
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:
BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping: index:0x0 flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1
404ba2a4
00020165 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0
40299e21
40088a12 41fe0ca0 41fe0ca4 020a 0001
402ca000
41fe0ca0 41fd2c10 41fd2c10 402b2388
0001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 0001
41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<402ca000>] 0x402ca000
[<400a0934>] 0x400a0934
Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
What path do you anticipate this taking into mainline?
I see it is still broken in 5.8-rc3.
I thought it will go through m68k tree.
Ok, no worries, I will push them through.
I have pushed into the for-next and for-linus branches of the m68knommu
git tree to get the ball rolling.
Regards
Greg
---
arch/m68k/kernel/setup_no.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..f66f4b1d062e 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add(_rambase, memory_end - _rambase);
+ memblock_reserve(_rambase, memory_start - _rambase);
/* Keep a copy of command line */
*cmdline_p = _line[0];
Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock
Hi Mike,
On 17/6/20 10:33 pm, Greg Ungerer wrote:
Hi Mike,
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:
BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping: index:0x0 flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
00020165 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
40088a12 41fe0ca0 41fe0ca4 020a 0001 402ca000
41fe0ca0 41fd2c10 41fd2c10 402b2388 0001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 0001 41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<402ca000>] 0x402ca000
[<400a0934>] 0x400a0934
Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
What path do you anticipate this taking into mainline?
I see it is still broken in 5.8-rc3.
Regards
Greg
---
arch/m68k/kernel/setup_no.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..f66f4b1d062e 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add(_rambase, memory_end - _rambase);
+ memblock_reserve(_rambase, memory_start - _rambase);
/* Keep a copy of command line */
*cmdline_p = _line[0];
Re: [PATCH 2/2] m68k: mm: fix node memblock init
Hi Mike, On 17/6/20 4:53 pm, Mike Rapoport wrote: From: Angelo Dureghello After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was hanging silently. memblock_add() seems not appropriate, since using MAX_NUMNODES as node id, while memblock_add_node() sets up memory for node id 0. Signed-off-by: Angelo Dureghello Signed-off-by: Mike Rapoport Acked-by: Greg Ungerer Regards Greg --- arch/m68k/mm/mcfmmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c index 29f47923aa46..7d04210d34f0 100644 --- a/arch/m68k/mm/mcfmmu.c +++ b/arch/m68k/mm/mcfmmu.c @@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void) m68k_memory[0].addr = _rambase; m68k_memory[0].size = _ramend - _rambase; - memblock_add(m68k_memory[0].addr, m68k_memory[0].size); + memblock_add_node(m68k_memory[0].addr, m68k_memory[0].size, 0); /* compute total pages in system */ num_pages = PFN_DOWN(_ramend - _rambase);
Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock
Hi Mike,
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:
BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping: index:0x0 flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
00020165 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
40088a12 41fe0ca0 41fe0ca4 020a 0001 402ca000
41fe0ca0 41fd2c10 41fd2c10 402b2388 0001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 0001 41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<402ca000>] 0x402ca000
[<400a0934>] 0x400a0934
Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/kernel/setup_no.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..f66f4b1d062e 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add(_rambase, memory_end - _rambase);
+ memblock_reserve(_rambase, memory_start - _rambase);
/* Keep a copy of command line */
*cmdline_p = _line[0];
Re: [PATCH 04/21] mm: free_area_init: use maximal zone PFNs rather than zone sizes
Hi Mike,
On 15/6/20 6:29 pm, Mike Rapoport wrote:
(reduced the spam list)
On Mon, Jun 15, 2020 at 05:17:28PM +1000, Greg Ungerer wrote:
On 15/6/20 4:22 pm, Mike Rapoport wrote:
On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
From: Mike Rapoport
Currently, architectures that use free_area_init() to initialize memory map
and node and zone structures need to calculate zone and hole sizes. We can
use free_area_init_nodes() instead and let it detect the zone boundaries
while the architectures will only have to supply the possible limits for
the zones.
Signed-off-by: Mike Rapoport
This is causing some new warnings for me on boot on at least one non-MMU m68k
target:
There were a couple of changes that cause this. The free_area_init()
now relies on memblock data and architectural limits for zone sizes
rather than on explisit pfns calculated by the arch code. I've update
motorola variant and missed coldfire. Angelo sent a fix for mcfmmu.c
[1] and I've updated it to include nommu as well
[1]
https://lore.kernel.org/linux-m68k/20200614225119.02-1-angelo.dureghe...@timesys.com
From 55b8523df2a5c4565b132c0691990f0821040fec Mon Sep 17 00:00:00 2001
From: Angelo Dureghello
Date: Mon, 15 Jun 2020 00:51:19 +0200
Subject: [PATCH] m68k: fix registration of memory regions with memblock
Commit 3f08a302f533 ("mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option")
introduced assumption that UMA systems have their memory at node 0 and
updated most of them, but it forgot nommu and coldfire variants of m68k.
The later change in free area initialization in commit fa3354e4ea39 ("mm:
free_area_init: use maximal zone PFNs rather than zone sizes") exposed that
and caused a lot of "BUG: Bad page state in process swapper" reports.
Even with this patch applied I am still seeing the same messages.
Argh, it was to early in the morning...
Can you please try the one below?
It seems that coldfire didn't register all its physical memory with
memblock and the pfn list was damaged because of that.
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..f66f4b1d062e 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add(_rambase, memory_end - _rambase);
+ memblock_reserve(_rambase, memory_start - _rambase);
/* Keep a copy of command line */
*cmdline_p = _line[0];
Yep, thats got it. Boots clean again with this one.
Regards
Greg
Re: [PATCH 04/21] mm: free_area_init: use maximal zone PFNs rather than zone sizes
Hi Mike,
On 15/6/20 4:22 pm, Mike Rapoport wrote:
On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
From: Mike Rapoport
Currently, architectures that use free_area_init() to initialize memory map
and node and zone structures need to calculate zone and hole sizes. We can
use free_area_init_nodes() instead and let it detect the zone boundaries
while the architectures will only have to supply the possible limits for
the zones.
Signed-off-by: Mike Rapoport
This is causing some new warnings for me on boot on at least one non-MMU m68k
target:
There were a couple of changes that cause this. The free_area_init()
now relies on memblock data and architectural limits for zone sizes
rather than on explisit pfns calculated by the arch code. I've update
motorola variant and missed coldfire. Angelo sent a fix for mcfmmu.c
[1] and I've updated it to include nommu as well
[1]
https://lore.kernel.org/linux-m68k/20200614225119.02-1-angelo.dureghe...@timesys.com
From 55b8523df2a5c4565b132c0691990f0821040fec Mon Sep 17 00:00:00 2001
From: Angelo Dureghello
Date: Mon, 15 Jun 2020 00:51:19 +0200
Subject: [PATCH] m68k: fix registration of memory regions with memblock
Commit 3f08a302f533 ("mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option")
introduced assumption that UMA systems have their memory at node 0 and
updated most of them, but it forgot nommu and coldfire variants of m68k.
The later change in free area initialization in commit fa3354e4ea39 ("mm:
free_area_init: use maximal zone PFNs rather than zone sizes") exposed that
and caused a lot of "BUG: Bad page state in process swapper" reports.
Even with this patch applied I am still seeing the same messages.
Regards
Greg
Using memblock_add_node() with nid = 0 to register memory banks solves the
problem.
Fixes: 3f08a302f533 ("mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option")
Fixes: fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than zone
sizes")
Signed-off-by: Angelo Dureghello
Co-developed-by: Mike Rapoport
Signed-off-by: Mike Rapoport
---
arch/m68k/kernel/setup_no.c | 2 +-
arch/m68k/mm/mcfmmu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..0c4589a39ba9 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,7 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add_node(memory_start, memory_end - memory_start, 0);
/* Keep a copy of command line */
*cmdline_p = _line[0];
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 29f47923aa46..7d04210d34f0 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void)
m68k_memory[0].addr = _rambase;
m68k_memory[0].size = _ramend - _rambase;
- memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
+ memblock_add_node(m68k_memory[0].addr, m68k_memory[0].size, 0);
/* compute total pages in system */
num_pages = PFN_DOWN(_ramend - _rambase);
Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression
On 13/6/20 2:35 am, Luc Van Oostenryck wrote: On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote: arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 This one I am not sure about yet. Still investigating. swab32(__raw_readl(addr)) ? Keeping __le32_to_cpu() will only force you to use ugly casts for no benefits and the comment above explain clearly the situation about the endianness. That is unfortunate, the use of le32_to_cpu() made it very clear what was going on - for those that don't choose to read comments. In any case that would seem to be the cleanest solution. Patch to follow. Regards Greg
Re: [PATCH 04/21] mm: free_area_init: use maximal zone PFNs rather than zone sizes
Hi Mike,
From: Mike Rapoport
Currently, architectures that use free_area_init() to initialize memory map
and node and zone structures need to calculate zone and hole sizes. We can
use free_area_init_nodes() instead and let it detect the zone boundaries
while the architectures will only have to supply the possible limits for
the zones.
Signed-off-by: Mike Rapoport
This is causing some new warnings for me on boot on at least one non-MMU m68k
target:
...
NET: Registered protocol family 17
BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping: index:0x0
flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
00020165 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
40088a12 41fe0ca0 41fe0ca4 020a 0001 402ca000
41fe0ca0 41fd2c10 41fd2c10 402b2388 0001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 0001 41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<402ca000>] 0x402ca000
[<400a0934>] 0x400a0934
[<40091056>] 0x40091056
[<40088db4>] 0x40088db4
[<40089e02>] 0x40089e02
[<4026ecf4>] 0x4026ecf4
[<40089e4e>] 0x40089e4e
[<4008ca26>] 0x4008ca26
[<4004adf8>] 0x4004adf8
[<402701ec>] 0x402701ec
[<4008f25e>] 0x4008f25e
[<400516f4>] 0x400516f4
[<4026eec0>] 0x4026eec0
[<400224f0>] 0x400224f0
[<402ca000>] 0x402ca000
[<4026eeda>] 0x4026eeda
[<40020b00>] 0x40020b00
...
Lots more of them.
...
BUG: Bad page state in process swapper pfn:201a0
page:41fe1400 refcount:0 mapcount:1 mapping: index:0x0
flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Tainted: GB
5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe1400 40299e21 40299df1 404ba2a4
000201a0 41fd2c10 402c7ba0 41fd2c04 40088504 41fe1400 40299e21
40088a12 41fe1400 41fe1404 020a 003b 0001 4034
41fe1400 41fd2c10 41fd2c10 41fe13e0 40022826
0044 404c9f44 404c9f44 404c9f44 40088db4 402c7ba0 0001 41fd2c04
41fe1400 41fd2000 41fe1400 40089e02 4026ecf4 40089e4e 41fe1400
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<40022826>] 0x40022826
[<40088db4>] 0x40088db4
[<40089e02>] 0x40089e02
[<4026ecf4>] 0x4026ecf4
[<40089e4e>] 0x40089e4e
[<4008ca26>] 0x4008ca26
[<4004adf8>] 0x4004adf8
[<402701ec>] 0x402701ec
[<4008f25e>] 0x4008f25e
[<400516f4>] 0x400516f4
[<4026eec0>] 0x4026eec0
[<400224f0>] 0x400224f0
[<402ca000>] 0x402ca000
[<4026eeda>] 0x4026eeda
[<40020b00>] 0x40020b00
Freeing unused kernel memory: 648K
This architecture does not have kernel memory protection.
Run /init as init process
...
System boots pretty much as normal through user space after this.
Seems to be fully operational despite all those BUGONs.
Specifically this is a M5208EVB target (arch/m68k/configs/m5208evb).
[snip]
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index b88d510d4fe3..6d3147662ff2 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -84,7 +84,7 @@ void __init paging_init(void)
* page_alloc get different views of the world.
*/
unsigned long end_mem = memory_end & PAGE_MASK;
- unsigned long zones_size[MAX_NR_ZONES] = { 0, };
+ unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
high_memory = (void *) end_mem;
@@ -98,8 +98,8 @@ void __init paging_init(void)
*/
set_fs (USER_DS);
- zones_size[ZONE_DMA] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT;
- free_area_init(zones_size);
+ max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
+ free_area_init(max_zone_pfn);
This worries me a little. On this target PAGE_OFFSET will be non-0.
Thoughts?
Regards
Greg
Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression
On 13/6/20 2:35 am, Luc Van Oostenryck wrote:
On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote:
On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
I think this one is due to not forcing the volatile cast in __raw_write().
So this change will fix that:
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 0498192e1d98..1bc739f1f1ad 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -14,15 +14,15 @@
* that behavior here first before we include asm-generic/io.h.
*/
#define __raw_readb(addr) \
-({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
+({ u8 __v = (*(__force volatile u8 *) (addr)); __v; })
#define __raw_readw(addr) \
-({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
+({ u16 __v = (*(__force volatile u16 *) (addr)); __v; })
#define __raw_readl(addr) \
-({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
+({ u32 __v = (*(__force volatile u32 *) (addr)); __v; })
-#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) =
(b))
-#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) =
(b))
-#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
+#define __raw_writeb(b, addr) (void)((*(__force volatile u8 *) (addr)) = (b))
+#define __raw_writew(b, addr) (void)((*(__force volatile u16 *) (addr)) = (b))
+#define __raw_writel(b, addr) (void)((*(__force volatile u32 *) (addr)) = (b))
Look good to me but isn't easier to leave them undefined and include
asm-generic/io.h?
Not so simple at the moment. Although juggling a few things around within
io_no.h will let you use the asm-generic functions it will now throw up
a _lot_ of warnings in many of the architecture files that pass int constant
addresses to the raw_* functions. That is on my todo list.
Regards
Greg
Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression
Hi Marc,
On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
the k-build robot found this sparse problem, triggered by building a CAN driver
for m68k. Is this a problem in our CAN driver or in the m68k headers?
I suspect a problem with the m68k (specifically non-mmu) headers.
On 6/12/20 7:28 AM, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b791d1bdf9212d944d749a5c7ff6febdba241771
commit: 26ad340e582d3d5958ed8456a1911d79cfb567b4 can: kvaser_pciefd: Add driver
for Kvaser PCIEcan devices
date: 11 months ago
config: m68k-randconfig-s032-20200612 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
git checkout 26ad340e582d3d5958ed8456a1911d79cfb567b4
# save the attached .config to linux build tree
make W=1 C=1 ARCH=m68k CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space
'' of expression
drivers/net/can/kvaser_pciefd.c:805:17: sparse: sparse: cast removes address
space '' of expression
arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
I think this one is due to not forcing the volatile cast in __raw_write().
So this change will fix that:
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 0498192e1d98..1bc739f1f1ad 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -14,15 +14,15 @@
* that behavior here first before we include asm-generic/io.h.
*/
#define __raw_readb(addr) \
-({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
+({ u8 __v = (*(__force volatile u8 *) (addr)); __v; })
#define __raw_readw(addr) \
-({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
+({ u16 __v = (*(__force volatile u16 *) (addr)); __v; })
#define __raw_readl(addr) \
-({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
+({ u32 __v = (*(__force volatile u32 *) (addr)); __v; })
-#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) = (b))
-#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) =
(b))
-#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
+#define __raw_writeb(b, addr) (void)((*(__force volatile u8 *) (addr)) = (b))
+#define __raw_writew(b, addr) (void)((*(__force volatile u16 *) (addr)) = (b))
+#define __raw_writel(b, addr) (void)((*(__force volatile u32 *) (addr)) = (b))
#if defined(CONFIG_COLDFIRE)
/*
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
This one I am not sure about yet.
Still investigating.
Regards
Greg
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space
'' of expression
[git pull] m68knommu changes for v5.8
Hi Linus,
Please pull the m68knommu changes for v5.8.
Regards
Greg
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
tags/m68knommu-for-v5.8
for you to fetch changes up to 9e2b6ed41f8f99c97b13c9d15cbef235dbd97fb6:
m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
(2020-05-30 10:55:54 +1000)
m68knommu: collection of fixes for v5.8
Fixes include:
. casting clean up in the user access macros
. memory leak on error case fix for PCI probing
. update of a defconfig.
Bin Meng (1):
m68k: Drop CONFIG_MTD_M25P80 in stmark2_defconfig
Christophe JAILLET (1):
m68k/PCI: Fix a memory leak in an error handling path
Luc Van Oostenryck (2):
m68k,nommu: add missing __user in uaccess' __ptr() macro
m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
arch/m68k/coldfire/pci.c| 4 +++-
arch/m68k/configs/stmark2_defconfig | 1 -
arch/m68k/include/asm/uaccess_no.h | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)
Re: [PATCH v2 0/2] fix missing handling of __user in nommu's uaccess()
Hi Luc,
On 30/5/20 5:02 am, Luc Van Oostenryck wrote:
I received a bug report for an unrelated patch when used with m68k-nommu.
It appears that the origin of the problem is that __get_user() and
__put_user() doesn't handle correctly __user. These 2 patches fix this.
Note: this is only minimaly tested but is quite straightforward and
since this only change __user annotation it will not change the
generated code.
Changes since v1:
* fix typo: s/plan/plain/
* appease checkpatch with better style: s/__force*/__force */
* avoid excessive line length caused by the added cast.
Luc Van Oostenryck (2):
m68k,nommu: add missing __user in uaccess' __ptr() macro
m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
arch/m68k/include/asm/uaccess_no.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Looks good, thanks for the fixup.
Applied to the m68knommu git tree, for-next branch.
Regards
Greg
Re: [PATCH 2/2] m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
Hi Luc, On 29/5/20 6:25 am, Luc Van Oostenryck wrote: The assembly for __get_user_asm() & __put_user_asm() uses memcpy() when the size is 8. However, the pointer is always a __user one while memcpy() expect a plan one and so this cast creates a lot of warnings when using Did you mean "plain"? Sparse. So, fix this by adding a cast to 'void __force *' at memcpy()'s argument. Reported-by: kbuild test robot Signed-off-by: Luc Van Oostenryck --- arch/m68k/include/asm/uaccess_no.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/m68k/include/asm/uaccess_no.h b/arch/m68k/include/asm/uaccess_no.h index 9651766a62af..f32f08a64eaa 100644 --- a/arch/m68k/include/asm/uaccess_no.h +++ b/arch/m68k/include/asm/uaccess_no.h @@ -42,7 +42,7 @@ static inline int _access_ok(unsigned long addr, unsigned long size) __put_user_asm(__pu_err, __pu_val, ptr, l); \ break; \ case 8: \ - memcpy(ptr, &__pu_val, sizeof (*(ptr))); \ + memcpy((void __force*)ptr, &__pu_val, sizeof (*(ptr))); \ ^^^ checkpatch wants a ' ' space in there. Otherwise I think it looks good. Regards Greg break; \ default: \ __pu_err = __put_user_bad();\ @@ -85,7 +85,7 @@ extern int __put_user_bad(void); u64 l; \ __typeof__(*(ptr)) t; \ } __gu_val; \ - memcpy(&__gu_val.l, ptr, sizeof(__gu_val.l)); \ + memcpy(&__gu_val.l, (const void __force*)ptr, sizeof(__gu_val.l)); \ (x) = __gu_val.t; \ break; \ } \
Re: [PATCH 1/4] m68k: add arch/m68k/Kbuild
On 26/5/20 10:38 pm, Masahiro Yamada wrote: Use the standard obj-y form to specify the sub-directories under arch/m68k/. No functional change intended. Signed-off-by: Masahiro Yamada Acked-by: Greg Ungerer Regards Greg --- arch/m68k/Kbuild | 19 +++ arch/m68k/Makefile | 20 +--- 2 files changed, 20 insertions(+), 19 deletions(-) create mode 100644 arch/m68k/Kbuild diff --git a/arch/m68k/Kbuild b/arch/m68k/Kbuild new file mode 100644 index ..7dc1398dd188 --- /dev/null +++ b/arch/m68k/Kbuild @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-y += kernel/ mm/ +obj-$(CONFIG_Q40) += q40/ +obj-$(CONFIG_AMIGA)+= amiga/ +obj-$(CONFIG_ATARI)+= atari/ +obj-$(CONFIG_MAC) += mac/ +obj-$(CONFIG_HP300)+= hp300/ +obj-$(CONFIG_APOLLO) += apollo/ +obj-$(CONFIG_MVME147) += mvme147/ +obj-$(CONFIG_MVME16x) += mvme16x/ +obj-$(CONFIG_BVME6000) += bvme6000/ +obj-$(CONFIG_SUN3X)+= sun3x/ sun3/ +obj-$(CONFIG_SUN3) += sun3/ sun3/prom/ +obj-$(CONFIG_NATFEAT) += emu/ +obj-$(CONFIG_M68040) += fpsp040/ +obj-$(CONFIG_M68060) += ifpsp060/ +obj-$(CONFIG_M68KFPU_EMU) += math-emu/ +obj-$(CONFIG_M68000) += 68000/ +obj-$(CONFIG_COLDFIRE) += coldfire/ diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 5d9288384096..88d4d8bbecd6 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -97,27 +97,9 @@ head-$(CONFIG_SUN3) := arch/m68k/kernel/sun3-head.o head-$(CONFIG_M68000) := arch/m68k/68000/head.o head-$(CONFIG_COLDFIRE) := arch/m68k/coldfire/head.o -core-y+= arch/m68k/kernel/ arch/m68k/mm/ +core-y += arch/m68k/ libs-y+= arch/m68k/lib/ -core-$(CONFIG_Q40) += arch/m68k/q40/ -core-$(CONFIG_AMIGA) += arch/m68k/amiga/ -core-$(CONFIG_ATARI) += arch/m68k/atari/ -core-$(CONFIG_MAC) += arch/m68k/mac/ -core-$(CONFIG_HP300) += arch/m68k/hp300/ -core-$(CONFIG_APOLLO) += arch/m68k/apollo/ -core-$(CONFIG_MVME147) += arch/m68k/mvme147/ -core-$(CONFIG_MVME16x) += arch/m68k/mvme16x/ -core-$(CONFIG_BVME6000)+= arch/m68k/bvme6000/ -core-$(CONFIG_SUN3X) += arch/m68k/sun3x/ arch/m68k/sun3/ -core-$(CONFIG_SUN3)+= arch/m68k/sun3/ arch/m68k/sun3/prom/ -core-$(CONFIG_NATFEAT) += arch/m68k/emu/ -core-$(CONFIG_M68040) += arch/m68k/fpsp040/ -core-$(CONFIG_M68060) += arch/m68k/ifpsp060/ -core-$(CONFIG_M68KFPU_EMU) += arch/m68k/math-emu/ -core-$(CONFIG_M68000) += arch/m68k/68000/ -core-$(CONFIG_COLDFIRE)+= arch/m68k/coldfire/ - all: zImage
Re: [PATCH 4/4] m68k: pass -D options to KBUILD_CPPFLAGS instead of KBUILD_{A,C}FLAGS
On 26/5/20 10:38 pm, Masahiro Yamada wrote: Precisely, -D is a preprocessor option. KBUILD_CPPFLAGS is passed to for compiling .c and .S files too. Signed-off-by: Masahiro Yamada Acked-by: Greg Ungerer Regards Greg --- arch/m68k/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index ae6e29da3a3e..c28f9f917ac0 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -70,9 +70,8 @@ ifdef CONFIG_MMU KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2 else # we can use a m68k-linux-gcc toolchain with these in place -KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\" -KBUILD_CFLAGS += -D__uClinux__ -KBUILD_AFLAGS += -D__uClinux__ +KBUILD_CPPFLAGS += -DUTS_SYSNAME=\"uClinux\" +KBUILD_CPPFLAGS += -D__uClinux__ endif KBUILD_LDFLAGS := -m m68kelf
Re: [PATCH 3/4] m68k: optimize cc-option calls for cpuflags-y
On 26/5/20 10:38 pm, Masahiro Yamada wrote: arch/m68k/Makefile computes lots of unneeded cc-option calls. For example, if CONFIG_M5441x is not defined, there is not point in evaluating the following compiler flag. cpuflags-$(CONFIG_M5441x) := $(call cc-option,-mcpu=54455,-mcfv4e) The result is set to cpuflags-, then thrown away. The right hand side of ':=' is immediately expanded. Hence, all of the 16 calls for cc-option are evaluated. This is expensive since cc-option invokes the compiler. This occurs even if you are not attempting to build anything, like 'make ARCH=m68k help'. Use '=' to expand the value _lazily_. The evaluation for cc-option is delayed until $(cpuflags-y) is expanded. So, the cc-option test happens just once at most. This commit mimics tune-y of arch/arm/Makefile. Signed-off-by: Masahiro Yamada Acked-by: Greg Ungerer Regards Greg --- arch/m68k/Makefile | 45 - 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 88d4d8bbecd6..ae6e29da3a3e 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -32,30 +32,33 @@ endif # compiler cpu type flag. # ifndef CONFIG_M68040 -cpuflags-$(CONFIG_M68060) := -m68060 +cpuflags-$(CONFIG_M68060) = -m68060 endif ifndef CONFIG_M68060 -cpuflags-$(CONFIG_M68040) := -m68040 +cpuflags-$(CONFIG_M68040) = -m68040 endif -cpuflags-$(CONFIG_M68030) := -cpuflags-$(CONFIG_M68020) := -cpuflags-$(CONFIG_M68000) := -m68000 -cpuflags-$(CONFIG_M5441x) := $(call cc-option,-mcpu=54455,-mcfv4e) -cpuflags-$(CONFIG_M54xx) := $(call cc-option,-mcpu=5475,-m5200) -cpuflags-$(CONFIG_M5407) := $(call cc-option,-mcpu=5407,-m5200) -cpuflags-$(CONFIG_M532x) := $(call cc-option,-mcpu=532x,-m5307) -cpuflags-$(CONFIG_M537x) := $(call cc-option,-mcpu=537x,-m5307) -cpuflags-$(CONFIG_M5307) := $(call cc-option,-mcpu=5307,-m5200) -cpuflags-$(CONFIG_M528x) := $(call cc-option,-mcpu=528x,-m5307) -cpuflags-$(CONFIG_M5275) := $(call cc-option,-mcpu=5275,-m5307) -cpuflags-$(CONFIG_M5272) := $(call cc-option,-mcpu=5272,-m5307) -cpuflags-$(CONFIG_M5271) := $(call cc-option,-mcpu=5271,-m5307) -cpuflags-$(CONFIG_M523x) := $(call cc-option,-mcpu=523x,-m5307) -cpuflags-$(CONFIG_M525x) := $(call cc-option,-mcpu=5253,-m5200) -cpuflags-$(CONFIG_M5249) := $(call cc-option,-mcpu=5249,-m5200) -cpuflags-$(CONFIG_M520x) := $(call cc-option,-mcpu=5208,-m5200) -cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200) -cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) +cpuflags-$(CONFIG_M68030) = +cpuflags-$(CONFIG_M68020) = +cpuflags-$(CONFIG_M68000) = -m68000 +cpuflags-$(CONFIG_M5441x) = $(call cc-option,-mcpu=54455,-mcfv4e) +cpuflags-$(CONFIG_M54xx) = $(call cc-option,-mcpu=5475,-m5200) +cpuflags-$(CONFIG_M5407) = $(call cc-option,-mcpu=5407,-m5200) +cpuflags-$(CONFIG_M532x) = $(call cc-option,-mcpu=532x,-m5307) +cpuflags-$(CONFIG_M537x) = $(call cc-option,-mcpu=537x,-m5307) +cpuflags-$(CONFIG_M5307) = $(call cc-option,-mcpu=5307,-m5200) +cpuflags-$(CONFIG_M528x) = $(call cc-option,-mcpu=528x,-m5307) +cpuflags-$(CONFIG_M5275) = $(call cc-option,-mcpu=5275,-m5307) +cpuflags-$(CONFIG_M5272) = $(call cc-option,-mcpu=5272,-m5307) +cpuflags-$(CONFIG_M5271) = $(call cc-option,-mcpu=5271,-m5307) +cpuflags-$(CONFIG_M523x) = $(call cc-option,-mcpu=523x,-m5307) +cpuflags-$(CONFIG_M525x) = $(call cc-option,-mcpu=5253,-m5200) +cpuflags-$(CONFIG_M5249) = $(call cc-option,-mcpu=5249,-m5200) +cpuflags-$(CONFIG_M520x) = $(call cc-option,-mcpu=5208,-m5200) +cpuflags-$(CONFIG_M5206e) = $(call cc-option,-mcpu=5206e,-m5200) +cpuflags-$(CONFIG_M5206) = $(call cc-option,-mcpu=5206,-m5200) + +# Evaluate tune cc-option calls now +cpuflags-y := $(cpuflags-y) KBUILD_AFLAGS += $(cpuflags-y) KBUILD_CFLAGS += $(cpuflags-y)
Re: [PATCH 29/31] binfmt_flat: use flush_icache_user_range
Hi Christoph, On 10/5/20 5:55 pm, Christoph Hellwig wrote: load_flat_file works on user addresses. Signed-off-by: Christoph Hellwig Acked-by: Greg Ungerer Regards Greg --- fs/binfmt_flat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 831a2b25ba79f..6f0aca5379da2 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -854,7 +854,7 @@ static int load_flat_file(struct linux_binprm *bprm, #endif /* CONFIG_BINFMT_FLAT_OLD */ } - flush_icache_range(start_code, end_code); + flush_icache_user_range(start_code, end_code); /* zero the BSS, BRK and stack areas */ if (clear_user((void __user *)(datapos + data_len), bss_len +
Re: [PATCH 16/31] m68knommu: use asm-generic/cacheflush.h
Hi Christoph,
On 10/5/20 5:54 pm, Christoph Hellwig wrote:
m68knommu needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/include/asm/cacheflush_no.h | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index 11e9a9dcbfb24..2731f07e7be8c 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -9,25 +9,8 @@
#include
#define flush_cache_all() __flush_cache_all()
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr) do { } while (0)
#define flush_dcache_range(start, len)__flush_dcache_all()
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page)do { } while (0)
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping) do { } while (0)
#define flush_icache_range(start, len)__flush_icache_all()
-#define flush_icache_page(vma,pg) do { } while (0)
-#define flush_icache_user_range(vma,pg,adr,len)do { } while (0)
-#define flush_cache_vmap(start, end) do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
- memcpy(dst, src, len)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
- memcpy(dst, src, len)
void mcf_cache_push(void);
@@ -98,4 +81,6 @@ static inline void cache_clear(unsigned long paddr, int len)
__clear_cache_all();
}
+#include
+
#endif /* _M68KNOMMU_CACHEFLUSH_H */
Re: [PATCH 1/7] binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf
One small nit:
On 6/5/20 5:41 am, Eric W. Biederman wrote:
In 2016 Linus moved install_exec_creds immediately after
setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
potential information leak.
Perform the same cleanup for the other binary formats.
Different binary formats doing the same things the same way makes exec
easier to reason about and easier to maintain.
The binfmt_flagt bits were tested by Greg Ungerer
^
flat
Regards
Greg
Ref: 9f834ec18def ("binfmt_elf: switch to new creds when switching to new mm")
Signed-off-by: "Eric W. Biederman"
---
arch/x86/ia32/ia32_aout.c | 3 +--
fs/binfmt_aout.c | 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/binfmt_flat.c | 3 +--
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index 9bb71abd66bd..37b36a8ce5fa 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -140,6 +140,7 @@ static int load_aout_binary(struct linux_binprm *bprm)
set_personality_ia32(false);
setup_new_exec(bprm);
+ install_exec_creds(bprm);
regs->cs = __USER32_CS;
regs->r8 = regs->r9 = regs->r10 = regs->r11 = regs->r12 =
@@ -156,8 +157,6 @@ static int load_aout_binary(struct linux_binprm *bprm)
if (retval < 0)
return retval;
- install_exec_creds(bprm);
-
if (N_MAGIC(ex) == OMAGIC) {
unsigned long text_addr, map_size;
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index 8e8346a81723..ace587b66904 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -162,6 +162,7 @@ static int load_aout_binary(struct linux_binprm * bprm)
set_personality(PER_LINUX);
#endif
setup_new_exec(bprm);
+ install_exec_creds(bprm);
current->mm->end_code = ex.a_text +
(current->mm->start_code = N_TXTADDR(ex));
@@ -174,7 +175,6 @@ static int load_aout_binary(struct linux_binprm * bprm)
if (retval < 0)
return retval;
- install_exec_creds(bprm);
if (N_MAGIC(ex) == OMAGIC) {
unsigned long text_addr, map_size;
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 240f3543..6c94c6d53d97 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -353,6 +353,7 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
current->personality |= READ_IMPLIES_EXEC;
setup_new_exec(bprm);
+ install_exec_creds(bprm);
set_binfmt(_fdpic_format);
@@ -434,7 +435,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
current->mm->start_stack = current->mm->start_brk + stack_size;
#endif
- install_exec_creds(bprm);
if (create_elf_fdpic_tables(bprm, current->mm,
_params, _params) < 0)
goto error;
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 831a2b25ba79..1a1d1fcb893f 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -541,6 +541,7 @@ static int load_flat_file(struct linux_binprm *bprm,
/* OK, This is the point of no return */
set_personality(PER_LINUX_32BIT);
setup_new_exec(bprm);
+ install_exec_creds(bprm);
}
/*
@@ -963,8 +964,6 @@ static int load_flat_binary(struct linux_binprm *bprm)
}
}
- install_exec_creds(bprm);
-
set_binfmt(_format);
#ifdef CONFIG_MMU
Re: exec: Promised cleanups after introducing exec_update_mutex
Hi Eric, On 6/5/20 5:39 am, Eric W. Biederman wrote: In the patchset that introduced exec_update_mutex there were a few last minute discoveries and fixes that left the code in a state that can be very easily be improved. During the merge window we discussed the first three of these patches and I promised I would resend them. What the first patch does is it makes the the calls in the binfmts: flush_old_exec(); /* set the personality */ setup_new_exec(); install_exec_creds(); With no sleeps or anything in between. At the conclusion of this set of changes the the calls in the binfmts are: begin_new_exec(); /* set the personality */ setup_new_exec(); The intent is to make the code easier to follow and easier to change. Eric W. Biederman (7): binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf exec: Make unlocking exec_update_mutex explict exec: Rename the flag called_exec_mmap point_of_no_return exec: Merge install_exec_creds into setup_new_exec exec: In setup_new_exec cache current in the local variable me exec: Move most of setup_new_exec into flush_old_exec exec: Rename flush_old_exec begin_new_exec Documentation/trace/ftrace.rst | 2 +- arch/x86/ia32/ia32_aout.c | 4 +- fs/binfmt_aout.c | 3 +- fs/binfmt_elf.c| 3 +- fs/binfmt_elf_fdpic.c | 3 +- fs/binfmt_flat.c | 4 +- fs/exec.c | 162 - include/linux/binfmts.h| 10 +-- kernel/events/core.c | 2 +- 9 files changed, 92 insertions(+), 101 deletions(-) I tested the the whole series on non-MMU m68k and non-MMU arm (exercising binfmt_flat) and it all tested out with no problems, so for the binfmt_flat changes: Tested-by: Greg Ungerer I reviewed the whole series too, and looks good to me: Reviewed-by: Greg Ungerer Regards Greg --- These changes are against v5.7-rc3. My intention once everything passes code reveiw is to place these changes in a topic branch in my tree and then into linux-next, and eventually to send Linus a pull when the next merge window opens. Unless someone has a better idea. I am a little concerned that I might conflict with the ongoing coredump cleanups. I have several follow up sets of changes with additional cleanups as well but I am trying to keep everything small enough that the code can be reviewed. After enough cleanups I hope to reopen the conversation of dealing with the livelock situation with cred_guard_mutex. As I think figuring out what to do becomes much easier once several of my planned cleanups/improvements have been made. But ultimately I just want to get exec to the point where when we have disucssions on how to make exec better the code is in good enough shape we can actually address the issues we see. Eric
Re: [PATCH] m68k: Drop CONFIG_MTD_M25P80 in stmark2_defconfig
Hi Bin,
On 2/5/20 2:30 pm, Bin Meng wrote:
From: Bin Meng
Drop CONFIG_MTD_M25P80 that was removed in
commit b35b9a10362d ("mtd: spi-nor: Move m25p80 code in spi-nor.c")
Signed-off-by: Bin Meng
Thanks, I will push into the m68knommu git tree, for-next branch.
Regards
Greg
---
arch/m68k/configs/stmark2_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/m68k/configs/stmark2_defconfig
b/arch/m68k/configs/stmark2_defconfig
index 27fa946..2b746f5 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -48,7 +48,6 @@ CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_ROM=y
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PLATRAM=y
-CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there
On 1/5/20 2:54 am, Linus Torvalds wrote: On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: in load_flat_file() - which is also used to loading _libraries_. Where it makes no sense at all. I haven't looked at the shared lib support in there for a long time, but I thought that "id" is only 0 for the actual final program. Libraries have a slot or id number associated with them. Yes, that was my assumption, but looking at the code, it really isn't obvious that that is the case at all. 'id' gets calculated from fields that very much look like they could be zero (eg by taking the top bits from another random field). Most of that file goes back to pre-git days. And most of the commits since are not so much about binfmt_flat, as they are about cleanups or changes elsewhere where binfmt_flat was just a victim. I'll have a look at this. Thanks. Quick hack test shows moving setup_new_exec(bprm) to be just before install_exec_creds(bprm) works fine for the static binaries case. Doing the flush_old_exec(bprm) there too crashed out - I'll need to dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". So to some degree, that's the important one. But that flush_old_exec() does look odd in load_flat_file(). It's not like anything but executing a binary should flush the old exec. Certainly not loading a library, however odd that flat library code is. My _guess_ is that the reason for this is that "load_flat_file()" also does a lot of verification of the file and does that whole "return -ENOEXEC if the file format isn't right". So we don't want to flush the old exec before that is done, but we obviously also don't want to flush the old exec after we've actually loaded the new one into memory.. Yeah, that is what it looks like. Looking at the history, the introduction of setup_new_exec() [in commit 221af7f87b974] was probably just added where the the existing flush_old_exec() was. So the location of flush_old_exec() makes that kind of sense, but it would have made it better if that flat file support had a clear separation of "check the file" from "load the file". Oh well. As mentioned, the whole "at least put setup_new_exec() and install_exec_creds() together" is the bigger thing. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... I am for that. If nobody pipes up and complains I'll look at taking it out. Regards Greg
Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there
On 1/5/20 12:51 am, Rich Felker wrote:
On Fri, May 01, 2020 at 12:10:05AM +1000, Greg Ungerer wrote:
On 30/4/20 9:03 am, Linus Torvalds wrote:
On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin
wrote:
I've never had any reason to use FDPIC, and I don't have any binaries
that would use it. Nicolas Pitre added ARM support, so I guess he
would be the one to talk to about it. (Added Nicolas.)
While we're at it, is there anybody who knows binfmt_flat?
It might be Nicolas too.
binfmt_flat doesn't do core-dumping, but it has some other oddities.
In particular, I'd like to bring sanity to the installation of the new
creds, and all the _normal_ binfmt cases do it largely close together
with setup_new_exec().
binfmt_flat is doing odd things. It's doing this:
/* Flush all traces of the currently running executable */
if (id == 0) {
ret = flush_old_exec(bprm);
if (ret)
goto err;
/* OK, This is the point of no return */
set_personality(PER_LINUX_32BIT);
setup_new_exec(bprm);
}
in load_flat_file() - which is also used to loading _libraries_. Where
it makes no sense at all.
I haven't looked at the shared lib support in there for a long time,
but I thought that "id" is only 0 for the actual final program.
Libraries have a slot or id number associated with them.
This sounds correct. My understanding of FLAT shared library support
is that it's really bad and based on having preassigned slot indices
for each library on the system, and a global array per-process to give
to data base address for each library. Libraries are compiled to know
their own slot numbers so that they just load from fixed_reg[slot_id]
to get what's effectively their GOT pointer.
I'm not sure if anybody has actually used this in over a decade. Last
time I looked the tooling appeared broken, but in this domain lots of
users have forked private tooling that's not publicly available or at
least not publicly indexed, so it's hard to say for sure.
Be at least 12 or 13 years since I last had a working shared library
build for m68knommu. I have not bothered with it since then, not that I
even used it much when it worked. Seemed more pain than it was worth.
Regards
Greg
Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there
On 1/5/20 5:07 am, Eric W. Biederman wrote: Linus Torvalds writes: On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: Most of that file goes back to pre-git days. And most of the commits since are not so much about binfmt_flat, as they are about cleanups or changes elsewhere where binfmt_flat was just a victim. I'll have a look at this. Thanks. Quick hack test shows moving setup_new_exec(bprm) to be just before install_exec_creds(bprm) works fine for the static binaries case. Doing the flush_old_exec(bprm) there too crashed out - I'll need to dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". But it is only half a help if we allow failure points between flush_old_exec and install_exec_creds. Greg do things work acceptably if install_exec_creds is moved to right after setup_new_exec? (patch below) Yes, confirmed. Worked fine with that patch applied. Looking at the code in load_flat_file after setup_new_exec it looks like the kinds of things that in binfmt_elf.c we do after install_exec_creds (aka vm_map). So I think we want install_exec_creds sooner, instead of setup_new_exec later. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... I looked a little deeper and there is another reason to think about ripping out the flat library loader. The code is recursive, and supports a maximum of 4 shared libraries in the entire system. load_flat_binary load_flat_file calc_reloc load_flat_shared_libary load_flat_file I am mystified with what kind of system can survive with a grand total of 4 shared libaries. I think my a.out slackware system that I ran on my i486 had more shared libraries. The kind of embedded systems that were built with this stuff 20 years ago didn't have lots of applications and libraries. I think we found back then that most of your savings were from making libc shared. Less significant gains from making other libraries shared. And there was a bit of extra pain in setting them up with the shared library code generation options (that had to be unique for each one). The whole mechanism is a bit of hack, and there was a few other limitations with the way it worked (I don't recall what they were right now). I am definitely in favor of removing it. Regards Greg Having read just a bit more it is definitely guaranteed (by the code) that the first time load_flat_file is called id 0 will be used (aka id 0 is guaranteed to be the binary), and the ids 1, 2, 3 and 4 will only be used if a relocation includes that id to reference an external shared library. That part of the code is drop dead simple. --- This is what I was thinking about applying. diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 831a2b25ba79..1a1d1fcb893f 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -541,6 +541,7 @@ static int load_flat_file(struct linux_binprm *bprm, /* OK, This is the point of no return */ set_personality(PER_LINUX_32BIT); setup_new_exec(bprm); + install_exec_creds(bprm); } /* @@ -963,8 +964,6 @@ static int load_flat_binary(struct linux_binprm *bprm) } } - install_exec_creds(bprm); - set_binfmt(_format); #ifdef CONFIG_MMU
Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there
On 30/4/20 9:03 am, Linus Torvalds wrote:
On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin
wrote:
I've never had any reason to use FDPIC, and I don't have any binaries
that would use it. Nicolas Pitre added ARM support, so I guess he
would be the one to talk to about it. (Added Nicolas.)
While we're at it, is there anybody who knows binfmt_flat?
It might be Nicolas too.
binfmt_flat doesn't do core-dumping, but it has some other oddities.
In particular, I'd like to bring sanity to the installation of the new
creds, and all the _normal_ binfmt cases do it largely close together
with setup_new_exec().
binfmt_flat is doing odd things. It's doing this:
/* Flush all traces of the currently running executable */
if (id == 0) {
ret = flush_old_exec(bprm);
if (ret)
goto err;
/* OK, This is the point of no return */
set_personality(PER_LINUX_32BIT);
setup_new_exec(bprm);
}
in load_flat_file() - which is also used to loading _libraries_. Where
it makes no sense at all.
I haven't looked at the shared lib support in there for a long time,
but I thought that "id" is only 0 for the actual final program.
Libraries have a slot or id number associated with them.
It does the
install_exec_creds(bprm);
in load_flat_binary() (which makes more sense: that is only for actual
binary loading, no library case).
I would _like_ for every binfmt loader to do
/* Flush all traces of the currently running executable */
retval = flush_old_exec(bprm);
if (retval)
return retval;
.. possibly set up personalities here ..
setup_new_exec(bprm);
install_exec_creds(bprm);
all together, and at least merge 'setup_new_exec()' with 'install_exec_creds()'.
And I think all the binfmt handlers would be ok with that, but the
flat one in particular is really oddly set up.
*Particularly* with that flush_old_exec/setup_new_exec() being done by
the same routine that is also loading libraries (and called from
'calc_reloc()' from binary loading too).
Adding Greg Ungerer for m68knommu. Can somebody sort out why that
flush_old_exec/setup_new_exec() isn't in load_flat_binary() like
install_exec_creds() is?
Most of that file goes back to pre-git days. And most of the commits
since are not so much about binfmt_flat, as they are about cleanups or
changes elsewhere where binfmt_flat was just a victim.
I'll have a look at this.
Quick hack test shows moving setup_new_exec(bprm) to be just before
install_exec_creds(bprm) works fine for the static binaries case.
Doing the flush_old_exec(bprm) there too crashed out - I'll need to
dig into that to see why.
Regards
Greg
Re: [PATCH 10/34] m68k/coldfire: Use CONFIG_PREEMPTION
Hi Sebastian, On 16/10/19 5:55 pm, Sebastian Andrzej Siewior wrote: On 2019-10-16 10:50:41 [+1000], Greg Ungerer wrote: Hi Sebastian, Hi Greg, On 16/10/19 5:17 am, Sebastian Andrzej Siewior wrote: From: Thomas Gleixner CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Switch the entry code over to use CONFIG_PREEMPTION. Cc: Greg Ungerer Acked-by: Greg Ungerer Thank you. Do you want me to take this via the m68knommu git tree? Or are you taking the whole series via some other tree? It is up to you. You have all the dependencies so you can either add it to your -next branch or leave it and we will pick it up for you. Patch added to the m68knommu git tree, for-next branch. Thanks Greg
Re: [PATCH 10/34] m68k/coldfire: Use CONFIG_PREEMPTION
Hi Sebastian, On 16/10/19 5:17 am, Sebastian Andrzej Siewior wrote: From: Thomas Gleixner CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Switch the entry code over to use CONFIG_PREEMPTION. Cc: Greg Ungerer Acked-by: Greg Ungerer Do you want me to take this via the m68knommu git tree? Or are you taking the whole series via some other tree? Regards Greg Cc: Geert Uytterhoeven Cc: linux-m...@lists.linux-m68k.org Signed-off-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior --- arch/m68k/coldfire/entry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S index 52d312d5b4d4f..d43a02795a4a4 100644 --- a/arch/m68k/coldfire/entry.S +++ b/arch/m68k/coldfire/entry.S @@ -108,7 +108,7 @@ ENTRY(system_call) btst#5,%sp@(PT_OFF_SR) /* check if returning to kernel */ jeq Luser_return/* if so, skip resched, signals */ -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPTION movel %sp,%d1 /* get thread_info pointer */ andl#-THREAD_SIZE,%d1 /* at base of kernel stack */ movel %d1,%a0
[git pull] m68knommu changes for v5.4
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, fix up header include in ColdFire specific GPIO handling code. Regards Greg The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e: Linux 5.3-rc8 (2019-09-08 13:33:15 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 372ea263b3d9cdeb70f8cffa025b2e0875e51b62: m68k: coldfire: Include the GPIO driver header (2019-09-09 09:32:32 +1000) Linus Walleij (1): m68k: coldfire: Include the GPIO driver header arch/m68k/coldfire/gpio.c | 1 + 1 file changed, 1 insertion(+)
Re: [PATCH 01/16] ARM: remove ks8695 platform
Hi Arnd, On 10/8/19 6:27 am, Arnd Bergmann wrote: ks8695 is an older SoC originally made by Kendin, which was later acquired by Micrel, and subsequently by Microchip. The platform port was originally contributed by Andrew Victor and Ben Dooks, and later maintained by Greg Ungerer. When I recently submitted cleanups, but Greg noted that the platform no longer boots and nobody is using it any more, we decided to remove it. Cc: Greg Ungerer Acked-by: Greg Ungerer Thanks for taking care of this. Regards Greg Cc: Andrew Victor Cc: Ben Dooks Link: https://wikidevi.com/wiki/Micrel Link: https://lore.kernel.org/linux-arm-kernel/2bc41895-d4f9-896c-0726-0b2862fcb...@kernel.org/ Signed-off-by: Arnd Bergmann --- MAINTAINERS | 6 - arch/arm/Kconfig | 16 +- arch/arm/Kconfig.debug| 8 - arch/arm/Makefile | 1 - arch/arm/configs/acs5k_defconfig | 77 -- arch/arm/configs/acs5k_tiny_defconfig | 69 - arch/arm/configs/ks8695_defconfig | 67 - arch/arm/include/debug/ks8695.S | 37 --- arch/arm/mach-ks8695/Kconfig | 88 --- arch/arm/mach-ks8695/Makefile | 23 -- arch/arm/mach-ks8695/Makefile.boot| 9 - arch/arm/mach-ks8695/board-acs5k.c| 238 - arch/arm/mach-ks8695/board-dsm320.c | 127 - arch/arm/mach-ks8695/board-micrel.c | 59 - arch/arm/mach-ks8695/board-og.c | 197 -- arch/arm/mach-ks8695/board-sg.c | 118 - arch/arm/mach-ks8695/cpu.c| 60 - arch/arm/mach-ks8695/devices.c| 197 -- arch/arm/mach-ks8695/devices.h| 29 -- arch/arm/mach-ks8695/generic.h| 12 - .../mach-ks8695/include/mach/entry-macro.S| 47 .../mach-ks8695/include/mach/gpio-ks8695.h| 36 --- arch/arm/mach-ks8695/include/mach/hardware.h | 42 --- arch/arm/mach-ks8695/include/mach/irqs.h | 51 arch/arm/mach-ks8695/include/mach/memory.h| 51 arch/arm/mach-ks8695/include/mach/regs-gpio.h | 55 arch/arm/mach-ks8695/include/mach/regs-irq.h | 41 --- arch/arm/mach-ks8695/include/mach/regs-misc.h | 97 --- .../mach-ks8695/include/mach/regs-switch.h| 66 - arch/arm/mach-ks8695/include/mach/regs-uart.h | 89 --- .../arm/mach-ks8695/include/mach/uncompress.h | 33 --- arch/arm/mach-ks8695/irq.c| 164 arch/arm/mach-ks8695/pci.c| 247 -- arch/arm/mach-ks8695/regs-hpna.h | 25 -- arch/arm/mach-ks8695/regs-lan.h | 65 - arch/arm/mach-ks8695/regs-mem.h | 89 --- arch/arm/mach-ks8695/regs-pci.h | 53 arch/arm/mach-ks8695/regs-sys.h | 34 --- arch/arm/mach-ks8695/regs-wan.h | 65 - arch/arm/mach-ks8695/time.c | 159 --- arch/arm/mm/Kconfig | 2 +- 41 files changed, 5 insertions(+), 2944 deletions(-) delete mode 100644 arch/arm/configs/acs5k_defconfig delete mode 100644 arch/arm/configs/acs5k_tiny_defconfig delete mode 100644 arch/arm/configs/ks8695_defconfig delete mode 100644 arch/arm/include/debug/ks8695.S delete mode 100644 arch/arm/mach-ks8695/Kconfig delete mode 100644 arch/arm/mach-ks8695/Makefile delete mode 100644 arch/arm/mach-ks8695/Makefile.boot delete mode 100644 arch/arm/mach-ks8695/board-acs5k.c delete mode 100644 arch/arm/mach-ks8695/board-dsm320.c delete mode 100644 arch/arm/mach-ks8695/board-micrel.c delete mode 100644 arch/arm/mach-ks8695/board-og.c delete mode 100644 arch/arm/mach-ks8695/board-sg.c delete mode 100644 arch/arm/mach-ks8695/cpu.c delete mode 100644 arch/arm/mach-ks8695/devices.c delete mode 100644 arch/arm/mach-ks8695/devices.h delete mode 100644 arch/arm/mach-ks8695/generic.h delete mode 100644 arch/arm/mach-ks8695/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-ks8695/include/mach/gpio-ks8695.h delete mode 100644 arch/arm/mach-ks8695/include/mach/hardware.h delete mode 100644 arch/arm/mach-ks8695/include/mach/irqs.h delete mode 100644 arch/arm/mach-ks8695/include/mach/memory.h delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-gpio.h delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-irq.h delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-misc.h delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-switch.h delete mode 100644 arch/arm/mach-ks8695/include/mach/regs-uart.h delete mode 100644 arch/arm/mach-ks8695/include/mach/uncompress.h delete mode 100644 arch/arm/mach-ks8695/irq.c delete mode 100644 arch/arm/mach-ks8695/pci.c delete mode 100644 arch/arm/mach-ks8695
Re: [PATCH] m68k: Prevent some compiler warnings in coldfire builds
Hi Geert,
On 5/8/19 5:14 pm, Geert Uytterhoeven wrote:
On Sat, Aug 3, 2019 at 1:36 AM Greg Ungerer wrote:
On 2/8/19 10:10 am, Finn Thain wrote:
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/macintosh.h.
The inclusion of asm/atarihw.h causes warnings like this:
In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
from arch/m68k/kernel/setup_mm.c:41,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
#define __raw_readb in_8
In file included from ./arch/m68k/include/asm/io.h:6:0,
from arch/m68k/kernel/setup_mm.c:36,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
previous definition
#define __raw_readb(addr) \
...
This issue is resolved by dropping the asm/raw_io.h include. It turns out
that asm/io_mm.h already includes that header file.
Moving the relevant macro definitions helps to clarify this dependency
and make it safe to include asm/atarihw.h.
The other warnings look like this:
In file included from arch/m68k/kernel/setup_mm.c:48:0,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data' declared
inside parameter list will not be visible outside of this definition or
declaration
extern void mac_irq_enable(struct irq_data *data);
^~~~
...
This issue is resolved by adding the missing linux/irq.h include.
Cc: Michael Schmitz
Signed-off-by: Finn Thain
Looks good to me:
Acked-by: Greg Ungerer
Geert: I can take this via the m68knommu tree if you like?
Or if you want to pick it up then no problem.
If you have fixes for m68knommu for v5.3, feel free to queue it.
Else I can queue it for v5.4.
Reviewed-by: Geert Uytterhoeven
I don't currently have any fixes for 5.3 queued.
And there is no real hurry on this anyway, it can wait for 5.4.
So please add to your queue for 5.4
Regards
Greg
Re: [PATCH] m68k: Prevent some compiler warnings in coldfire builds
Hi Finn,
On 2/8/19 10:10 am, Finn Thain wrote:
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/macintosh.h.
The inclusion of asm/atarihw.h causes warnings like this:
In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
from arch/m68k/kernel/setup_mm.c:41,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
#define __raw_readb in_8
In file included from ./arch/m68k/include/asm/io.h:6:0,
from arch/m68k/kernel/setup_mm.c:36,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
previous definition
#define __raw_readb(addr) \
...
This issue is resolved by dropping the asm/raw_io.h include. It turns out
that asm/io_mm.h already includes that header file.
Moving the relevant macro definitions helps to clarify this dependency
and make it safe to include asm/atarihw.h.
The other warnings look like this:
In file included from arch/m68k/kernel/setup_mm.c:48:0,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data' declared
inside parameter list will not be visible outside of this definition or
declaration
extern void mac_irq_enable(struct irq_data *data);
^~~~
...
This issue is resolved by adding the missing linux/irq.h include.
Cc: Michael Schmitz
Signed-off-by: Finn Thain
---
arch/m68k/include/asm/atarihw.h | 9 -
arch/m68k/include/asm/io_mm.h | 6 +-
arch/m68k/include/asm/macintosh.h | 1 +
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 533008262b69..5e5601c382b8 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -22,7 +22,6 @@
#include
#include
-#include
#include
extern u_long atari_mch_cookie;
@@ -132,14 +131,6 @@ extern struct atari_hw_present atari_hw_present;
*/
-#define atari_readb raw_inb
-#define atari_writeb raw_outb
-
-#define atari_inb_p raw_inb
-#define atari_outb_p raw_outb
-
-
-
#include
#include
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 6c03ca5bc436..819f611dccf2 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -29,7 +29,11 @@
#include
#ifdef CONFIG_ATARI
-#include
+#define atari_readb raw_inb
+#define atari_writeb raw_outb
+
+#define atari_inb_p raw_inb
+#define atari_outb_p raw_outb
#endif
diff --git a/arch/m68k/include/asm/macintosh.h b/arch/m68k/include/asm/macintosh.h
index 8f0698bca3dc..8a43babcf53a 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
Looks good to me:
Acked-by: Greg Ungerer
Geert: I can take this via the m68knommu tree if you like?
Or if you want to pick it up then no problem.
Regards
Greg
Re: [PATCH 1/6] ARM: ks8695: watchdog: stop using mach/*.h
Hi Arnd, On 23/7/19 12:44 am, Arnd Bergmann wrote: On Sat, May 4, 2019 at 4:27 PM Greg Ungerer wrote: On 4/5/19 3:06 am, Guenter Roeck wrote: On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote: On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote: Ultimately though I am left wondering if the ks8695 support in the kernel is useful to anyone the way it is at the moment. With a minimal kernel configuration I can boot up to a shell - but the system is really unreliable if you try to interactively use it. I don't think it is the hardware - it seems to run reliably with the old code it has running from flash on it. I am only testing the new kernel, running with the existing user space root filesystem on it (which dates from 2004 :-) Personally I think it is a bad sign that this subarch and boards do not have active OpenWrt support, they are routers after all (right?) and any active use of networking equipment should use a recent userspace as well, given all the security bugs that popped up over the years. Looking around on the internet, I found that Micrel at some point had their own openwrt fork for ks8695, but I can't find a copy any more, as the micrel.com domain is no longer used after the acquisition by Microchip. I build it with uClinux-dist, https://sourceforge.net/projects/uclinux/files/uClinux%20Stable/. And again I can build for it, it just doesn't currently work in any sort of reasonable way. So I get the impression it hasn't worked for a while and nobody has noticed. https://wikidevi.com/wiki/Micrel has a list of devices based on ks8695, and it seems that most of these are rather memory limited, which is a problem for recent openwrt builds. Only two of the 17 listed devices have the absolute minimum of 4MB flash and 32MB RAM for openwrt, two more have 8/32 and one or two have 4/64, but all these configurations are too limited for the web U/I now. With IXP4xx, Gemini and EP93xx we have found active users and companies selling the chips and reference designs and even recommending it for new products (!) at times. If this is not the case with KS8695 and no hobbyists are willing to submit it to OpenWrt and modernize it to use device tree I think it should be deleted from the kernel. That may be the best approach if indeed no one is using it, much less maintaining it. Well, I for one don't really use it any more. So I don't have a lot of motivation to maintain it any longer. I came across my patches while rebasing my backlog to 5.3-rc1. Should I save the (very small) trouble of sending them out again and just remove the platform then? At this time I have no issue with removing it. Regards Greg
[git pull] m68knommu changes for v5.3
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
A series of cleanups for the FLAT format binary loader, binfmt_flat,
from Christoph. The end goal is to support no-MMU on RISC-V, and the
last patch enables that.
Regards
Greg
The following changes since commit 4b972a01a7da614b4796475f933094751a295a2f:
Linux 5.2-rc6 (2019-06-22 16:01:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
for you to fetch changes up to ad97f9df0fee4ddc9ef056dda4dcbc6630d9f972:
riscv: add binfmt_flat support (2019-06-24 09:16:47 +1000)
Christoph Hellwig (17):
binfmt_flat: remove flat_reloc_valid
binfmt_flat: remove flat_set_persistent
binfmt_flat: provide a default version of flat_get_relocate_addr
binfmt_flat: remove flat_old_ram_flag
binfmt_flat: replace flat_argvp_envp_on_stack with a Kconfig variable
binfmt_flat: remove the uapi header
binfmt_flat: remove the unused OLD_FLAT_FLAG_RAM definition
binfmt_flat: consolidate two version of flat_v2_reloc_t
binfmt_flat: use fixed size type for the on-disk format
binfmt_flat: add endianess annotations
binfmt_flat: add a ARCH_HAS_BINFMT_FLAT option
binfmt_flat: make support for old format binaries optional
binfmt_flat: provide an asm-generic/flat.h
binfmt_flat: remove the persistent argument from flat_get_addr_from_rp
binfmt_flat: move the MAX_SHARED_LIBS definition to binfmt_flat.c
binfmt_flat: don't offset the data start
riscv: add binfmt_flat support
arch/arm/Kconfig | 2 +
arch/arm/include/asm/Kbuild| 1 +
arch/c6x/Kconfig | 1 +
arch/c6x/include/asm/flat.h| 7 +-
arch/h8300/Kconfig | 3 +
arch/h8300/include/asm/flat.h | 7 +-
arch/m68k/Kconfig | 2 +
arch/m68k/include/asm/flat.h | 30 +--
arch/microblaze/Kconfig| 1 +
arch/microblaze/include/asm/flat.h | 7 +-
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/Kbuild | 1 +
arch/sh/Kconfig| 1 +
arch/sh/include/asm/flat.h | 7 +-
arch/xtensa/Kconfig| 1 +
arch/xtensa/include/asm/flat.h | 7 +-
fs/Kconfig.binfmt | 18 +++-
fs/binfmt_flat.c | 99 ++
.../arm/include/asm => include/asm-generic}/flat.h | 19 +
include/linux/flat.h | 58 +
include/uapi/linux/flat.h | 59 -
21 files changed, 145 insertions(+), 187 deletions(-)
rename {arch/arm/include/asm => include/asm-generic}/flat.h (55%)
delete mode 100644 include/uapi/linux/flat.h
Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
Hi Geert,
On 26/6/19 6:18 pm, Geert Uytterhoeven wrote:
Hi Greg,
On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer wrote:
On 26/6/19 8:29 am, Al Viro wrote:
On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
Two branches of the ifdef maze actually have the same content, so merge
them.
Signed-off-by: Christoph Hellwig
---
include/linux/flat.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/flat.h b/include/linux/flat.h
index 2b7cda6e9c1b..19c586b74b99 100644
--- a/include/linux/flat.h
+++ b/include/linux/flat.h
@@ -69,15 +69,13 @@ struct flat_hdr {
typedef union {
unsigned long value;
struct {
-# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
+#if defined(__LITTLE_ENDIAN_BITFIELD) || \
+(defined(mc68000) && !defined(CONFIG_COLDFIRE))
signed long offset : 30;
unsigned long type : 2;
# elif defined(__BIG_ENDIAN_BITFIELD)
unsigned long type : 2;
signed long offset : 30;
-# elif defined(__LITTLE_ENDIAN_BITFIELD)
-signed long offset : 30;
-unsigned long type : 2;
# else
# error "Unknown bitfield order for flat files."
# endif
--
2.20.1
FWIW, I wonder if keeping that type is worth bothering.
Something like
old_reloc(__be32 reloc)
{
u32 v = be32_to_cpu(reloc);
int offset, type;
#if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
/* old m68k uses unusual format - type is in lower bits of octet 3 */
type = v % 4;
offset = (int)v / 4;
#else
/* everything else (including coldfire) has it in upper bits of octet 0
*/
type = v >> 30;
offset = (int)(v << 2) >> 2; /* or (v & 0x1fff) - (v & 0x2000) *
4 */
#endif
...
and to hell with bitfields, aliasing unions, etc. Unless I'm misreading
the whole thing, that is... Greg?
I think you are right. This is much better.
The old mc6800 is the odd one out, the rest have it in network order,
and this makes that much clearer.
Is that correct for Microblaze, which can be big or little endian?
It is true for all architectures that use flat. All fields inside a
flat format binary are store in network order.
The final processing of the relocation entries in the elf2flt
converter tool:
for (i=0; i
Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
On 26/6/19 8:29 am, Al Viro wrote:
On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
Two branches of the ifdef maze actually have the same content, so merge
them.
Signed-off-by: Christoph Hellwig
---
include/linux/flat.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/flat.h b/include/linux/flat.h
index 2b7cda6e9c1b..19c586b74b99 100644
--- a/include/linux/flat.h
+++ b/include/linux/flat.h
@@ -69,15 +69,13 @@ struct flat_hdr {
typedef union {
unsigned long value;
struct {
-# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
+#if defined(__LITTLE_ENDIAN_BITFIELD) || \
+(defined(mc68000) && !defined(CONFIG_COLDFIRE))
signed long offset : 30;
unsigned long type : 2;
# elif defined(__BIG_ENDIAN_BITFIELD)
unsigned long type : 2;
signed long offset : 30;
-# elif defined(__LITTLE_ENDIAN_BITFIELD)
- signed long offset : 30;
- unsigned long type : 2;
# else
# error "Unknown bitfield order for flat files."
# endif
--
2.20.1
FWIW, I wonder if keeping that type is worth bothering.
Something like
old_reloc(__be32 reloc)
{
u32 v = be32_to_cpu(reloc);
int offset, type;
#if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
/* old m68k uses unusual format - type is in lower bits of octet 3 */
type = v % 4;
offset = (int)v / 4;
#else
/* everything else (including coldfire) has it in upper bits of octet 0
*/
type = v >> 30;
offset = (int)(v << 2) >> 2; /* or (v & 0x1fff) - (v & 0x2000)
* 4 */
#endif
...
and to hell with bitfields, aliasing unions, etc. Unless I'm misreading
the whole thing, that is... Greg?
I think you are right. This is much better.
The old mc6800 is the odd one out, the rest have it in network order,
and this makes that much clearer.
Regards
Greg
Re: binfmt_flat cleanups and RISC-V support v2
Hi Christoph, On 13/6/19 5:08 pm, Christoph Hellwig wrote: below is a larger stash of cleanups for the binfmt_misc code, preparing for the last patch that now trivially adds RISC-V support, which will be used for the RISC-V nommu series I am about to post. Changes since v2: - fix the handling of old format flags - don't pass arguments on stack for RISC-V - small cleanups for flat_v2_reloc_t Thanks for doing this work. Tested and works for me on m68k/Coldfire too. I have pushed these onto the for-next branch of the m68knommu git tree. Regards Greg
Re: [PATCH 04/15] binfmt_flat: remove flat_old_ram_flag
On 11/6/19 5:36 pm, Christoph Hellwig wrote: On Tue, Jun 11, 2019 at 04:04:39PM +1000, Greg Ungerer wrote: index c0e4535dc1ec..18d82fd5f57c 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -488,7 +488,8 @@ static int load_flat_file(struct linux_binprm *bprm, * fix up the flags for the older format, there were all kinds * of endian hacks, this only works for the simple cases */ - if (rev == OLD_FLAT_VERSION && flat_old_ram_flag(flags)) + if (IS_ENABLED(CONFIG_BINFMT_FLAT_OLD_ALWAYS_RAM) && + rev == OLD_FLAT_VERSION) The flags are from the binary file header here, so this is going to lose that check for most platforms (except h8300 where it would always have been true). Indeed. The old code is: if (rev == OLD_FLAT_VERSION && flat_old_ram_flag(flags)) flags = FLAT_FLAG_RAM; which for !h8300 evaluates to: if (rev == OLD_FLAT_VERSION && flags) flags = FLAT_FLAG_RAM; so basically if any flag was set it was turned into FLAT_FLAG_RAM. Was that really intentional? Probably not, looking at the flags. For the compressed flag it makes some sense. But I don't think many of the others need load to RAM behavior. I guess even if it wasn't the is no point in changing this historic behavior now. So I guess what we could do it something like: if (rev == OLD_FLAT_VERSION && (flags || IS_ENABLED(CONFIG_BINFMT_FLAT_OLD_ALWAYS_RAM))) flags = FLAT_FLAG_RAM; Yeah, that to looks to preserve the old behavior. Regards Greg
Re: binfmt_flat cleanups and RISC-V support
On 11/6/19 5:38 pm, Christoph Hellwig wrote: On Tue, Jun 11, 2019 at 04:51:02PM +1000, Greg Ungerer wrote: Hi Christoph, On 11/6/19 7:20 am, Christoph Hellwig wrote: below is a larger stash of cleanups for the binfmt_misc code, preparing for the last patch that now trivially adds RISC-V support, which will be used for the RISC-V nommu series I am about to post. Whole series looks pretty good. Just the one comment I made. I normally take these through the m68knommu git tree, if you have no problem with that I'll push it in there. It will hit linux-next from there. Yes, that's fine. We'll need it to bring up riscv nommu support, but there is no actual dependency on the patches for it to compile, just for it to actually be useful. Btw, it seems like the uclinux-dev list is dead, is there a replacement for it? No, unfortunately no replacement. Generally I think anything that comes up goes to the architecture list that issues come up on. Probably not ideal, especially for things like this that are across all arches. Regards Greg
Re: binfmt_flat cleanups and RISC-V support
Hi Christoph, On 11/6/19 7:20 am, Christoph Hellwig wrote: below is a larger stash of cleanups for the binfmt_misc code, preparing for the last patch that now trivially adds RISC-V support, which will be used for the RISC-V nommu series I am about to post. Whole series looks pretty good. Just the one comment I made. I normally take these through the m68knommu git tree, if you have no problem with that I'll push it in there. It will hit linux-next from there. Thanks Greg
Re: [PATCH 04/15] binfmt_flat: remove flat_old_ram_flag
Hi Christoph,
On 11/6/19 7:20 am, Christoph Hellwig wrote:
Instead add a Kconfig variable that only h8300 selects.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/flat.h| 1 -
arch/c6x/include/asm/flat.h| 1 -
arch/h8300/Kconfig | 1 +
arch/h8300/include/asm/flat.h | 1 -
arch/m68k/include/asm/flat.h | 1 -
arch/microblaze/include/asm/flat.h | 1 -
arch/sh/include/asm/flat.h | 1 -
arch/xtensa/include/asm/flat.h | 1 -
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 3 ++-
10 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index a185fe023b60..acf162111ee2 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -9,7 +9,6 @@
#include
#define flat_argvp_envp_on_stack() 1
-#defineflat_old_ram_flag(flags)(flags)
static inline int flat_get_addr_from_rp(u32 __user *rp, u32 relval, u32 flags,
u32 *addr, u32 *persistent)
diff --git a/arch/c6x/include/asm/flat.h b/arch/c6x/include/asm/flat.h
index c4d703b454c6..353e4d06e8c0 100644
--- a/arch/c6x/include/asm/flat.h
+++ b/arch/c6x/include/asm/flat.h
@@ -5,7 +5,6 @@
#include
#define flat_argvp_envp_on_stack() 0
-#define flat_old_ram_flag(flags) (flags)
static inline int flat_get_addr_from_rp(u32 __user *rp, u32 relval, u32 flags,
u32 *addr, u32 *persistent)
{
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index ecfc4b4b6373..d30e8727b02d 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -2,6 +2,7 @@
config H8300
def_bool y
select ARCH_32BIT_OFF_T
+ select BINFMT_FLAT_OLD_ALWAYS_RAM
select GENERIC_ATOMIC64
select HAVE_UID16
select VIRT_TO_BUS
diff --git a/arch/h8300/include/asm/flat.h b/arch/h8300/include/asm/flat.h
index 7ef7eefded3d..14cc928d5478 100644
--- a/arch/h8300/include/asm/flat.h
+++ b/arch/h8300/include/asm/flat.h
@@ -9,7 +9,6 @@
#include
#define flat_argvp_envp_on_stack() 1
-#defineflat_old_ram_flag(flags)1
/*
* on the H8 a couple of the relocations have an instruction in the
diff --git a/arch/m68k/include/asm/flat.h b/arch/m68k/include/asm/flat.h
index 217fa89c8e34..7b1fb5c2809e 100644
--- a/arch/m68k/include/asm/flat.h
+++ b/arch/m68k/include/asm/flat.h
@@ -9,7 +9,6 @@
#include
#define flat_argvp_envp_on_stack() 1
-#defineflat_old_ram_flag(flags)(flags)
static inline int flat_get_addr_from_rp(u32 __user *rp, u32 relval, u32 flags,
u32 *addr, u32 *persistent)
{
diff --git a/arch/microblaze/include/asm/flat.h
b/arch/microblaze/include/asm/flat.h
index 846084fa7f04..1cd8d7f4cf12 100644
--- a/arch/microblaze/include/asm/flat.h
+++ b/arch/microblaze/include/asm/flat.h
@@ -14,7 +14,6 @@
#include
#define flat_argvp_envp_on_stack() 0
-#defineflat_old_ram_flag(flags)(flags)
/*
* Microblaze works a little differently from other arches, because
diff --git a/arch/sh/include/asm/flat.h b/arch/sh/include/asm/flat.h
index 0d520b4cc5ea..015678d7b771 100644
--- a/arch/sh/include/asm/flat.h
+++ b/arch/sh/include/asm/flat.h
@@ -12,7 +12,6 @@
#include
#define flat_argvp_envp_on_stack() 0
-#defineflat_old_ram_flag(flags)(flags)
static inline int flat_get_addr_from_rp(u32 __user *rp, u32 relval, u32 flags,
u32 *addr, u32 *persistent)
{
diff --git a/arch/xtensa/include/asm/flat.h b/arch/xtensa/include/asm/flat.h
index a1d88aa3ef8a..b215c1e66958 100644
--- a/arch/xtensa/include/asm/flat.h
+++ b/arch/xtensa/include/asm/flat.h
@@ -5,7 +5,6 @@
#include
#define flat_argvp_envp_on_stack() 0
-#define flat_old_ram_flag(flags) (flags)
static inline int flat_get_addr_from_rp(u32 __user *rp, u32 relval, u32 flags,
u32 *addr, u32 *persistent)
{
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index f87ddd1b6d72..5658e12ad944 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -97,6 +97,9 @@ config BINFMT_FLAT
help
Support uClinux FLAT format binaries.
+config BINFMT_FLAT_OLD_ALWAYS_RAM
+ bool
+
config BINFMT_ZFLAT
bool "Enable ZFLAT support"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index c0e4535dc1ec..18d82fd5f57c 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -488,7 +488,8 @@ static int load_flat_file(struct linux_binprm *bprm,
* fix up the flags for the older format, there were all kinds
* of endian hacks, this only works for the simple cases
*/
- if (rev == OLD_FLAT_VERSION && flat_old_ram_flag(flags))
+ if
Re: [PATCH] m68k: io: Fix io{read,write}{16,32}be() for Coldfire peripherals
Hi Geert, On 4/6/19 5:34 pm, Geert Uytterhoeven wrote: On Tue, Jun 4, 2019 at 9:18 AM Greg Ungerer wrote: On 3/6/19 10:26 pm, Angelo Dureghello wrote: couldn't seen any follow up on this patch. I tested it and at least for mcf5441x it works properly and solves all issues. Do you think it may be accepted as an initial fix ? I'll add it to the m68knommu git tree. Seeing as you wrote it Geert I assume you have no problem with that? :-) Actually I wanted to look into the issues pointed out by Arnd, but didn't get to that yet... Ok, no worries. I won't do anything with this right now then. Regards Greg
Re: [PATCH] m68k: io: Fix io{read,write}{16,32}be() for Coldfire peripherals
Hi Angelo,
On 3/6/19 10:26 pm, Angelo Dureghello wrote:
couldn't seen any follow up on this patch. I tested it and at least
for mcf5441x it works properly and solves all issues.
Do you think it may be accepted as an initial fix ?
I'll add it to the m68knommu git tree.
Seeing as you wrote it Geert I assume you have no problem with that? :-)
Regards
Greg
On Mon, Apr 29, 2019 at 10:19:37AM +0200, Geert Uytterhoeven wrote:
The generic definitions of mmio_{read,write}{16,32}be() in lib/iomap.c
assume that the {read,write}[wl]() I/O accessors always use little
endian accesses, and swap the result.
However, the Coldfire versions of the {read,write}[wl]() I/O accessors are
special, in that they use native big endian instead of little endian for
accesses to the on-SoC peripheral block, thus violating the assumption.
Fix this by providing our own variants, using the raw accessors,
reinstating the old behavior. This is fine on m68k, as no special
barriers are needed, and also avoids swapping data twice.
Reported-by: Angelo Dureghello
Fixes: aecc787c06f4300f ("iomap: Use non-raw io functions for
io{read|write}XXbe")
Signed-off-by: Geert Uytterhoeven
---
This can be reverted later, after this oddity of the Coldfire I/O
support has been fixed, and drivers have been updated.
---
arch/m68k/include/asm/io.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index aabe6420ead2a599..d47e7384681ab1cd 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -8,6 +8,12 @@
#include
#endif
+#define mmio_read16be(addr) __raw_readw(addr)
+#define mmio_read32be(addr)__raw_readl(addr)
+
+#define mmio_write16be(val, port) __raw_writew((val), (port))
+#define mmio_write32be(val, port) __raw_writel((val), (port))
+
#include
#endif /* _M68K_IO_H */
--
2.17.1
Re: [PATCH] binfmt_flat: make load_flat_shared_library() work
On 29/5/19 10:32 pm, John Paul Adrian Glaubitz wrote: On 5/28/19 12:56 PM, Greg Ungerer wrote: Maybe... but I didn't want to rip it out without having one of the maintainers confirm that this really isn't likely to be used anymore. I have not used shared libraries on m68k non-mmu setups for a very long time. At least 10 years I would think. We use shared libraries in Debian on m68k and Andreas Schwab uses them on openSUSE/m68k. When used on no-mmu platforms? Regards Greg So, they should keep working. Thanks, Adrian
Re: [PATCH] binfmt_flat: make load_flat_shared_library() work
On 29/5/19 10:05 pm, Arnd Bergmann wrote:
On Tue, May 28, 2019 at 12:56 PM Greg Ungerer wrote:
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
bytes read - so this only happens if the file is empty.
ouch.
Instead, call into load_flat_file() if the number of bytes read is
non-negative. (Even if the number of bytes is zero - in that case,
load_flat_file() will see nullbytes and return a nice -ENOEXEC.)
In addition, remove the code related to bprm creds and stop using
prepare_binprm() - this code is loading a library, not a main executable,
and it only actually uses the members "buf", "file" and "filename" of the
linux_binprm struct. Instead, call kernel_read() directly.
Cc: sta...@vger.kernel.org
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Jann Horn
---
I only found the bug by looking at the code, I have not verified its
existence at runtime.
Also, this patch is compile-tested only.
It would be nice if someone who works with nommu Linux could have a
look at this patch.
287980e49ffc was three years ago! Has it really been broken for all
that time? If so, it seems a good source of freed disk space...
Maybe... but I didn't want to rip it out without having one of the
maintainers confirm that this really isn't likely to be used anymore.
I have not used shared libraries on m68k non-mmu setups for
a very long time. At least 10 years I would think.
I think Emcraft have a significant customer base running ARM NOMMU
Linux, I wonder whether they would have run into this (adding
Sergei to Cc).
My suspicion is that they use only binfmt-elf-fdpic, not binfmt-flat.
The only architectures I see that enable binfmt-flat are sh, xtensa
and h8300, but only arch/sh uses CONFIG_BINFMT_SHARED_FLAT
m68k uses enables it too. It is the only binary format supported
when running no-mmu on m68k. (You can use it with MMU enabled too
if you really want too).
The shared flat format has been used on m68k in the past (it was
originally developed on m68k platforms). But I haven't used them
for a long time (probably 10 years at least) on m68k.
Regards
Greg
Re: [PATCH] binfmt_flat: make load_flat_shared_library() work
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
bytes read - so this only happens if the file is empty.
ouch.
Instead, call into load_flat_file() if the number of bytes read is
non-negative. (Even if the number of bytes is zero - in that case,
load_flat_file() will see nullbytes and return a nice -ENOEXEC.)
In addition, remove the code related to bprm creds and stop using
prepare_binprm() - this code is loading a library, not a main executable,
and it only actually uses the members "buf", "file" and "filename" of the
linux_binprm struct. Instead, call kernel_read() directly.
Cc: sta...@vger.kernel.org
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Jann Horn
---
I only found the bug by looking at the code, I have not verified its
existence at runtime.
Also, this patch is compile-tested only.
It would be nice if someone who works with nommu Linux could have a
look at this patch.
287980e49ffc was three years ago! Has it really been broken for all
that time? If so, it seems a good source of freed disk space...
Maybe... but I didn't want to rip it out without having one of the
maintainers confirm that this really isn't likely to be used anymore.
I have not used shared libraries on m68k non-mmu setups for
a very long time. At least 10 years I would think.
Regards
Greg
Re: [PATCH] binfmt_flat: make load_flat_shared_library() work
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
bytes read - so this only happens if the file is empty.
ouch.
Instead, call into load_flat_file() if the number of bytes read is
non-negative. (Even if the number of bytes is zero - in that case,
load_flat_file() will see nullbytes and return a nice -ENOEXEC.)
In addition, remove the code related to bprm creds and stop using
prepare_binprm() - this code is loading a library, not a main executable,
and it only actually uses the members "buf", "file" and "filename" of the
linux_binprm struct. Instead, call kernel_read() directly.
Cc: sta...@vger.kernel.org
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Jann Horn
---
I only found the bug by looking at the code, I have not verified its
existence at runtime.
Also, this patch is compile-tested only.
It would be nice if someone who works with nommu Linux could have a
look at this patch.
287980e49ffc was three years ago! Has it really been broken for all
that time? If so, it seems a good source of freed disk space...
Maybe... but I didn't want to rip it out without having one of the
maintainers confirm that this really isn't likely to be used anymore.
I have not used shared libraries on m68k non-mmu setups for
a very long time. At least 10 years I would think.
Regards
Greg
Re: [PATCH 1/6] ARM: ks8695: watchdog: stop using mach/*.h
On 4/5/19 3:06 am, Guenter Roeck wrote: On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote: On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote: I dug out some old ks8695 based hardware to try this out. I had a lot of trouble getting anything modern working on it. In the end I still don't have a reliable test bed to test this properly. What is usually used by old ARMv4 systems is OpenWrt or OpenEmbedded. Those is the only build systems that reliably produce a userspace for these things now, and it is also the appropriate size for this kind of systems. No, I can produce a user space environment for the KS8695 as well using the uClinux-dist build system. But that worked even less well than the old root filesystem that I had (which was also built with an older version of that build system). But there is no reason that old root filesystem should not work. And that is the thing that concerns me a bit here. I could mount it ok (it was a CRAMFS), it would run up the shell to a shell prompt, but when I try to run any commands from there they would oops. I didn't debug any further than that. Ultimately though I am left wondering if the ks8695 support in the kernel is useful to anyone the way it is at the moment. With a minimal kernel configuration I can boot up to a shell - but the system is really unreliable if you try to interactively use it. I don't think it is the hardware - it seems to run reliably with the old code it has running from flash on it. I am only testing the new kernel, running with the existing user space root filesystem on it (which dates from 2004 :-) Personally I think it is a bad sign that this subarch and boards do not have active OpenWrt support, they are routers after all (right?) and any active use of networking equipment should use a recent userspace as well, given all the security bugs that popped up over the years. With IXP4xx, Gemini and EP93xx we have found active users and companies selling the chips and reference designs and even recommending it for new products (!) at times. If this is not the case with KS8695 and no hobbyists are willing to submit it to OpenWrt and modernize it to use device tree I think it should be deleted from the kernel. That may be the best approach if indeed no one is using it, much less maintaining it. Well, I for one don't really use it any more. So I don't have a lot of motivation to maintain it any longer. Regards Greg
Re: [PATCH 1/6] ARM: ks8695: watchdog: stop using mach/*.h
Hi Arnd,
On 16/4/19 6:24 am, Arnd Bergmann wrote:
drivers should not rely on machine specific headers but
get their information from the platform device.
Signed-off-by: Arnd Bergmann
I dug out some old ks8695 based hardware to try this out.
I had a lot of trouble getting anything modern working on it.
In the end I still don't have a reliable test bed to test this properly.
Your patch series works as well as the kernel before the changes,
so I am happy enough to ack them as they are.
Acked-by: Greg Ungerer
Ultimately though I am left wondering if the ks8695 support in the
kernel is useful to anyone the way it is at the moment. With a minimal
kernel configuration I can boot up to a shell - but the system is
really unreliable if you try to interactively use it. I don't think
it is the hardware - it seems to run reliably with the old code
it has running from flash on it. I am only testing the new kernel,
running with the existing user space root filesystem on it (which
dates from 2004 :-)
Regards
Greg
arch/arm/mach-ks8695/devices.c | 13 -
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/ks8695_wdt.c | 30 +-
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
index 61cf20beb45f..57766817d86f 100644
--- a/arch/arm/mach-ks8695/devices.c
+++ b/arch/arm/mach-ks8695/devices.c
@@ -169,11 +169,22 @@ void __init ks8696_add_device_hpna(void)
/*
* Watchdog
* */
+#define KS8695_TMR_OFFSET (0xF + 0xE400)
+#define KS8695_TMR_PA (KS8695_IO_PA + KS8695_TMR_OFFSET)
+static struct resource ks8695_wdt_resources[] = {
+ [0] = {
+ .name = "tmr",
+ .start = KS8695_TMR_PA,
+ .end= KS8695_TMR_PA + 0xf,
+ .flags = IORESOURCE_MEM,
+ },
+};
static struct platform_device ks8695_wdt_device = {
.name = "ks8695_wdt",
.id = -1,
- .num_resources = 0,
+ .resource = ks8695_wdt_resources,
+ .num_resources = ARRAY_SIZE(ks8695_wdt_resources),
};
static void __init ks8695_add_device_watchdog(void)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 242eea859637..046e01daef57 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -397,7 +397,7 @@ config IXP4XX_WATCHDOG
config KS8695_WATCHDOG
tristate "KS8695 watchdog"
- depends on ARCH_KS8695
+ depends on ARCH_KS8695 || COMPILE_TEST
help
Watchdog timer embedded into KS8695 processor. This will reboot your
system when the timeout is reached.
diff --git a/drivers/watchdog/ks8695_wdt.c b/drivers/watchdog/ks8695_wdt.c
index 1e41818a44bc..87c542c2f912 100644
--- a/drivers/watchdog/ks8695_wdt.c
+++ b/drivers/watchdog/ks8695_wdt.c
@@ -23,10 +23,8 @@
#include
#include
#include
-#include
-#define KS8695_TMR_OFFSET (0xF + 0xE400)
-#define KS8695_TMR_VA (KS8695_IO_VA + KS8695_TMR_OFFSET)
+#define KS8695_CLOCK_RATE 2500
/*
* Timer registers
@@ -57,6 +55,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started (default="
static unsigned long ks8695wdt_busy;
static DEFINE_SPINLOCK(ks8695_lock);
+static void __iomem *tmr_reg;
/* . */
@@ -69,8 +68,8 @@ static inline void ks8695_wdt_stop(void)
spin_lock(_lock);
/* disable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon & ~TMCON_T0EN, tmr_reg + KS8695_TMCON);
spin_unlock(_lock);
}
@@ -84,15 +83,15 @@ static inline void ks8695_wdt_start(void)
spin_lock(_lock);
/* disable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon & ~TMCON_T0EN, tmr_reg + KS8695_TMCON);
/* program timer0 */
- __raw_writel(tval | T0TC_WATCHDOG, KS8695_TMR_VA + KS8695_T0TC);
+ __raw_writel(tval | T0TC_WATCHDOG, tmr_reg + KS8695_T0TC);
/* re-enable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon | TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon | TMCON_T0EN, tmr_reg + KS8695_TMCON);
spin_unlock(_lock);
}
@@ -105,9 +104,9 @@ static inline void ks8695_wdt_reload(void)
spin_lock(_lock);
/* disab
Re: [PATCH 1/6] ARM: ks8695: watchdog: stop using mach/*.h
Hi Arnd,
On 16/4/19 6:24 am, Arnd Bergmann wrote:
drivers should not rely on machine specific headers but
get their information from the platform device.
Signed-off-by: Arnd Bergmann
I like the whole series, thanks for doing this.
I haven't looked at the KS8695 in a long time now. I am not sure
that I have any working hardware - but I will have a look around my lab
and see if I can find something.
I'll get back to you with acks and tested bys soon.
Regards
Greg
---
arch/arm/mach-ks8695/devices.c | 13 -
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/ks8695_wdt.c | 30 +-
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
index 61cf20beb45f..57766817d86f 100644
--- a/arch/arm/mach-ks8695/devices.c
+++ b/arch/arm/mach-ks8695/devices.c
@@ -169,11 +169,22 @@ void __init ks8696_add_device_hpna(void)
/*
* Watchdog
* */
+#define KS8695_TMR_OFFSET (0xF + 0xE400)
+#define KS8695_TMR_PA (KS8695_IO_PA + KS8695_TMR_OFFSET)
+static struct resource ks8695_wdt_resources[] = {
+ [0] = {
+ .name = "tmr",
+ .start = KS8695_TMR_PA,
+ .end= KS8695_TMR_PA + 0xf,
+ .flags = IORESOURCE_MEM,
+ },
+};
static struct platform_device ks8695_wdt_device = {
.name = "ks8695_wdt",
.id = -1,
- .num_resources = 0,
+ .resource = ks8695_wdt_resources,
+ .num_resources = ARRAY_SIZE(ks8695_wdt_resources),
};
static void __init ks8695_add_device_watchdog(void)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 242eea859637..046e01daef57 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -397,7 +397,7 @@ config IXP4XX_WATCHDOG
config KS8695_WATCHDOG
tristate "KS8695 watchdog"
- depends on ARCH_KS8695
+ depends on ARCH_KS8695 || COMPILE_TEST
help
Watchdog timer embedded into KS8695 processor. This will reboot your
system when the timeout is reached.
diff --git a/drivers/watchdog/ks8695_wdt.c b/drivers/watchdog/ks8695_wdt.c
index 1e41818a44bc..87c542c2f912 100644
--- a/drivers/watchdog/ks8695_wdt.c
+++ b/drivers/watchdog/ks8695_wdt.c
@@ -23,10 +23,8 @@
#include
#include
#include
-#include
-#define KS8695_TMR_OFFSET (0xF + 0xE400)
-#define KS8695_TMR_VA (KS8695_IO_VA + KS8695_TMR_OFFSET)
+#define KS8695_CLOCK_RATE 2500
/*
* Timer registers
@@ -57,6 +55,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started (default="
static unsigned long ks8695wdt_busy;
static DEFINE_SPINLOCK(ks8695_lock);
+static void __iomem *tmr_reg;
/* . */
@@ -69,8 +68,8 @@ static inline void ks8695_wdt_stop(void)
spin_lock(_lock);
/* disable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon & ~TMCON_T0EN, tmr_reg + KS8695_TMCON);
spin_unlock(_lock);
}
@@ -84,15 +83,15 @@ static inline void ks8695_wdt_start(void)
spin_lock(_lock);
/* disable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon & ~TMCON_T0EN, tmr_reg + KS8695_TMCON);
/* program timer0 */
- __raw_writel(tval | T0TC_WATCHDOG, KS8695_TMR_VA + KS8695_T0TC);
+ __raw_writel(tval | T0TC_WATCHDOG, tmr_reg + KS8695_T0TC);
/* re-enable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon | TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon | TMCON_T0EN, tmr_reg + KS8695_TMCON);
spin_unlock(_lock);
}
@@ -105,9 +104,9 @@ static inline void ks8695_wdt_reload(void)
spin_lock(_lock);
/* disable, then re-enable timer0 */
- tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
- __raw_writel(tmcon | TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
+ tmcon = __raw_readl(tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon & ~TMCON_T0EN, tmr_reg + KS8695_TMCON);
+ __raw_writel(tmcon | TMCON_T0EN, tmr_reg + KS8695_TMCON);
spin_unlock(_lock);
}
@@ -238,6 +237,11 @@ static struct miscdevice ks8695wdt_miscdev = {
static int ks8695wdt_probe(struct platform_device *pdev)
{
int res;
+
Re: [PATCH 5/6] ARM: ks8695, serial: skip manual tx IRQ ack
Hi Arnd,
On 16/4/19 6:24 am, Arnd Bergmann wrote:
The TX interrupt is marked as edge triggered, so it will
already be acked by the top-level irq code, and does not
need the ack in the driver.
Removing this avoids a nasty dependency on the regs-irq.h
file that is otherwise reserved for the interrupt controller
driver.
Signed-off-by: Arnd Bergmann
---
drivers/tty/serial/serial_ks8695.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/serial/serial_ks8695.c
b/drivers/tty/serial/serial_ks8695.c
index b461d791188c..6c5e9900e69d 100644
--- a/drivers/tty/serial/serial_ks8695.c
+++ b/drivers/tty/serial/serial_ks8695.c
@@ -21,7 +21,6 @@
#include
#include
-#include
#if defined(CONFIG_SERIAL_KS8695_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
@@ -52,8 +51,6 @@
#define UART_GET_BRDR(p) __raw_readl((p)->membase + KS8695_URBD)
#define UART_PUT_BRDR(p, c) __raw_writel((c), (p)->membase + KS8695_URBD)
-#define KS8695_CLR_TX_INT() __raw_writel(1 << KS8695_IRQ_UART_TX, KS8695_IRQ_VA + KS8695_INTST)
-
#define UART_DUMMY_LSR_RX 0x100
#define UART_PORT_SIZE(KS8695_USR - KS8695_URRB + 4)
@@ -207,7 +204,6 @@ static irqreturn_t ks8695uart_tx_chars(int irq, void *dev_id)
unsigned int count;
if (port->x_char) {
- KS8695_CLR_TX_INT();
UART_PUT_CHAR(port, port->x_char);
port->icount.tx++;
port->x_char = 0;
@@ -221,7 +217,6 @@ static irqreturn_t ks8695uart_tx_chars(int irq, void
*dev_id)
count = 16; /* fifo size */
while (!uart_circ_empty(xmit) && (count-- > 0)) {
- KS8695_CLR_TX_INT();
I haven't looked at the ks8695 in quite a while...
But I recall that this was very problematic at the time. Without this being
done after each character it was very easy to get the transmitter to "hang" -
and stop wanting to send any more characters.
I'd like to test this before acking.
Regards
Greg
UART_PUT_CHAR(port, xmit->buf[xmit->tail]);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
[git pull] m68knommu fix for v5.1
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to provide platform side support for the eDMA hardware module on the ColdFire MCF5441X SoC. Regards Greg The following changes since commit 5908e6b738e3357af42c10e1183753c70a0117a9: Linux 5.0-rc8 (2019-02-24 16:46:45 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to d7e9d01ac2920959b474c6363dba269a868f4db9: m68k: add ColdFire mcf5441x eDMA platform support (2019-02-25 11:04:05 +1000) Angelo Dureghello (1): m68k: add ColdFire mcf5441x eDMA platform support arch/m68k/coldfire/device.c | 81 +++ arch/m68k/coldfire/m5441x.c | 4 +- arch/m68k/include/asm/m5441xsim.h | 15 3 files changed, 98 insertions(+), 2 deletions(-)
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
Hi Christoph, On 17/12/18 9:59 pm, Christoph Hellwig wrote: On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote: Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work by virtue of the SoC only having an instruction cache (the older V2 cores). Is there a good an easy case to detect if a core has a cache? Either runtime or in Kconfig? The MMU case is fixable, but I think it will mean changing away from the fall-back virtual:physical 1:1 mapping it uses for the kernel address space. So not completely trivial. Either that or a dedicated area of RAM for coherent allocations that we can mark as non-cachable via the really course grained and limited ACR registers - not really very appealing. What about CF_PAGE_NOCACHE? Reading arch/m68k/include/asm/mcf_pgtable.h suggest this would cause an uncached mapping, in which case something like this should work: http://git.infradead.org/users/hch/misc.git/commitdiff/4b8711d436e8d56edbc5ca19aa2be639705bbfef No, that won't work. The current MMU setup for ColdFire relies on a quirk of the cache control subsystem to map kernel mapping (actually all of RAM when accessed in supervisor mode). The effective address calculation by the CPU/MMU firstly checks the RAMBAR access, then From the ColdFire 5475 Reference Manual (section 5.5.1): If virtual mode is enabled, any normal mode access that does not hit in the MMUBAR, RAMBARs, ROMBARs, or ACRs is considered a normal mode virtual address request and generates its access attributes from the MMU. For this case, the default CACR address attributes are not used. The MMUBAR is the MMU control registers, the RAMBAR/ROMBAR are the internal static RAM/ROM regions and the ACR are the cache control registers. The code in arch/m68k/coldfire/head.S sets up the ACR registers so that all of RAM is accessible and cached when in supervisor mode. So kernel code and data accesses will hit this and use the address for access. User pages won't hit this and will go through to hit the MMU mappings. The net out is we don't need page mappings or use TLB entries for kernel code/data. The problem is we also can't map individual regions as not cached for coherent allocations... The ACR mapping means all-or-nothing. This leads back to what I mentioned earlier about changing the VM mapping to not use the ACR mapping method and actually page mapping the kernel space. Not completely trivial and I expect there will be a performance hit with the extra TLB pressure and their setup/remapping overhead. The noMMU case in general is probably limited to something like that same type of dedicated RAM/ACR register mechamism. The most commonly used periperal with DMA is the FEC ethernet module, and it has some "special" (used very loosely) cache flushing for parts like the 532x family which probably makes it mostly work right. There is a PCI bus on the 54xx family of parts, and I know general ethernet cards on it (like e1000's) have problems I am sure are related to the fact that coherent memory allocations aren't. If we really just care about FEC we can just switch it do use DMA_ATTR_NON_CONSISTENT and do explicit cache flushing. But as far as I can tell FEC only uses DMA coherent allocations for the TSO headers anyway, is TSO even used on this SOC? The FEC is the most commonly used, but not the only. I test generic PCI NICs on the PCI bus on the ColdFire 5475 - and a lot of those drivers rely on coherent allocations. Regards Greg
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
On 14/12/18 9:47 pm, Christoph Hellwig wrote:
On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
- page = alloc_pages(flag, order);
+ page = alloc_pages(flag | GFP_ZERO, order);
if (!page)
return NULL;
There's second implementation below, which calls __get_free_pages() and
does an explicit memset(). As __get_free_pages() calls alloc_pages(), perhaps
it makes sense to replace the memset() by GFP_ZERO, to increase consistency?
It would, but this patch really tries to be minimally invasive to just
provide the zeroing everywhere. There is plenty of opportunity
to improve the m68k dma allocator if I can get enough reviewers/testers:
- for one the coldfire/nommu case absolutely does not make sense to
me as there is not work done at all to make sure the memory is
mapped uncached despite the architecture implementing cache
flushing for the map interface. So this whole implementation
looks broken to me and will need some major work (I had a previous
discussion with Greg on that which needs to be dug out)
Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).
The MMU case is fixable, but I think it will mean changing away from
the fall-back virtual:physical 1:1 mapping it uses for the kernel address
space. So not completely trivial. Either that or a dedicated area of RAM
for coherent allocations that we can mark as non-cachable via the really
course grained and limited ACR registers - not really very appealing.
The noMMU case in general is probably limited to something like that same
type of dedicated RAM/ACR register mechamism.
The most commonly used periperal with DMA is the FEC ethernet module,
and it has some "special" (used very loosely) cache flushing for
parts like the 532x family which probably makes it mostly work right.
There is a PCI bus on the 54xx family of parts, and I know general
ethernet cards on it (like e1000's) have problems I am sure are
related to the fact that coherent memory allocations aren't.
I do plan to have a look at this for the MMU case some time soon.
Regards
Greg
- the "regular" implementation in this patch should probably be replaced
with the generic remapping helpers that have been added for the 4.21
merge window:
http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/0c3b3171ceccb8830c2bb5adff1b4e9b204c1450
Compile tested only patch below:
--
From ade86dc75b9850daf9111ebf9ce15825a6144f2d Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Fri, 14 Dec 2018 12:41:45 +0100
Subject: m68k: use the generic dma coherent remap allocator
This switche to using common code for the DMA allocations, including
potential use of the CMA allocator if configure. Also add a few
comments where the existing behavior seems to be lacking.
Signed-off-by: Christoph Hellwig
---
arch/m68k/Kconfig | 2 ++
arch/m68k/kernel/dma.c | 64 --
2 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 8a5868e9a3a0..60788cf02fbc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -2,10 +2,12 @@
config M68K
bool
default y
+ select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
+ select DMA_DIRECT_REMAP if MMU && !COLDFIRE
select HAVE_IDE
select HAVE_AOUT if MMU
select HAVE_DEBUG_BUGVERBOSE
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index dafe99d08a6a..16da5d96e228 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -18,57 +18,29 @@
#include
#if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
-
-void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
- gfp_t flag, unsigned long attrs)
+void arch_dma_prep_coherent(struct page *page, size_t size)
{
- struct page *page, **map;
- pgprot_t pgprot;
- void *addr;
- int i, order;
-
- pr_debug("dma_alloc_coherent: %d,%x\n", size, flag);
-
- size = PAGE_ALIGN(size);
- order = get_order(size);
-
- page = alloc_pages(flag | GFP_ZERO, order);
- if (!page)
- return NULL;
-
- *handle = page_to_phys(page);
- map = kmalloc(sizeof(struct page *) << order, flag & ~__GFP_DMA);
- if (!map) {
- __free_pages(page, order);
- return NULL;
- }
- split_page(page, order);
-
- order = 1 << order;
- size >>= PAGE_SHIFT;
- map[0] = page;
- for (i = 1; i < size; i++)
- map[i] = page + i;
- for (; i < order; i++)
- __free_page(page + i);
- pgprot =
[git pull] m68knommu fix for v4.20
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to fix an out of bounds array access when parsing boot command line. Regards Greg The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e: Linux 4.19-rc8 (2018-10-15 07:20:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454: m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 +1000) Angelo Dureghello (1): m68k: fix command-line parsing when passed from u-boot arch/m68k/kernel/uboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[git pull] m68knommu fix for v4.20
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to fix an out of bounds array access when parsing boot command line. Regards Greg The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e: Linux 4.19-rc8 (2018-10-15 07:20:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454: m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 +1000) Angelo Dureghello (1): m68k: fix command-line parsing when passed from u-boot arch/m68k/kernel/uboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike, On 04/07/18 16:28, Mike Rapoport wrote: These patches switch m68k boot time memory allocators from bootmem to memblock + no_bootmem. The first two patches update __ffs() and __va() definitions to be inline with other arches and asm-generic. This is required to avoid compilation warnings in mm/memblock.c and mm/nobootmem.c. The third patch performs the actual switch of the boot time mm. Its changelog has detailed description of the changes. I've tested the !MMU version with qemu-system-m68k -M mcf5208evb and the MMU version with q800 using qemu from [1]. I've also build tested allyesconfig and *_defconfig. [1] https://github.com/vivier/qemu-m68k.git v2: * fix reservation of the kernel text/data/bss for ColdFire MMU I am happy with all of these, so for me: Acked-by: Greg Ungerer Regards Greg Mike Rapoport (3): m68k/bitops: convert __ffs to match generic declaration m68k/page_no.h: force __va argument to be unsigned long m68k: switch to MEMBLOCK + NO_BOOTMEM arch/m68k/Kconfig | 3 +++ arch/m68k/include/asm/bitops.h | 8 ++-- arch/m68k/include/asm/page_no.h | 2 +- arch/m68k/kernel/setup_mm.c | 14 -- arch/m68k/kernel/setup_no.c | 20 arch/m68k/mm/init.c | 1 - arch/m68k/mm/mcfmmu.c | 13 +++-- arch/m68k/mm/motorola.c | 35 +++ arch/m68k/sun3/config.c | 4 9 files changed, 36 insertions(+), 64 deletions(-)
Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike, On 04/07/18 16:28, Mike Rapoport wrote: These patches switch m68k boot time memory allocators from bootmem to memblock + no_bootmem. The first two patches update __ffs() and __va() definitions to be inline with other arches and asm-generic. This is required to avoid compilation warnings in mm/memblock.c and mm/nobootmem.c. The third patch performs the actual switch of the boot time mm. Its changelog has detailed description of the changes. I've tested the !MMU version with qemu-system-m68k -M mcf5208evb and the MMU version with q800 using qemu from [1]. I've also build tested allyesconfig and *_defconfig. [1] https://github.com/vivier/qemu-m68k.git v2: * fix reservation of the kernel text/data/bss for ColdFire MMU I am happy with all of these, so for me: Acked-by: Greg Ungerer Regards Greg Mike Rapoport (3): m68k/bitops: convert __ffs to match generic declaration m68k/page_no.h: force __va argument to be unsigned long m68k: switch to MEMBLOCK + NO_BOOTMEM arch/m68k/Kconfig | 3 +++ arch/m68k/include/asm/bitops.h | 8 ++-- arch/m68k/include/asm/page_no.h | 2 +- arch/m68k/kernel/setup_mm.c | 14 -- arch/m68k/kernel/setup_no.c | 20 arch/m68k/mm/init.c | 1 - arch/m68k/mm/mcfmmu.c | 13 +++-- arch/m68k/mm/motorola.c | 35 +++ arch/m68k/sun3/config.c | 4 9 files changed, 36 insertions(+), 64 deletions(-)
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike,
On 04/07/18 14:22, Mike Rapoport wrote:
On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote:
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.
Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped
Signed-off-by: Mike Rapoport
This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.
The M5475 is a ColdFire with MMU enabled target.
With some early serial debug trace I see:
Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version
5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018
On node 0 totalpages: 4096
DMA zone: 18 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4096 pages, LIFO batch:0
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping off. Total pages: 4078
Kernel command line: root=/dev/mtdblock0
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Sorting __ex_table...
Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K
init, 77K bss, 29736K reserved, 0K cma-reserved)
^^
It seems I was over enthusiastic when I reserved the memory for the kernel.
Can you please try with the below patch:
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index e9e60e1..18c7bf6 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void)
high_memory = (void *)_ramend;
/* Reserve kernel text/data/bss */
- memblock_reserve(memstart, _ramend - memstart);
+ memblock_reserve(memstart, memstart - _rambase);
m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
diff --git a/mm/memblock.c b/mm/memblock.c
index 03d48d8..98661be 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -54,7 +54,7 @@ struct memblock memblock __initdata_memblock = {
.current_limit = MEMBLOCK_ALLOC_ANYWHERE,
};
-int memblock_debug __initdata_memblock;
+int memblock_debug __initdata_memblock = 1;
static bool system_has_some_mirror __initdata_memblock = false;
static int memblock_can_resize __initdata_memblock;
static int memblock_memory_in_slab __initdata_memblock = 0;
The memblock hunk is needed to see early memblock debug messages as all the
setup happens before parsing of the command line.
Ok, that works, boots all the way up now.
Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version
5.4.0 (GCC)) #7 Wed Jul 4 14:34:48 AEST 2018
memblock_add: [0x-0x01ff] 0x001ebaa0
memblock_reserve: [0x00332000-0x00663fff] 0x001ebafa
memblock_reserve: [0x01ffe000-0x01ff] 0x001efd38
memblock_reserve: [0x01ff8000-0x01ffdfff] 0x001efd38
memblock_virt_alloc_try_nid_nopanic: 147456 bytes align=0x0 nid=0 from=0x0
max_addr=0x0 0x00190dea
memblock_reserve: [0x01fd4000-0x01ff7fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 4 bytes align=0x0 nid=0 from=0x0
max_addr=0x0 0x001ee234
memblock_reserve: [0x01fd3ff0-0x01fd3ff3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea488
memblock_reserve: [0x01fd3fd0-0x01fd3fe3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea4a8
memblock_reserve: [0x01fd3fb0-0x01fd3fc3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea4c0
memblock_reserve: [0x01fd3f90-0x01fd3fa3] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 8192 bytes align=0x2000 nid=-1 from=0x0
max_addr=0x0 0x001eef30
memblock_reserve: [0x01fd-0x01fd1fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x2000 nid=-1 from=0x0
max_addr=0x0 0x001ef5d6
memblock_reserve: [0x01fc8000-0x01fc] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2ac
memblock_reserve: [0x01fd3f80-0x01fd3f83] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2c2
memblock_reserve: [0x01fd3f70-0x01fd3f73] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2d6
memblock_reserve: [0x01fd3f60-0x01fd3f63] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike,
On 04/07/18 14:22, Mike Rapoport wrote:
On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote:
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.
Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped
Signed-off-by: Mike Rapoport
This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.
The M5475 is a ColdFire with MMU enabled target.
With some early serial debug trace I see:
Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version
5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018
On node 0 totalpages: 4096
DMA zone: 18 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4096 pages, LIFO batch:0
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping off. Total pages: 4078
Kernel command line: root=/dev/mtdblock0
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Sorting __ex_table...
Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K
init, 77K bss, 29736K reserved, 0K cma-reserved)
^^
It seems I was over enthusiastic when I reserved the memory for the kernel.
Can you please try with the below patch:
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index e9e60e1..18c7bf6 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void)
high_memory = (void *)_ramend;
/* Reserve kernel text/data/bss */
- memblock_reserve(memstart, _ramend - memstart);
+ memblock_reserve(memstart, memstart - _rambase);
m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
diff --git a/mm/memblock.c b/mm/memblock.c
index 03d48d8..98661be 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -54,7 +54,7 @@ struct memblock memblock __initdata_memblock = {
.current_limit = MEMBLOCK_ALLOC_ANYWHERE,
};
-int memblock_debug __initdata_memblock;
+int memblock_debug __initdata_memblock = 1;
static bool system_has_some_mirror __initdata_memblock = false;
static int memblock_can_resize __initdata_memblock;
static int memblock_memory_in_slab __initdata_memblock = 0;
The memblock hunk is needed to see early memblock debug messages as all the
setup happens before parsing of the command line.
Ok, that works, boots all the way up now.
Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version
5.4.0 (GCC)) #7 Wed Jul 4 14:34:48 AEST 2018
memblock_add: [0x-0x01ff] 0x001ebaa0
memblock_reserve: [0x00332000-0x00663fff] 0x001ebafa
memblock_reserve: [0x01ffe000-0x01ff] 0x001efd38
memblock_reserve: [0x01ff8000-0x01ffdfff] 0x001efd38
memblock_virt_alloc_try_nid_nopanic: 147456 bytes align=0x0 nid=0 from=0x0
max_addr=0x0 0x00190dea
memblock_reserve: [0x01fd4000-0x01ff7fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 4 bytes align=0x0 nid=0 from=0x0
max_addr=0x0 0x001ee234
memblock_reserve: [0x01fd3ff0-0x01fd3ff3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea488
memblock_reserve: [0x01fd3fd0-0x01fd3fe3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea4a8
memblock_reserve: [0x01fd3fb0-0x01fd3fc3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ea4c0
memblock_reserve: [0x01fd3f90-0x01fd3fa3] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 8192 bytes align=0x2000 nid=-1 from=0x0
max_addr=0x0 0x001eef30
memblock_reserve: [0x01fd-0x01fd1fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x2000 nid=-1 from=0x0
max_addr=0x0 0x001ef5d6
memblock_reserve: [0x01fc8000-0x01fc] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2ac
memblock_reserve: [0x01fd3f80-0x01fd3f83] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2c2
memblock_reserve: [0x01fd3f70-0x01fd3f73] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
0x001ef2d6
memblock_reserve: [0x01fd3f60-0x01fd3f63] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike, On 04/07/18 11:39, Greg Ungerer wrote: On 03/07/18 20:29, Mike Rapoport wrote: In m68k the physical memory is described by [memory_start, memory_end] for !MMU variant and by m68k_memory array of memory ranges for the MMU version. This information is directly used to register the physical memory with memblock. The reserve_bootmem() calls are replaced with memblock_reserve() and the bootmap bitmap allocation is simply dropped. Since the MMU variant creates early mappings only for the small part of the memory we force bottom-up allocations in memblock because otherwise we will attempt to access memory that not yet mapped Signed-off-by: Mike Rapoport This builds cleanly for me with a m5475_defconfig, but it fails to boot on real hardware. No console, no nothing on startup. I haven't debugged any further yet. The M5475 is a ColdFire with MMU enabled target. With some early serial debug trace I see: Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018 On node 0 totalpages: 4096 DMA zone: 18 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4096 pages, LIFO batch:0 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping off. Total pages: 4078 Kernel command line: root=/dev/mtdblock0 Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) Sorting __ex_table... Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K init, 77K bss, 29736K reserved, 0K cma-reserved) SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 NR_IRQS: 256 clocksource: slt: mask: 0x max_cycles: 0x, max_idle_ns: 14370379300 ns Calibrating delay loop... 264.19 BogoMIPS (lpj=1320960) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 0, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns ColdFire: PCI bus initialization... Coldfire: PCI IO/config window mapped to 0xe000 PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0x] pci_bus :00: root bus resource [mem 0x-0x] pci_bus :00: root bus resource [bus 00-ff] pci :00:14.0: [8086:1229] type 00 class 0x02 pci :00:14.0: reg 0x10: [mem 0x-0x0fff] pci :00:14.0: reg 0x14: [io 0x-0x003f] pci :00:14.0: reg 0x18: [mem 0x-0x000f] pci :00:14.0: reg 0x30: [mem 0x-0x000f pref] pci :00:14.0: supports D1 D2 pci :00:14.0: PME# supported from D0 D1 D2 D3hot pci :00:14.0: BAR 2: assigned [mem 0xf000-0xf00f] pci :00:14.0: BAR 6: assigned [mem 0xf010-0xf01f pref] pci :00:14.0: BAR 0: assigned [mem 0xf020-0xf0200fff] pci :00:14.0: BAR 1: assigned [io 0x0400-0x043f] vgaarb: loaded clocksource: Switched to clocksource slt PCI: CLS 32 bytes, default 16 workingset: timestamp_bits=27 max_order=9 bucket_order=0 kobject_add_internal failed for slab (error: -12 parent: kernel) Cannot register slab subsystem. romfs: ROMFS MTD (C) 2007 Red Hat, Inc. io scheduler noop registered (default) io scheduler mq-deadline registered io scheduler kyber registered kobject_add_internal failed for ptyp0 (error: -12 parent: tty) Kernel panic - not syncing: Couldn't register pty driver CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc3-3-g109f5e551b18-dirty #5 Stack from 00283ee4: 00283ee4 001bc27a 000287ea 0019075c 0019 001f5390 0018ba36 002c6a00 002c6a80 0014ab82 00148816 001f2c2a 001b948c 001f2ad0 001f6ce8 0002118e 00283f8c 000211b4 0006 0019 001f5390 0018ba36 0007 001f53cc 00305fb0 0002118e 0003df6a 0006 0006 00305fb0 00305fb5 001ea7f6 001ba406 00305fb0 001d1c58 0019 0006 0006 0003df6a 001ea804 001f2ad0 001e5964 00282001 Call Trace: [<000287ea>] 0x000287ea [<0019075c>] 0x0019075c [<0018ba36>] 0x0018ba36 [<0014ab82>] 0x0014ab82 [<00148816>] 0x00148816 [<001f2c2a>] 0x001f2c2a [<001f2ad0>] 0x001f2ad0 [<0002118e>] 0x0002118e [<000211b4>] 0x000211b4 [<0018ba36>] 0x0018ba36 [<0002118e>] 0x0002118e [<0003df6a>] 0x0003df6a [<001ea7f6>] 0x001ea7f6 [<0003df6a>] 0x0003df6a [<001ea804>] 0x001ea804 [<001f2ad0>] 0x001f2ad0 [<00190bae>] 0x00190bae [<00190bb6>] 0x00190bb6 [<00190bae>] 0x00190bae [<00021aac>] 0x00021aac ---[ end Kernel panic - not syncing: Couldn't register pty driver ]--- random: fast init done Regards Greg --- arch/m68k/Kconfig | 3 +++ arch/m68k/kernel/setup_mm.c | 14 -- arch/m68k/kernel/setup_no.c | 20 ---
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike, On 04/07/18 11:39, Greg Ungerer wrote: On 03/07/18 20:29, Mike Rapoport wrote: In m68k the physical memory is described by [memory_start, memory_end] for !MMU variant and by m68k_memory array of memory ranges for the MMU version. This information is directly used to register the physical memory with memblock. The reserve_bootmem() calls are replaced with memblock_reserve() and the bootmap bitmap allocation is simply dropped. Since the MMU variant creates early mappings only for the small part of the memory we force bottom-up allocations in memblock because otherwise we will attempt to access memory that not yet mapped Signed-off-by: Mike Rapoport This builds cleanly for me with a m5475_defconfig, but it fails to boot on real hardware. No console, no nothing on startup. I haven't debugged any further yet. The M5475 is a ColdFire with MMU enabled target. With some early serial debug trace I see: Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018 On node 0 totalpages: 4096 DMA zone: 18 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4096 pages, LIFO batch:0 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping off. Total pages: 4078 Kernel command line: root=/dev/mtdblock0 Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) Sorting __ex_table... Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K init, 77K bss, 29736K reserved, 0K cma-reserved) SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 NR_IRQS: 256 clocksource: slt: mask: 0x max_cycles: 0x, max_idle_ns: 14370379300 ns Calibrating delay loop... 264.19 BogoMIPS (lpj=1320960) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 0, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns ColdFire: PCI bus initialization... Coldfire: PCI IO/config window mapped to 0xe000 PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0x] pci_bus :00: root bus resource [mem 0x-0x] pci_bus :00: root bus resource [bus 00-ff] pci :00:14.0: [8086:1229] type 00 class 0x02 pci :00:14.0: reg 0x10: [mem 0x-0x0fff] pci :00:14.0: reg 0x14: [io 0x-0x003f] pci :00:14.0: reg 0x18: [mem 0x-0x000f] pci :00:14.0: reg 0x30: [mem 0x-0x000f pref] pci :00:14.0: supports D1 D2 pci :00:14.0: PME# supported from D0 D1 D2 D3hot pci :00:14.0: BAR 2: assigned [mem 0xf000-0xf00f] pci :00:14.0: BAR 6: assigned [mem 0xf010-0xf01f pref] pci :00:14.0: BAR 0: assigned [mem 0xf020-0xf0200fff] pci :00:14.0: BAR 1: assigned [io 0x0400-0x043f] vgaarb: loaded clocksource: Switched to clocksource slt PCI: CLS 32 bytes, default 16 workingset: timestamp_bits=27 max_order=9 bucket_order=0 kobject_add_internal failed for slab (error: -12 parent: kernel) Cannot register slab subsystem. romfs: ROMFS MTD (C) 2007 Red Hat, Inc. io scheduler noop registered (default) io scheduler mq-deadline registered io scheduler kyber registered kobject_add_internal failed for ptyp0 (error: -12 parent: tty) Kernel panic - not syncing: Couldn't register pty driver CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc3-3-g109f5e551b18-dirty #5 Stack from 00283ee4: 00283ee4 001bc27a 000287ea 0019075c 0019 001f5390 0018ba36 002c6a00 002c6a80 0014ab82 00148816 001f2c2a 001b948c 001f2ad0 001f6ce8 0002118e 00283f8c 000211b4 0006 0019 001f5390 0018ba36 0007 001f53cc 00305fb0 0002118e 0003df6a 0006 0006 00305fb0 00305fb5 001ea7f6 001ba406 00305fb0 001d1c58 0019 0006 0006 0003df6a 001ea804 001f2ad0 001e5964 00282001 Call Trace: [<000287ea>] 0x000287ea [<0019075c>] 0x0019075c [<0018ba36>] 0x0018ba36 [<0014ab82>] 0x0014ab82 [<00148816>] 0x00148816 [<001f2c2a>] 0x001f2c2a [<001f2ad0>] 0x001f2ad0 [<0002118e>] 0x0002118e [<000211b4>] 0x000211b4 [<0018ba36>] 0x0018ba36 [<0002118e>] 0x0002118e [<0003df6a>] 0x0003df6a [<001ea7f6>] 0x001ea7f6 [<0003df6a>] 0x0003df6a [<001ea804>] 0x001ea804 [<001f2ad0>] 0x001f2ad0 [<00190bae>] 0x00190bae [<00190bb6>] 0x00190bb6 [<00190bae>] 0x00190bae [<00021aac>] 0x00021aac ---[ end Kernel panic - not syncing: Couldn't register pty driver ]--- random: fast init done Regards Greg --- arch/m68k/Kconfig | 3 +++ arch/m68k/kernel/setup_mm.c | 14 -- arch/m68k/kernel/setup_no.c | 20 ---
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike,
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.
Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped
Signed-off-by: Mike Rapoport
This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.
The M5475 is a ColdFire with MMU enabled target.
Regards
Greg
---
arch/m68k/Kconfig | 3 +++
arch/m68k/kernel/setup_mm.c | 14 --
arch/m68k/kernel/setup_no.c | 20
arch/m68k/mm/init.c | 1 -
arch/m68k/mm/mcfmmu.c | 11 +++
arch/m68k/mm/motorola.c | 35 +++
arch/m68k/sun3/config.c | 4
7 files changed, 29 insertions(+), 59 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 785612b..bd7f38a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -24,6 +24,9 @@ config M68K
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+ select HAVE_MEMBLOCK
+ select ARCH_DISCARD_MEMBLOCK
+ select NO_BOOTMEM
config CPU_BIG_ENDIAN
def_bool y
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index f35e3eb..6512955 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -165,6 +166,8 @@ static void __init m68k_parse_bootinfo(const struct
bi_record *record)
be32_to_cpu(m->addr);
m68k_memory[m68k_num_memory].size =
be32_to_cpu(m->size);
+ memblock_add(m68k_memory[m68k_num_memory].addr,
+m68k_memory[m68k_num_memory].size);
m68k_num_memory++;
} else
pr_warn("%s: too many memory chunks\n",
@@ -224,10 +227,6 @@ static void __init m68k_parse_bootinfo(const struct
bi_record *record)
void __init setup_arch(char **cmdline_p)
{
-#ifndef CONFIG_SUN3
- int i;
-#endif
-
/* The bootinfo is located right after the kernel */
if (!CPU_IS_COLDFIRE)
m68k_parse_bootinfo((const struct bi_record *)_end);
@@ -356,14 +355,9 @@ void __init setup_arch(char **cmdline_p)
#endif
#ifndef CONFIG_SUN3
- for (i = 1; i < m68k_num_memory; i++)
- free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
- m68k_memory[i].size);
#ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
-
reserve_bootmem_node(__virt_to_node(phys_to_virt(m68k_ramdisk.addr)),
-m68k_ramdisk.addr, m68k_ramdisk.size,
-BOOTMEM_DEFAULT);
+ memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index a98af10..3e8d87a 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -86,8 +87,6 @@ void (*mach_power_off)(void);
void __init setup_arch(char **cmdline_p)
{
- int bootmap_size;
-
memory_start = PAGE_ALIGN(_ramstart);
memory_end = _ramend;
@@ -142,6 +141,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
+ memblock_add(memory_start, memory_end - memory_start);
+
/* Keep a copy of command line */
*cmdline_p = _line[0];
memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
@@ -158,23 +159,10 @@ void __init setup_arch(char **cmdline_p)
min_low_pfn = PFN_DOWN(memory_start);
max_pfn = max_low_pfn = PFN_DOWN(memory_end);
- bootmap_size = init_bootmem_node(
- NODE_DATA(0),
- min_low_pfn,/* map goes here */
- PFN_DOWN(PAGE_OFFSET),
- max_pfn);
- /*
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike,
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.
Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped
Signed-off-by: Mike Rapoport
This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.
The M5475 is a ColdFire with MMU enabled target.
Regards
Greg
---
arch/m68k/Kconfig | 3 +++
arch/m68k/kernel/setup_mm.c | 14 --
arch/m68k/kernel/setup_no.c | 20
arch/m68k/mm/init.c | 1 -
arch/m68k/mm/mcfmmu.c | 11 +++
arch/m68k/mm/motorola.c | 35 +++
arch/m68k/sun3/config.c | 4
7 files changed, 29 insertions(+), 59 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 785612b..bd7f38a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -24,6 +24,9 @@ config M68K
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+ select HAVE_MEMBLOCK
+ select ARCH_DISCARD_MEMBLOCK
+ select NO_BOOTMEM
config CPU_BIG_ENDIAN
def_bool y
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index f35e3eb..6512955 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -165,6 +166,8 @@ static void __init m68k_parse_bootinfo(const struct
bi_record *record)
be32_to_cpu(m->addr);
m68k_memory[m68k_num_memory].size =
be32_to_cpu(m->size);
+ memblock_add(m68k_memory[m68k_num_memory].addr,
+m68k_memory[m68k_num_memory].size);
m68k_num_memory++;
} else
pr_warn("%s: too many memory chunks\n",
@@ -224,10 +227,6 @@ static void __init m68k_parse_bootinfo(const struct
bi_record *record)
void __init setup_arch(char **cmdline_p)
{
-#ifndef CONFIG_SUN3
- int i;
-#endif
-
/* The bootinfo is located right after the kernel */
if (!CPU_IS_COLDFIRE)
m68k_parse_bootinfo((const struct bi_record *)_end);
@@ -356,14 +355,9 @@ void __init setup_arch(char **cmdline_p)
#endif
#ifndef CONFIG_SUN3
- for (i = 1; i < m68k_num_memory; i++)
- free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
- m68k_memory[i].size);
#ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
-
reserve_bootmem_node(__virt_to_node(phys_to_virt(m68k_ramdisk.addr)),
-m68k_ramdisk.addr, m68k_ramdisk.size,
-BOOTMEM_DEFAULT);
+ memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index a98af10..3e8d87a 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -86,8 +87,6 @@ void (*mach_power_off)(void);
void __init setup_arch(char **cmdline_p)
{
- int bootmap_size;
-
memory_start = PAGE_ALIGN(_ramstart);
memory_end = _ramend;
@@ -142,6 +141,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
+ memblock_add(memory_start, memory_end - memory_start);
+
/* Keep a copy of command line */
*cmdline_p = _line[0];
memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
@@ -158,23 +159,10 @@ void __init setup_arch(char **cmdline_p)
min_low_pfn = PFN_DOWN(memory_start);
max_pfn = max_low_pfn = PFN_DOWN(memory_end);
- bootmap_size = init_bootmem_node(
- NODE_DATA(0),
- min_low_pfn,/* map goes here */
- PFN_DOWN(PAGE_OFFSET),
- max_pfn);
- /*
Re: [PATCH 0/5] m68k: IO Fixes and Cleanups
Hi Geert,
On 02/07/18 23:35, Geert Uytterhoeven wrote:
Hi all,
This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).
The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are dependencies
for further cleanup.
Patch 4 and 5 complete the cleanup.
Given the dependencies, I think it's easiest if the respective
maintainers would provide their Acked-by, so all patches can go in
through the m68k tree.
Thanks for your comments!
I like it alot. If we can just fix up the warnings caused by patch
number 1 I am more than happy to ack.
Regards
Greg
Geert Uytterhoeven (5):
m68k/io: Add missing ioremap define guards, fix typo
net: mac8390: Use standard memcpy_{from,to}io()
Input: hilkbd - Add casts to HP9000/300 I/O accessors
m68k/io: Move mem*io define guards to
m68k/io: Switch mmu variant to
arch/m68k/include/asm/io.h | 7 +
arch/m68k/include/asm/io_mm.h | 40 +++--
arch/m68k/include/asm/io_no.h | 12 -
arch/m68k/include/asm/kmap.h| 7 -
drivers/input/keyboard/hilkbd.c | 4 +--
drivers/net/ethernet/8390/mac8390.c | 20 +++
6 files changed, 28 insertions(+), 62 deletions(-)
Re: [PATCH 0/5] m68k: IO Fixes and Cleanups
Hi Geert,
On 02/07/18 23:35, Geert Uytterhoeven wrote:
Hi all,
This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).
The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are dependencies
for further cleanup.
Patch 4 and 5 complete the cleanup.
Given the dependencies, I think it's easiest if the respective
maintainers would provide their Acked-by, so all patches can go in
through the m68k tree.
Thanks for your comments!
I like it alot. If we can just fix up the warnings caused by patch
number 1 I am more than happy to ack.
Regards
Greg
Geert Uytterhoeven (5):
m68k/io: Add missing ioremap define guards, fix typo
net: mac8390: Use standard memcpy_{from,to}io()
Input: hilkbd - Add casts to HP9000/300 I/O accessors
m68k/io: Move mem*io define guards to
m68k/io: Switch mmu variant to
arch/m68k/include/asm/io.h | 7 +
arch/m68k/include/asm/io_mm.h | 40 +++--
arch/m68k/include/asm/io_no.h | 12 -
arch/m68k/include/asm/kmap.h| 7 -
drivers/input/keyboard/hilkbd.c | 4 +--
drivers/net/ethernet/8390/mac8390.c | 20 +++
6 files changed, 28 insertions(+), 62 deletions(-)
Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code
Hi Geert, On 22/06/18 16:35, Geert Uytterhoeven wrote: On Fri, Jun 22, 2018 at 2:20 AM Greg Ungerer wrote: On 22/06/18 06:30, Geert Uytterhoeven wrote: If DEBUG_DMA is defined: include/asm/dma.h: In function ‘set_dma_mode’: include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this function) include/asm/dma.h:393: error: (Each undeclared identifier is reported only once include/asm/dma.h:393: error: for each function it appears in.) include/asm/dma.h: In function ‘set_dma_addr’: include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this function) Reported-by: kbuild test robot Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer Do you want me to take this via the m68knommu git tree? Yes please. Thx! Done! Regards Greg
Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code
Hi Geert, On 22/06/18 16:35, Geert Uytterhoeven wrote: On Fri, Jun 22, 2018 at 2:20 AM Greg Ungerer wrote: On 22/06/18 06:30, Geert Uytterhoeven wrote: If DEBUG_DMA is defined: include/asm/dma.h: In function ‘set_dma_mode’: include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this function) include/asm/dma.h:393: error: (Each undeclared identifier is reported only once include/asm/dma.h:393: error: for each function it appears in.) include/asm/dma.h: In function ‘set_dma_addr’: include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this function) Reported-by: kbuild test robot Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer Do you want me to take this via the m68knommu git tree? Yes please. Thx! Done! Regards Greg
Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code
Hi Geert,
On 22/06/18 06:30, Geert Uytterhoeven wrote:
If DEBUG_DMA is defined:
include/asm/dma.h: In function ‘set_dma_mode’:
include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this
function)
include/asm/dma.h:393: error: (Each undeclared identifier is reported only
once
include/asm/dma.h:393: error: for each function it appears in.)
include/asm/dma.h: In function ‘set_dma_addr’:
include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this
function)
Reported-by: kbuild test robot
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Do you want me to take this via the m68knommu git tree?
Regards
Greg
---
v2:
- Add Acked-by.
---
arch/m68k/include/asm/dma.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index b0978a23bad1d7ee..ae2021964e32d36f 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -390,7 +390,7 @@ static __inline__ void set_dma_mode(unsigned int dmanr,
char mode)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x DIR[%x]=%x\n", __FILE__, __LINE__,
- dmanr, (int) [MCFDMA_DMR], dmabp[MCFDMA_DMR],
+dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DIR], dmawp[MCFDMA_DIR]);
#endif
}
@@ -421,7 +421,7 @@ static __inline__ void set_dma_addr(unsigned int dmanr,
unsigned int a)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x SAR[%x]=%08x DAR[%x]=%08x\n",
- __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmawp[MCFDMA_DMR],
+ __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DSAR], dmalp[MCFDMA_DSAR],
(int) [MCFDMA_DDAR], dmalp[MCFDMA_DDAR]);
#endif
Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code
Hi Geert,
On 22/06/18 06:30, Geert Uytterhoeven wrote:
If DEBUG_DMA is defined:
include/asm/dma.h: In function ‘set_dma_mode’:
include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this
function)
include/asm/dma.h:393: error: (Each undeclared identifier is reported only
once
include/asm/dma.h:393: error: for each function it appears in.)
include/asm/dma.h: In function ‘set_dma_addr’:
include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this
function)
Reported-by: kbuild test robot
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Do you want me to take this via the m68knommu git tree?
Regards
Greg
---
v2:
- Add Acked-by.
---
arch/m68k/include/asm/dma.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index b0978a23bad1d7ee..ae2021964e32d36f 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -390,7 +390,7 @@ static __inline__ void set_dma_mode(unsigned int dmanr,
char mode)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x DIR[%x]=%x\n", __FILE__, __LINE__,
- dmanr, (int) [MCFDMA_DMR], dmabp[MCFDMA_DMR],
+dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DIR], dmawp[MCFDMA_DIR]);
#endif
}
@@ -421,7 +421,7 @@ static __inline__ void set_dma_addr(unsigned int dmanr,
unsigned int a)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x SAR[%x]=%08x DAR[%x]=%08x\n",
- __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmawp[MCFDMA_DMR],
+ __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DSAR], dmalp[MCFDMA_DSAR],
(int) [MCFDMA_DDAR], dmalp[MCFDMA_DDAR]);
#endif
Re: [PATCH] m68k: fix "bad page state" oops on ColdFire boot
Hi Geert,
On 18/06/18 16:58, Geert Uytterhoeven wrote:
Hi Greg,
On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer wrote:
Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):
BUG: Bad page state in process sh pfn:01ce2
page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
flags: 0x0()
raw: fbff 0100 0200
raw: 039c4000
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13
Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.
Signed-off-by: Greg Ungerer
CC: Matthew Wilcox
---
arch/m68k/include/asm/mcf_pgalloc.h | 1 +
1 file changed, 1 insertion(+)
Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
about a similar problem with openrisc. Based on that I came up
with this fix for m68k/ColdFire. Fixes the issue for me.
diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..8c441eb57b80 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned
long address)
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
unsigned long address)
{
+ pgtable_page_dtor(page);
__free_page(page);
}
Do you need a call to pgtable_page_dtor() in pte_free(), too?
On x86 (and motorola_pgalloc.h and sun3_pgalloc.h FWIW), both functions
call pgtable_page_dtor().
I am thinking yes, looking at those other examples.
Regards
Greg
Re: [PATCH] m68k: fix "bad page state" oops on ColdFire boot
Hi Geert,
On 18/06/18 16:58, Geert Uytterhoeven wrote:
Hi Greg,
On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer wrote:
Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):
BUG: Bad page state in process sh pfn:01ce2
page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
flags: 0x0()
raw: fbff 0100 0200
raw: 039c4000
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13
Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.
Signed-off-by: Greg Ungerer
CC: Matthew Wilcox
---
arch/m68k/include/asm/mcf_pgalloc.h | 1 +
1 file changed, 1 insertion(+)
Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
about a similar problem with openrisc. Based on that I came up
with this fix for m68k/ColdFire. Fixes the issue for me.
diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..8c441eb57b80 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned
long address)
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
unsigned long address)
{
+ pgtable_page_dtor(page);
__free_page(page);
}
Do you need a call to pgtable_page_dtor() in pte_free(), too?
On x86 (and motorola_pgalloc.h and sun3_pgalloc.h FWIW), both functions
call pgtable_page_dtor().
I am thinking yes, looking at those other examples.
Regards
Greg
