Customizing ubldr build...

From: Tim Kientzle <kientzle_at_freebsd.org>
Date: Sun, 20 May 2012 10:47:04 -0700
In order to fully automate building SD images for Beaglebone,
I'm trying to come up with a clean way to tailor the ubldr build.

I think I've come up with a good way to do this and would appreciate any feedback.

First, here's the (somewhat simplified) script that builds and installs ubldr (this
is going into the beaglebsd.sh script I've been working on):

 cd /usr/src
 buildenv=`make TARGET_ARCH=arm TARGET_CPUTYPE=arm buildenvvars`
 cd sys/boot
 eval $buildenv make obj
 eval $buildenv make UBLDR_LOADADDR=0x80100000 all
 cd arm/uboot
 eval $buildenv make DESTDIR=${DESTDIR}  BINDIR=  NO_MAN=true install

The key issue is the physical load address, which differs among boards.
My idea is to allow specifying this at build time through a make
variable UBLDR_LOADADDR.

The Makefile for sys/boot/arm/uboot passes this down into a
dynamically-built loader script.  Here's a summary of the changes
I'm proposing to sys/boot/arm/uboot/Makefile:

+UBLDR_LOADADDR?=	0x1000000
 
 LDFLAGS=	-nostdlib -static
+LDFLAGS+=	-T ldscript.generated
 LDFLAGS+=	-T ${.CURDIR}/ldscript.${MACHINE_CPUARCH}
 
+${PROG}: ldscript.generated
+
+ldscript.generated::
+	echo "UBLDR_LOADADDR = ${UBLDR_LOADADDR};" > ldscript.generated

And now the standard loader script can simply use the symbol instead of
a hard-coded value:

 Index: ldscript.arm
 ===================================================================
 --- ldscript.arm	(revision 235597)
 +++ ldscript.arm	(working copy)
 _at__at_ -5,7 +5,7 _at__at_
  SECTIONS
  {
    /* Read-only sections, merged into text segment: */
 -  . = 0x1000000 + SIZEOF_HEADERS;
 +  . = UBLDR_LOADADDR + SIZEOF_HEADERS;
    .interp     : { *(.interp) 	}
    .hash          : { *(.hash)		}
    .dynsym        : { *(.dynsym)		}

This seems to work pretty well for me, except for one odd point:
the make dependencies cause ubldr to get relinked on every build.
(This can be fixed in the usual way.)

If anyone sees a better way to handle this, I'd much appreciate the input.

Cheers,

Tim
Received on Sun May 20 2012 - 15:47:12 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC