coreboot February 2007

coreboot@coreboot.org

68 participants
169 discussions

Re: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code
by Lu, Yinghai 03 Feb '07

03 Feb '07

We may consider moving ids to mcp55_ids.h later like kernel do. Instead of tough pci_ids.h YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ed Swierk Sent: Wednesday, January 31, 2007 4:54 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code On 1/31/07, Stefan Reinauer <stefan.reinauer(a)coresystems.de> wrote: > It's in. please go ahead. Cool. Can you apply this patch next? It adds the MCP55 PCI IDs (without which the southbridge code won't compile), and breaks an unnecessary dependency on the usbdebug code. Acked-by: Ed Swierk <eswierk(a)arastra.com> --Ed

2 1

Re: [LinuxBIOS] [PATCH] romstream off-by-1
by Roman Kononov 03 Feb '07

03 Feb '07

On 02/02/2007 10:57 AM, Stefan Reinauer wrote: > I suggest comparing (rom + bytes - 1) > rom_end, because rom_end seems > to be the logical border we're checking for. (rom + bytes - 1 > rom_end) equals to (rom + bytes > rom_end + 1) provided that [rom,rom_end+1) does not cross 0x7fffffff+1 and ptrdiff_t is signed, or [rom,rom_end+1) does not corss 0xffffffff+1 and ptrdiff_t is unsigned. In linuxbios, [rom,rom_end+1) crosses neither boundary. Strictly speaking, an exception for the first statement is when ptrdiff_t is signed (which is our case); rom+bytes-1 does not overflow and is 0x7fffffff; rom+bytes does overflow and is 0x80000000; rom_end is, for example, 0xffff0000. Then, (rom + bytes - 1 > rom_end) is true (rom + bytes > rom_end + 1) is false For this to happen rom must be within [0x00000000-0x7fffffff], which is impossible. Any way, you flavor is attached. Regards, Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com>

2 1

[LinuxBIOS] r2547 - trunk/LinuxBIOSv2/src/stream
by svn＠openbios.org 03 Feb '07

03 Feb '07

