coreboot

coreboot@coreboot.org

11 participants
39713 discussions

ppc targets
by Stefan Reinauer 14 Nov '04

14 Nov '04

The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c struct mem_range is never ever defined. Is it struct lb_memory?! I have a bunch of other patches lying around that I will commit if nobody complains Stefan

5 7

Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging
by Ken Fuchs 12 Nov '04

12 Nov '04

Purpose: To use AMD's HDT hardware/software to debug LinuxBIOS on various mainboards and chipsets. Two HDT headers were added to a commercial Tyan S2885 board. Here's my hardware setup: S2885 with HDT CPU0 header <-> HDT ribbon cable and HDT CPU1 header <-> HDT ribbon cable HDT ribbon cable <-> HDT Multiprocessor Adapter HDT ribbon cable <-> | HDT Multiprocessor Adapter <-> Macraigor Systems' OCDemon (Raven) OCDemon (Raven) <-> parallel cable <-> host EPP mode port Power up sequence: 1) Host 2) Target 3) OCDemon (Raven) 4) HDT MP Adapter Symptoms of the problem: 1) OCDemon host and target lights never go on. 2) When using the host HDT software to open a new workspace, only 1 processor is shown as available. 3) While completing the opening of this single processor workspace, a warning window with the text below pops open: +--------------------------------------------+ |Communication between HDT and | |Processor No. 0 has problem! | | | |Please check your HDT host | |and target TAP connections. | | | |Do you want to continue with incorrect info?| +--------------------------------------------+ Possible clue to the solution: Missing TDI/TDO jumpers or jumper headers? There is a 2x3 header pad (no header) directly between the P1 socket and the P0 DIMM sockets that could be the correct place for these jumper headers. Maybe all I need to do is add a 2x3 header there and trace the routes of the six pins, hopefully back to the P0's HDT connector? (I don't have access to the S2885's schematics.) It seems that MP HDT must be enabled in this way. I know that reference boards have toggle switches for this purpose. Please respond with your suggestions. Thank you very much! Sincerely, Ken Fuchs <kfuchs(a)winternet.com>

2 2

Re: ppc targets
by ebiederman＠lnxi.com 12 Nov '04

12 Nov '04

Greg Watson <g.watson(a)computer.org> writes: > On Nov 11, 2004, at 7:27 PM, Eric W. Biederman wrote: > > > Stefan Reinauer <stepan(a)openbios.org> writes: > > > >> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c > >> struct mem_range is never ever defined. Is it struct lb_memory?! > > > > That is because of the big change where sizeram was removed. > > I think the definition originally sat in src/include/mem.h > > Which has been removed, because it is no longer used. > > > > So where/how is this done now? read_resources of an appropriate device now returns the information. > What else has been changed? Everything (short of interrupts) is now done through the device tree. The static device tree now uses the same nodes as the dynamic device tree. > It would be nice if a change like this was accompanied by a > description of what has been done, particularly if targets are left > for someone else to update. It was not the intention to leave this for someone else to update. The ppc ports were simply at the end of the list. And beyond that their structure does not much resemble the structure of the other ports on x86. Just glancing at the ppc code I have not seen an appropriate device to attach the code to. I was planning on looking into the powerpc code in the next couple of days. To see if I could sort this out. Eric

1 0

RE: mtrr
by YhLu 11 Nov '04

11 Nov '04

x86_setup_mtrrs should be split to x86_setup_fixed_mtrrs x86_setup_var_mtrrs x86_setup_enable_mtrrs and for Opteron it can reuse x86_setup_var_mtrrs x86_setup_enable_mtrrs and x86_setup_var_mtrrs can take the cupid or sth as parameter to find out 40bit or 32 bit. YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Thursday, November 11, 2004 6:20 PM To: YhLu Cc: 'Ronald G. Minnich'; 'linuxbios(a)clustermatic.org' Subject: Re: mtrr YhLu <YhLu(a)tyan.com> writes: > In the cpu/x86/mtrr/mtrr.c > > #warning "FIXME I do not properly handle address more than 36 physical > address bits" > #ifdef k8 > # define ADDRESS_BITS 40 > #else > # define ADDRESS_BITS 36 > #endif > #define ADDRESS_BITS_HIGH (ADDRESS_BITS - 32) > #define ADDRESS_MASK_HIGH ((1u << ADDRESS_BITS_HIGH) - 1) > > It seems someone already remove k8 from Option.lb > > Then .... > > Regards Interesting. The mtrr's actually work and the kernel is confused. However what we need to do is call the appropriate cpuid function to compute it or pass in the number of address bits. It should not be a compile time option, at least not in the generic code. What happens when we get can plug in cpus with different address bit limits. Eric

1 0

autobuild statistics
by Stefan Reinauer 11 Nov '04

11 Nov '04

Hi, The abuild script checks for new checkins now every 4h and logs are placed at: http://snapshots.linuxbios.org/stats/ BTW, the latest changes made things a little more dramatic again. In size, compile time and compile success. Stefan

2 3

RE: mtrr
by YhLu 11 Nov '04

11 Nov '04

In the cpu/x86/mtrr/mtrr.c #warning "FIXME I do not properly handle address more than 36 physical address bits" #ifdef k8 # define ADDRESS_BITS 40 #else # define ADDRESS_BITS 36 #endif #define ADDRESS_BITS_HIGH (ADDRESS_BITS - 32) #define ADDRESS_MASK_HIGH ((1u << ADDRESS_BITS_HIGH) - 1) It seems someone already remove k8 from Option.lb Then .... Regards YH -----Original Message----- From: YhLu Sent: Thursday, November 11, 2004 6:00 PM To: YhLu; ebiederman(a)lnxi.com; Ronald G. Minnich Cc: linuxbios(a)clustermatic.org Subject: RE: mtrr On 2.4.22 it becomes to ~ # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=32768MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=16384MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=4096MB: write-back, count=1 x 16 -----Original Message----- From: YhLu Sent: Thursday, November 11, 2004 5:24 PM To: ebiederman(a)lnxi.com; Ronald G. Minnich Cc: linuxbios(a)clustermatic.org Subject: mtrr I just found the mtrr after booting is not right. ~ # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=985088MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1 and it should be reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1 and it is has 98340MB more = 0xf0 0000 0000. Regards YH _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

RE: mtrr
by YhLu 11 Nov '04

11 Nov '04

On 2.4.22 it becomes to ~ # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=32768MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=16384MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=4096MB: write-back, count=1 x 16 -----Original Message----- From: YhLu Sent: Thursday, November 11, 2004 5:24 PM To: ebiederman(a)lnxi.com; Ronald G. Minnich Cc: linuxbios(a)clustermatic.org Subject: mtrr I just found the mtrr after booting is not right. ~ # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=985088MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1 and it should be reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1 and it is has 98340MB more = 0xf0 0000 0000. Regards YH _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

mtrr
by YhLu 11 Nov '04

11 Nov '04

I just found the mtrr after booting is not right. ~ # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=985088MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1 and it should be reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1 and it is has 98340MB more = 0xf0 0000 0000. Regards YH

1 0

RE: autobuild statistics
by YhLu 11 Nov '04

11 Nov '04

Someone (who recent format the coherent_ht.c) need to static void fill_row(u8 node, u8 row, u32 value) { pci_write_config32(NODE_HT(node), 0x40+(row<<2), value); } Before #if CONFIG_MAX_CPUS > 1 to support ONE AMD K8 YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Thursday, November 11, 2004 1:11 PM To: linuxbios(a)clustermatic.org Subject: autobuild statistics Hi, The abuild script checks for new checkins now every 4h and logs are placed at: http://snapshots.linuxbios.org/stats/ BTW, the latest changes made things a little more dramatic again. In size, compile time and compile success. Stefan _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: Tyan/s2735
by YhLu 11 Nov '04

11 Nov '04

YES -----Original Message----- From: Gin [mailto:ginlin@nexcom.com.tw] Sent: Wednesday, November 10, 2004 11:03 PM To: 'Steven James' Cc: linuxbios(a)clustermatic.org Subject: Tyan/s2735 Steven, Thanks for the info. I've got the ram up by filling the some values in North Bridge(I reference a regular bios). I have an essential question about the code base for Tyan/s2735. Has it ever successfully built and run on that board? I have to make sure the code I am currently building our board on is good. Thanks -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Steven James Sent: Friday, November 05, 2004 10:40 PM To: Gin Lin Cc: linuxbios(a)clustermatic.org Subject: Re: ram init Greetings, It's been a while since I've looked at it, but when I last looked, it did sometimes need power cycled to restart. I worked around that by making the kernel reboot by writing 0x0e to port 0xcf9. That causes the southbridge to do a 3 second power off. G'day, sjames On Fri, 5 Nov 2004, Gin Lin wrote: > 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 > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > ||||| |||| ||||||||||||| ||| by Linux Labs International, Inc. Steven James, CTO 55 Marietta Street Suite 1830 Atlanta, Ga 30303 866 824 9737 support _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ 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