Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9752 > unrolled thread

PCI-enum and SouthBridge behaviour...

Back to article view | Back to alt.os.development

Contents

  PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-22 21:53 +0200
    Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-24 16:52 +0100
      Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-24 19:54 +0200
        Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-25 07:07 +0100
          Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-25 11:04 +0200
            Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-25 10:30 +0100
              Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-25 14:06 +0200
                Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-25 13:16 +0100
                  Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-26 13:09 +0200
                    Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-26 15:14 +0100
            Re: PCI-enum and SouthBridge behaviour... Rod Pemberton <NoHaveNotOne@bcczxcfrze.cam> - 2016-07-25 21:55 -0400
              Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-26 12:48 +0200
    Re: PCI-enum and SouthBridge behaviour... Rod Pemberton <NoHaveNotOne@bcczxcfrze.cam> - 2016-07-26 08:18 -0400
      Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-26 20:11 +0200
    Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-28 18:53 +0200
      Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-29 19:47 +0200
        Re: PCI-enum and SouthBridge behaviour... Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-07-29 17:44 -0400
          Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-30 09:44 +0200
      Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-30 12:55 +0100
        Re: PCI-enum and SouthBridge behaviour... "wolfgang kern" <nowhere@never.at> - 2016-07-30 19:40 +0200
          Re: PCI-enum and SouthBridge behaviour... James Harris <james.harris.1@gmail.com> - 2016-07-30 19:08 +0100

Page 1 of 2  [1] 2  Next page →

#9752 — PCI-enum and SouthBridge behaviour...

while I work on a new OS-version with most structures expanded 
and finally using UDMA for larger than disk-cache reads in the 
aspect of making all data-fields also usable within long mode, 
I figured a strange (yet for me unknown) BIOS behaviour:

when I boot from an IDE-connected drive and use BIOS calls like 
int11/12/14/17 (rather old and useless today anyway) I see 
much more PCI-devices (EHCI-USB, onboard SOUND and Bridges) 
than what I see if I boot from an SATA-drive with only a few 
BIOS calls (int15_e820,int10_0003,int13_4xxx).

the BIOS hide or just disable some PCI devices on the type of boot 
device? or is this any other BIOS function I havent seen so far ?

I can of course setup the (known by AMD southbridge docs) PCI-regs 
to reenable all expected PCI-devices, but why does BIOS disable it ?  

checked with and without USBtoPS/2 mouse-emulation yet, equal result.  
__
wolfgang 

[toc] | [next] | [standalone]

#9758

On 22/07/2016 20:53, wolfgang kern wrote:
> while I work on a new OS-version with most structures expanded and
> finally using UDMA for larger than disk-cache reads in the aspect of
> making all data-fields also usable within long mode, I figured a strange
> (yet for me unknown) BIOS behaviour:
>
> when I boot from an IDE-connected drive and use BIOS calls like
> int11/12/14/17 (rather old and useless today anyway) I see much more
> PCI-devices (EHCI-USB, onboard SOUND and Bridges) than what I see if I
> boot from an SATA-drive with only a few BIOS calls
> (int15_e820,int10_0003,int13_4xxx).
>
> the BIOS hide or just disable some PCI devices on the type of boot
> device? or is this any other BIOS function I havent seen so far ?
>
> I can of course setup the (known by AMD southbridge docs) PCI-regs to
> reenable all expected PCI-devices, but why does BIOS disable it ?
> checked with and without USBtoPS/2 mouse-emulation yet, equal result.  __

So, when you boot from IDE BIOS tells you one story but when you boot 
from SATA BIOS tells you a different story about connected devices?

First thought: Don't use the BIOS if you can avoid it. We know different 
BIOSes have different bugs. If you can detect what you need by hardware 
probing then you should be safer.

Walking the PCI bus (and other busses connected thereto) should 
enumerate everything, shouldn't it, on any PC made in the last 20 years 
or so? Before that there was PnP which would also allow enumeration.

That said, some chipsets may require special bits to be set in registers 
or they will hide some of their hardware. Is that the problem you are 
facing?


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9761

James Harris replied:

...
>> when I boot from an IDE-connected drive and use BIOS calls like
>> int11/12/14/17 (rather old and useless today anyway) I see much more
>> PCI-devices (EHCI-USB, onboard SOUND and Bridges) than what I see if I
>> boot from an SATA-drive with only a few BIOS calls
>> (int15_e820,int10_0003,int13_4xxx).

>> the BIOS hide or just disable some PCI devices on the type of boot
>> device? or is this any other BIOS function I havent seen so far ?

>> I can of course setup the (known by AMD southbridge docs) PCI-regs to
>> reenable all expected PCI-devices, but why does BIOS disable it ?
>> checked with and without USBtoPS/2 mouse-emulation yet, equal result.  __

> So, when you boot from IDE BIOS tells you one story but when you boot from 
> SATA BIOS tells you a different story about connected devices?

the BIOS disables some USB hosts (regardless of connected things) and
a few other devices too when I boot from SATA drive.

> First thought: Don't use the BIOS if you can avoid it. We know different 
> BIOSes have different bugs. If you can detect what you need by hardware 
> probing then you should be safer.

checked on another machine with different BIOS and a newer AMD-chipset
... same story.

> Walking the PCI bus (and other busses connected thereto) should enumerate 
> everything, shouldn't it, on any PC made in the last 20 years or so? 
> Before that there was PnP which would also allow enumeration.

Yes, but its hard to enumerate a device that dont show up.
perhaps thats why windoze need a lot of 'drivers' from mainboard vendor
and several reboot cycles to make all these unseen work.

> That said, some chipsets may require special bits to be set in registers 
> or they will hide some of their hardware. Is that the problem you are 
> facing?

Exact. I suspect that the BIOS modify too many southbridge bits for SATA.
I hoped there were known BIOS-functions to overrule this behaviour...

Meanwhile I have to run my whole PCI-scan one more time after chip-type
recognition and device enabling.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9763

On 24/07/2016 18:54, wolfgang kern wrote:
> James Harris replied:

...

>> Walking the PCI bus (and other busses connected thereto) should
>> enumerate everything, shouldn't it, on any PC made in the last 20
>> years or so? Before that there was PnP which would also allow
>> enumeration.
>
> Yes, but its hard to enumerate a device that dont show up.
> perhaps thats why windoze need a lot of 'drivers' from mainboard vendor
> and several reboot cycles to make all these unseen work.

Microsoft has always had the big advantage that hardware manufacturers 
will privately tell MS about their devices.

That said, Linux has to cope with the same problems. Maybe you could 
look at the Linux source?


>> That said, some chipsets may require special bits to be set in
>> registers or they will hide some of their hardware. Is that the
>> problem you are facing?
>
> Exact. I suspect that the BIOS modify too many southbridge bits for SATA.
> I hoped there were known BIOS-functions to overrule this behaviour...

That does sound like a good use for a BIOS because it would know what 
idiosyncratic hardware a machine contains. I don't know of any such 
functions.


> Meanwhile I have to run my whole PCI-scan one more time after chip-type
> recognition and device enabling.

That may be the only option. I guess that detecting chipset types is not 
easy to do reliably.

Measures of desperation: I take it there is no way on PCI scanning to 
reset busses and devices such that the hidden components are revealed? 
Any clue in /why/ the BIOS might hide some devices?

Your PCI scan won't take long, will it?

-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9766

 James Harris wrote:
...
>>> Walking the PCI bus (and other busses connected thereto) should
>>> enumerate everything, shouldn't it, on any PC made in the last 20
>>> years or so? Before that there was PnP which would also allow
>>> enumeration.

>> Yes, but its hard to enumerate a device that dont show up.
>> perhaps thats why windoze need a lot of 'drivers' from mainboard vendor
>> and several reboot cycles to make all these unseen work.

