From: Anand Gore <anand.gore@broadcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC BUG] CONFIG_OF_SEPARATE - ARM64 Incorrect calculation for uboot-spl.bin padding
Date: Wed, 28 Aug 2019 09:36:28 -0700 [thread overview]
Message-ID: <ad0178744d607fe849eacdd45a24b8e6@mail.gmail.com> (raw)
Hello,
While trying to use the CONFIG_OF_SEPARATE option for ARM64, I noticed that
the )/$(SPL_BIN)-pad.bin creates a 0 byte size in scripts/Makefile.spl in
the following rule.
scripts/Makefile.spl:
# Create a file that pads from the end of u-boot-spl-nodtb.bin to bss_end
$(obj)/$(SPL_BIN)-pad.bin: $(obj)/$(SPL_BIN)
@bss_size_str=$(shell $(NM) $< | awk 'BEGIN {size = 0} /__bss_size/
{size = $$1} END {print "ibase=16; " toupper(size)}' | bc); \
dd if=/dev/zero of=$@ bs=1 count=$${bss_size_str} 2>/dev/null;
The issue is that the armv8 uboot-spl.lds script doesn’t have bss_size
defined. Even if we add the bss_size, the lds script
(arch/arm/cpu/armv8/u-boot-spl.lds ) has 2 memory regions, sram for TEXT
and sdram for BSS. There could be a potential gap between the 2 sections.
Due to this, function board_fdt_blob_setup will calculate the wrong address
to look for the loaded dtb.
If we keep the padding issue but use following code (both for SPL/TPL and
u-boot), the *PLs find the dtb at the right location.
__weak void *board_fdt_blob_setup(void)
{
void *fdt_blob = NULL;
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
/* FDT is at end of BSS unless it is in a different memory region */
if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
fdt_blob = (ulong *)&_image_binary_end;
else
fdt_blob = (ulong *)&__bss_end;
#else
/* FDT is at end of image */
fdt_blob = (ulong *)&_end;
#endif
return fdt_blob;
}
Can someone suggest what the preferred solution is for ARM64?
Thanks
Anand
reply other threads:[~2019-08-28 16:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=ad0178744d607fe849eacdd45a24b8e6@mail.gmail.com \
--to=anand.gore@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox