coreboot December 2006

coreboot@coreboot.org

68 participants
183 discussions

[LinuxBIOS] #66: Merge all debug.c instances
by LinuxBIOS 06 Apr '07

06 Apr '07

#66: Merge all debug.c instances ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ There are a ton of very similar and even identical debug.c files in LinuxBIOSv2. We should put one version into src/lib/debug.c or so, and use that from all mainboards... -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/66> LinuxBIOS <http://www.linuxbios.org/>

1 1

[LinuxBIOS] #65: Unify SuperIO code?
by LinuxBIOS 06 Apr '07

06 Apr '07

#65: Unify SuperIO code? ---------------------------------+------------------------------------------ Reporter: stepan | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ One thing I've been noticing in the current superio implementations: A lot of differences come from having the part names used in variable and macro names. {{{ #define FDC37M60X_CONFIG_REG_CC 0x02 }}} Maybe we should change that to some unique names {{{ #define SUPERIO_CONFIG_REG_CC 0x02 }}} * Those names are usually file local only, so name clashes wont be a problem * They are the same for most (all?) SuperIOs? Doing so (maybe with function names as well?) would unify the superio interface, or at least make diffing the code of different devices a bit easier.. -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/65> LinuxBIOS <http://www.linuxbios.org/>

1 2

[LinuxBIOS] #71: Avoid device overlap with pci 0:0x18.0
by LinuxBIOS 06 Apr '07

06 Apr '07

#71: Avoid device overlap with pci 0:0x18.0 ----------------------------------+----------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs review | ----------------------------------+----------------------------------------- Patch by YH from http://www.linuxbios.org/pipermail/linuxbios/2006-December/017694.html The patch is available at http://www.openbios.org/pipermail/linuxbios/attachments/20061212/85cc07ef/a… -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/71> LinuxBIOS <http://www.linuxbios.org/>

1 1

[LinuxBIOS] #56: Support for AMD Virtualization (AMD-V) a.k.a Pacifica
by LinuxBIOS 06 Apr '07

06 Apr '07

#56: Support for AMD Virtualization (AMD-V) a.k.a Pacifica ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ This might be a long term issue, but we might want to support Pacifica at some point... -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/56> LinuxBIOS <http://www.linuxbios.org/>

1 1

[LinuxBIOS] #68: Is LinuxBIOS still funded by LANL?
by LinuxBIOS 06 Apr '07

06 Apr '07

#68: Is LinuxBIOS still funded by LANL? ------------------------------------+--------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: blocker | Milestone: Component: wiki/website/tracker | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ------------------------------------+--------------------------------------- See http://linuxbios.org/FAQ#Who_is_funding_LinuxBIOS.3F. Is that information still correct? If not, please update the FAQ accordingly. -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/68> LinuxBIOS <http://www.linuxbios.org/>

2 2

[LinuxBIOS] Intel 440bx
by Shaddam Corrino IV 02 Mar '07

02 Mar '07

On 11/21/06, ron minnich <rminnich(a)gmail.com> wrote: > > yow. I would say timing problem but it is odd that it is just that one > line. It should repeat more I think. the "*" in output of the 'od' means repeat/duplcate lines. Is this what you mean? You can add "-v" to od to make it present full output. > can you afford to buy some parts? It would help figure this out. My current problem is that I was given one week warranty on those eeproms. Since I'll be away starting on Thursday, I would like to resolve it by Wednesday. I can go to the vendor and say that those eeproms sucks and I want some different ones. No idea if that answers your question. and for reference ,with -v option : # od -v -t x1 < W29C020-12.after.zeroing.bin| grep ff 0744300 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 0744320 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0744340 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0744360 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff # od -v -t x1 < W29C020C-90B.after.zeroing.bin| grep ff 0354420 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354440 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354460 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354500 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354520 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354540 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0354560 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0745660 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff 0745700 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0745720 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0745740 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0745760 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff # -- Thanks! Shaddam IV -- Thanks! Shaddam IV

10 35

[LinuxBIOS] #35: Make it possible to boot Windows using LinuxBIOS
by LinuxBIOS 02 Mar '07

02 Mar '07

#35: Make it possible to boot Windows using LinuxBIOS -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -----------------------------+---------------------------------------------- From http://www.linuxbios.org/pipermail/linuxbios/2006-November/016793.html: {{{ The issue of booting XP just will not go away. So, there are two options I see, in order of preference: 1. find some way, using kexec etc., to boot XP under Linux, then put Linux in FLASH; done 2. revive ADLO there have been a number of suggestions for how to do the first one. 1. freeldr (vapor?) 2. tinyldr (vapor?) any non-vaporous ones out there? This note is an attempt to start a discussion and discovery on this subject. }}} -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/35> LinuxBIOS <http://www.linuxbios.org/>

1 1

[LinuxBIOS] #36: Make the mailing list archive searchable
by LinuxBIOS 02 Mar '07

02 Mar '07

#36: Make the mailing list archive searchable -------------------------------+-------------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -------------------------------+-------------------------------------------- "Challenge to the list: find that port patch Richard mentioned. I have to go to a meeting. If someone can find it, I'll check it out and commit it. -ron" Nuff said. The list archives need to be searchable. -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/36> LinuxBIOS <http://www.linuxbios.org/>

6 14

[LinuxBIOS] #70: fix util/getpir so that the output will compile
by LinuxBIOS 02 Mar '07

02 Mar '07

#70: fix util/getpir so that the output will compile -----------------------------------------------------+---------------------- Reporter: Jon Dufresne <jon.dufresne(a)gmail.com> | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | -----------------------------------------------------+---------------------- The file "irq_table.c" created by getpir needs an additional funciton in order to compile in a project. I patched getpir so this is taken care of automatically. I used a few different boars as an example -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/70> LinuxBIOS <http://www.linuxbios.org/>

11 17

[LinuxBIOS] epia, rom_cc and locking code
by Ben Hewson 16 Jan '07

16 Jan '07

Ok first off the issue with ROM_CC and #if - #else - #endif not compiling properly. After some testing I have at least found the problem and it only ever happens if you put a C++ style comment on the same line as the #if or #else so in the following example static void test_ifdef(void) { #if TEST_IFDEF // blows up outb(50,100); outb(51,100); outb(52,100); #else /* ok */ outb(60,100); outb(61,100); outb(62,100); #endif } Of course no comment works fine as well. Also putting a blank line after the comment produces the correct code. I can't say for the rest of the linuxbios code, but the via/epia code seems to have a good mixture of both types of comments. Perhaps as the code is not strictly C++ you should stick to using standard C style comments. Ok now to my problems with the EPIA board. I think in general it is working ok, but I still have some problems. >From a cold boot and also at other times, it will just hang. I am having problems tracking down just where it hangs. At first sight it appears to happen inside the SMBus read function, but that is a guess from the debug output. The problem I get is if I try and add any debug output inside SMBus read it gets worse and locks more frequently. If I have the memory test enabled it can also lock up when doing the verify. So I guess I can think of 3 reason for it to lock. 1. Some enabled, but not handled interrupt is happening. (I would assume that all interrupts are disabled at powerup but hardware so this is probably not it) 2. Southbridge is not configured properly. (would be very bad chip design if the SMBus part of the southbridge interferred with the rest of the functionality) 3. It is actually running, but serial output has stopped. ( don't think this is the case as it never boots up) I guess I need to look for loops that can become locked, probably withing the serial output code. Can anyone think of some other reason for it to lock up ?

3 6

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 December 2006