Signed-off-by: Tom Rini <trini@konsulko.com>

- Fix CMD_ACPI dependency in Kconfig
- Correct overflow in __udelay() in TSC timer driver
- Add a devicetree node for eMMC for Coral
- Minor improvements on image loading
- Reduce size of Samus image

With the recent addition of ACPI generation, the image size has got beyond
its current limit.

Samus does not actually use this, nor x86 emulation for PCI ROMs, so
disable both features.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

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>

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>

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>

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>

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>

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>

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>