Skip to contentSkip to conversation

2.5.42 broke ARM zImage/Image

DISCUSSION Russell King 3 participants 6 messages Oct 12, 2002 – Oct 15, 2002 Arm (32-bit)

lore
Share & tools
lore
#0 lore raw

Hi,

I'm trying to get 2.5.42 to build on ARM, and I've finally run out of ideas for things to try to get arch/arm/boot/Makefile and arch/arm/boot/compressed/Makefile to work correctly.

What I'm seeing is:

/home/rmk/bin/arm-linux-ld -p -X -T vmlinux.lds head.o misc.o piggy.o /home/rmk/arm-linux/lib/gcc-lib/arm-linux/2.95.3/libgcc.a -o vmlinux /home/rmk/bin/arm-linux-ld:vmlinux.lds:14: parse error
make[2]: *** [vmlinux] Error 1
make[1]: *** [compressed/vmlinux] Error 2
make: *** [zImage] Error 2

This appears to be because ZRELADDR is not passed from arch/arm/boot/Makefile to arch/arm/boot/compressed/Makefile. You may think this is fairly trivial to fix, just export it. However, it is already exported with a bunch of other symbols. Other symbols seem to make it through to compressed/Makefile though.

I've tried many things, like including $(TOPDIR) Rules.make at the top of arch/arm/boot/Makefile, but this doesn't seem to make any difference what so ever.

Help!

Unless this can be solved, I'm going to be pushing _compile only_ tested stuff to Linus in the forthcoming weeks until someone can provide some hints as to what and why this broke.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#1 lore raw
Quoted 6 lines · Russell King

Hi,

I'm trying to get 2.5.42 to build on ARM, and I've finally run out of ideas for things to try to get arch/arm/boot/Makefile and arch/arm/boot/compressed/Makefile to work correctly.

Quoted 7 lines

What I'm seeing is:

/home/rmk/bin/arm-linux-ld -p -X -T vmlinux.lds head.o misc.o piggy.o /home/rmk/arm-linux/lib/gcc-lib/arm-linux/2.95.3/libgcc.a -o vmlinux /home/rmk/bin/arm-linux-ld:vmlinux.lds:14: parse error
make[2]: *** [vmlinux] Error 1
make[1]: *** [compressed/vmlinux] Error 2
make: *** [zImage] Error 2

Well, I have no idea why this particular errors has appeared, but I took a look at the arm makefiles in 2.5.42.

This is my first sot at converting them to the new kbuild way of doing things.
I have fixed several potential problems.
I also took advantage of the infrastructure in Rules.make, especially in boot and boot/compressed.

I have installed arm-linux-gcc 2.95.3, but the compilations fails early, so this is untested.

Let me know if you want me to proceed, and in that case where to get a compile able arm-kernel.

Sam

===== arch/arm/Makefile 1.23 vs edited =====

arch/arm/Makefile +12 -15
@@ -179,8 +179,7 @@
 
 libs-y				+= arch/arm/lib/
 
-MAKEBOOT	 =$(MAKE) -C arch/$(ARCH)/boot
-MAKETOOLS	 =$(MAKE) -C arch/$(ARCH)/tools
+makeboot = $(call descend,arch/arm/boot,$(1))
 
 #	Update machine arch and proc symlinks if something which affects
 #	them changed.  We use .arch and .proc to indicate when they were
@@ -200,13 +199,13 @@
 
 prepare: maketools
 
-.PHONY: maketools
+.PHONY: maketools FORCE
 maketools: include/asm-arm/.arch include/asm-arm/.proc \
-	 include/asm-arm/constants.h include/linux/version.h FORCE
-	@$(MAKETOOLS)
+	   include/asm-arm/constants.h include/linux/version.h FORCE
+	+@$(call descend,arch/arm/tools, include/asm-arm/mach-types.h)
 
 bzImage zImage zinstall Image bootpImage install: vmlinux
-	@$(MAKEBOOT) $@
+	+@$(call makeboot,$@)
 
 MRPROPER_FILES	+= \
 	include/asm-arm/arch include/asm-arm/.arch \