> Microsoft has always had the big advantage that hardware manufacturers 
> will privately tell MS about their devices.

> That said, Linux has to cope with the same problems. Maybe you could look 
> at the Linux source?

C-source ?  it wont show me much I'm afraid :(

I tried to get a clue about hardware features by disassembling a lot of
windoze drivers in the past, but recently I rely only on known hardware
mainly from AMD/ATI, where I'm well supported with documentations.

>>> That said, some chipsets may require special bits to be set in
>>> registers or they will hide some of their hardware. Is that the
>>> problem you are facing?

>> Exact. I suspect that the BIOS modify too many southbridge bits for SATA.
>> I hoped there were known BIOS-functions to overrule this behaviour...

> That does sound like a good use for a BIOS because it would know what 
> idiosyncratic hardware a machine contains. I don't know of any such 
> functions.

RBIL show only the INT1A_B1xx group.

>> Meanwhile I have to run my whole PCI-scan one more time after chip-type
>> recognition and device enabling.

> That may be the only option. I guess that detecting chipset types is not 
> easy to do reliably.

Type detection isn't too hard, just read vendor- and device-ID.
But it would be hard to support all things around today, so I limited
my support to certain known stuff.

> Measures of desperation: I take it there is no way on PCI scanning to 
> reset busses and devices such that the hidden components are revealed?

By any luck SMBUS-config, northbridge and IOs are always visible.

> Any clue in /why/ the BIOS might hide some devices?

Not at all, that's why I posted here.

> Your PCI scan won't take long, will it?

No, only a few mS if I just scan until all desired are found, but a full
scan over all possible 256 busses would take seconds.

__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9768

On 25/07/2016 10:04, wolfgang kern wrote:
> James Harris wrote:

>>>> Walking the PCI bus (and other busses connected thereto) should
>>>> enumerate everything, shouldn't it, on any PC made in the last 20
>>>> years or so? Before that there was PnP which would also allow
>>>> enumeration.
>
>>> Yes, but its hard to enumerate a device that dont show up.
>>> perhaps thats why windoze need a lot of 'drivers' from mainboard vendor
>>> and several reboot cycles to make all these unseen work.
>
>> Microsoft has always had the big advantage that hardware manufacturers
>> will privately tell MS about their devices.
>
>> That said, Linux has to cope with the same problems. Maybe you could
>> look at the Linux source?
>
> C-source ?  it wont show me much I'm afraid :(

Ah, I forgot who I was writing to...!

Maybe you can convert it to a hex dump. ;-)

...

>>> Meanwhile I have to run my whole PCI-scan one more time after chip-type
>>> recognition and device enabling.
>
>> That may be the only option. I guess that detecting chipset types is
>> not easy to do reliably.
>
> Type detection isn't too hard, just read vendor- and device-ID.

For the chipset? Where from? Something in the PCI scan?

Early machines had motherboard or machine identification in the top 
bytes of the ROM.

...

>> Your PCI scan won't take long, will it?
>
> No, only a few mS if I just scan until all desired are found, but a full
> scan over all possible 256 busses would take seconds.

Wouldn't you only attempt to scan a non-root PCI bus if you discover a 
bridge to it? IIRC PCI configs for bridges give the downstream bus 
number. So you wouldn't need to scan 256 busses unless you had a veeery 
big machine. ;-)

-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9769

 James Harris wrote:
...
>> Type detection isn't too hard, just read vendor- and device-ID.

> For the chipset? Where from? Something in the PCI scan?

Yes, I compare the first four bytes of PCI-config blocks to match 
what's in my (very short) list and check on version if found. 

> Early machines had motherboard or machine identification in the top 
> bytes of the ROM.

isn't this methode obsolete since many years ?

> ...
>>> Your PCI scan won't take long, will it?

>> No, only a few mS if I just scan until all desired are found, but a full
>> scan over all possible 256 busses would take seconds.

> Wouldn't you only attempt to scan a non-root PCI bus if you discover a 
> bridge to it? IIRC PCI configs for bridges give the downstream bus 
> number. So you wouldn't need to scan 256 busses unless you had a veeery 
> big machine. ;-)

bridges allow communication between apart busses, but devices like 
USB hosts, sound, graphic, LAN, firewire,.. should all show up on the 
BUS where they are connected to. 

While I know most details on motherboard and chipset in my machines 
including BUS-Device-Function for onchip devices, there may be a few 
new addons on the board which become configured by the BIOS. So my 
onboard sound report its PCI-config on BUS_07 and firewire on BUS_3.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9770

On 25/07/2016 13:06, wolfgang kern wrote:
> James Harris wrote:

...

>> Early machines had motherboard or machine identification in the top
>> bytes of the ROM.
>
> isn't this methode obsolete since many years ?

You know me. ;-)


>>>> Your PCI scan won't take long, will it?
>
>>> No, only a few mS if I just scan until all desired are found, but a full
>>> scan over all possible 256 busses would take seconds.
>
>> Wouldn't you only attempt to scan a non-root PCI bus if you discover a
>> bridge to it? IIRC PCI configs for bridges give the downstream bus
>> number. So you wouldn't need to scan 256 busses unless you had a
>> veeery big machine. ;-)
>
> bridges allow communication between apart busses, but devices like USB
> hosts, sound, graphic, LAN, firewire,.. should all show up on the BUS
> where they are connected to.

(I think you mean "separate" rather than "apart".)


> While I know most details on motherboard and chipset in my machines
> including BUS-Device-Function for onchip devices, there may be a few new
> addons on the board which become configured by the BIOS. So my onboard
> sound report its PCI-config on BUS_07 and firewire on BUS_3.

I am not sure how that relates to having to scan 256 potential bus 
numbers. Can you not find slave busses as you scan?

To make an example, you might scan bus 0 and find:

  a disk controller
  a video controller
  a bridge to bus 3
  a bridge to bus 7

AIUI the PCI enumeration process would then scan busses 3 and 7.

Basically, PCI enumeration would not need to scan all 256 bus numbers 
but only those if finds bridges to.

I might be wrong. This is just from memory.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9780

James Harris wrote:
> ...
>>> Early machines had motherboard or machine identification in the top
>>> bytes of the ROM.
>> isn't this methode obsolete since many years ?
> You know me. ;-)
 
Oh  yeah ;)
 
>>>>> Your PCI scan won't take long, will it?

>>>> No, only a few mS if I just scan until all desired are found, but a 
>>>> full scan over all possible 256 busses would take seconds.

>>> Wouldn't you only attempt to scan a non-root PCI bus if you discover a
>>> bridge to it? IIRC PCI configs for bridges give the downstream bus
>>> number. So you wouldn't need to scan 256 busses unless you had a
>>> veeery big machine. ;-)

>> bridges allow communication between apart busses, but devices like USB
>> hosts, sound, graphic, LAN, firewire,.. should all show up on the BUS
>> where they are connected to.
 
> (I think you mean "separate" rather than "apart".)

either wayk, I see this stripped off serial HT-busses "taken as apart" ;)  

>> While I know most details on motherboard and chipset in my machines
>> including BUS-Device-Function for onchip devices, there may be a few new
>> addons on the board which become configured by the BIOS. So my onboard
>> sound report its PCI-config on BUS_07 and firewire on BUS_3.
 
> I am not sure how that relates to having to scan 256 potential bus 
> numbers. Can you not find slave busses as you scan?
 
> To make an example, you might scan bus 0 and find:
>  a disk controller
>  a video controller
>  a bridge to bus 3
>  a bridge to bus 7
> AIUI the PCI enumeration process would then scan busses 3 and 7.

