doc/README.vxworks

   1 # SPDX-License-Identifier: GPL-2.0+
   2 #
   3 # Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
   4 # Copyright (C) 2015-2018, Bin Meng <bmeng.cn@gmail.com>
   5 # Copyright (C) 2019, Lihua Zhao <lihua.zhao@windriver.com>
   6
   7 VxWorks Support
   8 ===============
   9
  10 This document describes the information about U-Boot loading VxWorks kernel.
  11
  12 Status
  13 ------
  14 U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands.
  15 For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
  16 on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
  17 on PowerPC and ARM, 'bootm' shall be used.
  18
  19 With CONFIG_EFI_LOADER option, it's possible to chain load a VxWorks x86 kernel
  20 via the UEFI boot loader application for VxWorks loaded by 'bootefi' command.
  21
  22 VxWorks 7 on PowerPC and ARM
  23 ---------------------------
  24 From VxWorks 7, VxWorks starts adopting device tree as its hardware description
  25 mechanism (for PowerPC and ARM), thus requiring boot interface changes.
  26 This section will describe the new interface.
  27
  28 Since VxWorks 7 SR0640 release, VxWorks starts using Linux compatible standard
  29 DTB for some boards. With that, the exact same bootm flow as used by Linux is
  30 used, which includes board-specific DTB fix up. To keep backward compatibility,
  31 only when the least significant bit of flags in bootargs is set, the standard
  32 DTB will be used. Otherwise it falls back to the legacy bootm flow.
  33
  34 For legacy bootm flow, make sure the least significant bit of flags in bootargs
  35 is cleared. The calling convention is described below:
  36
  37 For PowerPC, the calling convention of the new VxWorks entry point conforms to
  38 the ePAPR standard, which is shown below (see ePAPR for more details):
  39
  40     void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
  41
  42 For ARM, the calling convention is shown below:
  43
  44     void (*kernel_entry)(void *fdt_addr)
  45
  46 When using the Linux compatible standard DTB, the calling convention of VxWorks
  47 entry point is exactly the same as the Linux kernel.
  48
  49 When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
  50 is like below:
  51
  52     bootm <kernel image address> - <device tree address>
  53
  54 VxWorks bootline
  55 ----------------
  56 When using 'bootvx', the kernel bootline must be prepared by U-Boot at a
  57 board-specific address before loading VxWorks. U-Boot supplies its address
  58 via "bootaddr" environment variable. To check where the bootline should be
  59 for a specific board, go to the VxWorks BSP for that board, and look for a
  60 parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
  61 value for "bootaddr" on an x86 board is 0x101200.
  62
  63 If a "bootargs" variable is defined, its content will be copied to the memory
  64 location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
  65 there, command 'bootvx' can construct a valid bootline using the following
  66 environments variables: bootdev, bootfile, ipaddr, netmask, serverip,
  67 gatewayip, hostname, othbootargs.
  68
  69 When using 'bootm', just define "bootargs" in the environment and U-Boot will
  70 handle bootline fix up for the kernel dtb automatically.
  71
  72 When using 'bootefi' to chain load an x86 kernel, the UEFI boot loader
  73 application for VxWorks takes care of the kernel bootline preparation.
  74
  75 Serial console
  76 --------------
  77 It's very common that VxWorks BSPs configure a different baud rate for the
  78 serial console from what is being used by U-Boot. For example, VxWorks tends
  79 to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200.
  80 Please configure both U-Boot and VxWorks to use the same baud rate, or it may
  81 look like VxWorks hangs somewhere as nothing outputs on the serial console.
  82
  83 x86-specific information
  84 ------------------------
  85 Before direct loading an x86 kernel via 'bootvx', one additional environment
  86 variable need to be provided. This is "vx_phys_mem_base", which represent the
  87 physical memory base address of VxWorks.
  88
  89 Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For
  90 VxWorks 7, this is normally a virtual address and you need find out its
  91 corresponding physical address and assign its value to "vx_phys_mem_base".
  92
  93 For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
  94 be configured to use MP table and virtual wire interrupt mode. This requires
  95 INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
  96 VxWorks kernel configuration.
  97
  98 Both 32-bit x86 and 64-bit x64 kernels can be loaded.
  99
 100 There are two types of graphics console drivers in VxWorks. One is the 80x25
 101 VGA text mode driver. The other one is the EFI console bitmapped graphics mode
 102 driver. To make these drivers function, U-Boot needs to load and run the VGA
 103 BIOS of the graphics card first.
 104
 105     - If the kernel is configured with 80x25 VGA text mode driver,
 106       CONFIG_FRAMEBUFFER_SET_VESA_MODE must be unset in U-Boot.
 107     - If the kernel is configured with bitmapped graphics mode driver,
 108       CONFIG_FRAMEBUFFER_SET_VESA_MODE need remain set but care must be taken
 109       at which VESA mode is to be set. The supported pixel format is 32-bit
 110       RGBA, hence the available VESA mode can only be one of the following:
 111         * FRAMEBUFFER_VESA_MODE_10F
 112         * FRAMEBUFFER_VESA_MODE_112
 113         * FRAMEBUFFER_VESA_MODE_115
 114         * FRAMEBUFFER_VESA_MODE_118
 115         * FRAMEBUFFER_VESA_MODE_11B