@@ -215,18 +214,16 @@
 	include/asm-arm/mach-types.h
 
 # We use MRPROPER_FILES and CLEAN_FILES now
-archmrproper: FORCE
-	@/bin/true
-
+archmrproper:
 archclean: FORCE
-	@$(MAKEBOOT) clean
+	+@$(call makeboot,clean)
 
 # My testing targets (that short circuit a few dependencies)
-zImg:;	@$(MAKEBOOT) zImage
-Img:;	@$(MAKEBOOT) Image
-i:;	@$(MAKEBOOT) install
-zi:;	@$(MAKEBOOT) zinstall
-bp:;	@$(MAKEBOOT) bootpImage
+zImg:;	+@$(call makeboot, zImage)
+Img:;	+@$(call makeboot, Image)
+i:;	+@$(call makeboot, install)
+zi:;	+@$(call makeboot, zinstall)
+bp:;	+@$(call makeboot, bootpImage)
 
 #
 # Configuration targets.  Use these to select a

===== arch/arm/boot/Makefile 1.15 vs edited =====

arch/arm/boot/Makefile +31 -25

77 lines not on this page · raw message

===== arch/arm/boot/bootp/Makefile 1.5 vs edited =====

arch/arm/boot/bootp/Makefile +10 -8
@@ -2,23 +2,25 @@
 # linux/arch/arm/boot/bootp/Makefile
 #
 
-ZSYSTEM		=$(TOPDIR)/arch/arm/boot/zImage
-ZLDFLAGS	=-p -X -T bootp.lds \
+ZSYSTEM		= arch/arm/boot/zImage
+ZLDFLAGS	=-p -X -T $(obj)/bootp.lds \
 		 --defsym initrd_addr=$(INITRD_PHYS) \
 		 --defsym params=$(PARAMS_PHYS)
 
-all:		bootp
+EXTRA_TARGETS := bootp
+
+include $(TOPDIR)/Rules.make
 
 # Note that bootp.lds picks up kernel.o and initrd.o
-bootp:		init.o kernel.o initrd.o bootp.lds
-		$(LD) $(ZLDFLAGS) -o $@ init.o
+$(obj)/bootp:	$(addprefix $(obj)/,init.o kernel.o initrd.o bootp.lds)
+		$(LD) $(ZLDFLAGS) -o $@ $(obj)/init.o
 
-kernel.o:	$(ZSYSTEM)
+$(obj)/kernel.o: $(ZSYSTEM)
 		$(LD) -r -s -o $@ -b binary $(ZSYSTEM)
 
-initrd.o:	$(INITRD)
+$(obj)/initrd.o: $(INITRD)
 		$(LD) -r -s -o $@ -b binary $(INITRD)
 
 .PHONY:		$(INITRD) $(ZSYSTEM)
 
-clean:;		$(RM) bootp
+clean:;		$(RM) $(obj)/bootp

===== arch/arm/boot/compressed/Makefile 1.9 vs edited =====

arch/arm/boot/compressed/Makefile +25 -25

73 lines not on this page · raw message

===== arch/arm/kernel/Makefile 1.10 vs edited =====

arch/arm/kernel/Makefile +4 -3
@@ -43,6 +43,7 @@
 include $(TOPDIR)/Rules.make
 
 # Spell out some dependencies that `make dep' doesn't spot
-entry-armv.o: entry-header.S $(TOPDIR)/include/asm-arm/constants.h
-entry-armo.o: entry-header.S $(TOPDIR)/include/asm-arm/constants.h
-entry-common.o: entry-header.S calls.S $(TOPDIR)/include/asm-arm/constants.h
+$(obj)/entry-armv.o: 	$(obj)/entry-header.S include/asm-arm/constants.h
+$(obj)/entry-armo.o: 	$(obj)/entry-header.S include/asm-arm/constants.h
+$(obj)/entry-common.o: 	$(obj)/entry-header.S include/asm-arm/constants.h \
+			$(obj)/calls.S