my problem with the SATA boot is that some bridges are hidden,
here is what I see with IDE boot and miss with SATA:
bridges: PCI to LPC  and one PCI to PCI.
devices: all (2) EHCI, one of the five OHCI and onchip Audio.   

what I figured so far is that the devices are enabled but hidden.
 
> Basically, PCI enumeration would not need to scan all 256 bus numbers 
> but only those if finds bridges to.
> I might be wrong. This is just from memory.

there is the INT1A_B101 BIOS function which tell largest BUS#.

Perhaps I misunderstood what PCI-to-PCI bridges are supposed to do 
and what info I may find within their config space.
Seems my collection of PCI docs isn't complete ...
do you know a reference where PCI-config for all class code 06 variants 
are described on bit-level ?
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9785

On 26/07/2016 12:09, wolfgang kern wrote:
> James Harris wrote:

...

>>>>>> Your PCI scan won't take long, will it?
>
>>>>> No, only a few mS if I just scan until all desired are found, but a
>>>>> full scan over all possible 256 busses would take seconds.
>
>>>> Wouldn't you only attempt to scan a non-root PCI bus if you discover a
>>>> bridge to it? IIRC PCI configs for bridges give the downstream bus
>>>> number. So you wouldn't need to scan 256 busses unless you had a
>>>> veeery big machine. ;-)
>
>>> bridges allow communication between apart busses, but devices like USB
>>> hosts, sound, graphic, LAN, firewire,.. should all show up on the BUS
>>> where they are connected to.
>
>> (I think you mean "separate" rather than "apart".)
>
> either wayk, I see this stripped off serial HT-busses "taken as apart" ;)

In English you could take something apart meaning to disconnect its 
pieces from one another.

Or things could be "taken as separate", i.e. taken as being separate.


>>> While I know most details on motherboard and chipset in my machines
>>> including BUS-Device-Function for onchip devices, there may be a few new
>>> addons on the board which become configured by the BIOS. So my onboard
>>> sound report its PCI-config on BUS_07 and firewire on BUS_3.
>
>> I am not sure how that relates to having to scan 256 potential bus
>> numbers. Can you not find slave busses as you scan?
>
>> To make an example, you might scan bus 0 and find:
>>  a disk controller
>>  a video controller
>>  a bridge to bus 3
>>  a bridge to bus 7
>> AIUI the PCI enumeration process would then scan busses 3 and 7.
>
> my problem with the SATA boot is that some bridges are hidden,

I know. I was talking about the time needed to scan all PCI busses.

> here is what I see with IDE boot and miss with SATA:
> bridges: PCI to LPC  and one PCI to PCI.
> devices: all (2) EHCI, one of the five OHCI and onchip Audio.
> what I figured so far is that the devices are enabled but hidden.

If you unhide them by setting a bit in the specific chipset then it does 
sound as though that would be the only solution - because the chipset 
would be the boss.

I guess there is another possibility, though unlikely. Since things such 
as PCI bridges are apparently configured by the BIOS before our OSes get 
control, perhaps the BIOS fails to configure everything on SATA boot. As 
I say, that seems less likely but, if if that is what is happening, 
perhaps you could do the configuration yourself. That would be portable 
and mean you not having to check for a specific chipset.

Another slim possibility: maybe you don't see the bridges in your 
SATA-booted enumeration because they (the bridges) have not been fully 
configured. And if a PCI bridge has not been configured you won't see 
anything behind it.


>> Basically, PCI enumeration would not need to scan all 256 bus numbers
>> but only those if finds bridges to.
>> I might be wrong. This is just from memory.
>
> there is the INT1A_B101 BIOS function which tell largest BUS#.
>
> Perhaps I misunderstood what PCI-to-PCI bridges are supposed to do and
> what info I may find within their config space.
> Seems my collection of PCI docs isn't complete ...
> do you know a reference where PCI-config for all class code 06 variants
> are described on bit-level ?

By far the best reference I have is in book form: PCI System 
Architecture, Mindshare Inc. I don't know if it tells you everything but 
it does go down to bit level.

