[Milkymist-devel] Kernel modules fix
Sébastien Bourdeauducq
sebastien.bourdeauducq at lekernel.net
Wed Mar 17 11:53:01 PDT 2010
Hi,
Ok, once again an issue stemming from the sloppy Binutils support. Thank you
very much for your patch. I will apply it, further increasing the state of
mess the Linux port is in, but solving the problem on the short term. If
someday LM32 has a good support from the GNU toolchain (haha) or if I can find
enough time for serious work on Clang, LLVM and a LM32 assembler/linker, we
will revert that and use the correct architecture number that has been
eventually attributed by the bearded hippies to LM32 (0x8a).
Regards,
Sébastien
On Wednesday 17 March 2010 08:31:21 you wrote:
> On Tue, Mar 16, 2010 at 10:40 PM, Richard Sharpe
>
> <realrichardsharpe at gmail.com> wrote:
> > On Tue, Mar 16, 2010 at 9:40 PM, Richard Sharpe
> >
> > <realrichardsharpe at gmail.com> wrote:
> >> Some stuff now deleted ...
> >
> > OK, so I figured out the problem. If I change the value of EM_LM32 to
> > match what the toolchain builds, I get a loop in kmod trying to load
> > binfmt-xxxx, but that is because, as shown below, my initrd.bin (root
> > file system) has been built with a tool chain that embeds 0x666 in the
> > Machine/Arch field. Thus, I need to rebuild my initrd with the
> > toolchain.
> >
> > [root at localhost linux-2.6]# lm32-elf-readelf -h
> > /mnt/root-loop/bin/busybox ELF Header:
> > Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
> > Class: ELF32
> > Data: 2's complement, big endian
> > Version: 1 (current)
> > OS/ABI: UNIX - System V
> > ABI Version: 0
> > Type: EXEC (Executable file)
> > Machine: <unknown>: 0x666
> > Version: 0x1
> > Entry point address: 0x1c
> > Start of program headers: 52 (bytes into file)
> > Start of section headers: 834236 (bytes into file)
> > Flags: 0x1
> > Size of this header: 52 (bytes)
> > Size of program headers: 32 (bytes)
> > Number of program headers: 3
> > Size of section headers: 40 (bytes)
> > Number of section headers: 18
> > Section header string table index: 15
> > [root at localhost linux-2.6]# lm32-elf-readelf -h ../m
> > micotoolchain44.tar.bz2 module-simple/
> > [root at localhost linux-2.6]# lm32-elf-readelf -h
> > ../module-simple/hello.ko ELF Header:
> > Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
> > Class: ELF32
> > Data: 2's complement, big endian
> > Version: 1 (current)
> > OS/ABI: UNIX - System V
> > ABI Version: 0
> > Type: REL (Relocatable file)
> > Machine: Lattice Mico32
> > Version: 0x1
> > Entry point address: 0x0
> > Start of program headers: 0 (bytes into file)
> > Start of section headers: 16340 (bytes into file)
> > Flags: 0x1
> > Size of this header: 52 (bytes)
> > Size of program headers: 0 (bytes)
> > Number of program headers: 0
> > Size of section headers: 40 (bytes)
> > Number of section headers: 25
> > Section header string table index: 22
>
> This patch will work. It works for the existing rootfs as well as
> modules built by the toolchain. Now, on to the next problem, which is
> that some modules will not even build.
>
> index dd6eb92..df604de 100644
> --- a/arch/lm32/include/asm/elf.h
> +++ b/arch/lm32/include/asm/elf.h
> @@ -63,7 +63,8 @@ typedef struct fp_regs elf_fpregset_t;
> /*
> * This is used to ensure we don't load something for the wrong
> architecture. */
> -#define elf_check_arch(x) ((x)->e_machine == EM_LM32)
> +#define elf_check_arch(x) ((x)->e_machine == EM_LM32 || \
> + (x)->e_machine == EM_LM32_OLD)
> #define elf_check_fdpic(x) (1)
> #define elf_check_const_displacement(x) (1)
>
> @@ -73,7 +74,8 @@ typedef struct fp_regs elf_fpregset_t;
> #define ELF_CLASS ELFCLASS32
> #define ELF_DATA ELFDATA2MSB
> #define ELF_ARCH EM_LM32
> -#define EM_LM32 0x666 // FIXME
> +#define EM_LM32 0x8A // FIXME
> +#define EM_LM32_OLD 0x666 // The old value
>
> #define ELF_PLAT_INIT(_r, load_addr) do { } while(0)
>
More information about the Devel
mailing list