M Maker Communications, Inc. MXT3010 Universal Boot Format Applications Note Number 14 Revision 1.2 Maker Communications 73 Mount Wayte Avenue Framingham, Massachusetts 01702 Order Number: 100355-03 March 10, 1999 March 10, 1999 Copyright(c) 1998 by Maker Communications, Inc. All rights reserved. Printed in the United States of America. The information in this document is believed to be correct, however, the information can change without notice. Maker Communications, Inc. disclaims any responsibility for any consequences resulting from the use of the information contained in this document. The hardware, software, and the related documentation is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1) (ii) of The Rights in Technical Data and Computer Program Product clause at DFARS 252.2277013 or subparagraphs (c)(1) and (2) of the Commercial Computer Software-Restricted Rights at 48 CFR 52.227-19, as applicable. Contractor/manufacturer is: Maker Communications, Inc. 73 Mount Wayte Avenue Framingham, MA 01702 CellMaker and BridgeMaker are registered trademarks of Maker Communications, Inc. AccessMaker, CodeMaker, and LinkMaker are trademarks of Maker Communications, Inc. All other trademarks are owned by their respective companies. This information is proprietary and restricted. Do not copy. MXT3010 Universal Boot Format Introduction and Overview Introduction and Overview Maker Communications delivers application code in a universal boot format (UBF). The UBF format enables a single stage load of any MXT3010 application object to all MXT3010 devices. Additionally, Maker supplies development and configuration tools that generate UBF images from Maker source and binary firmware releases. The tools also create UBF images of customer developed SWAN applications. A UBF image provides a robust, self checking firmware download technique. Loading a UBF file transparently masks differences between the MXT3010C and the MXT3010EP. The load process includes a Power on Self Test (POST) of the MXT3010 subsystem and a bootstrap load of the target application. Maker provides the source code of the POST and bootstrap routines for end user modification and integration into custom SWAN applications. The differences between the MXT3010C and the MXT3010EP were introduced by bugs in the MXT3010EP. The UBF format hides these differences, which are listed below. MXT3010EP: bug#306: Fast Memory Mode 1 incompatible with uboot routine. MXT3010EP, bug#350: uBoot Wrap Problem. MXT3010EP, bug#351: Min/Max Opcodes are reversed. This application note describes the creation of the UBF format and the UBF download and self test processes. It also explains how to utilize source module components of the UBF format to create multiple stage download processes. Maker Communications, Inc. Company Confidential Page 1 MXT3010 Universal Boot Format WASM File Formats WASM File Formats The following table provides a synopsis of the file formats that WASM produces. Each format targets a different environment. The UBF file builds upon the .ld (LD) and .hex (HEX) formats and makes them obsolete as standalone formats. The .ld format of an application could be used for a download provided the application file is compiled for the correct version of the target (MXT3010C or MXT3010EP). However, the UBF file is the recommended approach to hide from the application code some of the complexities of the loading process. Also, the HEX format allows scattered loads saving filler blocks from taking up download space for sparse application code and data components. For details on the formats below, see the MXT3010 Reference Manual and the SWAN Assembler User's Guide. File Format Assembler Switch Description .ld -L Bootstrap code - Format understood by the microcode (uboot) embedded in the MXT3010. This uboot runs as the MXT3010 exits reset. The .ld is a contiguous region of application code loaded by the uboot. .hex -H Downloadable code - The .hex format is understood by the hex loader supplied in the bootstrap code. It allows multiple code regions to be loaded. CSIM code - default output format that can be loaded in the CellMaker Simulator (CSIM). .bin .ubf N/A .ubf files as well as .eld and .ehx files are generated by shell scripts included with the application source. Universal Boot Format (UBF) Description All firmware applications written and supported by Maker Communications will be distributed in both UBF format and an extended HEX format. The UBF format provides a default load with minimal user configuration. The extended HEX format enables the generation of UBF code images configured for end user systems. MXT3010s will load UBF files from Port1, Port2 or the Communications Port, determined by the strapping of the ICSO[C:D] pins as defined in the MXT3010 Reference Manual. The POST definition file contains system specific configuration options. This capability reduces or eliminates end user SWAN diagnostics programming. However, the user may extend the POST by modifying the supplied source code. Figure 1 illustrates the UBF algorithm which is described in more detail in the following sections. Maker Communications, Inc. Company Confidential Page 2 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description Figure 1: MXT3010 Universal Boot Process Reset Note 1: Hardware uBoot supports booting from P1,P2 or CommIn. Boot Word is configured by end user application Hardware uBoot Loader (.ld image) Note 2: When loading from COMMIN, the checksum is correct. When loading from Port1 or Port2, it is correct after the reload. See Booting a UBF Image. 16-bit ChkSum (CommOut[31:16]) Boot from CommIn or MXT3010C? No P1 or P2 BootStrap Loader Yes Note 4: Routine ensures that correct min/max opcodes are used for MXT3010EP or MXT3010C. Note 6: Return code written to flag location specified in configuration file -- Port1, Port2 or COMMOUT. Note 3: Addc used in internal uBoot Loader limits max boot size when booting from P1or P2, this routine is unnecessary when booting from the Comm Port. or on an MXT3010C device. Min/Max Swap Note 5: Power on SelfTest test the ALU, Icache, CSS, CB Ram, & FMEM Interface. Optionally the user can configure Port1 and Port2 tests to match system constraints. Power-On Self-Test Pass/Fail Indication xxxxffff - Self-Test Passed xxxxaaaa - Failing Test Pgm Counter Host Code should set a 2 sec watchdog timer to detect POST hang failures. Application HEX Loader Note 7: Boots firmware application encapsulated in the boot UBF image as a HEX image. Min/Max Swap Generic Initialization Sequence Note 8: Initialization Sequence can be modified by end user in mxt3010_selftest_config.asm. Jump to Application Maker Communications, Inc. Company Confidential Page 3 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description UBF File Components The UBF file format is a hybrid of extended LD and HEX formats. The UBF file contains a byte wide ASCII hex representation of the code. Note, this file format must be converted into binary form prior to transfer to the MXT3010. Table 1 illustrates the format of the UBF image. The UBF format consists of two major sections, the extended LD section and the extended HEX section. The first section is the bootstrap routines integrated with the POST in extended LD format - an LD image of the code followed by a list of min/max instruction addresses within the code. A HEX image of the application code, similarly extended with a list of min/max instruction addresses, follows the extended LD section. Maker Communications, Inc. Company Confidential Page 4 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description Table 1: Universal Boot File Format End of file (Higher Address) Section Sub Section Extended Hex (.ehx file) Min/Max List Application Firmware (.hex file) The four fields here repeat as required Extended Ld (.eld file) Min/Max List Load Firmware from MXT3010_ selftest.ld (.ld file) Sub-Sub Section Ref* Field Size Detail [Units] (Bytes) Reserved Ehx-d 4 0xffff_ffff [n/a] Min/Max Addresses Ehx-c Ehx-b*4 Address of locations with Min/Max instructions [Word] Adrs Count Ehx-b 2 Indicates how many min/max instructions are in hex file [Entries] EP/C Ctl Block Ehx-a 2 MXT3010 version assembled: 0x0001=EP; 0x0000=C [n/a] Data i Hex-d Hex-b Application data [n/a] Address i Hex-c 4 If byte count (Hex-b) > 0, Address [Bytes] where this code segment is placed in Fast Memory else (when Hex-b=0) code start address [Word] Byte Count i Hex-b 2 Number of bytes of the code segment described here in Hex-d. If zero, Hex-c is starting address of code and Hex-d is empty [Bytes] Cookie i Hex-a 2 Control parameter used to indicate start of code segment; 0x4325 [n/a] Reserved Eld-e 4 0xffffffff [n/a] Min/Max Addresses Eld-d Eld-c*4 Address of locations with Min/Max instructions [Word] Adrs Count Eld-c 2 Indicates how many min/max instructions are in ld file [Entries] EP/C Ctl Block Eld-b 2 MXT3010 version assembled: 0x01=EP; 0x00=C [n/a] Reserved Eld-a 2 Reserved; provides word alignment; 0xffff [n/a] Checksum Ld-f 2 Checksum of ld file fields of Ld-c, Ld-d, and Ld-e Hex Loader Ld-e Variable Contains Load_Hex application and the code (Hex_Loader) used to place it in high memory Power-On Self Test Ld-d Variable Contains the POST routines and the call list for the self tests Boot-Strap Loader Ld-c Variable Contains code to ensure a proper load of .ld code. Half Word Count Ld-b 2 Number of half words to be loaded from fields Ld-c through Ld-e [Half-Word] Start Address Ld-a 2 Start address for .ld load and for control to be passed [Word] Beginning of file (Address 0) * The references in this table only have significance in this document. Shaded sections are application specific. The .ld format is not required to have this code, nor is it required to be in this order. This is the format of the Maker supplied code. Maker Communications, Inc. Company Confidential Page 5 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description Min/Max Instruction Lists The lists of min/max instruction addresses allow the transparent mask of the MXT3010EP and MXT3010C min/ max opcodes. The list contains control information, including a flag that specifies the target architecture of the original code assembly and a count of the addresses. The address of each min/max instruction is stored as a 32 bit entity and represents a Program Counter (PC) - a word address. The PC address must be multiplied by 4 to derive a byte address in Fast Memory. During the UBF load process, the min/max swapper uses this control block to ensure that proper orientation of the min/max opcodes. Port1/Port2 Bootstrap Loader All MXT3010s contain hardwired microcode that loads an LD file when the chip exits the reset sequence. This microcode, the Hardware uBoot Loader, relies on the carry logic when booting from Port1 or Port2. Since the carry logic was omitted from the MXT3010EP (see Bug #297), the uBoot Loader operation is unreliable when loading from either DMA port on this device. On an MXT3010EP booted from Port1 or Port2, the bootstrap process embedded in the UBF file invokes the Port1/Port2 BootStrap Loader. This routine re-loads the LD formatted POST file; ensuring correctness by avoiding carry arithmetic. Without carry logic, the maximum size of an LD image on the MXT3010EP is 4K instructions on Port1 or 512 instructions on Port2. To simplify the implementation of the Port1/Port2 Bootstrap Loader, it resides within the first 512 instructions of the LD image. This design guarantees that the uBoot Loader downloads the Port1/Port2 Boostrap Loader correctly. POST Routines Once the extended LD image has been reliably downloaded, the UBF bootstrap code invokes a suite of POST routines. See Power-On Self Test on page 12 for a description of the POST. Maker Communications, Inc. Company Confidential Page 6 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description Hex Loader Successful completion of the POST confirms system integrity and readiness for downloading the application. The Hex Loader routine loads extended HEX images from a byte wide devices on Port1 or Port2 or in half word format from the COMMIN port. The Hex Loader requires two cache pages (4K instructions = 1 code segment). It uses segment 0x7000, which corresponds to Fast memory byte address range (0x1C000 - 0x1FFFF). Figure 2 illustrates the memory map of the default Hex Loader. Figure 2: Hex Loader Code Segment Jump to hex Application 0x7ffb No-Op Filler Min/Max Swapper Optional MXT3010 Init. Hex Intepreter 0x7000 When invoked, the Hex Loader loads the remaining section of the UBF image, using the same input method as the LD load. The remaining section is the extended HEX section of the UBF image - the application firmware and its min/max instruction address list. The Hex Loader parses the application code and loads it to Fast Memory. Then it calls the min/max swap routine to process the address list. Once the Hex image is downloaded, the Hex Loader purges the MXT3010 instruction cache (ICACHE) by executing nops until the last five instructions. The Hex Loader leaves the cache tags all set to 0xf. The last five instructions, shown below, invoke the application. ;;; ////////////////////////////////////////////////////////////////////////////////////// ;;; These are the last 5 instructions of the page, that allow ;;; the boot loader to jump to the start of the user specified ;;; address. #t4 has the value of the code segment of the first ;;; instruction and #t5 has the segment offset of the first ;;; instruction of the application. ;;; ////////////////////////////////////////////////////////////////////////////////////// .loc 0x1ffb $start_branch_to_user sftri #t5 12 r1 sftli #t4 4 #t4 mv #t5 #br_link_reg or #t4 r1 #ibase_reg br n $end_branch_to_user Maker Communications, Inc. Company Confidential Page 7 MXT3010 Universal Boot Format Universal Boot Format (UBF) Description Upon passing control to the downloaded application, the MXT3010's ICACHE has been flushed by loading the TAG=0xF. Cache segments with TAG=0xF must not be used by the application code. The use of this segment would generate unwanted cache hits, and cause erratic system behavior. Min/Max Swapper Figure 3 depicts the min/max swapper algorithm. The flowchart logically illustrates the process, which is contained within the mxt3010_minmax_swap.asm. The implementation allows a simple host algorithm when loading from the communications port. It is a stand-alone routine, callable by other applications. Figure 3: Min/Max Swap Algorithm Call Note 1: The EP/C Ctrl Block within the min/max address list data structure specifies the target device of the assembler output. Compiled for mxt3010ep Yes No Exit with Error No Compiled for mxt3010b/c Yes Running on C? No Get # of min/max instr in list Running on EP? No Count == 0? No Read 16bit Instr Word Adrs Yes sftli 2, to form fmem byte adr load min/max instruction from fmem Yes flip min->max or max -> min Decrement Word Count Exit Maker Communications, Inc. Company Confidential Yes Page 8 MXT3010 Universal Boot Format Booting a UBF Image The min/max routine accepts two input parameters -- the halfword address of the min/max list data structure and a width indicator which informs the routine whether the list is a byte wide structure. The routine interprets the EP/ C Control Block within the data structure to determine which device the compilation of the code targeted. The swap routine returns an error code if the control block is illegal. Otherwise, it returns a success code after the opcode have been swapped. Note that the min/max routine fully executes regardless of the need to swap. The swapping of the opcodes is performed by an XOR of 0x0 when the swap is not required. This allows the routine to cleanly remove the extended parts of the .eld and .ehx during the download process without a separate special routine. The flow chart is a 'logical' representation of the behavior. Booting a UBF Image The MXT3010 boot port is determined based on the setting of ICSO_A and ICSO_B1. During reset, ICSO_A and ICSO_B are tri-stated. As RESET_ is removed, the state of these pins is sensed. The boot port is determined as follows: ICSO_A ICSO_B Boot Port 0 1 Port1 Memory 1 0 Port2 Memory 1 1 COMMIN Register The UBF file design mimics the loading process of an LD file. From the host's perspective, the two downloads are identical, with the exception of POST status reporting. During code assembly, the location of the POST results is specified. The host should implement a POST watchdog timer to detect MXT3010 hang failures. The entire UBF process, including the post, should take less thatn 2 seconds. The boot flow and data format depends on the boot port. 1.During normal operation, ICSO_A and ICSO_B function as outputs. Maker Communications, Inc. Company Confidential Page 9 MXT3010 Universal Boot Format Booting a UBF Image Booting from Port1 or Port2 Figure 4 shows the UBF boot flow when booting from Port1 or Port2. Figure 4: Booting from Port1 or Port2 Host MXT3010 Reset Incorrect 16-bit checksum COMMOUT[31:16] Correct 16-bit checksum COMMOUT[31:16] POST Failure No POST Successful? Hardware Uboot .Eld load Bootstrap .Eld reload Post Status ID Timer Start Timer POST .Exh load (application) Yes No Jump to Code Timer Expired? Yes Issue API Commands Operational When booting from Port1 or Port2 the MXT3010 is expecting to read a single image byte in the most significant byte of either the P1AD or P2AD bus. When booting from Port2 the MXT3010 expects a byte wide FLASH/ PROM device and drives non-burst cycles onto the bus interface starting at address 0. Port1 loads also allow external logic to map a byte wide FLASH/PROM to the upper 1Mbyte of address space (address= 0xFFF00000). Optionally, the host may map Port1 system memory (RAM) to the upper 1Mbyte address space. In this case, the code image must be loaded to the RAM before the MXT3010 RESET signal is de-asserted. Figure 5 shows the expected byte lane position of the UBF image bytes (i.e. P1AD31-24). Although it is not shown, the expected Port2 location is the upper byte lane (i.e. P2AD15-8). Figure 5: Port1 Memory Byte Organization B y te 0 B y te 1 B y te 2 B y te 3 V b31 Maker Communications, Inc. b0 Company Confidential Page 10 MXT3010 Universal Boot Format Booting a UBF Image Booting from COMMIN Figure 6 shows the UBF boot flow when booting from COMMIN. Figure 6: Booting from COMMIN Host MXT3010 Reset Incorrect 16-bit checksum COMMOUT[31:16] POST Failure No POST Successful? Hardware Uboot .Eld load Post Status ID Timer Start Timer POST .Exh load (application) Yes No Jump to Code Timer Expired? Issue API Commands Yes Operational When booting from COMMIN, the MXT3010 expects to receive 2 bytes at a time and parses the most significant halfword of the COMMIN register, illustrated in Figure 7 below. The boot loader will obey the communications port low level handshake and only read a halfword when the COMMIN busy flag is set. Host software should ensure that successive writes to the COMMIN register are not performed until each halfword is read by the MXT3010 device. Figure 7: Communications Register Organization B y te 0 B y te 1 V V b31 Maker Communications, Inc. B y te 2 B y te 3 b0 Company Confidential Page 11 MXT3010 Universal Boot Format Power-On Self Test Power-On Self Test The POST diagnostics consist of 17 individually selectable tests. By default, only internal chip components are tested. The customer can enable additional tests during the make_ubf process. For more details on enabling or disabling specific tests refer to section describing make_ubf. The POST returns 0xFFFF if all tests pass. Otherwise, it returns the address of the failing routine. By default, the POST return value is written to COMMOUT. However, the return value may instead be returned to a user programmable address in Port1 or Port2 memory with a make_ubf configuration setting. Default Tests The tests described in this section are always enabled. They test internal chip components. Min/Max ALU Test This test serves as a simple ALU test. It is a pseudo-exhaustive test of all flavors of the min/max instruction. Additionally, it covers a fair amount of the 6 function comparator and the 16 bit add/subtract unit. CB RAM Address == Data This test steps through the entire CB RAM writing the address as the data pattern into each sequential half-word location. After writing the entire RAM it then reads each location to verify the unique data pattern at each address. In addition to this traditional address = = data test, this diagnostic also methodically tests the ABC branch nullification logic. This test ensures that ld/st instructions can be properly nullified. CB RAM SSO pattern This test ensures that every bit in the CB RAM toggles from 1 to 0. It high stresses the simultaneously switching output (SSO) performance of the internal RAM. The test writes all half-word locations in CB RAM with 0x0000, 0xfffff, 0x5555, 0xaaaa. PSB RAM Address == Data This diagnostic performs an address = = data test on the Primary Scoreboard (PSB) RAM. See the CB RAM Address = = Data test for a description of the test algorithm. PSB RAM SSO pattern This test stresses the PSB RAM in the same manner as described in the CB RAM SSO pattern test. Maker Communications, Inc. Company Confidential Page 12 MXT3010 Universal Boot Format Power-On Self Test SSB Size Test This test verifies that all legal configurations of the Cell scheduling system are verified. It makes four passes testing 8,4,2, & 1 scoreboard on each successive pass. The pseudo-code below depicts the test algorithm. ;;; *for (i=1;i<=n) ;where "n" is the number of scoreboards ;;; * { ;;; * for (j=1;j<=k*16) ;where "k" is number of scoreboard slots ;;; * { ;;; * push ++ ;;; * } ;;; * push ; ;;; * check for schedule error; ;;; * for (j=1;j<=k*16) ;where "k" is number of scoreboard slots ;;; * { ;;; * pop_and_compare ;;; * } ;;; * Maker Communications, Inc. Company Confidential Page 13 MXT3010 Universal Boot Format Power-On Self Test CSS Test There are two phases to the Cell Scheduling System test. The Test Algorithm is outlined below. TESTA: ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * (1) Fill Primary Scoreboard and Schedule a Push;;; * ensure that a CSS error is asserted clear the error ensure that a CSS error is de-asserted (2) Hierarchically Setup a Primary Scoreboard with 128 empty slots (1per each bit in the secondary scoreboard. FOR (i=1,i <= 128, i= i+1) begin (a) pop the cell. check the conn id. ensure that the "assigned cell flag" is not asserted. +--(b) push the cell starting from the beginning of the scoreboard | check the ptr table address where CSS scheduled | ensure that the "assigned cell flag is not asserted +--(c) pop the cell check the conn id. ensure that the "assigned cell flag" was asserted. clear the "assigned cell flag". (d) push the cell and re-schedule from the end of the scoreboard check the ptr table address where CSS scheduled ensure that the "assigned cell flag is not asserted ensure that no CSS errors where asserted. end ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * ;;; * (2) Pop 16 Consecutive Cells from above. ensure that no CSS errors where asserted. hierarchically check the push vs. shadow Memory. (1) Push 8 Consecutive Cells ensure that no CSS errors where asserted. hierarchically check the push vs. shadow Memory. (3) Push/Pop 8 Consecutive Cells. Schedule a 129 Push;;; * ensure that CSS error where asserted. clear the error TESTB: Maker Communications, Inc. Company Confidential Page 14 MXT3010 Universal Boot Format Power-On Self Test Expansion Tests The following tests can be enabled individually during the make_ubf process. Some tests also require customer configuration. FMEM Bank 0 walking 1/0 This test verifies the integrity of the Fast memory (FMEM) data bus by walking both a "1" and a "0" onto the FMEM data bus. Note that all fast memory writes are done as 16 bit writes and that the reads are performed as 32 bit reads. FMEM Bank 1 walking 1/0 This test is identical to the previous test, except that it operates on bank 1. FMEM Bank SSO pattern Write Alternating FFFFs and 0000s to alternating banks. This tests back-back reads from adjacent banks of fast memory and should detect bus contention conditions. FMEM Address == Data This steps through the entire FMEM RAM array writing the address as the data pattern into each sequential location. After writing the entire RAM it then reads each location to verify the unique data pattern at each address. When enabled, the test starts at the first word after the executable POST code image. Note that all fast memory writes are done as 16bit writes and that the reads are performed as 32bit reads. Port1 walking 1/0 This test verifies the integrity of the Port1 interface by walking both a "1" and a "0" onto the P1AD bus. The starting address of the Port1 Test Region as the location to which it walks the 1 and 0. The Start Address of Port1 Memory is configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Maker Communications, Inc. Company Confidential Page 15 MXT3010 Universal Boot Format Power-On Self Test Port1 Address == Data This test does a traditional test stepping through the P1 Memory Region under writing the address as the data pattern into each sequential location. After writing the entire RAM it then re-reads each location to verify the unique data pattern at each address. The Start and End Addresses of Port1 Memory are configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Port1 block data The test ensures that each 32 bit word in the Port1 Region under test is written with 0x0000, 0xfffff, 0x5555, 0xaaaa. In addition to Ensuring that Every bit in the Region under test toggles this test will verify all legal block transfer sizes on the P1 Bus. The Start and End Addresses of Port1 Memory are configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Port2 Walking 1/0 This test verifies the integrity of the Port2 Adrs/Data bus in burst mode by walking both a "1" and a "0" onto the P2AD bus. The test uses the starting adrs of the Port2 Test Region as the location to which it walks the 1 and 0. The Start Address of Port2 Memory is configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Port2 Burst Address ==Data This test does a traditional test stepping through the P2 Memory Region under test writing the address as the data pattern into each sequential location, utilizing the P2 Burst mode operation. After writing the entire RAM it then re-reads each location to verify the unique data pattern at each address. The Start and End Addresses of Port1 Memory are configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Port2 block data This test ensures that every bit in the CB RAM toggles from 1 to 0. It is designed to be very stressful in testing the SSO performance of the internal RAM. The test ensures that each 32 bit word in the Port1 Region under test is written with 0x0000, 0xfffff, 0x5555, 0xaaaa. In addition to Ensuring that Every bit in the Region under test toggles this test will verify all legal block transfer sizes on the P1 Bus. The Start and End Addresses of Port1 Memory are configurable by the user in the MXT3010_SELFTEST_CONFIG.asm file. Maker Communications, Inc. Company Confidential Page 16 MXT3010 Universal Boot Format Creating UBF Files Creating UBF Files Maker delivers a default UBF file which runs the default POST routines and returns status via COMMOUT. However, the UBF file's flexible design allows numerous configuration options. To enable users to configure their own UBF files, Maker provides utilities that create UBF files. For source customers, UBF files are made with loader/post source and application source and for binary customers, UBF files are made with loader/post source and application hex files. Maker Release Directory Structure Figure 8 shows the directory structure of Maker applications. The top level directory contains two subdirectories. One contains the application itself (application). The other contains Maker's development tools (dev_tools). The application directory contains all application specific binaries. Source releases also contain a separate directory with the application's source code. Under the development tools directory, three directories - harness, mxt3010 and selftest, contain the UBF bootstrap routines and reside in a POST directory. The wasm directory contains the SWAN Assembler and shell scripts for building UBF files. Figure 8: Application Directory Structure and UBF Build Process <APPLICATION> <NAME> dev_tools wasm Contains the source for the SWAN Assembler (WASM) and shell scripts to generate file formats. application POST harness mxt3010 selftest Contains the diagnostic test harness source code. Contains the source code for tests specific to the MXT3010 binary Contains routines that bootstrap load the firmware and invokes self-tests. source Present only for source releases build_hex build_ld Extended HEX File Extended LD File <application.ehx> mxt3010_selftest.eld build_ubf shell script UBF <application.ubf> UBF Boot Process Maker Communications, Inc. Company Confidential Page 17 MXT3010 Universal Boot Format Creating UBF Files UBF Development Tools Maker provides a set of development tools that allow customers to create UBF files. All Maker customers receive the tools, including those developing custom applications, modifying Maker source code or simply running Maker binary applications in their systems. The bootstrap and POST source code are provided as part of the development tools. Currently two utilities layered on top of WASM generate UBF files in a two step process described below. These utilities are shell scripts that invoke WASM and post-process the assembler's text output with AWK to generate the UBF file. build_ld This shell script invokes WASM with the -L option to generate an LD file. Then it appends the min/max address list to the LD file to create an extended LD image. Maker releases an extended LD image with all applications. This image, mxt3010_selftest.eld, contains the bootstrap routines and a default POST. The user may customize this image as described in Defining Selftest Parameters on page 19. build_hex Invokes WASM with the -H option to generate a hex file and generates the appends the min/max address list to this file to create an extended HEX image. This file output is input to the BUILD_UBF utility. Maker releases an extended HEX image of all application with both binary and source releases. Note that there are build_hex scripts for test purposes in the dev-tools tree while the target application tree will contain a build_hex script for the target application. build_ubf After customizing the POST via mxt3010_selftest_config.asm, this utility is called with two parameters - the filename of the extended LD bootstrap/POST object and the filename of the extended HEX application object. This utility will generate an LD format of the selftest image with the build_ld utility, and bind it with the application hex file to generate a UBF file. Note that there are build_ubf scripts for test purposes in the dev_tools tree while the target application tree will contain a build_ubf script for the target application. In either case, the output file from the build_ld script will be the input to any of the build_ubf scripts. Maker Communications, Inc. Company Confidential Page 18 MXT3010 Universal Boot Format Creating UBF Files Multiple Stage Hex Loaders There are some applications that require or expect to load the end application only after running an intermediate application such as custom diagnostics, which then bootstraps the firmware application. Often this allows maximum flexibility for field upgrades. In this scenario the "application firmware" embedded in the UBF image is the diagnostic/bootstrap. To load the final application, the bootstrap program must load an extended HEX file and swap the min/max prior to passing control to the downloaded application. The example application code provided with the UBF POST routines provides an example of an application which invokes the Hex Loader. Customer may integrate the example loader with system specific bootstrap routines with little or no changes to the provided source code. Defining Selftest Parameters The UBF File is designed to be customized in a configuration file, mxt3010_selftest_config.asm, supplied with the source for the selftest. This section describes the options available in that file. ;;; //////////////////////////////////////////////////////////////////////////// ;;; // SelfTest Revision Number: ;;; // ;;; // This Revision Number is written to comm_out[31:16] after the ;;; // completion of the selftest. Comm_out[15:0] will indicate pass ;;; // fail status: ;;; // ;;; // Commout[15:0] :0000 #selftest_failed ;;; // Commout[15:0] :1030 #selftest_passed #define POST_rev_num 0x100 ;;; //////////////////////////////////////////////////////////////////////////// ;;; // Programming the Boot Configuration Word: ;;; // ;;; // It is very important that bit4 matches your hardware configuration, ;;; // if you are using 128Kx18 SRAMS then bit4=1. Additionally ;;; // the "early end" modes on Port1 and Port2 must match your hardware ;;; // before performing burst cycles on either bus. Note that when ;;; // downloading code, the transfers are performed as single-word transfers. ;;; // ;;; // bit7:hdw_p2_e_end = 0 ;;; // bit6:hdw_p1_e_end = 0 ;;; // bit5:hdw_rla_inc_mode = 0 ;;; // bit4:hdw_512k_banks = 0 ;;; // bit3:hdw_asynch_txclk = 0 ;;; // bit2:hdw_asynch_rxclk = 0 ;;; // bit1:hdw_ut_56b_cells = 0 ;;; // bit0:hdw_ut_skip_hec = 0 Maker Communications, Inc. Company Confidential Page 19 MXT3010 Universal Boot Format Creating UBF Files #define boot_config_reg 00 ;;; //////////////////////////////////////////////////////////////////////////// ;;; The Following Parameter Controls the Code Segment (4Kbytes Used by the ;;; hex loader). This is a PC Word Address. Upon loading the Hex application ;;; the last cache page (0x7800-0x7fff) should not be used by the firmware ;;; application since this has been used as the cache flush page. #define hex_load_segment 0x7000 ;;; ///////////////////////////////////////////////////////////////////////////////// ;;; // SubTest Pass Count ;;; // ;;; // The Selftest makes a single pass through the main diagnostic loop. The Number ;;; // of subpasses of each individual test is programmable but must be less than ;;; // 64K subpasses ;;; ///////////////////////////////////////////////////////////////////////////////// #define subtest_passes 10 ;;; ///////////////////////////////////////////////////////////////////////////////// ;;; // To Disable a Test Comment out the Switch. Having all Switches Commented ;;; // out effectively bypasses the power-on selftest. .define minmax_test ; Min/Max/Cmp ALU Test .define cbr_adrs_data ; CB Ram Adrs=Data testn .define cbr_pattern_test; CB Ram SSO Patterns .define psb_adrs_data ; PSB Ram Adrs=Data testn .define psb_pattern_test; PSB Ram SSO Patternsn ;;; ///////////////////////////////////////////////////////////////////////////////// ;;; The User must Properly Configure the Fmem Address Range Switches that Follow... .define fmem_walk_data_bank0; Walking 1's/0's to Bank0n .define fmem_walk_data_bank1; Walking 1's/0's to Bank0 .define fmem_bank_sso; SSO Patterns Alternating Between Bank 0/1 .define fmem_adrs_data; Fast Memory Adrs=Data Test. .define ssb_size_test ; Tests 8,4,2,1 Scoreboard Configurations .define css_test ; CSS Test.. ;;; ///////////////////////////////////////////////////////////////////////////////// ;;; If Either Port1/Port2 Tests are Configured the User must Properly Configure ;;; the Port1/Port2 Address Range Switches that Follow... ;.define p1_walk_data ;.define p1_adrs_data ;.define p1_block ;.define p2_walk_data ;.define p2_adrs_data ;.define p2_block ; Port1 Walking 1's/0's ; Port1 Adrs=Data test. ; Port1 Block Data Test. ; Port2 Walking 1's/0's ; Port2 Adrs=Data test. ; Port2 Block Data Test. ;;; ///////////////////////////////////////////////////////////////////////////////// ;;; // To Disable ALl Selftests comment in the Following Switch. This also prevents ;;; // source code from being compiled in.. Maker Communications, Inc. Company Confidential Page 20 MXT3010 Universal Boot Format Creating UBF Files .define skip_all_selftests ;;; ///////////////////////////////////////////////////////////////////////////////////// ;;; // FMem Configuration: ;;; // ;;; // The SelfTest Uses This Information to Determine Fast Memory Test Range ;.define fmem_2_bank ;.define fmem_512k_bank ; 2 Fmem Banks Populated ; 1 Bank = 512KBytes ;;; ///////////////////////////////////////////////////////////////////////////////////// ;;; // Port1 Memory Configuration: ;;; // ;;; // The SelfTest Uses This Information to Determine Port1 Burst Memory Test Range #define port1_adrs_start 0000100xh #define port1_adrs_end 0200000xh ;;; ///////////////////////////////////////////////////////////////////////////////////// ;;; // Port2 Memory Configuration: ;;; // ;;; // The SelfTest Uses This Information to Determine Port1 Burst Memory Test Range #define port2_adrs_start 0000000xh #define port2_adrs_end 080000xh ;;; ///////////////////////////////////////////////////////////////////////////////////// ;;; Hardware Register Initialization ;;; ///////////////////////////////////////////////////////////////////////////////////// #define #m10_r32_init0x0000 #define #m10_r33_init0xffff #define #m10_r34_init0xff00 #define #m10_r35_init0x0040 ;;; ///////////////////////////////////////////////////////////////// ;;; R36 is a Bit-Bucket... ;;; ///////////////////////////////////////////////////////////////// #define #m10_r36_init 0x0000 #define #m10_r37_init0x0000 #define #m10_r38_init0x0000#define #m10_r39_init0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; Comm Registers are Not Manipulated by the Initialization Sequeunce. ;;; ///////////////////////////////////////////////////////////////// ;#define #m10_r40_init ;#define #m10_r41_init ;;; ///////////////////////////////////////////////////////////////// ;;; r42 is a set/clear register. Bits 2=3=0, Bits4,5,6,7 Are Only ;;; Programmed by the Hardware Configuration Register, and Ignored Below. ;;; ///////////////////////////////////////////////////////////////// Maker Communications, Inc. Company Confidential Page 21 MXT3010 Universal Boot Format Creating UBF Files #define #m10_r42_init0x0000 #define #m10_r43_init 0x0000 #define #m10_r44_init 0x0000 #define #m10_r45_init 0x0000 #define #m10_r46_init 0x0000 #define #m10_r47_init 0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; Initializes all Entries in the UTX Ctrl Fifo to the Following Value. ;;; ///////////////////////////////////////////////////////////////// #define #m10_r48_init0x0000 #define #m10_r49_init0x0000 #define #m10_r50_init0x0000 #define #m10_r51_init0x0000 #define #m10_r52_init0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; This Register is not written since it is required by the Initialization. ;#define #m10_r53_init0x0000 #define #m10_r54_init0x0000 #define #m10_r55_init0x0000 #define #m10_r56_init0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; r57 is a set/clear register. Bits 2=3=0, Bits4,5,6,7 Are Only ;;; Programmed by the Hardware Configuration Register. ;;; ///////////////////////////////////////////////////////////////// #define #m10_r57_init0x0000 #define #m10_r58_init0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; R59: This Register is not written since it is required by the ;;; Initialization Routine. ;;; ///////////////////////////////////////////////////////////////// #define #m10_r60_init0x0000 ;;; ///////////////////////////////////////////////////////////////// ;;; R61: Read Only Register... ;;; ///////////////////////////////////////////////////////////////// ;;; ///////////////////////////////////////////////////////////////// ;;; Should Not Allow the Utopia Tx/Rx to Come out of Reset, since ;;; phy devices are not likely to be properly initialized. ;;; Bits 3:1 Rx Cell Count == 0 ;;; Bits 6:4 Rx Cell Count == 0 ;;; ///////////////////////////////////////////////////////////////// #define #m10_r62_init 0x4181 #define #m10_r63_init 0x0000 Maker Communications, Inc. Company Confidential Page 22 MXT3010 Universal Boot Format Creating UBF Files ;;; ///////////////////////////////////////////////////////////////////////////////////// ;;; TEST NUMBERS: ;;; ;;; These Numbers are HardCoded and Should Not be Modified!! The Are included in this ;;; File for Documentation Purposes. ;;; ///////////////////////////////////////////////////////////////////////////////////// #define minmax_test_testno0000xh #define cbr_adrs_data_testno0001xh #define cbr_pattern_testno0002xh #define psb_adrs_data_testno0003xh #define psb_pattern_testno0004xh #define fmem_walk_data_bank0_testno0010xh #define fmem_walk_data_bank1_testno0011xh #define fmem_bank_sso_testno0012xh #define fmem_adrs_data_testno0013xh #define ssb_size_testno0020xh #define css_testno 0021xh #define port1_walk_data_testno0030xh #define port1_adrs_data_testno0031xh #define port1_block_testno0032xh #define port2_walk_data_testno0040xh #define port2_adrs_data_testno0041xh #defne port2_block_testno0042xh Maker Communications, Inc. Company Confidential Page 23 MXT3010 Universal Boot Format Maker Communications, Inc. Creating UBF Files Company Confidential Page 24