文件列表:

bios-1.0.2.1\boot\data.c (2255, 2014-11-08)
bios-1.0.2.1\boot\disk.c (11675, 2014-11-08)
bios-1.0.2.1\boot\link.lds (2206, 2014-11-08)
bios-1.0.2.1\boot\main.c (29187, 2014-11-08)
bios-1.0.2.1\boot\Makefile (2086, 2014-11-08)
bios-1.0.2.1\boot\pad (11, 2014-11-08)
bios-1.0.2.1\boot\pxeapi.c (18454, 2014-11-08)
bios-1.0.2.1\defs.boot (3906, 2014-11-08)
bios-1.0.2.1\fat\ff.c (156270, 2014-11-08)
bios-1.0.2.1\fat\Makefile (849, 2014-11-08)
bios-1.0.2.1\i386\bios_disk.s (11702, 2014-11-08)
bios-1.0.2.1\i386\bios_generic.s (4577, 2014-11-08)
bios-1.0.2.1\i386\bios_pxe.s (1565, 2014-11-08)
bios-1.0.2.1\i386\bswap.s (952, 2014-11-08)
bios-1.0.2.1\i386\gateA20.s (2241, 2014-11-08)
bios-1.0.2.1\i386\Makefile (915, 2014-11-08)
bios-1.0.2.1\i386\prot.s (6257, 2014-11-08)
bios-1.0.2.1\i386\pxecall.s (2657, 2014-11-08)
bios-1.0.2.1\i386\start.s (9433, 2014-11-08)
bios-1.0.2.1\include\bios.h (1224, 2014-11-08)
bios-1.0.2.1\include\data.h (7667, 2014-11-08)
bios-1.0.2.1\include\disk.h (3294, 2014-11-08)
bios-1.0.2.1\include\diskio.h (2565, 2014-11-08)
bios-1.0.2.1\include\ff.h (13167, 2014-11-08)
bios-1.0.2.1\include\ffconf.h (9398, 2014-11-08)
bios-1.0.2.1\include\pxe.h (15504, 2014-11-08)
bios-1.0.2.1\include\pxeapi.h (1123, 2014-11-08)
bios-1.0.2.1\include\vxoffsets.h (1102, 2014-11-08)
bios-1.0.2.1\Makefile (4078, 2014-11-08)
bios-1.0.2.1\boot (0, 2015-04-01)
bios-1.0.2.1\fat (0, 2015-04-01)
bios-1.0.2.1\i386 (0, 2015-04-01)
bios-1.0.2.1\include (0, 2015-04-01)
bios-1.0.2.1 (0, 2015-04-01)

