Hello,everyone. I'm a student, and now my task is studying Linuxbios.
I'm not very clear about the difference between the protect mode and the real mode. So I wonder why should Linuxbios turn into protect mode at the very beginning.
And is there any difference between protect mode in Linuxbios and in linux kernel. If any, what's the main difference?
On 5/29/07, Fu xiayin fxyzc.114@gmail.com wrote:
Hello,everyone. I'm a student, and now my task is studying Linuxbios.
I'm not very clear about the difference between the protect mode and the real mode. So I wonder why should Linuxbios turn into protect mode at the very beginning.
And is there any difference between protect mode in Linuxbios and in linux kernel. If any, what's the main difference?
Dude you seriously need to get some book on the protected mode architecture.
real mode is 16 bit mode. all x86 cpus start in this mode. protected mode is 32 bit mode. protected mode is good; real mode is bad.
thats all i can tell you.
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Tuesday 29 May 2007 04:50, Fu xiayin wrote:
Hello,everyone. I'm a student, and now my task is studying Linuxbios.
I'm not very clear about the difference between the protect mode and the real mode.
Real mode: 16 bit offsets, address space limited to 20 bit. Protected mode (or "Linear Flat Mode", see below): 32 bit offsets, address space 32 bit
So I wonder why should Linuxbios turn into protect mode at the very beginning.
Try to access your ROM at physical address 0xFFFF0000 in real mode and you will "feel" the reason. ;-)
And is there any difference between protect mode in Linuxbios and in linux kernel. If any, what's the main difference?
The mode used in LinuxBIOS is more a 32 bit real mode (called "Linear Flat Mode") than a protected mode, because there is no protection at all. Also there is no paging and no address translation activated. Every segment starts at physical offset 0x00000000 and has a limit of 4GiB (this means: "no limit").
Juergen
I am also confused a little. The propriety BIOS runs in the real mode, how does it test the memory beyond 1MB?
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
Best Regards
??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Juergen Beisert Sent: Wednesday, May 30, 2007 6:09 PM To: linuxbios@linuxbios.org Cc: Fu xiayin Subject: Re: [LinuxBIOS] Question about protect mode?
On Tuesday 29 May 2007 04:50, Fu xiayin wrote:
Hello,everyone. I'm a student, and now my task is studying Linuxbios.
I'm not very clear about the difference between the protect mode and the real mode.
Real mode: 16 bit offsets, address space limited to 20 bit. Protected mode (or "Linear Flat Mode", see below): 32 bit offsets, address space 32 bit
So I wonder why should Linuxbios turn into protect mode at the very beginning.
Try to access your ROM at physical address 0xFFFF0000 in real mode and you will "feel" the reason. ;-)
And is there any difference between protect mode in Linuxbios and in linux kernel. If any, what's the main difference?
The mode used in LinuxBIOS is more a 32 bit real mode (called "Linear Flat Mode") than a protected mode, because there is no protection at all. Also there is no paging and no address translation activated. Every segment starts at physical offset 0x00000000 and has a limit of 4GiB (this means: "no limit").
Juergen
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Feng, Libo wrote:
I am also confused a little. The propriety BIOS runs in the real mode, how does it test the memory beyond 1MB?
The propietary BIOS such as Award-Phoenix, AMI, Insyde, etc. switches the machine to "Voodoo Mode/Flat real mode" or "Flat Protected Mode with no memory management scheme (as written by Juergen)". Use google with these keywords and you will find a lot of info in the web. LinuxBIOS is much more clean because the 32-bit mode it uses is thoroughly defined in Intel's Manual, no confusion about how to enter the processor operating mode. The propietary BIOSes use the "kludge" known as "Voodoo Mode". I'm not sure whether processor from different manufacturer will comply to it or not, because IIRC it's quite an undocumented feature.
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
Through the chipset decoding logic. BIOS chips is partially mapped in the "legacy part" of x86 physical address space. The chipset carry out the tasks. Pay attention to the chipset datasheet as you read through (and/or disassembly) the BIOS code.
--Darmawan
On Wednesday 30 May 2007 12:20, Feng, Libo wrote:
I am also confused a little. The propriety BIOS runs in the real mode, how does it test the memory beyond 1MB?
It switches also into the Linear Flat Mode. After the test is done it switches back to realmode.
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
At what time it accesses this devices? At system start? Or when something like DOS runs? At system start see above.
When DOS runs? Hmmm. There are ways to setup all segment registers to real mode limits except for one, the ES. This one you could setup for baseaddress 0 and limit 4GiB. With this setting you could run real mode code, and whenever you like access addresses beyond 1MiB you simply use the segment override es:<blablub> for this mnemonic. But this only works within assembler. Its a solution, but an ugly one. Another way is to switch into pm for every access beyond 1MiB and switch back to real mode when its done. This is the way some BIOSs goes to copy chunks of memory content from below 1MiB to above 1MiB.
Juergen
... LinuxBIOS is much more clean because the 32-bit mode it uses is thoroughly defined in Intel's Manual, no confusion about how to enter the processor operating mode. ...
... Pay attention to the chipset datasheet as you read through (and/or disassembly) the BIOS code.
--Darmawan
Yes. Find yourself Intel's processor manual and any of the northbridge chipset datasheet. I think they will help a lot.
Hi, Mr. Juergen Beisert,
I mean that, just after power on, processor leaves the reset state, the first instruction is fetched from 0xFFFFFFF0, the address may be led to LPC, X-BUS or PCI. From other people's reply, it seems an external jumper decides the configuration, then chipset decoding logic leads the address to the right place. My understanding is correct?
Best Regards
??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406
-----Original Message----- From: Juergen Beisert [mailto:juergen127@kreuzholzen.de] Sent: Wednesday, May 30, 2007 7:27 PM To: linuxbios@linuxbios.org Cc: Feng, Libo Subject: Re: [LinuxBIOS] Question about protect mode?
On Wednesday 30 May 2007 12:20, Feng, Libo wrote:
I am also confused a little. The propriety BIOS runs in the real mode, how does it test the memory beyond 1MB?
It switches also into the Linear Flat Mode. After the test is done it switches back to realmode.
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
At what time it accesses this devices? At system start? Or when something like DOS runs? At system start see above.
When DOS runs? Hmmm. There are ways to setup all segment registers to real mode limits except for one, the ES. This one you could setup for baseaddress 0 and limit 4GiB. With this setting you could run real mode code, and whenever you like access addresses beyond 1MiB you simply use the segment override es:<blablub> for this mnemonic. But this only works within assembler. Its a solution, but an ugly one. Another way is to switch into pm for every access beyond 1MiB and switch back to real mode when its done. This is the way some BIOSs goes to copy chunks of memory content from below 1MiB to above 1MiB.
Juergen
On Thursday 31 May 2007 04:45, Feng, Libo wrote:
Hi, Mr. Juergen Beisert,
I mean that, just after power on, processor leaves the reset state, the first instruction is fetched from 0xFFFFFFF0, the address may be led to LPC, X-BUS or PCI. From other people's reply, it seems an external jumper decides the configuration, then chipset decoding logic leads the address to the right place. My understanding is correct?
Yes.
Juergen
To Xia-yin: Processor manual does help. Of course, explanation from people here is more specific.
2007/5/30, Feng, Libo Libo.Feng@amd.com:
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
To Libo and Juergen: It seems not every board can do that. Would you name some of them ?
Maybe a silly question: Isn't it that PCI needs initialization before we could access it? How could we get there when the processor is fetching the 1st instruction?
Hi,
On Thursday 31 May 2007 11:00, Yuning Feng wrote:
To Xia-yin: Processor manual does help. Of course, explanation from people here is more specific.
2007/5/30, Feng, Libo Libo.Feng@amd.com:
Another question is BIOS ROM can attach to XBUS, LPC, someone told me, even PCI, how dose the address forward to the location?
To Libo and Juergen: It seems not every board can do that. Would you name some of them ?
Hmm, every board *must" do it. The CPU outputs the address 0xFFFFFFF0 and awaits to read its first instruction. The external chipset (if not a SoC) is responsible to generate a chip select signal to a device that contains this instruction(s) and to forward the "answer" from this device back to the CPU data bus. So every board can do it, but maybe not all variants listed above. Maybe only one of it, or maybe more than one of it. In the latter case you must select in a _chipset_specific_way_ where the device is connected that contains the boot code. So you should not read processor's manual, you should read chipset's manual instead (for the case they are separate devices. On SoCs they are combined in one silicon).
Maybe a silly question: Isn't it that PCI needs initialization before we could access it? How could we get there when the processor is fetching the 1st instruction?
In this case the ROM device is connected to the PCI bus, but not connected _as_ a PCI device!. It shares the PCI bus address/data lines only to save an additional bus. If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data bus). Add also three separate additional lines (read, write, chip select) and you are done. Whenever the chipset generates a ROM device access cycle, it does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So this does not hurt any other *real* PCI device on the same bus. But this may work only at system start. Later on some PCI master devices could inhibit this mode. But it doesn't matter: At this point of time the ROM content runs from system RAM, so there is no more need to access the real ROM device (maybe only to reprogramm it).
Hope it helps.
Juergen
On Wednesday 30 May 2007 11:26, Rogelio Serrano wrote:
protected mode is good; real mode is bad.
Sounds good :-))
Juergen
2007/5/31, Juergen Beisert juergen127@kreuzholzen.de:
Maybe a silly question: Isn't it that PCI needs initialization before we could access it? How could we get there when the processor is fetching the 1st instruction?
In this case the ROM device is connected to the PCI bus, but not connected _as_ a PCI device!. It shares the PCI bus address/data lines only to save an additional bus. If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data bus). Add also three separate additional lines (read, write, chip select) and you are done. Whenever the chipset generates a ROM device access cycle, it does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So this does not hurt any other *real* PCI device on the same bus. But this may work only at system start. Later on some PCI master devices could inhibit this mode. But it doesn't matter: At this point of time the ROM content runs from system RAM, so there is no more need to access the real ROM device (maybe only to reprogramm it).
Hope it helps.
Juergen
Please check whether I have understood correctly.
The processor lauches a cycle with address = 0xFFFF_FFF0. The north bridge chipset explains this address. In this case, it signals the read line and chip select line which connect the ROM device, and select an address of the ROM device through PCI bus AD[31..8]. To the north bridge, the ROM device is like a common BIOS ROM except that it uses PCI bus to exchange information. Then the ROM device uses AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte of data is a portion of the 1st instruction.
Thanks.
Yu-ning
On Saturday 02 June 2007 10:25, Yu-ning Feng wrote:
Please check whether I have understood correctly.
The processor lauches a cycle with address = 0xFFFF_FFF0. The north bridge chipset explains this address. In this case, it signals the read line and chip select line which connect the ROM device, and select an address of the ROM device through PCI bus AD[31..8]. To the north bridge, the ROM device is like a common BIOS ROM except that it uses PCI bus to exchange information. Then the ROM device uses AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte of data is a portion of the 1st instruction.
This could be a valid scenario, yes.
Juergen
Juergen,
Can you please explain which chipset northbridge does this? I've never seen one that uses the PCI bus in this fashion, but I'd like to know if there is one.
http://www.intel.com/design/chipsets/440/documentation.htm
Everyone, please look at Intel 440BX chipset docs for a clear explanation. It's an older chipset but that helps to explain the history of some things.
Northbridge 440BX
http://www.intel.com/design/chipsets/datashts/290633.htm
Page 1-2 has an excellent system diagram.
The CPU reset vector is 0xFFFF_FFF0. After reset the Intel i82443BX northbridge decodes everything to PCI. The southbridge will also respond to aliases below 16M and 1M. The usual sequence of the BIOS is then to configure RAM and enable decoding. At that point, the alias below 1M disappears (going to RAM now), and possibly the one below 16M depending on how much RAM there is.
After that, it is possible to copy BIOS to RAM, and write-protect it for "shadowing" and legacy support of BIOS at 0xF0000.
It is also possible to enable a memory "hole" from 15M to 16M and access the BIOS from there.
Page 4-5 explains:
High BIOS Area (FFE0_0000h –FFFF_FFFFh)
The top 2 MB of the Extended Memory Region is reserved for System BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of the system BIOS. CPU begins execution from the High BIOS after reset. This region is mapped to PCI so that...
Southbridge PIIX4E:
http://www.intel.com/design/intarch/datashts/290562.htm
Page 12 has another useful system diagram showing the BIOS.
The PIIX4E i82371EB claims the 0xFFFF_FFF0 cycle, and aliases to top of X-bus (1M and 16M) which is where the BIOS rom is connected. This is done after reset, even without PCI configuration, as a special case to allow booting.
Page 155 gives the details.
Regards,
Jeremy
On Sat, 2007-06-02 at 16:25 +0800, Yu-ning Feng wrote:
2007/5/31, Juergen Beisert juergen127@kreuzholzen.de:
Maybe a silly question: Isn't it that PCI needs initialization before we could access it? How could we get there when the processor is fetching the 1st instruction?
In this case the ROM device is connected to the PCI bus, but not connected _as_ a PCI device!. It shares the PCI bus address/data lines only to save an additional bus. If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data bus). Add also three separate additional lines (read, write, chip select) and you are done. Whenever the chipset generates a ROM device access cycle, it does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So this does not hurt any other *real* PCI device on the same bus. But this may work only at system start. Later on some PCI master devices could inhibit this mode. But it doesn't matter: At this point of time the ROM content runs from system RAM, so there is no more need to access the real ROM device (maybe only to reprogramm it).
Hope it helps.
Juergen
Please check whether I have understood correctly.
The processor lauches a cycle with address = 0xFFFF_FFF0. The north bridge chipset explains this address. In this case, it signals the read line and chip select line which connect the ROM device, and select an address of the ROM device through PCI bus AD[31..8]. To the north bridge, the ROM device is like a common BIOS ROM except that it uses PCI bus to exchange information. Then the ROM device uses AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte of data is a portion of the 1st instruction.
Thanks.
Yu-ning
Hi Jeremy,
On Saturday 02 June 2007 20:25, Jeremy Jackson wrote:
Can you please explain which chipset northbridge does this? I've never seen one that uses the PCI bus in this fashion, but I'd like to know if there is one.
Sorry, I had no special x86 chipset in mind. This is only a possible scenario one can use to save an additional bus mostly used at system start up only.
I only know a PowerPC (405GP if I remember right, its a SoC) processor that supports such kind of ROM device addressing/connecting.
http://www.intel.com/design/chipsets/440/documentation.htm
Everyone, please look at Intel 440BX chipset docs for a clear explanation. It's an older chipset but that helps to explain the history of some things.
Northbridge 440BX
http://www.intel.com/design/chipsets/datashts/290633.htm
Page 1-2 has an excellent system diagram.
And it shows the ROM is connected to the ISA bus, behind the southbridge. Nothing PCI specific.
Southbridge PIIX4E:
http://www.intel.com/design/intarch/datashts/290562.htm
Page 12 has another useful system diagram showing the BIOS.
The PIIX4E i82371EB claims the 0xFFFF_FFF0 cycle, and aliases to top of X-bus (1M and 16M) which is where the BIOS rom is connected. This is done after reset, even without PCI configuration, as a special case to allow booting.
Page 155 gives the details.
Seems also the ISA bus is where the ROM device is connected to. And to reach the ISA bus, you must reach the southbridge first. So that's why the PCI bus is relevant here. But not to access the ROM device itself.
So it does not match my scenario where the ROM device is directly connected to PCI lines.
Juergen
On Saturday 02 June 2007 22:25, Juergen Beisert wrote:
I only know a PowerPC (405GP if I remember right, its a SoC) processor that supports such kind of ROM device addressing/connecting.
And the PowerPC MPC5200 does it in such a way, as it shares lines between PCI and local bus. Nothing x86 specific.
Juergen
On Sat, Jun 02, 2007 at 02:25:59PM -0400, Jeremy Jackson wrote:
Can you please explain which chipset northbridge does this? I've never seen one that uses the PCI bus in this fashion, but I'd like to know if there is one.
Southbridge. See ICH7 and/or ICH8.
//Peter
-
Darmawan Salihun -
Feng, Libo -
Fu xiayin -
Jeremy Jackson -
Juergen Beisert -
Peter Stuge -
Rogelio Serrano -
Yu-ning Feng -
Yuning Feng