Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote: On Tue, Sep 22, 2009 at 01:56:53PM +0200, Peter Stuge wrote: Check out the 5536 data book on Atomic Bit Programming and/or look at the Linux LED driver for reference. To program the GPIOs you have to follow the algorithm outlined in 6.16.1. Hmm. I followed that guideline, and did the same thing than the Linux driver, but it still doesn't work. I only found one location from where I could successfully write to the GPIO registers, and that is hardware_stage1() in mainboard/pcengines/alix2c3/stage.c. When moving the same code to southbridge_init() in southbridge/amd/cs5536/cs5536.c, the register accesses fail. Also, when booting Linux, the LED driver does not work with coreboot for me. The register space mapping seems to be given up at some point on the way, but I can't figure out where and why yet. As I don't know coreboot's internals, I'd appreciate any pointer. I traced a little further and implemented a cs5536_set_resources() which simply wraps the call to pci_set_resources(). GPIO registers are accessed ok before pci_set_resources() but fail after. This is the output of print_resource_tree() of the device used: (CB) PCI: 00:0f.0 links 0 child on link 0 NULL (CB) PCI: 00:0f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags e100 index 0 (CB) PCI: 00:0f.0 resource base 20b0 size 8 align 3 gran 3 limit flags 4100 index 10 (CB) PCI: 00:0f.0 resource base 1800 size 100 align 8 gran 8 limit flags 4100 index 14 (CB) PCI: 00:0f.0 resource base 2000 size 40 align 6 gran 6 limit flags 4100 index 18 (CB) PCI: 00:0f.0 resource base 2080 size 20 align 5 gran 5 limit flags 4100 index 1c (CB) PCI: 00:0f.0 resource base 1c00 size 80 align 7 gran 7 limit flags 4100 index 20 (CB) PCI: 00:0f.0 resource base 2040 size 40 align 6 gran 6 limit flags 4100 index 24 Any ideas? Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] buildrom/filo build fix
Daniel Mack wrote: buildrom does not currently build filo due to a missing include path. This fixes it. --- Index: Makefile === --- Makefile (revision 94) +++ Makefile (working copy) @@ -76,7 +76,7 @@ LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) OBJS := $(patsubst %,$(obj)/%,$(TARGETS-y)) -INCLUDES := -I$(INCPAYLOAD) -Iinclude -I$(ARCHDIR-y)/include -Ibuild +INCLUDES := -I$(INCPAYLOAD) -I$(INCPAYLOAD)/$(ARCHDIR-y) -Iinclude -I$(ARCHDIR-y)/include -Ibuild INCLUDES += -I$(GCCINCDIR) try-run= $(shell set -e; \ What's your error without this? Is that a patch against FILO? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] buildrom/filo build fix
On Wed, Sep 23, 2009 at 11:43:02AM +0200, Stefan Reinauer wrote: Daniel Mack wrote: buildrom does not currently build filo due to a missing include path. This fixes it. --- Index: Makefile === --- Makefile(revision 94) +++ Makefile(working copy) @@ -76,7 +76,7 @@ LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) OBJS := $(patsubst %,$(obj)/%,$(TARGETS-y)) -INCLUDES := -I$(INCPAYLOAD) -Iinclude -I$(ARCHDIR-y)/include -Ibuild +INCLUDES := -I$(INCPAYLOAD) -I$(INCPAYLOAD)/$(ARCHDIR-y) -Iinclude -I$(ARCHDIR-y)/include -Ibuild INCLUDES += -I$(GCCINCDIR) try-run= $(shell set -e; \ What's your error without this? Is that a patch against FILO? It couldn't find arch specific includes. But it was all due to an old version of filo - the fix went in upstream with r98. Buildrom uses r104 now, so it's all fine. Sorry for the noise. Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] FILO: parse old ext2 revisions correctly
This patch applies against r104 of filo and allows older versions of ext2 file systems to be accessed. The problem with the current code is that EXT2_INODE_SIZE() returns 0 for these file systems and the EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a div0 and sends the machine to reboot. Below is a fix for that. Signed-off-by: Daniel Mack dan...@caiaq.de Index: fs/fsys_ext2fs.c === --- fs/fsys_ext2fs.c(revision 105) +++ fs/fsys_ext2fs.c(working copy) @@ -253,10 +253,18 @@ ((char *)((char *)DATABLOCK1 + EXT2_BLOCK_SIZE(SUPERBLOCK))) /* linux/ext2_fs.h */ + +#define EXT2_OLD_REV 0 /* The good old (original) format */ +#define EXT2_DYNAMIC_REV 1 /* V2 format w/ dynamic inode sizes */ + +#define EXT2_OLD_INODE_SIZE128 + #define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof (__u32)) #define EXT2_ADDR_PER_BLOCK_BITS(s)(log2(EXT2_ADDR_PER_BLOCK(s))) -#define EXT2_INODE_SIZE(s) (SUPERBLOCK-s_inode_size) +#define EXT2_INODE_SIZE(s) (((s)-s_rev_level == EXT2_OLD_REV) ? \ + EXT2_OLD_INODE_SIZE : (s)-s_inode_size) + #define EXT2_INODES_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s)) /* linux/ext2_fs.h */ @@ -287,6 +295,7 @@ printf( b_free=%d\n, le32_to_cpu(s-s_free_blocks_count)); printf( first=%d\n, le32_to_cpu(s-s_first_data_block)); printf( log_b_size=%d, b_size=%d\n, le32_to_cpu(s-s_log_block_size), EXT2_BLOCK_SIZE(s)); +printf( inode_size=%d\n, le32_to_cpu(EXT2_INODE_SIZE(s))); printf( log_f_size=%d\n, le32_to_cpu(s-s_log_frag_size)); printf( bpg=%d\n, le32_to_cpu(s-s_blocks_per_group)); printf( fpg=%d\n, le32_to_cpu(s-s_frags_per_group)); - End forwarded message - -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coreboot or UEFI, who will be the winner.
I got a brief UEFI introduction. It seems that it is pretty close to coreboot. They have same goal and face same problem. Any idea? Zheng _ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot or UEFI, who will be the winner.
On 23.09.2009 15:29, Zheng Bao wrote: I got a brief UEFI introduction. It seems that it is pretty close to coreboot. They have same goal and face same problem. Any idea? I think there are quite some differences which make coreboot the better solution: - The lowlevel parts of UEFI are closed source. - UEFI is bigger/bloated. - UEFI stays resident in memory. - UEFI has to provide network/disk/video drivers which can/should be used by the OS. And if someone really wants EFI functionality, it is possible to run UEFI as a coreboot payload. Besides that, if you want a completely opensource firmware with UEFI, you have to use coreboot+UEFI because the chipset/CPU init in UEFI is not open source. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
I traced a little further and implemented a cs5536_set_resources() which simply wraps the call to pci_set_resources(). GPIO registers are accessed ok before pci_set_resources() but fail after. Sounds like the address where you access the resource is changing after resource allocation. You have a couple of options: 1. Use the new address after pci_set_resources 2. Don't use pci_set_resources to allocate that resource (Set up that resource as fixed) I think #1 is the best, unless you have to have that address at a specific location. This is the output of print_resource_tree() of the device used: I don't know enough about it to know which of these resources is the one you're looking for, but you can look through the code to see where the GPIO registers are set up. (CB) PCI: 00:0f.0 links 0 child on link 0 NULL (CB) PCI: 00:0f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags e100 index 0 (CB) PCI: 00:0f.0 resource base 20b0 size 8 align 3 gran 3 limit flags 4100 index 10 (CB) PCI: 00:0f.0 resource base 1800 size 100 align 8 gran 8 limit flags 4100 index 14 (CB) PCI: 00:0f.0 resource base 2000 size 40 align 6 gran 6 limit flags 4100 index 18 (CB) PCI: 00:0f.0 resource base 2080 size 20 align 5 gran 5 limit flags 4100 index 1c (CB) PCI: 00:0f.0 resource base 1c00 size 80 align 7 gran 7 limit flags 4100 index 20 (CB) PCI: 00:0f.0 resource base 2040 size 40 align 6 gran 6 limit flags 4100 index 24 Good luck, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [FILO] r106 - trunk/filo/fs
Author: stuge Date: 2009-09-23 16:12:31 +0200 (Wed, 23 Sep 2009) New Revision: 106 Modified: trunk/filo/fs/fsys_ext2fs.c Log: Fix EXT2_INODE_SIZE() for original format ext2 filesystems This patch applies against r104 of filo and allows older versions of ext2 file systems to be accessed. The problem with the current code is that EXT2_INODE_SIZE() returns 0 for these file systems and the EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a div0 and sends the machine to reboot. Below is a fix for that. Signed-off-by: Daniel Mack dan...@caiaq.de Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/filo/fs/fsys_ext2fs.c === --- trunk/filo/fs/fsys_ext2fs.c 2009-08-27 22:52:37 UTC (rev 105) +++ trunk/filo/fs/fsys_ext2fs.c 2009-09-23 14:12:31 UTC (rev 106) @@ -253,10 +253,16 @@ ((char *)((char *)DATABLOCK1 + EXT2_BLOCK_SIZE(SUPERBLOCK))) /* linux/ext2_fs.h */ +#define EXT2_OLD_REV 0 /* The good old (original) format */ +#define EXT2_DYNAMIC_REV 1 /* V2 format w/ dynamic inode sizes */ + +#define EXT2_OLD_INODE_SIZE128 + #define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof (__u32)) #define EXT2_ADDR_PER_BLOCK_BITS(s)(log2(EXT2_ADDR_PER_BLOCK(s))) -#define EXT2_INODE_SIZE(s) (SUPERBLOCK-s_inode_size) +#define EXT2_INODE_SIZE(s) (((s)-s_rev_level == EXT2_OLD_REV) ? \ + EXT2_OLD_INODE_SIZE : (s)-s_inode_size) #define EXT2_INODES_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s)) /* linux/ext2_fs.h */ @@ -287,6 +293,7 @@ printf( b_free=%d\n, le32_to_cpu(s-s_free_blocks_count)); printf( first=%d\n, le32_to_cpu(s-s_first_data_block)); printf( log_b_size=%d, b_size=%d\n, le32_to_cpu(s-s_log_block_size), EXT2_BLOCK_SIZE(s)); +printf( inode_size=%d\n, le32_to_cpu(EXT2_INODE_SIZE(s))); printf( log_f_size=%d\n, le32_to_cpu(s-s_log_frag_size)); printf( bpg=%d\n, le32_to_cpu(s-s_blocks_per_group)); printf( fpg=%d\n, le32_to_cpu(s-s_frags_per_group)); -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] FILO: parse old ext2 revisions correctly
Daniel Mack wrote: This patch applies against r104 of filo and allows older versions of ext2 file systems to be accessed. The problem with the current code is that EXT2_INODE_SIZE() returns 0 for these file systems and the EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a div0 and sends the machine to reboot. Below is a fix for that. Signed-off-by: Daniel Mack dan...@caiaq.de Thanks. r106 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] getpir patch
This patch changes following in getpir application. 1 - Moved the check sum validation to probe_table function. 2 - Proper handling of resources allocated. 3 - Signature check is done in 16 byte boundaries. 4 - irq_tables.c file is created only if a valid PIRQ table is found. 5 - Makefile and README file are modified accordingly. Signed-off-by: Mohamed Mansoor mans...@iwavesystems.com --- DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. -- getpir.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot or UEFI, who will be the winner.
The killer for uefi for me are the security concerns. For many outfits, nowadays, the closed nature, and the limited control, of UEFI is worrisome. Here's a simple rule: open source almost always wins. I've seen almost no exceptions save maybe in compilers, and that only in special cases. Open source is the water that wears down the rock. There's more and more interest in the last two years in coreboot. Customers really want it. It's just that PC vendors are worried about providing it for some reason. PC vendors need to be careful, they're building closed ecosystems now around the PC platform. It's quite amazing how much more closed the PC platform is than it was in 1994 or even 1999. Closed ecosystems die. Here at linuxcon and other recent conferences, all the real innovation and cool stuff is ARM-based. PCs are those big, expensive, hot, closed things that you're not allowed to hack. Really wonderful stuff being done on OMAP 35. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. Yeah, known issue. The linux kernel driver stupidly assumes that all firmware sets up the GPIOs at the same IO port. The kernel driver should look up the msr and then do the right thing, but it does not. I think Peter Stuge may have a patch for the LED driver... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
Daniel Mack wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. The driver should be improved to read the base address from the MSR, then it would work everywhere. Another sad fact is that the driver scans the BIOS 0xf segment for a particular string which is present in the factory BIOS, but not in coreboot. I believe there is an override. You may find msrtool helpful since it knows a bit about Geode, although not nearly everything. It's good with the DIVIL and interrupts. boot factory BIOS # msrtool -l -s file this saves a list of known MSRs along with their values into file boot coreboot # msrtool -d file this shows decoded MSR differences between saved and current values //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
Ward Vandewege wrote: I think Peter Stuge may have a patch for the LED driver... If I do it's on a hard drive that I can't find anymore. It's not a terribly complex change, but the mere thought of cloning the led-2.6 tree is a little exhausting. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Tyan s2881 Kconfig
I realize that these boards are old. If I were new to coreboot and wanted to experiment with it, I might be looking at boards like this one. You can get them for $39 with 2 CPUs (refurbished). Build tested but not boot tested. Signed-off-by: Myles Watson myle...@gmail.com Thanks, Myles Index: svn/src/mainboard/tyan/Kconfig === --- svn.orig/src/mainboard/tyan/Kconfig +++ svn/src/mainboard/tyan/Kconfig @@ -23,6 +23,7 @@ choice depends on VENDOR_TYAN source src/mainboard/tyan/s1846/Kconfig +source src/mainboard/tyan/s2881/Kconfig source src/mainboard/tyan/s2891/Kconfig source src/mainboard/tyan/s2892/Kconfig source src/mainboard/tyan/s2895/Kconfig Index: svn/src/mainboard/tyan/s2881/Kconfig === --- svn.orig/src/mainboard/tyan/s2881/Kconfig +++ svn/src/mainboard/tyan/s2881/Kconfig @@ -1,142 +1,143 @@ -config BOARD_TYAN_S2891 - bool Tyan Thunder K8SRE S2891 +config BOARD_TYAN_S2881 + bool Tyan Thunder K8SR S2881 select ARCH_X86 select CPU_AMD_K8 select CPU_AMD_SOCKET_940 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX - select SOUTHBRIDGE_NVIDIA_CK804 select SOUTHBRIDGE_AMD_AMD8131 + select SOUTHBRIDGE_AMD_AMD8111 select SUPERIO_WINBOND_W83627HF + select I2C_ADM1027 select PIRQ_TABLE config MAINBOARD_DIR string - default tyan/s2891 - depends on BOARD_TYAN_S2891 + default tyan/s2881 + depends on BOARD_TYAN_S2881 config APIC_ID_OFFSET hex default 0x10 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_ON_BUS0 int default 2 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config LB_CKS_RANGE_END int default 122 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config LB_CKS_LOC int default 123 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAINBOARD_PART_NUMBER string - default s2891 - depends on BOARD_TYAN_S2891 + default s2881 + depends on BOARD_TYAN_S2881 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex - default 0x2891 - depends on BOARD_TYAN_S2891 + default 0x2881 + depends on BOARD_TYAN_S2881 config USE_FAILOVER_IMAGE bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HW_MEM_HOLE_SIZEK hex default 0x10 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MEM_TRAIN_SEQ bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HAVE_FAILOVER_BOOT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config USE_FAILOVER_IMAGE bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAX_CPUS int default 4 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAX_PHYSICAL_CPUS int default 2 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MEM_TRAIN_SEQ bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config AP_CODE_IN_CAR bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HW_MEM_HOLE_SIZE_AUTO_INC bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HT_CHAIN_UNITID_BASE hex - default 0 - depends on BOARD_TYAN_S2891 + default 0xa + depends on BOARD_TYAN_S2881 config HT_CHAIN_END_UNITID_BASE hex - default 0x20 - depends on BOARD_TYAN_S2891 + default 0x6 + depends on BOARD_TYAN_S2881 config USE_INIT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SERIAL_CPU_INIT bool default y - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config AP_CODE_IN_CAR bool default y - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config WAIT_BEFORE_CPUS_INIT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_ON_BUS0 int - default 2 - depends on BOARD_TYAN_S2891 + default 0 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_UNITID_OFFSET_ONLY bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HAVE_ACPI_TABLES bool Generate ACPI tables - default y - depends on BOARD_TYAN_S2891 + default n + depends on BOARD_TYAN_S2881 Index: svn/src/drivers/Makefile.inc === --- svn.orig/src/drivers/Makefile.inc +++ svn/src/drivers/Makefile.inc @@ -1 +1,2 @@ subdirs-y += pci +subdirs-y += i2c Index: svn/src/drivers/i2c/Makefile.inc === --- /dev/null +++ svn/src/drivers/i2c/Makefile.inc @@ -0,0 +1,2 @@ +subdirs-y += adm1026 +subdirs-y += adm1027 Index: svn/src/Kconfig === --- svn.orig/src/Kconfig +++ svn/src/Kconfig @@ -31,6 +31,7 @@ source src/mainboard/Kconfig source src/arch/i386/Kconfig
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 9:52 AM, Peter Stuge pe...@stuge.se wrote: Daniel Mack wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
Myles Watson wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. It's at 6000 something, and I don't like to. I would much prefer the driver not make assumptions for no da^Wreason. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 10:04 AM, Peter Stuge pe...@stuge.se wrote: Myles Watson wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. It's at 6000 something, So that would be easy too. and I don't like to. I would much prefer the driver not make assumptions for no da^Wreason. Agreed. I guess it comes down to making changes where you can. Have you filed a bug report with the driver's authors? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote: Myles Watson wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. It's at 6000 something, and I don't like to. I would much prefer the driver not make assumptions for no da^Wreason. I think the driver assumes CS5536_BASE = 0x06100 Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan s2881 Kconfig
Currently, because they are so simple, we don't have makefile.inc files for i2c drivers. see serengeti_cheetah: driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o This is admittedly inconsistent, but it saves a lot of unnecessary makefile.inc stuff. So I don't think we need the Makefile.inc for the i2c parts. $39 for those boards is pretty attractive, do you have a link? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote: Myles Watson wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. It's at 6000 something, and I don't like to. I would much prefer the driver not make assumptions for no da^Wreason. Could you outline which steps would need to be taken in order to find out the correct address to use? Any maybe a way to sany detect the precence of that function on the board? I might go ahead and send a patch for the driver then. Thanks, Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan s2881 Kconfig
On Wed, Sep 23, 2009 at 10:56 AM, ron minnich rminn...@gmail.com wrote: Currently, because they are so simple, we don't have makefile.inc files for i2c drivers. see serengeti_cheetah: driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o Should it be a driver? In the old config it was just an object. This is admittedly inconsistent, but it saves a lot of unnecessary makefile.inc stuff. No problem. I just missed it. $39 for those boards is pretty attractive, do you have a link? http://www.pacificgeek.com/product.asp?id=847374 $35 if you buy 100 or more :) Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack dan...@caiaq.de wrote: Could you outline which steps would need to be taken in order to find out the correct address to use? Any maybe a way to sany detect the precence of that function on the board? I might go ahead and send a patch for the driver then. Not really an outline; it is just one MSR read. Take a look at the GPIO kernel driver: http://lxr.linux.no/#linux+v2.6.31/drivers/char/cs5535_gpio.c#L188 Also, to correct the 0xF scan ickiness, the proper way to detect a board revision is usually done by reading a PCI subvendor/subdevice ID too. I don't know if alix's non-coreboot BIOS does that properly. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan s2881 Kconfig
On Wed, Sep 23, 2009 at 10:56 AM, ron minnich rminn...@gmail.com wrote: Currently, because they are so simple, we don't have makefile.inc files for i2c drivers. see serengeti_cheetah: driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o Second try. Signed-off-by: Myles Watson myle...@gmail.com Thanks, Myles Index: svn/src/mainboard/tyan/Kconfig === --- svn.orig/src/mainboard/tyan/Kconfig +++ svn/src/mainboard/tyan/Kconfig @@ -23,6 +23,7 @@ choice depends on VENDOR_TYAN source src/mainboard/tyan/s1846/Kconfig +source src/mainboard/tyan/s2881/Kconfig source src/mainboard/tyan/s2891/Kconfig source src/mainboard/tyan/s2892/Kconfig source src/mainboard/tyan/s2895/Kconfig Index: svn/src/mainboard/tyan/s2881/Kconfig === --- svn.orig/src/mainboard/tyan/s2881/Kconfig +++ svn/src/mainboard/tyan/s2881/Kconfig @@ -1,142 +1,142 @@ -config BOARD_TYAN_S2891 - bool Tyan Thunder K8SRE S2891 +config BOARD_TYAN_S2881 + bool Tyan Thunder K8SR S2881 select ARCH_X86 select CPU_AMD_K8 select CPU_AMD_SOCKET_940 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX - select SOUTHBRIDGE_NVIDIA_CK804 select SOUTHBRIDGE_AMD_AMD8131 + select SOUTHBRIDGE_AMD_AMD8111 select SUPERIO_WINBOND_W83627HF select PIRQ_TABLE config MAINBOARD_DIR string - default tyan/s2891 - depends on BOARD_TYAN_S2891 + default tyan/s2881 + depends on BOARD_TYAN_S2881 config APIC_ID_OFFSET hex default 0x10 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_ON_BUS0 int default 2 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config LB_CKS_RANGE_END int default 122 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config LB_CKS_LOC int default 123 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAINBOARD_PART_NUMBER string - default s2891 - depends on BOARD_TYAN_S2891 + default s2881 + depends on BOARD_TYAN_S2881 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex - default 0x2891 - depends on BOARD_TYAN_S2891 + default 0x2881 + depends on BOARD_TYAN_S2881 config USE_FAILOVER_IMAGE bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HW_MEM_HOLE_SIZEK hex default 0x10 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MEM_TRAIN_SEQ bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HAVE_FAILOVER_BOOT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config USE_FAILOVER_IMAGE bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAX_CPUS int default 4 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MAX_PHYSICAL_CPUS int default 2 - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config MEM_TRAIN_SEQ bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config AP_CODE_IN_CAR bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HW_MEM_HOLE_SIZE_AUTO_INC bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HT_CHAIN_UNITID_BASE hex - default 0 - depends on BOARD_TYAN_S2891 + default 0xa + depends on BOARD_TYAN_S2881 config HT_CHAIN_END_UNITID_BASE hex - default 0x20 - depends on BOARD_TYAN_S2891 + default 0x6 + depends on BOARD_TYAN_S2881 config USE_INIT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SERIAL_CPU_INIT bool default y - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config AP_CODE_IN_CAR bool default y - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config WAIT_BEFORE_CPUS_INIT bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_ON_BUS0 int - default 2 - depends on BOARD_TYAN_S2891 + default 0 + depends on BOARD_TYAN_S2881 config SB_HT_CHAIN_UNITID_OFFSET_ONLY bool default n - depends on BOARD_TYAN_S2891 + depends on BOARD_TYAN_S2881 config HAVE_ACPI_TABLES bool Generate ACPI tables - default y - depends on BOARD_TYAN_S2891 + default n + depends on BOARD_TYAN_S2881 Index: svn/src/mainboard/tyan/s2881/Makefile.inc === --- svn.orig/src/mainboard/tyan/s2881/Makefile.inc +++ svn/src/mainboard/tyan/s2881/Makefile.inc @@ -1 +1,2 @@ include $(src)/mainboard/tyan/Makefile.s289x.inc +driver-$(CONFIG_BOARD_TYAN_S2881) += ../../../drivers/i2c/adm1027/adm1027.o -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Compression fix
Separate payload compression from stage compression. I figured out why sometimes my coreboot_ram was 40K and sometimes it was 250K. Signed-off-by: Myles Watson myle...@gmail.com Thanks, Myles Index: svn/src/arch/i386/Makefile.inc === --- svn.orig/src/arch/i386/Makefile.inc +++ svn/src/arch/i386/Makefile.inc @@ -25,7 +25,7 @@ ifeq ($(CONFIG_PAYLOAD_NONE),y) @printf PAYLOADnone (as specified by user)\n else @printf PAYLOAD$(CONFIG_FALLBACK_PAYLOAD_FILE) $(COMPRESSFLAG)\n - $(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE) fallback/payload $(CBFS_COMPRESS_FLAG) + $(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE) fallback/payload $(CBFS_PAYLOAD_COMPRESS_FLAG) ifeq ($(CONFIG_VGA_BIOS),y) @printf VGABIOS$(CONFIG_FALLBACK_VGA_BIOS_FILE) $(CONFIG_FALLBACK_VGA_BIOS_ID)\n $(CBFSTOOL) ./build/coreboot.rom add $(CONFIG_FALLBACK_VGA_BIOS_FILE) pci$(CONFIG_FALLBACK_VGA_BIOS_ID).rom optionrom Index: svn/Makefile === --- svn.orig/Makefile +++ svn/Makefile @@ -236,9 +236,10 @@ CFLAGS +=-Wwrite-strings -Wredundant-dec CFLAGS += -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer -CBFS_COMPRESS_FLAG:= -ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZMA),y) CBFS_COMPRESS_FLAG:=l +CBFS_PAYLOAD_COMPRESS_FLAG:= +ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZMA),y) +CBFS_PAYLOAD_COMPRESS_FLAG:=l endif coreboot: prepare prepare2 $(obj)/coreboot.rom -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Compression fix
Myles Watson wrote: Separate payload compression from stage compression. I figured out why sometimes my coreboot_ram was 40K and sometimes it was 250K. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4659 - in trunk/coreboot-v2: . src/arch/i386
Author: myles Date: 2009-09-23 19:48:28 +0200 (Wed, 23 Sep 2009) New Revision: 4659 Modified: trunk/coreboot-v2/Makefile trunk/coreboot-v2/src/arch/i386/Makefile.inc Log: Separate payload compression from stage compression. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/coreboot-v2/Makefile === --- trunk/coreboot-v2/Makefile 2009-09-22 22:08:47 UTC (rev 4658) +++ trunk/coreboot-v2/Makefile 2009-09-23 17:48:28 UTC (rev 4659) @@ -236,9 +236,10 @@ CFLAGS += -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer -CBFS_COMPRESS_FLAG:= +CBFS_COMPRESS_FLAG:=l +CBFS_PAYLOAD_COMPRESS_FLAG:= ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZMA),y) -CBFS_COMPRESS_FLAG:=l +CBFS_PAYLOAD_COMPRESS_FLAG:=l endif coreboot: prepare prepare2 $(obj)/coreboot.rom Modified: trunk/coreboot-v2/src/arch/i386/Makefile.inc === --- trunk/coreboot-v2/src/arch/i386/Makefile.inc2009-09-22 22:08:47 UTC (rev 4658) +++ trunk/coreboot-v2/src/arch/i386/Makefile.inc2009-09-23 17:48:28 UTC (rev 4659) @@ -25,7 +25,7 @@ @printf PAYLOADnone (as specified by user)\n else @printf PAYLOAD$(CONFIG_FALLBACK_PAYLOAD_FILE) $(COMPRESSFLAG)\n - $(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE) fallback/payload $(CBFS_COMPRESS_FLAG) + $(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE) fallback/payload $(CBFS_PAYLOAD_COMPRESS_FLAG) ifeq ($(CONFIG_VGA_BIOS),y) @printf VGABIOS$(CONFIG_FALLBACK_VGA_BIOS_FILE) $(CONFIG_FALLBACK_VGA_BIOS_ID)\n $(CBFSTOOL) ./build/coreboot.rom add $(CONFIG_FALLBACK_VGA_BIOS_FILE) pci$(CONFIG_FALLBACK_VGA_BIOS_ID).rom optionrom -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Compression fix
On Wed, Sep 23, 2009 at 11:44 AM, Peter Stuge pe...@stuge.se wrote: Myles Watson wrote: Separate payload compression from stage compression. I figured out why sometimes my coreboot_ram was 40K and sometimes it was 250K. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.sehttp://www.coreboot.org/mailman/listinfo/coreboot Rev 4659. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan s2881 Kconfig
On Wed, Sep 23, 2009 at 11:13:11AM -0600, Myles Watson wrote: On Wed, Sep 23, 2009 at 10:56 AM, ron minnich rminn...@gmail.com wrote: Currently, because they are so simple, we don't have makefile.inc files for i2c drivers. see serengeti_cheetah: driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o Should it be a driver? In the old config it was just an object. This is admittedly inconsistent, but it saves a lot of unnecessary makefile.inc stuff. No problem. I just missed it. $39 for those boards is pretty attractive, do you have a link? http://www.pacificgeek.com/product.asp?id=847374 Argh, can not resist. Ordered :) Good for spare parts, too - I've still got a couple of those out in the field... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4660 - in trunk/coreboot-v2/src/mainboard/tyan: . s2881
Author: myles Date: 2009-09-23 19:59:56 +0200 (Wed, 23 Sep 2009) New Revision: 4660 Added: trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc Modified: trunk/coreboot-v2/src/mainboard/tyan/Kconfig Log: Add Kconfig support for Tyan s2881. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Ronald G. Minnich rminn...@gmail.com Modified: trunk/coreboot-v2/src/mainboard/tyan/Kconfig === --- trunk/coreboot-v2/src/mainboard/tyan/Kconfig2009-09-23 17:48:28 UTC (rev 4659) +++ trunk/coreboot-v2/src/mainboard/tyan/Kconfig2009-09-23 17:59:56 UTC (rev 4660) @@ -23,6 +23,7 @@ depends on VENDOR_TYAN source src/mainboard/tyan/s1846/Kconfig +source src/mainboard/tyan/s2881/Kconfig source src/mainboard/tyan/s2891/Kconfig source src/mainboard/tyan/s2892/Kconfig source src/mainboard/tyan/s2895/Kconfig Copied: trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig (from rev 4658, trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig) === --- trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig (rev 0) +++ trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig 2009-09-23 17:59:56 UTC (rev 4660) @@ -0,0 +1,142 @@ +config BOARD_TYAN_S2881 + bool Tyan Thunder K8SR S2881 + select ARCH_X86 + select CPU_AMD_K8 + select CPU_AMD_SOCKET_940 + select NORTHBRIDGE_AMD_AMDK8 + select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX + select SOUTHBRIDGE_AMD_AMD8131 + select SOUTHBRIDGE_AMD_AMD8111 + select SUPERIO_WINBOND_W83627HF + select PIRQ_TABLE + +config MAINBOARD_DIR + string + default tyan/s2881 + depends on BOARD_TYAN_S2881 + +config APIC_ID_OFFSET + hex + default 0x10 + depends on BOARD_TYAN_S2881 + +config SB_HT_CHAIN_ON_BUS0 + int + default 2 + depends on BOARD_TYAN_S2881 + +config LB_CKS_RANGE_END + int + default 122 + depends on BOARD_TYAN_S2881 + +config LB_CKS_LOC + int +default 123 + depends on BOARD_TYAN_S2881 + +config MAINBOARD_PART_NUMBER + string + default s2881 + depends on BOARD_TYAN_S2881 + +config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID + hex + default 0x2881 + depends on BOARD_TYAN_S2881 + +config USE_FAILOVER_IMAGE + bool + default n + depends on BOARD_TYAN_S2881 + +config HW_MEM_HOLE_SIZEK + hex + default 0x10 + depends on BOARD_TYAN_S2881 + +config MEM_TRAIN_SEQ + bool + default n + depends on BOARD_TYAN_S2881 + +config HAVE_FAILOVER_BOOT + bool + default n + depends on BOARD_TYAN_S2881 + +config USE_FAILOVER_IMAGE + bool + default n + depends on BOARD_TYAN_S2881 + +config MAX_CPUS + int + default 4 + depends on BOARD_TYAN_S2881 + +config MAX_PHYSICAL_CPUS + int + default 2 + depends on BOARD_TYAN_S2881 + +config MEM_TRAIN_SEQ + bool + default n + depends on BOARD_TYAN_S2881 + +config AP_CODE_IN_CAR + bool + default n + depends on BOARD_TYAN_S2881 + +config HW_MEM_HOLE_SIZE_AUTO_INC + bool + default n + depends on BOARD_TYAN_S2881 + +config HT_CHAIN_UNITID_BASE + hex + default 0xa + depends on BOARD_TYAN_S2881 + +config HT_CHAIN_END_UNITID_BASE + hex + default 0x6 + depends on BOARD_TYAN_S2881 + +config USE_INIT + bool + default n + depends on BOARD_TYAN_S2881 + +config SERIAL_CPU_INIT + bool + default y + depends on BOARD_TYAN_S2881 + +config AP_CODE_IN_CAR + bool + default y + depends on BOARD_TYAN_S2881 + +config WAIT_BEFORE_CPUS_INIT + bool + default n + depends on BOARD_TYAN_S2881 + +config SB_HT_CHAIN_ON_BUS0 + int + default 0 + depends on BOARD_TYAN_S2881 + +config SB_HT_CHAIN_UNITID_OFFSET_ONLY + bool + default n + depends on BOARD_TYAN_S2881 + +config HAVE_ACPI_TABLES + bool Generate ACPI tables + default n + depends on BOARD_TYAN_S2881 + Copied: trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc (from rev 4658, trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc) === --- trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc (rev 0) +++ trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc 2009-09-23 17:59:56 UTC (rev 4660) @@ -0,0 +1,2 @@ +include $(src)/mainboard/tyan/Makefile.s289x.inc +driver-$(CONFIG_BOARD_TYAN_S2881) += ../../../drivers/i2c/adm1027/adm1027.o Property changes on: trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc ___ Added: svn:mergeinfo +
Re: [coreboot] Tyan s2881 Kconfig
On Wed, Sep 23, 2009 at 11:54 AM, ron minnich rminn...@gmail.com wrote: great. Is it a driver or not? I'm too distracted with another but to tell. If you're sure it's a driver, I thought it should be, and serengeti_cheetah says it is. If it's wrong I guess we can change both in a separate commit. Acked-by: Ronald G. Minnich rminn...@gmail.com Rev 4660. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Drivers vs. Objects
Drivers and objects seem interchangeable to me except that drivers get registered and checked against devices that are found during enumeration, that weren't mentioned in devicetree.cb. Either one seems to get linked into the correct place if the device is mentioned in the device tree. Are there other differences? Should I2C devices use objects, since you can't scan for them? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
Myles Watson wrote: Are there other differences? That's how I understand it too. Should I2C devices use objects, since you can't scan for them? Makes sense. Either way I strongly favor having a policy for this, so that the tree is consistent. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4659
Dear coreboot readers! This is the automatic build system of coreboot. The developer myles checked in revision 4659 to the coreboot repository. This caused the following changes: Change Log: Separate payload compression from stage compression. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
Should I2C devices use objects, since you can't scan for them? Makes sense. Either way I strongly favor having a policy for this, so that the tree is consistent. Making it a driver seems easier to enforce/explain since it provides an *_ops struct. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
Myles Watson wrote: Should I2C devices use objects, since you can't scan for them? Makes sense. Either way I strongly favor having a policy for this, so that the tree is consistent. Making it a driver seems easier to enforce/explain since it provides an *_ops struct. On the other hand a phony ops struct is bad in so many ways. Less is more, no? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4660
Dear coreboot readers! This is the automatic build system of coreboot. The developer myles checked in revision 4660 to the coreboot repository. This caused the following changes: Change Log: Add Kconfig support for Tyan s2881. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Ronald G. Minnich rminn...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
On Wed, Sep 23, 2009 at 12:42 PM, Peter Stuge pe...@stuge.se wrote: Myles Watson wrote: Should I2C devices use objects, since you can't scan for them? Making it a driver seems easier to enforce/explain since it provides an *_ops struct. On the other hand a phony ops struct is bad in so many ways. Less is more, no? My impression was that the ops struct works fine, but you can't scan for it because I2C is missing the equivalent of PCI vendor/device IDs. In what way is the ops struct phony? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4662 - trunk/coreboot-v2/src
Author: stepan Date: 2009-09-23 20:54:18 +0200 (Wed, 23 Sep 2009) New Revision: 4662 Removed: trunk/coreboot-v2/src/pmc/ Log: Looks like this should have become cpu init code after growing up. The remaining questions are: - Why was it never used? - Why is it in /src and not in /src/cpu/ppc? Given this is dead code and part of an unmaintained powerpc port, I consider removing it trivial. (The code really does not do much) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4661
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4661 to the coreboot repository. This caused the following changes: Change Log: simplify source tree hierarchy: move files from sdram/ and ram/ to lib/ It's only three files. Also fix up all the paths (Gotta love included C files) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Ronald G. Minnich rminn...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4662
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4662 to the coreboot repository. This caused the following changes: Change Log: Looks like this should have become cpu init code after growing up. The remaining questions are: - Why was it never used? - Why is it in /src and not in /src/cpu/ppc? Given this is dead code and part of an unmaintained powerpc port, I consider removing it trivial. (The code really does not do much) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] CBFS bounce buffer fix
src/boot/selfboot.c: In function 'get_bounce_buffer':
src/boot/ssrc/boot/selfboot.c: In function 'get_bounce_buffer':
src/boot/selfboot.c:113: warning: declaration of 'bounce_size' shadows a
global elfboot.c:113: warning: declaration of 'bounce_size' shadows a global
The global never got initialized, so I couldn't boot a kernel. Now I can,
but I'm not sure this is the most elegant fix, or even that it is 100%
correct.
While I was there I changed another bounce_size to size to avoid confusion
with the global, and made selfboot static to get rid of this warning:
src/boot/selfboot.c:508: warning: no previous prototype for 'selfboot'
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/boot/selfboot.c
===
--- svn.orig/src/boot/selfboot.c
+++ svn/src/boot/selfboot.c
@@ -71,9 +71,10 @@ struct ip_checksum_vcb {
unsigned short ip_checksum;
};
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
+
void * cbfs_load_payload(struct lb_memory *lb_mem, const char *name)
{
- int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
struct cbfs_payload *payload;
payload = (struct cbfs_payload *)cbfs_find_file(name, CBFS_TYPE_PAYLOAD);
@@ -110,7 +111,7 @@ void * cbfs_load_payload(struct lb_memor
static unsigned long bounce_size, bounce_buffer;
-static void get_bounce_buffer(struct lb_memory *mem, unsigned long bounce_size)
+static void get_bounce_buffer(struct lb_memory *mem, unsigned long req_size)
{
unsigned long lb_size;
unsigned long mem_entries;
@@ -118,7 +119,7 @@ static void get_bounce_buffer(struct lb_
int i;
lb_size = (unsigned long)(_eram_seg - _ram_seg);
/* Double coreboot size so I have somewhere to place a copy to return to */
- lb_size = bounce_size + lb_size;
+ lb_size = req_size + lb_size;
mem_entries = (mem-size - sizeof(*mem))/sizeof(mem-map[0]);
buffer = 0;
for(i = 0; i mem_entries; i++) {
@@ -142,6 +143,7 @@ static void get_bounce_buffer(struct lb_
buffer = tbuffer;
}
bounce_buffer = buffer;
+ bounce_size = req_size;
}
static int valid_area(struct lb_memory *mem, unsigned long buffer,
@@ -424,7 +426,8 @@ static int load_self_segments(
for(ptr = head-next; ptr != head; ptr = ptr-next) {
if (!overlaps_coreboot(ptr)) continue;
unsigned long bounce = ptr-s_dstaddr + ptr-s_memsz - lb_start;
- if (bounce required_bounce_size) required_bounce_size = bounce;
+ if (bounce required_bounce_size)
+ required_bounce_size = bounce;
}
get_bounce_buffer(mem, required_bounce_size);
if (!bounce_buffer) {
@@ -458,14 +461,12 @@ static int load_self_segments(
size_t len;
len = ptr-s_filesz;
switch(ptr-compression) {
-#if CONFIG_COMPRESSED_PAYLOAD_LZMA==1
case CBFS_COMPRESS_LZMA: {
printk_debug(using LZMA\n);
unsigned long ulzma(unsigned char *src, unsigned char *dst);
len = ulzma(src, dest);
break;
}
-#endif
#if CONFIG_COMPRESSED_PAYLOAD_NRV2B==1
case CBFS_COMPRESS_NRV2B: {
printk_debug(using NRV2B\n);
@@ -505,7 +506,7 @@ static int load_self_segments(
return 1;
}
-int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
{
u32 entry=0;
struct segment head;
Index: svn/src/arch/i386/boot/boot.c
===
--- svn.orig/src/arch/i386/boot/boot.c
+++ svn/src/arch/i386/boot/boot.c
@@ -68,7 +68,7 @@ int elf_check_arch(Elf_ehdr *ehdr)
}
-void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long bounce_size)
+void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long size)
{
extern unsigned char _ram_seg, _eram_seg;
unsigned long lb_start, lb_size;
@@ -79,7 +79,7 @@ void jmp_to_elf_entry(void *entry, unsig
lb_start = (unsigned long)_ram_seg;
lb_size = (unsigned long)(_eram_seg - _ram_seg);
- adjust = buffer + bounce_size - lb_start;
+ adjust = buffer + size - lb_start;
adjusted_boot_notes = (unsigned long)elf_boot_notes;
adjusted_boot_notes += adjust;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] CBFS bounce buffer fix
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] CBFS bounce buffer fix
Am Mittwoch, den 23.09.2009, 14:23 -0600 schrieb Myles Watson: The global never got initialized, so I couldn't boot a kernel. Now I can, but I'm not sure this is the most elegant fix, or even that it is 100% correct. Looks good to me. I had similar changes here already, but messed around with That Other Selfboot Bug[tm] and thus have nothing finished yet. src/boot/selfboot.c:508: warning: no previous prototype for 'selfboot' Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Patrick Georgi patrick.geo...@coresystems.de Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4663 - in trunk/coreboot-v2/src: arch/i386/boot boot
Author: myles
Date: 2009-09-23 22:32:21 +0200 (Wed, 23 Sep 2009)
New Revision: 4663
Modified:
trunk/coreboot-v2/src/arch/i386/boot/boot.c
trunk/coreboot-v2/src/boot/selfboot.c
Log:
Fix the bounce_size global so that the bounce buffer works with CBFS.
Make self_boot() static.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Ronald G. Minnich rminn...@gmail.com
Modified: trunk/coreboot-v2/src/arch/i386/boot/boot.c
===
--- trunk/coreboot-v2/src/arch/i386/boot/boot.c 2009-09-23 18:54:18 UTC (rev
4662)
+++ trunk/coreboot-v2/src/arch/i386/boot/boot.c 2009-09-23 20:32:21 UTC (rev
4663)
@@ -68,7 +68,7 @@
}
-void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long
bounce_size)
+void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long size)
{
extern unsigned char _ram_seg, _eram_seg;
unsigned long lb_start, lb_size;
@@ -79,7 +79,7 @@
lb_start = (unsigned long)_ram_seg;
lb_size = (unsigned long)(_eram_seg - _ram_seg);
- adjust = buffer + bounce_size - lb_start;
+ adjust = buffer + size - lb_start;
adjusted_boot_notes = (unsigned long)elf_boot_notes;
adjusted_boot_notes += adjust;
Modified: trunk/coreboot-v2/src/boot/selfboot.c
===
--- trunk/coreboot-v2/src/boot/selfboot.c 2009-09-23 18:54:18 UTC (rev
4662)
+++ trunk/coreboot-v2/src/boot/selfboot.c 2009-09-23 20:32:21 UTC (rev
4663)
@@ -71,9 +71,10 @@
unsigned short ip_checksum;
};
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
+
void * cbfs_load_payload(struct lb_memory *lb_mem, const char *name)
{
- int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
struct cbfs_payload *payload;
payload = (struct cbfs_payload *)cbfs_find_file(name,
CBFS_TYPE_PAYLOAD);
@@ -110,7 +111,7 @@
static unsigned long bounce_size, bounce_buffer;
-static void get_bounce_buffer(struct lb_memory *mem, unsigned long bounce_size)
+static void get_bounce_buffer(struct lb_memory *mem, unsigned long req_size)
{
unsigned long lb_size;
unsigned long mem_entries;
@@ -118,7 +119,7 @@
int i;
lb_size = (unsigned long)(_eram_seg - _ram_seg);
/* Double coreboot size so I have somewhere to place a copy to return
to */
- lb_size = bounce_size + lb_size;
+ lb_size = req_size + lb_size;
mem_entries = (mem-size - sizeof(*mem))/sizeof(mem-map[0]);
buffer = 0;
for(i = 0; i mem_entries; i++) {
@@ -142,6 +143,7 @@
buffer = tbuffer;
}
bounce_buffer = buffer;
+ bounce_size = req_size;
}
static int valid_area(struct lb_memory *mem, unsigned long buffer,
@@ -424,7 +426,8 @@
for(ptr = head-next; ptr != head; ptr = ptr-next) {
if (!overlaps_coreboot(ptr)) continue;
unsigned long bounce = ptr-s_dstaddr + ptr-s_memsz - lb_start;
- if (bounce required_bounce_size) required_bounce_size =
bounce;
+ if (bounce required_bounce_size)
+ required_bounce_size = bounce;
}
get_bounce_buffer(mem, required_bounce_size);
if (!bounce_buffer) {
@@ -458,14 +461,12 @@
size_t len;
len = ptr-s_filesz;
switch(ptr-compression) {
-#if CONFIG_COMPRESSED_PAYLOAD_LZMA==1
case CBFS_COMPRESS_LZMA: {
printk_debug(using LZMA\n);
unsigned long ulzma(unsigned char *src,
unsigned char *dst);
len = ulzma(src, dest);
break;
}
-#endif
#if CONFIG_COMPRESSED_PAYLOAD_NRV2B==1
case CBFS_COMPRESS_NRV2B: {
printk_debug(using NRV2B\n);
@@ -505,7 +506,7 @@
return 1;
}
-int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
{
u32 entry=0;
struct segment head;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] CBFS bounce buffer fix
On Wed, Sep 23, 2009 at 2:28 PM, ron minnich rminn...@gmail.com wrote: Acked-by: Ronald G. Minnich rminn...@gmail.com Rev 4663. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] CBFS bounce buffer fix
On Wed, Sep 23, 2009 at 2:30 PM, Patrick Georgi patr...@georgi-clan.dewrote: Am Mittwoch, den 23.09.2009, 14:23 -0600 schrieb Myles Watson: The global never got initialized, so I couldn't boot a kernel. Now I can, but I'm not sure this is the most elegant fix, or even that it is 100% correct. Looks good to me. Thanks for the review. I had similar changes here already, but messed around with That Other Selfboot Bug[tm] and thus have nothing finished yet I hope you get the fix committed before I find it the hard way :) Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] CBFS bounce buffer fix
Am Mittwoch, den 23.09.2009, 14:35 -0600 schrieb Myles Watson: I had similar changes here already, but messed around with That Other Selfboot Bug[tm] and thus have nothing finished yet I hope you get the fix committed before I find it the hard way :) The issue is that the loader doesn't properly cope with the case that the payload overlaps with coreboot and starts at a lower address. That happens on some AMD boards (with RAMBASE at 2MB, for whatever reason) and FILO (which has a huge .bss section that moves well into coreboot's memory). Any other configuration should not run into this issue, and for AMD, it should be enough to move RAMBASE to somewhere else (both 1MB and 4MB worked for me) as a workaround. Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
Myles Watson wrote: In what way is the ops struct phony? The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
s...@coreboot.org wrote: simplify source tree hierarchy: move files from sdram/ and ram/ to lib/ It's only three files. Also fix up all the paths (Gotta love included C files) Definately a good change! Do we have a strategy for the included C files? Will that be trivial once Kconfig has settled in? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
On Wed, Sep 23, 2009 at 2:48 PM, Peter Stuge pe...@stuge.se wrote: Myles Watson wrote: In what way is the ops struct phony? The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection. I'd be interested to see the alternative code. Devices that can't be probed for can still have resources that need to be read and set and init functions to call. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
On Wed, Sep 23, 2009 at 1:51 PM, Peter Stuge pe...@stuge.se wrote: Do we have a strategy for the included C files? Will that be trivial once Kconfig has settled in? it's going to be a bit longer than that. I've done complete seperate compilation for a few targets but, remember, if you're using romcc you're including .c files. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4663
Dear coreboot readers! This is the automatic build system of coreboot. The developer myles checked in revision 4663 to the coreboot repository. This caused the following changes: Change Log: Fix the bounce_size global so that the bounce buffer works with CBFS. Make self_boot() static. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Ronald G. Minnich rminn...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
ron minnich wrote: Do we have a strategy for the included C files? Will that be trivial once Kconfig has settled in? it's going to be a bit longer than that. I've done complete seperate compilation for a few targets but, remember, if you're using romcc you're including .c files. Yes! Thanks! CAR is the key to that. But where there is CAR and Kconfig, maybe it could be fixed up fairly easily. I hope we can support both CAR and romcc use of the same source without having to mess much with Kconfig. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Drivers vs. Objects
Myles Watson wrote: I'd be interested to see the alternative code. Fair enough. I have none, It wasn't supposed to be a challenge. Just that I could tell we weren't understanding each other somehow. Pseudo code would have been fine. but if it works as an object without ops then is any more code needed? Ah. There's the point I've been missing in your argument. It works _with_ ops in the object. The ops get linked in to the device tree, so they get used by the correct device even though it can't be discovered. Devices that can't be probed for can still have resources that need to be read and set and init functions to call. Yes, but wouldn't that all need to be done by code with knowledge of the device (ie. just use static functions in the file) anyway? Yes. The problem is how to call them if you don't have an ops structure somewhere. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4664 - in trunk/coreboot-v2: src/cpu/amd/model_gx2 src/cpu/amd/model_lx src/lib src/mainboard/artecgroup/dbe61/realmode src/mainboard/via/epia-m src/northbridge/via/cn400 src/northbri
Author: stepan Date: 2009-09-23 23:52:45 +0200 (Wed, 23 Sep 2009) New Revision: 4664 Modified: trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c trunk/coreboot-v2/src/lib/xmodem.c trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c trunk/coreboot-v2/src/northbridge/via/cn700/vgabios.c trunk/coreboot-v2/src/northbridge/via/vx800/vgabios.c trunk/coreboot-v2/util/ADLO/COPYING trunk/coreboot-v2/util/ADLO/bochs/bios/Makefile trunk/coreboot-v2/util/cbfstool/elf.h trunk/coreboot-v2/util/cbfstool/lzma/C/LGPL.txt trunk/coreboot-v2/util/x86emu/x86.c trunk/coreboot-v2/util/x86emu/x86_asm.S trunk/coreboot-v2/util/x86emu/x86_interrupts.c Log: fix some wrong versions of the FSF's address (trivial) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c === --- trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c 2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c 2009-09-23 21:52:45 UTC (rev 4664) @@ -19,7 +19,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. * * LA-CC is the Los Alamos Control and Compliance Number, see also: * http://supply.lanl.gov/property/customs/eximguide/default.shtml Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c === --- trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-09-23 21:52:45 UTC (rev 4664) @@ -38,7 +38,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. * * Portions related to the alpha architecture are: * Modified: trunk/coreboot-v2/src/lib/xmodem.c === --- trunk/coreboot-v2/src/lib/xmodem.c 2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/lib/xmodem.c 2009-09-23 21:52:45 UTC (rev 4664) @@ -14,7 +14,7 @@ You should have received a copy of the GNU Lesser General Public License along with this program; if not, write to the Free Software -Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ #include string.h Modified: trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c === --- trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c 2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c 2009-09-23 21:52:45 UTC (rev 4664) @@ -32,7 +32,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. * * Portions related to the alpha architecture are: * Modified: trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c === --- trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c2009-09-23 21:52:45 UTC (rev 4664) @@ -32,7 +32,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. * * Portions related to the alpha architecture are: * Modified: trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c === --- trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c 2009-09-23 20:32:21 UTC (rev 4663) +++ trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c 2009-09-23 21:52:45 UTC (rev 4664) @@ -32,7 +32,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; if
[coreboot] [v2] r4665 - trunk/util/nvramtool
Author: stepan Date: 2009-09-23 23:53:25 +0200 (Wed, 23 Sep 2009) New Revision: 4665 Modified: trunk/util/nvramtool/DISCLAIMER trunk/util/nvramtool/cmos_lowlevel.c trunk/util/nvramtool/cmos_lowlevel.h trunk/util/nvramtool/cmos_ops.c trunk/util/nvramtool/cmos_ops.h trunk/util/nvramtool/common.c trunk/util/nvramtool/common.h trunk/util/nvramtool/input_file.c trunk/util/nvramtool/input_file.h trunk/util/nvramtool/layout.c trunk/util/nvramtool/layout.h trunk/util/nvramtool/layout_file.c trunk/util/nvramtool/layout_file.h trunk/util/nvramtool/lbtable.c trunk/util/nvramtool/lbtable.h trunk/util/nvramtool/nvramtool.8 trunk/util/nvramtool/nvramtool.c trunk/util/nvramtool/opts.c trunk/util/nvramtool/opts.h trunk/util/nvramtool/reg_expr.c trunk/util/nvramtool/reg_expr.h Log: fix some wrong occurences of the FSF's address (trivial) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/util/nvramtool/DISCLAIMER === --- trunk/util/nvramtool/DISCLAIMER 2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/DISCLAIMER 2009-09-23 21:53:25 UTC (rev 4665) @@ -23,7 +23,7 @@ You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., -59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. This work was produced at the University of California, Lawrence Livermore National Laboratory (UC LLNL) under contract no. W-7405-ENG-48 (Contract 48) Modified: trunk/util/nvramtool/cmos_lowlevel.c === --- trunk/util/nvramtool/cmos_lowlevel.c2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/cmos_lowlevel.c2009-09-23 21:53:25 UTC (rev 4665) @@ -25,7 +25,7 @@ * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. \*/ #if defined(__FreeBSD__) Modified: trunk/util/nvramtool/cmos_lowlevel.h === --- trunk/util/nvramtool/cmos_lowlevel.h2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/cmos_lowlevel.h2009-09-23 21:53:25 UTC (rev 4665) @@ -25,7 +25,7 @@ * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. \*/ #ifndef NVRAMTOOL_CMOS_LOWLEVEL_H Modified: trunk/util/nvramtool/cmos_ops.c === --- trunk/util/nvramtool/cmos_ops.c 2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/cmos_ops.c 2009-09-23 21:53:25 UTC (rev 4665) @@ -25,7 +25,7 @@ * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. \*/ #include common.h Modified: trunk/util/nvramtool/cmos_ops.h === --- trunk/util/nvramtool/cmos_ops.h 2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/cmos_ops.h 2009-09-23 21:53:25 UTC (rev 4665) @@ -25,7 +25,7 @@ * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. \*/ #ifndef CMOS_OPS_H Modified: trunk/util/nvramtool/common.c === --- trunk/util/nvramtool/common.c 2009-09-23 21:52:45 UTC (rev 4664) +++ trunk/util/nvramtool/common.c 2009-09-23 21:53:25 UTC (rev 4665) @@ -25,7 +25,7 @@ * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
[coreboot] build service results for r4664
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4664 to the coreboot repository. This caused the following changes: Change Log: fix some wrong versions of the FSF's address (trivial) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4665
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4665 to the coreboot repository. This caused the following changes: Change Log: fix some wrong occurences of the FSF's address (trivial) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] duplicated code in Coreboot
Since I started to work on the coreboot, I always sense that the much code is duplicated. By duplicated, it doesn't mean the code in different folders is almost same. As a matter of fact, it should be same. For example, the most feature of it871(2,6,8) should be the same. But it8712f_enable_serial doesn't use the first parameter dev, while it8716f_enable_serial does. When the board changes the super io, you can not just change the 2 to 6. You should also change the parameters. That makes me confused. This also happens on some chips which are close. Is it possible to fix this in future? Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] duplicated code in Coreboot
Bao, Zheng wrote: Is it possible to fix this in future? I hope so! I would love to see it improve. It's possible to start fixing it immediately. Please do! So far not a lot of time has been spent on improving the state of the codebase, because the typical procedure of major contribution to coreboot is that the contributor sends several hundred kilobytes of (working) source code to the mailing list, with very little if any followup communication. This way of contributing to an open source project places an unneccessarily heavy burden on the project. It is a contribution, and all contributions are valuable, but in the long term this procedure leads to unneccessary extra work for everyone who is involved in coreboot, and everyone who wishes to benefit from coreboot. I understand very much the desire to only send code when it is working, and working well. But it is too late when the code is finished. I would like to request that any contributors who work with coreboot code send their lines of code as early as possible! The ideal way to contribute to an open source project, such as coreboot, is to send small changes very often over a long period of time. I think it is even OK to add a new, empty, file to the repository - under the condition that code will be added to the file in a following patch which is sent a few days later. This allows small problems to be fixed in one place before they turn into big problems existing in many places. It also allows other developers to immediately benefit from the work that has already been done. If someone is using the code that is being developed, they can also help with development. The key, which I myself struggle with, is to strive for letting as many developers as possible benefit as much as possible as soon as possible from what you develop. You will be thanked. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
