Is Apple using BIOS?

[stevewm]

One of the weakest points of all Wintel systems has always been power management! (sleep modes, hibernation, starting up and shutting down) Very buggy to this day!

When power management fails to function on a x86 system it is always caused by one of two things... Hardware itself and/or drivers. though it usually turns out the be driver related. Its not the fault of the BIOS.

I have seen many drivers that did not support power management, or had a very half-assed implimentation of it. When you have a driver like this, then you will have problems. For example: ATI's older Rage series drivers particularly had problems with Suspend to RAM functions (aka Deep Sleep in the Mac world.) Putting your computer into STR mode would usually result in a hardlock. If it managed to make it into STR mode, it would not wake up without being unplugged first They fixed the problems fairly fast though... With modern hardware and drivers, power management is rarely a problem in the PC/BIOS/Windows world.

My homebuilt machine does STR/Sleep perfectly. Goes down in 3 seconds, and comes back up just as fast!

Apple is not without fault in power management. I've seen many things make suspending/sleep screw up on the Mac. Sometimes caused by Apple's own software updates.

 

[shamino]

Haven't you said as much yourself, more or less -- that energy management is handled by the BIOS? This is presumably why my XP box freezes more often than not when I try to wake it from standby mode and my Mac never does.

The BIOS is just softwre in ROM.

If you have a proper device driver, you have provide the exact same functionality in the OS without any BIOS support.

Since Apple will be manufacturing these x86 Macs, they definitely will have all the information necessary to write such a driver.

APM is typically in ROM on PC's, because there are several different core-logic chipsets. The industry has decided (right or wrong) that they'd rather the motherboard maker put the control logic in the BIOS ROM instead of in software drivers (the way most other chipset-specific featurs are supported.)

As for your PC freezing, that has everything to do with the quality of your core-logic chipset, and the software that drives it. The location of the software (ROM or OS) doesn't have anything to do with this.

 

[shamino]

Since the hardware environment the EFI code will be written to will likely encorporate enough unique parts and drivers that reproducing that environment would require either custom fabrication or very cunning emulation the act of reverse engineering it could prove a very amusing (and time consuming) "Rubik's Cube" to the fifteen most talented Hackers in the world while proving daunting enough to everyone else that the act of reverse engineering approaches diminished returns with about the same impact noise as a pigeon hitting a window?

You forget - we're living in the era of instant communication.

All it takes is one person to hack the environment. Then the code will be distributed to the entire world. Then the system will become completely useless, because anybody who cares will be able to download the code and use it.

People made similar claims about every other DRM scheme in existance. They've all been broken. The only thing DRM does is give a copyright owner grounds to file a DMCA-based lawsuit, after it's been broken. It doesn't do a thing to actually control the content.

 

[shamino]

My technical knowledge here is limited, so I can't say with confidence either way, but from what I understand, PC-BIOS is PC-BIOS. It's primitive, and nearly 25 years old, and can't be tricked around to be much more than what it is.

But it's also possible for an OS to ignore any piece of it, or even all of it.

Once the boot sequence is handed off to OS code, the BIOS doesn't have to exist at all. Device drivers (whether built-in to the kernel or dynamically loaded) can completely replace it.

Modern operating systems only use BIOS code as a convenience, not because it is in any way necessary.

 

[shamino]

The fact that that requires a separate partition (!!!) should tell you something about the limits of the classic PC BIOS...

Why? Because IBM decided they wanted to design their system that way?

BTW, are you aware that IBM has been doing this for a very long time? Most PS/2 systems deleted lots of functionality from their ROMs, offloading it into OS code, special setup boot floppies, and hidden disk partitions.

Does this mean a PS/2 doesn't have a BIOS? Or that everybody else, that didn't remove these features doesn't?

The graphical bootloader in OF doesn't reside on any bootable devices; it's written into the firmware itself.

I've got a 486 PC with a graphical setup program in the ROM BIOS.

You seem to think that there is only one BIOS program that everybody copies.

Not so. There are tons of different ones. Any ROM that implements a core set of APIs and can boot the OS is a BIOS. Manufacturers have been extending and customizing this code ever since the first non-IBM BIOS was developed (for the original Compaq systems - the first PC clones.)

If the BIOS in your PC doesn't have a particular feature, it simply means that your PC's manufacturer decided to not put that feature in ROM. It doesn't mean a thing about what is or is not possible.

