mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Antony Pavlov <antonynpavlov@gmail.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: "U-Boot Version 2 (barebox)" <barebox@lists.infradead.org>
Subject: Re: shouldn't asm-generic/barebox.lds.h be arch-independent?
Date: Sun, 18 Nov 2012 22:21:20 +0400	[thread overview]
Message-ID: <CAA4bVAEpXjiv-DAG=aF9OfmJBOqHZKadr6xpXOznEB6MPdQMkA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1211181240360.32651@oneiric>

On 18 November 2012 21:52, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   perusing the code to see how the final barebox executable is created
> and ran across this opening to include/asm-generic/barebox.lds.h:
>
> #if defined CONFIG_ARCH_IMX25 || \
>         defined CONFIG_ARCH_IMX35 || \
>         defined CONFIG_ARCH_IMX51 || \
>         defined CONFIG_ARCH_IMX53 || \
>         defined CONFIG_ARCH_IMX6 || \
>         defined CONFIG_X86 || \
>         defined CONFIG_ARCH_EP93XX
> #include <mach/barebox.lds.h>
> #endif
>
> #ifndef PRE_IMAGE
> #define PRE_IMAGE
> #endif
>
>   i find that more than a little confusing and inappropriate -- it
> strikes me that the allegedly "generic" lds.h file shouldn't be
> testing for an arbitrary set of inexplicable machine/arch
> combinations, especially when there is absolutely no explanation about
> what makes that particular set of symbols magic with respect to this
> file.
>
>   a minute or two of perusing shows that what it's for is inserting
> some special "pre-image" content into the executable, but that means
> that for each new selection that needs that, this file will have to be
> changed and that's just messy.
>
>   the linux kernel has a simpler strategy for
> asm-generic/vmlinux.lds.h, as you see in this patch snippet that added
> bss first section functionality to that file earlier this year:
>
> +/*
> + * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
> + * sections to the front of bss.
> + */
> +#ifndef BSS_FIRST_SECTIONS
> +#define BSS_FIRST_SECTIONS
> +#endif
> +
>  #define BSS(bss_align)                                                 \
>         . = ALIGN(bss_align);                                           \
>         .bss : AT(ADDR(.bss) - LOAD_OFFSET) {                           \
> +               BSS_FIRST_SECTIONS                                      \
>                 *(.bss..page_aligned)                                   \
>                 *(.dynbss)                                              \
>                 *(.bss)                                                 \
>
>   that would seem to be a much nicer solution as it pushes the
> selection of pre-image content back to the architectures where it
> belongs.
>
>   the fact that the current approach is prone to "error" can be seen
> in the file arch/mips/lib/barebox.lds.S:
>
> #include <asm-generic/barebox.lds.h>
>
> OUTPUT_ARCH(mips)
> ENTRY(_start)
> SECTIONS
> {
>         . = TEXT_BASE;
>
>         . = ALIGN(4);
>         .text      :
>         {
>                 _start = .;
>                 *(.text_entry*)
>                 _stext = .;
>                 _text = .;
>                 __bare_init_start = .;
>                 *(.text_bare_init*)
>                 __bare_init_end = .;
>                 *(.text*)
>         }
>         BAREBOX_BARE_INIT_SIZE
>
>         PRE_IMAGE  <--- ?????
>
> apparently, the MIPS architecture is including the "PRE_IMAGE"
> content, despite the fact that it can't possibly be defined.  it's not
> wrong, it's just pointless and potentially confusing.

Unfortunately nowadays MIPS lacks lowlevel initialization support.
Yesterday I mailed RFC about pbl (prebootloader) support. It needs
much work, but IMHO after incorporating MIPS pbl support the status of
"PRE_IMAGE" will be more clear.

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2012-11-18 18:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-18 17:52 Robert P. J. Day
2012-11-18 18:21 ` Antony Pavlov [this message]
2012-11-18 18:24   ` Robert P. J. Day
2012-11-18 18:31 ` Robert P. J. Day
2012-11-19  8:32   ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA4bVAEpXjiv-DAG=aF9OfmJBOqHZKadr6xpXOznEB6MPdQMkA@mail.gmail.com' \
    --to=antonynpavlov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=rpjday@crashcourse.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox