The REAL OS construction contest

Index > OS Construction > The REAL OS construction contest

Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next

Author

Thread

DJ Mauretto

Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy

DJ Mauretto 02 Mar 2009, 19:17

Quote:

Which violates the rules because them state that the BIOS must load no more than 512 bytes

OOPS

I don't have read the rules,anyway simply low level floppy sector
loader fit good in 512 bytes, only IN and OUT instruction
only 1 byte Wink

_________________
Nil Volentibus Arduum Razz

02 Mar 2009, 19:17

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 03 Mar 2009, 16:20

PIO will work with USB, HD, network, etc... Seems the broadest supported non-BIOS method (down with the floppies already). I've tested it on a few machines and it worked well. (*BIOS does intercept the port accesses to support emulation, but not in all cases. So, in some cases I think this solution doesn't comply with the rules, but in other cases it does -- I assume this is okay?)

03 Mar 2009, 16:20

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 03 Mar 2009, 17:04

Quote:

*BIOS does intercept the port accesses to support emulation, but not in all cases.

Maybe this is a chipset feature? Was the V86 flag on?

03 Mar 2009, 17:04

edfed

Joined: 20 Feb 2006
Posts: 4330
Location: Now

edfed 03 Mar 2009, 17:57

OK for no bios INT13h, but at least, does somebody have a ready to use driver non destructive?

it would be interresting to share a common driver for beginners like me.

03 Mar 2009, 17:57

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 02:56

LocoDelAssembly wrote:

Quote:

*BIOS does intercept the port accesses to support emulation, but not in all cases.

Maybe this is a chipset feature? Was the V86 flag on?

Maybe the BIOS just configures a feature of the chipset and ends it's involvement. IIRC, SMM (system management mode) is used to handle the emulation (this executes code from the BIOS?). Don't think V86 is used, but I haven't finished reading the chipset docs.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

04 Mar 2009, 02:56

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20292
Location: In your JS exploiting you and your system

revolution 04 Mar 2009, 03:13

bitRAKE wrote:

PIO will work with USB, HD, network, etc... Seems the broadest supported non-BIOS method (down with the floppies already). I've tested it on a few machines and it worked well. (*BIOS does intercept the port accesses to support emulation, but not in all cases. So, in some cases I think this solution doesn't comply with the rules, but in other cases it does -- I assume this is okay?)

Does that mean that the BIOS is using v8086 mode and also using a virtual disk driver from protected mode? How would the boot code switch to protected mode if the CPU is already in protected mode? What does smsw ax give?

04 Mar 2009, 03:13

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 04 Mar 2009, 03:35

Quote:

SMM (system management mode) is used to handle the emulation (this executes code from the BIOS?)

Yes I was thinking the mechanism could be something around that, but still the BIOS doesn't intercept the I/O but handles it when the chipset calls the BIOS through SMM.

revolution, but trying to switch to protected mode from V86 doesn't generate an exception? The BIOS could take that opportunity to end emulation and then complete the protected mode transition the boot loader was wanting to do.

04 Mar 2009, 03:35

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20292
Location: In your JS exploiting you and your system

revolution 04 Mar 2009, 03:42

LocoDelAssembly: But before entering protected mode the code needs to setup other things like GDT which will cause an exception. The BIOS might be able to catch all cases and emulate until the final write to CR0/MSW but it would be very tricky to implement.

All: So if your hardware is using the SMM mechanism to trap your I/O port access then so be it. If the hardware is so determined to emulate everything for you then I won't stop you from using that "feature". But I wonder what would happen in protected mode if you forget (or don't know how) to turn off the SMM interception? And remember that if your code fails to work on other testers PCs then you won't get many votes!

04 Mar 2009, 03:42

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 04 Mar 2009, 04:02

I always thought that the BIOS will emulate this only via INTs (e.g. sata,usb keyboard) but direct i/o bypasses all of this, hence the need for pm drivers.

04 Mar 2009, 04:02

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 05:30

The controller hub converts the port access into an SMI (system management interrupt) - this is the way modern PC's boot off USB and is quite common. Protected mode does not interfere with SMM mode.