No. The Open Firmware prompt is something rather different. As the name implies, it doesn't have anything to do with the OS. You can access it by holding down cmd-opt-O-F on boot on any NewWorld (i.e. has built-in USB) Mac.

As with the graphical boot-device selection thingy, this is not resident on any attached devices; it's part of the firmware itself. You can disconnect all hard drives and other storage devices from a Mac and still have access to Open Firmware (including the graphical selection thing).

The UI built-in to the ROM is one of the least important features of Open Firmware.

The big deal about it is that it eliminated the megabyte or so of OS code that used to be in apple's Toolbox ROM, in recognition of the fact that the Mac OS was no longer using very much (if any) of it anyway.

I doubt it--not if we're talking about the current, standard PC BIOS...

Maybe you can define what is "standard" about the BIOS. Aside from a small number of legacy APIs that are never used (unless you boot MS-DOS), a modern BIOS bears almost no resemblance to the ROM code that IBM originally developed for their original 8088-based PCs.

The only thing "standard" about the BIOS is that everybody's is different from everybody else's.

 

[shamino]

One of the weakest points of all Wintel systems has always been power management! (sleep modes, hibernation, starting up and shutting down) Very buggy to this day!

What makes you think the ROM code is the reason for these bugs. Have you ever considered that Windows itself is the source of these bugs?

The BIOS is something that Apple is leaving to Intel (Phoenix) engineers for now, and that does not bode well for the tight hardware / software integration that Apple is known for.

Where did you hear this? Are you privy to some secret information that Apple has not released to the rest of the world?

There needs to be a replacement for the traditional BIOS. It's certainly possible that Apple can help to set new standards.

The official word from Apple is that you should not make any assumptions about what the ROM will look like in an x86 Mac. Anybody who tells you they know what will actually be in these systems is either lying to you or violating an NDA. Maybe both.

MS has essentially failed with its Intel EFI initiative of 2003.

Kind of hard to do, since EFI is not a Microsoft project. Maybe you're thinking of something else?

 

[shamino]

There are Microsoft-specific extensions in Intel's EFI spec, its binary format is designed to be easily generated by Microsoft tools, and Microsoft already support it

EFI is an extensible spec. It's possible for all kinds of vendors to code their own extensions.

As for "easily generated by Microsoft tools", what does this mean? That you don't have to spend a week figuring out how to compile the sources? Why is this a bad thing? And why do you tink this in any way makes it a Microsoft product.

Are you now going to claim that Photoshop is an Apple product because it is compiled using Xcode?

(Windows Swerver already uses it on Itanic systems; in the past, non-x86 Windows systems used Open Firmware).

????

I hope you're not claiming that Apple wrote the ROM firmware for all those MIPS, Alpha, and SPARC systems that could boot various versions of Windows. Such a claim would be completely nonsense.

 

[shamino]

Apart from the obvious of having a MUCH simpler interface then open firmware, the BIOS in a PC gives you control of every piece of hardware in your computer, and not just changing the ram timings, you can change the voltages being supplied to your computer, over clock your ram/CPU/AGP etc, etc... change aperture sizes, basically anything you can think of as with regards to fiddling with your hardware to get the most out of it...

Only if the motherboard manufacturer decides to put that software in the ROM chip.

There are plenty of PC's where you can't do any of this.

 

[iMeowbot]

EFI is an extensible spec.

I'd have never figured out that the Extensible firmware Interface was extensible.

It's possible for all kinds of vendors to code their own extensions.

Intel incorporated Microsoft's extensions to the Intel EFI spec, version 1.10, and they have also been working in conjunction with hardware vendors. They are most certainly not developing EFi in isolation, that would be astoundingly stupid for obvious reasons. By following the links at http://www.intel.com/technology/efi/efi.htm one can easily see what portions of the specification were developed by Microsoft.

As for "easily generated by Microsoft tools", what does this mean?

It means that the native binary format for EFI is the Microsoft PE format, and that the native filesystem is Microsoft FAT. This is all in the specification, of course.

 

[WM.]

Apart from the obvious of having a MUCH simpler interface then open firmware, the BIOS in a PC gives you control of every piece of hardware in your computer, and not just changing the ram timings, you can change the voltages being supplied to your computer, over clock your ram/CPU/AGP etc, etc... change aperture sizes, basically anything you can think of as with regards to fiddling with your hardware to get the most out of it...

