version: Remove global macro U_BOOT_VERSION_STRING from version.h

[J-u-boot.git] / doc / README.vxworks

diff --git a/doc/README.vxworks b/doc/README.vxworks
index 3239c5bb11f75a9b61310acedc4758ec3e6dd32b..12a0d744d8a7b1c17785d6a7ebbf88d426e636cc 100644 (file)
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -1,9 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0+
 #
 # Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
-# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
-#
-# SPDX-License-Identifier:     GPL-2.0+
-#
+# Copyright (C) 2015-2018, Bin Meng <bmeng.cn@gmail.com>
+# Copyright (C) 2019, Lihua Zhao <lihua.zhao@windriver.com>
 
 VxWorks Support
 ===============
@@ -17,12 +16,24 @@ For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
 on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
 on PowerPC and ARM, 'bootm' shall be used.
 
+With CONFIG_EFI_LOADER option, it's possible to chain load a VxWorks x86 kernel
+via the UEFI boot loader application for VxWorks loaded by 'bootefi' command.
+
 VxWorks 7 on PowerPC and ARM
 ---------------------------
-From VxWorks 7, VxWorks starts adopting device tree as its hardware decription
-mechansim (for PowerPC and ARM), thus requiring boot interface changes.
+From VxWorks 7, VxWorks starts adopting device tree as its hardware description
+mechanism (for PowerPC and ARM), thus requiring boot interface changes.
 This section will describe the new interface.
 
+Since VxWorks 7 SR0640 release, VxWorks starts using Linux compatible standard
+DTB for some boards. With that, the exact same bootm flow as used by Linux is
+used, which includes board-specific DTB fix up. To keep backward compatibility,
+only when the least significant bit of flags in bootargs is set, the standard
+DTB will be used. Otherwise it falls back to the legacy bootm flow.
+
+For legacy bootm flow, make sure the least significant bit of flags in bootargs
+is cleared. The calling convention is described below:
+
 For PowerPC, the calling convention of the new VxWorks entry point conforms to
 the ePAPR standard, which is shown below (see ePAPR for more details):
 
@@ -32,6 +43,9 @@ For ARM, the calling convention is shown below:
 
     void (*kernel_entry)(void *fdt_addr)
 
+When using the Linux compatible standard DTB, the calling convention of VxWorks
+entry point is exactly the same as the Linux kernel.
+
 When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
 is like below:
 
@@ -55,6 +69,9 @@ gatewayip, hostname, othbootargs.
 When using 'bootm', just define "bootargs" in the environment and U-Boot will
 handle bootline fix up for the kernel dtb automatically.
 
+When using 'bootefi' to chain load an x86 kernel, the UEFI boot loader
+application for VxWorks takes care of the kernel bootline preparation.
+
 Serial console
 --------------
 It's very common that VxWorks BSPs configure a different baud rate for the
@@ -65,9 +82,9 @@ look like VxWorks hangs somewhere as nothing outputs on the serial console.
 
 x86-specific information
 ------------------------
-Before loading an x86 kernel, one additional environment variable need to be
-provided. This is "vx_phys_mem_base", which represent the physical memory
-base address of VxWorks.
+Before direct loading an x86 kernel via 'bootvx', one additional environment
+variable need to be provided. This is "vx_phys_mem_base", which represent the
+physical memory base address of VxWorks.
 
 Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For
 VxWorks 7, this is normally a virtual address and you need find out its