coreboot

coreboot@coreboot.org

11 participants
39713 discussions

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

RE: Makefile changes for symbols
by Stephen.Kimball＠bench.com 03 Nov '04

03 Nov '04

> <Stephen.Kimball(a)bench.com> writes: > > > Rod, > > > > I'm using Source Point 7.0.0. I can see the source files. I can > > display source, disassembly or mixed. However, the disassembly doesn't > > match up with the source code. There is a way to give Source Point an > > offset when the symbols are loaded, but I can't seem to get the right > > value. I know the address of _start and __protected_start but these > > labels are not in linuxbios_c.o. I need to find the location of a > >symbol in linuxbios_c.o to compute the offset. > > ??? > > linuxbios_c is run at an absolute location in memory so the address > of the symbols within it should be fine. > > Look at readelf -a linuxbios_c. I have looked at the readelf output. Readelf says hardwaremain is at 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8 (32-bit mode). But it's not there even after the copy into RAM. > > Now these are not addresses within the rom chip. The are the addresses > the code is copied to after memory initialization. > > Currently romcc which generates the code that executes immediately > out of the rom chip does not give good debugging output. But > you should still be able to see the assembly. crt0.s should > match what you are looking at. > > You don't have the debugger in 16bit mode or something do you? SourcePoint switches to 32-bit mode 16 instructions into crt0.s at the JMP instruction. Am I right that crt0.s loads LinuxBIOS into RAM then branches to hardwaremain? Steve

6 15

Etherboot 5.2.5 with gcc 3.4
by YhLu 03 Nov '04

03 Nov '04

Eric, When using gcc 3.4 to compile Etherboot 5.2.5, I got ld -N -Ttext 0x20000 -T arch/i386/core/etherboot.lds -o bin/tg3.tmp bin/start32.o bin/pcbios.o bin/memsizes.o bin/basemem.o bin/linuxbios.o bin/config.o bin/tg3.o bin/bootlib.a bin/linuxbios.o(.text+0x337): In function `get_memsizes': : undefined reference to `memcpy' Regards YH

1 0

RE: i845GV ddr sdram init passed
by YhLu 03 Nov '04

03 Nov '04

send out raminit.inc, I could convert that into freebios2 for you. I guess raminit.inc is similar to e7501's. Regards YH -----Original Message----- From: zhu shi song [mailto:zhushisongzhu@yahoo.com] Sent: Wednesday, November 03, 2004 3:03 AM To: linuxbios(a)clustermatic.org Subject: i845GV ddr sdram init passed After working hard for three day, I have made i845gv ddr sdram work well. I can boot linux 2.4.27 with root filesystem on my hard disk. But linux 2.4.27 support new hardware weakly. So I hope I can boot linux 2.6. I have before used initrd dyn invented by l inux router project to boot linux 2.4. I like the way booting linux. (1) Who knows can initrd dyn support linux 2.6. I know the latest version of initrd dyn is for linux2.5.54. (2) If unfortunately I can't use initrd dyn again, how can I make my root fs? how can I boot linux 2.6 using tar.gz file as root filesystem? tks zhu __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

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