See, you're missing the point. As shamino pointed out, all of these are possible not because having a PC BIOS magically makes them possible; they're possible because, in those cases, both the hardware and the BIOS have been specifically designed to make them possible.

One could just as easily make a motherboard that used Open Firmware instead and had a comparable if not much better interface to do the same things. But you'd have to design the motherboard to allow it.

The reason you can't do all those things on an OF-using Mac is that neither Apple's firmware nor Apple's motherboards are designed to allow it. It's, again, NOT a limitation of Open Firmware, the standard.

The PC BIOS standard (such as it is) DOES have many limitations that Open Firmware doesn't. This link, for the third time, explains many of them.

to do the same in open firmware is a pain in the arse.. though some of it can be done through OF, it's definitely not as easy to achieve the same thing with OF, and it's definitely not right in front of you in a menu system.

See above. This is not a limitation of OF; it's a limitation of whatever implementations of OF you've used.

a Pheonix/Award/AMI bios does what you need and nothing more, i'll agree that OF can provide you with more possibilities, but a lot of the time this is unnecessary, and this is where the aforementioned BIOS versions win out...

besides that fact, anything else you need to do can be easily done outside of the BIOS, and i really don't see the need for all the extra junk that can be found in OF

Well, it's cool, for one thing. I'm reasonably sure you can't browse filesystems in PC BIOSes, which you can do in OF--if your particular implementation can read the appropriate filesystem, of course. I believe the version on my PowerBook can read HFS+, FAT32, and ext2, among others, but I'm not positive.

 

[WM.]

Why? Because IBM decided they wanted to design their system that way?

BTW, are you aware that IBM has been doing this for a very long time? Most PS/2 systems deleted lots of functionality from their ROMs, offloading it into OS code, special setup boot floppies, and hidden disk partitions.

Does this mean a PS/2 doesn't have a BIOS? Or that everybody else, that didn't remove these features doesn't?
I've got a 486 PC with a graphical setup program in the ROM BIOS.

Okay, great. I'm glad such things are possible in the BIOS.

You seem to think that there is only one BIOS program that everybody copies.

No, but as I understand it there is a quasi-standard which is rather limited. I won't link to the same article for the fourth time in this thread, but, um, it's there.

Now, EFI I don't think I'd have a problem with. It seems much better able to provide the kind of hardware experience that we expect from Macs...

If the BIOS in your PC doesn't have a particular feature, it simply means that your PC's manufacturer decided to not put that feature in ROM. It doesn't mean a thing about what is or is not possible.

