…and it is even FAST!

hardware support: 250 mainboards supported in 2012!

Chromebook (IvyBridge / Thinkpad X60 / Thinkpad T 60

It comes with OpenBoot = also good and a direct rival to Intel’s EFI adoption. (checkout: https://www.coreboot.org/, coreboot interview: why coreboot?)

https://github.com/openbios

“Open Firmware may be accessed through its Forth language shell interface. It achieves essentially the same functionality as the later EFI standard initiated at Intel, with lower overhead.”

Berlin based BIOS Flashing service: http://www.zerocat.org/

https://www.heise.de/make/meldung/Zerocat-Open-Hardware-bis-zum-Chip-3728922.html

coreboot demonstration:

Getting started

coreboot provides a fast, reliable, secure, and predictable boot-firmware solution for numerous modern and legacy chipsets. There are millions of devices running coreboot, including Google Chromebooks and Chromeboxes, and it runs in many datacenters. In 2016, coreboot.org has over 300 active developers, and roughly 60000 lines of code are added each quarter.

Advantages

Using coreboot has numerous advantages for an OEM/ODM. coreboot comes with SoC support available to all developers. You share your codebase with other companies which are helping improving the SoC and driver-specific implementations. But there are also other reasons to use coreboot as your standard firmware.

Extremely fast

  • coreboot is designed to do the minimum amount necessary and get out of the way.
  • Especially for servers, coreboot provides faster boot up.
  • Desktop and Notebooks boot up in 400ms – 2.5s.
  • Server boot time can be as low as a quarter of the OEM BIOS boot time.

Flexible and customizable

  • Because coreboot does hardware init, then jumps to a payload to continue, it is very flexible.
  • Payload support for everything which is a ELF binary. Feel free to ship your own payload !
  • GPLv2 licensed core. Payloads can be proprietary and we offer a BSD licensed support library.
  • coreboot provides ready-to-build payloads like UEFI, SeaBIOS, U-Boot, Grub2 and many more..

Made with safety in mind

  • Recovery Mode based on multiple copies of the firmware which can be updated independently.
  • Integrity of stages and binaries in coreboot can be easily verified.

Designed for security by default

  • Uses a minimal trusted computing base for each platform which is easily auditable, helping to guarantee security.
  • As coreboot is Open Source, anyone can check the codebase.
  • On blob-free platforms, coreboot provides completely auditable boot firmware.
  • After it has completed initialization, more than 99% of the code is removed from memory.
  • Platform security features are supported like IOMMU, flash protections, TEE and more..
  • coreboot comes with Secure Boot support called VBOOT2.

Debugging done easily

  • There are multiple ways to extract the boot log, from classic serial to EHCI debug, even over the pc-speaker.
  • Using the partner-project Serialice, software debug is available from just after the reset vector.
  • GDB Stub support via serial.
  • In memory console log support
  • Tracing functions and other exotic features are supported as well.

Saves costs and time

  • Unlike UEFI EDK2, it includes full platform support for different architectures and SoC vendors.
  • Unlike U-Boot, coreboot strongly encourages a single source tree model,
    making it easier to adapt feature development to different boards and chipsets.
  • X86, ARM/64, MIPS, POWER8 and RISC-V are supported architectures.
  • It works with operating systems like Windows, OS X, Linux and Android out of the box.
  • Supported and maintained code for Intel FSP and AMD AGESA platforms.
  • Porting new hardware on an existing chipset to coreboot can done extremely quickly, usually within 1 week.

Quality assurance

  • All changes to the code are peer reviewed, to maintain code quality. Additionally, changes are build and run tested.
  • There are test frameworks like REACTS or LAVA to hook up your device and perform automated testing.

Need help with coreboot?

If you do not employ your own firmware engineers, you can contact one of our many licensed coreboot contractors. Additional help is available through the extensive documentation on coreboot processes and an active online community, both in IRC and on the mailing list.

src: https://www.coreboot.org/vendors.html

sun:

what follows is a backup of the article on Sun’s OpenBoot: http://sunsite.uakom.sk/sunworldonline/swol-10-1995/swol-10-openboot.html

Questions and answers on OpenBoot

Bookmark this so the next time you need to diagnose a pesky hardware problem this information will be at hand

By Steve Leung
SunWorld
October 1995
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!

Abstract

OpenBoot — the firmware in the Sun boot PROM — is an obscure component of any workstation, but it turns out to be pretty important, with some interesting features. Solaris expert Steve Leung of Amdahl uses a Q&A format to reveal the dark magic of an oft-overlooked system every administrator can use. You may not need this information today, but add it to your bookmarks so that the next time you need to diagnose a pesky hardware problem this information’s at hand. (4,500 words)



Mail this
article to
a friend

Contents

Q: What is OpenBoot?
When you turn on a Sun workstation, the firmware in the boot PROM (programmable read-only memory) is executed immediately. The main function of a boot PROM is to load a standalone program to the core memory and start its execution. Standalone programs can be operating systems, diagnostic software, and others. The firmware in Sun’s boot PROM is called OpenBoot. Other than initial program loading and invocation, OpenBoot provides debugging features to assist kernel debugging and board bring-up.

Q: What is the main advantage of OpenBoot?

Sun offers many different machine architectures (e.g., sun4d, sun4m, etc.) and boot devices (e.g., different types of disks). Instead of having different versions of the boot PROM firmware to support all combinations, OpenBoot supports plug-in device drivers. The drivers are written in a dialect of the interpreted language Forth (OpenBoot implements a Forth interpreter). The code for the driver may reside on the device PROM itself or in empty space on the system board PROM. This plug-in feature allows Sun or any third party vendors to develop new boot devices but without recompiling or relinking the boot PROM.

Another nice thing about OpenBoot is that it behaves the same across platforms. The newer revisions provide new commands, but generally OpenBoot is stable. Sun hasn’t released a major revision in more than a year.

Q: Why do application developers need to care about OpenBoot?

When the network connected to your workstation is down, and you have nothing else to do, you can always go to OpenBoot to write a Forth program to entertain yourself for a few hours. Besides that, there are many practical things you can do with OpenBoot, such as security and device diagnostics.


Q: How do I access OpenBoot?

Pressing the keys L1 and A at the same time will bring you to the OpenBoot system. You will see the display

Type b (boot), c (continued), or n (new command mode)
>

You are now interacting with the restricted monitor that allows you to do three things. Typing b boots a standalone program (most likely the operating system). Typing c resumes the execution of a halted program. Typing n gets you to the Forth monitor, and the prompt will change to ok. Most of the Forth language syntax is accepted at the Forth monitor, a.k.a., the ok prompt.

ok

Now you are ready and able to do many interesting things. To continue executing (e.g., return to the OS), type

ok go

Q: What is Forth doing in OpenBoot?

OpenBoot contains a command interpreter (something like the shell). Instead of providing a new command language syntax, it incorporates a dialect of the programming language Forth. Forth is a popular language used in many embedded systems. Because the language is simple and its interpreter small, Forth systems take up very little space. They fit perfectly into PROM.

Q: What does a Forth program look like?

Forth programming is interactive, much like BASIC programming. You see the result immediately. Forth commands are also called words. In addition to accepting arguments, Forth words rely heavily on values in the Forth stack, which is a last-in, first-out (LIFO) buffer for temporarily holding information. The word showstack shows the current content of the stack. Forth uses postfix notation rather than infix. For example, in Forth, you write “3 4 +” instead of “3 + 4”.

You can define your own Forth word. The syntax is weird. A colon starts the definition, and semicolon ends it. (There is a space between the colon and the name of the word.)

In the following example, we define a new Forth word double, which doubles the value of the top stack item. dup and + are built-in Forth words. dup duplicates the top stack item. + adds the topmost two stack items and pushes the result on top of the stack. The built-in command . (yes, it’s a period) pops the top stack item and displays it. You can see the source code of any Forth word by the command see.

ok : double dup + . ;

ok 4 double

8

ok see double

: double dup + . ;

Q: How do I change the OpenBoot settings?

There are OpenBoot configuration parameters that you can set. They are stored in the non-volatile RAM (NVRAM) that keeps the values of the parameters even after a power cycle. To display all current values, type

ok printenv

To display just the current value of a named parameter, type

ok printenv parameter

where parameter is the name of the object you want to see.

To set the named parameter to the given value, type

ok setenv parameter value

To reset all parameters or the named parameter to the factory default, type

ok set-defaults

or

ok set-default parameter

to reset just one specific parameter.

Some of the valid parameters are boot-device, boot-file, screen-#columns, screen-#rows, and security-mode.

Q: How do I stop people from rebooting my workstation?
OpenBoot can provide security on reboot. Security parameters control what actions users can perform in OpenBoot. Remember, users interact with OpenBoot through either the restricted monitor or the Forth Monitor. Security parameter security-mode places restrictions on how the boot process works. The default value of security-mode is none; therefore, anybody can reboot the machine. With security-mode set to command, a password is required to boot with parameters (the b command), or execute the n command in the restricted monitor. This prevents illegal users executing illegal programs. For example,

>b stand_alone_program_virus
PROM Password:

>n
PROM Password:

For the examples above, a password is required for both the command b and n, and is not echoed as it is typed. Note: A password is not required to reboot with default parameters. If you set security-mode to full, then a password is required to perform any kind of reboot. For example,

>b
PROM Password:

You can set the password with the command password in the Forth monitor. For example,

ok password
New Password (only first 8 chars are used);
Retype new password:

You can reset security back to none by issuing the command setenv security-mode none.

One thing you have to remember — if you enable the password and forget it, you will have to call Sun’s support to remove the password and make your machine bootable again.

Q: How do I change the Power-on
Banner?

First, you can display the system banner by executing the command banner. It displays Sun’s power-on logo and message. To let the OEM partners have a little bit of freedom, Sun (or OpenBoot) lets you set your own power-on logo and message. For example, type

ok setenv oem-banner power-on-message

ok setenv oem-banner? True

This will set your own power-on message. To set the power-on logo, you do the same thing with the parameters oem-logo and oem-logo?. However it is a little bit more complicated to set oem-logo, since a logo is a bit-mapped icon. It is better to do this with OS utility eeprom. eeprom can be used to access OpenBoot settings. First, at the OS level, run iconedit to create the power-on icon, then use eeprom to convert the icon to the internal format oem-logo uses.

Q: How do I boot a different
kernel?

At the Forth monitor, the command to boot a standalone program (e.g., OS kernel) is :

ok boot [boot-device] [stand-alone-program] [flag(s)-for-the-stand-alone-program]

If you execute boot without any arguments, defaults are used. The defaults are stored in the configuration parameters boot-device and boot-file. To display their contents, type

ok printenv boot-device
boot-device disk0 disk

ok printenv bootfile
boot-file

In the above example, current and default values of boot-device are disk0 and disk. And the values of boot-file are empty strings. disk0 and disk are device aliases. To see the real device, type

ok devalias disk0
disk0 /sbus/esp@0,800000/sd@3,0

As you can see from the output, disk0 is a SCSI disk sd. An empty string in boot-file means to let the secondary booter choose the default, usually kernel/unix. The commands devalias and printenv with no argument list all the device aliases and NVRAMRC configuration parameters in the OpenBoot firmware, respectively.

Q: What exactly happens during the boot process?
A lot. First, at the Forth monitor, the command boot locates the boot device. boot loads the fixed-size block bootblock from a fixed location in the boot device. Second, bootblock loads the secondary booter from the device. The location of the secondary booter is recorded in the bootblock. bootblock is prepared by the Solaris utility installboot. If the boot device is a UFS file system, the secondary booter is ufsboot. Third, the secondary booter locates and loads the standalone program. If the name of the standalone program was not specified in boot, ufsboot loads its default kernel/unix. At last the standalone program is executed. A different secondary booter is needed for each different type of file system installed in the boot device. This is because the secondary booter needs to understand the protocol of that particular file system in order to locate and load the standalone program. For example, if you specify the standalone program as /home/mary/test/version10/kernel/unix, the secondary booter has to be able to locate the file from the file system in the boot device.

Q: Can I boot from any
device? Officially, Sun only supports booting from a hard disk, CD-ROM, floppy disk, and Ethernet. A floppy disk typically does not have the capacity to boot a kernel, given their usual size. However you can use it to boot other standalone programs (assuming that they would fit in a single floppy disk). When booting from the network, OpenBoot broadcasts a reverse ARP request to the network, and a boot server will reply. Then OpenBoot establishes a TFTP connection to the boot server to retrieve the secondary booter inetboot. inetboot uses the bootparams protocol to obtain the root file system, and then it uses the NFS protocol to fetch the kernel over the Ethernet. The boot server needs to set up its boot parameter database properly in order for this boot process to work.

Q: What are the option parameters available in booting Solaris kernels?
A Solaris kernel takes a few standard flags at the Forth monitor. They are

ok boot kernel/unix [-a | -r | -s | -v ]

-a asks you interactively for configuration information. You use this flag if you want to specify a different system configuration file (not /etc/system), a different root file system, a different search path for dynamic load modules (DLMs), etc.

-r reconfigures your device tree at both /dev and /devices. You would boot the kernel with this flag on after you add a new device to the system. The system probes all attached hardware devices and rebuilds the device tree from scratch. -s boots the kernel to the single-user mode. Many times when you fail to complete a full kernel boot, you would prefer to at least boot to the single-user mode and then perform troubleshooting there.

-v turns on the verbose mode. This means system boot messages are not just going to the system log file (usually /var/adm/messages) but also simultaneously to the console display.

Q: What other standalone programs are
available for OpenBoot?

Ninety-nine percent of the time, the standalone program is the Solaris kernel. The rest of the time you probably run the kernel debugger kadb and some hardware diagnostic tools from the hardware vendors.

kadb is based on the debugger adb and includes many pre-defined macros which understand kernel data structures. Sorry, you cannot define your own macros. They are compiled together with kadb. The syntax to run kadb is

ok boot [boot-device] kadb [-d] [kernel-flags]

With -d, kadb prompts you for the kernel you want to debug; otherwise the default kernel/unix is used. Kernel flags are simply passed to the kernel by kadb.

Q: What is a device tree?
Sun hardware uses the concept of the device tree to organize devices attached to the system. To see the entire device tree, use show-devs.

ok show-devs
/io-unit@f,e1200000
/io-unit@f,e0200000
/mem-unit@f,e1100000
/mem-unit@f,e0100000
/cpu-unit@f,e1800000
/cpu-unit@f,e1000000
/cpu-unit@f,e0800000
/cpu-unit@f,e0000000
/boards
/openprom
/virtual-memory@0,0
/memory@0,0
/aliases
/options
/packages
/io-unit@f,e1200000/sbi@0,0
/io-unit@f,e1200000/sbi@0,0/SBUSDKHS@3,2000
/io-unit@f,e1200000/sbi@0,0/lebuffer@0,40000
/io-unit@f,e1200000/sbi@0,0/dma@0,81000
/io-unit@f,e1200000/sbi@0,0/lebuffer@0,40000/le@0,60000
/io-unit@f,e1200000/sbi@0,0/dma@0,81000/esp@0,80000

Each entry of the output represents a device. At the Solaris OS level, you can see the same tree under /devices. In addition, the Forth Monitor provides Unix-like commands to manipulate the devices. For example,

ok cd /io-unit@f,e0200000/sbi@0.0

The command cd makes the device /io-unit@f,e0200000/sbi@0.0 the current node.

ok ls
ffda2b3c qec@3,20000
ffda093c lebuffer@1,40000
ffd9baec dma@1,81000
ffd998ec lebuffer@0,40000
ffd946c4 dma@0,81000

The command ls lists the nodes under the current nodes. The second column of the output lists the names of the nodes. The first column lists the physical addresses associated with the nodes.

The command pwd displays the pathname of the current node.

ok pwd
/io-unit@f,e0200000/sbi@0,0

Q: How do I interpret a device
tree?

Each node in the device tree represents a device. Nodes with children usually represent buses and their associated controllers. Their children are devices connected to the buses or controllers.

A full device path begins with a /. It is the root of the tree and represents the machine node. Each node name has the form name@address:arguments. Other than name, the rest are optional and the format is device-dependent. If the system can identify the device without ambiguity, you can ignore that portion of the device path name. I usually write the complete path.

address represents a physical address associated with the device. arguments is used to pass additional information to the device’s software.

Let’s look at a simple example. The root file system of my IPX system is /dev/dsk/c0t3d0s0, which is equivalent to the device node

/sbus@1,f8000000/esp@0,800000/sd@3,0:a

Let’s see how we interpret the path. From sd@3,0:a, we know the device is a SCSI disk sd attached to the SCSI bus at target 3 and logical unit 0. The a at the end represents the first partition of the disk. From esp@0,800000, we know the SCSI bus is implemented as a SCSI host adapter esp residing in the SBus slot 0 at offset 800,000. Finally from sbus@1,f8000000, we know the SBus interface is attached to the system bus at address 1,f8000000.

Q: How do I create device
aliases?

As you can see, each device path is quite long. It would be nice to be able to make aliases for devices. OpenBoot provides the command devalias for this purpose.

ok devalias [alias]

The command devalias displays the current values of all device aliases (if no parameter is given) or the named alias.

ok devalias alias device-path

devalias with two arguments defines a device alias alias to the value device-path.

Q: What can I do with a device
node?

Each device node has attributes and methods associated with it. Use the Forth Monitor commands .attributes and words to display the values for the current node. For example,

ok cd /io-unit@f,e0200000/sbi@0,0/dma@0,81000/esp@0,80000/sd
ok .attributes
device_type              block
name                     sd
ok words
selftest      reset         load          write         read
seek          sd-selftest   close         open
write-blocks  read-blocks   dma-free      dma-alloc
max-transfer  block-size    spin-up

The above example shows a SCSI disk sd and it is a block device. Methods are provided to open, close, read and write the device. The cd command is needed to make the named device the current node. .attributes and words only work on the current node.

Q: How do I perform device
diagnostics?

There are a few commands that come very handy for device diagnostics. probe-scsi-all identifies all SCSI devices attached to the system.

(Note: probe-scsi-all is not supported until OpenBoot revision 2.6. The output of the command banner will indicate the current OpenBoot revision number for your machine.)

ok probe-scsi-all
/io-unit@f,e1200000/sbi@0,0/dma@0,81000/esp@0,80000
Target 0
Unit 0   Disk     CONNER  CP30548  SUN0535AEBX9308288P
Target 1
Unit 0   Disk     CONNER  CP30548  SUN0535AEBX93082PA7
Target 2
Unit 0   Disk     CONNER  CP30548  SUN0535AEBX9308280V
Target 3
Unit 0   Disk     CONNER  CP30548  SUN0535AEBX93082PMC

/io-unit@f,e0200000/sbi@0,0/dma@1,81000/esp@1,80000
Target 0
Unit 0   Disk     SEAGATE ST42400N SUN2.1G0417705457  Copyright (c)
1992 Seagate All rights reserved
ok

probe-scsi identifies SCSI devices attached to only the built-in SCSI bus.

ok probe-scsi
Target 0
Unit 0   Disk     SEAGATE ST31200N SUN1.05872200147810Copyright (c)
1994 Seaga
te All rights reserved 0000
Target 1
Unit 0   Disk     SEAGATE ST31200N SUN1.05872200137389Copyright (c)
1994 Seaga
te All rights reserved 0000
Target 2
Unit 0   Disk     SEAGATE ST31200N SUN1.05872200150421Copyright (c)
1994 Seaga
te All rights reserved 0000
Target 3
Unit 0   Disk     SEAGATE ST31200N SUN1.058722001494te All rights
reserved 000078Copyright (c) 1994 Seaga
te All rights reserved 0000
Target 5
Unit 0   Removable Tape     ARCHIVE Python 28454-XXX4ASB
Target 6
Unit 0   Removable Read Only device     SONY    CDU 561  SUNMSCD1.9k
ok

test executes the named device’s method selftest. In other words, if words lists the method, selftest, test will work.

ok  test /io-unit@f,e0200000/sbi@0,0
No selftest method for /io-unit@f,e0200000/sbi@0,0
ok test disk

In the example, the device /io-unit@f,e0200000/sbi@0,0 does not have the method selftest; therefore test would not work. The device disk has the method; therefore, test
works. If selftest succeeds, it outputs nothing.

test-all tests all the devices in the system.

ok test-all
Testing /memory@0,0

Testing /io-unit@f,e1200000/sbi@0,0/lebuffer@0,40000
Testing /io-unit@f,e1200000/sbi@0,0/lebuffer@0,40000/le@0,60000
Internal loopback test -- succeeded.
External loopback test -- succeeded.
Testing /io-unit@f,e1200000/sbi@0,0/dma@0,81000/esp@0,80000
Testing /io-unit@f,e0200000/sbi@0,0/qec@3,20000
Testing /io-unit@f,e0200000/sbi@0,0/lebuffer@1,40000
Testing /io-unit@f,e0200000/sbi@0,0/lebuffer@0,40000
Testing /io-unit@f,e0200000/sbi@0,0/qec@3,20000/qe@3,0
Internal loopback test -- succeeded.
Internal (including Mendec) loopback test -- succeeded.
Link state check --  failed, transceiver cable problem? or check the
hub.
Selftest failed. Return code = -1

watch-clock tests the clock function. The system responds by incrementing a number (starting at zero) by one each second.

ok watch-clock
Watching the 'seconds' register of the real time clock chip.
It should be 'ticking' once a second.
Type any key to stop.
49
ok

watch-net monitors the network traffic. It displays a dot (.) each time it receives a error-free packet. The external loopback test will fail if the system is not connected to Ethernet.

ok watch-net
Internal loopback test -- succeeded.
External loopback test -- succeeded.
Looking for Ethernet packets.
'.' is a good packet.  'X' is a bad packet.
Type any key to stop.
................................................................................
...................................
ok

show-bus displays all the installed and probed SBus devices.

ok show-sbus
Board# 0 SBus slot 0 lebuffer le dma esp
Board# 0 SBus slot 1 lebuffer le dma esp
Board# 0 SBus slot 2
Board# 0 SBus slot 3 qec qe qe qe qe
Board# 1 SBus slot 0 lebuffer le dma esp
Board# 1 SBus slot 1
Board# 1 SBus slot 2
Board# 1 SBus slot 3 SBUSDKHS
ok

Q: How do I make permanent changes in OpenBoot settings?
A portion of the NVRAM called NVRAMRC is reserved for storing user-defined commands and device aliases. User-defined commands are written in Forth. You can look at it as those Unix rc files in which commands are executed during start-up. Those commands are stored in ASCII text format. Almost all Forth monitor commands can be used. Exceptions are banner, boot, go, nvedit, password, reset, and setenv security-mode. Some useful commands to operate NVRAMRC are:

ok nvalias alias device-path

The effect of nvalias is to store the command “devalias alias device-path” in the NVRAMRC. Or you can use the NVRAMRC editor nvedit to directly edit the NVRAMRC buffer. nvedit has its own editing commands, a little bit like Emacs, e.g., CTRL-P to move forward one character and CTRL-B to move backward. nvedit only operates on a temporary buffer. To make permanent changes to NVRAMRC, execute the command nvstore after you quit nvedit. To test the changes in the buffer, try nvrun, which executes the contents of the temporary buffer. Also

ok nvunalias alias

deletes the named alias from NVRAMRC.

Q: How do I do program debugging with
OpenBoot?

OpenBoot provides register-display commands, breakpoint commands, a disassembler, and symbolic debugging ability. However they are intended for assisting device bring-up’s. They are not general-purpose facilities for the general public. For OS- and applications-level debugging, kadb is the preferred choice.

OpenBoot debugging commands normally display addresses in hexadecimal. However, if you load the standalone program through the command dload (which is another way to perform program loading in OpenBoot), OpenBoot will keep the symbol table information, and memory addresses are displayed symbolically whenever possible. The OS is usually not loaded with dload but through some intermediate booter (like the ufsboot used with boot); therefore symbol information included in the kernel’s a.out file is not available to the OpenBoot debugging facility. It is really not much use for the average users if the symbol information is not available.

Here are some useful commands if you have to debug at the OpenBoot level (for example, if kadb was not started at the boot time, and the system crashes):

.fregisters displays values in registers %f0 through %f31.

ok .fregisters
	0        1        2        3        4        5        6
	7
+0:        0        0 ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff
+8: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff
+16: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff
+24: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff
fsr:        0 fq:address:        0 fq:instruction:  81a00000

.registers displays values in registers %g0 through %g7, plus %pc, %npc, %psr, %y, %wim, %tbr.

ok .registers
%g0      %g1      %g2      %g3      %g4      %g5      %g6      %g7
0 e00511f0 e3781ec0 e0069fb8      570        0        1 e3781ec0
PC      nPC        Y      PSR      WIM      TBR
ffd72210 ffd72214        0 40400ce6       10 e0040050

.locals displays the values in %i, %L, and %o registers. In SPARC terminology, %i, %L, and %o are input, local and output registers respectively.

ok .locals
0        1        2        3        4        5        6        7
IN:         2 ffd418a0        e e01a54e2        0        1 e379fdb0
e006ca04
LOC: 40800cc6       f0 e006c518       40        0 e0069fb8        7
ffffffc0
OUT: e0040050 ffeff000        0  1f00506        0      f00 e379fd50
ffd418ac

%f0 and etc. return the value of the individual register respectively. The value is pushed onto the Forth monitor stack. The command . is used to pop the value off the stack and display it.

ok %g1 .
e00511f0
ok %pc .
ffd72210

w sets the current active window for displaying %i, %L, and %o registers. By changing the current register window, you can examine different set of local registers. SPARC has the concept of register sliding windows. Each window has its own set of local resisters for faster context switch. 1 w .locals advances one window and executes .locals.

ok 1 w .locals
IN:    2e0000       6e   2e0000        4        1       6e e379fe10
e004c878
LOC:       60 e00e48a0        f       10        1 e01b88c8        1
e01c4f10
OUT:        2 ffd418a0        e e01a54e2        0        1 e379fdb0
e006ca04

ctrace displays the return stack showing C functions.

ok ctrace
PC: ffd72210
Last leaf: call ffd721ec    from ffd418ac
0 w  %o0-%o5: ( e0040050 ffeff000        0  1f00506        0      f00 )

jmpl  ffd418a0    from e006ca04
1 w  %o0-%o5: (        2 ffd418a0 e01b8800        f        c        1 )

call e006c9a4    from e004c878
2 w  %o0-%o5: (   2e0000       63   2e0000 e01b88dc        c       63 )

call e004c764    from e004c748
3 w  %o0-%o5: (        0   740000       74        0 e01c497c e01c497c )

ok

dis starts disassembling at the given address. +dis continues disassembling where the last disassembly left off. In the following example, it starts the disassembling at the current program counter. The command %pc places the current value of the program counter on the Forth monitor stack. dis pops the value off the top of the stack and takes it as the argument.

ok %pc
ok dis
ffd72210     ta      %g0, 7f
ffd72214     wrtbr   %o0, 0
ffd72218     sethi   0, %g0
ffd7221c     sethi   0, %g0
ffd72220     sethi   0, %g0
ffd72224     jmp     %o7, 8, %g0
ffd72228     sethi   0, %g0
ok +dis
ffd7222c     call    ffd48ecc
ffd72230     sub     %g7, 4, %g7
ok

Q: At OpenBoot, can I mount file systems and
access files?

No, in practice you cannot. OpenBoot understands neither Solaris file systems nor files. It is a very primitive system that mainly deals with hardware devices and not high-level objects like file systems and files. But yes, theoretically, you can. You can write a Forth program to interface with the methods of a device like a hard disk. For example a hard disk device would have the methods to read and write disk blocks. You can then map the file system related data structures to the disk blocks and locate the individual files. The whole process is definitely not trivial.

Q: How do I reset reboot the
system?

ok reset

The command reset resets the complete system and is similar to a power cycle. It initializes the memory to zeros. If auto-boot? is set to true, the system will also re-boot. Alternately you can use the command sync to reboot the system. sync synchronizes all the mounted file systems and flushes out all the dirty pages to the disks before the reboot.

ok sync

The command sync returns to the OS which then synchronizes (sync) all the mounted file systems, and saves a core image of the kernel. You can hit L1-A to stop the core dump. Sync always reboots the machine automatically at the end.

Q: Where can I find more literature on
OpenBoot and related topics?

At the Forth Monitor, you can type help to get more information. In addition each command is a Forth word, and you can type see command to view the Forth source code for a particular command.

There are also manual pages. Try man pages: monitor(1M), boot(1M), eeprom(1M), kernel(1M), kadb(1M), iconedit(1), system(4), installboot(1M).

There are reference manuals and users’ guides too. Try Writing FCode Programs, by Sun Microsystems, published by SunSoft Press, 1994, ISBN 0-13-107236-6. Details and ordering info on this book are available at http://www.sun.com/smi/ssoftpress/books/WritingFCode/WritingFCode.html.

To learn more on Forth 83 programming, read: Starting Forth, second edition by Leo Brodie, Prentice-Hall.

 

 


Click on our Sponsors to help Support SunWorld

About the author
Steve Leung (SSL20@amdahl.com) is a senior software engineer at Amdahl Corp., Sunnyvale, CA. He works on the Amdahl A+ edition of Solaris and on UTS (Amdahl’s version of Unix SVR4 on S/390 mainframes).

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin