coreboot November 2006

coreboot@coreboot.org

61 participants
260 discussions

Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163.
by Li Haiqiang 06 Nov '06

06 Nov '06

What does debug code 0xf9 mean? It stopped here. ----- Original Message ---- From: Richard Smith <smithbone(a)gmail.com> To: Li Haiqiang <haiqiang2linux(a)yahoo.com> Cc: LinuxBIOS mailinglist <linuxbios(a)linuxbios.org> Sent: Monday, November 6, 2006 10:12:57 AM Subject: Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. >> From: Li Haiqiang <haiqiang2linux(a)yahoo.com> >> Date: 6 november 2006 2:39:39 GMT+01:00 >> To: Segher Boessenkool <segher(a)kernel.crashing.org> >> Subject: Re: [LinuxBIOS] Hello, I have a problem to put the >> linuxbios on my mainboard ms6163. >> >> Yes, I have only one memory module. Li, See my mail earlier today on 44bx. That outlines what you have to do to make 440bx work. -- Richard A. Smith

2 1

Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163.
by Li Haiqiang 06 Nov '06

06 Nov '06

I even don't know how to . Can you help me? ----- Original Message ---- From: Richard Smith <smithbone(a)gmail.com> To: Li Haiqiang <haiqiang2linux(a)yahoo.com> Cc: LinuxBIOS mailinglist <linuxbios(a)linuxbios.org> Sent: Monday, November 6, 2006 10:12:57 AM Subject: Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. >> From: Li Haiqiang <haiqiang2linux(a)yahoo.com> >> Date: 6 november 2006 2:39:39 GMT+01:00 >> To: Segher Boessenkool <segher(a)kernel.crashing.org> >> Subject: Re: [LinuxBIOS] Hello, I have a problem to put the >> linuxbios on my mainboard ms6163. >> >> Yes, I have only one memory module. Li, See my mail earlier today on 44bx. That outlines what you have to do to make 440bx work. -- Richard A. Smith

1 0

[LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163.
by Segher Boessenkool 06 Nov '06

06 Nov '06

[Forwarding to the list, I guess Li pressed a wrong button.] Li, please use "reply to all". Begin forwarded message: > From: Li Haiqiang <haiqiang2linux(a)yahoo.com> > Date: 6 november 2006 2:39:39 GMT+01:00 > To: Segher Boessenkool <segher(a)kernel.crashing.org> > Subject: Re: [LinuxBIOS] Hello, I have a problem to put the > linuxbios on my mainboard ms6163. > > Yes, I have only one memory module. > > The lspci -xxx output: > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX > Host bridge (rev 03) > 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 40 00 00 > 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 0c 8a 00 ff 00 00 00 09 03 10 11 01 00 00 00 00 > 60: 08 10 10 10 10 10 10 10 00 0f c0 00 00 8a 00 00 > 70: 20 1f 0a 38 05 00 03 01 26 ff 10 38 00 00 00 00 > 80: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 98 22 00 00 04 61 00 00 00 05 00 00 00 00 00 00 > a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 > b0: 80 20 00 00 30 00 00 00 00 00 ef 07 20 10 00 00 > c0: 00 00 00 00 00 00 00 00 18 0c ff ff 67 00 00 00 > d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 > e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00 > f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00 > > > > And the LinuxBIOS serial output: > PCI: 00:00.00 > 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 00 00 00 > 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 0 > 50: 04 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 > 60: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 > 70: 00 1f 02 38 00 00 00 00 00 00 00 38 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 80 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00 > a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 18 0c 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 f8 00 00 20 0f 00 00 00 00 00 00 > > > > > ----- Original Message ---- > From: Segher Boessenkool <segher(a)kernel.crashing.org> > To: Stefan Reinauer <stepan(a)coresystems.de> > Cc: Li Haiqiang <haiqiang2linux(a)yahoo.com>; linuxbios(a)linuxbios.org > Sent: Monday, November 6, 2006 2:45:19 AM > Subject: Re: [LinuxBIOS] Hello, I have a problem to put the > linuxbios on my mainboard ms6163. > > > You need to run > > dump_pci_devices(); > > > > as last command in auto.c > > > >> lspci -xxx: > > If you resend this lspci output with the dump_pci_devices() > output (and please do!), use lspci -xxx -s0:0 or just > cut'n'paste only device 0 ("Host Bridge"), the rest isn't > interesting. > > Did you send the SPD contents dump already? I didn't see > it yet -- if you didn't send it to the list, please do. > > Oh and answer Stefan's question: > > >> Ok. Its reading 1 SPD-ROM. Do you have 1 memory module > >> installed? If yes: Everything is fine here. If you have more, > >> we need to find out where they are. > > > > Segher > > >

2 1

Re: [LinuxBIOS] #9: Do not hardcode iasl path
by LinuxBIOS 05 Nov '06

05 Nov '06

#9: Do not hardcode iasl path -----------------------------------+---------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: | Include_gantt: 1 Dependencies: | Due_assign: Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * patchstatus: => patch needs review -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/9#comment:4> LinuxBIOS <http://www.linuxbios.org/>

1 0

Re: [LinuxBIOS] #22: sed error in abuild
by LinuxBIOS 05 Nov '06

05 Nov '06

#22: sed error in abuild -----------------------------------------------+---------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: critical | Milestone: Component: testsystem | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch is ready to be committed | -----------------------------------------------+---------------------------- Changes (by uwe): * patchstatus: => patch is ready to be committed -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/22#comment:3> LinuxBIOS <http://www.linuxbios.org/>

1 0

[LinuxBIOS] 440bx stuff
by Richard Smith 05 Nov '06

05 Nov '06

Thinking about this some more, whats needed is a lot of grunt work that doesn't necessarily have to be done by the same person who fixes the ram init code. Here's TODO from my past emails.. > 1. I named both the northbridge and the southbridge i440bx. While I > don't think it s a huge problem. The southbridge code needs to be > changed to piix4 since thats really what the part is. I'll hopefully > be able to do that soon. This has been done. It's now i82371eb. > 2. I seemed to have based the framework on one of the VIA chips. But > looking at things now I see a much better choice would have been the > Intel e7501. Hopefully I can find some time to work on this a bit > this week. This still outstanding. If someone is feeling spunky they could go through the code re-do most of the stuff thats there. The only thing functional in the current code is the boot stuff and the core SPD read functions, everything else is up for grabs. Its possible, (but I won't promise anything) that if someone were to get the framework all setup that I could come in and spend an hour or 2 comparing the ram init code to V1 and fixup the missing details. One thing that can be done that doesn't require you to grok the ram init code but is still necessary is verifying the SPD support code functions are spiting out the right values. The e7501 raminit code is _very_ well commented and pretty easy to follow even if you don't understand whats happening. A lot of the registers also seem very familiar to what I remember from the 440bx data sheet. So the first step here is to start patching in the e7501 code and auditing it against the 440bx datasheet and V1 and then checking to see if the sane values are popping out of the various spd_support functions. Things like number of dram sticks installed, what the min cas timing is across all sticks, etc. None of this is really hard just very time consuming. That would go a _long_ way in helping me make this chipset fly again. -- Richard A. Smith

