coreboot

coreboot@coreboot.org

11 participants
39712 discussions

RE: S2885
by YhLu 26 Oct '04

26 Oct '04

Comment out // resource->limit = info->mask | (step - 1); In pnp_get_ioresource Will make it works right. Regards YH -----Original Message----- From: YhLu Sent: Tuesday, October 26, 2004 1:12 PM To: ebiederman(a)lnxi.com Cc: Ronald G. Minnich; linuxbios(a)clustermatic.org Subject: RE: S2885 You are right, after I comment out the superio section in Config.lb. it allocate correct io range for device in amd8111 PCI bridge. Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Tuesday, October 26, 2004 12:52 PM To: YhLu Cc: Ronald G. Minnich; linuxbios(a)clustermatic.org Subject: Re: S2885 YhLu <YhLu(a)tyan.com> writes: > Eric, > > I find the device on amd8111 pci io allocation get werid. Please check 6:b.0 > and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000. Agreed this is a bug. Currently the code updates the limit on bridges if all of the devices behind the bridge cannot use that limit. In theory that works great in practice however it barely works. With I/O devices typically the problem is typically superio chips with a limit of 0xfff. > It works well before you add set_subsystem. set_subsystem has been there since somewhere the start of the merge. Although all of the methods for the amd8111 and amd8131 were not. I suspect this has more to do with the updated pnp device code, which now correctly computes the limit address. And thus messes up the computation logic for everything else. At least if the resource is not set statically. If this is what I think it is, except for hard coding the superio resources I don't see a quick fix in the works. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

RE: S2885
by YhLu 26 Oct '04

26 Oct '04

You are right, after I comment out the superio section in Config.lb. it allocate correct io range for device in amd8111 PCI bridge. Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Tuesday, October 26, 2004 12:52 PM To: YhLu Cc: Ronald G. Minnich; linuxbios(a)clustermatic.org Subject: Re: S2885 YhLu <YhLu(a)tyan.com> writes: > Eric, > > I find the device on amd8111 pci io allocation get werid. Please check 6:b.0 > and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000. Agreed this is a bug. Currently the code updates the limit on bridges if all of the devices behind the bridge cannot use that limit. In theory that works great in practice however it barely works. With I/O devices typically the problem is typically superio chips with a limit of 0xfff. > It works well before you add set_subsystem. set_subsystem has been there since somewhere the start of the merge. Although all of the methods for the amd8111 and amd8131 were not. I suspect this has more to do with the updated pnp device code, which now correctly computes the limit address. And thus messes up the computation logic for everything else. At least if the resource is not set statically. If this is what I think it is, except for hard coding the superio resources I don't see a quick fix in the works. Eric

1 0

S2885
by YhLu 26 Oct '04

26 Oct '04

Eric, I find the device on amd8111 pci io allocation get werid. Please check 6:b.0 and 6:c.0 io allocation. It comes from 0x0000, instead of 0x1000. It works well before you add set_subsystem. Regards YH PCI_DOMAIN: 0000 00 <- [0x0000000400 - 0x0000000fff] io PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f0000000 - 0x00f03fffff] mem PCI: 00:18.0 1ba <- [0x00f0000000 - 0x00efffffff] prefmem <node 0 link 2> PCI: 00:18.0 1d8 <- [0x0000001000 - 0x0000000fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0> PCI: 00:18.0 1a8 <- [0x00f0300000 - 0x00f03fffff] mem <node 0 link 0> PCI: 00:18.0 1a2 <- [0x00f0000000 - 0x00f02fffff] mem <node 0 link 2> PCI: 01:01.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem PCI: 01:01.0 14 <- [0x00f0300000 - 0x00f0300000] mem PCI: 03:01.0 20 <- [0x00f0000000 - 0x00f00fffff] bus 4 mem PCI: 04:09.0 10 <- [0x00f0000000 - 0x00f000ffff] mem PCI: 03:01.1 10 <- [0x00f0200000 - 0x00f0200fff] mem PCI: 03:02.1 10 <- [0x00f0201000 - 0x00f0201fff] mem PCI: 03:03.0 1c <- [0x0000000000 - 0x0000000fff] bus 6 io PCI: 03:03.0 20 <- [0x00f0100000 - 0x00f01fffff] bus 6 mem PCI: 06:00.0 10 <- [0x00f0104000 - 0x00f0104fff] mem PCI: 06:00.1 10 <- [0x00f0105000 - 0x00f0105fff] mem PCI: 06:0b.0 10 <- [0x0000000010 - 0x0000000017] io PCI: 06:0b.0 14 <- [0x0000000030 - 0x0000000033] io PCI: 06:0b.0 18 <- [0x0000000020 - 0x0000000027] io PCI: 06:0b.0 1c <- [0x0000000040 - 0x0000000043] io PCI: 06:0b.0 20 <- [0x0000000000 - 0x000000000f] io PCI: 06:0b.0 24 <- [0x00f0107000 - 0x00f01073ff] mem PCI: 06:0c.0 10 <- [0x00f0106000 - 0x00f01067ff] mem PCI: 06:0c.0 14 <- [0x00f0100000 - 0x00f0103fff] mem And it should be PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io PCI_DOMAIN: 0000 01 <- [0x00e0000000 - 0x00efffffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f0000000 - 0x00f03fffff] mem PCI: 00:18.0 1ba <- [0x00f0000000 - 0x00efffffff] prefmem <node 0 link 2> PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2> PCI: 00:18.0 1d8 <- [0x0000003000 - 0x0000002fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0> PCI: 00:18.0 1a8 <- [0x00f0300000 - 0x00f03fffff] mem <node 0 link 0> PCI: 00:18.0 1a2 <- [0x00f0000000 - 0x00f02fffff] mem <node 0 link 2> PCI: 01:01.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem PCI: 01:01.0 14 <- [0x00f0300000 - 0x00f0300000] mem PCI: 03:01.0 20 <- [0x00f0000000 - 0x00f00fffff] bus 4 mem PCI: 04:09.0 10 <- [0x00f0000000 - 0x00f000ffff] mem PCI: 03:01.1 10 <- [0x00f0200000 - 0x00f0200fff] mem PCI: 03:02.1 10 <- [0x00f0201000 - 0x00f0201fff] mem PCI: 03:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 6 io PCI: 03:03.0 20 <- [0x00f0100000 - 0x00f01fffff] bus 6 mem PCI: 06:00.0 10 <- [0x00f0104000 - 0x00f0104fff] mem PCI: 06:00.1 10 <- [0x00f0105000 - 0x00f0105fff] mem PCI: 06:0b.0 10 <- [0x0000001010 - 0x0000001017] io PCI: 06:0b.0 14 <- [0x0000001030 - 0x0000001033] io PCI: 06:0b.0 18 <- [0x0000001020 - 0x0000001027] io PCI: 06:0b.0 1c <- [0x0000001040 - 0x0000001043] io PCI: 06:0b.0 20 <- [0x0000001000 - 0x000000100f] io PCI: 06:0b.0 24 <- [0x00f0107000 - 0x00f01073ff] mem PCI: 06:0c.0 10 <- [0x00f0106000 - 0x00f01067ff] mem PCI: 06:0c.0 14 <- [0x00f0100000 - 0x00f0103fff] mem

2 1

ARIMA HDAMA
by Ronald G. Minnich 26 Oct '04

26 Oct '04

The new boot speed is really nice to watch. I'm having one problem in that the irq table seems wrong now. Has anyone brought HDAMA up under the new tree, booted linux, and seen interrupts work on the ethernet devices? Just checking. I am going to take a closer look tomorrow. ron

4 4

FILO users
by Ronald G. Minnich 26 Oct '04

26 Oct '04

who is keeping FILO nowadays? I have a simple patch. ron

1 0

cpu,flash,sdram,usb
by Salvatore Lionetti 26 Oct '04

26 Oct '04

Hi, i'm choicing an alternati to boot loader. This is the system on which i'd wish to install linuxbios; here's the question: 1) if usb need initialization (like sdram controller); 2) where i can find doc on how to boot another kernel after linuxbios; 3) if you have any hint to me. Than you. ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica Scaricalo ora! http://it.messenger.yahoo.it

1 0

Re: FYI: Merge in progress...S2735
by ebiederman＠lnxi.com 24 Oct '04

24 Oct '04

"Yinghai Lu" <yhlu(a)tyan.com> writes: > Thanks. > > 1. no 64 bit PCI mem. > 2. better way get MC. > 3. enable memremap > 4. remove cpu_bus_scan. > > I guess it can be copy to intel/i855pm. Pretty much. Things like the memory remap may need to be removed but for the most part the e7501 code looks like a decent example of how to convert sizeram() to the new tree. Eric

1 0

RE: FYI: Merge in progress...S2735
by YhLu 23 Oct '04

23 Oct '04

Eric, I copy some line from amd k8 to intel e7501 northbridge.c. Can you check that for me? Regards YH -----Original Message----- From: YhLu Sent: Friday, October 22, 2004 11:53 AM To: ebiederman(a)lnxi.com; Ronald G. Minnich Cc: Li-Ta Lo; 'LinuxBIOS' Subject: RE: FYI: Merge in progress...S2735 Eric, I change sth for s2735. I don't know how to modify src/northbridge/intel/e7501/norbridge.c Can you have a look at that? Regards YH s2735 half update CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: src/cpu/intel/model_f2x/Config.lb CVS: src/cpu/intel/model_f2x/model_f2x_init.c CVS: src/cpu/intel/socket_mPGA604_533Mhz/chip.h CVS: src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c CVS: src/mainboard/tyan/s2735/Config.lb CVS: src/mainboard/tyan/s2735/auto.c CVS: src/mainboard/tyan/s2735/chip.h CVS: src/mainboard/tyan/s2735/failover.c CVS: src/mainboard/tyan/s2735/mainboard.c CVS: src/mainboard/tyan/s2735/mptable.c CVS: src/mainboard/tyan/s4880/Options.lb CVS: src/mainboard/tyan/s4882/Options.lb CVS: targets/tyan/s2735/Config.lb targets/tyan/s2735/ns2735 CVS: ---------------------------------------------------------------------- -----Original Message----- From: YhLu Sent: Friday, October 22, 2004 10:45 AM To: ebiederman(a)lnxi.com; Ronald G. Minnich Cc: Li-Ta Lo; 'LinuxBIOS' Subject: RE: FYI: Merge in progress...S2735 Eric, About S2735, in auto.c How to change #include "cpu/p6/apic_timer.c" Amd version is #include "cpu/amd/model_fxx/apic_timer.c" I can not find other apic_timer.c in src/cpu Regards YH _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

RE: FYI: Merge in progress...S2735
by YhLu 22 Oct '04

22 Oct '04

Eric, About S2735, in auto.c How to change #include "cpu/p6/apic_timer.c" Amd version is #include "cpu/amd/model_fxx/apic_timer.c" I can not find other apic_timer.c in src/cpu Regards YH

2 1

JTAG debugging
by Stephen.Kimball＠bench.com 22 Oct '04

22 Oct '04

I agree with Ron. JTAG debuggers are more robust. But I am interested in stepping through LinuxBIOS on a working target to quickly understand the code, so I'm able to attempt a port to a new target. I view it as a learning tool and a productivity tool. If you could show people how to use a product like the American Arium, you might get more help. Steve -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 22, 2004 3:06 PM To: Eric W. Biederman Cc: Kimball, Stephen; linuxbios(a)clustermatic.org Subject: Re: Makefile changes for symbols On Fri, 22 Oct 2004, Eric W. Biederman wrote: > Alternatively it might be work adding gdb stubs into LinuxBIOS. And doing > using a remote debugger that way. What a jtag interface provides > is really not much more than what gdb stubs provides. At least > not after memory is initialized. that's not quite correct. There are a host of cpu failures you can detect with a jtag interface that gdb stubs are useless for. GDB stubs requires that the processor be basically sane, jtag interfaces are not near as picky. ron

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot