coreboot

coreboot@coreboot.org

7 participants
39579 discussions

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

01 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 30 Aug '03

30 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

Infrastructure status....
by ebiederman＠lnxi.com 30 Aug '03

30 Aug '03

I have been working on merging the static and dynamic device trees, and I finally have a working version. The hard part was that I was enumerating hypertransport first thing and that was new code so any bug there and nothing looked like it was working. I have just a little bit more to finish up my initial superio example and then I plan on committing the code. I have had to extend the dynamic device tree in a couple of ways to get this far. Unless someone has some objects my plan is to tag the tree so it is possible to look back and then commit everything. There are lots of places where I am certain things can be done better but the code is far enough along to be useful. Which means it is now safe to put more eyes on the code and see how things are going. Eric

2 1

答复: AMD8111_DEV
by YhLu 30 Aug '03

30 Aug '03

These three files seems should be removed and the AMD8111_DEV should be removed too. -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月28日 8:26 收件人: linuxbios(a)clustermatic.org 主题: AMD8111_DEV Hi, Looking at the config variable AMD8111_DEV I find quite some strange things: ./mainboard/amd/solo/Config:option AMD8111_DEV=0x5 ./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800 ./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV ./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV ./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV ./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5 ./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800 ./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV It seems to be 5 in some places, and 0x3800 in some obsolete places, which makes me think that in some config files it is assumed to be shifted whereas in others it is assumed to contain an already shifted value. Same thing here: ./southbridge/amd/amd8111/cmos_boot_failover.inc: movl $(0x80000000 | AMD8111_DEV | 0x40), %eax ./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3) ./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300) This should be cleaned up. Any preferences for any variant? Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

re: Unified setup...
by YhLu 29 Aug '03

29 Aug '03

Stephan, I have checked the AMD sheet, and you are right it will not change to setting width and speed without reset or LDTSTOP_L. In the pci_device.c, there is some code about HT. I have removed the hardcode about width and speed and do some test, after I checked the REG, and it seems width is set right but the speed is not right. Maybe Eric need to check that part. 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. Regards YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月28日 7:40 收件人: linuxbios(a)clustermatic.org 主题: Re: Unified setup... Hi again, the coherent_ht.c changes are all to LYH's hardcodes to coherent_ht_finalize(). These are there to setup link speed and width on the cht nodes. I remember tomz from LNXI was working on that on a higher level at pci setup. Is that code complete by now? Are all bridges set up full speed? Then we could just drop this code, which i would favour. Otherwise it should walk into the motherboard specific code. As far as I can see this code is noop anyways since speed changes need a reset or LDTSTOP_L which is not asserted here. LYH, any comments? --- coherent_ht.c 2003-08-14 11:11:10.000000000 +0200 +++ coherent_ht.1.c 2003-08-28 06:42:50.000000000 +0200 [..] - PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x770000d0, + PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x11000020, [..] - PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000000, + PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000400, [..] - 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, Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 3

about VGA support in voyager2 board
by elife elife 29 Aug '03

29 Aug '03

Hi, I am trying to add VGA support in cocom voyager2 board. The VGA is found but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the original bios and found besides VGA BIOS I extracted, there is VSA driver. Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where should I put it? And need I do more things to make it work? Best Regards! ******** phoneix.bin BIOS component ******** No. Item-Name Original-Size Compressed-Size Original-File-Name ============================================================================== 0. System BIOS 20000h(128.00K) 12EECh(75.73K) original.tmp 1. XGROUP CODE 07340h(28.81K) 04D70h(19.36K) awardext.rom 2. EPA LOGO 0168Ch(5.64K) 002AAh(0.67K) AwardBmp.bmp 3. VGA ROM[1] 08000h(32.00K) 04229h(16.54K) gxivideo.208 4. PCI ROM[A] 0C800h(50.00K) 07536h(29.30K) RTSROM_M.LOM 5. VSA driver 20000h(128.00K) 09B2Fh(38.80K) GXM55306.BIN 6. LOGO BitMap 2583Ch(150.06K) 0474Bh(17.82K) n5535.bmp --------------------------------------------------------------------- INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1078, did=104 0x55 0xaa 0x40 0xeb 0x4b 0x37 0x34 0x30 0x30 0xe9 0x4c 0x19 0x77 0xcc 0x56 0x49 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

4 12

AMD8111_DEV
by Stefan Reinauer 28 Aug '03

28 Aug '03

Hi, Looking at the config variable AMD8111_DEV I find quite some strange things: ./mainboard/amd/solo/Config:option AMD8111_DEV=0x5 ./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800 ./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV ./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV ./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5 ./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV ./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5 ./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800 ./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV It seems to be 5 in some places, and 0x3800 in some obsolete places, which makes me think that in some config files it is assumed to be shifted whereas in others it is assumed to contain an already shifted value. Same thing here: ./southbridge/amd/amd8111/cmos_boot_failover.inc: movl $(0x80000000 | AMD8111_DEV | 0x40), %eax ./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3) ./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300) This should be cleaned up. Any preferences for any variant? Stefan -- Architecture Team SuSE Linux AG

2 1

Re: Unified setup...
by YhLu 28 Aug '03

28 Aug '03

Stephan, All about the duplicate code are for the multilink etc. I think after Eric and the code to enumerate the HT belongs to the CPU0. and make the static links to work in chip.h and ... it will be eliminated. (auto.c and pci_device.c and cpufixup.c may all need the static config processing code) Regards Yinghai Lu -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月28日 6:34 收件人: linuxbios(a)clustermatic.org 主题: Unified setup... Hi LYH, Ron and others, I've been looking at the recent changes that went into the tree, and I don't like the fact that a lot of code is duplicated. Is there some way to unify this? --- raminit.c 2003-08-28 14:43:39.000000000 +0200 +++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200 [..] - PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00, + PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20, This changes the link id where the southbridge is connected. We can get this information out of the configuration file since we are able to describe a map of all CHT components. On most machines the southbridge is probably connected to LDT0, but having two files for this one setting seems inappropriate. Ron, what is the easiest way of getting this information from the config file? LYH: To get this unified again, I added a resourcemap.c file to the s2885 directory that contains the resource map of the 2885. In auto.c this is used instead of the default. - PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000, + PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020, same as above. - PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003, - PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203, + PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003, These change the bus numbers and read/write enables. How can we write these more general? +/* //BY LYH add IOMMU 64M APERTURE PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70, PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002, PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300, //BY LYH END +*/ I added a configuration variable ENABLE_IOMMU and set it to 1 for all existing boards except the s2885. It would be nice to have the size of the aperture also selectable via the configuration file, or even better during firmware run time. I am scared that changes for special motherboards will contaminate the source tree and make it hard for anyone to see what is actually going on. If this happens in a source tree for a special motherboard, it does not really matter, but I think it is a good goal to keep the generic code clean and generic and make it even more generic in the places where it's not sufficient. I'll look into coherent_ht.1.c and see if this can be done more general as well. I commited the attached patch. Please comment. Stefan -- Architecture Team SuSE Linux AG

1 0

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