Hi
I am using an Olimex A20 SOM with NAND and due to some binary blob for
NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
here: https://github.com/linux-sunxi/linux-sunxi)
I am currently using buildroot-2016 and gcc-5.5 for building the
kernel and every other package needed.
Now the requirement is to move to the latest version of gcc-9.x, so
that we can have glibc++ provided by the gcc-9.1 toolchain.
Main problem for moving to later versions of buildroot is the kernel
3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
gcc-9.1 requirement is mandatory so now have to look into compiling
linux-3.4 with gcc-9.1 or above.
Now I need some help.
-- Is it realistic to expect 3.4 kernel compiling and boot
successfully with gcc-9.1?
-- Secondly, till now I am able to compile until the point when its
going to generate the vmlinuz image, it failed with error at LD stage:
arm-none-linux-gnueabihf-ld: no machine record defined
Last few lines from compile log:
-------------------------------------------------------------------------------
include/linux/init.h:267:24: note: in expansion of macro ‘__initcall’
267 | #define module_init(x) __initcall(x);
| ^~~~~~~~~~
net/sunrpc/auth_gss/auth_gss.c:1721:1: note: in expansion of macro ‘module_init’
1721 | module_init(init_rpcsec_gss)
| ^~~~~~~~~~~
In file included from include/linux/kernel.h:20,
from include/linux/spinlock.h:55,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:4,
from include/linux/slab.h:12,
from net/sunrpc/auth_gss/svcauth_gss.c:40:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
LD net/sunrpc/auth_gss/auth_rpcgss.o
LD net/sunrpc/auth_gss/built-in.o
LD net/sunrpc/built-in.o
LD net/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
In file included from include/linux/kernel.h:20,
from include/linux/cache.h:4,
from include/linux/time.h:7,
from include/linux/stat.h:60,
from include/linux/module.h:10,
from init/version.c:10:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
LD init/built-in.o
LD .tmp_vmlinux1
arm-none-linux-gnueabihf-ld: no machine record defined
Makefile:875: recipe for target '.tmp_vmlinux1' failed
make: *** [.tmp_vmlinux1] Error 1
-------------------------------------------------------------------------------
After some investigation I found that the MACHINE_START macro from
arch/arm/include/asm/mach/arch.h is optimised by compiler and removed
from the object file during compilation of
"arch/arm/plat-sunxi/core.c" due to the error here:
---------------------------------------------------------------
flateef@flateef-XPS-13-9360:~/src/tmp/linux-custom-venus-gc-9.2$ make
ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- EXTRAVERSION=-custom1
uImage LOADADDR="0x40008000" -j4
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC arch/arm/plat-sunxi/core.o
In file included from include/linux/kernel.h:20,
from arch/arm/plat-sunxi/core.c:20:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
In file included from include/linux/scatterlist.h:10,
from include/linux/dma-mapping.h:9,
from arch/arm/plat-sunxi/core.c:24:
arch/arm/plat-sunxi/core.c: In function ‘sw_irq_unmask’:
arch/arm/plat-sunxi/core.c:287:14: warning: left shift count >= width
of type [-Wshift-count-overflow]
287 | writel((1 << SW_INT_IRQNO_ENMI), SW_INT_IRQ_PENDING_REG0);
| ^~
/home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/io.h:52:88:
note: in definition of macro ‘__raw_writel’
52 | #define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile
unsigned int __force *)(a) = (v))
|
^
include/linux/byteorder/generic.h:87:21: note: in expansion of macro
‘__cpu_to_le32’
87 | #define cpu_to_le32 __cpu_to_le32
| ^~~~~~~~~~~~~
/home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/io.h:244:36:
note: in expansion of macro ‘writel_relaxed’
244 | #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
| ^~~~~~~~~~~~~~
arch/arm/plat-sunxi/core.c:287:4: note: in expansion of macro ‘writel’
287 | writel((1 << SW_INT_IRQNO_ENMI), SW_INT_IRQ_PENDING_REG0);
| ^~~~~~
In file included from arch/arm/plat-sunxi/core.c:53:
At top level:
/home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
warning: ‘__mach_desc_SUN7I’ defined but not used
[-Wunused-const-variable=]
69 | static const struct machine_desc __mach_desc_##_type \
| ^~~~~~~~~~~~
arch/arm/plat-sunxi/core.c:424:1: note: in expansion of macro ‘MACHINE_START’
424 | MACHINE_START(SUN7I, "sun7i")
| ^~~~~~~~~~~~~
/home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
warning: ‘__mach_desc_SUN5I’ defined but not used
[-Wunused-const-variable=]
69 | static const struct machine_desc __mach_desc_##_type \
| ^~~~~~~~~~~~
arch/arm/plat-sunxi/core.c:410:1: note: in expansion of macro ‘MACHINE_START’
410 | MACHINE_START(SUN5I, "sun5i")
| ^~~~~~~~~~~~~
/home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
warning: ‘__mach_desc_SUN4I’ defined but not used
[-Wunused-const-variable=]
69 | static const struct machine_desc __mach_desc_##_type \
| ^~~~~~~~~~~~
arch/arm/plat-sunxi/core.c:396:1: note: in expansion of macro ‘MACHINE_START’
396 | MACHINE_START(SUN4I, "sun4i")
| ^~~~~~~~~~~~~
LD arch/arm/plat-sunxi/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
In file included from include/linux/kernel.h:20,
from include/linux/cache.h:4,
from include/linux/time.h:7,
from include/linux/stat.h:60,
from include/linux/module.h:10,
from init/version.c:10:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
LD init/built-in.o
LD .tmp_vmlinux1
arm-none-linux-gnueabihf-ld: no machine record defined
Makefile:875: recipe for target '.tmp_vmlinux1' failed
make: *** [.tmp_vmlinux1] Error 1
---------------------------------------------------------------
I modified the MACHINE_START macro in arch/arm/include/asm/mach/arch.h
and added "__attribute__((used))" so it became:
static const struct machine_desc __mach_desc_##_type
__attribute__((used)) \
And I managed to get the vmlinux image.
-------------------------------------------------------------
arch/arm/mm/mmu.c:919:1: note: in expansion of macro ‘early_param’
919 | early_param("vmalloc", early_vmalloc);
| ^~~~~~~~~~~
include/linux/init.h:241:33: warning: ‘__setup_noalign_setup’ defined
but not used [-Wunused-variable]
241 | static struct obs_kernel_param __setup_##unique_id \
| ^~~~~~~~
include/linux/init.h:247:2: note: in expansion of macro ‘__setup_param’
247 | __setup_param(str, fn, fn, 0)
| ^~~~~~~~~~~~~
arch/arm/mm/mmu.c:175:1: note: in expansion of macro ‘__setup’
175 | __setup("noalign", noalign_setup);
| ^~~~~~~
include/linux/init.h:241:33: warning: ‘__setup_early_ecc’ defined but
not used [-Wunused-variable]
241 | static struct obs_kernel_param __setup_##unique_id \
| ^~~~~~~~
include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
252 | __setup_param(str, fn, fn, 1)
| ^~~~~~~~~~~~~
arch/arm/mm/mmu.c:165:1: note: in expansion of macro ‘early_param’
165 | early_param("ecc", early_ecc);
| ^~~~~~~~~~~
include/linux/init.h:241:33: warning: ‘__setup_early_nowrite’ defined
but not used [-Wunused-variable]
241 | static struct obs_kernel_param __setup_##unique_id \
| ^~~~~~~~
include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
252 | __setup_param(str, fn, fn, 1)
| ^~~~~~~~~~~~~
arch/arm/mm/mmu.c:154:1: note: in expansion of macro ‘early_param’
154 | early_param("nowb", early_nowrite);
| ^~~~~~~~~~~
include/linux/init.h:241:33: warning: ‘__setup_early_nocache’ defined
but not used [-Wunused-variable]
241 | static struct obs_kernel_param __setup_##unique_id \
| ^~~~~~~~
include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
252 | __setup_param(str, fn, fn, 1)
| ^~~~~~~~~~~~~
arch/arm/mm/mmu.c:145:1: note: in expansion of macro ‘early_param’
145 | early_param("nocache", early_nocache);
| ^~~~~~~~~~~
include/linux/init.h:241:33: warning: ‘__setup_early_cachepolicy’
defined but not used [-Wunused-variable]
241 | static struct obs_kernel_param __setup_##unique_id \
| ^~~~~~~~
include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
252 | __setup_param(str, fn, fn, 1)
| ^~~~~~~~~~~~~
arch/arm/mm/mmu.c:136:1: note: in expansion of macro ‘early_param’
136 | early_param("cachepolicy", early_cachepolicy);
| ^~~~~~~~~~~
AS arch/arm/kernel/head.o
LD arch/arm/kernel/built-in.o
AS arch/arm/mm/cache-v7.o
AS arch/arm/mm/tlb-v7.o
AS arch/arm/mm/proc-v7.o
LD arch/arm/mm/built-in.o
AS arch/arm/lib/copy_page.o
AS arch/arm/lib/csumpartialcopyuser.o
AR arch/arm/lib/lib.a
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
In file included from include/linux/kernel.h:20,
from include/linux/cache.h:4,
from include/linux/time.h:7,
from include/linux/stat.h:60,
from include/linux/module.h:10,
from init/version.c:10:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
XZKERN arch/arm/boot/compressed/piggy.xzkern
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
CC arch/arm/boot/compressed/string.o
In file included from include/linux/kernel.h:20,
from
arch/arm/boot/compressed/../../../../lib/xz/xz_private.h:15,
from
arch/arm/boot/compressed/../../../../lib/decompress_unxz.c:145,
from arch/arm/boot/compressed/decompress.c:50:
include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
because it conflicts with attribute ‘const’ [-Wattributes]
22 | int ____ilog2_NaN(void);
| ^~~
SHIPPED arch/arm/boot/compressed/lib1funcs.S
SHIPPED arch/arm/boot/compressed/ashldi3.S
AS arch/arm/boot/compressed/lib1funcs.o
AS arch/arm/boot/compressed/ashldi3.o
AS arch/arm/boot/compressed/piggy.xzkern.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.4.113-custom1
Created: Sun Mar 28 20:27:03 2021
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1869496 Bytes = 1825.68 KiB = 1.78 MiB
Load Address: 40008000
Entry Point: 40008000
Image arch/arm/boot/uImage is ready
-----------------------------------------------------------------------------
-- I still can't boot the kernel on the platform. I believe its
because there were lots of warning like above (unused const variables
etc) and might have removed some other code/functions OR macros?
So please suggest what I can do for compiling working kernel-3.4 with gcc-9.
Thanks in advance,
-- Fawad Lateef
On Sun, 28 Mar 2021 at 22:49, Andy Shevchenko <[email protected]> wrote:
>
>
>
> On Sunday, March 28, 2021, Fawad Lateef <[email protected]> wrote:
>>
>> Hi
>>
>> I am using an Olimex A20 SOM with NAND and due to some binary blob for
>> NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
>> here: https://github.com/linux-sunxi/linux-sunxi)
>>
>> I am currently using buildroot-2016 and gcc-5.5 for building the
>> kernel and every other package needed.
>>
>> Now the requirement is to move to the latest version of gcc-9.x, so
>> that we can have glibc++ provided by the gcc-9.1 toolchain.
>>
>> Main problem for moving to later versions of buildroot is the kernel
>> 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
>> gcc-9.1 requirement is mandatory so now have to look into compiling
>> linux-3.4 with gcc-9.1 or above.
>>
>> Now I need some help.
>>
>> -- Is it realistic to expect 3.4 kernel compiling and boot
>> successfully with gcc-9.1?
>
>
> Pretty much, but i’m not sure the patches will be acceptable by upstream / stable.
Upstream patch is not really a concern as we are already running a
non-upstream kernel from sunxi.
>
>>
>> -- Secondly, till now I am able to compile until the point when its
>> going to generate the vmlinuz image, it failed with error at LD stage:
>> arm-none-linux-gnueabihf-ld: no machine record defined
>>
>> Last few lines from compile log:
>>
>> -------------------------------------------------------------------------------
>> include/linux/init.h:267:24: note: in expansion of macro ‘__initcall’
>> 267 | #define module_init(x) __initcall(x);
>> | ^~~~~~~~~~
>> net/sunrpc/auth_gss/auth_gss.c:1721:1: note: in expansion of macro ‘module_init’
>> 1721 | module_init(init_rpcsec_gss)
>> | ^~~~~~~~~~~
>> In file included from include/linux/kernel.h:20,
>> from include/linux/spinlock.h:55,
>> from include/linux/mmzone.h:7,
>> from include/linux/gfp.h:4,
>> from include/linux/slab.h:12,
>> from net/sunrpc/auth_gss/svcauth_gss.c:40:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> LD net/sunrpc/auth_gss/auth_rpcgss.o
>> LD net/sunrpc/auth_gss/built-in.o
>> LD net/sunrpc/built-in.o
>> LD net/built-in.o
>> LD vmlinux.o
>> MODPOST vmlinux.o
>> GEN .version
>> CHK include/generated/compile.h
>> UPD include/generated/compile.h
>> CC init/version.o
>> In file included from include/linux/kernel.h:20,
>> from include/linux/cache.h:4,
>> from include/linux/time.h:7,
>> from include/linux/stat.h:60,
>> from include/linux/module.h:10,
>> from init/version.c:10:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> arm-none-linux-gnueabihf-ld: no machine record defined
>> Makefile:875: recipe for target '.tmp_vmlinux1' failed
>> make: *** [.tmp_vmlinux1] Error 1
>> -------------------------------------------------------------------------------
>>
>>
>> After some investigation I found that the MACHINE_START macro from
>> arch/arm/include/asm/mach/arch.h is optimised by compiler and removed
>> from the object file during compilation of
>> "arch/arm/plat-sunxi/core.c" due to the error here:
>>
>> ---------------------------------------------------------------
>>
>> flateef@flateef-XPS-13-9360:~/src/tmp/linux-custom-venus-gc-9.2$ make
>> ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- EXTRAVERSION=-custom1
>> uImage LOADADDR="0x40008000" -j4
>> CHK include/linux/version.h
>> CHK include/generated/utsrelease.h
>> make[1]: 'include/generated/mach-types.h' is up to date.
>> CALL scripts/checksyscalls.sh
>> CHK include/generated/compile.h
>> CC arch/arm/plat-sunxi/core.o
>> In file included from include/linux/kernel.h:20,
>> from arch/arm/plat-sunxi/core.c:20:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> In file included from include/linux/scatterlist.h:10,
>> from include/linux/dma-mapping.h:9,
>> from arch/arm/plat-sunxi/core.c:24:
>> arch/arm/plat-sunxi/core.c: In function ‘sw_irq_unmask’:
>> arch/arm/plat-sunxi/core.c:287:14: warning: left shift count >= width
>> of type [-Wshift-count-overflow]
>> 287 | writel((1 << SW_INT_IRQNO_ENMI), SW_INT_IRQ_PENDING_REG0);
>> | ^~
>> /home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/io.h:52:88:
>> note: in definition of macro ‘__raw_writel’
>> 52 | #define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile
>> unsigned int __force *)(a) = (v))
>> |
>> ^
>> include/linux/byteorder/generic.h:87:21: note: in expansion of macro
>> ‘__cpu_to_le32’
>> 87 | #define cpu_to_le32 __cpu_to_le32
>> | ^~~~~~~~~~~~~
>> /home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/io.h:244:36:
>> note: in expansion of macro ‘writel_relaxed’
>> 244 | #define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
>> | ^~~~~~~~~~~~~~
>> arch/arm/plat-sunxi/core.c:287:4: note: in expansion of macro ‘writel’
>> 287 | writel((1 << SW_INT_IRQNO_ENMI), SW_INT_IRQ_PENDING_REG0);
>> | ^~~~~~
>> In file included from arch/arm/plat-sunxi/core.c:53:
>> At top level:
>> /home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
>> warning: ‘__mach_desc_SUN7I’ defined but not used
>> [-Wunused-const-variable=]
>> 69 | static const struct machine_desc __mach_desc_##_type \
>> | ^~~~~~~~~~~~
>> arch/arm/plat-sunxi/core.c:424:1: note: in expansion of macro ‘MACHINE_START’
>> 424 | MACHINE_START(SUN7I, "sun7i")
>> | ^~~~~~~~~~~~~
>> /home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
>> warning: ‘__mach_desc_SUN5I’ defined but not used
>> [-Wunused-const-variable=]
>> 69 | static const struct machine_desc __mach_desc_##_type \
>> | ^~~~~~~~~~~~
>> arch/arm/plat-sunxi/core.c:410:1: note: in expansion of macro ‘MACHINE_START’
>> 410 | MACHINE_START(SUN5I, "sun5i")
>> | ^~~~~~~~~~~~~
>> /home/flateef/src/tmp/linux-custom-venus-gc-9.2/arch/arm/include/asm/mach/arch.h:69:34:
>> warning: ‘__mach_desc_SUN4I’ defined but not used
>> [-Wunused-const-variable=]
>> 69 | static const struct machine_desc __mach_desc_##_type \
>> | ^~~~~~~~~~~~
>> arch/arm/plat-sunxi/core.c:396:1: note: in expansion of macro ‘MACHINE_START’
>> 396 | MACHINE_START(SUN4I, "sun4i")
>> | ^~~~~~~~~~~~~
>> LD arch/arm/plat-sunxi/built-in.o
>> LD vmlinux.o
>> MODPOST vmlinux.o
>> GEN .version
>> CHK include/generated/compile.h
>> UPD include/generated/compile.h
>> CC init/version.o
>> In file included from include/linux/kernel.h:20,
>> from include/linux/cache.h:4,
>> from include/linux/time.h:7,
>> from include/linux/stat.h:60,
>> from include/linux/module.h:10,
>> from init/version.c:10:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> arm-none-linux-gnueabihf-ld: no machine record defined
>> Makefile:875: recipe for target '.tmp_vmlinux1' failed
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> ---------------------------------------------------------------
>>
>> I modified the MACHINE_START macro in arch/arm/include/asm/mach/arch.h
>> and added "__attribute__((used))" so it became:
>>
>> static const struct machine_desc __mach_desc_##_type
>> __attribute__((used)) \
>>
>> And I managed to get the vmlinux image.
>>
>> -------------------------------------------------------------
>>
>>
>> arch/arm/mm/mmu.c:919:1: note: in expansion of macro ‘early_param’
>> 919 | early_param("vmalloc", early_vmalloc);
>> | ^~~~~~~~~~~
>> include/linux/init.h:241:33: warning: ‘__setup_noalign_setup’ defined
>> but not used [-Wunused-variable]
>> 241 | static struct obs_kernel_param __setup_##unique_id \
>> | ^~~~~~~~
>> include/linux/init.h:247:2: note: in expansion of macro ‘__setup_param’
>> 247 | __setup_param(str, fn, fn, 0)
>> | ^~~~~~~~~~~~~
>> arch/arm/mm/mmu.c:175:1: note: in expansion of macro ‘__setup’
>> 175 | __setup("noalign", noalign_setup);
>> | ^~~~~~~
>> include/linux/init.h:241:33: warning: ‘__setup_early_ecc’ defined but
>> not used [-Wunused-variable]
>> 241 | static struct obs_kernel_param __setup_##unique_id \
>> | ^~~~~~~~
>> include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
>> 252 | __setup_param(str, fn, fn, 1)
>> | ^~~~~~~~~~~~~
>> arch/arm/mm/mmu.c:165:1: note: in expansion of macro ‘early_param’
>> 165 | early_param("ecc", early_ecc);
>> | ^~~~~~~~~~~
>> include/linux/init.h:241:33: warning: ‘__setup_early_nowrite’ defined
>> but not used [-Wunused-variable]
>> 241 | static struct obs_kernel_param __setup_##unique_id \
>> | ^~~~~~~~
>> include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
>> 252 | __setup_param(str, fn, fn, 1)
>> | ^~~~~~~~~~~~~
>> arch/arm/mm/mmu.c:154:1: note: in expansion of macro ‘early_param’
>> 154 | early_param("nowb", early_nowrite);
>> | ^~~~~~~~~~~
>> include/linux/init.h:241:33: warning: ‘__setup_early_nocache’ defined
>> but not used [-Wunused-variable]
>> 241 | static struct obs_kernel_param __setup_##unique_id \
>> | ^~~~~~~~
>> include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
>> 252 | __setup_param(str, fn, fn, 1)
>> | ^~~~~~~~~~~~~
>> arch/arm/mm/mmu.c:145:1: note: in expansion of macro ‘early_param’
>> 145 | early_param("nocache", early_nocache);
>> | ^~~~~~~~~~~
>> include/linux/init.h:241:33: warning: ‘__setup_early_cachepolicy’
>> defined but not used [-Wunused-variable]
>> 241 | static struct obs_kernel_param __setup_##unique_id \
>> | ^~~~~~~~
>> include/linux/init.h:252:2: note: in expansion of macro ‘__setup_param’
>> 252 | __setup_param(str, fn, fn, 1)
>> | ^~~~~~~~~~~~~
>> arch/arm/mm/mmu.c:136:1: note: in expansion of macro ‘early_param’
>> 136 | early_param("cachepolicy", early_cachepolicy);
>> | ^~~~~~~~~~~
>> AS arch/arm/kernel/head.o
>> LD arch/arm/kernel/built-in.o
>> AS arch/arm/mm/cache-v7.o
>> AS arch/arm/mm/tlb-v7.o
>> AS arch/arm/mm/proc-v7.o
>> LD arch/arm/mm/built-in.o
>> AS arch/arm/lib/copy_page.o
>> AS arch/arm/lib/csumpartialcopyuser.o
>> AR arch/arm/lib/lib.a
>> LD vmlinux.o
>> MODPOST vmlinux.o
>> GEN .version
>> CHK include/generated/compile.h
>> UPD include/generated/compile.h
>> CC init/version.o
>> In file included from include/linux/kernel.h:20,
>> from include/linux/cache.h:4,
>> from include/linux/time.h:7,
>> from include/linux/stat.h:60,
>> from include/linux/module.h:10,
>> from init/version.c:10:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> KSYM .tmp_kallsyms1.S
>> AS .tmp_kallsyms1.o
>> LD .tmp_vmlinux2
>> KSYM .tmp_kallsyms2.S
>> AS .tmp_kallsyms2.o
>> LD vmlinux
>> SYSMAP System.map
>> SYSMAP .tmp_System.map
>> OBJCOPY arch/arm/boot/Image
>> Kernel: arch/arm/boot/Image is ready
>> AS arch/arm/boot/compressed/head.o
>> XZKERN arch/arm/boot/compressed/piggy.xzkern
>> CC arch/arm/boot/compressed/misc.o
>> CC arch/arm/boot/compressed/decompress.o
>> CC arch/arm/boot/compressed/string.o
>> In file included from include/linux/kernel.h:20,
>> from
>> arch/arm/boot/compressed/../../../../lib/xz/xz_private.h:15,
>> from
>> arch/arm/boot/compressed/../../../../lib/decompress_unxz.c:145,
>> from arch/arm/boot/compressed/decompress.c:50:
>> include/linux/log2.h:22:1: warning: ignoring attribute ‘noreturn’
>> because it conflicts with attribute ‘const’ [-Wattributes]
>> 22 | int ____ilog2_NaN(void);
>> | ^~~
>> SHIPPED arch/arm/boot/compressed/lib1funcs.S
>> SHIPPED arch/arm/boot/compressed/ashldi3.S
>> AS arch/arm/boot/compressed/lib1funcs.o
>> AS arch/arm/boot/compressed/ashldi3.o
>> AS arch/arm/boot/compressed/piggy.xzkern.o
>> LD arch/arm/boot/compressed/vmlinux
>> OBJCOPY arch/arm/boot/zImage
>> Kernel: arch/arm/boot/zImage is ready
>> UIMAGE arch/arm/boot/uImage
>> Image Name: Linux-3.4.113-custom1
>> Created: Sun Mar 28 20:27:03 2021
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 1869496 Bytes = 1825.68 KiB = 1.78 MiB
>> Load Address: 40008000
>> Entry Point: 40008000
>> Image arch/arm/boot/uImage is ready
>>
>>
>> -----------------------------------------------------------------------------
>>
>>
>> -- I still can't boot the kernel on the platform. I believe its
>> because there were lots of warning like above (unused const variables
>> etc) and might have removed some other code/functions OR macros?
>>
>> So please suggest what I can do for compiling working kernel-3.4 with gcc-9.
>
>
> Is it possible to switch to new kernel, like v4.4 or even newer?
As mentioned above, not possible. The mainline kernel doesn't support
the NAND chip/driver due to some binary blobs. So pretty much only
option for us is to stick with SUNXI provided 3.4.xxx kernel version.
(Mainline kernel supports Sunxi-A20 SOM from Olimex but only the eMMC
version _not_ NAND).
>
>>
>>
>> Thanks in advance,
>>
>> -- Fawad Lateef
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> Hi
>
> I am using an Olimex A20 SOM with NAND and due to some binary blob for
> NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> here: https://github.com/linux-sunxi/linux-sunxi)
Please work with the vendor that is forcing you to use this obsolete and
insecure kernel version. You are paying for that support, and they are
the only ones that can support you.
> I am currently using buildroot-2016 and gcc-5.5 for building the
> kernel and every other package needed.
>
> Now the requirement is to move to the latest version of gcc-9.x, so
> that we can have glibc++ provided by the gcc-9.1 toolchain.
>
> Main problem for moving to later versions of buildroot is the kernel
> 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
> gcc-9.1 requirement is mandatory so now have to look into compiling
> linux-3.4 with gcc-9.1 or above.
>
> Now I need some help.
>
> -- Is it realistic to expect 3.4 kernel compiling and boot
> successfully with gcc-9.1?
No. It took a lot of work and effort just to get the 4.4.y kernel to
work with that gcc version.
Again, please work with the company that you are already paying for
support from, they can do this for you.
good luck!
greg k-h
Hi Greg,
On Mon, 29 Mar 2021 at 06:57, Greg KH <[email protected]> wrote:
>
> On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> > Hi
> >
> > I am using an Olimex A20 SOM with NAND and due to some binary blob for
> > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> > here: https://github.com/linux-sunxi/linux-sunxi)
>
> Please work with the vendor that is forcing you to use this obsolete and
> insecure kernel version. You are paying for that support, and they are
> the only ones that can support you.
>
The problem is vendor Olimex now have eMMC based SOM which is
supported by mainline kernel _but_ they still selling NAND SOM and
only supporting 3.4 kernel (as this is the only latest version from
sunxi with NAND support, after that sunxi is now moved away from NAND
too).
> > I am currently using buildroot-2016 and gcc-5.5 for building the
> > kernel and every other package needed.
> >
> > Now the requirement is to move to the latest version of gcc-9.x, so
> > that we can have glibc++ provided by the gcc-9.1 toolchain.
> >
> > Main problem for moving to later versions of buildroot is the kernel
> > 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
> > gcc-9.1 requirement is mandatory so now have to look into compiling
> > linux-3.4 with gcc-9.1 or above.
> >
> > Now I need some help.
> >
> > -- Is it realistic to expect 3.4 kernel compiling and boot
> > successfully with gcc-9.1?
>
> No. It took a lot of work and effort just to get the 4.4.y kernel to
> work with that gcc version.
>
Ok, thanks for the information. Any pointers on what to look at if I
had to go this route for 3.4 kernel?
> Again, please work with the company that you are already paying for
> support from, they can do this for you.
>
From Olimex they say it's an open hardware platform, so I really can't
expect them to do anything for it.
(https://www.olimex.com/Products/SOM/A20/A20-SOM/ NAND version)
Thanks and regards,
Fawad Lateef
> good luck!
>
> greg k-h
On Mon, Mar 29, 2021 at 09:20:32PM +0200, Fawad Lateef wrote:
> Hi Greg,
>
>
>
> On Mon, 29 Mar 2021 at 06:57, Greg KH <[email protected]> wrote:
> >
> > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> > > Hi
> > >
> > > I am using an Olimex A20 SOM with NAND and due to some binary blob for
> > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> > > here: https://github.com/linux-sunxi/linux-sunxi)
> >
> > Please work with the vendor that is forcing you to use this obsolete and
> > insecure kernel version. You are paying for that support, and they are
> > the only ones that can support you.
> >
>
> The problem is vendor Olimex now have eMMC based SOM which is
> supported by mainline kernel _but_ they still selling NAND SOM and
> only supporting 3.4 kernel (as this is the only latest version from
> sunxi with NAND support, after that sunxi is now moved away from NAND
> too).
If they are forcing you to use a binary kernel module, then they are the
only ones that can give you support, sorry. That should be included in
the price you paid for the hardware. If not, you need to go complain to
your purchasing department :)
Good luck!
greg k-h
On Mon, Mar 29, 2021 at 9:23 PM Fawad Lateef <[email protected]> wrote:
>
> On Mon, 29 Mar 2021 at 06:57, Greg KH <[email protected]> wrote:
> >
> > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> > > Hi
> > >
> > > I am using an Olimex A20 SOM with NAND and due to some binary blob for
> > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> > > here: https://github.com/linux-sunxi/linux-sunxi)
> >
> > Please work with the vendor that is forcing you to use this obsolete and
> > insecure kernel version. You are paying for that support, and they are
> > the only ones that can support you.
> >
>
> The problem is vendor Olimex now have eMMC based SOM which is
> supported by mainline kernel _but_ they still selling NAND SOM and
> only supporting 3.4 kernel (as this is the only latest version from
> sunxi with NAND support, after that sunxi is now moved away from NAND
> too).
From a very quick look at the git history, I can tell that A20 NAND driver
support was added in linux-4.8. Have you actually tried a modern kernel?
There is also a howto document at
https://linux-sunxi.org/Mainline_NAND_Howto
The olimex board specific dts files seem to be missing the entry for
the nand controller. If you have trouble figuring out how to enable that
from the howto above, Olimex should be able to prove a small patch
for it.
> > > I am currently using buildroot-2016 and gcc-5.5 for building the
> > > kernel and every other package needed.
> > >
> > > Now the requirement is to move to the latest version of gcc-9.x, so
> > > that we can have glibc++ provided by the gcc-9.1 toolchain.
> > >
> > > Main problem for moving to later versions of buildroot is the kernel
> > > 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
> > > gcc-9.1 requirement is mandatory so now have to look into compiling
> > > linux-3.4 with gcc-9.1 or above.
There is no need to compile user space and kernel with the same compiler.
Arnd
Hi Arnd,
On Mon, 29 Mar 2021 at 22:06, Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Mar 29, 2021 at 9:23 PM Fawad Lateef <[email protected]> wrote:
> >
> > On Mon, 29 Mar 2021 at 06:57, Greg KH <[email protected]> wrote:
> > >
> > > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> > > > Hi
> > > >
> > > > I am using an Olimex A20 SOM with NAND and due to some binary blob for
> > > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> > > > here: https://github.com/linux-sunxi/linux-sunxi)
> > >
> > > Please work with the vendor that is forcing you to use this obsolete and
> > > insecure kernel version. You are paying for that support, and they are
> > > the only ones that can support you.
> > >
> >
> > The problem is vendor Olimex now have eMMC based SOM which is
> > supported by mainline kernel _but_ they still selling NAND SOM and
> > only supporting 3.4 kernel (as this is the only latest version from
> > sunxi with NAND support, after that sunxi is now moved away from NAND
> > too).
>
> From a very quick look at the git history, I can tell that A20 NAND driver
> support was added in linux-4.8. Have you actually tried a modern kernel?
>
I tried compiling and booting kernel v4.4 (from sunxi repo on github)
but unable to make it boot. Stuck at "Starting kernel". By the way I
am booting from RAM (using the sunxi usbboot/usb-otg option).
You mentioned that it's supported from linux-4.8 (from your quick look
at git history); can you tell me which driver/files? As I was able to
see some sort of sunxi NAND driver even in v4.4 kernel
(https://lxr.missinglinkelectronics.com/linux+v4.4/drivers/mtd/nand/sunxi_nand.c).
When I tried to compare with the sunxi-3.4 kernel code, I found that
the kernel has code for "nfc" but no reference to "nfd" (I don't know
what they are referring to).
The sunxi 3.4 kernel NAND driver at quick look seems quite different.
(https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4/drivers/block/sunxi_nand)
I will try the v4.8 or above kernel.
> There is also a howto document at
> https://linux-sunxi.org/Mainline_NAND_Howto
>
I somehow missed this earlier :( And the prerequisite says kernel
4.10 above and some extra patch set). Will look into it too. Thanks
for the link
> The olimex board specific dts files seem to be missing the entry for
> the nand controller. If you have trouble figuring out how to enable that
> from the howto above, Olimex should be able to prove a small patch
> for it.
>
Will see. As above link have some details regarding this which might be helpful.
> > > > I am currently using buildroot-2016 and gcc-5.5 for building the
> > > > kernel and every other package needed.
> > > >
> > > > Now the requirement is to move to the latest version of gcc-9.x, so
> > > > that we can have glibc++ provided by the gcc-9.1 toolchain.
> > > >
> > > > Main problem for moving to later versions of buildroot is the kernel
> > > > 3.4 which we couldn't to work with gcc-6 a few years ago _but_ now the
> > > > gcc-9.1 requirement is mandatory so now have to look into compiling
> > > > linux-3.4 with gcc-9.1 or above.
>
> There is no need to compile user space and kernel with the same compiler.
>
So can I still use kernel-3.4 compiled with gcc-5.5, and boot full
user-space with gcc-9.1?
I was expecting it to be possible but might not work due to
incompatibility? As I know that when I tried to compile buildroot-2019
(with latest version of openssl and others) it needs kernel headers
and then I likely can't use 3.4 kernel.
I will still give it a try. Thanks again
> Arnd
On Tue, Mar 30, 2021 at 03:23:10PM +0200, Fawad Lateef wrote:
> So can I still use kernel-3.4 compiled with gcc-5.5, and boot full
> user-space with gcc-9.1?
Yes, of course.
> I was expecting it to be possible but might not work due to
> incompatibility? As I know that when I tried to compile buildroot-2019
> (with latest version of openssl and others) it needs kernel headers
> and then I likely can't use 3.4 kernel.
buildroot might be different, as that is how you are building your whole
system, but there is no dependency on the kernel and userspace to use
the same version of the compiler. Otherwise everyone would have to
rebuild the world for every time they updated their kernel, this isn't
the BSDs :)
thanks,
greg k-h
On Tue, Mar 30, 2021 at 3:23 PM Fawad Lateef <[email protected]> wrote:
> On Mon, 29 Mar 2021 at 22:06, Arnd Bergmann <[email protected]> wrote:
> >
> > On Mon, Mar 29, 2021 at 9:23 PM Fawad Lateef <[email protected]> wrote:
> > >
> > > On Mon, 29 Mar 2021 at 06:57, Greg KH <[email protected]> wrote:
> > > >
> > > > On Sun, Mar 28, 2021 at 10:20:50PM +0200, Fawad Lateef wrote:
> > > > > Hi
> > > > >
> > > > > I am using an Olimex A20 SOM with NAND and due to some binary blob for
> > > > > NAND driver, I am stuck with the sunxi kernel 3.4.xxx version. (Repo
> > > > > here: https://github.com/linux-sunxi/linux-sunxi)
> > > >
> > > > Please work with the vendor that is forcing you to use this obsolete and
> > > > insecure kernel version. You are paying for that support, and they are
> > > > the only ones that can support you.
> > > >
> > >
> > > The problem is vendor Olimex now have eMMC based SOM which is
> > > supported by mainline kernel _but_ they still selling NAND SOM and
> > > only supporting 3.4 kernel (as this is the only latest version from
> > > sunxi with NAND support, after that sunxi is now moved away from NAND
> > > too).
> >
> > From a very quick look at the git history, I can tell that A20 NAND driver
> > support was added in linux-4.8. Have you actually tried a modern kernel?
> >
>
> I tried compiling and booting kernel v4.4 (from sunxi repo on github)
> but unable to make it boot. Stuck at "Starting kernel". By the way I
> am booting from RAM (using the sunxi usbboot/usb-otg option).
>
> You mentioned that it's supported from linux-4.8 (from your quick look
> at git history); can you tell me which driver/files? As I was able to
> see some sort of sunxi NAND driver even in v4.4 kernel
> (https://lxr.missinglinkelectronics.com/linux+v4.4/drivers/mtd/nand/sunxi_nand.c).
The nand flash controller node for a20 was added in commit
b2a83ad217b8 ("ARM: dts: sun7i: Add NFC node to Allwinner A20 SoC")
The driver was merged first but not hooked up in the dt.
For the specific board file, you need to still need to either enable the
device and add a partition map in the dts (as described in the howto),
or have a boot loader that fills out that information.
> When I tried to compare with the sunxi-3.4 kernel code, I found that
> the kernel has code for "nfc" but no reference to "nfd" (I don't know
> what they are referring to).
> The sunxi 3.4 kernel NAND driver at quick look seems quite different.
> (https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4/drivers/block/sunxi_nand)
>
> I will try the v4.8 or above kernel.
I think the custom nand driver in that tree was trying to avoid the
patents for nand flash by using an independently developed implementation,
but that of course leads to copyright issues with incompatible licenses.
The new driver is a regular mtd driver. I don't know whether the layout
of the data is compatible at all, so it's possible that you have to backup
all the data using the old kernel and write back the file system using a
new kernel.
Arnd
Hi Greg,
(Sending again as seems like I had rich-text available by mistake, so
likely my message is rejected)
On Tue, 30 Mar 2021 at 15:40, Greg KH <[email protected]> wrote:
>
> On Tue, Mar 30, 2021 at 03:23:10PM +0200, Fawad Lateef wrote:
> > So can I still use kernel-3.4 compiled with gcc-5.5, and boot full
> > user-space with gcc-9.1?
>
> Yes, of course.
>
> > I was expecting it to be possible but might not work due to
> > incompatibility? As I know that when I tried to compile buildroot-2019
> > (with latest version of openssl and others) it needs kernel headers
> > and then I likely can't use 3.4 kernel.
>
> buildroot might be different, as that is how you are building your whole
> system, but there is no dependency on the kernel and userspace to use
> the same version of the compiler. Otherwise everyone would have to
> rebuild the world for every time they updated their kernel, this isn't
> the BSDs :)
>
I tried booting the userspace compiled with gcc-9.1 and kernel
compiled with gcc-5.5. But seems like the kernel 3.4.111 is not
compatible with user-space compiled with gcc-9.1.
During boot getting error: "FATAL: kernel too old." (from init I
believe) and then kernel Panics. Log (part) below:
------
[ 26.242878] registered taskstats version 1
[ 26.247522] axp20_buck3: incomplete constraints, leaving on
[ 26.253314] axp20_buck2: incomplete constraints, leaving on
[ 26.259161] axp20_ldo4: incomplete constraints, leaving on
[ 26.264877] axp20_ldo3: incomplete constraints, leaving on
[ 26.270581] axp20_ldo2: incomplete constraints, leaving on
[ 26.276299] axp20_ldo1: incomplete constraints, leaving on
[ 26.282059] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01
00:00:00 UTC (1262304000)
[ 26.291136] Freeing init memory: 160K
FATAL: kernel too old
[ 26.308118] usb 3-1.1: New USB device found, idVendor=148f, idProduct=5572
[ 26.315022] usb 3-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 26.322322] usb 3-1.1: Product: 802.11 n WLAN
[ 26.326730] usb 3-1.1: Manufacturer: Ralink
[ 26.330908] usb 3-1.1: SerialNumber: 1.0
[ 26.335055] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00007f00
[ 26.335061]
[ 26.344221] [<c0011285>] (unwind_backtrace+0x1/0x90) from
[<c02bdc4f>] (panic+0x6f/0x15c)
[ 26.352400] [<c02bdc4f>] (panic+0x6f/0x15c) from [<c0031fc7>]
(do_exit+0x5ff/0x600)
[ 26.360057] [<c0031fc7>] (do_exit+0x5ff/0x600) from [<c0032009>]
(do_group_exit+0x25/0x78)
[ 26.368318] [<c0032009>] (do_group_exit+0x25/0x78) from
[<c0032069>] (__wake_up_parent+0x1/0x18)
[ 26.377101] [<c0032069>] (__wake_up_parent+0x1/0x18) from
[<c000ca81>] (ret_fast_syscall+0x1/0x44)
[ 26.386064] CPU1: stopping
[ 26.388781] [<c0011285>] (unwind_backtrace+0x1/0x90) from
[<c0010707>] (handle_IPI+0x157/0x170)
[ 26.397477] [<c0010707>] (handle_IPI+0x157/0x170) from [<c0008393>]
(gic_handle_irq+0x3f/0x40)
[ 26.406085] [<c0008393>] (gic_handle_irq+0x3f/0x40) from
[<c000c65b>] (__irq_svc+0x3b/0x5c)
[ 26.414427] Exception stack(0xef065f88 to 0xef065fd0)
[ 26.419476] 5f80: ffffffed 00000001 1037d000
00000000 ef064000 c04d3c08
[ 26.427648] 5fa0: ef064000 ef064000 c04a9a10 ef064018 00000000
00000000 3b9aca00 ef065fd0
[ 26.435817] 5fc0: c000d469 c000d46a 60000033 ffffffff
[ 26.440870] [<c000c65b>] (__irq_svc+0x3b/0x5c) from [<c000d46a>]
(default_idle+0x1a/0x1c)
[ 26.449048] [<c000d46a>] (default_idle+0x1a/0x1c) from [<c000d6c1>]
(cpu_idle+0x91/0x98)
[ 26.457135] [<c000d6c1>] (cpu_idle+0x91/0x98) from [<40480bd9>] (0x40480bd9)
[ 26.464181] Rebooting in 10 seconds..
[ 36.444472] Restarting Linux version 3.4.113
(flateef@flateef-XPS-13-9360) (gcc version 5.5.0 (Buildroot
2016.02-00152-g83a8d925e-dirty) ) #1 SMP Wed Mar 24 00:29:58 CET 2021
[ 36.444482]
-----------------------------------------------------
Can I do something to make them work together?
Thanks
Fawad Lateef
> thanks,
>
> greg k-h
On Sun, Apr 18, 2021 at 07:25:08PM +0200, Fawad Lateef wrote:
> I tried booting the userspace compiled with gcc-9.1 and kernel
> compiled with gcc-5.5. But seems like the kernel 3.4.111 is not
> compatible with user-space compiled with gcc-9.1.
> During boot getting error: "FATAL: kernel too old." (from init I
> believe) and then kernel Panics. Log (part) below:
That's not a compiler issue, it's a libc issue. When you built your
toolchain you have likely (or accidently) selected a minimum kernel
version that is more recent than this one. The init code in the linker
checks the kernel version and refuses to start in such a case. If your
init depends on this libc, you simply cannot boot.
I don't know how far recent libcs can go on kernel support, but
you may possibly need to rebuild an older one, and sometimes older
libc will not build with modern gcc. So you should use the most
recent libc that still claims to support that kernel, and use the
most recent compiler your libc can be built with (maybe yours is
OK but I don't know).
Hoping this helps,
Willy