Enhance do_bootm_vxworks() to support Linux compatible standard DTB
for ARM and PPC, when the least significant bit of flags in VxWorks
bootargs is set. Otherwise it falls back to the existing bootm flow
which is now legacy.

Signed-off-by: Lihua Zhao <lihua.zhao@windriver.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Change the scope of do_bootvx_fdt() to static since it is only
used in common/bootm_os.c.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

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

On VxWorks x86 its bootline address is at a pre-defined offset @
0x1200. If 'bootaddr' is not passed via environment variable, we
assign its value based on the kernel memory base address.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

When booting from EFI BIOS, VxWorks bootloader stores the EFI GOP
framebuffer info at a pre-defined offset @ 0x6100. When VxWorks
kernel boots up, its EFI console driver tries to find such a block
and if the signature matches, the framebuffer information will be
used to initialize the driver.

However it is not necessary to prepare an EFI environment for
VxWorks's EFI console driver to function (eg: EFI loader in
U-Boot). If U-Boot has already initialized the graphics card and
set it to a VESA mode that is compatible with EFI GOP, we can
simply prepare such a block for VxWorks.

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

This changes 'struct e820info' to 'struct e820_info' to conform
with the coding style.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

VxWorks bootloader stores its size at a pre-defined offset @ 0x5004.
Later when VxWorks kernel boots up and system memory information is
retrieved from the E820 table, the bootloader size will be subtracted
from the total system memory size to calculate the size of available
memory for the OS.

Explicitly clear the bootloader image size otherwise if memory
at this offset happens to contain some garbage data, the final
available memory size for the kernel is insane.

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

At present two environment variables 'e820data'/'e820info' are required
to boot a VxWorks x86 kernel, but this is superfluous. The offset of
these two tables are actually at a fixed offset from the kernel memory
base address and we can provide the kernel memory base address to U-Boot
via only one variable 'vx_phys_mem_base'.

Note as it name indicates, the physical address should be provided.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

E820 is critical to the kernel as it provides system memory map
information. Pass it to an x86 VxWorks kernel.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Jian Luo <jian.luo4@boschrexroth.de>

So far VxWorks bootline can be contructed from various environment
variables, but when these variables do not exist we get these from
corresponding config macros. This is not helpful as it requires
rebuilding U-Boot, and to make sure these config macros take effect
we should not have these environment variables. This is a little
bit complex and confusing.

Now we change the logic to always contruct the bootline from
environments (the only single source), by adding two new variables
"bootdev" and "othbootargs", and adding some comments about network
related settings mentioning they are optional. The doc about the
bootline handling is also updated.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>