Interestingly, it shows PCI-PCI bridges (class code 6) as having THREE 
bus numbers: Primary bus (upstream, i.e. towards the OS), Secondary bus 
(downstream), and Subordinate bus (highest downstream bus number).

Why three? Apparently the bridge forwards transactions downwards if the 
target bus number is between Secondary and Subordinate. Makes sense.

Nonetheless, my point is/was that you could find out the downstream bus 
number when you interrogate the bridge. No need to scan all 256 (or 
fewer if the BIOS - the lying BIOS perhaps - gives a different upper 
limit).


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9777

On Mon, 25 Jul 2016 11:04:42 +0200
"wolfgang kern" <nowhere@never.at> wrote:

> No, only a few mS if I just scan until all desired are found, but a
> full scan over all possible 256 busses would take seconds.

Can you do a full scan when you install your OS and save the output?
Then, do a short scan each boot to detect for changes to the known
AMD/ATI stuff with documentation?  You're not going to be supporting
that fuller set.  So why check for it multiple times?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9779

Rod Pemberton wrote:
 
>> No, only a few mS if I just scan until all desired are found, but a
>> full scan over all possible 256 busses would take seconds.
 
> Can you do a full scan when you install your OS and save the output?

I do a full scan for testing new hardware only.
The OS-installer just checks if the machine is KESYS-compliant and 
it wont install on unknown hardware anyway.

> Then, do a short scan each boot to detect for changes to the known
> AMD/ATI stuff with documentation? 

Yeah, after installed the boot will just check if anything changed. 

> You're not going to be supporting that fuller set.  So why check for 
> it multiple times?

For now I do it a second time when missing PCI-devices which I know 
to have inside after reactivate them. I still check if any preceding 
action can make my first PCI-scan show me all present devices.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9784

On Fri, 22 Jul 2016 21:53:22 +0200
"wolfgang kern" <nowhere@never.at> wrote:

> when I boot from an IDE-connected drive and use BIOS calls like 
> int11/12/14/17 (rather old and useless today anyway) I see 
> much more PCI-devices (EHCI-USB, onboard SOUND and Bridges) 
> than what I see if I boot from an SATA-drive with only a few 
> BIOS calls (int15_e820,int10_0003,int13_4xxx).

Is the SATA drive being emulated as IDE by BIOS?  Or, is this SATA
drive being used as native SATA?  If you're using BIOS calls, would
that mean the SATA drive is being emulated as IDE?

E.g., I can boot SATA drive emulated as IDE into DOS, but I can't
access other SATA drives from DOS.  I have to load SATA drivers in DOS
to access other SATA drives.  The SATA boot drive is being emulated as
an IDE drive by BIOS, but other drives aren't.

Could there be a similar issue or related issue here?  E.g., for an IDE
boot maybe the BIOS exposes other devices it may be emulating?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9788

Rod Pemberton wrote:
 
>> when I boot from an IDE-connected drive and use BIOS calls like 
>> int11/12/14/17 (rather old and useless today anyway) I see 
>> much more PCI-devices (EHCI-USB, onboard SOUND and Bridges) 
>> than what I see if I boot from an SATA-drive with only a few 
>> BIOS calls (int15_e820,int10_0003,int13_4xxx).
 
> Is the SATA drive being emulated as IDE by BIOS?  Or, is this SATA
> drive being used as native SATA?  If you're using BIOS calls, would
> that mean the SATA drive is being emulated as IDE?

SATA hosts can be set to work in "combined mode" (not emulated).
this is also known as SATA-native-mode + IDE-like port settings.  

> E.g., I can boot SATA drive emulated as IDE into DOS, but I can't
> access other SATA drives from DOS.  I have to load SATA drivers in DOS
> to access other SATA drives.  The SATA boot drive is being emulated as
> an IDE drive by BIOS, but other drives aren't.

