From: Bin Meng <bmeng.cn@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2 04/12] x86: Make sure the SPL image ends on a suitable boundary
Date: Mon, 1 Feb 2021 14:37:22 +0800 [thread overview]
Message-ID: <CAEUhbmXqETHYGw6VyjNEuFMnrZGjw-vcDYvUW3XV5a7D+WwJXg@mail.gmail.com> (raw)
In-Reply-To: <20210124100608.v2.4.I66e525bc185416fb67c5ff72d9fadde9d60f7ae4@changeid>
On Mon, Jan 25, 2021 at 1:06 AM Simon Glass <sjg@chromium.org> wrote:
>
> The part of U-Boot that actually ends up in u-boot-nodtb.bin is not built
> with any particular alignment. It ends at the start of the BSS section.
> The BSS section selects its own alignment, which may larger.
may be
> This means that there can be a gap of a few bytes between the image
> ending and BSS starting.
>
> Since u-boot.bin is build by joining u-boot-nodtb.bin and u-boot.dtb (with
> perhaps some padding for BSS), the expected result is not obtained. U-Boot
> uses the end of BSS to find the devicetree, so this means that it cannot
> be found.
>
> Add 32-byte alignment of BSS so that the image size is correct and
> appending the devicetree will place it at the end of BSS.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Example SPL output without this patch:
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 000142a1 fef40000 fef40000 00001000 2**4
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 1 .u_boot_list 000014a4 fef542a8 fef542a8 000152a8 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 2 .rodata 0000599c fef55760 fef55760 00016760 2**5
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 3 .data 00000970 fef5b100 fef5b100 0001c100 2**5
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 4 .binman_sym_table 00000020 fef5ba70 fef5ba70 0001ca70 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 5 .bss 00000060 fef5baa0 fef5baa0 00000000 2**5
> ALLOC
>
> You can see that .bss is aligned to 2**5 (32 bytes). This is because of
> the mallinfo struct in dlmalloc.c:
>
> 17 .bss.current_mallinfo 00000028 00000000 00000000 000004c0 2**5
> ALLOC
>
> In this case the size of u-boot-spl-nodtb.bin is 0x1ba90. This matches up
> with the _image_binary_end symbol:
>
> fef5ba90 g .binman_sym_table 00000000 _image_binary_end
>
> But BSS starts 16 bytes later, at 0xfef5baa0, due to the 32-byte
> alignment. So we must align _image_binary_end to a 32-byte boundary. This
> forces the binary size to be 0x1baa0, i.e. ending at the start of bss, as
> expected.
>
> Note that gcc reports __BIGGEST_ALIGNMENT__ of 16 on this build, even
> though it generates an object file with a member that requests 32-byte
> alignment.
>
> The current_mallinfo struct is 40 bytes in size. Increasing the struct to
> 68 bytes (i.e. just above a 64-byte boundary) does not cause the alignment
> to go above 32 bytes. So it seems that 32 bytes is the maximum alignment
> at present.
>
The above information is very useful for people to understand such
tricky changes.
I can put such in the commit message when applying.
> Changes in v2:
> - Add comment to .lds file
> - Add more notes to the commit
>
> arch/x86/cpu/u-boot-spl.lds | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
next prev parent reply other threads:[~2021-02-01 6:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-24 17:06 [PATCH v2 00/12] x86: Minor improvements mostly for image loading Simon Glass
2021-01-24 17:06 ` [PATCH v2 01/12] x86: acpi_gpe: Update driver name to match devicetree Simon Glass
2021-01-24 17:06 ` [PATCH v2 02/12] x86: spl: Add a function to find the text base Simon Glass
2021-01-24 17:06 ` [PATCH v2 03/12] x86: apl: Enhance debugging in the SPL loader Simon Glass
2021-01-24 17:06 ` [PATCH v2 04/12] x86: Make sure the SPL image ends on a suitable boundary Simon Glass
2021-02-01 6:37 ` Bin Meng [this message]
2021-01-24 17:06 ` [PATCH v2 05/12] x86: spl: Make moving BSS conditional Simon Glass
2021-01-24 17:06 ` [PATCH v2 06/12] x86: Update Chromium OS GNVS names Simon Glass
2021-01-24 17:06 ` [PATCH v2 07/12] x86: zimage: Allow dumping the image from outside the module Simon Glass
2021-01-24 17:06 ` [PATCH v2 08/12] x86: zimage: Improve command-line debug handling Simon Glass
2021-01-24 17:06 ` [PATCH v2 09/12] x86: spl: Clear BSS unconditionally Simon Glass
2021-01-24 17:06 ` [PATCH v2 10/12] x86: tpl: Show next stage being booted Simon Glass
2021-01-24 17:06 ` [PATCH v2 11/12] sysinfo: Allow showing model info from sysinfo Simon Glass
2021-01-24 17:06 ` [PATCH v2 12/12] x86: coral: Show memory config and SKU ID on startup Simon Glass
2021-02-01 6:40 ` [PATCH v2 00/12] x86: Minor improvements mostly for image loading Bin Meng
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=CAEUhbmXqETHYGw6VyjNEuFMnrZGjw-vcDYvUW3XV5a7D+WwJXg@mail.gmail.com \
--to=bmeng.cn@gmail.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.