There are some things, though, that I understand to be impossible in a BIOS but quite possible in Open Firmware (because it's so flexible and extensible). For example, could one write a BIOS that allowed filesystem access? Use of the mouse?

More than four "primary partitions", whatever that means?

I honestly am not sure of the answers of these questions, and I'd love to hear that I'm wrong in my perceptions of what one can do with a PC BIOS.

The UI built-in to the ROM is one of the least important features of Open Firmware.

The big deal about it is that it eliminated the megabyte or so of OS code that used to be in apple's Toolbox ROM, in recognition of the fact that the Mac OS was no longer using very much (if any) of it anyway.
Maybe you can define what is "standard" about the BIOS. Aside from a small number of legacy APIs that are never used (unless you boot MS-DOS), a modern BIOS bears almost no resemblance to the ROM code that IBM originally developed for their original 8088-based PCs.

The only thing "standard" about the BIOS is that everybody's is different from everybody else's.

Well, my link indicates that there are some things that all PC BIOSes have in common. Feel free to point out things that it gets wrong...

 

[WM.]

I hope you're not claiming that Apple wrote the ROM firmware for all those MIPS, Alpha, and SPARC systems that could boot various versions of Windows. Such a claim would be completely nonsense.

Um, no, Open Firmware is, as the name implies, an open standard. It was invented by Sun. Wikipedia says: "Open Firmware (also, OpenBoot) is a hardware-independent firmware (computer software which loads the operating system), developed by Sun Microsystems, and used in PowerPC-based Apple Macintosh computers, Sun Microsystems SPARC based workstations and servers, IBM POWER systems, and PegasosPPC systems, among others."

Actually, I don't think it was used in the NuBus Power Macs, but close enough...

Anyway, the point is, no one's trying to say that Apple wrote every implementation of Open Firmware. I'm not sure how you got that idea.

 

[GregA]

Eventually you'll be able to run an old version of OSX on a new Dell (e.g.) because by the time Dell catches up on hardware there will be a new version of OSX out (~ yearly).

The flaw in that argument is that the new version of OSX, while written for the latest and greatest Apple hardware, will also be written to run on older OSX hardware.

I don't think Apple will rely on Mac's having the latest hardware to keep OSX from being copied. I'm still betting on some form of Fairplay (with flexibility?)

 

[ClimbingTheLog]

The flaw in that argument is that the new version of OSX, while written for the latest and greatest Apple hardware, will also be written to run on older OSX hardware.

Ya, you're right. I realized that after I got in the car and was away from the computer. 8)

On reflection, I think the best Apple can hope for is to use that tactic for the first generation, and hope to pull ahead in the market. Then they have to survive on their own merits.

They certainly could implement FairPlay, but at the rate jhymn has been beating it, having it in hardware would make it harder to upgrade. Unless they required firmware updates to install the next version of OSXi.

 

[opq]

What about the trademark one button mouse?

Edit: Sometimes you just have to know when to let go.

Haha! I beg to differ ... While I think having a second button on the mouse is improving on the mouse, how is removing the startup chime improving the computer? No longer will I be able to make people aroudn me jealosu because I have a Mac - they won't look around when I startup my computer anymore

 

[orestes1984]

See, you're missing the point. As shamino pointed out, all of these are possible not because having a PC BIOS magically makes them possible; they're possible because, in those cases, both the hardware and the BIOS have been specifically designed to make them possible.

One could just as easily make a motherboard that used Open Firmware instead and had a comparable if not much better interface to do the same things. But you'd have to design the motherboard to allow it.

The reason you can't do all those things on an OF-using Mac is that neither Apple's firmware nor Apple's motherboards are designed to allow it. It's, again, NOT a limitation of Open Firmware, the standard.

The PC BIOS standard (such as it is) DOES have many limitations that Open Firmware doesn't. This link, for the third time, explains many of them.


See above. This is not a limitation of OF; it's a limitation of whatever implementations of OF you've used.


Well, it's cool, for one thing. I'm reasonably sure you can't browse filesystems in PC BIOSes, which you can do in OF--if your particular implementation can read the appropriate filesystem, of course. I believe the version on my PowerBook can read HFS+, FAT32, and ext2, among others, but I'm not positive.

you're missing my point, and that is to 99% of people all the extra bells and whistles OF has are unescesary, and that to the same 99% of people the afermentioned BIOS versions i was talking about are a lot easier to use.

Yes OF can be coded to be as simple but that is beyond the point.

Also you can do 99% of what OF does before windows boots anyway by having things writen into the MBR

 

[orestes1984]

Haha! I beg to differ ... While I think having a second button on the mouse is improving on the mouse, how is removing the startup chime improving the computer? No longer will I be able to make people aroudn me jealosu because I have a Mac - they won't look around when I startup my computer anymore

you'll just have to get used to a standard beep from a PC Speaker

 

[shamino]

No, but as I understand it there is a quasi-standard which is rather limited. I won't link to the same article for the fourth time in this thread, but, um, it's there.

The "standard" is the set of real-mode interrupt calls that IBM put in the original PCs, and maybe some of their later extensions in the PC/AT.

Just about everything else is what hardware manufacturers decided would be useful. Mostly chipset initialization features.

There are some de-facto standards - extensions that multiple vendors have agreed upon - like support for LBA-48 mode and APM.

There are some things, though, that I understand to be impossible in a BIOS but quite possible in Open Firmware (because it's so flexible and extensible). For example, could one write a BIOS that allowed filesystem access? Use of the mouse?

Why not?

One of my 486 systems uses a serial mouse as a part of its GUI-based setup screen.

The lack of a standard for BIOS means that any vendor can put any code he wants in there. Nothing is prohibited, and nothing (other than the basic interrupt service calls) is guaranteed to exist.

More than four "primary partitions", whatever that means?

The disk partitioning scheme is not a function of the BIOS. It's a function of the code in the master boot record. The reason there's a limit of four partitions is because the partition table is stored in the same disk block as the MBR code, and there's no room for more in there.

It would be no big deal to design MBR code that looks elsewhere for a partition table (maybe in the next disk block). This would break low-level programs like fdisk, but they could easily be patched/replaced.

Well, my link indicates that there are some things that all PC BIOSes have in common. Feel free to point out things that it gets wrong...

There are a lot of things that they have in common, but (with the exception of the core interrupt service routines), none of them are mandatory.

One vendor adds a feature, the others think it's a good feature and they copy it.

The first PC/AT systems needed a DOS-based utility to configure the CMOS parameters. Later on, vendors added built-in setup screens. BIOS setup code replaced DIP switches and jumpers on the motherboard for chipset configuration. None of these changes are mandated or prohibited by the BIOS specifications.

What we see today, in modern PC's, is standard only in the sense that all the major vendors incorporate the features. Not because there is any document mandating the presence of those features.

Chipset features, power management, etc. can all be configured through other means (Windows device drivers, motherboard jumpers, etc.) and the ROM will be just as "standard", although not as convenient.

 

[shamino]

The PC BIOS standard (such as it is) DOES have many limitations that Open Firmware doesn't. This link, for the third time, explains many of them.

OK. I'm reading your link. (I didn't notice it until now.)

It is not without errors. Not even in the obvious parts.

For instance:

Legacy BIOS depends on VGA, which is a legacy standard, and is unnecessarily complicated to program for.

Not at all true. The original BIOS's were hard-coded with monochrome text displays. When IBM released the CGA card, it was then hard-coded for CGA text display (which stores the character buffer at a different memory location.) Originally, jumpers on the motherboard would be used to tell the BIOS which to use.

Later, when EGA/VGA and newer cards came out, you would set the jumpers for "none" - a BIOS extension ROM on the video card would instead be given control during the boot sequence to take over display-specific responsibilities.

Today, the VGA-compatible code resides in the ROM because all modern video cards are VGA-compatible. and its a convenience for the rest of the industry. Not because the spec requires it. As a matter of fact, some modern BIOS's still let you configure the screen for MDA/CGA/VGA, even though nobody today has MDA or CGA cards installed.

The PC partitioning scheme is tied to the BIOS

Absolutely 100% false.

The BIOS doesn't know anything about partitions. The BIOS loads the MBR (absolute disk block 0 of the drive), and executes it. The MBR contains software. That software is what knows about the partitioning scheme. It reads the partition table (which is usually some data at the end of the MBR's disk block) to determine the bootable partition, and then loads the boot code from that partition.

You want a disk with the capacity for dozens of partitions? No problem. Store the partition table somewhere else (since there won't be room in the MBR), and modify the MBR's software to read that table from wherever you decided to put it. If there isn't enough room in the single disk block of the MBR for this software, the MBR code can load more code from somewhere else on the disk - as long as those disk blocks aren't used by any partition, this is not a problem.

Of course, if you do this, your disk-partitioning software (like fdisk) will break and need to be updated. But that's a software issue, not a BIOS issue.

 

[mischief]

You forget - we're living in the era of instant communication.

All it takes is one person to hack the environment. Then the code will be distributed to the entire world. Then the system will become completely useless, because anybody who cares will be able to download the code and use it.

People made similar claims about every other DRM scheme in existance. They've all been broken. The only thing DRM does is give a copyright owner grounds to file a DMCA-based lawsuit, after it's been broken. It doesn't do a thing to actually control the content.

Okay. Lets assume that 1 person manages to reverse-engineer emulation for a version of the hardware with a few thousand lines of code. Lets further assume that this layer is efficient enough and small enough to run OS X at more than an opium-den pace on the average BIY PC. You still have the issues of the thousands of proprietary/Generic devices out there that will not have OS X support (Such as DirectX), Total lack of support from Apple and probable incompatibility for any intensive software that relies on fairly direct access to things like video cards.

I'm not arguing about whether it's possible, Im arguing over whether it's worthwhile. I could, theoretically power my house off of the fermenting wastes currently being channelled off to the city sewers and wasted. It's possible, someone out there knows how to do it and the technology exists to make it happen. Does that mean that many houses will soon be powered by their wastewater? I think not.

See also: Theoretically it's possible to rip out an ATM to get at the money inside. How often does it happen successfully?

 

[WM.]

(stuff)

All right. Thank you for setting me straight.

 

[Rocketman]

I will simply point out to all Apple zealots (and collectors) that the release of this system represents an official Apple release of a CPU with MacOS installed. Thus and therefore it must remain on all future hardware lists.

Rocketman

 

[Flynnstone]

Windows systems barely use the BIOS. Just used to get started then it talks directly to hardware. I believe the PC BIOS is mostly 16 bit code.
So I can't see a standard PC BIOS in a Mac. Most likely a Open Firmware variant.
Consistency is a big issue with Mac, so why mess with users. Give them what they are used to.

 

[immovableobject]

Bad Information

There is a lot of bad information in this thread posted by a lot of computer users that don't know more than how to use a BIOS. A few points:

1. The BIOS configures the PC for use. It is very basic and results in a machine that runs in real mode to boot one or maybe a couple of devices. It is horribly error prone and has many pieces that the user can't access. These pieces run prior to the video screen initialization, which means that any error found prior to that point CAN'T be shown to the user. Some other "features" of the current PC bios:

• It requires a VGA console for initial configuration. It can't use a serial port (e.g. on a server) without reconfiguration.
• It does not initialize the hardware. Each piece of hardware must be initialized as it is "discovered" for full functionality. Remember the older network cards that "remembered' their old information on a reboot?
• They have TONS of features that have no real meaning. "Turbo" or "Delayed Memory Transaction"? Who knows (or cares) about these features?
• Only a single PCI card can be in BIOS enabled mode. Got two PCI HBAs? Good luck -- the magical ordering of the PCI slots will determine what IRQ they get and which one boots first. And some RAID cards can't be BIOS disabled. That's simply stupid.
• Power management. Nuf said.
• IRQ Sharing. What a hack!
• In short, the BIOS is a conglomeration of hacks from the late 1980s. It barely works.

2. Open Firmware looks for the devices in a system and builds a sane heirarchical device tree. This tree can be referenced for all of the devices in the system, even if there are dozens (e.g. on a Sun server, which also uses OF) of them. It supports automatically switching to a serial console should a monitor not be found.
3. EFI is simply a bad idea:

• It has proprietary IP (the FAT filesystem is required) that must be licensed from Microsoft.
• It still requires a VGA monitor for system set-up.
• EFI is universally hated: http://darrell.hates-software.com/2003/11/06/c5c014e4.html

Btw, the proof that the BIOS sucks is demonstrated by the problems that Linux has with PC hardware and sleep/wake. It's not Windows in that case -- both OSs have big problems with sleep/wake. That makes it a fundamental hardware problem, not an operating sytem problem.

On a side note, I am curious as to how Apple will solve the lack or IRQs in the Intel platform. It would be fantastic if they could demonstrate the use of an Intel chip that wasn't clogged with 8086isms.

Btw2, I like the name "inteltosh".

 

[GregA]

There is a lot of bad information in this thread posted by a lot of computer users that don't know more than how to use a BIOS.
3. EFI is simply a bad idea:

• It has proprietary IP (the FAT filesystem is required) that must be licensed from Microsoft.
• It still requires a VGA monitor for system set-up.
• EFI is universally hated: http://darrell.hates-software.com/2003/11/06/c5c014e4.html

I don't know much about EFI, just what I quickly found on the web.

Firstly - "Universally" hated may be overstating it! I've found very few criticisms of the new standard actually.

Secondly, EFI requires that the graphics card has UGA firmware otherwise it falls back to VGA.
http://www.kernelthread.com/publications/firmware/
http://www.ami.com/support/doc/EFI-FAQ.pdf

As far as requiring a license to use FAT, do all EFI implementations require FAT? Even if they did, it appears MS has given permission for use of FAT for EFI implementations.

http://www.intel.com/technology/efi/agreesource_draft.htm

6. You may use internally the FAT 32 File System Driver for your internal use and to create derivative works only to read and/or write to a file system that is directly managed by an EFI Implementation or by an emulator of an EFI Implementation.
7. Once the Complete EFI Specification is made publicly available by Intel, You may distribute through multiple tiers of distribution the FAT 32 File System Driver and all licensed derivative works that you are licensed to create under section 6, provided that the FAT 32 File System Driver and the licensed derivative works are subject to the licensed restrictions set forth in section 6.