Browse Prior Art Database

Remote first fetch with flash recovery, ROM PFA, and dynamic updates

IP.com Disclosure Number: IPCOM000032792D
Original Publication Date: 2004-Nov-12
Included in the Prior Art Database: 2004-Nov-12
Document File: 3 page(s) / 28K

Publishing Venue

IBM

Abstract

Today we have no good solution to distribute flash images (or other updates), diags or other distributed functions from many (sources) to or from many (destinations). We also have issues where a boot image gets corrupt that can render the system unusable.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 3

Remote first fetch with flash recovery, ROM PFA, and dynamic updates

    Remove flash from main system and place off the system management device which has access to other I/O such as a network. Also this design intercepts power button and the ACPI shut down event from the system/OS. This prevents someone from pushing the power button or holding down the power off for s forced shutdown, during a system critical update.

This allows: Saving cost of flash memory
Flash updates to all systems at once
Verification of Flash/ROM area
Remote boot or retrieval of boot image from remote i/o and updated Single location for all boot images for multiple systems System to encapsulate to any device for system boot (USB key, firewire, etc) - This could allow you to have a temp boot device - Boot advanced diags - Boot a temp build that may set registers or could cause the system in a unstable state this would allow you to boot to a temp image and do the test before you build it in the

real image

No sideband signals needed to do and will use existing hardware.

 ACPI/button interception allows not only a safer system update, but also allow synchronized power cycling

Other usages:

In a blade center you could do real time diags or stand alone diags.

You could load to the local flash or redirect to the MM and run them from the MM
(i.e MM looks at key items during the test run to see what is going on) that way you can remotely figure out what happens if you fail and the MM can insure that all diags are up to date or take remote action

    On a stand alone you could do a virtual floppy from the MM or remotely boot and run or again do real time diags
Both can allow complete eco testing (would enable certification testing on blades and other systems)

    The two examples below show how this could be implemented. Both show a pull method, but you could use a push method by using a controller that could push images, diags, etc... based on certain conditions like: blue screen or kernel panic could cause a remote diag session, A new images for a system could be pushed to the system for the next boot, were it is not pulled from the remote system this could be done using multi-cast, uni-cast, etc. If it is in an enclosed system you could do this over an interconnected I/O or proprietary I/O.

Network boot:

    This invention consists of a computer system with a BMC connected to a bus that carries default ROM cycles. A flash memory (or other storage media) is connected to the BMC. The BMC is capable of communicating on a management network and the system I/O buses. (Figure 1)

1

Page 2 of 3

    System flash typically resides on an XBus or LPC bus connected to the system South Bridge. The South Bridge decodes the ROM cycles off the PCI bus (or in some cases the LPC bus is connected to the North Bridge (or root hub), and the North Bridge decodes the ROM cycles directly from the processor bus). The BMC that is connected to the LPC bus decodes these default ROM cycles and inserts wait states on...