flat assembler
Message board for the users of flat assembler.

Index > OS Construction > The REAL OS construction contest

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author
Thread Post new topic Reply to topic
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto
Quote:

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

OOPS Embarassed
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
Post 02 Mar 2009, 19:17
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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?)
Post 03 Mar 2009, 16:20
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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?
Post 03 Mar 2009, 17:04
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
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.
Post 03 Mar 2009, 17:57
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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)/¯ unlicense.org
Post 04 Mar 2009, 02:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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?
Post 04 Mar 2009, 03:13
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 04 Mar 2009, 03:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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!
Post 04 Mar 2009, 03:42
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
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.
Post 04 Mar 2009, 04:02
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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.
Post 04 Mar 2009, 05:30
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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.
Post 04 Mar 2009, 05:43
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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)/¯ unlicense.org


Last edited by bitRAKE on 04 Mar 2009, 06:04; edited 1 time in total
Post 04 Mar 2009, 05:57
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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?
Post 04 Mar 2009, 06:03
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
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...)
Post 04 Mar 2009, 06:17
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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.
Post 04 Mar 2009, 06:30
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
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.
Post 04 Mar 2009, 06:42
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
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)/¯ unlicense.org
Post 04 Mar 2009, 06:51
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
So that is basically a way to disable the SMI (as far as sata is concerned)?
Code:
  mov eax,wiki
  add eax,NaCl    
Post 04 Mar 2009, 07:10
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3056
Location: vpcmipstrm
bitRAKE
Laughing

and byte [PCIE_BASE + ATC_APM],-16
...should do it. Then reset the USB.
Post 04 Mar 2009, 07:21
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
bitRAKE wrote:
Laughing

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

Ouch Laughing
Post 04 Mar 2009, 07:24
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.