coreboot November 2004

coreboot@coreboot.org

31 participants
183 discussions

Just for Fun: 01/12/01 submission
by David Nicol 04 Nov '04

04 Nov '04

Just for Fun: 01/12/01: Submit your ideas for the best use of all the useless factory flash parts we've got laying around Thesis: Glue on appropriate fishhooks and sell for use as lures. Antithesis: Donate to elementary schools as a craft supply. Synthesis: Outsource gluing on the fishhooks to child labor. -- David L Nicol

1 0

RE: Removing device driver code in mainboard.c for Tyan boards?
by YhLu 04 Nov '04

04 Nov '04

Please get new one from CVS tree. It checks the device class code. YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, November 04, 2004 1:05 PM To: YhLu Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? On Thu, 2004-11-04 at 14:08, YhLu wrote: > Please check the si/3114 > > I guess you need to keep > Ati > Si > Trident > The si_sata.c only enable the BM DMA. Are you going to do something more ? Ollie

2 1

RE: Removing device driver code in mainboard.c for Tyan boards?
by YhLu 04 Nov '04

04 Nov '04

Please check the si/3114 I guess you need to keep Ati Si Trident Regards YH -----Original Message----- From: YhLu Sent: Thursday, November 04, 2004 12:37 PM To: Li-Ta Lo Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? Yes, We still need some, I will give a example about SI image chip. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, November 04, 2004 12:05 PM To: YhLu Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? On Thu, 2004-11-04 at 10:45, YhLu wrote: > OK for me. > > Some line I want to use print mem or pci at the end of LinuxBIOS can not be > used now. Eric removed the CHIP_PASS.... > I guess we don't need the driver/intel|si||adaptec|boradcom anymore ? Ollie > Regards > > YH > > -----Original Message----- > From: Li-Ta Lo [mailto:ollie@lanl.gov] > Sent: Thursday, November 04, 2004 9:07 AM > To: YhLu; LinuxBIOS > Subject: Removing device driver code in mainboard.c for Tyan boards? > > YhLu, > > Now we have a totally new device driver architecture, could we remove > those #if 0 #endf code in the mainboard.c for Tyan board? > > Ollie > _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 2

RE: Removing device driver code in mainboard.c for Tyan boards?
by YhLu 04 Nov '04

04 Nov '04

I want to print PCI regs after PCI device initialization. Where need to put the calling print_pci_regs_all? In hardwaremain ??? YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, November 04, 2004 1:13 PM To: YhLu Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? On Thu, 2004-11-04 at 14:17, YhLu wrote: > It is disabled via DEBUG. > I know. But why you need a virtual debug_device? Just to dump the PCI CS registers ? Ollie > YH > > -----Original Message----- > From: Li-Ta Lo [mailto:ollie@lanl.gov] > Sent: Thursday, November 04, 2004 1:11 PM > To: YhLu > Cc: LinuxBIOS > Subject: RE: Removing device driver code in mainboard.c for Tyan boards? > > On Thu, 2004-11-04 at 14:08, YhLu wrote: > > Please check the si/3114 > > > > I guess you need to keep > > Ati > > Si > > Trident > > > > > Why you put the debug_device back ? > > Ollie >

2 1

RE: Removing device driver code in mainboard.c for Tyan boards?
by YhLu 04 Nov '04

04 Nov '04

It is disabled via DEBUG. YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, November 04, 2004 1:11 PM To: YhLu Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? On Thu, 2004-11-04 at 14:08, YhLu wrote: > Please check the si/3114 > > I guess you need to keep > Ati > Si > Trident > Why you put the debug_device back ? Ollie

2 1

RE: Removing device driver code in mainboard.c for Tyan boards?
by YhLu 04 Nov '04

04 Nov '04

Yes, We still need some, I will give a example about SI image chip. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, November 04, 2004 12:05 PM To: YhLu Cc: LinuxBIOS Subject: RE: Removing device driver code in mainboard.c for Tyan boards? On Thu, 2004-11-04 at 10:45, YhLu wrote: > OK for me. > > Some line I want to use print mem or pci at the end of LinuxBIOS can not be > used now. Eric removed the CHIP_PASS.... > I guess we don't need the driver/intel|si||adaptec|boradcom anymore ? Ollie > Regards > > YH > > -----Original Message----- > From: Li-Ta Lo [mailto:ollie@lanl.gov] > Sent: Thursday, November 04, 2004 9:07 AM > To: YhLu; LinuxBIOS > Subject: Removing device driver code in mainboard.c for Tyan boards? > > YhLu, > > Now we have a totally new device driver architecture, could we remove > those #if 0 #endf code in the mainboard.c for Tyan board? > > Ollie >

