OLD Setup (based upon Buildroot 2015.08.1)
- GCC 4.9.3 (ARM cross compiler for ARM11 based target, Buildroot built)
- GLIBC 2.20
- BINUTILS: 2.24 (target) 2.22 (host)
- Linux kernel: 3rd party provided 3.14.17 (with their patches + additional proprietary patches)
- Host for Build: RHEL6 based system
New Setup (based upon Buildroot 2020.02)
- GCC 9.2.0 (ARM cross compiler for ARMv7 (cortexA9) based target, Buildroot built)
- GLIBC 2.30
- BINUTILS: 2.30 (target) 2.30 (host)
- Linux kernel: 3rd party provided 3.14.17 (with their patches + additional proprietary patches)
- Host for Build: Ubuntu 18.04.4
The reason for the update is to update to newer compiler/glibc that correct certain ARM CVE issues that have been deemed important enough to be addressed.
On the Old Setup, everything builds just fine, kernel boots, etc. This setup supports 3 shipping products.
On the New Setup (for new product), when building the same kernel, I get the:output/host/bin/arm-buildroot-linux-gnueabi-ld: no machine record defined
now nothing has changed in how this is defined by the 3rd party vendor. The only thing that has changed is the compiler, glibc, binutils.
in the arch/arm/kernel/vmlinux.lds.S (from vmlinux.lds )
/* * These must never be empty * If you have to comment these two assert statements out, your * binutils is too old (for other reasons as well) */ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined"commenting out the ASSERT allows the the kernel build and we get our output package (netbootable kernel)
However, this kernel will not boot: dies right away:
## Booting kernel from Legacy Image at 83000000 ... Image Name: Linux-3.14.17-ami Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 25338920 Bytes = 24.2 MiB Load Address: 81008000 Entry Point: 81008000 Loading Kernel Image ... OKSCU_RST_CTRL_STAT = 0x2Coming up from Internal ResetStarting kernel ...given that the error relates to the arch_info_begin/arch_info_end structure, makes me think that the linux kernel doesn't see this information and that's why it's not booting. So the next question is: what does / how does binutils (per the comment above) affect this???
And how can this be fixed/patched to move forward from here?
Your expertise and assistance is greatly appreciated.
Regards,Stephen Beckwith