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