coreboot

coreboot@coreboot.org

11 participants
39713 discussions

Start a nNew thread

pnp_enable_devices
by YhLu 15 Nov '04

15 Nov '04

pnp_enable_devices(dev, &pnp_ops,....) I think the second parameter is not necessary and can be removed. Regards YH

2 1

recent changes
by Greg Watson 15 Nov '04

15 Nov '04

We now seem to have a chip keyword, in addition to config, device, driver and object keywords. We have a device_operations structure, a cpu_device_id structure and a cpu_driver structure as well as a pci_driver structure. The cpu tree has been reorganized to include vendor directories as well as architecture directories. We now seem to have a drivers directory tree. Can someone please provide the following information: 1. What does each keyword actually do now? 2. How do the keywords relate to the data structures? 3. What files are now auto generated, and how is everything linked together? 4. What keywords/data structures are actually needed, and by which devices? 5. How/where are the data structures used? 6. What is the rationale behind the reorganization of the cpu tree, and how is it supposed to work? 7. What is the purpose of the drivers tree, how do drivers differ from devices, and why is the console not included? The configuration process now seems so complicated that I can't see how we could expect someone to port to a new board without some basic description of how everything is supposed to work. I have a major vendor interested in doing this, but at the moment I can't offer them any help. Greg

2 1

RE: recent changes
by YhLu 15 Nov '04

15 Nov '04

According to my experience. With Chip ... Device.... end Device ... end End And "Config chip.h" The static.c will be produced according to the Config.lb in MB dir. All device under that chip will share one chip_operation, and the chip_operation will contain one enable_dev member. It will link and enable static that can not be done via pci function.... Regards YH -----Original Message----- From: Greg Watson [mailto:gwatson@lanl.gov] Sent: Monday, November 15, 2004 11:26 AM To: LinuxBIOS Subject: recent changes We now seem to have a chip keyword, in addition to config, device, driver and object keywords. We have a device_operations structure, a cpu_device_id structure and a cpu_driver structure as well as a pci_driver structure. The cpu tree has been reorganized to include vendor directories as well as architecture directories. We now seem to have a drivers directory tree. Can someone please provide the following information: 1. What does each keyword actually do now? 2. How do the keywords relate to the data structures? 3. What files are now auto generated, and how is everything linked together? 4. What keywords/data structures are actually needed, and by which devices? 5. How/where are the data structures used? 6. What is the rationale behind the reorganization of the cpu tree, and how is it supposed to work? 7. What is the purpose of the drivers tree, how do drivers differ from devices, and why is the console not included? The configuration process now seems so complicated that I can't see how we could expect someone to port to a new board without some basic description of how everything is supposed to work. I have a major vendor interested in doing this, but at the moment I can't offer them any help. Greg _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

recent changes
by Greg Watson 15 Nov '04

15 Nov '04

1 0

vgabios/testbios
by Ronald G. Minnich 15 Nov '04

15 Nov '04

I've just added a few new fixes to vgabios, and expect to add more as I get it to the point that it can run this BIOS for the 855gm board. Just FYI. ron

2 1

Re: coherent_ht.c,1.29,1.30
by Stefan Reinauer 15 Nov '04

15 Nov '04

* Eric Biederman <ebiederm(a)users.sourceforge.net> [041115 11:46]: > Modified Files: > coherent_ht.c > Log Message: > - optimize_link_read_pointers compiles now on the solo so don't disable it. The problem was actually not htat it did not compile, but that it made linuxbios hang on the hardware. Did you verify that it does not do this anymore with optimize_link_read_pointers()? I cannot verify this since I don't have access to test hardware anymore. > --- coherent_ht.c 15 Nov 2004 10:46:43 -0000 1.30 > *** 643,651 **** > coherent_ht_finalize(result.nodes); > result.needs_reset = apply_cpu_errata_fixes(result.nodes, result.needs_reset); > - > - #if CONFIG_MAX_CPUS > 1 /* Why doesn't this work on the solo? */ > result.needs_reset = optimize_link_read_pointers(result.nodes, result.needs_reset); > - #endif > - > return result.needs_reset;

2 4

ram_check
by Gin 15 Nov '04

15 Nov '04

I have a question with the ram. Don't know if anyone has heard the same problem before. I ran the ram_check procedure and it reports that there are always 4 bytes out of every 64 bytes that reads zero. I think that's why I can run the code in the ram but it gets reset in the in different places. Gin

3 2

RE: romcc quesiton
by YhLu 15 Nov '04

15 Nov '04

I met that too, and I have remove some un converted code in E7501 raminit.c YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Tuesday, November 09, 2004 6:44 AM To: linuxbios(a)clustermatic.org Subject: romcc quesiton I'm seeing that with the new built-in preprocessor the following types of things work incorrectly: #if 0 blha blha #endif The #if 0 is ignored, the romcc tries to compile the code. Is this the expected behavior? ron p.s. cvs update as of this morning. _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

5 14

ram init
by Gin Lin 14 Nov '04

14 Nov '04

Does anyone know if the raminit.c under intel/E7501 is stable enough? I am having a problem with the system reseting when it jumps to the first address in the ram. Could the procedures of writing NorthBrige registers have problems? thanks, Gin

3 5

i845 MB progress
by zhu shi song 14 Nov '04

14 Nov '04

Now I can boot my i845 MB successfully with kernel 2.4.27. please see content of /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 3) . Prefetchable 32 bit memory at 0xe0000000 [0xe3ffffff]. Bus 0, device 2, function 0: VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integ rated Graphics Device (rev 3). IRQ 11. Prefetchable 32 bit memory at 0xd0000000 [0xd7ffffff]. Non-prefetchable 32 bit memory at 0xdff80000 [0xdfffffff]. Bus 3, device 10, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ ( rev 16). IRQ 3. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xcc00 [0xccff]. Non-prefetchable 32 bit memory at 0xdfdfff00 [0xdfdfffff]. It seemed that linux assigned correct irq to rtl8139. But there was some trouble with ethernet. (1)insmod 8139too ---> ok (2)ifconfig eth0 192.12.10.167 ---> error linux box hangup and the driver output "rtl8139: exiting interrupt, intr_status=0000" continuously. my settings: (1)don't set FEC0__xxxx regs (2) 0x4d0=28 0x4d1=1c 0x21=e8 0xA1=3f who has met the same problem and can give some glues to solve it? tks zhu __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

2 1

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