Commit graph

1853 commits

Author SHA1 Message Date
Marek Behún
236f2ec432 treewide: Convert macro and uses of __section(foo) to __section("foo")
This commit does the same thing as Linux commit 33def8498fdd.

Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.

Remove the quote operator # from compiler_attributes.h __section macro.

Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-05-24 14:21:30 -04:00
Patrick Delaunay
77b8cfef53 lmb: move CONFIG_LMB in Kconfig
Migrate CONFIG_LMB in Kconfig.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-22 14:09:45 -04:00
Joel Peshkin
4e9bce1243 Add support for stack-protector
Add support for stack protector for UBOOT, SPL, and TPL
as well as new pytest for stackprotector

Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com>

Adjust UEFI build flags.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-04-20 07:31:12 -04:00
Heinrich Schuchardt
1598c83ece x86: correct usage of CFLAGS_NON_EFI
The current usage of the variable CFLAGS_NON_EFI on the x86 architecture
deviates from other architectures.

Variable CFLAGS_NON_EFI is the list of compiler flags to be removed when
building UEFI applications. It is not a list of flags to be added anywhere.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-04-20 07:31:12 -04:00
Wolfgang Wallner
21296b093e x86: mtrr: Fix function descriptions
Fix copy/paste errors in the descriptions of mtrr_close () and mtrr_set().

Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-04-15 10:43:17 +08:00
Asherah Connor
5b0b43e0e2 x86: qemu: move QFW to its own uclass
We move qfw into its own uclass and split the PIO functions into a
specific driver for that uclass.  The PIO driver is selected in the
qemu-x86 board config (this covers x86 and x86_64).

include/qfw.h is cleaned up and documentation added.

Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2021-04-12 17:44:55 -04:00
Simon Glass
80a4570c99 x86: coral: Show memory config and SKU ID on startup
Provide the model information through sysinfo so that it shows up on
boot. For memconfig 4 pins are provided, for 16 combinations. For SKU
ID there are two options:

   - two pins provided in a ternary arrangement, for 9 combinations.
   - reading from the EC

Add a binding doc and drop the unused #defines as well.

Example:

   U-Boot 2021.01-rc5

   CPU:   Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
   DRAM:  3.9 GiB
   MMC:   sdmmc@1b,0: 1, emmc@1c,0: 2
   Video: 1024x768x32 @ b0000000
   Model: Google Coral (memconfig 5, SKU 3)

This depends on the GPIO series:

   http://patchwork.ozlabs.org/project/uboot/list/?series=228126

Signed-off-by: Simon Glass <sjg@chromium.org>

Acked-by: Bin Meng <bmeng.cn@gmail.com>
2021-03-27 16:26:48 +13:00
Simon Glass
529d5f96cf cpu: Rename SPL_CPU_SUPPORT to SPL_CPU
The _SUPPORT suffix is from an earlier time and interferes with use of
the CONFIG_IS_ENABLED() macro. Rename the option to drop the suffix.

Tidy up the TODO that prompted this.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:31 +13:00
Simon Glass
70f5c99d60 x86: coreboot: Don't setup MTRR when booting from coreboot
This currently hangs and it is not necessary in any case. Drop the code
when booting from coreboot.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:31 +13:00
Simon Glass
9087e468c7 x86: fsp: Don't notify if booted from coreboot
When booting from coreboot there is no need to notify the FSP of anything,
since coreboot has already done it. Nor it is possible, since the FSP
details are not provided by coreboot.

Skip it in this case.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:30 +13:00
Simon Glass
8657989f29 x86: coral: Fall back to coreboot video when FSP missing
When booting from coreboot the FSP video information is no-longer
available. Enable the coreboot driver so that we can get some sort of
display in this case.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:30 +13:00
Simon Glass
51de94dfe4 x86: coral: Allow init of debug UART in U-Boot proper
At present the debug UART is only set up in SPL, on the assumption that
the boot flow will always pass through there. When booting from coreboot,
SPL is not used, so the debug UART is not available.

Move the code into a common place so that it can be used in U-Boot proper
also. Add the required init to start_from_spl.S as well.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:30 +13:00
Simon Glass
2018a33cb7 x86: coral: Avoid build error with !CONFIG_ACPIGEN
When CONFIG_ACPIGEN is not enabled the CPU code does not build. Fix this
by moving things around.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:30 +13:00
Simon Glass
937175ee72 x86: fsp: Don't enable FSP graphics if booted from coreboot
This driver cannot work when booted from coreboot, since the FSP
information is not available. Disable it in that case, so that the
coreboot video driver can be used instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:30 +13:00
Simon Glass
e7bae8283f x86: Allow installing an e820 when booting from coreboot
Move this code into a generic location so that it can be used by other x86
boards which want to boot from coreboot. Also ensure that this is called
if booting from coreboot.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 15:04:29 +13:00
Simon Glass
1058ab37f7 x86: coreboot: Update parsing of the latest sysinfo
Quite a few new tag types have been added over the years. Bring these into
U-Boot so that all required tags can be parsed.

Add a proper comment to struct sysinfo_t while we are here, since many of
the meanings are not obvious.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:59 +13:00
Simon Glass
68e03ca21a x86: Move coreboot sysinfo parsing into generic x86 code
It is useful to be able to parse coreboot tables on any x86 build which is
booted from coreboot. Add a new Kconfig option to enable this feature and
move the code so it can be used on any board, if enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:59 +13:00
Simon Glass
f9f06e628e x86: coreboot: Sync up timestamp codes
Add new timestamp codes that are present in coreboot, so that we can decode
these in U-Boot.

At present TS_U_BOOT_START_KERNEL is used twice. It should only be used
just before jumping to Linux, so update the other call site to use
TS_START_KERNEL.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:37 +13:00
Simon Glass
17753b0382 x86: Move coreboot timestamp info into coreboot_tables.h
This all relates to the sysinfo structure provided by coreboot. Put the
timestamp definitions into the same file as the others. Tidy up a few
comments at the same time.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:37 +13:00
Simon Glass
e35b6497f4 x86: Make coreboot sysinfo available to any x86 board
It is possible to boot U-Boot for chromebook_coral either 'bare metal' or
from coreboot. In the latter case we want to provide access to the coreboot
sysinfo tables. Move the definitions into a file available to any x86
board.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:37 +13:00
Simon Glass
5536f1285f cbfs: Allow access to CBFS without a header
In some cases CBFS does not start with a header but is just a collection
of files. It is possible to support this so long as the size of the CBFS
is provided.

Update the cbfs_init_mem() function to support this.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27 13:59:37 +13:00
Simon Glass
ac7765017a x86: coral: Update the SD card-detect GPIO
Since the recent bug fix, it doesn't matter which GPIO phandle is used so
long as the GPIO number is right. Still, we may as well use the correct
one to avoid confusion.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-03-27 13:59:36 +13:00
Simon Glass
041089fe93 x86: coral: Put the eMMC first
At present the eMMC device does not have an alias so it appears after
the SD card which is device 1. There is no device 0 which is odd.

Make the eMMC device be the first one. Update the boot script to use the
new device.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-03-27 13:59:36 +13:00
Simon Glass
cad7b6b251 x86: dts: Drop unused CONFIG_SPL
This cannot be used since the previous #elif has already dealt with SPL.
Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:10 +13:00
Simon Glass
cb88ec7cab x86: Make use of binman expanded entries
We don't need to spell out the separate pieces of U-Boot phase binaries
anymore. Revert to using the simple entry and let binman do the expansion
itself as needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
98ed0ae2cc x86: apl: Use read-only SPL and new of-platdata
With Apollo Lake, SPL is placed in read-only memory. Set this new option
so that OF_PLATDATA_INST can be used.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
541b2adf08 x86: coral: Drop TPM and ACPI interrupts from TPL
These devices are not actually built in TPL but are currently active in
the TPL devicetree. For of-platdata-inst this means that we will try to
generate devices for them, which fails.

Update them to be active only in U-Boot proper.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
5384ea96ce x86: Don't include reset driver in SPL
We don't normally need this driver in TPL/SPL, so drop it for now. It can
be enabled by individual boards if needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
1d3daaa681 x86: Support a fake PCI device with of-platdata-inst
With TPL we don't need full PCI support and it adds to code size. Instead,
a simple_bus driver is good enough to be able to read and write the PCI
config and do a little basic setup.

So at present there are two drivers in U-Boot called pci_x86. One is in
UCLASS_PCI, used in SPL and U-Boot proper. The other is in
UCLASS_SIMPLE_BUS and used only in TPL.

Add a tag to tell dtoc about this, so it knows which one to use when
generating the devices and uclasses.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
763ce51bc3 x86: itss: Tidy up bind() for of-platdata-inst
With the standard of-platdata we must fix up driver_data manually. With
of-platadata-inst this is not necessary, since it is added to the device
by dtoc.

Update the code to handle this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
a65c35ed77 x86: apl: Tell of-platdata about a required header file
This enum is needed to generate build-time devices. Tell dtoc where to
find the header, to avoid compile errors in the generated code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
8d0defa44b x86: apl: Fix the header order in pmc
The dm.h header should come first. In fact it needs to, since otherwise
the driver model definitions are not available to dt-structs.h

Fix this, since it causes problems with OF_PLATDATA_INST.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Simon Glass
72db28ee68 x86: Define a region for device priv/plat data
Collect this together in one place, so driver model can access set it up
in a new place if needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-26 17:03:09 +13:00
Tom Rini
22fc991daf Prepare v2021.04-rc4
-----BEGIN PGP SIGNATURE-----
 
 iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmBPhiUACgkQFHw5/5Y0
 tywChgv/RYpdSKrD5s4kCJnImfOwDznESj/CqAQK3Au5zviq7qXRrgxyTKv2e1wM
 W51vUBd0cE1YTACXqbr92wSSyqoTthLqd57KQgVele5uC2dvkqVTSvjPOUwtyIbQ
 BTPkoQnHPn30AILRdPjpEdBGfZhJDDtJFdQopn6h4GjEjPKVH8Wx1Dd+V6SD5f20
 WiksUjgdjMr1AmORY+LdwwJO8FZrGGPYgs8CDtiqxmCSwh3d7kUFFTT+G23BZdo7
 M+81+1uIUaW2Bolds7ZTPrrjr8bPwkWoTqNYhUB4bNPLp72gwnjM1rtU1X3hyiJM
 MdxSBimLHUOYPihfeSYCHSUrJaQFAAEFkuzWfZN1fgoswKEZQIVVVTzT/TomTyqf
 1DIXD+0HpXGKgVLW/Nkpl4D+UFjR865XI4kiuDxddjKI7bGbvDlbZ/k3PNelD7op
 umUswHnC3OTSw/g+A9VH/zf1rMFNLfu++vD7XJtdoWlcsl6x6/6Fh75tuC6K/X0K
 caPmehD3
 =ENym
 -----END PGP SIGNATURE-----

Merge tag 'v2021.04-rc4' into next

Prepare v2021.04-rc4
2021-03-15 12:15:38 -04:00
Simon Glass
736ecc643d x86: Select advanced Intel code only if allowed
At present most of the Intel-specific code is built on all devices, even
those which don't have software support for the features provided there.

This means that any board can enable CONFIG_INTEL_ACPIGEN even if it does
not have the required features.

Add a new INTEL_SOC option to control this access. This must be selected
by SoCs that can support the required features.

Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed a typo in arch/x86/Kconfig]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-03-09 09:42:12 +08:00
Simon Glass
049c4dc677 x86: Move INTEL_ACPIGEN to arch/x86
This option is better placed in the x86 code since it is not generic
enough to be in the core code. Move it.

Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed a typo in arch/x86/Kconfig]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-03-09 09:42:12 +08:00
Simon Glass
0b823e16b6 x86: Fix member check in intel_gnvs
When CONFIG_CHROMEOS is not enabled this currently does not build. Fix it.

Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-03-09 09:42:12 +08:00
Heinrich Schuchardt
97401d0dbc x86: sizeof-array-div error in lpc_common_early_init
Building qemu-x86_64_defconfig with GCC 11.0 fails with:

arch/x86/cpu/intel_common/lpc.c:
In function ‘lpc_common_early_init’:
arch/x86/cpu/intel_common/lpc.c:56:40:
error: expression does not compute the number of elements in this array;
element type is ‘struct reg_info’, not ‘u32’ {aka ‘unsigned int’}
[-Werror=sizeof-array-div]
   56 |                         sizeof(values) / sizeof(u32));
      |                                        ^
arch/x86/cpu/intel_common/lpc.c:56:40: note: add parentheses around the
second ‘sizeof’ to silence this warning
arch/x86/cpu/intel_common/lpc.c:50:11: note: array ‘values’ declared here
   50 |         } values[4], *ptr;
      |           ^~~~~~

Add parentheses to silence warning.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-03-09 09:42:12 +08:00
Simon Glass
edab114775 gpio: x86: Drop the deprecated methods in intel_gpio
We don't need to implement direction_input() and direction_output()
anymore. Drop them and use update_flags() instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-03 15:40:11 -05:00
Harald Seiler
35b65dd8ef reset: Remove addr parameter from reset_cpu()
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to.  This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value.  Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.

Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g.  COLD vs WARM resets).  As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).

To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely.  Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.

This transformation was done with the following coccinelle patch:

    @@
    expression argvalue;
    @@
    - reset_cpu(argvalue)
    + reset_cpu()

    @@
    identifier argname;
    type argtype;
    @@
    - reset_cpu(argtype argname)
    + reset_cpu(void)
    { ... }

Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-03-02 14:03:02 -05:00
Tom Rini
2ae80437fb Merge branch '2021-02-02-drop-asm_global_data-when-unused'
- Merge the patch to take <asm/global_data.h> out of <common.h>
2021-02-15 10:16:45 -05:00
Bin Meng
8cd1a0cf52 x86: qemu: Fix broken multi-core boot
Unfortunately the multi-core boot for QEMU x86 has been broken since
commit 77a5e2d3bc ("x86: mp_init: Set up the CPU numbers at the start").

In order to support QEMU x86 multi-core boot, the /cpus node must be
bound before any actual fix up in qemu_cpu_fixup(). This adds the
uclass_get() call to ensure this, just like what was done before.

Fixes: 77a5e2d3bc ("x86: mp_init: Set up the CPU numbers at the start")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-02-03 22:54:56 +08:00
Simon Glass
401d1c4f5d common: Drop asm/global_data.h from common header
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-02-02 15:33:42 -05:00
Simon Glass
3138e4603c x86: tpl: Show next stage being booted
Enhance the debugging to show the next stage being booted as well as a
dump of the start of the image.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:25 +08:00
Simon Glass
02840ca1b0 x86: spl: Clear BSS unconditionally
This should be done even if not using TPL, since BSS may be in use or
boards that only use SPL. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:25 +08:00
Simon Glass
06c085c0d2 x86: zimage: Improve command-line debug handling
At present if the command line is very long it is truncated by the
printf() statement, which works within a limited buffer. Use puts()
instead. Also show better debugging with the command-line setup
fails.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:25 +08:00
Simon Glass
577c4ad055 x86: zimage: Allow dumping the image from outside the module
At present it is possible to dump an image within the zimage command, but
it is also useful to be able to dump it from elsewhere, for example in a
loader that has special handling for the different zimage stages.

Export this feature as a new function.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:25 +08:00
Simon Glass
f82438948f x86: Update Chromium OS GNVS names
The Global Non-Volatile Storage struct has some fields with particular
meanings. Rename these to make things easier to follow. Also add a few
more boot flags.

GNVS should not be confused with GNVQ (Going Nowhere Very Quickly).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:24 +08:00
Simon Glass
76baecf670 x86: spl: Make moving BSS conditional
At present BSS is always placed in SDRAM. If a separate BSS is not in use
this means that BSS doesn't work as expected. Make the setting conditional
on the SEPARATE_BSS option.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:33:24 +08:00
Simon Glass
37c664e825 x86: Make sure the SPL image ends on a suitable boundary
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.
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.

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.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: add more details in the commit message to help people understand]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-01 15:29:02 +08:00