[LinuxBIOS] Complete and generic 32bit/64bit support

Myles Watson myles at pel.cs.byu.edu
Wed Nov 21 18:43:09 CET 2007

> This patch does not set the UCLIBC_ARCH variable correctly on 32 bit; it
> needs to be forced to i386 there instead of $(TARGET_ARCH), which is i686 on
> my box.
> For 64 bit it's fine, because there the UCLIBC_ARCH variable needs to be
> x86_64 which happens to match $(TARGET_ARCH).
> Here's a simple fix for the m57sli board:
> --- config/platforms/m57sli.conf        (revision 57)
> +++ config/platforms/m57sli.conf        (working copy)
> @@ -6,8 +6,15 @@
>  STRIP=strip
>  AS=as
> +ifeq ($(CONFIG_TARGET_64BIT),y)
> +TARGET_ARCH=x86_64
> +UCLIBC_ARCH=x86_64
> +CFLAGS_platform =
> +else
> -CFLAGS_platform = -m32
> +CFLAGS_platform =
> +endif
> Can you fix that for all boards?

How about this fix?  Can you test the attached patch?  It fixes it in
uclibc.mk instead of in each individual board.

If the patch works for you, I'll send a full patch from the latest svn.
> The other thing I was wondering about is why the exit -1 is dropped in
> buildrom-devel/bin/checkrom.sh when the image won't fit? It's nice for the
> build to fail explicitly if the image is too big instead of producing obscure
> linker errors further down the line.

The problem is that the amount that is free in the ROM is dependent on
the size of the ROM, the size of LinuxBIOS, and any other payloads you
have in your configuration.  Thus checkrom depends on a magic number
to say if it will fail or not.

Choose a platform with a ROM_SIZE smaller than 1 MB and checkrom
doesn't protect you from linker errors.  Choose to use a 2 MB ROM and
checkrom fails even when it shouldn't.

Maybe the warning needs to be more verbose, but I really don't like
the magic number test and fail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc_arch.patch
Type: application/octet-stream
Size: 887 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071121/be4e2fda/attachment.obj>

More information about the coreboot mailing list