===== arch/arm/lib/Makefile 1.11 vs edited =====

arch/arm/lib/Makefile +2 -2
@@ -43,6 +43,6 @@
 
 include $(TOPDIR)/Rules.make
 
-csumpartialcopy.o: csumpartialcopygeneric.S
-csumpartialcopyuser.o: csumpartialcopygeneric.S
+$(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
+$(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
 

===== arch/arm/mm/Makefile 1.12 vs edited =====

arch/arm/mm/Makefile +1 -1
@@ -42,4 +42,4 @@
 include $(TOPDIR)/Rules.make
 
 # Special dependencies
-$(p-y):	$(TOPDIR)/include/asm-arm/constants.h
+$(obj)/$(p-y):	include/asm-arm/constants.h

===== arch/arm/tools/Makefile 1.6 vs edited =====

arch/arm/tools/Makefile +3 -4
@@ -4,9 +4,8 @@
 # Copyright (C) 2001 Russell King
 #
 
-all:	$(TOPDIR)/include/asm-arm/mach-types.h
+include $(TOPDIR)/Rules.make
 
-$(TOPDIR)/include/asm-arm/mach-types.h: mach-types gen-mach-types
-	awk -f gen-mach-types mach-types > $@
+include/asm-arm/mach-types.h: $(obj)/mach-types $(obj)/gen-mach-types
+	awk -f $(obj)/gen-mach-types $(obj)/mach-types > $@
 
-.PHONY:	all
#2 lore raw

Sam & Kai, lkml and others who join us on this happy day.

As well intentioned as your efforts are, and as patient as you are, I don't believe we're going to solve this one with the way things now stand in kbuild.

Everything appears to work correctly with Sam's latest patch. However, there is one fundamental problem that looks like it's impossible to solve. Here's the relevant fragment of Sam's patch:

===== arch/arm/boot/compressed/Makefile 1.10 vs edited =====

arch/arm/boot/compressed/Makefile Mon Oct 14 22:15:08 2002 renamed from arch/arm/boot/compressed/Makefile Sun Oct 13 12:22:02 2002 +11 -7
@@ -65,35 +63,39 @@
 OBJS           += head-xscale.o
 endif
 
-SEDFLAGS       = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;s/BSS_START/$(ZBSSADDR)/
+SEDFLAGS       = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;\
+s/BSS_START/$(ZBSSADDR)/;s#OBJ#$(obj)#
 
-LIBGCC         := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
+EXTRA_TARGETS := vmlinux piggy.o font.o head.o $(OBJS)
+EXTRA_CFLAGS  := $(CFLAGS_BOOT) -fpic
+EXTRA_AFLAGS  := -traditional
 
-all:           vmlinux
+include $(TOPDIR)/Rules.make
 
-vmlinux:       $(HEAD) $(OBJS) piggy.o vmlinux.lds
-               $(LD) $(ZLDFLAGS) $(HEAD) $(OBJS) piggy.o $(LIBGCC) -o vmlinux
+LDFLAGS_vmlinux := -p -X -T $(obj)/vmlinux.lds \
+       $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
 
-$(HEAD):       $(HEAD:.o=.S)
-               $(CC) $(AFLAGS) -traditional -c $(HEAD:.o=.S)
+$(obj)/vmlinux: $(obj)/$(HEAD) $(obj)/piggy.o $(obj)/vmlinux.lds \
+               $(addprefix $(obj)/, $(OBJS))
+       $(call if_changed,ld)
 

So we end up with the following to link the decompressor vmlinux:

LDFLAGS_vmlinux := -p -X -T $(obj)/vmlinux.lds \
        $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
$(obj)/vmlinux: $(obj)/$(HEAD) $(obj)/piggy.o $(obj)/vmlinux.lds \
                $(addprefix $(obj)/, $(OBJS))
        $(call if_changed,ld)

When linking vmlinux for the decompressor, we use the following linker script:

OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
...

  .text : {
    input_data = .;
    arch/arm/boot/compressed/piggy.o
    input_data_end = .;
    . = ALIGN(4);

}
...
}

which directs the linker to place arch/arm/boot/compressed/piggy.o between two symbols, input_data and input_data_end. However, in practice, we actually get the following:

ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
/usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux

00082b5c t lbits
00082b60 t dbits
00082b9c t p.687
00082d80 T _binary_arch_arm_boot_compressed_piggy_gz_start 000c1713 A _binary_arch_arm_boot_compressed_piggy_gz_size 00144493 T _binary_arch_arm_boot_compressed_piggy_gz_end 00144494 T _start
00144494 T input_data
00144494 T input_data_end

Changing the path in the vmlinux.lds.in script makes the linker correctly complain that the object isn't found, so it is using it:

ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
/usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux

ld: cannot open piggy.o: No such file or directory

Removing the object from the linker command line, but leaving it in the script results in the same object file layout - in other words, the linker isn't doing what its being told:

ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
/usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a arch/arm/boot/compressed/head.o arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux

00082b5c t lbits
00082b60 t dbits
00082b9c t p.687
00082d80 T _binary_arch_arm_boot_compressed_piggy_gz_start 000c1713 A _binary_arch_arm_boot_compressed_piggy_gz_size 00144493 T _binary_arch_arm_boot_compressed_piggy_gz_end 00144494 T _start
00144494 T input_data
00144494 T input_data_end

So I decided to see how x86 does it, and tried it on ARM:

ld -r -b binary --oformat elf32-littlearm -T
arch/arm/boot/compressed/piggy.lds arch/arm/boot/compressed/piggy.gz
-o arch/arm/boot/compressed/piggy.o
ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
/usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a
arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o
arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o
arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux
ld: Error: arch/arm/boot/compressed/piggy.o uses hard floating point, whereas arch/arm/boot/compressed/vmlinux uses soft floating point File format not recognized: failed to merge target specific data of file arch/arm/boot/compressed/piggy.o

So, basically, I'm screwed at the moment, unless someone has anything else to suggest.

If there isn't anything else, I'm going to have to call for the re-implementation of the make -C method that Kai originally had in his patch.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#3 lore raw
Quoted 4 lines · Russell King

Sam & Kai, lkml and others who join us on this happy day.

So, basically, I'm screwed at the moment, unless someone has anything else to suggest.

How about a simple workaround for now:

$(obj)/vmlinux: $(obj)/$(HEAD) $(obj)/piggy.o $(obj)/vmlinux.lds \
                $(addprefix $(obj)/, $(OBJS))
	cp $(obj)/piggy.o .
        $(call if_changed,ld)
	rm piggy.o

I onther words just make a temporary copy of piggy.o in current directory. No changes needed in .lds file.

Untested!

I do not know the linker command language, but I assume there is some way to do this even with piggy.o located somewhere else than current directory.

My suggestion is a simple workaround to make the arm kernel compile, not something I would like to see as a permanent solution.

Sam

#4 lore raw
Quoted 8 lines · Sam Ravnborg
Quoted 4 lines · Russell King

Sam & Kai, lkml and others who join us on this happy day.

So, basically, I'm screwed at the moment, unless someone has anything else to suggest.

How about a simple workaround for now:
[...]

Actually, we figured out what the problem was now, the link script was given as an argument to ld twice, which obviously confused it. After fixing that, all is well.

Thanks anyway,
--Kai

#5 lore raw
Quoted 3 lines · Kai Germaschewski

Actually, we figured out what the problem was now, the link script was given as an argument to ld twice, which obviously confused it. After fixing that, all is well.

Good spot!

Russell - I'm planning to give the makefiles an additional clean-up when they show up in the linus kernel.
There is still a few bits here and there that could use some attention, and when Linus pull the next bunch of updates from Kai the handling of clean has been improved. I'm planning to introduce this in arm too - just to finish the job in a proper way.

OK?

If you want me to do it beforehand then just give me a pointer to a tree where I can pull from.

And I'm glad the two of you got it solved, now I just fear what problems shows up for the next architecture...

Sam