Flash ROM programming

A method comprises providing a golden ROM unit comprising known good ROM code. The golden ROM is coupled to a ROM socket of a target system. The target system is booted, wherein booting comprises providing power to the target system and independently providing power to the ROM socket. The known good ROM code is loaded from the golden ROM to a system memory of the target system. Power is removed from the ROM socket and the golden ROM is decoupled from the ROM socket. A first subject ROM is coupled to the ROM socket. Power is provided to the ROM socket and the first subject ROM is programmed with the known good ROM code.

TECHNICAL FIELD

The present invention relates generally to the field of computer architecture and ROM programming and, more particularly, to a system and method for improved flash ROM programming.

BACKGROUND OF THE INVENTION

Modern electronic computing systems, such as microprocessor systems, often include a system board and a flash ROM (read-only memory). In many cases, the flash ROM contains the bootstrapping machine instructions. An issue frequently encountered in early system and software development is the need to reprogram a flash ROM if, for example, the ROM has been corrupted, has a code bug blocking execution, or a new device must be flashed. The traditional approach to this issue is to have a stand-alone flash programmer available to initially program the flash ROM.

For example, referring toFIG. 1, system100is an exemplary flash ROM programming system in accordance with the Prior Art. A flash programmer110couples to a system120. Flash programmer110is a stand-alone system and has a database112and an interface114. Database112is a database of various flash packages and ROM code varying systems120. System120has a system power122, a flash ROM124, and an interface126. Where ROM124is corrupted or blank, flash programmer110copies the flash code from database112to ROM124through a connection between interface114and interface126. When system120powers on, ROM124executes the bootstrap code and system120operates accordingly.

One skilled in the art will understand that flash programmer110is relatively expensive and slow, and must support the various Flash packages used by the various systems120. As such, Industry developed other flash programming systems to support a scan-based flash methodology, but these other systems also require additional hardware and code to implement, which increases the system cost.

BRIEF SUMMARY

A method comprises providing a golden ROM unit comprising known good ROM code. The golden ROM is coupled to a ROM socket of a target system. The target system is booted, wherein booting comprises providing power to the target system and independently providing power to the ROM socket. The known good ROM code is loaded from the golden ROM to a system memory of the target system. Power is removed from the ROM socket and the golden ROM is decoupled from the ROM socket. A first subject ROM is coupled to the ROM socket. Power is provided to the ROM socket and the first subject ROM is programmed with the known good ROM code.

In an alternate embodiment, a system comprises a board and a memory coupled to the board. A system power module couples to the board and is configured to control power to the board. A ROM socket couples to the board and is configured to receive a ROM unit. A socket power module couples to the board and is configured to control power to the ROM socket. The ROM socket is further configured to receive a golden ROM unit comprising known good ROM code and to copy the good ROM code to the memory. The ROM socket is further configured to receive a subject ROM and to copy the good ROM code from the memory to the subject ROM.

DETAILED DESCRIPTION

Referring now to the drawings,FIG. 2is a high-level block diagram illustrating certain components of a system200for improved flash ROM programming. System200comprises a “golden ROM”210and a target system220.

Generally, golden ROM210is an otherwise conventional flash ROM, known to operate as intended and configured with a known good ROM code. In one embodiment, golden ROM210is configured to function as a system bootstrap ROM for target system220. As described in more detail below, golden ROM210is configured to couple to target system220through an otherwise conventional ROM socket.

In one embodiment, known good ROM code is computer code known to operate as intended. In one embodiment, golden ROM210comprises the known good ROM code. In an alternate embodiment, golden ROM210comprises code configured to initiate a sequence wherein CPU224obtains good ROM code from a network device, or a storage device such as a USB device, and copies the good ROM code to memory226.

Target system220includes a plurality of elements mounted on a board222. Generally, board222is an otherwise conventional printed circuit board, modified as described herein. Generally, all other elements of target system220couple directly to board222, except as noted below. As shown, target system220includes a control processing unit (CPU)224and a memory226. CPU224is an otherwise conventional processing unit and memory226is an otherwise conventional memory.

Target system220also includes board power230. Board power230is an otherwise conventional power supply and is configured to provide power to, and remove power from, components of target system220. In one embodiment, board power230also provides power to socket power240. In an alternate embodiment, board power230does not provide power to socket power240.

Socket power240is an otherwise conventional power supply and is configured to provide power to, and remove power from, a ROM socket250. In one embodiment, power supply240is a jumper wire. In an alternate embodiment, power supply240is a field effect transistor (FET). In an alternate embodiment, power supply240is a relay configured to gate a power supply. As described above, in one embodiment, socket power240receives power from board power230. In an alternate embodiment, socket power240couples to an alternate power supply (not shown). Accordingly, in every embodiment, power supply240provides power to socket250independent of the other elements of target system220.

Socket250is an otherwise conventional flash ROM socket. As shown, socket250is configured to receive a flash ROM260and golden ROM210. In the illustrated embodiment, socket250receives only one flash ROM at a time.

In an exemplary operation, board power230removes or gates off power to board222and socket power240removes or gates off power to socket250. A user removes flash ROM260and couples golden ROM210to socket250. Target system220“boots”, in which target system220performs hardware startup actions including board power230providing power to board222and socket power240providing power to socket250.