1 0

Removing device driver code in mainboard.c for Tyan boards?
by Li-Ta Lo 04 Nov '04

04 Nov '04

YhLu, Now we have a totally new device driver architecture, could we remove those #if 0 #endf code in the mainboard.c for Tyan board? Ollie

1 0

Build fixes....
by ebiederman＠lnxi.com 04 Nov '04

04 Nov '04

I have been working on getting all of the working ports in the tree to build. Of particular interest is that the mainboard/via/epia builds. The exceptions are currently: - i855pm as it's raminit.c is still 1/2 in assembly. - The via epia-m as it's southbridge code needs to converted so it will run. - The ppc ports as I am still building a cross compiler and have not had a chance to test it yet. - Whatever I fat fingered at the last minute before I decided to call it quits. Cross compiler currently works in LinuxBIOS (we routinely use it on amd64) so I don't expect problems compile testing the ppc code, as soon as I have built a cross compiler. Our dependency information is currently atrocious. Ideally abuild would allow the dependencies to prevent us from rebuilding any port that has built successfully when none of it's dependencies have changed. Unfortunately we don't generate those properly, and abuild.sh is not quite smart enough yet to take advantage of dependencies even if we properly generated them. This is something to put on the wishlist. Anyway my checking comments are below. Hopefully I have not gotten too spacey and missed something important. Eric - Update abuild.sh so it will rebuild successfull builds - Move pci_set_method out of hardwaremain.c - Re-add debugging name field but only include the CONFIG_CHIP_NAME is enabled. All instances are now wrapped in CHIP_NAME - Many minor cleanups so most ports build. - Implemented failover.c on many ports where it was previously a stub. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: documentation/LinuxBIOS-AMD64.tex src/arch/i386/lib/Config.lb CVS: src/arch/i386/lib/pci_ops.c src/boot/hardwaremain.c CVS: src/config/Config.lb src/config/Options.lb CVS: src/cpu/amd/socket_754/socket_754.c CVS: src/cpu/amd/socket_940/socket_940.c CVS: src/cpu/intel/slot_2/slot_2.c CVS: src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c CVS: src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c CVS: src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c CVS: src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c CVS: src/include/device/device.h src/include/device/pci_ops.h CVS: src/mainboard/Iwill/DK8S2/Config.lb CVS: src/mainboard/Iwill/DK8S2/auto.c CVS: src/mainboard/Iwill/DK8S2/chip.h CVS: src/mainboard/Iwill/DK8S2/cmos.layout CVS: src/mainboard/Iwill/DK8S2/mainboard.c CVS: src/mainboard/Iwill/DK8S2/mptable.c CVS: src/mainboard/Iwill/DK8X/Config.lb CVS: src/mainboard/Iwill/DK8X/auto.c CVS: src/mainboard/Iwill/DK8X/chip.h CVS: src/mainboard/Iwill/DK8X/cmos.layout CVS: src/mainboard/Iwill/DK8X/mainboard.c CVS: src/mainboard/Iwill/DK8X/mptable.c CVS: src/mainboard/amd/quartet/Config.lb CVS: src/mainboard/amd/quartet/auto.c CVS: src/mainboard/amd/quartet/chip.h CVS: src/mainboard/amd/quartet/mainboard.c CVS: src/mainboard/amd/quartet/mptable.c CVS: src/mainboard/amd/serenade/Config.lb CVS: src/mainboard/amd/serenade/auto.c CVS: src/mainboard/amd/serenade/chip.h CVS: src/mainboard/amd/serenade/mainboard.c CVS: src/mainboard/amd/serenade/mptable.c CVS: src/mainboard/amd/solo/Config.lb CVS: src/mainboard/amd/solo/mainboard.c CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/auto.c CVS: src/mainboard/arima/hdama/cmos.layout CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/densitron/dpx114/Config.lb CVS: src/mainboard/densitron/dpx114/auto.c CVS: src/mainboard/densitron/dpx114/chip.h CVS: src/mainboard/densitron/dpx114/failover.c CVS: src/mainboard/densitron/dpx114/mainboard.c CVS: src/mainboard/digitallogic/adl855pc/Config.lb CVS: src/mainboard/digitallogic/adl855pc/auto.c CVS: src/mainboard/digitallogic/adl855pc/chip.h CVS: src/mainboard/digitallogic/adl855pc/failover.c CVS: src/mainboard/digitallogic/adl855pc/mainboard.c CVS: src/mainboard/emulation/qemu-i386/auto.c CVS: src/mainboard/emulation/qemu-i386/mainboard.c CVS: src/mainboard/ibm/e325/Config.lb CVS: src/mainboard/ibm/e325/Options.lb CVS: src/mainboard/ibm/e325/auto.c src/mainboard/ibm/e325/chip.h CVS: src/mainboard/ibm/e325/mainboard.c CVS: src/mainboard/ibm/e325/mptable.c CVS: src/mainboard/newisys/khepri/Config.lb CVS: src/mainboard/newisys/khepri/auto.c CVS: src/mainboard/newisys/khepri/chip.h CVS: src/mainboard/newisys/khepri/mainboard.c CVS: src/mainboard/newisys/khepri/mptable.c CVS: src/mainboard/technologic/ts5300/Config.lb CVS: src/mainboard/technologic/ts5300/mainboard.c CVS: src/mainboard/tyan/s2735/mainboard.c CVS: src/mainboard/tyan/s2850/mainboard.c CVS: src/mainboard/tyan/s2880/mainboard.c CVS: src/mainboard/tyan/s2881/mainboard.c CVS: src/mainboard/tyan/s2882/auto.c CVS: src/mainboard/tyan/s2882/mainboard.c CVS: src/mainboard/tyan/s2885/mainboard.c CVS: src/mainboard/tyan/s4880/auto.c CVS: src/mainboard/tyan/s4880/mainboard.c CVS: src/mainboard/tyan/s4882/mainboard.c CVS: src/mainboard/via/epia/Config.lb src/mainboard/via/epia/auto.c CVS: src/mainboard/via/epia/failover.c CVS: src/mainboard/via/epia/mainboard.c CVS: src/mainboard/via/epia-m/Config.lb CVS: src/mainboard/via/epia-m/auto.c CVS: src/mainboard/via/epia-m/chip.h CVS: src/mainboard/via/epia-m/failover.c CVS: src/mainboard/via/epia-m/mainboard.c CVS: src/northbridge/amd/amdk8/northbridge.c CVS: src/northbridge/emulation/qemu-i386/northbridge.c CVS: src/northbridge/intel/e7501/northbridge.c CVS: src/northbridge/intel/i855pm/northbridge.c CVS: src/northbridge/intel/i855pm/raminit.c CVS: src/northbridge/transmeta/tm5800/northbridge.c CVS: src/northbridge/via/vt8601/northbridge.c CVS: src/northbridge/via/vt8623/northbridge.c CVS: src/northbridge/via/vt8623/raminit.c CVS: src/southbridge/amd/amd8111/amd8111.c CVS: src/southbridge/intel/i82801dbm/i82801dbm.c CVS: src/southbridge/intel/i82801er/i82801er.c CVS: src/southbridge/ricoh/rl5c476/rl5c476.c CVS: src/southbridge/via/vt8231/vt8231.c CVS: src/southbridge/via/vt8235/vt8235.c CVS: src/superio/NSC/pc87360/superio.c CVS: src/superio/NSC/pc87366/chip.h CVS: src/superio/NSC/pc87366/superio.c CVS: src/superio/NSC/pc97307/superio.c CVS: src/superio/via/vt1211/vt1211.c CVS: src/superio/winbond/w83627hf/superio.c CVS: src/superio/winbond/w83627hf/w83627hf.h CVS: src/superio/winbond/w83627hf/w83627hf_early_serial.c CVS: src/superio/winbond/w83627thf/chip.h CVS: src/superio/winbond/w83627thf/superio.c util/abuild/abuild.sh CVS: Added Files: CVS: src/arch/i386/include/arch/pci_ops.h CVS: src/arch/i386/lib/pci_ops_auto.c CVS: src/arch/i386/lib/pci_ops_conf1.c CVS: src/arch/i386/lib/pci_ops_conf2.c CVS: src/arch/ppc/include/arch/pci_ops.h CVS: src/mainboard/Iwill/DK8S2/Options.lb CVS: src/mainboard/Iwill/DK8X/Options.lb CVS: src/mainboard/densitron/dpx114/Options.lb CVS: src/mainboard/digitallogic/adl855pc/Options.lb CVS: src/mainboard/via/epia-m/Options.lb CVS: ----------------------------------------------------------------------

1 0

RE: Merge/Cleanup status
by YhLu 03 Nov '04

03 Nov '04

FYI With gcc 3.4 linuxbios_rom.rom spare 1400 bytes. With gcc 3.2.2 in RH9 ./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b input/output = 76396/29877 = 2.557 cp linuxbios_ram.nrv2b linuxbios_ram.rom echo "INCLUDE ldoptions" > ldscript.ld ; for file in /home/yhlu/xx/xx/freebios2/src/arch/i386/init/ldscript.lb /home/yhlu/xx/xx/freebios2/src//cpu/x86/16bit/entry16.lds /home/yhlu/xx/xx/freebios2/src//cpu/x86/32bit/entry32.lds /home/yhlu/xx/xx/freebios2/src//cpu/x86/16bit/reset16.lds /home/yhlu/xx/xx/freebios2/src//arch/i386/lib/id.lds /home/yhlu/xx/xx/freebios2/src//arch/i386/lib/failover.lds ; do echo "INCLUDE $file" >> ldscript.ld ; done /usr/bin/gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o nm -n linuxbios | sort > linuxbios.map objcopy -O binary linuxbios linuxbios.strip /usr/bin/gcc -o buildrom /home/yhlu/xx/xx/freebios2/util/buildrom/buildrom.c ./buildrom linuxbios.strip linuxbios.rom ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf 0x10000 0x20000 linuxbios image is 66272 bytes; only 65536 allowed Linuxbios input file larger than allowed size! With gcc 3.4 ./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b input/output = 74572/28488 = 2.618 cp linuxbios_ram.nrv2b linuxbios_ram.rom gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o nm -n linuxbios | sort > linuxbios.map objcopy -O binary linuxbios linuxbios.strip ./buildrom linuxbios.strip linuxbios.rom ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf 0x10000 0x20000

