x86: Add a dtsi file for the pc speaker
[oweals/u-boot.git] / doc / README.vxworks
index 3433e4f3aea47778da562f824f83ce84a40d4180..3e087112076e7d6a1c2ed4ad1656b64a19a5e608 100644 (file)
@@ -1,9 +1,7 @@
+# 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>
 
 VxWorks Support
 ===============
@@ -17,12 +15,13 @@ 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.
 
-64-bit x86 kernel cannot be loaded as of today.
+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.
 
-VxWork 7 on PowerPC and ARM
+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.
 
 For PowerPC, the calling convention of the new VxWorks entry point conforms to
@@ -30,11 +29,11 @@ the ePAPR standard, which is shown below (see ePAPR for more details):
 
     void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
 
-For ARM, the calling convention is show below:
+For ARM, the calling convention is shown below:
 
     void (*kernel_entry)(void *fdt_addr)
 
-When booting new VxWorks kernel (uImage format), the parameters passed to bootm
+When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
 is like below:
 
     bootm <kernel image address> - <device tree address>
@@ -46,7 +45,7 @@ board-specific address before loading VxWorks. U-Boot supplies its address
 via "bootaddr" environment variable. To check where the bootline should be
 for a specific board, go to the VxWorks BSP for that board, and look for a
 parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
-value for "bootaddr" is 0x101200.
+value for "bootaddr" on an x86 board is 0x101200.
 
 If a "bootargs" variable is defined, its content will be copied to the memory
 location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
@@ -57,6 +56,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
@@ -67,19 +69,34 @@ look like VxWorks hangs somewhere as nothing outputs on the serial console.
 
 x86-specific information
 ------------------------
-Before loading an x86 kernel, two additional environment variables need to be
-provided. They are "e820data" and "e820info", which represent the address of
-E820 table and E820 information (defined by VxWorks) in system memory.
-
-Check VxWorks kernel configuration to look for BIOS_E820_DATA_START and
-BIOS_E820_INFO_START, and assign their values to "e820data" and "e820info"
-accordingly. If neither of these two are supplied, U-Boot assumes a default
-location at 0x4000 for "e820data" and 0x4a00 for "e820info". Typical values
-for "e820data" and "e820info" are 0x104000 and 0x104a00. But there is one
-exception on Intel Galileo, where "e820data" and "e820info" should be left
-unset, which assume the default location for VxWorks.
-
-Note since currently U-Boot does not support ACPI yet, VxWorks kernel must
+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
+corresponding physical address and assign its value to "vx_phys_mem_base".
+
+For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
 be configured to use MP table and virtual wire interrupt mode. This requires
 INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
 VxWorks kernel configuration.
+
+Both 32-bit x86 and 64-bit x64 kernels can be loaded.
+
+There are two types of graphics console drivers in VxWorks. One is the 80x25
+VGA text mode driver. The other one is the EFI console bitmapped graphics mode
+driver. To make these drivers function, U-Boot needs to load and run the VGA
+BIOS of the graphics card first.
+
+    - If the kernel is configured with 80x25 VGA text mode driver,
+      CONFIG_FRAMEBUFFER_SET_VESA_MODE must be unset in U-Boot.
+    - If the kernel is configured with bitmapped graphics mode driver,
+      CONFIG_FRAMEBUFFER_SET_VESA_MODE need remain set but care must be taken
+      at which VESA mode is to be set. The supported pixel format is 32-bit
+      RGBA, hence the available VESA mode can only be one of the following:
+        * FRAMEBUFFER_VESA_MODE_10F
+        * FRAMEBUFFER_VESA_MODE_112
+        * FRAMEBUFFER_VESA_MODE_115
+        * FRAMEBUFFER_VESA_MODE_118
+        * FRAMEBUFFER_VESA_MODE_11B