4 5

Re: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries
by LinuxBIOS 05 Nov '06

05 Nov '06

#20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by segher): > It was used to drop the "name" in the structure completely, thus saving a couple of bytes for every device. Since romcc was easily bloating auto.c up to 64k, the savings can be considered non-existent Ah I see, it's conditionally compiled out. Yeah let's always enable it, it doesn't take much space, and the (potentially) improved diagnostics are worth it /me thinks. Segher -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/20#comment:5> LinuxBIOS <http://www.linuxbios.org/>

1 0

Re: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom
by Segher Boessenkool 05 Nov '06

05 Nov '06

> + /* Set bit 9: 1-Meg Extended BIOS Enable (PCI master accesses to > + FFF00000-FFF7FFFF are forwarded to ISA). > + Set bit 7: Extended BIOS Enable (PCI master accesses to > + FFF80000-FFFDFFFF are forwarded to ISA). > + Set bit 6: Lower BIOS Enable (PCI master, or ISA master > accesses to > + the lower 64-Kbyte BIOS block (E00000 EFFFF) > at the top > + of 1 Mbyte, or the aliases at the top of 4 > Gbyte > + (FFFE0000-FFFEFFF) result in the generation > of BIOSCS#. One more thing, you might want to add a comment to say that accesses to the 64kB @ f00000 and it's alias are always forwarded to the ISA bus. Segher

1 0

Re: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom
by Segher Boessenkool 05 Nov '06

05 Nov '06

> +/* Datasheet: http://www.intel.com/design/intarch/datashts/ > 290562.htm */ Trivial in this case, but in general: can we please add the name or document number (not just the URL) for datasheets and other documentation? Vendors just _love_ to rearrange their websites (and some pull their old docs altogether); if we have the name/number (or even just the filename of the pdf) at least there's a chance to google for it again (either on the vendor's site or on some archive). > + the lower 64-Kbyte BIOS block (E00000- > EFFFF) at the top A 0 too many. > + of 1 Mbyte, or the aliases at the top of 4 > Gbyte > + (FFFE0000-FFFEFFF) result in the generation > of BIOSCS#. But you balanced it by dropping an F :-) > + Set bit 2: BIOSCS# Write Protect Enable (1=enable, > 0=disable). */ The bit is misnamed in the datasheet: it's the "write enable" bit, not the "write protect enable" (which would be "write disable"). > + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY) > \n", xbcs, new, name); Warning only? It's pretty damn fatal :-) Or does this mean "trying to continue anyway" (which might not be such a great plan for a utility that can brick your system)? Would be nice if this message could be made a bit less cryptic, for example, "WARNING: failed setting %s register %#x to %#x\n". Yes I realise this is probably copied all over the place ;-) Segher

2 2

Re: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries
by LinuxBIOS 05 Nov '06

05 Nov '06

#20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): Replying to [comment:3 anonymous]: > > The CHIP_NAME macro was invented at a time when we were really tight in rom space, but it is obviously the wrong approach. > > I don't see how a macro would help any in this regard? It was used to drop the "name" in the structure completely, thus saving a couple of bytes for every device. Since romcc was easily bloating auto.c up to 64k, the savings can be considered non-existent -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/20#comment:4> LinuxBIOS <http://www.linuxbios.org/>

1 0

← Newer
1
...
17
18
19
20
21
22
23
...
26
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 2006