System200copies the good ROM code from golden ROM210to memory226. In one embodiment, golden ROM210copies the good ROM code to memory226. In an alternate embodiment, golden ROM210initiates a startup sequence wherein CPU224copies the good ROM code to memory226. In an alternate embodiment, golden ROM210initiates a sequence wherein CPU224obtains good ROM code from a storage or network device and copies the good ROM code to memory226. In an alternate embodiment, golden ROM210initiates a sequence wherein CPU224obtains good ROM code from a storage or network device by coping into memory226ROM code to initiate the sequence.

Once memory226contains the good ROM code, socket power240removes power from the socket250. Once socket power240removes power from the socket250, a user can remove the ROM device from the socket to which the device couples. A user decouples golden ROM210and couples a subject flash ROM260to socket250. Generally, subject ROM260is a functional device lacking known good ROM code, or configured with faulty, corrupted, or otherwise bad ROM code.

Socket power240provides power to socket250and target system222programs the subject ROM260. In one embodiment, CPU224copies code from memory226to ROM260. In an alternate embodiment, CPU224executes a program in memory226that programs ROM260.

In one embodiment, ROM260is configured as a bootstrap ROM for target system220. In an alternate embodiment, ROM260is intended for use as a flash ROM in another system (not shown). In such cases, socket power240removes power from socket250and a user decouples ROM260. ROM260is then ready for use as a flash ROM in another system.

So configured, target system220can program a plurality of flash ROMs260, without requiring a reboot in between programming. Broadly, a target system board feature facilitates independent removal of the power supply to the flash ROM socket while the rest of the system remains powered and running. A user installs a single “golden” flash to boot the board to the point where in-situ flash programming can occur. The target system removes power from the socketed flash ROM and the user removes the golden ROM from the socket. The user repopulates the ROM socket with a blank or corrupted subject ROM, which the target system powers on independently. The target system updates the subject ROM with correct code, in one embodiment from a program running in system memory.

FIG. 3is a circuit diagram illustrating certain components of a system300for improved flash ROM programming. System300includes a socket310configured to couple to a ROM device312. Socket310couples to a power supply line320.

Power supply line320couples to a switch element330. In the illustrated embodiment, switch element330is an otherwise conventional FET. In an alternate embodiment, switch element330is an otherwise conventional jumper wire. In an alternate embodiment, switch element330is an otherwise conventional relay.

In the illustrated embodiment, switch element330couples to an otherwise conventional power supply340and an otherwise conventional resistor342. Resistor342which couples to another otherwise conventional power supply344. As shown, switch element330is activated by power control signal350.

In one embodiment power control signal350is a power signal configured to provide or remove power to socket310. In one embodiment, a logic high power control signal350closes switch element330, coupling socket310to power supply340, thereby providing power to socket310. In one embodiment, a logic low power control signal350opens switch element330, decoupling socket310from power supply340, thereby removing power from socket310. In one embodiment, system300ejects ROM device312by pulling power control signal350low.

FIG. 4illustrates one embodiment of a method for flash ROM programming. Specifically,FIG. 4illustrates a high-level flow chart400that depicts logical operational steps performed by, for example, system200ofFIG. 2, which may be implemented in accordance with a preferred embodiment. Generally, target system220performs the steps of the method, unless indicated otherwise.

As indicated at block405, the process begins, wherein a user generates or configures a golden ROM with known good ROM code. Next, as illustrated at block410, a user couples the golden ROM to a ROM socket of a target system. Next, as illustrated at block410, the target system boots. As described above, in one embodiment, the target system provides power independently to the ROM socket and to other system components.

Next, as illustrated at block420, the target system loads known good ROM code from the golden ROM to a memory of the target system. Next, as illustrated at block425, the target system removes power from the ROM socket. In one embodiment, the target system also pulls a power signal low. Next, as illustrated at block430a user decouples the golden ROM from the ROM socket.

Next, as illustrated at block435, a user couples a subject ROM to the ROM socket. Next, as illustrated at block440, the target system provides power to the ROM socket. In one embodiment, the target system also pulls a power signal high. Next, as illustrated at block445, the target system loads known good ROM code to the subject ROM. As such, the subject ROM is programmed with known good ROM code and can be used in another system.

Next, as illustrated at block450, the target system pulls the power signal low and removes power from the ROM socket. Next, as illustrated at decisional block455, the system determines whether there are more subject ROM devices for programming. If there are additional subject ROM devices for programming, the process continues along the YES branch, returning to block430, wherein the user decouples the current subject ROM and the process continues as described above. If there are no additional subject ROM devices for programming, the process continues along the NO branch, and the process ends.

Accordingly, the disclosed embodiments provide numerous advantages over other methods and systems. For example, the disclosed embodiments can be configured to reprogram multiple ROM units. Further, the disclosed embodiments can be configured to reprogram multiple ROM units without requiring a system reboot in between programs. Additionally, the disclosed embodiments can be configured to repair or reprogram multiple ROM units without requiring a special stand-alone programming system. Other technical advantages will be apparent to one skilled in the relevant arts.