Copyright (c) Hyperion Entertainment and contributors.

Difference between revisions of "UserDoc:BIOS"

From AmigaOS Documentation Wiki
Jump to navigation Jump to search
Line 164: Line 164:
 
Onboard VIA686B only - specifies the transfer mode that a1ide.device will use for each device.
 
Onboard VIA686B only - specifies the transfer mode that a1ide.device will use for each device.
 
If you specify an unsupported mode, it will use the best mode the drive claims to support.
 
If you specify an unsupported mode, it will use the best mode the drive claims to support.
  +
|-
  +
| agp_enable
  +
|
  +
{| class="wikitable"
  +
| on || enables the AGP bus
  +
|-
  +
| off || disables the AGP bus
  +
|}
  +
|-
  +
| agp_sideband
  +
|
  +
{| class="wikitable"
  +
| on || enables sideband addressing on the AGP bus
  +
|-
  +
| off || disables sideband addressing on the AGP bus
  +
|}
  +
|-
  +
| agp_speed
  +
|
  +
{| class="wikitable"
  +
| 1x || 1X speed
  +
|-
  +
| 2x || 2X speed
  +
|}
  +
|-
  +
| autostart
  +
|
  +
{| class="wikitable"
  +
| yes || execute the kernel as soon as it has been loaded
  +
|-
  +
| no || do not execute the kernel after loading
  +
|}
 
|}
 
|}

Revision as of 20:13, 3 March 2014

When your Amiga computer system is powered on or reset, the BIOS or firmware's job is to initialize the hardware and to start the booting process of the operating system. It also enables you to define some settings that you may want to use either for the next boot or for every time you use your computer. There are two interface modes that can be used; a console mode and a graphical mode. If you are not an expert don't panic, because once you have setup some firmware variables, you'll use the console very rarely. Typically you will only use the graphic mode, i.e. the menus, which are easier to use. Your computer can boot in many different ways, depending how you setup your variables.

The firmware will generally not be updated very often. The reason for this is because the hardware itself is not changing. The firmware's job is to initialize the hardware to a pointer where the operating system can take over and nothing more.

The BIOS of a new generation Amiga computer will not be explained here as it depends on the hardware. Hence, it is the manufacturer's job to provide a manual describing how the BIOS works and which options you can select to operate the computer.

For now, there are:

  • Das U-Boot used on the Sam440, Sam460 and AmigaOne 500 products from ACube Systems. U-Boot was also used by Eyetech for their AmigaOne-XE and MicroA1-C products and various developer boards.
  • CFE used on the AmigaOne X1000 built by A-EON Technology.
  • Custom Open Firmware compliant firmware was used on the Pegasos2 made by Genesi.

Das U-Boot Environment Variables

Environment Variables are values that can be set during the boot process to control the behaviour of various pieces of software running on the computer. Some variables are shared by more than one process, while other are unique to a process, but there is no finite list of Environment Variables.

Displaying Environment Variables

To find out what Environment Variables are set on your machine type printenv at the U-Boot Console. The display will show each variable defined and its value, but it will NOT be alphabetically ordered as shown, and you will only be able to see the last 22 lines of the list.

In order to see the complete list, you must change the "stdout" environment variable from "vga" to "serial" and use a null modem cable from the serial port on the AmigaOne connected to the serial port of another computer running a serial comms program that can display the incoming data stream.

Alternatively, if you suspect a particular variable and want to check its contents, type printenv followed by the name of the variable, e.g.

]printenv autostart
autostart=yes

Listing Environment Variables

Once AmigaOS has been installed you can obtain a complete unsorted list by typing NVGetVar from a Shell to display all of the UBoot environment variables. Typing NVGetVar >RAM:varlist will output the list to a file on the RAM Disk which you can print off for reference if required.

Warning
The battery on the motherboards used to maintain these variables has a life of around 3 years and will need to be replaced periodically. If the battery dies, or when you remove it to replace it, you will lose all of the U-Boot environment variables, so it is important to keep an up-to-date listing handy in order that you can reconfigure your machine when the need arises.

Changing Environment Variables

If you find that an Environment Variable contains the wrong value, you can change it using the "setenv" command at the U-Boot console. For example, suppose you want to change the delay time for the U-Boot Initialisation Display, you simply enter a new value for the "bootdelay" variable, i.e.

]printenv bootdelay
bootdelay=10
]setenv bootdelay 3
]saveenv
]printenv bootdelay
bootdelay=3

Notice that the "=" sign is NOT used when specifying values for the setenv command. However, if the value contains any embedded blanks, the value must be enclosed within " marks.

Creating New Environment Variables

Anyone can create new variables for whatever they wish, and some people even create their own variables to save them having to key in repetitive commands each time, e.g.

]setenv lx "diskboot 500000 2:0 0; bootm"
]saveenv
]printenv lx
lx=diskboot 500000 2:0 0; bootm

In future, rather than having to type the full command to install Debian from CD-ROM, they can simply type "lx". Note how more than one command can be specified on the same line separated by a semi colon " ; ".

Resetting or Removing Environment Variables

If you want to reset or remove an Environment Variable simply leave off the value, e.g.

]setenv lx
]saveenv
]printenv lx
## Error: "lx" not defined

Understanding Environment Variables

It can be very useful to know what some of these variables are and what they contain, particularly when things don't behave as expected, so we have compiled a list of common environment variables that we know about with typical values to give you some idea where to look.

U-Boot Environment Variables
Variable Name Common Values and Description
a1ide_conf
(not set) scan IDE buses and auto-configure
4 chars - (primary master,primary slave,secondary master,secondary slave)
0 nothing
1 hard disk
2 dvd/cdrom reader/writer

Onboard VIA686B only - specifies the configuration that a1ide.device will use.

a1ide_irq
(not set) use IRQs
4 chars - (primary master,primary slave,secondary master,secondary slave)
1 use IRQs
any other value don't use IRQs

Onboard VIA686B only - specifies whether a1ide.device will use IRQs. Using interrupts relieves the CPU (PIO approx 20%, UDMA approx 95%). It also affects transfer speed (PIO 10-20% lower, UDMA 10-20% faster).

a1ide_maxbus
(not set) both IDE channels
0 no IDE channel at all
1 only primary IDE channe
2 both IDE channels

Onboard VIA686B only - specifies which IDE Buses a1ide.device will use.

a1ide_timeout
(not set) 20
1 - 30 specified timeout

Onboard VIA686B only - specifies the timeout interval in seconds for a1ide connected devices. The recommended ATA(PI) specification is 30 seconds.

a1ide_xfer
(not set) use best PIO mode
4 chars - (primary master,primary slave,secondary master,secondary slave)
0 Automatic (best PIO mode)
a PIO 0 (3 MB/s, modeid 8)
b PIO 1 (5 MB/s, modeid 9)
c PIO 2 (8 MB/s, modeid 10)
d PIO 3 (11 MB/s, modeid 11)
e PIO 4 (16 MB/s, modeid 12)
A UDMA 0 (16 MB/s, modeid 64)
B UDMA 1 (25 MB/s, modeid 65)
C UDMA 2 (33 MB/s, modeid 66)
D UDMA 3 (44 MB/s, modeid 67)
E UDMA 4 (66 MB/s, modeid 68)
F UDMA 5 (100 MB/s, modeid 69)

Onboard VIA686B only - specifies the transfer mode that a1ide.device will use for each device. If you specify an unsupported mode, it will use the best mode the drive claims to support.

agp_enable
on enables the AGP bus
off disables the AGP bus
agp_sideband
on enables sideband addressing on the AGP bus
off disables sideband addressing on the AGP bus
agp_speed
1x 1X speed
2x 2X speed
autostart
yes execute the kernel as soon as it has been loaded
no do not execute the kernel after loading