coreboot

coreboot@coreboot.org

24 participants
39545 discussions

epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte
by Niki Waibel 03 Sep '03

03 Sep '03

i am still trying to get this running: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte it took quite long until all parts arrived. anyway. the current problem is that if i plug the dip2plcc adapter into the bios savior socket epia-m does not boot anymore... (of course i've written the bios to the bios savior plcc chip before). that's very strange -- i am going to check the pins of the adapter. i've 2 adapters. both refuse to work with the board. maybe this is a high frequency electrical problem... does someone know in which "speed" the bios is accessed? niki

3 7

Re: [COMMIT] Infrastructure Updates 4
by YhLu 02 Sep '03

02 Sep '03

S2880 and S2882 is OK now. S2885 has some problems. I will try it more.. -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年9月2日 17:58 收件人: ron minnich 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 ron minnich <rminnich(a)lanl.gov> writes: > OK, this commit works for me. Not completely, but well enough to say it's > good enough. > > The only problem is the usual PIRQ fun. I'm going to try to work out a > reasonable solution given time. Cool that sounds about right. There is a very real chance I might reverse the order of the devices on the hypertransport chain. So I can allocate from the top of the unitid space instead of from the bottom. With that it will be easier to cram all of the hypertransport chains into bus 0 cleanly. So we really need to find a way to move irq information to the static to the dynamic device tree. That is one of the harder remaining problems. It is not a show stopper but something we need to do before we are done. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

Re: [COMMIT] Infrastructure Updates 4
by YhLu 02 Sep '03

02 Sep '03

Eric, Could you explain the Config.lb about northbridge and southbridge PCI numbering info? Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年9月2日 12:37 收件人: Stefan Reinauer 抄送: LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 Stefan Reinauer <stepan(a)suse.de> writes: > * Eric W. Biederman <ebiederman(a)lnxi.com> [030902 19:28]: > > If you want all of your hypertransport devices to be on bus 0, that is > > feasible but it will take a little more work. Right now each > > hypertranport chain get's it's own bus. > > What is missing to achieve this? Just a little code. Merging busses into bus 0 is an interesting logicistics feat, but the current infrastructure will allow it. > Can this cause trouble with current board implementations? Not it is software only. > In the Tyan update code, some hardcoded bus numbers were changed. We should be able to complete remove that. Right now each Hypertransport chains appears to be it's own bus and all of that information is dynamically calculated. The busses that are Hypertranpsort chains are enumerated just like other busses. The way to look at the code is that: - device.c has the logic to enumerate and assign resources to devices and busses. - pci_device.c has the methods for doing that on pci devices. - hypertransport.c has the methods for doing that with hypertranport devices. - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge. In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes. I have committed the code not in a final perfect state. But in a state where it works well enough to be useful. And whatever details we encounter are minor things. Passing information to the dynamic device tree from the static device tree is currently a weak area. But we are building one tree from the other so it is just a matter of a small amount of refactoring if we want to do something better. Basically what remains is to dive into the code see what it is doing, and tweak it a little if is not doing quite the right thing. But usually all that needs to happen is to improve a method of a device so that it operates better. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

[COMMIT] Infrastructure Updates 4
by ebiederman＠lnxi.com 02 Sep '03

02 Sep '03

OK. With this update I start taking advantage of the infrastructure changes I have been making with the merged trees to dynamically allocate superio device resources, and to enumerate hypertranport devices. The code is still rough around the edges but the basic ideas are there. If you want all of your hypertransport devices to be on bus 0, that is feasible but it will take a little more work. Right now each hypertranport chain get's it's own bus. Mostly I have updated the arima/hdama the rest of the boards I have only modified enough that they still function. OK Now I'm off to bug fix land for a few days. - 1.1.4 Major restructuring of hypertransport handling. Major rewerite of superio/NSC/pc87360 as a proof of concept for handling superio resources dynamically Updates to hard_reset handling when resetting because of the need to change hypertransport link speeds and widths. (a) No longer assume the boot is good just because we get to a hard reset point. (b) Set a flag to indicate that the BIOS triggered the reset so we don't decrement the boot counter. Updates to arima/hdama mptable so it tracks the new bus numbers Eric CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS src/config/Config src/config/Options.lb CVS: src/devices/Config.lb src/devices/pci_device.c CVS: src/include/device/device.h CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/arima/hdama/mptable.c CVS: src/mainboard/arima/hdama/reset.c CVS: src/northbridge/amd/amdk8/Config.lb CVS: src/northbridge/amd/amdk8/northbridge.c CVS: src/northbridge/amd/amdk8/reset_test.c CVS: src/superio/NSC/pc87360/superio.c CVS: Added Files: CVS: src/devices/hypertransport.c CVS: src/include/device/hypertransport.h CVS: src/northbridge/amd/amdk8/chip.h CVS: src/northbridge/amd/amdk8/misc_control.c CVS: src/northbridge/amd/amdk8/northbridge.h CVS: ----------------------------------------------------------------------

1 0

Re: Unified setup...
by YhLu 02 Sep '03

02 Sep '03

Then, the setup scripts tool should include that support and should have support for auto.c too. YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月29日 4:48 收件人: YhLu 抄送: linuxbios(a)clustermatic.org 主题: Re: Unified setup... * YhLu <YhLu(a)tyan.com> [030828 23:36]: > PS: > - PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000, > + PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000, > [..] > - PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000, > + PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000, > > should be there. It defines the bus number behind the links. It will be used > when enumerating the non-coherent devices. I agree. But maybe we find a nicer way of describing this. Are these "hard coded" in hardware? The motherboard configuration should then probably contain a busnumber value for each ht bridge that implements a pci bus southbridge amd/amd8131 "amd8131" register "bus0" = "5" end southbridge amd/amd8151 "amd8151" register "bus0" = "3" end Or should this be handled distinct from the bridges with options like option BUS1=99 option BUS2=5 ? Stefan -- Architecture Team SuSE Linux AG

2 1

epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte
by Niki Waibel 02 Sep '03

02 Sep '03

i checked the dip2plcc adapter -- everything is fine. all pins are connected properly. is it possible that this does not work because the wires are too long (bios savior + dip2plcc adapter)? would it help to reduce the clockrate of the epia-m? does someone know how that could be done? it is okay if i boot without dip2plcc converter and then plug it on top of the bios savior. i am going to try booting linux and then place only dip2plcc conv + doc mill. see if the mtd is detected. niki

2 3

[COMMIT] Infrastructure Updates 3
by ebiederman＠lnxi.com 02 Sep '03

02 Sep '03

At this point all of the major infrastructure changes. The next group of changes will start taking advantage of them to handle hypertransport more cleanly and dynamically. - Major update of the dynamic device tree so it can handle * subtractive resources * merging with the static device tree * more device types than just pci - The piece to watch out for is the new enable_resources method that was needed in all of the drivers Eric CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS src/arch/i386/lib/pci_ops.c src/arch/ppc/lib/pci_ops.c CVS: src/boot/hardwaremain.c src/config/Config CVS: src/config/Options.lb src/devices/Config.lb src/devices/chip.c CVS: src/devices/device.c src/devices/device_util.c CVS: src/devices/pci_device.c src/include/device/chip.h CVS: src/include/device/device.h src/include/device/pci.h CVS: src/include/device/resource.h CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/tyan/s2880/adaptec_scsi.c CVS: src/mainboard/tyan/s2880/intel_nic.c CVS: src/mainboard/tyan/s2880/promise_sata.c CVS: src/mainboard/tyan/s2882/adaptec_scsi.c CVS: src/mainboard/tyan/s2882/intel_nic.c CVS: src/mainboard/tyan/s2882/si_sata.c CVS: src/mainboard/tyan/s2885/adaptec_scsi.c CVS: src/mainboard/tyan/s2885/broadcom_nic.c CVS: src/mainboard/tyan/s2885/intel_nic.c CVS: src/mainboard/tyan/s2885/si_sata.c CVS: src/mainboard/tyan/s2885/ti_firewire.c CVS: src/southbridge/amd/amd8111/amd8111_acpi.c CVS: src/southbridge/amd/amd8111/amd8111_ide.c CVS: src/southbridge/amd/amd8111/amd8111_lpc.c CVS: src/southbridge/amd/amd8111/amd8111_usb.c CVS: src/southbridge/amd/amd8111/amd8111_usb2.c CVS: src/southbridge/amd/amd8131/amd8131_bridge.c CVS: src/southbridge/amd/amd8151/amd8151_agp3.c CVS: CVS: Committing in . CVS: CVS: Added Files: CVS: src/devices/root_device.c src/include/device/path.h CVS: ----------------------------------------------------------------------

1 0

[COMMIT] Infrastructure update 1
by ebiederman＠lnxi.com 01 Sep '03

01 Sep '03

Giant monolithic changes are dangerous and hard to track down so I am updating the infrastructure in small steps where everything should continue to work. If there are problems it becomes easier to track things down. This first change is the set of changes that gets the new configuration working for me. Until we starting doing something better with the development branch I bumping the version number and tagging each chunk of changes. So linuxbios_1_1_0 is tagged just before I started doing anything. And this set of changes is tagged linuxbios_1_1_1 Eric - Updates to config.g so that it works more reliably and has initial support for paths - Renamed some configuration variables SMP -> CONFIG_SMP MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS - Removed some dead configuration variables MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS SMP -> CONFIG_SMP FINAL_MAINBOARD_FIXUP SIO_BASE SIO_SYSTEM_CLK_INPUT NO_KEYBOARD USE_NORMAL_IMAGE SERIAL_CONSOLE USE_ELF_BOOT ENABLE_FIXED_AND_VARIABLE_MTRRS START_CPU_SEG DISABLE_WATCHDOG ENABLE_IOMMU AMD8111_DEV - Removed some assembly files that are no longer needed killed src/southbridge/amd/amd8111/smbus.inc killed src/southbrideg/amd/amd8111/cmos_boot_failover.inc killed src/ram/ramtest.inc - Updates to config.g so that it works more reliably and has initial support for paths - Renamed some configuration variables SMP -> CONFIG_SMP MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS - Removed some dead configuration variables MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS SMP -> CONFIG_SMP FINAL_MAINBOARD_FIXUP SIO_BASE SIO_SYSTEM_CLK_INPUT NO_KEYBOARD USE_NORMAL_IMAGE SERIAL_CONSOLE USE_ELF_BOOT ENABLE_FIXED_AND_VARIABLE_MTRRS START_CPU_SEG DISABLE_WATCHDOG ENABLE_IOMMU AMD8111_DEV - Removed some assembly files that are no longer needed killed src/southbridge/amd/amd8111/smbus.inc killed src/southbrideg/amd/amd8111/cmos_boot_failover.inc killed src/ram/ramtest.inc killed src/sdram/generic_dump_spd.inc killed src/sdram/generic_dump_spd.inc - Updated the arima/hdama to build with the new configuration system - Updated config.g to list all of the variables with make echo CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS documentation/RFC/config.tex src/arch/i386/boot/tables.c CVS: src/arch/i386/config/make.base CVS: src/arch/i386/include/arch/smp/mpspec.h CVS: src/arch/i386/lib/c_start.S src/arch/i386/smp/mpspec.c CVS: src/arch/i386/smp/secondary.S src/arch/i386/smp/start_stop.c CVS: src/arch/ppc/config/make.base src/boot/hardwaremain.c CVS: src/config/Config src/config/Options.lb CVS: src/config/linuxbios_c.ld src/include/device/device.h CVS: src/mainboard/amd/quartet/Config CVS: src/mainboard/amd/quartet/Config.lb CVS: src/mainboard/amd/quartet/auto.c CVS: src/mainboard/amd/quartet/example-fallback.config CVS: src/mainboard/amd/quartet/example-normal.config CVS: src/mainboard/amd/quartet/mainboard.c CVS: src/mainboard/amd/solo/Config src/mainboard/amd/solo/Config.lb CVS: src/mainboard/amd/solo/example-fallback.config CVS: src/mainboard/amd/solo/example-normal.config CVS: src/mainboard/amd/solo/mainboard.c CVS: src/mainboard/arima/hdama/Config CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/auto.c CVS: src/mainboard/arima/hdama/example-fallback.config CVS: src/mainboard/arima/hdama/example-normal.config CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/motorola/sandpoint/Config CVS: src/mainboard/motorola/sandpoint/example-altimus.config CVS: src/mainboard/motorola/sandpoint/hardwaremain.c CVS: src/mainboard/newisys/khepri/Config.lb CVS: src/mainboard/newisys/khepri/auto.c CVS: src/mainboard/newisys/khepri/mainboard.c CVS: src/mainboard/tyan/s2880/Config CVS: src/mainboard/tyan/s2880/Config.lb CVS: src/mainboard/tyan/s2880/mainboard.c CVS: src/mainboard/tyan/s2880/tyan-fallback.config CVS: src/mainboard/tyan/s2880/tyan-normal.config CVS: src/mainboard/tyan/s2882/Config CVS: src/mainboard/tyan/s2882/Config.lb CVS: src/mainboard/tyan/s2882/mainboard.c CVS: src/mainboard/tyan/s2882/tyan-fallback.config CVS: src/mainboard/tyan/s2882/tyan-normal.config CVS: src/mainboard/tyan/s2885/Config CVS: src/mainboard/tyan/s2885/Config.lb CVS: src/mainboard/tyan/s2885/mainboard.c CVS: src/mainboard/tyan/s2885/tyan-fallback.config CVS: src/mainboard/tyan/s2885/tyan-normal.config CVS: src/northbridge/amd/amdk8/coherent_ht.c CVS: src/northbridge/amd/amdk8/raminit.c CVS: targets/arima/hdama/Config.lb CVS: targets/embeddedplanet/ep405pc/Config.lb CVS: targets/motorola/sandpoint/Config.lb CVS: targets/tyan/s2880/Config.lb targets/tyan/s2882/Config.lb CVS: targets/tyan/s2885/Config.lb util/config/NLBConfig.py CVS: util/newconfig/config.g CVS: Removed Files: CVS: src/ram/ramtest.inc src/sdram/generic_dump_spd.inc CVS: src/southbridge/amd/amd8111/cmos_boot_failover.inc CVS: src/southbridge/amd/amd8111/smbus.inc CVS: ----------------------------------------------------------------------

2 1

[COMMIT] Infrastructure Update 2
by ebiederman＠lnxi.com 01 Sep '03

01 Sep '03

- 1.1.2 Add back in the hard_reset method from freebios1 this allows generic code to reset the box. Update the hypertransport setup code to automatically optimize hypertransport link widths and frequencies, and to call hard_reset if necessary for the changes to go into effect.

1 0

hdd register and dma
by Felix Kloeckner 31 Aug '03

31 Aug '03

hello, i am booting linuxbios from compatchflash and skip initialization of my additional hdd for faster booting (using kernel-commandline-argument "hdc=none"). after the system is up I register the hdd using #hdparm -R 0x170 0x376 15 /dev/hda everything works fine, except after enabling the drive this way I can't put it into dma mode, hdparm produces error like this: # hdparm -d1 /dev/hdc /dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) I am using elitegroup/p6stp-fl, sis630, sis5513 as IDE-controller any idea ps.: Bari Ari, did you find any solution to your "ide-hotswap" problem, please let me know! thanks Felix Kloeckner

2 1

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