>> Alternatively, why not use the fact that the chips with only
>> 0-63 as valid addresses effectively fold back 64-127 to 0-63
>> to auto-detect that fact.
> I am not too sure you could rely on this.
It was true on the IBM AT that I used to have, so it isn't a new
premise.
>> typedef unsigned char BYTE;
>> typedef unsigned short int WORD;
>>
>> #define RTC_SECONDS 0
>>
>> WORD cmos_ram_size(void)
>> {
>> WORD limit = 64;
>> BYTE new, old;
>>
>> while (limit < 32768) {
>> old = read_rtc(limit+RTC_SECONDS);
>> sleep( 1 );
>> new = read_rtc(limit+RTC_SECONDS);
>> if (old != new)
>> break;
>> limit <<= 1;
>> }
>> return (limit);
>> }
>> Assuming that the returned value indicates the size of the
>> CMOS's address space, and that read_rtc(addr) returns the
>> current value of the byte at the RTC's register with the
>> specified address, that will correctly handle CMOS chips
>> with up to 32k of CMOS RAM. I would tend
> wrong. RTC NVRAM has a single address byte, the msb of which
> is used to mask / unmask the nmi.
Can I suggest that you re-read what I wrote, as you have clearly
misunderstood it. For reference:
1. When I said "Assuming that the returned value...", I was
referring to the FUNCTION read_rtc() which is presumably
aware of exactly how to index the specific RTC chip in
the computer in question. If the chip matches your spec,
then the read_rtc() function will be masking the MSB out
anyway, so the function supplied will still work.
2. Not all RTC chips have a single address byte, nor do they
all share it in the manner you indicated. I have written
software for one system whose RTC/CMOS chip had 1010 bytes
of CMOS RAM in it, so I know they exist.
>> to assume that chips with larger RAM are not currently
>> available, but if they are, it's not hard to extend the
>> above to support them.
> there have been several approaches to larger NVRAM sizes (one
> for the PS/2 and one by Compaq at least).
In EVERY case, the ONLY difference as far as the routine I presented
is concerned is that the details of the read_rtc() function would vary
dependant on the precice chip used. As far as the presented routine is
concerned, the ONLY change would be if chips with more than 32k of
address space were to be supported, when one would need to make the
variable limit an unsigned long int and raise the limit in the while
statement, and it would then be capable of handling them.
>> The above code makes the following assumptions:
>> 1. The register at address 0 returns the current second as
>> stored in the RTC. I have NOT checked that this is the
>> correct offset, but if not, just put the relevant offset
>> in the definition of RTC_SECONDS.
>> 2. The result of the sleep(1) call will always be sufficient
>> for the second counter to tick over.
> 3. you have several seconds to wait for the autodetection
> to work
See my previous post dealing with that very point and how it can be
dealt with.
> 4. nobody else sets the RTC
Since we're talking about booting the kernel here, that doesn't even
come close to being relevant.
> 5. if you have an old RTC, it will handle the bit 6 set case
> correctly
Name one that does? The one used in the genuine IBM PC/AT didn't, and
all the early clones used the same chip, so you'll need to do more to
prove that claim than just make it...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/