Quote:

By design, the OS cannot override or disable SMIs.

04 Mar 2009, 05:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20292
Location: In your JS exploiting you and your system

revolution 04 Mar 2009, 05:43

bitRAKE wrote:

The controller hub converts the port access into an SMI (system management interrupt) - this is the way modern PC's boot off USB and is quite common. Protected mode does not interfere with SMM mode.
Quote:
By design, the OS cannot override or disable SMIs.

Sure, as you say "Protected mode does not interfere with SMM mode". But what about the other way around? SMM mode does not interfere with protected mode? If want to access my USB port in high-speed mode then I don't want a SMM interrupt watching everything I am doing. That would be very slow (there is a large overhead with switching in/out of SMM). So I would want to turn that off somewhere in the hardware chipset.

04 Mar 2009, 05:43

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 05:57

revolution wrote:

If want to access my USB port in high-speed mode then I don't want a SMM interrupt watching everything I am doing.

You wouldn't be writing your high-speed USB driver to access the ATA ports, so no SMI takes place unless SMM has a need to interrupt those (USB ports), too. Yes, a conflict does exist, though.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

Last edited by bitRAKE on 04 Mar 2009, 06:04; edited 1 time in total

04 Mar 2009, 05:57

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20292
Location: In your JS exploiting you and your system

revolution 04 Mar 2009, 06:03

When I want to access the normal HDD (not the USB anymore) I have to tell the hardware that I need emulation turned off.

But actually, I thought what sinsi said was correct. That emulation is only for INT 13 access. bitRAKE: Do you have a reference for this behaviour of port emulation by SMM drivers?

04 Mar 2009, 06:03

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 04 Mar 2009, 06:17

So if I enable "legacy" mode in the BIOS for my USB mouse, the BIOS goes into SMM and redirects I/O to port 60/64 to the correct USB port? And if I tell windows that I have a PS/2 mouse, the driver will trigger a SMI which the BIOS handles (even in windows' pmode)?

Can we split this thread, since it's a bit off-topic and I am finding this bit interesting (the intel manuals are a bit dry...)

04 Mar 2009, 06:17

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 06:30

5.16.7.3 and 5.18.8 of the ICH9 manual (page 200 and 214, respectively) is what I'm currently reading, but it is quite common. The north bridge documentation has more on general SMI generation and SMM configuration. In the case of my hardware drivers access through the memory mapped addresses and have little need for port access - which are converted to memory accesses by the north bridge anyhow.

sinsi, absolutely, but a chipset driver might disable the legacy support.

04 Mar 2009, 06:30

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 04 Mar 2009, 06:42

bitRAKE wrote:

sinsi, absolutely, but a chipset driver might disable the legacy support.

But how?

Quote:

By design, the OS cannot override or disable SMIs.

Thanks for that ICH9 link, btw.

04 Mar 2009, 06:42

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 06:51

sinsi wrote:

bitRAKE wrote:
sinsi, absolutely, but a chipset driver might disable the legacy support.
But how?
Quote:
By design, the OS cannot override or disable SMIs.
Thanks for that ICH9 link, btw.

SMM is essentially locked from outside probing, but the chipset control flags are still available (section 14.1.37 linked in the manual). Unfortunately, some bits trigger a SMI, so SMM can lockout changes -- this is not the case with the emulation features.

That quote was from the Wikipedia article on SMM.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

04 Mar 2009, 06:51

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 04 Mar 2009, 07:10

So that is basically a way to disable the SMI (as far as sata is concerned)?

Code:

  mov eax,wiki
  add eax,NaCl

04 Mar 2009, 07:10

bitRAKE

Joined: 21 Jul 2003
Posts: 4016
Location: vpcmpistri

bitRAKE 04 Mar 2009, 07:21

and byte [PCIE_BASE + ATC_APM],-16
...should do it. Then reset the USB.

04 Mar 2009, 07:21

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 04 Mar 2009, 07:24

bitRAKE wrote:

and byte [PCIE_BASE + ATC_APM],-16
...should do it. Then reset the USB.

Ouch

04 Mar 2009, 07:24

Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum