The Bootloader is permanent software burned into the chipset. The INT6000™ and INT6300™ both have a Bootloader program but they behave differently because the INT6000™ needs flash memory and the INT6300™ does not. Neither the INT6000™ Bootloader nor the INT6300™ Bootloader can write to flash memory.

On startup, the INT6000™ Bootloader attempts to load runtime firmware from flash memory into SDRAM. If flash memory is not available, or the runtime firmware stored there cannot be loaded, then the INT6000™ Bootloader cannot continue so the device cannot function.

On startup, the INT6300™ Bootloader attempts to load runtime firmware from flash memory into SDRAM. If flash memory is not available, or the runtime firmware stored there cannot be loaded, then Bootloader will request runtime firmware from the local host processor.

An optional program stored in flash memory in place of runtime firmware. This program is used on the INT6000™ to support the Boot From Host operation, if needed. It is not used on the INT6300™ because the INT6300™ Bootloader now performs similar functions. The Softloader cannot write to flash memory.

On startup, the INT6000™ Bootloader loads the Softloader from flash memory into SDRAM, as it would do with runtime firmware. The Softloader then requests the actual runtime firmware from local host.

A small block of information that describes the type, size and characteristics of the SDRAM available for the benefit of the Bootloader. On the INT6000, SDRAM configuration must be stored in flash memory. On the INT6300, it may be stored in flash memory or on the local host. The INT6300™ Bootloader attempts to read configuration information from flash memory when it is present; otherwise, it requests that information from the local host using a VS_HST_ACTION message and so the host must store this information until it is requested.

There are two SDRAM configuration file formats. The first format is used by the Windows Device Manager and the int6k2 program and typically has a .config file extension. The second format is used by the int6k program and int6kf program and typically has a .cfg file extension. The latter format is more robust and should eventually replace the format.

The Windows Device Manager form consists of 64 hexadecimal ASCII characters. Files are at least 64 bytes but only the first 64 bytes are used. Files can be modified using a text editor. ASCII hex to binary conversion and checksum computation is needed on input. The config2cfg program can be used to convert this format to Open Powerline Toolkit format.

The Open Powerline Toolkit format consists of 32 binary bytes plus a 4 byte checksum. The file size is exactly 36 bytes. No conversion or checksum computation is needed on input. The chkcfg program can be used the validate this file format because it contains a checksum.

The INT6400™ chipset does not need a memory configuration parameter file because it has a different memory controller than earlier chipsets. SDRAM is now configured dynamically by an applets stored in the .nvm file.

The executable image that determines INT6000™ or INT6300™ capability and functionality. Runtime firmware refers to any executable image except the Bootloader which is considered to be boot firmware. Firmware files have a .nvm extension and can contain multiple firmware images. One of these images could be the parameter information block but Atheros currently distributes that as a separate file. The chknvm program can be used to detect obsolete or corrupt .nvm files. Runtime firmware can write to flash memory and must be running in order to re-program the chipset.

The configuration image that determines device network identity, functional capability and operational mode. The PIB structure often changes from one major firmware release to the next and often is not portable across major releases. Parameter information files have a .pib extension by convention and contain one parameter set. The chkpib program can be used to detect obsolete or corrupt PIB files.

Recent firmware releases support two PIB images in flash memory: the Factory PIB and the User PIB. The Factory PIB is the first PIB image written to flash memory. Once written, the Factory PIB cannot be changed without special software. The User PIB is created and over-written whenever the device needs to save new PIB parameters. Factory default values are restored by erasing the User PIB and rebooting the device. When a device reboots, it attempts to load the User PIB from flash memory. Failing that, it attempts to load the Factory PIB from flash memory. Failing that, it loads a Default PIB having minimum functionality. The loaded PIB becomes the Working PIB and determines runtime device identity and behavior.