Thread (7 messages) 7 messages, 3 authors, 2017-08-21

Re: [PATCH] MIPS: Set ISA bit in entry-y for microMIPS kernels

From: Paul Burton <hidden>
Date: 2017-08-18 17:19:30

Hi Maciej,

On Friday, 18 August 2017 09:46:30 PDT Maciej W. Rozycki wrote:
quoted hunk ↗ jump to hunk
On Fri, 18 Aug 2017, Maciej W. Rozycki wrote:
quoted
quoted
When building a kernel for the microMIPS ISA, ensure that the ISA bit
(ie. bit 0) in the entry address is set. Otherwise we may include an
entry address in images which bootloaders will jump to as MIPS32 code.
 
 Hmm, what's going on here?  The ISA bit is set by the linker according to

the mode the code at the entry symbol has been assembled for, e.g.:

$ readelf -h vmlinux | grep Entry

  Entry point address:               0x804355e1

$ readelf -s vmlinux | grep kernel_entry
156535: 80100400     0 FUNC    GLOBAL DEFAULT [MICROMIPS]     1
__kernel_entry 156742: 804355e0   146 FUNC    GLOBAL DEFAULT [MICROMIPS] 
   1 kernel_entry $

or no microMIPS (or MIPS16) executable could work.  Is your build process
or toolchain used broken by any chance?
 It is indeed the build process.  You've come up with a valid, however a
complicated solution.  How about the change below, on top of yours -- does
it work for you?  If so, then I'll wrap it up and submit as an update.

  Maciej

---
 arch/mips/Makefile |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

linux-mips-start-address.diff
Index: linux-sfr-usead/arch/mips/Makefile
===================================================================
--- linux-sfr-usead.orig/arch/mips/Makefile	2017-08-18 15:25:58.196676000
+0100 +++ linux-sfr-usead/arch/mips/Makefile	2017-08-18 15:27:55.309653000
+0100 @@ -242,21 +242,8 @@ include arch/mips/Kbuild.platforms
 ifdef CONFIG_PHYSICAL_START
 load-y					= $(CONFIG_PHYSICAL_START)
 endif
-
-entry-noisa-y				= 0x$(shell $(NM) vmlinux 2>/dev/null \
-					| grep "\bkernel_entry\b" | cut -f1 -d \ )
-ifdef CONFIG_CPU_MICROMIPS
-  #
-  # Set the ISA bit, since the kernel_entry symbol in the ELF will have it
-  # clear which would lead to images containing addresses which bootloaders
may -  # jump to as MIPS32 code.
-  #
-  entry-y = $(patsubst %0,%1,$(patsubst %2,%3,$(patsubst %4,%5, \
-              $(patsubst %6,%7,$(patsubst %8,%9,$(patsubst %a,%b, \
-              $(patsubst %c,%d,$(patsubst %e,%f,$(entry-noisa-y)))))))))
-else
-  entry-y = $(entry-noisa-y)
-endif
+entry-y				= $(shell $(OBJDUMP) -f vmlinux 2>/dev/null \
+					| sed -n 's/start address //p')

 cflags-y			+= -I$(srctree)/arch/mips/include/asm/mach-generic
 drivers-$(CONFIG_PCI)		+= arch/mips/pci/
I originally did this [1], and wrote about it in the post-three-dashes notes 
for this patch. To quote myself:
I originally tried using "objdump -f" to obtain the entry address, which
works for microMIPS but it always outputs a 32 bit address for a 32 bit
ELF whilst nm will sign extend to 64 bit. That matters for systems where
we might want to run a MIPS32 kernel on a MIPS64 CPU & load it with a
MIPS64 bootloader, which would then jump to a non-canonical
(non-sign-extended) address.

This works in all cases as it only changes the behaviour for microMIPS
kernels, but isn't the prettiest solution. A possible alternative would
be to write a custom tool to just extract, sign extend & print the entry
point of an ELF executable. I'm open to feedback if that would be
preferred.
So if we were to use objdump we'd need to handle sign extending 32 bit 
addresses to form a canonical address. Perhaps that'd be cleaner though.

Thanks,
    Paul

[1] https://patchwork.linux-mips.org/patch/14020/

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help