Author: stepan Date: 2007-02-03 11:43:48 +0100 (Sat, 03 Feb 2007) New Revision: 2547 Modified: trunk/LinuxBIOSv2/src/stream/rom_stream.c Log: This eliminates an illegal and annoying warning. 'rom' is the current read pointer. 'rom_end' points to last valid byte of the stream. Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/LinuxBIOSv2/src/stream/rom_stream.c =================================================================== --- trunk/LinuxBIOSv2/src/stream/rom_stream.c 2007-02-02 22:40:10 UTC (rev 2546) +++ trunk/LinuxBIOSv2/src/stream/rom_stream.c 2007-02-03 10:43:48 UTC (rev 2547) @@ -116,7 +116,7 @@ { byte_offset_t bytes; bytes = count; - if ((rom + bytes) > rom_end) { + if ((rom + bytes - 1) > rom_end) { printk_warning("%6d:%s() - overflowed source buffer\n", __LINE__, __FUNCTION__); bytes = 0;

1 0

[LinuxBIOS] Unexpected Exception: 13
by michal wan 03 Feb '07

03 Feb '07

in the file src/cpu/amd/model_lx/model_lx_init.c static void model_lx_init(device_t dev) { printk_debug("model_lx_init\n"); /* Turn on caching if we haven't already */ x86_enable_cache(); /* Enable the local cpu apics */ //setup_lapic(); // do VSA late init vsm_end_post_smi(); // Set gate A20 (legacy vsm disables it in late init) printk_debug("A20 (0x92): %d\n",inb(0x92)); outb(0x02,0x92); printk_debug("A20 (0x92): %d\n",inb(0x92)); printk_debug("model_lx_init DONE\n"); }; ~ when using vsm_end_post_smi() function, Unexpected Exception occures, any advice would be appreciated! _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

1 0

Re: [LinuxBIOS] DK8-HTX: 8131 A-bus running slow
by Lu, Yinghai 03 Feb '07

03 Feb '07

Is there any jumper there? YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of mcqmcqmcq(a)fastmail.fm Sent: Friday, February 02, 2007 12:54 PM To: linuxbios(a)linuxbios.org Subject: [LinuxBIOS] DK8-HTX: 8131 A-bus running slow Guys, Once my DK8-HTX is up and running in Linux, I observe that the 8131 is programmed thusly (full regdump and my cute little utility attached): /proc/bus/pci/00/0b.0: AMD 8131 PCI-X Tunnel PCI-X Bridge 0x40 PCI-X Miscellaneous Register 1-1 Conentional PCI mode frequency RW 0 0 33 MHz 0xa0 PCI-X Secondary Status Register 24-22 Secondary clock frequency R 0 3 133 MHz PCI-X /proc/bus/pci/00/0a.0: AMD 8131 PCI-X Tunnel PCI-X Bridge 0x40 PCI-X Miscellaneous Register 1-1 Conentional PCI mode frequency RW 0 1 66 Mhz 0xa0 PCI-X Secondary Status Register 24-22 Secondary clock frequency R 0 0 conventional PCI In particular, the A-bus 0a.0 is massively horribly slow (50MB/s to my RAID card as opposed to 350MB/s in the 0b.0 slot). I only see one speed line during LB bootup and would expect two (one for each bus): Capability: 0x07 @ 0xa0 PCI: 03: 133MHz PCI-X So my theory is that the A-bus is just never getting configued at all (nobody who uses LB does I/O, right? ;-). Can anybody confirm or deny this theory, and possibly point me toward what I might do to fix it? As an aside, I'm still working from the r2520 I was ages ago. YH, you were once going to look into repeating the hangs I was seeing with a Pathscale HTX IB card installed (during HT reset in iwill/dk8_htx/cache_as_ram_auto.c) -- did that ever go anywhere? Once I get this sucker fully tested, I'll summarize what I've done to get it there and compare to svn head for you guys' continued entertainment. Thanks, y'all, -mcq -- mcqmcqmcq(a)fastmail.fm -- http://www.fastmail.fm - Send your email first class

1 0

Re: [LinuxBIOS] The two load RAM codes.
by Lu, Yinghai 03 Feb '07

03 Feb '07

LinuxBIOS have three parts 1. linuxbios for init RAM, and Cache_as_RAM. Code is Flash, and stack is in CACHE. From cache_as_ram_main() 2. linuxbios_ram: for PCI device handling. --- from hardwaremain() Code is in ram and unzipped from rom by 1. 3. payload: it could be Etherboot ( boot from Network) or Kernel. Elfloader in 2 will load payload and jmp to it. Also the flash will contain three linuxbios.rom Normal+Fallback+Failover. Failover will be used to init 64K above rom access. YH ________________________________ From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Feng, Libo Sent: Thursday, February 01, 2007 8:16 PM To: linuxbios(a)linuxbios.org Subject: [LinuxBIOS] The two load RAM codes. I am studying the LinuxBios project. I have a question about the RAM code: from Makefile, it seems that LinuxBios could load codes from FLASH to RAM twice, first for linuxbios_ram, second for so-called payload. My understanding is correct or not. However, also from Makefile, it seems that linuxbios is dependent on LINUXBIOS_RAM_ROM, but doesn't include it. The below is abstracted from a Makefile for via epia-m based on LinuxBiosV2-2534: linuxbios: crt0.o $(INIT-OBJECTS) $(LINUXBIOS_APC) $(LINUXBIOS_RAM_ROM) ldscript.ld $(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS) $(CROSS_COMPILE)nm -n linuxbios | sort > linuxbios.map. So, there is no action on LINUXBIOS_RAM_ROM. Does it mean linuxbios_ram is not very important. Even without it, the system is also ok? Feng Libo

1 0

Re: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected
by Lu, Yinghai 03 Feb '07

03 Feb '07

Good catch. YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Roman Kononov Sent: Wednesday, January 31, 2007 2:25 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected This fixes a small typo. Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com> --- On 01/31/2007 03:19 PM, Peter Stuge wrote: > Please have a look at http://linuxbios.org/Development_Guidelines Thank you

1 0

Re: [LinuxBIOS] [PATCH] romstream off-by-1
by Lu, Yinghai 03 Feb '07

03 Feb '07

+ if ((rom + bytes - 1) > rom_end) { Would be good. YH Index: src/stream/rom_stream.c =================================================================== --- src/stream/rom_stream.c (revision 2542) +++ src/stream/rom_stream.c (working copy) @@ -116,7 +116,7 @@ byte_offset_t stream_skip(byte_offset_t { byte_offset_t bytes; bytes = count; - if ((rom + bytes) > rom_end) { + if (rom+bytes-1 > rom_end) { printk_warning("%6d:%s() - overflowed source buffer\n", __LINE__, __FUNCTION__); bytes = 0; -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Roman Kononov Sent: Friday, February 02, 2007 1:23 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] [PATCH] romstream off-by-1 On 02/02/2007 10:57 AM, Stefan Reinauer wrote: > I suggest comparing (rom + bytes - 1) > rom_end, because rom_end seems > to be the logical border we're checking for. (rom + bytes - 1 > rom_end) equals to (rom + bytes > rom_end + 1) provided that [rom,rom_end+1) does not cross 0x7fffffff+1 and ptrdiff_t is signed, or [rom,rom_end+1) does not corss 0xffffffff+1 and ptrdiff_t is unsigned. In linuxbios, [rom,rom_end+1) crosses neither boundary. Strictly speaking, an exception for the first statement is when ptrdiff_t is signed (which is our case); rom+bytes-1 does not overflow and is 0x7fffffff; rom+bytes does overflow and is 0x80000000; rom_end is, for example, 0xffff0000. Then, (rom + bytes - 1 > rom_end) is true (rom + bytes > rom_end + 1) is false For this to happen rom must be within [0x00000000-0x7fffffff], which is impossible. Any way, you flavor is attached. Regards, Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com>

1 0

Re: [LinuxBIOS] r2546 - trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804
by Lu, Yinghai 02 Feb '07

02 Feb '07

YES -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com(a)linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com@linuxbios.org] On Behalf Of svn(a)openbios.org Sent: Friday, February 02, 2007 2:40 PM To: linuxbios(a)linuxbios.org Subject: [LinuxBIOS] r2546 - trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804 Author: rminnich Date: 2007-02-02 23:40:10 +0100 (Fri, 02 Feb 2007) New Revision: 2546 Modified: trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/chip.h trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_usb.c Log: I have Sun Ultra40 workstation. Southbridge is nVidia CrushK8-04/nforce 2200 (too many names, sounds like a criminal). 1) Linuxbios loads kernel A; kernel A loads kernel B. Everything works fine. 2) Then I push the reset button. 3) Linuxbios loads kernel A; kernel A loads kernel B. Kernel B complains about wrong checksum of the mptable and crushes later. An investigation showed that in 3), short after kernel A (v2.6.19.2) sets the Bus Master Enable bit of the nVidia's USB1 controller (pci_set_master()), the mptable gets two bytes at physical address 0x80 damaged. Nothing is plugged to the USB ports. Other two Sun workstations had the same behavior. This does not make sense to me unless the controller has a HW bug. I believe, this should better be fixed in the kernel USB driver. For now this patch offers a possibility for linuxbios to reset the USB controller by setting HostControllerReset bit in HcCommandStatus Register. It is enablead by using 'register "usb1_hc_reset"="1"' in 'chip southbridge/nvidia/ck804' section of the mainboard's Config.lb. Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com Modified: trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/chip.h 2007-02-02 17:08:04 UTC (rev 2545) +++ trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/chip.h 2007-02-02 22:40:10 UTC (rev 2546) @@ -1,10 +1,11 @@ #ifndef CK804_CHIP_H #define CK804_CHIP_H -struct southbridge_nvidia_ck804_config +struct southbridge_nvidia_ck804_config { - unsigned int ide0_enable : 1; - unsigned int ide1_enable : 1; + unsigned int usb1_hc_reset : 1; + unsigned int ide0_enable : 1; + unsigned int ide1_enable : 1; unsigned int sata0_enable : 1; unsigned int sata1_enable : 1; unsigned long nic_rom_address; Modified: trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_usb.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_usb.c 2007-02-02 17:08:04 UTC (rev 2545) +++ trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_usb.c 2007-02-02 22:40:10 UTC (rev 2546) @@ -9,9 +9,22 @@ #include <device/pci_ops.h> #include "ck804.h" +static void usb1_init(struct device *dev) { + struct southbridge_nvidia_ck804_config const * conf=dev->chip_info; + if (conf->usb1_hc_reset) { + //Somehow the warm reset does not really resets the USB controller. + //Later, during boot, when the Bus Master bit is set, the USB + //controller trashes the memory, causing weird misbehavior. + //Was detected on Sun Ultra40, where mptable was damaged. + uint32_t bar0=pci_read_config32(dev,0x10); + uint32_t* regs=(uint32_t*)(bar0&~0xfff); + regs[2]|=1; //OHCI USB HCCommandStatus Register, HostControllerReset bit + } +} + static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) -{ - pci_write_config32(dev, 0x40, +{ + pci_write_config32(dev, 0x40, ((device & 0xffff) << 16) | (vendor & 0xffff)); } static struct pci_operations lops_pci = { @@ -22,7 +35,7 @@ .read_resources = pci_dev_read_resources, .set_resources = pci_dev_set_resources, .enable_resources = pci_dev_enable_resources, - .init = 0, + .init = usb1_init, // .enable = ck804_enable, .scan_bus = 0, .ops_pci = &lops_pci, -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

[LinuxBIOS] new feature - CrushK8-04 USB1 Controller Reset
by Roman Kononov 02 Feb '07

02 Feb '07

I have Sun Ultra40 workstation. Southbridge is nVidia CrushK8-04/nforce 2200 (too many names, sounds like a criminal). 1) Linuxbios loads kernel A; kernel A loads kernel B. Everything works fine. 2) Then I push the reset button. 3) Linuxbios loads kernel A; kernel A loads kernel B. Kernel B complains about wrong checksum of the mptable and crushes later. An investigation showed that in 3), short after kernel A (v2.6.19.2) sets the Bus Master Enable bit of the nVidia's USB1 controller (pci_set_master()), the mptable gets two bytes at physical address 0x80 damaged. Nothing is plugged to the USB ports. Other two Sun workstations had the same behavior. This does not make sense to me unless the controller has a HW bug. I believe, this should better be fixed in the kernel USB driver. For now this patch offers a possibility for linuxbios to reset the USB controller by setting HostControllerReset bit in HcCommandStatus Register. It is enablead by using 'register "usb1_hc_reset"="1"' in 'chip southbridge/nvidia/ck804' section of the mainboard's Config.lb. Signed-off-by: Roman Kononov <kononov195-lbl(a)yahoo.com>

4 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2007