summaryrefslogtreecommitdiff
path: root/src/mainboard/ibm/e325/cmos.layout
AgeCommit message (Collapse)Author
2010-04-08Replace dual_core and quad_core CMOS (nvram) options with multi_core. Fix ↵Myles Watson
some white space. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5380 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-30unify cmos.layout wrt AMD extended configuration registers.Stefan Reinauer
This removes double preprocessor define warnings from many boards. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5323 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-03Revert "CMOS: Add set_option and rework get_option."Luc Verhaegen
This reverts commit eb7bb49eb5b48c39baf7a256b7c74e23e3da5660. Stepan pointed out that "s" means string, which makes the following statement in this commit message invalid: "Since we either have reserved space (which we shouldn't do anything with in these two functions), an enum or a hexadecimal value, unsigned int seemed like the way to go." Signed-off-by: Luc Verhaegen <libv@skynet.be> Acked-by: Luc Verhaegen <libv@skynet.be> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4335 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-03CMOS: Add set_option and rework get_option.Luc Verhaegen
To ease some of my debugging pain on the unichrome, i decided i needed to move FB size selection into cmos, so i could test a size and then reset it to the default after loading this value so that the next reboot uses the (working) default again. This meant implementing set_option in parallel to get_option. get_option was then found to have inversed argument ordering (like outb) and passing char * and then depending on the cmos layout length, which made me feel quite uncomfortable. Since we either have reserved space (which we shouldn't do anything with in these two functions), an enum or a hexadecimal value, unsigned int seemed like the way to go. So all users of get_option now have their arguments inversed and switched from using ints to unsigned ints now. The way get_cmos_value was implemented forced us to not overlap byte and to have multibyte values be byte aligned. This logic is now adapted to do a full uint32_t read (when needed) at any offset and any length up to 32, and the shifting all happens inside an uint32_t as well. set_cmos_value was implemented similarly. Both routines have been extensively tested in a quick separate little program as it is not easy to get this stuff right. build_opt_tbl.c was altered to function correctly within these new parameters. The enum value retrieval has been changed strol(..., NULL, 10) to stroul(..., NULL, 0), so that we not only are able to use unsigned ints now but so that we also interprete hex values correctly. The 32bit limit gets imposed on all entries not marked reserved, an unused "user_data" field that appeared in a lot of cmos.layouts has been changed to reserved as well. Signed-off-by: Luc Verhaegen <libv@skynet.be> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4332 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-05-01Trivial patch to make #defines generated from cmos.layout have unique names. ↵Myles Watson
Kills a few more compiler warnings. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4243 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2006-07-19closing issue 44: rename ram clocks in cmos.layoutStefan Reinauer
https://openbios.org/roundup/linuxbios/issue44 git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2340 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2005-12-02issue 41 - fix up motherboard compilation. There's always hope.Stefan Reinauer
1201_ht_bus0_dev0_fidvid_mb.diff part 1 git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2120 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-03-18e325 supportRonald G. Minnich
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1440 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1