mirror of
				https://xff.cz/git/u-boot/
				synced 2025-10-29 09:33:46 +01:00 
			
		
		
		
	This updates the doc to mention chain-loading an x86 kernel via 'bootefi' command, along with several typos fix. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de>
		
			
				
	
	
		
			103 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			103 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| # SPDX-License-Identifier: GPL-2.0+
 | |
| #
 | |
| # Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
 | |
| # Copyright (C) 2015-2018, Bin Meng <bmeng.cn@gmail.com>
 | |
| 
 | |
| VxWorks Support
 | |
| ===============
 | |
| 
 | |
| This document describes the information about U-Boot loading VxWorks kernel.
 | |
| 
 | |
| Status
 | |
| ------
 | |
| U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands.
 | |
| 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 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
 | |
| 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 shown below:
 | |
| 
 | |
|     void (*kernel_entry)(void *fdt_addr)
 | |
| 
 | |
| When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
 | |
| is like below:
 | |
| 
 | |
|     bootm <kernel image address> - <device tree address>
 | |
| 
 | |
| VxWorks bootline
 | |
| ----------------
 | |
| When using 'bootvx', the kernel bootline must be prepared by U-Boot at a
 | |
| 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" 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
 | |
| there, command 'bootvx' can construct a valid bootline using the following
 | |
| environments variables: bootdev, bootfile, ipaddr, netmask, serverip,
 | |
| 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
 | |
| serial console from what is being used by U-Boot. For example, VxWorks tends
 | |
| to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200.
 | |
| Please configure both U-Boot and VxWorks to use the same baud rate, or it may
 | |
| look like VxWorks hangs somewhere as nothing outputs on the serial console.
 | |
| 
 | |
| x86-specific information
 | |
| ------------------------
 | |
| 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
 |