That's right, DOS tools assume ports 01f0/0170 base ports while 
SATA connected drives reside somewhere else (inknown by DOS-tools)  
 .
> Could there be a similar issue or related issue here?  E.g., for an IDE
> boot maybe the BIOS exposes other devices it may be emulating?

I'm not sure yet about it, but the fact that I dont see the LPC-bridge 
when I boot from an SATA drive, tells me that the BIOS work different. 

__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9798

my ranting about missing PCI devices when I boot from SATA:

its again (remember my issues with boot from CD) a morphing BIOS story.
I couldn't figure why it behaves different, but it does.

my old (working since 2004) code use only PCI-mechanism 01 
(via port pair 0xcf8/0cfc) for PCI scan.

So when I boot from SATA the BIOS use PCI-mech 02 (IOMM) starting 
at 0xE000_0000 but I still have no idea why devices/functions arent
visible with PCI-mech 01 as well.

Finally I'll change my code to check if IOMM is available and use it.

thanks for all your replies,
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9802

btw, I checked on BIOS:
it compares 0x07d0 at boot to "NTLD" and if this match we see 
another version of the BIOS in addition to versions we already 
found if we boot from CD,DVD,IDE,SATA,SSD,USB,Smartcard,X-ROMs.

BIOS vendors seem to gain money by creeping into the arse of B.G.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9803

On Fri, 29 Jul 2016 19:47:23 +0200
"wolfgang kern" <nowhere@never.at> wrote:

> btw, I checked on BIOS:
> it compares 0x07d0 at boot to "NTLD" and if this match we see 
> another version of the BIOS in addition to versions we already 
> found if we boot from CD,DVD,IDE,SATA,SSD,USB,Smartcard,X-ROMs.
> 
> BIOS vendors seem to gain money by creeping into the arse of B.G.

0x07d0 is an offset for what? memory? boot sector?

Should this NTLD field be blanked by someone coding a boot sector?

Is this a standard BIOS machine or UEFI?

Any idea on what is loaded in extra BIOS? boot loader? UEFI?

Does this NTLD field have anything to do with your issue?

Are you sure your BIOS is not infected?

BIOS rootkit
https://www.virusbulletin.com/virusbulletin/2011/10/new-bios-rootkit-spreads-china

Is this something to do with Secure Boot?

Secure Boot disables a BIOS CSM module for normal booting.
This is supposedly for UEFI v2.3.1 Errata C or later.

Could this CSM module be the other version of BIOS that you're seeing?

Apparently, UEFI can't be disabled on newer PCs.
http://www.pcworld.com/article/2901262/microsoft-tightens-windows-10s-secure-boot-screws-where-does-that-leave-linux.html

Does anyone know if UEFI Secure Boot on new motherboards is preventing
older Linux distributions from being installed?

Does anyone know if newer PCs cannot boot custom boot loaders?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9805

Rod Pemberton wrote:

>> btw, I checked on BIOS:
>> it compares 0x07d0 at boot to "NTLD" and if this match we see
>> another version of the BIOS in addition to versions we already
>> found if we boot from CD,DVD,IDE,SATA,SSD,USB,Smartcard,X-ROMs.

>> BIOS vendors seem to gain money by creeping into the arse of B.G.

> 0x07d0 is an offset for what? memory? boot sector?

the four bytes are compared with [07d0:0050] which is offset 0x0150
in the MBR sector.

> Should this NTLD field be blanked by someone coding a boot sector?

it would rare contain "NTLD" if not a windoze MBR.

> Is this a standard BIOS machine or UEFI?

UEFI can be enabled/disabled by my BIOS-setup, I disabled it.

> Any idea on what is loaded in extra BIOS? boot loader? UEFI?

havent checked which functions of the BIOS will become different,
I just figured that it's morphing similar to the CD-boot.

> Does this NTLD field have anything to do with your issue?

No. I stumbled over it while I searched the BIOS on PCI-issues.

> Are you sure your BIOS is not infected?

