On Wed, Oct 13, 2010 at 08:29:35PM -0500, Dale Rahn wrote: > On Thu, Oct 14, 2010 at 01:50:36AM +0200, Tobias Ulmer wrote: > > I'm currently loading the kernel at a fixed start address using u-boot. > > There's no relocation going on. > > Accessing anything in the data segment leads to crashes due to file- and > > address offsets desyncing. > > > > The patch below fixes this issue and, as a bonus, syncs the code with > > the comment. > > Possibly affected are armish, beagle, gumstix, palm and zaurus > > > > Index: arch/arm/conf/ldscript.tail > > =================================================================== > > RCS file: > > /srv/boron/data/vcs/cvs/openbsd/src/sys/arch/arm/conf/ldscript.tail,v > > retrieving revision 1.4 > > diff -u -p -r1.4 ldscript.tail > > --- arch/arm/conf/ldscript.tail 27 Jun 2009 14:44:39 -0000 1.4 > > +++ arch/arm/conf/ldscript.tail 13 Oct 2010 23:17:30 -0000 > > @@ -5,7 +5,7 @@ > > PROVIDE (etext = .); > > /* Adjust the address for the data segment to start on the next page > > boundary. */ > > - . = ALIGN(0x8000); > > + . = ALIGN(0x1000); > > .data : > > AT (LOADADDR(.text) + (ADDR(.data) - ADDR(.text))) > > { > > > > How are you loading the kernel with u-boot? > > When I was doing this in the past, I was doing the following > $ ${OBJCOPY} -O binary bsd bsd.img > $ mkuboot -a arm -o linux -e ${KERNEL_BASE_PHYS} -l ${KERNEL_BASE_PHYS} > bsd.img bsd.umg > > This method had no problem with the current 'alignment'
I create bsd.umg without the intermediate OBJCOPY step. I remember that not going well when I first tried it, not sure why. The load address is KERNEL_BASE_PHYS minus the ELF header. This works just fine, except for that small data segment detail. bsd.umg: bsd ${MKUBOOT} -a arm -o OpenBSD -e ${KERNEL_BASE_PHYS} -l `printf "0x%x" $$((${KERNEL_BASE_PHYS}-${KERNEL_BASE_EOFF}))` bsd bsd.umg > > I thought I recalled that the ldscript aligned the pages on 64k boundaries, > but that does not appear to be the case. Not certian why 32k would be > desireable. > Will look into this more. > > Dale Rahn dr...@dalerahn.com > Here's some objdump -h output, first one without the patch: Idx Name Size VMA LMA File off Algn 0 .start 000000a8 00801000 00801000 00001000 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 001f1c77 c08010a8 008010a8 000010a8 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .data 00008f70 c09f8000 009f8000 001f3000 2**2 CONTENTS, ALLOC, LOAD, DATA Idx Name Size VMA LMA File off Algn 0 .start 000000a8 00801000 00801000 00001000 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 001f20eb c08010a8 008010a8 000010a8 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .data 00008f70 c09f4000 009f4000 001f4000 2**2 CONTENTS, ALLOC, LOAD, DATA (sdram starts at 0x0, u-boot occupies 0-8M - I like to keep its illegal instruction handler etc for the time being)