VxWorks BIOS boot loader ======================== This directory contains the source code for the VxWorks BIOS boot loader for the IA32 and X*** platforms. This is a first stage loader which replaces the vxStage1Boot.s code provided in the BSP. When using the BIOS boot path, the system start up in 16-bit real mode. In this mode, only ***0K of memory is accessible. In early releases, the boot strategy for VxWorks on Intel systems required two pieces: a boot block placed in the master boot record (MBR) of the disk, and a compressed bootapp, stored on the disk as bootrom.sys. The bootapp would switch the system into protected mode and load a full VxWorks image. However this was only possible because the compressed bootapp was small enough to fit in ***0K of RAM. With more recent releases of VxWorks, adding the USB stack and ACPI support will easily cause the bootapp to exceed the size limit. In VxWorks 6.9, this problem was addressed by introducing a 2-stage boot process. The boot block would instead load a simple first-stage loader program, vxStage1Boot.bin, which would take the place of bootrom.sys. This in turn would load the actual bootapp, now named bootapp.sys. The vxStage1Boot code is unfortunately somewhat limited due to it being written entirely in 16-bit assembly code. Also, it does not properly support PXE booting by itself. The BIOS-based loader here is intended to be a drop-in replacement for the vxStage1Boot code, with the following benefits: - Written partly in assembly but mostly in C, to simplify maintenance and the addition of new features in the future. - Supports both disk and network booting. - Only one image is required for both cases (separate .bin and .pxe images are not needed). - Full source code provided - Code is independent of BSPs 1. Loader design ---------------- Since the C compilers shipped by Wind River produce 32-bit Intel architecture code, and since BIOS and PXE calls must be made in 16-bit real mode, the BIOS loader must be able to support both environments. To do this, the loader runs primarily in 32-bit protected mode but will "thunk" into 16-bit real mode to make a BIOS or PXE call, returning to 32-bit protected mode when the call is complete. This allows the loader to use the BIOS to access the underlying disk and network controllers on the platform without requiring protected-mode driver support: a single image will work on all BIOS-based systems. The loader provides support for setting the GATE A20 line if needed and will initialize the 8259 PIC for protected mode operation. It will also use the BIOS E820 interface to obtain a memory map which VxWorks can use to automatically determine how much memory is available in the system. The loader is separated into a few sub-modules modules: - stand, some standalone C library routines - i386, the underlying 32-bit assembly language code - fat, a small FAT filesystem module for disk booting - boot, the main loader code - include, header files 2. Dependencies on VxWorks -------------------------- The include/vxoffsets.h file defines a few constants which may need to be adjusted to suit a given VxWorks image. The most important ones are: ROM_TEXT_ADRS -- the address where the VxWorks image will be loaded into memory (default is 0x408000) ROM_WARM_HIGH -- the warm start entry point relative to ROM_TEXT_ADRS, defaults to 0x10. (Should be the same for all Intel BSPs in VxWorks 7.) To load the image at a different location, ROM_TEXT_ADRS must be changed to the value used when compiling the VxWorks bootapp or ROMable image. 3. Loading a VxWorks bootapp vs. ROMable image ---------------------------------------------- Historically, the VxWorks bootstrap process for the Intel architecture involved two pieces: the boot block (vxld.bin or bootsect.bin) and a VxWorks bootapp. The bootapp was typically called a bootrom, but this is a bit of a misnomer: a bootrom is expected to actually be in ROM or flash, and its romInit code is expected to be the first thing that runs after a CPU reset, but on the Intel architecture it's the BIOS that fits this description. It is the BIOS which would load the boot block from disk, and the boot block in turn would load the BOOTROM.SYS file into memory at address 0x8000 and jump to it. The romInit code in BOOTROM.SYS was responsible only for switching the CPU from 16-bit real mode to 32-bit protected mode and starting VxWorks. (For a PXE boot, the boot block was not required: the PXE ROM would just load the bootapp directly.) This strategy only worked as long as the bootapp was small enough to fit into the approximately ***0KB of RAM available when the CPU is running in 16-bit real mode. However, with the addition ACPI and USB support, the bootapp grew too large to fit in this space, even when compressed. As a result a two-stage boot strategy was introduced in VxWorks 6.9. An intermediate stage was added that would take the place of BOOTROM.SYS and it in turn would load the real bootapp, BOOTAPP.SYS. Typically BOOTAPP.SYS was still build as a compressed ROMable image, but this was not really required. Since the ***0KB size limitation is no longer an issue, this implies that it's no longer strictly required to boot VxWorks on the Intel architecture using a bootapp. Instead, the user can now create a VxWorks image that's configured as a ROMable image and load it directly. There are three possible ROMable image formats: vxWorks_rom, vxWorks_romCompress and vxWorks_romResident. While not normally used on Intel, all three of them will work with some judicious setting of ROM_HIGH_ADRS and ROM_LOW_ADRS. The one exception is vxWorks_romResident, which currently is not supported for ***-bit builds. (It's possible to create a ***-bit VxWorks Image Project and configure it for a romResident build, however compilation will fail.) The difference between creating a bootapp and creating a ROMable VxWorks image is the use of the PROFILE_BOOTAPP profile. A bootapp therefore is just a ROMable VxWorks image built using the bootapp profile. Several scripts are available in the examples directory which show how to configure and build 32-bit and ***-bit bootapps and images which can be loaded with either the BIOS loader or UEFI loader. 4. Building the loader ---------------------- All that's required to build the BIOS loader is to type make in the top level directory. All object code will be compiled into vxworks-7/workspace/bios. The resulting vxStage1Boot. 5. Using the loader ------------------- For disk booting, the same instructions in the target.ref BSP documetation for creating a bootable disk should be followed, with the one exception being that the new vxStage1Boot.bin loader binary should be substituted for the original. After formatting a flash drive or disk and installing the boot block, copy vxStage1Boot.bin to the root directory of the drive as BOOTROM.SYS. Then copy the vxWorks_rom.bin, vxWorks_romCompress.bin or vxWorks_romResident.bin image to BOOTAPP.SYS in the same location. When the system boots, it should load BOOTROM.SYS, which will then load BOOTAPP.SYS. The original vxStage1Boot.s code did not properly support PXE booting, however the new code does. For PXE boot, the vxStage1Boot.bin image should be specified as the bootstrap file in the DHCP entry for the target. The VxWorks image (vxWorks_rom.bin, vxWorks_romCompress.bin or vxWorks_romResident.bin) should then be copied to the top level TFTP server directory as bootapp.sys. When the target boots, the PXE ROM will download the vxStage1Boot.bin file and it in turn will then download the bootapp.sys file.

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：