Yes, sure not infected, it met only me and KESYS yet :)
perhaps it's just different to what I'm familiar with.
I'll check if new specifications are available.

> BIOS rootkit
> https://www.virusbulletin.com/virusbulletin/2011/10/new-bios-rootkit-spreads-china

> Is this something to do with Secure Boot?

could be..

> Secure Boot disables a BIOS CSM module for normal booting.
> This is supposedly for UEFI v2.3.1 Errata C or later.

> Could this CSM module be the other version of BIOS that you're seeing?

I havent 'seen' the other version working, I just disassembled functions
within 0e_0000..0f_ffff and some of the many 16 and 32bit parts found in
the BIOS-ROM itself at the topmost 4MB below 4GB.

> Apparently, UEFI can't be disabled on newer PCs.
> http://www.pcworld.com/article/2901262/microsoft-tightens-windows-10s-secure-boot-screws-where-does-that-leave-linux.html

If I could not disable UEFI on my motherboards I'd send it back.

> Does anyone know if UEFI Secure Boot on new motherboards is preventing
> older Linux distributions from being installed?

> Does anyone know if newer PCs cannot boot custom boot loaders?

dont know, it may depend on 'who' touched it first,  I buy only
components and assemble and setup my machines as desired.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9809

On 28/07/2016 17:53, wolfgang kern wrote:
>
> my ranting about missing PCI devices when I boot from SATA:
>
> its again (remember my issues with boot from CD) a morphing BIOS story.
> I couldn't figure why it behaves different, but it does.
>
> my old (working since 2004) code use only PCI-mechanism 01 (via port
> pair 0xcf8/0cfc) for PCI scan.

According to my PCI book that has been THE way to access PCI 
configuration since at least PCI 2.2.

There was an older way, via two byte-wide ports at 0xcf8/0xcfa.

But neither would work on machines which do not have an IO space. They 
would have to use memory mapping. Are you saying, below, that you are 
using memory mapping to do PCI configuration? If so, how do you begin 
the process, e.g. to find out where the PCI devices are mapped?

> So when I boot from SATA the BIOS use PCI-mech 02 (IOMM) starting at
> 0xE000_0000 but I still have no idea why devices/functions arent
> visible with PCI-mech 01 as well.
>
> Finally I'll change my code to check if IOMM is available and use it.

So you get full results from memory mapped PCI config, even when you 
boot from SATA? But on SATA boot IO-based config hides some devices?


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#9814

James Harris wrote:

>> my ranting about missing PCI devices when I boot from SATA:

>> its again (remember my issues with boot from CD) a morphing BIOS story.
>> I couldn't figure why it behaves different, but it does.

>> my old (working since 2004) code use only PCI-mechanism 01 (via port
>> pair 0xcf8/0cfc) for PCI scan.
 
> According to my PCI book that has been THE way to access PCI 
> configuration since at least PCI 2.2.
 
> There was an older way, via two byte-wide ports at 0xcf8/0xcfa.
 
> But neither would work on machines which do not have an IO space. They 
> would have to use memory mapping. Are you saying, below, that you are 
> using memory mapping to do PCI configuration? If so, how do you begin 
> the process, e.g. to find out where the PCI devices are mapped?

Yes, and I get it from "MMIO Configuration Base Address Register" 
this is MSR C001_0058 on AMD CPUs (dont know where Intel have it).

>> So when I boot from SATA the BIOS use PCI-mech 02 (IOMM) starting at
>> 0xE000_0000 but I still have no idea why devices/functions arent
>> visible with PCI-mech 01 as well.
>> Finally I'll change my code to check if IOMM is available and use it.
 
> So you get full results from memory mapped PCI config, even when you 
> boot from SATA? 

Yes, all devices and functions are visible and easier accessible too.

> But on SATA boot IO-based config hides some devices? 

unfortunately yes, it could be a bug or something I havent figured yet. 
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.development

csiph-web