Browse Prior Art Database

Virtual MBR on a flash device

IP.com Disclosure Number: IPCOM000178016D
Original Publication Date: 2009-Jan-13
Included in the Prior Art Database: 2009-Jan-13
Document File: 3 page(s) / 29K

Publishing Venue

IBM

Abstract

Include support in Flash controller chips to allow the system firmware (e.g. BIOS) to switch the active partition without rewriting the Master Boot Record

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Virtual MBR on a flash device

Systems are beginning to embed solid state (Flash) HDDs as a way to ship embedded bootable software preloaded with the system. Examples include embedded hypervisors such as VMWare ESXi and embedded diagnostics (Dynamic System Analysis).

    If you want to include multiple software applications on flash in a system, there are a few ways you can accomplish that:

Include multiple flash devices

This provides maximal separation of the software applications (so that there are not interactions or incompatibilities between the different applications), but has a higher bill of materials cost, and consumes greater space on the planar.

Include all the software on 1 flash

This has the advantage of a lower parts cost, but has a drawback similar to trying to include multiple operating systems on a single HDD. You can try including all of the software on 1 HDD partition, but sometimes that's difficult or impossible (for example, if the applications need to be stored using different file systems). You can put each piece of software into a separate partition, but then a boot loader menu program is needed (e.g. LILO or GRUB) OR some other piece of software (e.g. BIOS) needs to write the Master Boot Record (MBR) sector on the HDD to activate the correct partition every time the system needs to switch to another application. Using a boot loader has two drawbacks: 1) not all bootable applications are compatible with boot loaders, and 2) the system BIOS wouldn't be able to select which tool/application to boot from the flash device (e.g. the hypervisor might be the default boot, but when the system detects a problem during POST, it might want to load diagnostics instead). Having the BIOS rewrite the MBR sector would allow BIOS to select which application to run, but is problematic with Flash memory because Flash has a limited number of write cycles. It also increases the exposure to failures. If the MBR sector of a flash drive is corrupt, the device will not boot; every time you write the MBR you have the possibility that something will go wrong and the sector will be corrupted.

Solution to described problem:


Usually, a NAND flash chip is connected to a system through a limited function controller chip, as illustrated in the figure. The controller chip presents a USB Mass-storage device interface to the system, and handles the erasing, flashing, remapping bad blocks, wear leveling, etc. needed by the NAND flash chips. The controller has a small CPU and a limited amount of RAM built into it.

1

Page 2 of 3

USB

The solution is to create a command that can be sent to the controller chip to tell it which partition the system wishes to boot from. The controller chip stores the partition number in its RAM. When the system reads the MBR sector from the device (through ordinary stan...