Re: [ 00/17] 3.0.84-stable review
From: Greg Ungerer
Date: Thu Aug 01 2013 - 10:35:42 EST
Hi Guenter,
Sorry, I am way behind on this...
On 27/06/13 09:29, Guenter Roeck wrote:
On Thu, Jun 27, 2013 at 09:06:11AM +1000, Greg Ungerer wrote:
On 26/06/13 17:34, Geert Uytterhoeven wrote:
On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
Hi GÃnther,
On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Build m68k:defconfig passed
Build m68k:apollo_defconfig passed
Build m68k:m5272c3_defconfig failed
Build m68k:m5307c3_defconfig failed
Build m68k:m5249evb_defconfig failed
Build m68k:m5407c3_defconfig failed
Build m68k:mac_defconfig passed
Build m68k:multi_defconfig passed
Build m68k:sun3_defconfig passed
Build m68k:sun3x_defconfig passed
Build m68k:mvme16x_defconfig passed
Build m68k:hp300_defconfig passed
m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
one of them.
Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
only marginally. Of course, if you have too many spare cycles ;-)
Thanks, I'll do that. The complete build for three releases takes 15+ hours
with i7-3700k, so reducing that a bit doesn't hurt.
FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
Would there be any useful builds to add ?
You could add m68k:m5475evb_defconfig, which is the only Coldfire
defconfig with MMU=y.
Greg: Any other advice for Coldfire?
I might have some, except I am not sure what we are talking about.
I don't have enough context from the above alone :-)
Just trying to figure out an optimal set of targets for test builds.
I take it this is test building 3.0.84?
Yes
I haven't built a 3.0.x for a while, so not sure why the above
ColdFire targets are failing without going and trying it out.
Lots of assembler error messages, plus complaints about redefinitions and
implicit declarations.
arch/m68k/platform/coldfire/entry.S: Assembler messages:
arch/m68k/platform/coldfire/entry.S:64: Error: Unknown operator -- statement `save_all' ignored
arch/m68k/platform/coldfire/entry.S:91: Error: operands mismatch -- statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:143: Error: Unknown operator -- statement `restore_user' ignored
arch/m68k/platform/coldfire/entry.S:192: Error: Unknown operator -- statement `rdusp' ignored
arch/m68k/platform/coldfire/entry.S:201: Error: Unknown operator -- statement `wrusp' ignored
In file included from arch/m68k/mm/init.c:4:0:
arch/m68k/mm/init_no.c:45:15: error: conflicting types for âempty_zero_pageâ
/home/groeck/src/linux-stable/arch/m68k/include/asm/pgtable_mm.h:92:14: note: previous declaration of âempty_zero_pageâ was here
arch/m68k/kernel/setup_no.c: In function 'setup_arch':
arch/m68k/kernel/setup_no.c:264:2: error: implicit declaration of function 'paging_init' [-Werror=implicit-function-declaration]
/tmp/ccjVitY8.s:120: Error: invalid instruction for this architecture; needs 68010 or higher (68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `moves.l %d1,(%a2)' ignored
and so on. Not that it tells me anything. I'd guess I have the wrong compiler, but it does
build for 3.9, so maybe not. If you have an insight, please let me know.
Yes, this is the wrong compiler. You needed to use a m68k-uclinux
targeted toolchain for 3.0 and older kernels. There are changes to
the m68k arch Makefile and linker scripts on newer kernels that mean
you can now use an m68k-linux- toolchain (that is why 3.9 compiles
cleanly).
Its reasonably easy to fix this on 3.0.x kernels if you want this.
The below patch does it. I don't have any firm opinion on whether
you want to apply this to the stable 3.0.x tree. Anyone using 3.0.x
on m68knommu has always had to use a m68k-uclinux- toolchain up to
now.
Regards
Greg
m68k: allow m68knommu targets to build with an m68k-linux toolchain
Non-mmu m68k arch targets fail to compile with a traditional m68k-linux
toolchain. Some code relies on __uClinux__ being implicitly defined.
We can just define it in our arch Makefile to satisfy this. We will
also need to add the notes section to the linker script to get a
successful build.
Singed-off-by: Greg Ungerer <gerg@xxxxxxxxxxx>
--- linux-3.0.88/arch/m68k/Makefile_no.org 2013-08-01 23:47:39.953081304
+1000
+++ linux-3.0.88/arch/m68k/Makefile_no 2013-08-01 23:50:37.453077257 +1000
@@ -107,9 +107,11 @@
cflags-$(CONFIG_M68360) := -m68332
KBUILD_AFLAGS += $(cflags-y)
+KBUILD_AFLAGS += -D__uClinux__
KBUILD_CFLAGS += $(cflags-y)
KBUILD_CFLAGS += -D__linux__
+KBUILD_CFLAGS += -D__uClinux__
KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
head-y := arch/m68k/platform/$(cpuclass-y)/head.o
--- linux-3.0.88/arch/m68k/kernel/vmlinux.lds_no.S.org 2013-08-01
23:58:49.913160401 +1000
+++ linux-3.0.88/arch/m68k/kernel/vmlinux.lds_no.S 2013-08-02
00:00:34.373904823 +1000
@@ -75,6 +75,10 @@
*(__ex_table)
__stop___ex_table = .;
+ __start_notes = .;
+ *(.note.*)
+ __stop_notes = .;
+
*(.rodata) *(.rodata.*)
*(__vermagic) /* Kernel version magic */
*(__markers_strings)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/