See patch.
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
Uwe.
On 27/03/08 21:24 +0100, Uwe Hermann wrote:
See patch.
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
Uwe.
http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Add initial support for some basic CMOS read/write functions and the bcd2dec()/dec2bcd() functions we'll need for (among other things) converting some date/time parameters in CMOS.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Acked-by: Jordan Crouse jordan.crouse@amd.com
Good stuff!
Index: include/libpayload.h
--- include/libpayload.h (Revision 3190) +++ include/libpayload.h (Arbeitskopie) @@ -41,6 +41,18 @@ #define MAX(a,b) ((a) > (b) ? (a) : (b)) #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+/* Some CMOS byte definitions */ +#define CMOS_RTC_SECONDS 0 +#define CMOS_RTC_MINUTES 2 +#define CMOS_RTC_HOURS 4 +#define CMOS_RTC_DAY 7 +#define CMOS_RTC_MONTH 8 +#define CMOS_RTC_YEAR 9
+/* drivers/cmos.c */ +u8 cmos_read(u8 addr); +void cmos_write(u8 val, u8 addr);
/* drivers/keyboard.c */ int keyboard_havechar(void); unsigned char keyboard_get_scancode(void); @@ -87,6 +99,10 @@ void *calloc(size_t nmemb, size_t size); void *realloc(void *ptr, size_t size);
+/* libc/lib.c */ +int bcd2dec(int b); +int dec2bcd(int d);
/* libc/memory.c */ void *memset(void *s, int c, size_t n); void *memcpy(void *dst, const void *src, size_t n); Index: libc/Makefile.inc =================================================================== --- libc/Makefile.inc (Revision 3190) +++ libc/Makefile.inc (Arbeitskopie) @@ -28,5 +28,4 @@ ##
TARGETS-y += libc/malloc.o libc/printf.o libc/console.o libc/string.o -TARGETS-y += libc/memory.o libc/ctype.o -TARGETS-y += libc/ipchecksum.o +TARGETS-y += libc/memory.o libc/ctype.o libc/ipchecksum.o libc/lib.o Index: libc/lib.c =================================================================== --- libc/lib.c (Revision 0) +++ libc/lib.c (Revision 0) @@ -0,0 +1,51 @@ +/*
- This file is part of the libpayload project.
- Copyright (C) 2008 Uwe Hermann uwe@hermann-uwe.de
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
- Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
- The name of the author may not be used to endorse or promote products
- derived from this software without specific prior written permission.
- THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- SUCH DAMAGE.
- */
+/*
- Convert a number in BCD format to decimal.
- @param b The BCD number.
- @return The given BCD number in decimal format.
- */
+int bcd2dec(int b) +{
- return ((b >> 4) & 0x0f) * 10 + (b & 0x0f);
+}
+/*
- Convert a number in decimal format into the BCD format.
- @param d The decimal number.
- @return The given decimal number in BCD format.
- */
+int dec2bcd(int d) +{
- return ((d / 10) << 4) | (d % 10);
+}
Index: Config.in
--- Config.in (Revision 3190) +++ Config.in (Arbeitskopie) @@ -68,6 +68,10 @@ depends VGA_CONSOLE default y
+config CMOS
bool "Support for reading/writing CMOS bytes"default yendmenu
menu "Build Options" Index: drivers/cmos.c =================================================================== --- drivers/cmos.c (Revision 0) +++ drivers/cmos.c (Revision 0) @@ -0,0 +1,69 @@ +/*
- This file is part of the libpayload project.
- Copyright (C) 2008 Uwe Hermann uwe@hermann-uwe.de
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
- Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
- The name of the author may not be used to endorse or promote products
- derived from this software without specific prior written permission.
- THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- SUCH DAMAGE.
- */
+/*
- Datasheet:
- Name: MC146818: Real-time Clock Plus RAM (RTC)
- Order number: MC146818/D
- */
+/*
- See also:
- */
+#include <libpayload.h>
+#define RTC_PORT 0x70
+/**
- Read a byte from the specified CMOS address.
- @param addr The CMOS address to read a byte from.
- @return The byte at the given CMOS address.
- */
+u8 cmos_read(u8 addr) +{
- outb(addr, RTC_PORT);
- return inb(RTC_PORT + 1);
+}
+/**
- Write a byte to the specified CMOS address.
- @param val The byte to write to CMOS.
- @param addr The CMOS address to write to.
- */
+void cmos_write(u8 val, u8 addr) +{
- outb(addr, RTC_PORT);
- outb(val, RTC_PORT + 1);
+} Index: drivers/Makefile.inc =================================================================== --- drivers/Makefile.inc (Revision 3190) +++ drivers/Makefile.inc (Arbeitskopie) @@ -31,3 +31,4 @@ TARGETS-$(CONFIG_SERIAL_CONSOLE) += drivers/serial.o TARGETS-$(CONFIG_VGA_CONSOLE) += drivers/vga.o TARGETS-$(CONFIG_PC_KEYBOARD) += drivers/keyboard.o +TARGETS-$(CONFIG_CMOS) += drivers/cmos.o
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Mar 27, 2008 at 03:05:23PM -0600, Jordan Crouse wrote:
Add initial support for some basic CMOS read/write functions and the bcd2dec()/dec2bcd() functions we'll need for (among other things) converting some date/time parameters in CMOS.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Acked-by: Jordan Crouse jordan.crouse@amd.com
Thanks, r3192.
Uwe.
On Thu, Mar 27, 2008 at 09:24:08PM +0100, Uwe Hermann wrote:
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
It would be nice to use NVRAM instead of CMOS. Looks good!
//Peter
On Thu, Mar 27, 2008 at 11:21:53PM +0100, Peter Stuge wrote:
On Thu, Mar 27, 2008 at 09:24:08PM +0100, Uwe Hermann wrote:
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
It would be nice to use NVRAM instead of CMOS. Looks good!
Hm, yeah, I thought about it, NVRAM is probably the more correct term these days, but the original datasheet (from the 80ies or so) didn't use that and I think the general user base is used to the term CMOS a bit more.
I don't care too much, though, I wouldn't object renaming it to NVRAM.
Uwe.
Uwe Hermann wrote:
On Thu, Mar 27, 2008 at 11:21:53PM +0100, Peter Stuge wrote:
On Thu, Mar 27, 2008 at 09:24:08PM +0100, Uwe Hermann wrote:
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
It would be nice to use NVRAM instead of CMOS. Looks good!
Hm, yeah, I thought about it, NVRAM is probably the more correct term these days, but the original datasheet (from the 80ies or so) didn't use that and I think the general user base is used to the term CMOS a bit more.
I don't care too much, though, I wouldn't object renaming it to NVRAM.
I vote for nvram, too, especially if we plan going to non-x86 architectures again. CMOS is really an odd term, I think it got molded by the legacy bios vendors over the years.
I don't care too much, though, I wouldn't object renaming it to NVRAM.
I vote for nvram, too, especially if we plan going to non-x86 architectures again. CMOS is really an odd term, I think it got molded by the legacy bios vendors over the years.
On embedded platforms, some sectors of flash are used for this kind of stuff.
Rudolf
On 28/03/08 10:41 +0100, Stefan Reinauer wrote:
Uwe Hermann wrote:
On Thu, Mar 27, 2008 at 11:21:53PM +0100, Peter Stuge wrote:
On Thu, Mar 27, 2008 at 09:24:08PM +0100, Uwe Hermann wrote:
I'll follow-up with a coreinfo patch to dump the whole CMOS array.
It would be nice to use NVRAM instead of CMOS. Looks good!
Hm, yeah, I thought about it, NVRAM is probably the more correct term these days, but the original datasheet (from the 80ies or so) didn't use that and I think the general user base is used to the term CMOS a bit more.
I don't care too much, though, I wouldn't object renaming it to NVRAM.
I vote for nvram, too, especially if we plan going to non-x86 architectures again. CMOS is really an odd term, I think it got molded by the legacy bios vendors over the years.
On the other hand, CMOS is the agreed upon term for x86 platforms - it sounds stupid to our ears, but we're not typical users. I would stick with CMOS.
Regardless of where people think they are going to take coreboot (I have serious doubts about the usefulness of coreboot on other architectures, especially the ones being bandied about on the email list), we need to remember that coreboot is targeted at x86, and thats where all of its users and potential users will come from for the near future. We shouldn't go out of our way to alienate a real x86 user so that we can embrace a mythical MIPS user.
Jordan
On Fri, Mar 28, 2008 at 08:42:41AM -0600, Jordan Crouse wrote:
I vote for nvram, too, especially if we plan going to non-x86 architectures again. CMOS is really an odd term, I think it got molded by the legacy bios vendors over the years.
On the other hand, CMOS is the agreed upon term for x86 platforms - it sounds stupid to our ears, but we're not typical users. I would stick with CMOS.
I prefer to educate users rather than bending around a bad habit.
Regardless of where people think they are going to take coreboot (I have serious doubts about the usefulness of coreboot on other architectures, especially the ones being bandied about on the email list), we need to remember that coreboot is targeted at x86, and thats where all of its users and potential users will come from for the near future.
I don't agree at all that coreboot is targeted exclusively at x86. If other architectures can use new bootcode like the PC then I would love for coreboot to be that new bootcode.
Yes, today it is all x86, but if the hardware can be used in other architectures then the software should as well.
In a few desktop machine generations, when Windows has been better abstracted, the PC arch will linger no more.
AMD/NatSemi already threw it out with the Geode arch.
I think we'll have better code in v4 if we already keep other archs in mind. (Not jump through hoops to befriend them, but just keep them in mind.)
//Peter
On 29.03.2008 02:26, Peter Stuge wrote:
On Fri, Mar 28, 2008 at 08:42:41AM -0600, Jordan Crouse wrote:
Regardless of where people think they are going to take coreboot (I have serious doubts about the usefulness of coreboot on other architectures, especially the ones being bandied about on the email list), we need to remember that coreboot is targeted at x86, and thats where all of its users and potential users will come from for the near future.
I don't agree at all that coreboot is targeted exclusively at x86. If other architectures can use new bootcode like the PC then I would love for coreboot to be that new bootcode.
Yes, today it is all x86, but if the hardware can be used in other architectures then the software should as well.
v1 had Alpha, PPC and x86, v2 has PPC and x86, v3 will have MIPS and x86. I strongly dispute the notion that coreboot is x86 only. x86 may be the predominant architecture right now, but if the MIPS efforts take off, we have the chance to test our abstraction model.
I think we'll have better code in v4 if we already keep other archs in mind. (Not jump through hoops to befriend them, but just keep them in mind.)
I'm scared. The development I plan for v3 will give us significant reductions in code duplication and config duplication compared to what we now have on v3. If there is any reason to plan v4 in the next few years, I'd like to know.
Regards, Carl-Daniel
On 29/03/08 02:26 +0100, Peter Stuge wrote:
On Fri, Mar 28, 2008 at 08:42:41AM -0600, Jordan Crouse wrote:
I vote for nvram, too, especially if we plan going to non-x86 architectures again. CMOS is really an odd term, I think it got molded by the legacy bios vendors over the years.
On the other hand, CMOS is the agreed upon term for x86 platforms - it sounds stupid to our ears, but we're not typical users. I would stick with CMOS.
I prefer to educate users rather than bending around a bad habit.
The problem is - our users aren't interested in being educated, they are interested in making their stuff work. Taking the high road benefits nobody (yeah, I know that this is the story of the legacy PC world, but its the world we live in).
I don't agree at all that coreboot is targeted exclusively at x86. If other architectures can use new bootcode like the PC then I would love for coreboot to be that new bootcode.
Yes, today it is all x86, but if the hardware can be used in other architectures then the software should as well.
In a few desktop machine generations, when Windows has been better abstracted, the PC arch will linger no more.
AMD/NatSemi already threw it out with the Geode arch.
I think we'll have better code in v4 if we already keep other archs in mind. (Not jump through hoops to befriend them, but just keep them in mind.)
This won't come as a surprise to anybody, but we are lagging years behind the other architectures. There are already very good free and open source boot monitors for many of the other architectures. I view the coreboot effort not as creating something new and magical, but rather as dragging the x86 into modern times to catchup with its cousins that long ago passed it in terms of cluefulness. I hate the idea of spending valuable cycles thinking about other architectures when we're still so far away from making our primary one work. Just my opinion.
Jordan
On Mon, Mar 31, 2008 at 09:25:04AM -0600, Jordan Crouse wrote:
This won't come as a surprise to anybody, but we are lagging years behind the other architectures. There are already very good free and open source boot monitors for many of the other architectures. I view the coreboot effort not as creating something new and magical, but rather as dragging the x86 into modern times to catchup with its cousins that long ago passed it in terms of cluefulness. I hate the idea of spending valuable cycles thinking about other architectures when we're still so far away from making our primary one work. Just my opinion.
I think we all agree that we have lots of work left to be done on x86.
We surely wouldn't object to patches for non-x86 architectures though, and it's also a good idea to keep our code as archıtecture-independent and generic as possible to make porting easier.
But yes, I'm personally not _too_ interested in spending lots of time in porting coreboot to architectures which _already_ have perfectly supported, open-source bootloader and firmware projects. There's not much point in re-inventing/re-implementing Uboot, or YABOOT, or whatever just for the sake of it (but again -- patches in that direction will not be rejected of course, if somebody wants to do the work).
Uwe.
On Monday 31 March 2008, Jordan Crouse wrote:
On 29/03/08 02:26 +0100, Peter Stuge wrote:
On Fri, Mar 28, 2008 at 08:42:41AM -0600, Jordan Crouse wrote:
On the other hand, CMOS is the agreed upon term for x86 platforms - it sounds stupid to our ears, but we're not typical users. I would stick with CMOS.
I prefer to educate users rather than bending around a bad habit.
CMOS RAM is a krufty legacy from the 1980ies, well known by that name. It simply _is_not_ NVRAM, like it appeared shortly after on SparcStations. I'd really *love* to store OFW boot device, path and args in it, but those lousy 112 Bytes are only good for tight bit packing.
This won't come as a surprise to anybody, but we are lagging years behind the other architectures. [...] I hate the idea of spending valuable cycles thinking about other architectures when we're still so far away from making our primary one work. Just my opinion.
Full Ack. I do not want to go on a crusade to preach an abstraction which is not practical. The x86 PC does not have NVRAM as we know it; CMOS RAM is different, because it is so much smaller, so let's call it differently.
Torsten
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
Rudolf Marek -
Stefan Reinauer -
Torsten Duwe -
Uwe Hermann