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 [email protected]
>
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)
