1 |
Mark Knecht <markknecht@×××××.com> [11-01-21 21:04]: |
2 |
> On Fri, Jan 21, 2011 at 11:40 AM, <meino.cramer@×××.de> wrote: |
3 |
> <SNIP> |
4 |
> > Hi Mark, |
5 |
> > |
6 |
> <SNIP> |
7 |
> > I thought (which implies "I dont know for sure"), that the BIOS do |
8 |
> > enable/disable certain features, the kernels reads that settings and |
9 |
> > act accordingly -- but definitely this is not true for all settings. |
10 |
> > |
11 |
> |
12 |
> Certainly true for some hardware, like clocks, etc. |
13 |
> |
14 |
> For disk controllers AFAIK the goal is to give the boot loader a |
15 |
> chance to boot. After that it doesn't, in general, matter what the |
16 |
> BIOS did. |
17 |
> |
18 |
> For instance, modern SATA controllers use DMA. BIOS and older |
19 |
> operating systems like DOS didn't know much, if anything, about DMA, |
20 |
> so BIOS leaves that turned off. The kernel turns that on. |
21 |
> |
22 |
> > Does the contents of a harddisk differ when written with AHCI |
23 |
> > compared to a disk which is written with IDE? |
24 |
> > |
25 |
> |
26 |
> TTBOMK no. Other things like file system type, etc., change what's on |
27 |
> the disk, but the disk store so many bytes/sector and that's just the |
28 |
> way it works. |
29 |
> |
30 |
> |
31 |
> > If NO _AND_ only the kernel sets the AHCI- odr IDE-protocol, then |
32 |
> > the harddisk should be readable in either case. |
33 |
> > |
34 |
> |
35 |
> Certainly, which is why you could build this system using AHCI and |
36 |
> then move it to some other system and read the disk using DOS. |
37 |
> (Assuming DOS could understand the file system like FAT, etc.) |
38 |
> |
39 |
> > If the BIOS _and_ the kernel settings are defining, how to talk |
40 |
> > to the disk, then it may happen, that there is only the "sound of silence" |
41 |
> > between kernel and hardware if before the BIOS set up the SATA-chips |
42 |
> > differently to what the kernel wants to talk. |
43 |
> > |
44 |
> |
45 |
> BIOS sets up the system hardware so the boot loader can get the kernel |
46 |
> image off the disk. The kernel is read into memory using these |
47 |
> settings. At that point there aren't any more disk reads for a while. |
48 |
> The kernel executes and starts resetting the hardware through driver |
49 |
> loads, etc. This is why one controller could be set to use a SATA |
50 |
> Drive by itself or RAID. |
51 |
> |
52 |
> > But again, these are only thougts drifting in the dark. |
53 |
> > |
54 |
> > I tried to shed some more light (for getting greater shadows ;) ) |
55 |
> > by posting my question here... ;) 8) |
56 |
> > |
57 |
> > May be I should do some more stupid things??? ;) |
58 |
> > |
59 |
> |
60 |
> Ain't no such thing a stupid question. Only thing to do when |
61 |
> experimenting is ensure you aren't risking data you care about. I |
62 |
> would do these experiments on a new clean system. I would not do them |
63 |
> on a system that has stuff I care about unless I had known good |
64 |
> backups. |
65 |
> |
66 |
> > Thanks again for your help and your words, Mark! |
67 |
> > Have a nice weekend! |
68 |
> > Best regards, |
69 |
> > mcc |
70 |
> > |
71 |
> |
72 |
> You too sir! |
73 |
> |
74 |
> Cheers, |
75 |
> Mark |
76 |
> |
77 |
|
78 |
:) Thanks for your explanations, Mark! |
79 |
|
80 |
I have a complete mirror of the harddisk in question on another |
81 |
identical harddisk... |
82 |
Despite "others" may think...I am not /that/ stupid, hahahahahahahaha! |
83 |
:) 8) X) |
84 |
|
85 |
Best regards, |
86 |
mcc |