1 0

flash_rom on SST49LF004B tips?
by Donald Zoch 03 Nov '04

03 Nov '04

I'm trying to get the flash_rom program working on the SST49LF004B. This is the part that is coming in our newer Arima HDAMA boards that replaces the SST49LF040. It has the same id as the SST49LF004A, but is different in that when we first started trying to flash it, the flash looked like it worked but would never verify. I took a look at the data sheet and from the looks of it there are these block locking registers that the zero bit must be cleared in in order to write to certain parts of the flash. At least that's why I think it's not flashing. I'm trying to zero out the registers, but it appears as if the first 4 cannot be cleared out. The last 4 look like they're being set to zero. I have tried to calculate the register locations by looking at the probe jedec code and seeing that the jedec ID registers are at bios and bios + 0x01. I then looked in the data sheet at where those registers appear in the memory map and then calculated the register memory locations as offsets to bios, some negative offsets and some positive. I've also tried anding that value with 0xFE just to zero out the bit that I need, but that doesn't seem to work. I can never seem to change the values in the first four registers. Do either of you have any pointers on how to get this to work? I will attach the data sheet for the flash part. It's the 49lf004b that I'm interested in. void unprotect_49lf004b(volatile unsigned char *bios) { *(volatile unsigned char *) (bios + 0x30002) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x30002)); *(volatile unsigned char *) (bios + 0x20002) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x20002)); *(volatile unsigned char *) (bios + 0x10002) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x10002)); *(volatile unsigned char *) (bios + 0x00002) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x00002)); *(volatile unsigned char *) (bios - 0xFFFE) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0xFFFE)); *(volatile unsigned char *) (bios - 0x1FFFE) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x1FFFE)); *(volatile unsigned char *) (bios - 0x2FFFE) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x2FFFE)); *(volatile unsigned char *) (bios - 0x3FFFE) = 0x00; printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x3FFFE)); } Donald ---- Donald Zoch Phone: (512) 602-7945 Pager: (512) 604-5401 donald.zoch(a)amd.com

4 3

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

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 November 2004