On Fri, Jan 21, 2011 at 11:40 AM,  <meino.cra...@gmx.de> wrote:
<SNIP>
> Hi Mark,
>
<SNIP>
> I thought (which implies "I dont know for sure"), that the BIOS do
> enable/disable certain features, the kernels reads that settings and
> act accordingly -- but definitely this is not true for all settings.
>

Certainly true for some hardware, like clocks, etc.

For disk controllers AFAIK the goal is to give the boot loader a
chance to boot. After that it doesn't, in general, matter what the
BIOS did.

For instance, modern SATA controllers use DMA. BIOS and older
operating systems like DOS didn't know much, if anything, about DMA,
so BIOS leaves that turned off. The kernel turns that on.

> Does the contents of a harddisk differ when written with AHCI
> compared to a disk which is written with IDE?
>

TTBOMK no. Other things like file system type, etc., change what's on
the disk, but the disk store so many bytes/sector and that's just the
way it works.


> If NO _AND_ only the kernel sets the AHCI- odr IDE-protocol, then
> the harddisk should be readable in either case.
>

Certainly, which is why you could build this system using AHCI and
then move it to some other system and read the disk using DOS.
(Assuming DOS could understand the file system like FAT, etc.)

> If the BIOS _and_ the kernel settings are defining, how to talk
> to the disk, then it may happen, that there is only the "sound of silence"
> between kernel and hardware if before the BIOS set up the SATA-chips
> differently to what the kernel wants to talk.
>

BIOS sets up the system hardware so the boot loader can get the kernel
image off the disk. The kernel is read into memory using these
settings. At that point there aren't any more disk reads for a while.
The kernel executes and starts resetting the hardware through driver
loads, etc. This is why one controller could be set to use a SATA
Drive by itself or RAID.

> But again, these are only thougts drifting in the dark.
>
> I tried to shed some more light (for getting greater shadows ;) )
> by posting my question here... ;) 8)
>
> May be I should do some more stupid things??? ;)
>

Ain't no such thing a stupid question. Only thing to do when
experimenting is ensure you aren't risking data you care about. I
would do these experiments on a new clean system. I would not do them
on a system that has stuff I care about unless I had known good
backups.

> Thanks again for your help and your words, Mark!
> Have a nice weekend!
> Best regards,
> mcc
>

You too sir!

Cheers,
Mark

Reply via email to