Re: [LinuxBIOS] Intel refactoring and microcode updates
On Fri, Jan 11, 2008 at 04:34:39AM +0100, Peter Stuge wrote: On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote: How many different cores could you put in even the most popular socket, three? LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images. I think we need to make it configurable. Yep, agreed. You should be able to specify exactly which CPU you want to use and the build process should only include the updates for just that CPU (or list of CPUs if you specify more than one). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Intel refactoring and microcode updates
On Tue, Jan 08, 2008 at 09:36:20PM -0500, Corey Osgood wrote:
Both patches Signed-off-by: Corey Osgood [EMAIL PROTECTED]
I checked that this doesn't break abuild, so far so good.
On which hardware has this been tested so far? I'm reluctant to commit
this without some broader testing on actual hardware. I'd say at least
some of the 440BX boards, i810, and others.
I can test some of the above soonish I hope, but someone with
server-grade boards should probably also do some tests (E7520 boards and
similar).
Index: src/cpu/intel/microcode/2107-m406fbB4.inc
===
--- src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0)
+++ src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0)
@@ -0,0 +1,266 @@
+/**
+ * Copyright Intel Corporation, 1995, 96, 97, 98, 99, 2000, 01, 02,
+ * 03, 04, 05, 06, 07.
+ *
+ * These microcode updates are distributed for the sole purpose of
+ * installation in the BIOS or Operating System of computer systems
+ * which include a Genuine Intel microprocessor sold or distributed
+ * to or by you. You are not authorized to use this material for
+ * any other purpose.
+**/
Where exactly do these files come from (URL on intel.com?) We should
document this in either the files and/or the wiki.
I know about
http://www.urbanmyth.org/microcode/
http://people.debian.org/~cate/files/microcode/
is that the source?
There's also some stuff at
http://downloadcenter.intel.com/detail_desc.aspx?strstate=liveproductid=528dwnldid=14303agr=nlang=engprdmap=528
for example, which has a different license header, though:
/+++
/ Copyright (c) 1995-2008, Intel Corporation.
/ All rights reserved.
/
/ Redistribution. Redistribution and use in binary form, without
modification, are
/ permitted provided that the following conditions are met:
/ .Redistributions must reproduce the above copyright notice and
the following
/ disclaimer in the documentation and/or other materials provided with the
/ distribution.
/ .Neither the name of Intel Corporation nor the names of its
suppliers may be used
/ to endorse or promote products derived from this software without
specific prior
/ written permission.
/ .No reverse engineering, decompilation, or disassembly of this
software is
/ permitted.
/ .Binary form includes any format commonly used for electronic
conveyance
/ which is a reversible, bit-exact translation of binary representation
to ASCII or
/ ISO text, for example, uuencode.
/
/ DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT
/ HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED
/ WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
/ WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
/ PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
/ OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
/ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
/ LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
/ CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
/ STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
/ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/
/ These microcode updates are distributed for the sole purpose of
/ installation in the BIOS or Operating System of computer systems
/ which include a Genuine Intel microprocessor sold or distributed
/ to or by you. You are not authorized to use this material for
/ any other purpose.
/---
+/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the
info
+ * on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence,
+ * combined for good reasons. */
+struct cpu_device_id cpu_table[] = {
+ { X86_VENDOR_INTEL, 0x0f0a },
+ { X86_VENDOR_INTEL, 0x0f11 },
+ { X86_VENDOR_INTEL, 0x0f12 },
+ { X86_VENDOR_INTEL, 0x0f22 },
+ { X86_VENDOR_INTEL, 0x0f24 },
+ { X86_VENDOR_INTEL, 0x0f25 },
+ { X86_VENDOR_INTEL, 0x0f26 },
+ { X86_VENDOR_INTEL, 0x0f27 },
+ { X86_VENDOR_INTEL, 0x0f29 },
+ { 0, 0 },
+};
+
+struct chip_operations cpu_intel_socket_603_ops = {
+ CHIP_NAME(Socket 603 CPU)
Shouldn't this be
CHIP_NAME(Socket 603/604 CPU)
then?
+/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the
info
+ * on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence,
+ * combined for good reasons. */
+struct cpu_device_id cpu_table[] = {
+ { X86_VENDOR_INTEL, 0x0f22 },
+ { X86_VENDOR_INTEL, 0x0f24 },
+ { X86_VENDOR_INTEL, 0x0f25 },
+ { X86_VENDOR_INTEL, 0x0f26 },
+ { X86_VENDOR_INTEL, 0x0f27 },
+
Re: [LinuxBIOS] LinuxBIOSv3 Config files
On Fri, Jan 11, 2008 at 01:48:36PM +0100, Stefan Reinauer wrote: * Myles Watson [EMAIL PROTECTED] [080111 05:00]: On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: it really should be a feature that kconfig offers. It's make defconfig in Linux. Make defconfig ignores your .config file. What I wanted was something similar to make allyesconfig, which chooses yes for anything you didn't specify. Maybe make alldefconfig? make oldconfig? That's interactive per default, I think. But it's the correct option if you want the defaults for unspecified options, IIRC. If you want yes for all unspecified options: make oldconfig /usr/bin/yes Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Intel refactoring and microcode updates
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: Peter Stuge wrote: I think we need to make it configurable. I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket. (Actually no, not always.) We should be able to do the same. I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0=n=all microcode updates. Definately an advanced option, but still. Yep, that's what I meant. It's fine if the default is all microcode updates, but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 Config files
On Fri, Jan 11, 2008 at 07:59:17AM -0800, ron minnich wrote: On Jan 11, 2008 7:31 AM, Uwe Hermann [EMAIL PROTECTED] wrote: If you want yes for all unspecified options: make oldconfig /usr/bin/yes Now, Uwe, we just came full circle. I said something like that a few messages ago and Jordan yelled at me :-) Yeah, sorry, I should have read the whole thread first ;-) Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] problem about dram init
On Thu, Dec 20, 2007 at 10:42:33AM -0500, Corey Osgood wrote: Weird, I've never seen that problem. Do you have any other dram modules you can try? Can you send me the specs (or a link to the datasheet would be best) on the module you're currently using? I have some comments I need to put in about some important bits, but haven't had the time or ambition lately to do it. Eventually those bits should be set up automatically, but I'm running up against ROMCC's limitations. There are some other tricks like disabling/removing debugging stuff etc., but one thing that helped me on some other board is a different -mcpu option for romcc, e.g. action ./romcc -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@ Without the '-mcpu=p2' I get 'too few registers', adding it fixes that problem. Depending on the CPU/chipset values other than 'p2' might work. Basically, it allows romcc to use more registers, I think, but I'm not a romcc expert, just guessing... HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r3018 - trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah_fam10
On Wed, Dec 19, 2007 at 12:36:51PM -0500, Corey Osgood wrote: -Wall -o rom_stream.o /home/corey/LinuxBIOSv2/src/stream/rom_stream.c /home/corey/LinuxBIOSv2/src/stream/rom_stream.c:47:90: error: invalid suffix x on integer constant make[1]: *** [rom_stream.o] Error 1 make[1]: Leaving directory `/home/corey/LinuxBIOSv2/util/abuild/linuxbios-builds/amd_serengeti_cheetah_fam10/normal' make: *** [normal/linuxbios.rom] Error 1 Looks like this is the old version before your commit? I now get: Compiling image ..FAILED after 14s! Log excerpt: mv dsdt_lb.hex dsdt.c mv: cannot stat `dsdt_lb.hex': No such file or directory make[1]: *** [dsdt.c] Error 1 Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]
On Mon, Dec 17, 2007 at 02:55:35PM -0500, Marc Karasek wrote: That would work, but this brings up a rather interesting point. What are we todo about all the other Distros? At some point (if not already) they will also face a similar issue. Yep, true. The correct thing IMO is to check for the actual feature/bug, not for version number strings of compilers or programs or distros. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Tyan s1894
On Mon, Dec 17, 2007 at 03:55:06AM +0100, Peter Stuge wrote: On Sat, Dec 15, 2007 at 03:21:28PM -0600, Jason Green wrote: I am new to LinuxBIOS mailing list. I have a few old boards I want to try out. I dunno if it's compatible with this or not. http://www.tyan.com/archive/products/html/tigercub100.html Maybe it's similar enough to the s1846 that the 1846 port works as is? Or maybe it could at least be a good start for a s1894 port? Yep, definately. Shouldn't be too much hassle to port this board. Jason, please post the output of 'lspci -tvnn' and 'superiotool -dV' here (run as root). Also, post the irq_tables.c file which is generated when you run 'getpir' on the board. With that information as a starting point we'll be able to make a first patch for your board. Do you have a possibility to flash your BIOS chip (either an external programmer or you can use the flashrom tool (please post 'flashrom -V' here so we know if your board might be supported). Also, is the BIOS chip in a socket or soldered onto the board? Do you have a null-modem cable to grab serial debugging output from LinuxBIOS later? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] IDE legacy port access + UDMA/33 for 440BX boards
Updated patch. It enableѕ legacy I/O port access, but disables UDMA/33 per default as we don't know if the user's devices support it. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org Enable IDE legacy port access for all 440BX based boards per default, as this is needed (at the very least) to make FILO work on these boards. Disable UDMA/33 per default, which is slower but the safe choice, as we don't know which IDE devices a user has attached, and some don't support UDMA/33 very well or at all. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Index: src/mainboard/a-trend/atc-6220/Config.lb === --- src/mainboard/a-trend/atc-6220/Config.lb (Revision 3009) +++ src/mainboard/a-trend/atc-6220/Config.lb (Arbeitskopie) @@ -130,6 +130,12 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/gigabyte/ga-6bxc/Config.lb === --- src/mainboard/gigabyte/ga-6bxc/Config.lb (Revision 3009) +++ src/mainboard/gigabyte/ga-6bxc/Config.lb (Arbeitskopie) @@ -128,6 +128,12 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/biostar/m6tba/Config.lb === --- src/mainboard/biostar/m6tba/Config.lb (Revision 3009) +++ src/mainboard/biostar/m6tba/Config.lb (Arbeitskopie) @@ -124,6 +124,12 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/azza/pt-6ibd/Config.lb === --- src/mainboard/azza/pt-6ibd/Config.lb (Revision 3009) +++ src/mainboard/azza/pt-6ibd/Config.lb (Arbeitskopie) @@ -130,6 +130,12 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/tyan/s1846/Config.lb === --- src/mainboard/tyan/s1846/Config.lb (Revision 3009) +++ src/mainboard/tyan/s1846/Config.lb (Arbeitskopie) @@ -126,6 +126,12 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/compaq/deskpro_en_sff_p600/Config.lb === --- src/mainboard/compaq/deskpro_en_sff_p600/Config.lb (Revision 3009) +++ src/mainboard/compaq/deskpro_en_sff_p600/Config.lb (Arbeitskopie) @@ -134,6 +134,12 @@ device pci 14.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + # Enable UDMA/33 for higher speed if your IDE device(s) support it. + register ide0_drive0_udma33_enable = 0 + register ide0_drive1_udma33_enable = 0 + register ide1_drive0_udma33_enable = 0 + register ide1_drive1_udma33_enable = 0 end end end Index: src/mainboard/asus/p2b/Config.lb === --- src/mainboard/asus/p2b/Config.lb (Revision 3009) +++ src/mainboard/asus/p2b/Config.lb (Arbeitskopie) @@ -130,6 +130,12 @@ device pci 4.3 on end # ACPI register ide0_enable = 1
Re: [LinuxBIOS] [PATCH] IDE legacy port access + UDMA/33 for 440BX boards
On Mon, Dec 17, 2007 at 10:11:16PM +0100, Carl-Daniel Hailfinger wrote: On 17.12.2007 22:05, Uwe Hermann wrote: Enable IDE legacy port access for all 440BX based boards per default, as this is needed (at the very least) to make FILO work on these boards. Disable UDMA/33 per default, which is slower but the safe choice, as we don't know which IDE devices a user has attached, and some don't support UDMA/33 very well or at all. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Acked-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Thanks, r3010. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Add dump support for NSC PC87317
On Sat, Dec 15, 2007 at 10:04:21PM +0100, Ulf Jordan wrote: Add dump support for NSC PC87317. Signed-off-by: Ulf Jordan [EMAIL PROTECTED] Thanks, r3011. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] PCI: Left over static devices. Check your Config.lb
On Mon, Dec 17, 2007 at 03:10:52PM -0700, Marc Jones wrote: Carl-Daniel Hailfinger wrote: On 10.12.2007 21:56, Marc Jones wrote: A devices needs to be listed in the config.lb if it requires more setup than standard PCI initialization (resource allocation). Usually that means the CPU, northbridge, southbridge, and SIO. Those devices are usually needed to indicate the system bus structure(pci_domain) as well as do any system specific initialization on those devices. During the LinuxBIOS PCI/system scan process, if a device in config.lb is found, the functions to do customized initialization are called via the device_operations and the chip_operations structs. Can you add that explanation to the wiki? Regards, Carl-Daniel What page would this go on? I don't see an appropriate place. I'd say http://linuxbios.org/Developer_Manual#Config.lb (maybe with some rewording to make it more generic and HOWTO-like) HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Add detection and dump support for NSC PC97307
On Thu, Dec 06, 2007 at 09:11:50PM +0100, Ulf Jordan wrote: Add detection and dump support for NSC PC97307. Signed-off-by: Ulf Jordan [EMAIL PROTECTED] Thanks, r3005. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Add dump support for NSC PC8741x
On Wed, Nov 28, 2007 at 11:18:52PM +0100, Ulf Jordan wrote: Add dump support for NSC PC8741x. Signed-off-by: Ulf Jordan [EMAIL PROTECTED] Thanks, r3004. Sorry for the delay. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Add dump support for NSC PC97317
On Sun, Dec 09, 2007 at 04:42:05PM +0100, Ulf Jordan wrote: Add dump support for NSC PC97317. Signed-off-by: Ulf Jordan [EMAIL PROTECTED] Thanks, r3006. Good work btw, I double-checked all your patches against the datasheets before committing and didn't notice a single typo so far -:) Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] buildrom qemu patch
On Thu, Dec 13, 2007 at 04:54:44PM -0700, Myles Watson wrote: Index: buildrom-devel/config/platforms/Config.in === --- buildrom-devel/config/platforms/Config.in (revision 84) +++ buildrom-devel/config/platforms/Config.in (working copy) @@ -112,15 +112,16 @@ default n help Say 'y' here to build a patched version of QEMU to work with - LinuxBIOS. This downloads the correct version and patches it - it even builds it if you specify the QEMU_CC correctly. + LinuxBIOS. This downloads the correct version and patches it; + it even builds it if you specify the QEMU_CC correctly Why this? You remove the full stop from the sentence, which is incorrect. Kconfig help texts should be full sentences which end with a full stop. config QEMU_CC string Compiler to use when building QEMU depends BUILD_QEMU - default gcc32 + default gcc34 help - Set this string to point to your compiler (GCC_VER =3.2) + qemu has known problems when built using gcc 4.x + Set this string to point to your compiler (GCC_VER 3.x) Ditto, should end with full stop. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] PCI: Left over static devices. Check your Config.lb
On Mon, Dec 10, 2007 at 10:08:30AM -0800, Steve Isaacs wrote: For the PCI parts, LinuxBIOS sets up the static/onboard devices and scans for other devices dynamically, if I'm not mistaken. This means you do not specify PCI/AGP/PCIe extention cards in Config.lb, they're rather detected at runtime. By dynamic is it meant devices for which it is possible to set the device ID (DID) in the PCI configuration space? Which means that devices for which the DID cannot be configured are considered static? No, I don't think this has anything to do with the DID. But I'm not really an expert here, better listen to Ron (see other mail). For Super I/O stuff, the (PnP) settings are hardcoded from the options in the 'chip superio/foo/bar' section of Config.lb If I understand this then it is correct to have the Super I/O as a subsection under the southbridge? Yes. Do the sections in Config.lb point to code that is executed Sort of, yes. E.g. the keywords io and irq etc. in the Super I/O section are translated to function calls in src/device/pnp_device.c and others. PCI entries are translated into function calls in src/device/*pci*.c. device pci_domain 0 on chip northbridge/amd/amdk8 device pci 18.0 on # northbridge # devices on link 0 chip southbridge/broadcom/bcm21000 The document shows names being appended to these (e.g. northbridge/amd/amdk8 mc0). What effect does that have? None. It's just a comment for humans to better understand the file. device pci 6.2 on What device is 6.2? The Super I/O section below should be a child of the ISA/LPC device usually. 6.2 is the LPC device on the southbridge. OK, good, that's correct then. Do you have the sch4304 datasheet? If so, it would be nice if you could add support for this chip to superiotool, see http://linuxbios.org/Superiotool Yes I do. I might have an opportunity to do as you ask when the development schedule will allow more time. Great, thanks. Where does this come from? I don't see 6.3, 6.4 etc. in the lspci output. This is part of my confusion. I installed a Phoenix BIOS to boot Linux and be able to run lspci. I have no visibility into what it's (Phoenix BIOS) design is for this board. I suspect there are several devices it hides (a feature of the chipset) because the assumption is they won't be needed for the reference board. Hm, not sure. I usually use lspci from the vendor BIOS (Phoenix in your case) for comparison purposes. Yes, some devices may not appear (some depend on the BIOS config menu settings; e.g. the menu may allow to enable/disable an AC97 modem or not, etc), but the majority of devices (and their IDs) should be correct. Can you also post the 'lspci' output? Your version of lspci doesn't attach the device names to the -tvnn output. One thing that keeps tripping me is it appears that some device numbers are 0 based and others are 1 based. For example 18.0 agrees with a PCI bus scan as well as 19.0 but 6.0 in the Config shows up as 7.0 in the scan and 0.0 as 1.0. What's up with that? Hm, good question. Someone else will have to answer it. Here's the output you requested. I've included the output from print_pci_devices() (debug.c). Please also post the lspci from the vendor BIOS for comparison. Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] many trivial patches
On Fri, Dec 07, 2007 at 03:21:34PM -0500, Ward Vandewege wrote: Acked-by: Ward Vandewege [EMAIL PROTECTED] Thanks, r3002. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 lgdt and gdtptr patch
On Thu, Dec 06, 2007 at 03:08:58PM -0700, Myles Watson wrote: On Thu, Dec 06, 2007 at 10:14:41AM -0700, Myles Watson wrote: It was submitted (but not in patch form) by Brendan Trotter http://www.mail-archive.com/linuxbios@linuxbios.org/msg08771.html Here it is in patch form. - data32 lgdt %cs:gdtptr + movl$gdtptr, %ebx + lgdt%cs:(%bx) It removes the first line, which causes some compilers to give a truncated gdtptr error, and replaces it with an intermediate load step. I think it should be tested by someone with the working compiler, to compare the output. Please repost with a Signed-off-by. I was hoping Brendan Trotter would supply that, since it was his work. It could be considered trivial, though, if the compiler output is the same. Yes, I guess this is trivial enough so you can post it with your Signed-off-by, but if Brendan (CC'd) can re-send with a Signed-off-by that's fine too, of course. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Will linuxBIOS Work on My Machine?
On Wed, Dec 05, 2007 at 12:31:54PM -0800, Wakefield, John wrote: I have an Acer 5102WLMi Notebook with Dual Core AMD TL50s, which are 64 I'm afraid LinuxBIOS doesn't yet work on laptops, those are much harder to support than normal PCs for various reasons. It's on our TODO list to support laptops too sooner or later, but it's not a trivial task. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] SLIT Support
On Fri, Dec 07, 2007 at 02:28:42PM -0600, David Edrich wrote: Also though I would like to know if anyone knows if SLIT has been implemented by the major BIOS vendors? I would think that maybe it hasn't since it would require customization probably every time. Well, yes, but that's required anyway. Each board has to get a custom ACPI implementation (in LinuxBIOS, but I'm pretty sure that's also the case for the commercial BIOSes). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] PCI: Left over static devices. Check your Config.lb
On Wed, Dec 05, 2007 at 12:00:59PM -0800, Steve Isaacs wrote: On Wed, 2007-12-05 at 12:30 +0100, Uwe Hermann wrote: Please post your Config.lb and 'lspci -tvnn' output. You're likely listing PCI devices in Config.lb which are not on the board, or you use the wrong nesting or order (?) Thanks, see below. I have been in a very uncomfortable position of having to guess about this. I dug around in other boards trying to find something that almost fits and then hacked from there. Is there anything that describes how to make a configuration in detail? I'd rather learn the rules than have someone figure it out for me. There's a PDF which describes some parts of it, not sure how complete it is: $ cd documentation $ make $ xpdf LinuxBIOS-AMD64.pdf Other questions are, in what form and how is this information used at run-time? For the PCI parts, LinuxBIOS sets up the static/onboard devices and scans for other devices dynamically, if I'm not mistaken. This means you do not specify PCI/AGP/PCIe extention cards in Config.lb, they're rather detected at runtime. For Super I/O stuff, the (PnP) settings are hardcoded from the options in the 'chip superio/foo/bar' section of Config.lb The CPU/socket/APIC stuff below tells LinuxBIOS which CPU init code to execute etc. Config.lb chip northbridge/amd/amdk8/root_complex device apic_cluster 0 on chip cpu/amd/socket_F device apic 0 on end end end Looks ok. device pci_domain 0 on chip northbridge/amd/amdk8 device pci 18.0 on # northbridge # devices on link 0 chip southbridge/broadcom/bcm21000 device pci 0.0 on end device pci 1.0 off end device pci 2.0 on end device pci 3.0 off end device pci 4.0 off end end chip southbridge/broadcom/bcm11000 device pci 0.0 on end device pci 0.1 on end Hm, not sure about the above stuff... device pci 1.0 on device pci e.0 on end end I may be wrong, but I don't think you can nest PCI entries like this. device pci 1.1 on end device pci 2.0 on device pci b.0 on end device pci b.1 on end device pci b.2 on end device pci c.0 on end device pci c.1 on end device pci c.2 on end device pci d.0 on end device pci d.1 on end device pci d.2 on end What is 2.0? What are the b.0 etc. entries? This doesn't seem to match the lspci you posted. end device pci 2.1 on end device pci 3.0 on end device pci 3.1 on end device pci 4.0 on end device pci 4.1 on end device pci 6.0 on chip drivers/i2c/i2cmux2 # pca9544 smbus mux device i2c 71 on # MIS_ P40,28,39 end #0 pca9544 0 device i2c 71 on # HT_ P40,24,42 end #0 pca9544 1 device i2c 71 on # pca9544 2 P1_ P40,2,6,7 chip drivers/generic/generic #dimm 0-0-0 device i2c 50 on end end chip drivers/generic/generic #dimm 0-0-1 device i2c 51 on end end chip drivers/generic/generic #dimm 0-1-0 device i2c 52 on end end chip drivers/generic/generic #dimm 0-1-1 device i2c 53 on end end end device i2c 71 on #pca9544 3 P2_ P40,8,12,13 chip drivers/generic/generic #dimm 1-0-0 device i2c 50 on end end chip drivers/generic/generic #dimm 1-0-1 device i2c 51 on end end chip drivers/generic/generic #dimm 1-1-0 device i2c 52 on end end chip drivers/generic/generic #dimm 1-1-1 device i2c 53 on end end end end end device pci 6.1 on end device pci 6.2 on What device is 6.2? The Super I/O section below should be a child of the ISA/LPC device usually. chip superio/smsc/sch4304 Please use the 'superio/smsc/smscsuperio' driver, which is a common driver for many SMSC Super I/Os. It should be easy to add support for the sch4304 there. Do
[LinuxBIOS] [PATCH] Abit BE6-II V2.0 support
On Fri, Dec 07, 2007 at 01:39:43PM +0300, Sergei Antonov wrote: I'd like to try LinuxBIOS on a 440BX-based Abit BE6-II V2.0. After talking on IRC, I'm sending the output of 'lspci -tvnn' and 'superiotool -dV' and a generated irq_tabl.c. Thanks, here's a patch for your board you can test. I guess most of the hardware should work with this code, but some smaller issues might need to be fixed after it has been tested on real hardware. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org Add support for the Abit BE6-II V2.0 board. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Index: src/mainboard/abit/be6-ii_v2_0/Config.lb === --- src/mainboard/abit/be6-ii_v2_0/Config.lb (Revision 0) +++ src/mainboard/abit/be6-ii_v2_0/Config.lb (Revision 0) @@ -0,0 +1,141 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 Uwe Hermann [EMAIL PROTECTED] +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE) +else + default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) + default ROM_SECTION_OFFSET = 0 +end +default CONFIG_ROM_PAYLOAD_START = (0x - ROM_SIZE ++ ROM_SECTION_OFFSET + 1) +default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) +default _ROMBASE = (CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE) +default XIP_ROM_SIZE = 64 * 1024 +default XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE) +arch i386 end +driver mainboard.o +if HAVE_PIRQ_TABLE + object irq_tables.o +end +makerule ./failover.E + depends $(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc + action ./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@ +end +makerule ./failover.inc + depends $(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc + action ./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@ +end +makerule ./auto.E + # depends $(MAINBOARD)/auto.c option_table.h ./romcc + depends $(MAINBOARD)/auto.c ./romcc + action ./romcc -E -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@ +end +makerule ./auto.inc + # depends $(MAINBOARD)/auto.c option_table.h ./romcc + depends $(MAINBOARD)/auto.c ./romcc + action ./romcc -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@ +end +mainboardinit cpu/x86/16bit/entry16.inc +mainboardinit cpu/x86/32bit/entry32.inc +ldscript /cpu/x86/16bit/entry16.lds +ldscript /cpu/x86/32bit/entry32.lds +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/reset16.inc + ldscript /cpu/x86/16bit/reset16.lds +else + mainboardinit cpu/x86/32bit/reset32.inc + ldscript /cpu/x86/32bit/reset32.lds +end +mainboardinit arch/i386/lib/cpu_reset.inc +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds +if USE_FALLBACK_IMAGE + ldscript /arch/i386/lib/failover.lds + mainboardinit ./failover.inc +end +mainboardinit cpu/x86/fpu/enable_fpu.inc +mainboardinit cpu/x86/mmx/enable_mmx.inc +mainboardinit ./auto.inc +mainboardinit cpu/x86/mmx/disable_mmx.inc + +dir /pc80 +config chip.h + +chip northbridge/intel/i440bx # Northbridge + device apic_cluster 0 on # APIC cluster +chip cpu/intel/slot_2 # CPU (FIXME: It's slot 1, actually) + device apic 0 on end # APIC +end + end + device pci_domain 0 on # PCI domain +device pci 0.0 on end # Host bridge +device pci 1.0 on end # PCI/AGP bridge +chip southbridge/intel/i82371eb # Southbridge + device pci 7.0 on # ISA bridge +chip superio/winbond/w83977tf # Super I/O (FIXME: It's W83977EF!) + device pnp 3f0.0 on # Floppy +io 0x60 = 0x3f0 +irq 0x70 = 6 +drq 0x74 = 2 + end + device pnp 3f0.1 on # Parallel port +io 0x60 = 0x378 +irq 0x70 = 7 + end + device pnp 3f0.2 on # COM1 +io 0x60 = 0x3f8 +irq 0x70 = 4 + end + device pnp 3f0.3 on # COM2 / IR +io 0x60 = 0x2f8 +irq 0x70 = 3 + end + device pnp 3f0.5 on # PS/2 keyboard
Re: [LinuxBIOS] SLIT Support
On Tue, Dec 04, 2007 at 03:40:03PM -0600, David Edrich wrote: I've seen SLIT support within Linux does anyone know anything about what platforms/systems have implemented SLIT Table support? Is this does by any standard BIOS vendor? Dunno, sorry. Someone else has to answer this question. In Linux BIOS? ACPI support in LinuxBIOS has to be implemented for each board extra. Currently not all boards in LinuxBIOS support ACPI (most don't), but from a quick look at the code it _seems_ that these two _do_ have SLIT support: src/mainboard/iwill/dk8_htx/acpi_tables.c src/mainboard/amd/serengeti_cheetah/acpi_tables.c HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Patch file for Fedora 8 compile problems
On Fri, Dec 07, 2007 at 12:43:57PM -0500, Marc Karasek wrote:
Here it is in -u format...
Thanks, but I think your Thunderbird broke the patch, probably because
you copy-pasted it into the mailer and it clipped long lines.
I recommend to use 'svn diff foo.patch' in your svn tree (easier IMO,
and that already produces patches in the -u format) and then just attach
that file to the mail.
=
diff -r -u -x .svn LinuxBIOSv2.orig/src/arch/i386/Config.lb
LinuxBIOSv2/src/arch/i386/Config.lb
--- LinuxBIOSv2.orig/src/arch/i386/Config.lb 2007-12-06
10:06:31.0 -0500
+++ LinuxBIOSv2/src/arch/i386/Config.lb 2007-12-04 16:25:13.0 -0500
@@ -100,7 +100,7 @@
makerule linuxbios
depends crt0.o init.o $(LINUXBIOS_APC) $(LINUXBIOS_RAM_ROM) ldscript.ld
- action $(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld
crt0.o init.o
+ action $(CC) -Wl,--build-id=none -nostdlib -nostartfiles -static -o
We should make sure this doesn't break any other distros / compiler
versions. Do all reasonably new gcc/ld versions know about '--build-id'?
$@ -T ldscript.ld crt0.o init.o
action $(CROSS_COMPILE)nm -n linuxbios | sort linuxbios.map
end
diff -r -u -x .svn LinuxBIOSv2.orig/src/arch/i386/lib/id.lds
LinuxBIOSv2/src/arch/i386/lib/id.lds
--- LinuxBIOSv2.orig/src/arch/i386/lib/id.lds 2007-12-06
10:06:31.0 -0500
+++ LinuxBIOSv2/src/arch/i386/lib/id.lds 2007-12-06 10:36:31.0 -0500
@@ -1,5 +1,11 @@
SECTIONS {
- . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
+
+/*
+ * . = (_ROMBASE + (ROM_IMAGE_SIZE - 0x10)) - (__id_end - __id_start);
+ * This is a temporary fix. Under Fedora 8 ld does not like it if the
.id section is above address 0x_EF00
+*/
+ _ROMTEMP = 0xef00;
+ . = _ROMTEMP;
I cannot parse this changeset completely, but won't this
break the code for other distros or boards?
Please resend the 'svn diff' output so we can test this on some
non-Fedora distros.
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] alix1c patch for irq.
On Mon, Nov 26, 2007 at 01:08:21PM +0100, Stefan Reinauer wrote: This should be the last change needed for the alix1c. The minipci slot works, and with this change, the pci slot seems to work too. At least for me. Signed-off-by: Ronald G. Minnich [EMAIL PROTECTED] Acked-by: Stefan Reinauer [EMAIL PROTECTED] This is r2987. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Add detection and dump support for NSC PC87309
On Fri, Nov 30, 2007 at 10:15:07PM +0100, Ulf Jordan wrote: Add detection and dump support for NSC PC87309. Signed-off-by: Ulf Jordan [EMAIL PROTECTED] Thanks, r3001. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Re: superiotool: conflicting SID for PC97317?
On Fri, Dec 07, 2007 at 07:59:21PM +0100, Ulf Jordan wrote:
There was never a PC97371 made by National.
-Bari
Attched is a patch that fixes the typos in superiotool/nsc.c.
/ulf
Fix typo. According to National's datasheet PC87317 has SID = 0xd0 and
PC97317 has SID = 0xdf. PC87371/PC97371 do not seem to exist.
Signed-off-by: Ulf Jordan [EMAIL PROTECTED]
Index: nsc.c
===
--- nsc.c (revision 2998)
+++ nsc.c (working copy)
@@ -25,9 +25,9 @@
#define CHIP_REV_REG 0x27/* Super I/O revision ID (SRID) */
static const struct superio_registers reg_table[] = {
- {0xd0, PC87371, { /* From sensors-detect */
+ {0xd0, PC87317, {
{EOT}}},
- {0xdf, PC97371, { /* From sensors-detect */
+ {0xdf, PC97317, {
{EOT}}},
{0xe1, PC87360, {
{NOLDN, NULL,
Thanks, r2999.
I agree with both of you that this seems to be a typo.
Please also send a patch to the lm-sensors list to fix sensors-detect.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Expand linuxbiosv3 support
On Fri, Dec 07, 2007 at 12:31:37PM -0700, Jordan Crouse wrote: On 07/12/07 00:06 -0500, Corey Osgood wrote: Typo! That makes 2 mistakes this week! Are you feeling okay? :P This does look pretty good though, and the idea of having v3 in buildrom is great! I'm kicking myself now for never having used buildrom until yesterday, such a great tool. Did you ever track down the source of that __stack_chk_fail we discussed on IRC? Autoconf is very annoying, but as the inventor of OpenEmbedded once famously said, autoconf sucks, but at least we know how it sucks. However, no amount of autoconf knowledge will save us from projects that further abuse the already fragile scripts. In this case, we have mkelfimage committing several crimes - 1) they overwrite incoming environment variables in autoconf, thereby thwarting any possibility of us tweaking things from the ouside, and Yep, this should be fixed in mkelfimage, please notify the developers. 2) they ship a version of the final configure script, which forces us to patch both the configure.ac _and_ the configure script itself, Alternatively you could just patch configure.ac and run autoconf/automake etc. to regenerate the generated files, but I'm afraid that's pretty fragile too (different autoconf versions etc). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] buildrom: add supermicro h8dmr
On Fri, Nov 30, 2007 at 02:01:59PM -0700, Jordan Crouse wrote: Add Supermicro H8DMR support to buildrom. Signed-off-by: Ward Vandewege [EMAIL PROTECTED] Acked-by: Jordan Crouse [EMAIL PROTECTED] This is r71. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Patch file for Fedora 8 compile problems
On Fri, Dec 07, 2007 at 12:39:36PM -0800, Ed Swierk wrote:
Here is another attempt that does not rely on the --build-id option,
incorporating Marc's workaround in src/arch/i386/lib/id.lds for the
.id allocation issue.
The patch is missing the original Signed-off-by from Marc, and your
Signed-off-by.
Index: LinuxBIOSv2-2571/src/config/linuxbios_ram.ld
===
--- LinuxBIOSv2-2571.orig/src/config/linuxbios_ram.ld
+++ LinuxBIOSv2-2571/src/config/linuxbios_ram.ld
@@ -62,6 +62,10 @@ SECTIONS
. = ALIGN(4);
_erodata = .;
+ }
+ /* ld segfaults if we give it --build-id and then discard this section
*/
+ .note.gnu.build-id : {
+ *(.note.gnu.build-id)
}
/*
* After the code we place initialized data (typically initialized
Index: LinuxBIOSv2-2571/src/arch/i386/lib/id.lds
===
--- LinuxBIOSv2-2571.orig/src/arch/i386/lib/id.lds
+++ LinuxBIOSv2-2571/src/arch/i386/lib/id.lds
@@ -1,5 +1,10 @@
SECTIONS {
- . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
+ /*
+ * . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
+ * This is a temporary fix. Under Fedora 8 ld does not like it if the
.id section is above address 0x_EF00
+ */
+ _ROMTEMP = 0xef00;
+ . = _ROMTEMP;
This part breaks the majority of all boards in v2 (checked with abuild).
E.g. on asus/p2b:
./buildrom linuxbios.strip linuxbios.rom payload 0x1 0x2
linuxbios image is 192277 bytes; only 65536 allowed
Linuxbios input file larger than allowed size!
: Success
make[1]: *** [linuxbios.rom] Error 2
make[1]: Leaving directory `/tmp/v2/targets/asus/p2b/p2b/normal'
make: *** [normal/linuxbios.rom] Error 1
There must be some other way to fix this.
.id (.): {
*(.id)
}
Index: LinuxBIOSv2-2571/src/arch/i386/init/ldscript.lb
===
--- LinuxBIOSv2-2571.orig/src/arch/i386/init/ldscript.lb
+++ LinuxBIOSv2-2571/src/arch/i386/init/ldscript.lb
@@ -53,6 +53,10 @@ SECTIONS
_erom = .;
}
+ .note.gnu.build-id : {
+ *(.note.gnu.build-id)
+ }
+
_lrom = LOADADDR(.rom);
_elrom = LOADADDR(.rom) + SIZEOF(.rom);
_iseg = _RAMBASE;
@@ -63,5 +67,6 @@ SECTIONS
/DISCARD/ : {
*(.comment)
*(.note)
+ *(.note.*)
}
}
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] CONFIG_ROM_STREAM verus CONFIG_IDE_STREAM verus CONFIG_FS_STREAM?
On Tue, Dec 04, 2007 at 10:59:21AM -0800, Steve Isaacs wrote: I'm puzzled about the difference between these options. If I want to boot using an IDE device does the following make sense? ## Boot linux from IDE default CONFIG_IDE=1 default CONFIG_FS_STREAM=1 default CONFIG_FS_EXT2=1 default CONFIG_FS_ISO9660=1 default CONFIG_FS_FAT=1 default AUTOBOOT_CMDLINE=hda1:/vmlinuz I found these in mainboard/momentum/apache and am wondering if I can use them as is for my board. Where is this from? There's no such board in LinuxBIOS, AFAICS. Am I correct in interpreting this as: Use the IDE interface to boot which can contain an EXT2 or ISO9660 (CDROM) or FAT file system? (This is what I want -- simply boot Linux using the ATA drive connected to the IDE interface). I'm currently able to boot this way using a proprietary BIOS and want to do the same using LinuxBIOS. You want to use the latest FILO version from svn, see http://linuxbios.org/Filo Which board and chipset is this btw? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOSv3 lgdt and gdtptr patch
On Thu, Dec 06, 2007 at 10:14:41AM -0700, Myles Watson wrote: It was submitted (but not in patch form) by Brendan Trotter http://www.mail-archive.com/linuxbios@linuxbios.org/msg08771.html Here it is in patch form. - data32 lgdt %cs:gdtptr + movl$gdtptr, %ebx + lgdt%cs:(%bx) It removes the first line, which causes some compilers to give a truncated gdtptr error, and replaces it with an intermediate load step. I think it should be tested by someone with the working compiler, to compare the output. Please repost with a Signed-off-by. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r539 - LinuxBIOSv3/arch/x86
On Wed, Dec 05, 2007 at 02:45:55AM +0100, [EMAIL PROTECTED] wrote: linuxbios.stage2.o (and stage2.o in the LAR) are NOT .o files, they are ELF executables. Remove the .o suffix to reduce confusion. For clarity's sake we might even want to add an .elf extention? Opinions? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Drop coherent_ht_car.c file
On Wed, Dec 05, 2007 at 11:40:50AM -0700, Marc Jones wrote: Acked-by: Marc Jones [EMAIL PROTECTED] Thanks, r2998. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] State of the buildrom
On Wed, Dec 05, 2007 at 01:28:33PM -0700, Myles Watson wrote: This patch adds support for QEMU to buildrom, for both v2 and v3. It also allows you to build QEMU from sources with the patches. I've built it for v2 and v3 and it boots in v2, I'm not sure why it builds but doesn't boot in v3. Anyone care to send me their config file that works? The default config should work fine with current v3 trunk. Just run 'make menuconfig' and save (no changes). In both v2 and v3 I turned of lzma compression because the decompressor was running out of space, and emulated ROM space was cheap today. I set it to use revision 539 of v3 because that was the last revision before it was broken on purpose to mirror hardware better. You can use trunk, qemu build/run has been fixed in v3. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] Drop coherent_ht_car.c file
See patch.
That file is a duplicate (it was slightly different at some point, but
identical in its current form) of coherent_ht.c, so drop it.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Remove the coherent_ht_car.c file. It is exactly the same as
coherent_ht.c (save one empty line removed) so there's no use
to keep it around.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: src/northbridge/amd/amdk8/coherent_ht_car.c
===
--- src/northbridge/amd/amdk8/coherent_ht_car.c (Revision 2997)
+++ src/northbridge/amd/amdk8/coherent_ht_car.c (Arbeitskopie)
@@ -1,1838 +0,0 @@
-/* coherent hypertransport initialization for AMD64
- *
- * written by Stefan Reinauer [EMAIL PROTECTED]
- * (c) 2003-2004 by SuSE Linux AG
- *
- * (c) 2004 Tyan Computer
- * 2004.12 yhlu added support to create routing table dynamically.
- * it also support 8 ways too. (8 ways ladder or 8 ways crossbar)
- *
- * This code is licensed under GPL.
- */
-
-/*
- * This algorithm assumes a grid configuration as follows:
- *
- * nodes : 12468
- * org. : 1x1 2x1 2x2 2x3 2x4
- Ladder:
- CPU7-CPU6
- ||
- ||
- ||
- ||
- ||
- ||
- CPU5-CPU4
- ||
- ||
- ||
- ||
- ||
- ||
- CPU3-CPU2
- ||
- ||
- ||
- ||
- ||
- ||
- CPU1-CPU0
- CROSS_BAR_47_56:
- CPU7-CPU6
- | \___/ |
- | \ / |
- |\/ |
- |/\ |
- | / \ |
- | /\___ |
- CPU5 CPU4
- ||
- ||
- ||
- ||
- ||
- ||
- CPU3-CPU2
- ||
- ||
- ||
- ||
- ||
- ||
- CPU1-CPU0
- */
-
-#include device/pci_def.h
-#include device/pci_ids.h
-#include device/hypertransport_def.h
-#include arch/romcc_io.h
-
-#include amdk8.h
-
-#define enable_bsp_routing() enable_routing(0)
-
-#define NODE_HT(x) PCI_DEV(0,24+x,0)
-#define NODE_MP(x) PCI_DEV(0,24+x,1)
-#define NODE_MC(x) PCI_DEV(0,24+x,3)
-
-#define DEFAULT 0x00010101 /* default row entry */
-
-#ifndef CROSS_BAR_47_56
- #define CROSS_BAR_47_56 0
-#endif
-
-#ifndef TRY_HIGH_FIRST
- #define TRY_HIGH_FIRST 0
-#endif
-
-#ifndef K8_HT_FREQ_1G_SUPPORT
- #define K8_HT_FREQ_1G_SUPPORT 0
-#endif
-
-#ifndef K8_HT_CHECK_PENDING_LINK
- #if CONFIG_MAX_PHYSICAL_CPUS = 4
- #define K8_HT_CHECK_PENDING_LINK 1
- #else
- #define K8_HT_CHECK_PENDING_LINK 0
- #endif
-#endif
-
-#ifndef CONFIG_MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED
- #define CONFIG_MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED 0
-#endif
-
-#ifndef ENABLE_APIC_EXT_ID
-#define ENABLE_APIC_EXT_ID 0
-#endif
-
-
-static inline void print_linkn (const char *strval, uint8_t byteval)
-{
-#if 1
-#if CONFIG_USE_PRINTK_IN_CAR
- printk_debug(%s%02x\r\n, strval, byteval);
-#else
- print_debug(strval); print_debug_hex8(byteval); print_debug(\r\n);
-#endif
-#endif
-}
-
-static void disable_probes(void)
-{
- /* disable read/write/fill probes for uniprocessor setup
- * they don't make sense if only one cpu is available
- */
-
- /* Hypetransport Transaction Control Register
- * F0:0x68
- * [ 0: 0] Disable read byte probe
- * 0 = Probes issues
- * 1 = Probes not issued
- * [ 1: 1] Disable Read Doubleword probe
- * 0 = Probes issued
- * 1 = Probes not issued
- * [ 2: 2] Disable write byte probes
- * 0 = Probes issued
- * 1 = Probes not issued
- * [ 3: 3] Disable Write Doubleword Probes
- * 0 = Probes issued
- * 1 = Probes not issued.
- * [10:10] Disable Fill Probe
- * 0 = Probes issued for cache fills
- * 1 = Probes not issued for cache fills.
- */
-
- u32 val;
-
- print_spew(Disabling read/write/fill probes for UP... );
-
- val=pci_read_config32(NODE_HT(0), HT_TRANSACTION_CONTROL);
- val |= HTTC_DIS_FILL_P | HTTC_DIS_RMT_MEM_C | HTTC_DIS_P_MEM_C |
- HTTC_DIS_MTS | HTTC_DIS_WR_DW_P | HTTC_DIS_WR_B_P |
- HTTC_DIS_RD_DW_P | HTTC_DIS_RD_B_P;
- pci_write_config32(NODE_HT(0), HT_TRANSACTION_CONTROL, val);
-
- print_spew(done.\r\n);
-
-}
-
-static void enable_apic_ext_id(u8 node)
-{
-#if ENABLE_APIC_EXT_ID==1
-#warning FIXME Is the right place
Re: [LinuxBIOS] mcp55 irq and apic patch
On Wed, Dec 05, 2007 at 11:38:15AM -0800, yhlu wrote:
[Patch] mcp55: irq and apic
route device irq through pci bridge instead in mptable.
don't enable pin0 for ioapic of io-4
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
Thanks! The patch didn't apply cleanly and had some random whitespace
breakage in it which I fixed, see attached version of the patch.
I'll reply with a quick review and some questions.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Route device IRQ through PCI bridge instead in mptable.
Don't enable pin0 for ioapic of io-4.
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
Index: src/southbridge/nvidia/mcp55/mcp55_lpc.c
===
--- src/southbridge/nvidia/mcp55/mcp55_lpc.c (Revision 2998)
+++ src/southbridge/nvidia/mcp55/mcp55_lpc.c (Arbeitskopie)
@@ -87,7 +87,7 @@
/* Be careful and don't write past the end... */
};
-static void setup_ioapic(unsigned long ioapic_base)
+static void setup_ioapic(unsigned long ioapic_base, int master)
{
int i;
unsigned long value_low, value_high;
@@ -95,7 +95,14 @@
volatile unsigned long *l;
struct ioapicreg *a = ioapicregvalues;
- ioapicregvalues[0].value_high = lapicid()(56-32);
+ if (master) {
+ ioapicregvalues[0].value_high = lapicid()(56-32);
+ ioapicregvalues[0].value_low = ENABLED | TRIGGER_EDGE | POLARITY_HIGH | PHYSICAL_DEST | ExtINT;
+ }
+ else {
+ ioapicregvalues[0].value_high = NONE;
+ ioapicregvalues[0].value_low = DISABLED;
+ }
l = (unsigned long *) ioapic_base;
@@ -121,14 +128,14 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#define SLOW_CPU_OFF 0
-#define SLOW_CPU__ON 1
+#define SLOW_CPU_OFF 0
+#define SLOW_CPU__ON 1
#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
+#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
-static void lpc_common_init(device_t dev)
+static void lpc_common_init(device_t dev, int master)
{
uint8_t byte;
uint32_t dword;
@@ -139,13 +146,12 @@
pci_write_config8(dev, 0x74, byte);
dword = pci_read_config32(dev, PCI_BASE_ADDRESS_1); // 0x14
- setup_ioapic(dword);
-
+ setup_ioapic(dword, master);
}
static void lpc_slave_init(device_t dev)
{
- lpc_common_init(dev);
+ lpc_common_init(dev, 0);
}
#if 0
@@ -166,13 +172,12 @@
int on;
int nmi_option;
- lpc_common_init(dev);
+ lpc_common_init(dev, 1);
#if 0
/* posted memory write enable */
byte = pci_read_config8(dev, 0x46);
pci_write_config8(dev, 0x46, byte | (10));
-
#endif
/* power after power fail */
@@ -198,7 +203,7 @@
dword = inl(pm10_bar + 0x10);
on = 8-on;
printk_debug(Throttling CPU %2d.%1.1d percent.\n,
-(on*12)+(on1),(on1)*5);
+ (on*12)+(on1),(on1)*5);
}
#if 0
Index: src/mainboard/nvidia/l1_2pvv/mptable.c
===
--- src/mainboard/nvidia/l1_2pvv/mptable.c (Revision 2998)
+++ src/mainboard/nvidia/l1_2pvv/mptable.c (Arbeitskopie)
@@ -39,6 +39,7 @@
unsigned sbdn;
int i,j;
+ unsigned char apicpin[4];
mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN);
memset(mc, 0, sizeof(*mc));
@@ -65,8 +66,8 @@
/*Bus: Bus ID Type*/
/* define bus and isa numbers */
-for(j= 0; j 256 ; j++) {
- if(m-bus_type[j])
+for (j = 0; j 256 ; j++) {
+ if (m-bus_type[j])
smp_write_bus(mc, j, PCI );
}
smp_write_bus(mc, m-bus_isa, ISA );
@@ -77,38 +78,43 @@
struct resource *res;
uint32_t dword;
-dev = dev_find_slot(m-bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0));
+dev = dev_find_slot(m-bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0));
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
- if (res) {
+ if (res)
smp_write_ioapic(mc, m-apicid_mcp55, 0x11, res-base);
- }
+ /* Initialize interrupt mapping*/
+ dword = pci_read_config32(dev, 0x74);
+ dword = ~(115);
+ dword |= 12;
+ pci_write_config32(dev, 0x74, dword);
+
dword = 0x43c6c643;
- pci_write_config32(dev, 0x7c, dword);
+ pci_write_config32(dev, 0x7c, dword);
dword = 0x81001a00;
pci_write_config32(dev, 0x80, dword);
- dword = 0xd00012d2;
+ dword = 0xd00012d2;
pci_write_config32(dev, 0x84, dword);
}
- if(m-bus_mcp55b[0]) {
-dev = dev_find_slot(m-bus_mcp55b[0], PCI_DEVFN(m-sbdnb + 0x1,0));
+ if (m-bus_mcp55b) {
+dev = dev_find_slot(m-bus_mcp55b, PCI_DEVFN(m-sbdnb + 0x1,0));
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
- if (res) {
+ if (res)
smp_write_ioapic(mc, m-apicid_mcp55b, 0x11, res-base);
- }
+
dword = 0x43c6;
- pci_write_config32(dev, 0x7c, dword);
+ pci_write_config32(dev, 0x7c, dword);
dword
Re: [LinuxBIOS] Add support for the AMD SimNow (TM) simulator (try 2)
On Tue, Dec 04, 2007 at 02:39:04PM -0700, Myles Watson wrote:
On 11/28/07, Jordan Crouse [EMAIL PROTECTED] wrote:
On 28/11/07 12:31 -0800, ron minnich wrote:
Is there a howto on the web page to show how to use this sim
environment? This is really cool.
I put up a basic page today that should help someone get started.
It's at http://www.linuxbios.org/AMD_SimNow and it's linked to from
the homepage, down by QEMU.
Very nice, thanks! But please add a license at the bottom of the page
(use {{GPL}} or {{PD-self}} etc).
See here for a list of licenses:
http://linuxbios.org/index.php?title=Special%3AAllpagesfrom=namespace=10
We can add others if you prefer another (free-ish) one.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] PCI: Left over static devices. Check your Config.lb
On Tue, Dec 04, 2007 at 04:08:47PM -0800, Steve Isaacs wrote: I'm seeing this message during boot and have made several attempts and modifying the Config.lb as the message suggests. Here's the tail of the messages: PCI: 00:09.0 [1166/0142] disabled PCI: 00:0a.0 subbordinate bus PCI Express PCI: 00:0a.0 [1166/0144] enabled PCI: 00:0b.0 subbordinate bus PCI Express PCI: 00:0b.0 [1166/0142] disabled PCI: 00:0c.0 subbordinate bus PCI Express PCI: 00:0c.0 [1166/0144] disabled PCI: 00:01.1 PCI: Left over static devices. Check your Config.lb I did start with a much longer list of left over devices and have narrowed it down to this one but I can't find a config that corrects the problem. I've tried locating documentation that provides the rules for proper PCI configuration but haven't found anything that helps me understand what I've gotten wrong. Any clues I need to look for? Please post your Config.lb and 'lspci -tvnn' output. You're likely listing PCI devices in Config.lb which are not on the board, or you use the wrong nesting or order (?) Uwe, -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] mcp55 irq and apic patch
On Wed, Dec 05, 2007 at 10:49:52PM +0100, Uwe Hermann wrote:
route device irq through pci bridge instead in mptable.
don't enable pin0 for ioapic of io-4
Please explain in more detail why the change is done and which
consequences there are or which bugs / problems are fixed.
Also, you're changing the MCP55 code _and_ some board-specific code
for just one board? Will the other MCP55 boards need fixes, too?
If so, which fixes?
Index: src/southbridge/nvidia/mcp55/mcp55_lpc.c
===
--- src/southbridge/nvidia/mcp55/mcp55_lpc.c (Revision 2998)
+++ src/southbridge/nvidia/mcp55/mcp55_lpc.c (Arbeitskopie)
@@ -87,7 +87,7 @@
/* Be careful and don't write past the end... */
};
-static void setup_ioapic(unsigned long ioapic_base)
+static void setup_ioapic(unsigned long ioapic_base, int master)
{
int i;
unsigned long value_low, value_high;
@@ -95,7 +95,14 @@
volatile unsigned long *l;
struct ioapicreg *a = ioapicregvalues;
- ioapicregvalues[0].value_high = lapicid()(56-32);
+ if (master) {
+ ioapicregvalues[0].value_high = lapicid()(56-32);
+ ioapicregvalues[0].value_low = ENABLED | TRIGGER_EDGE |
POLARITY_HIGH | PHYSICAL_DEST | ExtINT;
+ }
+ else {
+ ioapicregvalues[0].value_high = NONE;
+ ioapicregvalues[0].value_low = DISABLED;
+ }
l = (unsigned long *) ioapic_base;
@@ -121,14 +128,14 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#define SLOW_CPU_OFF 0
-#define SLOW_CPU__ON 1
+#define SLOW_CPU_OFF 0
+#define SLOW_CPU__ON 1
#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
+#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
-static void lpc_common_init(device_t dev)
+static void lpc_common_init(device_t dev, int master)
{
uint8_t byte;
uint32_t dword;
@@ -139,13 +146,12 @@
pci_write_config8(dev, 0x74, byte);
dword = pci_read_config32(dev, PCI_BASE_ADDRESS_1); // 0x14
- setup_ioapic(dword);
-
+ setup_ioapic(dword, master);
}
static void lpc_slave_init(device_t dev)
{
- lpc_common_init(dev);
+ lpc_common_init(dev, 0);
Maybe
#define FOO_MASTER 1
#define FOO_SLAVE 0
at the top of the file, with some good name for 'FOO', to
remove the magic constants from the function calls and to
make it clear what's meant.
}
#if 0
@@ -166,13 +172,12 @@
int on;
int nmi_option;
- lpc_common_init(dev);
+ lpc_common_init(dev, 1);
#if 0
/* posted memory write enable */
byte = pci_read_config8(dev, 0x46);
pci_write_config8(dev, 0x46, byte | (10));
-
#endif
/* power after power fail */
@@ -198,7 +203,7 @@
dword = inl(pm10_bar + 0x10);
on = 8-on;
printk_debug(Throttling CPU %2d.%1.1d percent.\n,
- (on*12)+(on1),(on1)*5);
+ (on*12)+(on1),(on1)*5);
}
#if 0
Index: src/mainboard/nvidia/l1_2pvv/mptable.c
===
--- src/mainboard/nvidia/l1_2pvv/mptable.c(Revision 2998)
+++ src/mainboard/nvidia/l1_2pvv/mptable.c(Arbeitskopie)
@@ -39,6 +39,7 @@
unsigned sbdn;
int i,j;
+ unsigned char apicpin[4];
This should be u8 I think (you need stdint.h).
mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN);
memset(mc, 0, sizeof(*mc));
@@ -65,8 +66,8 @@
/*Bus: Bus ID Type*/
/* define bus and isa numbers */
-for(j= 0; j 256 ; j++) {
- if(m-bus_type[j])
+for (j = 0; j 256 ; j++) {
+ if (m-bus_type[j])
smp_write_bus(mc, j, PCI );
}
smp_write_bus(mc, m-bus_isa, ISA );
@@ -77,38 +78,43 @@
struct resource *res;
uint32_t dword;
-dev = dev_find_slot(m-bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0));
+dev = dev_find_slot(m-bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0));
Why is this no longer an array? Only on this board or for all MCP55
boards?
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
- if (res) {
+ if (res)
smp_write_ioapic(mc, m-apicid_mcp55, 0x11,
res-base);
- }
+ /* Initialize interrupt mapping*/
+ dword = pci_read_config32(dev, 0x74);
+ dword = ~(115);
+ dword |= 12;
+ pci_write_config32(dev, 0x74, dword);
+
dword = 0x43c6c643;
- pci_write_config32(dev, 0x7c, dword
Re: [LinuxBIOS] r534 - in LinuxBIOSv3: arch/x86 include lib northbridge/amd/geodelx northbridge/intel/i440bxemulation
On Mon, Dec 03, 2007 at 10:08:36PM +0100, Stefan Reinauer wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [071203 21:32]: Author: uwe Date: 2007-12-03 21:32:53 +0100 (Mon, 03 Dec 2007) New Revision: 534 Added: LinuxBIOSv3/include/northbridgelib.h LinuxBIOSv3/lib/northbridgelib.c Reading the code this seems to belong to device/pci_device.c and device/device_util.c rather than in lib/? Good point. Patch sent with other subject. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] Move northbridgelib.c code to pci_device.c
See patch.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Move the code from northbridgelib.c to pci_device.c.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: include/northbridgelib.h
===
--- include/northbridgelib.h (Revision 535)
+++ include/northbridgelib.h (Arbeitskopie)
@@ -1,26 +0,0 @@
-/*
- * This file is part of the LinuxBIOS project.
- *
- * Copyright (C) 2007 Advanced Micro Devices, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include device/device.h
-
-void pci_domain_read_resources(struct device *dev);
-void ram_resource(struct device *dev, unsigned long index,
- unsigned long basek, unsigned long sizek);
-unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max);
Index: include/device/pci.h
===
--- include/device/pci.h (Revision 535)
+++ include/device/pci.h (Arbeitskopie)
@@ -94,6 +94,12 @@
struct resource *pci_get_resource(struct device *dev, unsigned long index);
void pci_dev_set_subsystem(struct device * dev, unsigned vendor, unsigned device);
+void pci_domain_read_resources(struct device *dev);
+void ram_resource(struct device *dev, unsigned long index,
+ unsigned long basek, unsigned long sizek);
+unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max);
+
+
#define PCI_IO_BRIDGE_ALIGN 4096
#define PCI_MEM_BRIDGE_ALIGN (1024*1024)
Index: device/pci_device.c
===
--- device/pci_device.c (Revision 535)
+++ device/pci_device.c (Arbeitskopie)
@@ -449,6 +449,32 @@
pci_get_rom_resource(dev, PCI_ROM_ADDRESS1);
}
+/**
+ * Set resources for the PCI domain.
+ *
+ * A PCI domain contains the I/O and memory resource address space below it.
+ * Set up basic global ranges for I/O and memory. Allocation of sub-resources
+ * draws on these top-level resources in the usual hierarchical manner.
+ *
+ * @param dev The northbridge device.
+ */
+void pci_domain_read_resources(struct device *dev)
+{
+ struct resource *res;
+
+ /* Initialize the system-wide I/O space constraints. */
+ res = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+ res-limit = 0xUL;
+ res-flags =
+ IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+ /* Initialize the system-wide memory resources constraints. */
+ res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+ res-limit = 0xULL;
+ res-flags =
+ IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
static void pci_set_resource(struct device *dev, struct resource *resource)
{
resource_t base, end;
@@ -580,6 +606,32 @@
pci_write_config8(dev, PCI_CACHE_LINE_SIZE, 64 2);
}
+/**
+ * Create a RAM resource, by taking the passed-in size and creating
+ * a resource record.
+ *
+ * @param dev The device.
+ * @param index A resource index.
+ * @param basek Base memory address in KB.
+ * @param sizek Size of memory in KB.
+ */
+void ram_resource(struct device *dev, unsigned long index,
+ unsigned long basek, unsigned long sizek)
+{
+ struct resource *res;
+
+ if (!sizek)
+ return;
+
+ res = new_resource(dev, index);
+ res-base = ((resource_t) basek) 10; /* Convert to bytes. */
+ res-size = ((resource_t) sizek) 10; /* Convert to bytes. */
+ res-flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE |
+ IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
+
+ printk(BIOS_SPEW, Adding RAM resource (%lld bytes)\n, res-size);
+}
+
void pci_dev_enable_resources(struct device *dev)
{
const struct pci_operations *ops;
@@ -1108,6 +1160,22 @@
}
/**
+ * Support for scan bus from the tippy top -- i.e. the PCI domain,
+ * not the 0:0.0 device.
+ *
+ * This function works for almost all chipsets (AMD K8 is the exception).
+ *
+ * @param dev The PCI domain device.
+ * @param max Maximum number of devices to scan.
+ * @return TODO
+ */
+unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max)
+{
+ /* There is only one link on this device, and it is always link 0. */
+ return pci_scan_bus(dev-link[0], PCI_DEVFN(0, 0), 0xff, max);
+}
+
+/**
* Scan a PCI bridge and the buses behind the bridge
Re: [LinuxBIOS] [PATCH] Move northbridgelib.c code to pci_device.c
On Tue, Dec 04, 2007 at 12:23:04PM +0100, Stefan Reinauer wrote: Acked-by: Stefan Reinauer [EMAIL PROTECTED] Thanks, r536. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Refactoring, northbridgelib.c
On Sun, Dec 02, 2007 at 10:58:31AM -0800, ron minnich wrote: Acked-by: Ronald G. Minnich [EMAIL PROTECTED] Thanks, r534. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] LinuxBIOS on Compaq ProLiant 1850R?
On Mon, Dec 03, 2007 at 10:45:01AM -0500, Corey Osgood wrote: I was wondering if LinuxBIOS would work on my Compaq ProLiant 1850R server. The current Compaq BIOS lacks a lot of options. The system itself is not supported yet, but all the components are. It wouldn't be very hard to port it. Yep, let's do it. Does the board have a socketed BIOS so you can hot-swap it to have a backup chip stored away safely? I identified the following chips on the mainboard: Super I/O: NSC PC87317 Northbridge: Intel FW82443BX Southbridge: Intel FW82371EB Looks good, we can support that easily. Please send the output of 'lspci -tvnn' and 'superiotool -dV' from your board (run it as root). Also, please run the 'getpir' tool and send us the irq_tables.c file which is generated by the tool. We can make a patch with that information then, if you're willing to test it on your hardware. SCSI: Symbios LSI 53C876 (on-board) You'd have to extract the original option rom from the bios for this, then prepend it to linuxbios. Explore around the wiki a bit, there's a build guide for another board with a SCSI option rom, or else it's the same process as for a VGA rom. Do you absolutely need the SCSI? See also Peter's post, I'm not sure if/how it may work, but you should be able to boot off of IDE just fine with LinuxBIOS if that helps. Video: ATI Rage IIc (on-board) There's a driver in LB for the rage, I don't know if it'll work with this particular one or not, but it can't hurt to try. This would mean no Yeah, that would be very interesting to know. need to use the vendor BIOS. There's a tyan board that uses this, but I don't know which one(s) off the top of my head. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Infamous __stack_chk_fail problem.
On Mon, Dec 03, 2007 at 10:36:51PM +0100, Stefan Reinauer wrote: You can add the following lines to your target/vendor/board/Config.lb: option CC=i386-elf-gcc # this one is CFLAGS. option CPU_OPT=-O2 -Wl,... option HOSTCC=gcc Yep, this should be in the wiki (FAQ?) if it's not already there. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Improved Intel 82371EB (and others) support
On Fri, Nov 30, 2007 at 04:01:16AM +0100, Žiga Mlinar wrote: This is required to make all 440BX based boards in v2 almost fully supported. Without the patch at least the Super I/O init is never performed, thus lots of stuff is broken. Works here on Azza/PT-6IBD. With this patch ps2 mouse and ps2 keyboard work. They didn't before. Great, thanks! Wiki is updated now. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] OT: Motherboard
On Mon, Dec 03, 2007 at 05:08:57PM -0500, Forest Dean Feighner wrote: Off topic for the list yet apropos. Can anyone recommend an entry level motherboard that has a bios socket rather than one wired to the board? Too generic. There are tons of boards with socketed BIOS. Do you want a shiny new boards or something older from the Pentium II/III era etc? http://linuxbios.org/Supported_Motherboards Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Infamous __stack_chk_fail problem.
On Mon, Dec 03, 2007 at 02:11:50PM -0800, Steve Isaacs wrote: So, I summarize. If I need a consistent and repeatable build I use the toolchain of my choice and use the above to point the LinuxBIOS build to that toolchain. Yep, pretty much. For a product you probably also want to stick with a certain tested svn version of LinuxBIOS (not trunk, which is a moving target). (This doesn't mean trunk is unstable. Any breakage is considered a no-no and is a bug; all commits should keep trunk in a building/working state. But using a specific svn version is still a bit safer) HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] State of the buildrom
On Mon, Dec 03, 2007 at 11:29:27AM -0700, Jordan Crouse wrote: I think it's more important to figure out how we really want to configure LinuxBIOS (it seems to be a large hurdle for newbies), not buildrom. Agreed - being able to do these things easily with v3 is a priority. We have to think about what we would want to control externally, and then make those knobs easy to turn. Isn't that easy in v3 already? You just use / modify defconfig files as with the kernel. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Refactoring, northbridgelib.c
On Tue, Nov 27, 2007 at 02:08:52AM +0100, Uwe Hermann wrote: See patch. Factor out common code. In v2 98% of all northbridges do exactly the same thing (in these functions), thus refactor. It's easy to override the common functions if a northbridge needs slightly different ones (I think K8 will, for example). ping? Thiѕ is a pretty obvious refactoring which removes lots of duplicated code (now, and for many future northbridges we'll add). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] flashrom: Acorp 6A815EPD board-enable
On Mon, Nov 26, 2007 at 05:24:25PM -0600, [EMAIL PROTECTED] wrote:
Add board-enable for Acorp 6A815EPD.
Signed-off-by: Jonathan A. Kollasch [EMAIL PROTECTED]
Thanks, committed in r2995.
+ dev = pci_dev_find(0x8086, 0x2440); /* Intel ICH2 LPC */
+ if (!dev) {
+ fprintf(stderr, \nERROR: ICH2 LPC bridge not found.\n);
+ return -1;
+ }
+
+ /* use GPIOBASE register to find where the GPIO is mapped */
+ port = (pci_read_word(dev, 0x58) 0xFF80) + 0xE;
Maybe I have a thinko, but shouldn't this be 0xffc0 instead of 0xff80?
+
+ val = inb(port);
+ val |= 0x80; /* Top Block Lock -- pin 8 of PLCC32 */
+ val |= 0x40; /* Lower Blocks Lock -- pin 7 of PLCC32 */
This is board-specific I assume? Did you trace the connections going to
the ROM to find the specific lines?
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Booting Windows with QEMU+LinuxBIOS
On Thu, Nov 29, 2007 at 06:37:10PM +0900, Jun Koi wrote: Hmm... I managed to do like this: - Compile ADLO separately, then I have a file named payload - In LinuxBIOSv3, I run make menuconfig, then specify the path of payload option to the above payload. - Save options, quit and compile. As a result, I have build/bios.bin, and I overwrites this file onto the original bios.bin of my QEMU. No need to overwrite. Just use the '-L build' command line option for QEMU and it will use the bios.bin in the build/ directory instead of the normal one. Then, I run QEMU with my Linux image. It works, and I can login to my Linux QEMU. Now, the problem is that I am not sure if my Linux on QEMU really uses LinuxBIOS. How can I confirm that? dmesg doesnt seem to return anything special to me. Use the '-serial stdio' command line option with QEMU, that will print a LinuxBIOS starting... or similar message if it's really LinuxBIOS. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] USB booting in LinuxBIOS
On Thu, Nov 29, 2007 at 08:00:11PM -0700, Jordan Crouse wrote: On 30/11/07 03:33 +0100, Uwe Hermann wrote: [New thread] On Thu, Nov 29, 2007 at 08:25:32PM -0500, Richard Smith wrote: That said, here in the OLPC offices we have still have periodic pain involved with USB booting. A lot of usb sticks are just trash. The generic case requires up to several seconds of delay before you can access them. I'm curious, what do you use for USB booting? Is it suitable for generic LinuxBIOS use, too? Both FILO and Etherboot seem pretty broken wrt USB at the moment, GRUB2 doesn't have support at all AFAIK. They use OFW. Sure, but how is the boot from USB functionality implemented? Forth code? C code? Can we port it to LinuxBIOS/FILO/GRUB somehow? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] IDE legacy port access + UDMA/33 for 440BX boards
On Fri, Nov 30, 2007 at 09:14:57AM +0100, Stefan Reinauer wrote: * Uwe Hermann [EMAIL PROTECTED] [071130 03:21]: See patch. At the very least the IDE legacy port access must be enabled to be able to use FILO. The rest is optional, but I see no reason to not enable it per default. should this maybe be a cmos option instead? Some old drives (being present in old machines) might not work with the setting. On the long run, yes. IMO we should automatically extract a CMOS option out of these config variables. All of them make run-time decisions in the code already - perfect for CMOS options. For now I'd like to commit as is, there's no CMOS support on 440BX boards anyway at the moment, and ide_legacy_enable = 1 is really needed to be able to use FILO. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] r2991 - trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx
On Thu, Nov 29, 2007 at 02:39:30PM +0100, Stefan Reinauer wrote: Signed-off-by: Mondrian Nuessle [EMAIL PROTECTED] Acked-by: mcq [EMAIL PROTECTED] Short question: Do we require real names for Acked-by or is that just a requirement for Signed-off-by? I vote for both. Me too, but there wasn't any real name in trac to use this time (sorry). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] USB booting in LinuxBIOS
[New thread] On Thu, Nov 29, 2007 at 08:25:32PM -0500, Richard Smith wrote: That said, here in the OLPC offices we have still have periodic pain involved with USB booting. A lot of usb sticks are just trash. The generic case requires up to several seconds of delay before you can access them. I'm curious, what do you use for USB booting? Is it suitable for generic LinuxBIOS use, too? Both FILO and Etherboot seem pretty broken wrt USB at the moment, GRUB2 doesn't have support at all AFAIK. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] Improved Intel 82371EB (and others) support
See patch.
This is required to make all 440BX based boards in v2 almost fully
supported. Without the patch at least the Super I/O init is never
performed, thus lots of stuff is broken.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Improve support for the Intel 82371FB/SB/AB/EB/MB southbridge(s):
- Implement ISA related support:
- Initialize the RTC
- Enable access to all BIOS regions (but _not_ write access to ROM)
- Enable ISA (not EIO) support
- Without the *_isa.c file, the Super I/O init is never performed
- Improve IDE support:
- Add config option to enable Ultra DMA/33 for each disk
- Add config option to enable legacy IDE port access
- Implement hard reset support
- Implement USB controller support
- Various code cleanups and improvements
The code partially supports southbridges other than the 82371EB (but
which are very similar), more complete support will follow.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: src/southbridge/intel/i82371eb/Config.lb
===
--- src/southbridge/intel/i82371eb/Config.lb (Revision 2993)
+++ src/southbridge/intel/i82371eb/Config.lb (Arbeitskopie)
@@ -19,8 +19,9 @@
##
config chip.h
-
driver i82371eb.o
+driver i82371eb_isa.o
+driver i82371eb_ide.o
+driver i82371eb_usb.o
driver i82371eb_smbus.o
-driver i82371eb_ide.o
-
+driver i82371eb_reset.o
Index: src/southbridge/intel/i82371eb/i82371eb_isa.c
===
--- src/southbridge/intel/i82371eb/i82371eb_isa.c (Revision 0)
+++ src/southbridge/intel/i82371eb/i82371eb_isa.c (Revision 0)
@@ -0,0 +1,72 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Uwe Hermann [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include stdint.h
+#include console/console.h
+#include device/device.h
+#include device/pci.h
+#include device/pci_ids.h
+#include pc80/isa-dma.h
+#include pc80/mc146818rtc.h
+#include i82371eb.h
+
+static void isa_init(struct device *dev)
+{
+ u16 reg16;
+ u32 reg32;
+
+ /* Initialize the real time clock (RTC). */
+ rtc_init(0);
+
+ /* Enable access to all BIOS regions. */
+ reg16 = pci_read_config16(dev, XBCS);
+ reg16 |= LOWER_BIOS_ENABLE;
+ reg16 |= EXT_BIOS_ENABLE;
+ reg16 |= EXT_BIOS_ENABLE_1MB;
+ reg16 = ~(WRITE_PROTECT_ENABLE); /* Disable ROM write access. */
+ pci_write_config16(dev, XBCS, reg16);
+
+ /*
+ * The PIIX4 can support the full ISA bus, or the Extended I/O (EIO)
+ * bus, which is a subset of ISA. We select the full ISA bus here.
+ */
+ reg32 = pci_read_config32(dev, GENCFG);
+ reg32 |= ISA; /* Select ISA, not EIO. */
+ pci_write_config16(dev, GENCFG, reg32);
+
+ /* Initialize ISA DMA. */
+ isa_dma_init();
+}
+
+static const struct device_operations isa_ops = {
+ .read_resources = pci_dev_read_resources,
+ .set_resources = pci_dev_set_resources,
+ .enable_resources = pci_dev_enable_resources,
+ .init = isa_init,
+ .scan_bus = scan_static_bus, /* TODO: Needed? */
+ .enable = 0,
+ .ops_pci = 0, /* No subsystem IDs on 82371EB! */
+};
+
+static const struct pci_driver isa_driver __pci_driver = {
+ .ops = isa_ops,
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_INTEL_82371AB_ISA,
+};
Index: src/southbridge/intel/i82371eb/i82371eb.c
===
--- src/southbridge/intel/i82371eb/i82371eb.c (Revision 2993)
+++ src/southbridge/intel/i82371eb/i82371eb.c (Arbeitskopie)
@@ -18,46 +18,47 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-/* Datasheet:
+/* Note: This code supports the 82371FB/SB/MX/AB/EB/MB and 82437MX. */
+
+/* Datasheets:
+ * - Name: 82371FB (PIIX) AND 82371SB (PIIX3) PCI ISA IDE XCELERATOR
+ * - URL: http://www.intel.com/design/intarch/datashts/290550.htm
+ * - PDF: http://download.intel.com/design/intarch/datashts/29055002.pdf
+ * - Date: April 1997
+ * - Order Number: 290550-002
+ *
+ * - Name: 82371FB (PIIX) and 82371SB (PIIX3) PCI ISA IDE Xcelerator
+ * Specification Update
+ * - URL: http://www.intel.com/design/chipsets/specupdt/297658.htm
+ * - PDF: http://download.intel.com
[LinuxBIOS] [PATCH] IDE legacy port access + UDMA/33 for 440BX boards
See patch. At the very least the IDE legacy port access must be enabled to be able to use FILO. The rest is optional, but I see no reason to not enable it per default. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org Enable IDE legacy port access and UDMA/33 for all 440BX based boards per default, for now. If there are problems with UDMA on some of them we might selectively disable UDMA there. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Index: src/mainboard/a-trend/atc-6220/Config.lb === --- src/mainboard/a-trend/atc-6220/Config.lb (Revision 2994) +++ src/mainboard/a-trend/atc-6220/Config.lb (Arbeitskopie) @@ -130,6 +130,11 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/gigabyte/ga-6bxc/Config.lb === --- src/mainboard/gigabyte/ga-6bxc/Config.lb (Revision 2994) +++ src/mainboard/gigabyte/ga-6bxc/Config.lb (Arbeitskopie) @@ -128,6 +128,11 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/biostar/m6tba/Config.lb === --- src/mainboard/biostar/m6tba/Config.lb (Revision 2994) +++ src/mainboard/biostar/m6tba/Config.lb (Arbeitskopie) @@ -124,6 +124,11 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/azza/pt-6ibd/Config.lb === --- src/mainboard/azza/pt-6ibd/Config.lb (Revision 2994) +++ src/mainboard/azza/pt-6ibd/Config.lb (Arbeitskopie) @@ -130,6 +130,11 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/tyan/s1846/Config.lb === --- src/mainboard/tyan/s1846/Config.lb (Revision 2994) +++ src/mainboard/tyan/s1846/Config.lb (Arbeitskopie) @@ -126,6 +126,11 @@ device pci 7.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/compaq/deskpro_en_sff_p600/Config.lb === --- src/mainboard/compaq/deskpro_en_sff_p600/Config.lb (Revision 2994) +++ src/mainboard/compaq/deskpro_en_sff_p600/Config.lb (Arbeitskopie) @@ -134,6 +134,11 @@ device pci 14.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/asus/p2b/Config.lb === --- src/mainboard/asus/p2b/Config.lb (Revision 2994) +++ src/mainboard/asus/p2b/Config.lb (Arbeitskopie) @@ -130,6 +130,11 @@ device pci 4.3 on end # ACPI register ide0_enable = 1 register ide1_enable = 1 + register ide_legacy_enable = 1 + register ide0_drive0_udma33_enable = 1 + register ide0_drive1_udma33_enable = 1 + register ide1_drive0_udma33_enable = 1 + register ide1_drive1_udma33_enable = 1 end end end Index: src/mainboard/asus/p2b-f/Config.lb === --- src/mainboard/asus/p2b-f/Config.lb (Revision 2994) +++ src/mainboard/asus/p2b-f/Config.lb (Arbeitskopie) @@ -130,6 +130,11 @@ device pci 4.3 on end # ACPI
Re: [LinuxBIOS] [PATCH] Improved Intel 82371EB (and others) support
On Fri, Nov 30, 2007 at 02:50:31AM +0100, Stefan Reinauer wrote: Acked-by: Stefan Reinauer [EMAIL PROTECTED] Thanks, r2994. Not sure about the USB controller part. It does nothing, yet, does it? Good question. This needs some more testing, but I _think_ Linux just enables the USB ports anyway, no matter what we configure here (even setting it to 'off' in Config.lb seems to be ignored by Linux (?)) That's not a reason to not attempt any init, though. We not only want to support Linux but also ADLO/Windows, FILO/GRUB (which might require the USB devices to be setup (?)), custom payloads etc. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
On Wed, Nov 28, 2007 at 08:04:59AM -0500, Richard Smith wrote: I may be able to help out here. I have a GigaByte i440bx board with a dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled. Oh. I don't care about bricking. My boards have sockets and unbricking things is my specialty. I got programmers, rework equipment, bla bla. I just don't want to spend my time adding memory autodetection code if somebody already has it 90% there. I have an almost-finished (and untested, yet) patch lingering on my drive for a few weeks now for the 440BX RAM init, which adds generic SPD functions in lib/spd.c and some 440BX-specific stuff in the resp. raminit.c. Will post soon. Another patch I have here (just needs some small fixes, but an older version is still in the list archives, I posted it months ago) for the 82371EB southbridge which the 440BX boards use. I'll finish up that one first an post it after a few tests. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] AMD CPU ID fixes and additions
See patch.
There are some comment updates (datasheet now says SH-CG instead of
SH7-CG, for example), and also 2-3 new CPU IDs. I only looked at
the AMD Athlon64 datasheet, other parts might need updates, too.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Update AMD CPU IDs in model_fxx_init.c with information from
the latest version (Rev. 3.73, October 2007) of the 'Revision Guide for
AMD Athlon 64 and AMD Opteron Processors' datasheet.
Also, add information about the CPU socket for each ID (as per datasheet).
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: src/cpu/amd/model_fxx/model_fxx_init.c
===
--- src/cpu/amd/model_fxx/model_fxx_init.c (Revision 2988)
+++ src/cpu/amd/model_fxx/model_fxx_init.c (Arbeitskopie)
@@ -562,42 +562,45 @@
};
static struct cpu_device_id cpu_table[] = {
#if K8_REV_F_SUPPORT == 0
- { X86_VENDOR_AMD, 0xf50 }, /* B3 */
- { X86_VENDOR_AMD, 0xf51 }, /* SH7-B3 */
- { X86_VENDOR_AMD, 0xf58 }, /* SH7-C0 */
- { X86_VENDOR_AMD, 0xf48 },
+ { X86_VENDOR_AMD, 0xf40 }, /* SH-B0 (socket 754) */
+ { X86_VENDOR_AMD, 0xf50 }, /* SH-B0 (socket 940) */
+ { X86_VENDOR_AMD, 0xf51 }, /* SH-B3 (socket 940) */
+ { X86_VENDOR_AMD, 0xf58 }, /* SH-C0 (socket 940) */
+ { X86_VENDOR_AMD, 0xf48 }, /* SH-C0 (socket 754) */
+ { X86_VENDOR_AMD, 0xf5a }, /* SH-CG (socket 940) */
+ { X86_VENDOR_AMD, 0xf4a }, /* SH-CG (socket 754) */
+ { X86_VENDOR_AMD, 0xf7a }, /* SH-CG (socket 939) */
+ { X86_VENDOR_AMD, 0xfc0 }, /* DH-CG (socket 754) */
+ { X86_VENDOR_AMD, 0xfe0 }, /* DH-CG (socket 754) */
+ { X86_VENDOR_AMD, 0xff0 }, /* DH-CG (socket 939) */
+ { X86_VENDOR_AMD, 0xf82 }, /* CH-CG (socket 754) */
+ { X86_VENDOR_AMD, 0xfb2 }, /* CH-CG (socket 939) */
- { X86_VENDOR_AMD, 0xf5A }, /* SH7-CG */
- { X86_VENDOR_AMD, 0xf4A },
- { X86_VENDOR_AMD, 0xf7A },
- { X86_VENDOR_AMD, 0xfc0 }, /* DH7-CG */
- { X86_VENDOR_AMD, 0xfe0 },
- { X86_VENDOR_AMD, 0xff0 },
- { X86_VENDOR_AMD, 0xf82 }, /* CH7-CG */
- { X86_VENDOR_AMD, 0xfb2 },
//AMD_D0_SUPPORT
- { X86_VENDOR_AMD, 0x10f50 }, /* SH7-D0 */
- { X86_VENDOR_AMD, 0x10f40 },
- { X86_VENDOR_AMD, 0x10f70 },
-{ X86_VENDOR_AMD, 0x10fc0 }, /* DH7-D0 */
-{ X86_VENDOR_AMD, 0x10ff0 },
-{ X86_VENDOR_AMD, 0x10f80 }, /* CH7-D0 */
-{ X86_VENDOR_AMD, 0x10fb0 },
+ { X86_VENDOR_AMD, 0x10f50 }, /* SH-D0 (socket 940) */
+ { X86_VENDOR_AMD, 0x10f40 }, /* SH-D0 (socket 754) */
+ { X86_VENDOR_AMD, 0x10f70 }, /* SH-D0 (socket 939) */
+{ X86_VENDOR_AMD, 0x10fc0 }, /* DH-D0 (socket 754) */
+{ X86_VENDOR_AMD, 0x10ff0 }, /* DH-D0 (socket 939) */
+{ X86_VENDOR_AMD, 0x10f80 }, /* CH-D0 (socket 754) */
+{ X86_VENDOR_AMD, 0x10fb0 }, /* CH-D0 (socket 939) */
+
//AMD_E0_SUPPORT
-{ X86_VENDOR_AMD, 0x20f50 }, /* SH8-E0*/
+{ X86_VENDOR_AMD, 0x20f50 }, /* SH8-E0 */
{ X86_VENDOR_AMD, 0x20f40 },
{ X86_VENDOR_AMD, 0x20f70 },
-{ X86_VENDOR_AMD, 0x20fc0 }, /* DH8-E0 */ /* DH-E3 */
-{ X86_VENDOR_AMD, 0x20ff0 },
-{ X86_VENDOR_AMD, 0x20f10 }, /* JH8-E1 */
+{ X86_VENDOR_AMD, 0x20fc0 }, /* DH8-E0 */ /* DH-E3 (socket 754) */
+{ X86_VENDOR_AMD, 0x20ff0 }, /* DH-E3 (socket 939) */
+{ X86_VENDOR_AMD, 0x20f10 }, /* JH-E1 (socket 940) */
{ X86_VENDOR_AMD, 0x20f30 },
-{ X86_VENDOR_AMD, 0x20f51 }, /* SH-E4 */
-{ X86_VENDOR_AMD, 0x20f71 },
-{ X86_VENDOR_AMD, 0x20f42 }, /* SH-E5 */
-{ X86_VENDOR_AMD, 0x20ff2 }, /* DH-E6 */
-{ X86_VENDOR_AMD, 0x20fc2 },
-{ X86_VENDOR_AMD, 0x20f12 }, /* JH-E6 */
-{ X86_VENDOR_AMD, 0x20f32 },
+{ X86_VENDOR_AMD, 0x20f51 }, /* SH-E4 (socket 940) */
+{ X86_VENDOR_AMD, 0x20f71 }, /* SH-E4 (socket 939) */
+{ X86_VENDOR_AMD, 0x20fb1 }, /* BH-E4 (socket 939) */
+{ X86_VENDOR_AMD, 0x20f42 }, /* SH-E5 (socket 754) */
+{ X86_VENDOR_AMD, 0x20ff2 }, /* DH-E6 (socket 939) */
+{ X86_VENDOR_AMD, 0x20fc2 }, /* DH-E6 (socket 754) */
+{ X86_VENDOR_AMD, 0x20f12 }, /* JH-E6 (socket 940) */
+{ X86_VENDOR_AMD, 0x20f32 }, /* JH-E6 (socket 939) */
{ X86_VENDOR_AMD, 0x30ff2 }, /* E4 ? */
#endif
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: factor out one makefile rule
On Tue, Nov 27, 2007 at 10:54:59AM -0800, ron minnich wrote: Acked-by: Ronald G. Minnich [EMAIL PROTECTED] r529. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] AMD CPU ID fixes and additions
On Wed, Nov 28, 2007 at 05:23:57PM -0700, Jordan Crouse wrote: There are some comment updates (datasheet now says SH-CG instead of SH7-CG, for example), and also 2-3 new CPU IDs. I only looked at the AMD Athlon64 datasheet, other parts might need updates, too. As far as the uncommented ones: You can get rid of 0x20f30, that shouldn't be in the wild. The other OK, done. unknown ones are real, but they are not listed in the public revision guides, so no details. Acked-by: Jordan Crouse [EMAIL PROTECTED] Thanks, r2989. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
On Tue, Nov 27, 2007 at 03:39:54AM +0100, Peter Stuge wrote: On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote: What 440bx based boards now work? tyan/s1846 Uh, that and ASUS P2B ASUS P2B-F ASUS P3B-F A-Trend ATC-6220 AZZA PT-6IBD Biostar M6TBA Compaq Deskpro EN SFF P600 GIGABYTE GA-6BXC Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] v3: convert stage2 to multi-segment LAR
On Tue, Nov 27, 2007 at 06:26:23PM +0100, Stefan Reinauer wrote: * Carl-Daniel Hailfinger [EMAIL PROTECTED] [071127 18:01]: Yes. How about: old way: normal/stage2.o/segment0 normal/stage2.o/segment1 new 1: normal/stage2/seg0 normal/stage2/seg1 new 2: normal/stage2/0 normal/stage2/1 I prefer having seg in the name to make it obvious that these are segments. Then just leave the name segment. It doesn't significantly safe space to abbreviate here. I like dropping .o in the name though. ACK for both. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: post code standard
On Mon, Nov 26, 2007 at 03:02:00PM -0800, ron minnich wrote: comments welcome. ron Proposed start of standard post codes. Signed-off-by: Ronald G. Minnich [EMAIL PROTECTED] Index: include/post_code.h === --- include/post_code.h (revision 521) +++ include/post_code.h (working copy) @@ -25,6 +25,11 @@ SHARED(post_code, void, u8 value); -#define POST_START_OF_MAIN 0x01 +#define POST_FATAL_ERROR 0xff Maybe this should not be 0xff or 0x00, as dummy/tests/errors might also produce 0x00 or 0xff? Maybe 0xfe or something to distringuish it from other random problems in the (hardware) setup? +#define POST_CAR_BASE0x03 What is this? When is it used? I think each (or most) POST codes should have a comment here. +#define POST_STAGE1_BASE 0x10 +#define POST_STAGE2_BASE 0x20 I like the names here. +/* BOGUS! */ +#define POST_START_OF_MAIN 0x01 #endif /* POST_CODE_H */ I agree with Peter that a chronological order might be good. _And_ the chronological order should (mostly at least) match the numbers, i.e. higher numbers appear later in the boot process. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote: That said, I still have some boards and I would sure love to see proper video pop out sometime before I die. It is the only project of mine that outright failed because of technical problems I was not able to solve. The scars remain. That was 6 months of some of the most intense debugging I've ever done. Eventually discovering the root cause would cleanse my debugging soul. What 440bx based boards now work? Each one which is in v2 svn (ca. 10 boards). Maybe I'll take a Sunday afternoon and try to boot the code one of them on the IMS boards I have. That would be great. If you stick one DIMM in slot 0 it should boot right away (yes, this will be fixed to support all combinations), just use either of the 440BX targets in svn. Except for 4-5 lines of code per target they're all the same. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] flashrom support for AMD CS5536
On Wed, Nov 28, 2007 at 01:15:01AM +0700, Darmawan Salihun wrote: I'm not sure if there is somekind of /dev/cmos in Linux. But IIRC, there is a project that working on such a thing. I just don't know where exactly it is. I think lxbios has an option to dump the CMOS contents (which should also work if you're not booted with LinuxBIOS). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Constify structs
On Sun, Nov 25, 2007 at 07:09:03PM -0800, ron minnich wrote: Acked-by: Ronald G. MInnich [EMAIL PROTECTED] Thanks, r519. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Can't compile flashrom
On Mon, Nov 26, 2007 at 09:34:17AM -0700, Shocky wrote: On Sunday 25 November 2007 19:42, ron minnich wrote: how's about we just figure out why flashrom won't build? ron Yeah, that's what I was hoping for 8^). Any ideas? Please post the full compile output here. Do you have pciutils-dev and zlib-dev (or whatever it's called on your distribution) installed? Also, there's a Mandriva package already (don't know in which branch of Mandriva though). Doesn't that work? http://linuxbios.org/Flashrom#Installation If all else fails, edit the Makefile to remove the check for pciutils-dev etc. and see if it works anyway. Maybe it's just the check which is broken. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Various cleanups
On Sun, Nov 25, 2007 at 08:12:25PM -0500, Corey Osgood wrote: Did Carl-Daniel's documentation fixes make it in yet? I think so, yes. r511, r512. Index: mainboard/emulation/qemu-x86/vga.c === --- mainboard/emulation/qemu-x86/vga.c (Revision 518) +++ mainboard/emulation/qemu-x86/vga.c (Arbeitskopie) @@ -32,11 +32,14 @@ struct pc_keyboard conf; printk(BIOS_INFO, Init VGA device\n); + dev-on_mainboard = 1; dev-rom_address = 0xc; - // FIXME - this should be in superio some day - // but since qemu has no superio. + /* +* FIXME: This should be in superio some day Comma please Done. +* but since QEMU has no superio... +*/ init_pc_keyboard(0x60, 0x64, conf); } Index: README === --- README (Revision 518) +++ README (Arbeitskopie) @@ -102,7 +102,7 @@ The 'flashrom' tool is located in util/flashrom where you can build it from source code by typing 'make'. Alternatively, your favorite Linux distribution might ship a 'flashrom' package which provides the 'flashrom' - program in (e.g.) /usr/bin. On Debian GNU/Linux systems you can get + program in /usr/sbin. On Debian GNU/Linux systems you can get the flashrom package via 'apt-get install flashrom'. Does every distribution out there provide it in /usr/sbin? If not, please leave the (e.g.). Done. I don't know what other distros do, but /usr/sbin is the correct location according to the FHS, and it's also the default install location in the current svn version of flashrom. Acked-by: Corey Osgood [EMAIL PROTECTED] Thanks, r520. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Various cleanups
[Please post all replies on the mailing list]
On Mon, Nov 26, 2007 at 07:36:31PM +0100, Paul Menzel wrote:
Hi,
small typos I think.
Am Montag, den 26.11.2007, 00:54 + schrieb Uwe Hermann:
/**
- * Place holder in case we ever need it. Since this file is a
- * template for other motherboards, we want this here and we want the
- * call in the right place.
- */
-
+ * Place holder in case we ever need it. Since this file is a template for
Placeholder
Fixed.
+ * other boards, we want this here and we want the call in the right place.
+ */
static void mb_gpio_init(void)
{
/* Early mainboard specific GPIO setup */
}
- /* NOTE: must do this AFTER the early_setup!
-* it is counting on some early MSR setup
-* for cs5536.
+ /*
+* NOTE: Must do this AFTER the early_setup! It is counting on some
+* early MSR setup for the CS5536. We do this early for debug.
+* Real setup should done in chipset init via Config.lb.
should be done
Fixed.
Index: README
===
--- README (Revision 518)
+++ README (Arbeitskopie)
- program in (e.g.) /usr/bin. On Debian GNU/Linux systems you can get
+ program in /usr/sbin. On Debian GNU/Linux systems you can get
the flashrom package via 'apt-get install flashrom'.
aptitude
That's more a matter of taste.
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] add support the IEI PCISA-LX
On Mon, Nov 26, 2007 at 12:25:45PM +0500, Nikolay Petukhov wrote:
This board (http://www.ieiworld.com/en/product_IPC.asp?model=PCISA-LX)
is based on amd-lx800/cs5536, so most of the on-board hardware is work
normally.
Thanks a lot! Here's a quick review:
I think the full name for this specific board is PCISA-LX-R11,
correct? If so, please use that everywhere (directory names, strings,
variable names, comments). PCISA-LX seems to be the general name for a
whole family of boards.
So the directory name should probably be 'pcisa-lx-r11'.
diff -Nru LinuxBIOSv2-2986/src/mainboard/iei/pcisa-lx/cache_as_ram_auto.c
LinuxBIOSv2-2986-lx/src/mainboard/iei/pcisa-lx/cache_as_ram_auto.c
--- LinuxBIOSv2-2986/src/mainboard/iei/pcisa-lx/cache_as_ram_auto.c
1970-01-01 05:00:00.0 +0500
+++ LinuxBIOSv2-2986-lx/src/mainboard/iei/pcisa-lx/cache_as_ram_auto.c
2007-11-26 09:50:43.0 +0500
@@ -0,0 +1,138 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov [EMAIL PROTECTED]
+ * Borrowed from amd/db800.
Either the code you grabbed from the DB800 target is trivial (then drop
this line completely), or it is not (then retain the Copyright lines from
the respective DB800 file please).
In this case the file is a plain copy of the DB800 one, with small fixes
in the #defines at the beginning, so please keep the original
copyright/license header and drop the Borrowed from amd/db800.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include stdint.h
+#include device/pci_def.h
+#include arch/io.h
+#include device/pnp_def.h
+#include arch/hlt.h
+#include pc80/serial.c
+#include arch/i386/lib/console.c
+#include ram/ramtest.c
+#include cpu/x86/bist.h
+#include cpu/x86/msr.h
+#include cpu/amd/lxdef.h
+#include cpu/amd/geode_post_code.h
+#include southbridge/amd/cs5536/cs5536.h
+
+#define POST_CODE(x) outb(x, 0x80)
+#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
+
+#include southbridge/amd/cs5536/cs5536_early_smbus.c
+#include southbridge/amd/cs5536/cs5536_early_setup.c
+#include superio/winbond/w83627hf/w83627hf_early_serial.c
+
+static inline int spd_read_byte(unsigned int device, unsigned int address)
+{
+ return smbus_read_byte(device, address);
+}
+
+#define ManualConf 1 /* Do automatic strapped PLL config */
+#define PLLMSRhi 0x059C /* CPU and GLIU mult/div 500/400*/
+#define PLLMSRhi 0x049C /* CPU and GLIU mult/div 500/333*/
+#define PLLMSRhi 0x039C /* CPU and GLIU mult/div 500/266*/
+//0x059C |0101 1|0|01 110|0
+/* Hold Count - how long we will sit in reset */
+#define PLLMSRlo 0x00DE6000
+
+#define DIMM0 0xA0
+#define DIMM1 0xA2
+#include northbridge/amd/lx/raminit.h
+#include northbridge/amd/lx/pll_reset.c
+#include northbridge/amd/lx/raminit.c
+#include sdram/generic_sdram.c
+#include cpu/amd/model_lx/cpureginit.c
+#include cpu/amd/model_lx/syspreinit.c
+
+static void msr_init(void)
+{
+ msr_t msr;
+
+ /* Setup access to the cache for under 1MB. */
+ msr.hi = 0x24fffc02;
+ msr.lo = 0x1000A000;/* 0-A write back */
+ wrmsr(CPU_RCONF_DEFAULT, msr);
+
+ msr.hi = 0x0; /* Write back */
+ msr.lo = 0x0;
+ wrmsr(CPU_RCONF_A0_BF, msr);
+ wrmsr(CPU_RCONF_C0_DF, msr);
+ wrmsr(CPU_RCONF_E0_FF, msr);
+
+ /* Setup access to the cache for under 640K. Note MC not setup yet. */
+ msr.hi = 0x2000;
+ msr.lo = 0xfff80;
+ wrmsr(MSR_GLIU0 + 0x20, msr);
+
+ msr.hi = 0x2000;
+ msr.lo = 0x80fffe0;
+ wrmsr(MSR_GLIU0 + 0x21, msr);
+
+ msr.hi = 0x2000;
+ msr.lo = 0xfff80;
+ wrmsr(MSR_GLIU1 + 0x20, msr);
+
+ msr.hi = 0x2000;
+ msr.lo = 0x80fffe0;
+ wrmsr(MSR_GLIU1 + 0x21, msr);
+}
As this function is exactly the same for this board (and DB800), is it
possible that it's not really board-specific anyway? If so, it should
be moved to a global location in the chipset code.
+
+static void mb_gpio_init(void)
+{
+ /* Early mainboard specific GPIO setup. */
+}
+
+void cache_as_ram_main(void)
+{
+ POST_CODE(0x01);
+
+ static const struct mem_controller memctrl[] = {
+
Re: [LinuxBIOS] patch: alix1c support for v3
On Sun, Nov 25, 2007 at 07:07:42PM -0800, ron minnich wrote:
try again.
Yep, works now. Committed as r521 with some coding style fixes etc.
+int main(void)
+{
+ u8 smb_devices[] = {
+ DIMM0, DIMM1
+ };
+
+ post_code(POST_START_OF_MAIN);
POST_START_OF_MAIN, and...
+void hardware_stage1(void)
+{
+ post_code(POST_START_OF_MAIN);
... POST_START_OF_MAIN again.
Shouldn't those be different?
It's in every board. We have a problem here. Any ideas welcome, but I
would rather not hold up this commit since it just follows the pattern
of other boards; we need to fix them all.
Yep.
I think something line POST_START_OF_MAIN / POST_START_OF_HARDWARE_STAGE1
makes sense? The two values must be different, of course.
Index: mainboard/pcengines/alix1c/cmos.layout
===
--- mainboard/pcengines/alix1c/cmos.layout(revision 0)
+++ mainboard/pcengines/alix1c/cmos.layout(revision 0)
Add the common license header to this file, please.
no other cmos.layout has it. Let's get a template and apply them all,
but I don't want to hold this specific board up when we need a general
fix.
Is this (or does it have to be) board-specific anyway? Everybody just
keeps blindly copying it from board to board... Why not have a common
file which each board uses per default, _unless_ it's overridden in dts
for a specific board which needs/wants a different setup?
Please don't hardcode POST codes, add them aѕ #defines in post_code.h
and document them (i.e. in which situation it is supposed to be used).
uh oh. There's only one entry in post_code.h :-)
Yeah, this is a TODO ;)
we need to sync up the doc and post_code.h
No, post_code.h _is_ the single place for the documentation (or rather
it will be).
how about we commit this and take 3 action items:
1. fix up post_code.h
Yep.
2. Fix all cmos.layout files with license headers
Move one generic file somewhere globally, use that for all boards,
unless overridden.
3. fix all main.c and stage1.c to use diffferent post code entries.
Yep.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Board support
On Mon, Nov 26, 2007 at 12:12:14PM +0100, Klaus Stammermann wrote: Hi The bios of my MINI-ITX board from VIA is booting too slow. So I am looking for an alternative bios and found this project. But my board is not listed at supported motherboard list. I am using an VIA EPIA ME6000G (NB CLE266, SB VT8235). Is it possible to run linuxBIOS on this board? I think so, the components are supported AFAIK. Please post the output of 'lspci -tvnn' and 'superiotool -dV' from the board. Also, is your BIOS chip in a socket or soldered on the board? Please also run 'flashrom -V' to check if flashrom supports your board (and post the output here). If you have a backup/spare BIOS chip you can try flashing the epia-m target and see how it goes. Do _not_ do this if you don't have a verified backup ROM chip with your original vendor BIOS! HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] v3: Refactoring, northbridgelib.c
See patch.
Factor out common code. In v2 98% of all northbridges do exactly the
same thing (in these functions), thus refactor. It's easy to override
the common functions if a northbridge needs slightly different ones
(I think K8 will, for example).
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Factor out common functions which almost all northbridges share
into lib/northbridgelib.c.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: include/northbridgelib.h
===
--- include/northbridgelib.h (Revision 0)
+++ include/northbridgelib.h (Revision 0)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include device/device.h
+
+void pci_domain_read_resources(struct device *dev);
+void ram_resource(struct device *dev, unsigned long index,
+ unsigned long basek, unsigned long sizek);
+unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max);
Index: lib/northbridgelib.c
===
--- lib/northbridgelib.c (Revision 0)
+++ lib/northbridgelib.c (Revision 0)
@@ -0,0 +1,92 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include types.h
+#include console.h
+#include device/device.h
+#include device/pci.h
+
+/**
+ * Set resources for the PCI domain.
+ *
+ * A PCI domain contains the I/O and memory resource address space below it.
+ * Set up basic global ranges for I/O and memory. Allocation of sub-resources
+ * draws on these top-level resources in the usual hierarchical manner.
+ *
+ * @param dev The northbridge device.
+ */
+void pci_domain_read_resources(struct device *dev)
+{
+ struct resource *res;
+
+ /* Initialize the system-wide I/O space constraints. */
+ res = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+ res-limit = 0xUL;
+ res-flags =
+ IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+ /* Initialize the system-wide memory resources constraints. */
+ res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+ res-limit = 0xULL;
+ res-flags =
+ IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
+/**
+ * Create a RAM resource, by taking the passed-in size and creating
+ * a resource record.
+ *
+ * @param dev The device.
+ * @param index A resource index.
+ * @param basek Base memory address in KB.
+ * @param sizek Size of memory in KB.
+ */
+void ram_resource(struct device *dev, unsigned long index,
+ unsigned long basek, unsigned long sizek)
+{
+ struct resource *res;
+
+ if (!sizek)
+ return;
+
+ res = new_resource(dev, index);
+ res-base = ((resource_t) basek) 10; /* Convert to bytes. */
+ res-size = ((resource_t) sizek) 10; /* Convert to bytes. */
+ res-flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE |
+ IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
+
+ printk(BIOS_SPEW, Adding RAM resource (%lld bytes)\n, res-size);
+}
+
+/**
+ * Support for scan bus from the tippy top -- i.e. the PCI domain,
+ * not the 0:0.0 device.
+ *
+ * This function works for almost all chipsets (AMD K8 is the exception).
+ *
+ * @param dev The PCI domain device.
+ * @param max Maximum number of devices to scan.
+ * @return TODO
+ */
+unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max)
+{
+ /* There is only one link
Re: [LinuxBIOS] Drop Bitworks IMS board
On Mon, Nov 26, 2007 at 04:11:02PM -0700, Jordan Crouse wrote: On 14/11/07 00:28 +0100, Peter Stuge wrote: On Tue, Nov 13, 2007 at 03:47:07PM +0100, Uwe Hermann wrote: Drop the unfinished, non-working Bitworks IMS board. Richard? Ok with you? I asked him on IRC and he said OK. Acked-by: Jordan Crouse [EMAIL PROTECTED] Thanks, r2988. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] superiotool: Use 'static const' instead of 'const static'
On Wed, Oct 24, 2007 at 09:57:34PM +0200, Uwe Hermann wrote: Use the preferred order of 'static const' instead of 'const static'. This is the common style in both Linux as well as in LinuxBIOS. For reference, this is r2922. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: improve LAR comments, fix possible access to uninitialized memory
On Tue, Oct 16, 2007 at 08:42:42PM +0200, Carl-Daniel Hailfinger wrote: Acked-by: Uwe Hermann [EMAIL PROTECTED] Thanks, will fix and commit. This was r506. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] superiotool - dump support for fdc37c672
On Sat, Oct 06, 2007 at 04:27:33PM -0400, Robinson Tryon wrote: Signed-off-by: Robinson P. Tryon [EMAIL PROTECTED] Thanks, r2986 with some small changes. Sorry for the delay. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] patch: alix1c support for v3
On Sun, Nov 25, 2007 at 12:45:29PM -0800, ron minnich wrote:
This builds.
Not yet:
HOSTCC build/util/kconfig/zconf.tab.o
HOSTCC build/util/kconfig/mconf
mainboard/Kconfig:61: can't open file mainboard/pcengines/Kconfig
make: *** [menuconfig] Error 1
The fix should be easy though. You probably forgot to 'svn add' the
Kconfig file mainboard/pcengines/Kconfig.
Please repost the full patch.
It also includes some additional posts for geode setup which ought to be
useful.
This is unrelated and should probably be in an extra patch.
Index: mainboard/Kconfig
===
--- mainboard/Kconfig (revision 518)
+++ mainboard/Kconfig (working copy)
@@ -47,12 +47,18 @@
help
Select this option for various system emulators, such as QEMU.
+config VENDOR_PCENGINES
+ bool PC Engines
+ help
+ Select this option for PC Engines systems
Add a full stop to the help text, please.
+
endchoice
source mainboard/adl/Kconfig
source mainboard/amd/Kconfig
source mainboard/artecgroup/Kconfig
source mainboard/emulation/Kconfig
+source mainboard/pcengines/Kconfig
choice
prompt ROM chip size
Index: mainboard/pcengines/alix1c/Kconfig
===
--- mainboard/pcengines/alix1c/Kconfig(revision 0)
+++ mainboard/pcengines/alix1c/Kconfig(revision 0)
@@ -0,0 +1,46 @@
+##
+## This file is part of the LinuxBIOS project.
+##
+## Copyright (C) 2007 coresystems GmbH
+## (Written by Stefan Reinauer [EMAIL PROTECTED] for coresystems GmbH)
Ron Minnich?
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+##
+
+config MAINBOARD_NAME
+ string
+ default pcengines/alix1c
+ depends BOARD_PCENGINES_ALIX1C
+ help
+ This is the default mainboard name.
+
+config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
+ hex
+ # TODO: Fix PCI ID.
+ # PC Engines has no PCI vendor ID. Now what?
Good point. I think we need to improve this in LinuxBIOS anyway.
In v2 we currently have only one such ID in Options.lb which is then
used for _all_ devices in the system (if it's used at all).
The correct thing would be to allow an override of the ID for each
PCI device, per-board (via entries in the dts, IMHO).
+ default 0x1022
+ depends BOARD_AMD_NORWICH
+ help
+ Mainboard specific PCI subsystem vendor ID.
+
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+ hex
+ # TODO: Fix PCI ID.
+ # PC Engines has no PCI vendor ID. Now what?
+ default 0x2323
+ depends BOARD_AMD_NORWICH
+ help
+ Mainboard specific PCI subsystem device ID.
For now I'd say just drop the entries here, the code checks via #ifdef
if they're defined and does nothing if they're not...
+int main(void)
+{
+ u8 smb_devices[] = {
+ DIMM0, DIMM1
+ };
+
+ post_code(POST_START_OF_MAIN);
POST_START_OF_MAIN, and...
+void hardware_stage1(void)
+{
+ post_code(POST_START_OF_MAIN);
... POST_START_OF_MAIN again.
Shouldn't those be different?
+/{
+ enabled;
+ mainboard-vendor = PC Engines;
+ mainboard-name = Alix 1C;
ALIX1.C
Index: mainboard/pcengines/alix1c/cmos.layout
===
--- mainboard/pcengines/alix1c/cmos.layout(revision 0)
+++ mainboard/pcengines/alix1c/cmos.layout(revision 0)
Add the common license header to this file, please.
Index: arch/x86/geodelx/stage0.S
===
--- arch/x86/geodelx/stage0.S (revision 518)
+++ arch/x86/geodelx/stage0.S (working copy)
@@ -183,6 +183,7 @@
movw%ax, %fs
movw%ax, %gs
+ port80_post(0x02)
Please don't hardcode POST codes, add them aѕ #defines in post_code.h
and document them (i.e. in which situation it is supposed to be used).
@@ -364,6 +379,8 @@
outb%al, $0x80
DCacheSetupBad:
+movb$0xFF, %al
+outb%al, $0x80
Why this?
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
[LinuxBIOS] [PATCH] v3: Constify structs
See patch.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Constify structs which can be const.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: include/device/device.h
===
--- include/device/device.h (Revision 518)
+++ include/device/device.h (Arbeitskopie)
@@ -270,7 +270,7 @@
resource_t align_up(resource_t val, unsigned long gran);
resource_t align_down(resource_t val, unsigned long gran);
-extern struct device_operations default_dev_ops_root;
+extern const struct device_operations default_dev_ops_root;
extern int id_eq(struct device_id *id1, struct device_id *id2);
void root_dev_read_resources(struct device * dev);
Index: include/arch/x86/pci_ops.h
===
--- include/arch/x86/pci_ops.h (Revision 518)
+++ include/arch/x86/pci_ops.h (Arbeitskopie)
@@ -17,11 +17,11 @@
#ifndef ARCH_X86_PCI_OPS_H
#define ARCH_X86_PCI_OPS_H
-extern struct pci_bus_operations pci_cf8_conf1;
-extern struct pci_bus_operations pci_cf8_conf2;
+extern const struct pci_bus_operations pci_cf8_conf1;
+extern const struct pci_bus_operations pci_cf8_conf2;
#if defined(CONFIG_MMCONF_SUPPORT) (CONFIG_MMCONF_SUPPORT==1)
-extern struct pci_bus_operations pci_ops_mmconf;
+extern const struct pci_bus_operations pci_ops_mmconf;
#endif
void pci_set_method(struct device * dev);
Index: mainboard/artecgroup/dbe61/initram.c
===
--- mainboard/artecgroup/dbe61/initram.c (Revision 518)
+++ mainboard/artecgroup/dbe61/initram.c (Arbeitskopie)
@@ -107,7 +107,7 @@
/* Hold Count - how long we will sit in reset */
#define PLLMSRlo 0x00DE
-struct wmsr {
+static const struct wmsr {
u32 reg;
struct msr msr;
} dbe61_msr[] = {
Index: mainboard/artecgroup/dbe61/stage1.c
===
--- mainboard/artecgroup/dbe61/stage1.c (Revision 518)
+++ mainboard/artecgroup/dbe61/stage1.c (Arbeitskopie)
@@ -30,7 +30,7 @@
#include southbridge/amd/cs5536/cs5536.h
#include northbridge/amd/geodelx/raminit.h
-struct wmsr {
+static const struct wmsr {
u32 reg;
struct msr msr;
} dbe61_msr[] = {
Index: mainboard/emulation/qemu-x86/vga.c
===
--- mainboard/emulation/qemu-x86/vga.c (Revision 518)
+++ mainboard/emulation/qemu-x86/vga.c (Arbeitskopie)
@@ -40,7 +40,7 @@
init_pc_keyboard(0x60, 0x64, conf);
}
-static struct device_operations qemuvga_pci_ops_dev = {
+static const struct device_operations qemuvga_pci_ops_dev = {
.constructor = default_device_constructor,
.phase3_scan = 0,
.phase4_read_resources = pci_dev_read_resources,
@@ -51,7 +51,7 @@
.ops_pci = pci_dev_ops_pci,
};
-struct constructor qemuvga_constructors[] = {
+const struct constructor qemuvga_constructors[] = {
{.id = {.type = DEVICE_ID_PCI,
.u = {.pci = {.vendor = PCI_VENDOR_ID_CIRRUS,
.device = PCI_DEVICE_ID_CIRRUS_5446}}},
Index: device/pcie_device.c
===
--- device/pcie_device.c (Revision 518)
+++ device/pcie_device.c (Arbeitskopie)
@@ -57,11 +57,11 @@
}
/** Default device operations for PCI Express bridges. */
-static struct pci_operations pcie_bus_ops_pci = {
+static const struct pci_operations pcie_bus_ops_pci = {
.set_subsystem = 0,
};
-struct device_operations default_pcie_ops_bus = {
+const struct device_operations default_pcie_ops_bus = {
.read_resources = pci_bus_read_resources,
.set_resources= pci_dev_set_resources,
.enable_resources = pci_bus_enable_resources,
Index: device/cardbus_device.c
===
--- device/cardbus_device.c (Revision 518)
+++ device/cardbus_device.c (Arbeitskopie)
@@ -242,7 +242,7 @@
return max;
}
-struct device_operations default_cardbus_ops_bus = {
+const struct device_operations default_cardbus_ops_bus = {
.read_resources = cardbus_read_resources,
.set_resources= pci_dev_set_resources,
.enable_resources = cardbus_enable_resources,
Index: device/root_device.c
===
--- device/root_device.c (Revision 518)
+++ device/root_device.c (Arbeitskopie)
@@ -216,7 +216,7 @@
* own ops in (e.g.) the mainboard, and initialize it in the dts in the
* mainboard directory.
*/
-struct device_operations default_dev_ops_root = {
+const struct device_operations default_dev_ops_root = {
.phase4_read_resources = root_dev_read_resources,
.phase4_set_resources= root_dev_set_resources,
.phase5_enable_resources = root_dev_enable_resources,
Index: device/hypertransport.c
===
--- device/hypertransport.c (Revision 518)
+++ device
[LinuxBIOS] [PATCH] v3: Various cleanups
See patch.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Various cleanups and cosmetic fixes.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: Kconfig
===
--- Kconfig (Revision 518)
+++ Kconfig (Arbeitskopie)
@@ -101,20 +101,24 @@
depends EXPERT
default n
help
- Until now, LinuxBIOS has used elf for the payload. There are many problems
- this, not least being the inefficiency -- the ELF has to be decompressed to
- memory and then the segments have to be copied. Plus, lar can't see the segments
- in the elf -- to see all segments, you have to extract the elf and run readelf on it.
- There are problems with collisions of the decompressed ELF location in memory
- and the segment locations in memory.
- Finally, validation of the ELF is done at run time, once you have flashed the
- FLASH and rebooted the machine. Boot time is really not the time you want to find
- out your ELF payload is broken.
- With this option, LinuxBIOS will direct lar to break each elf segment into a LAR
- entry. ELF will not be used at all. Note that (for now) LinuxBIOS is backward
- compatible -- if you put an ELF payload in, LinuxBIOS can still parse it. We hope
- to remove ELF entirely in the future.
+ Until now, LinuxBIOS has used ELF for the payload. There are many
+ problems with this, not least being the inefficiency -- the ELF has
+ to be decompressed to memory and then the segments have to be
+ copied. Plus, lar can't see the segments in the ELF -- to see all
+ segments, you have to extract the ELF and run readelf on it.
+ There are problems with collisions of the decompressed ELF
+ location in memory and the segment locations in memory.
+ Finally, validation of the ELF is done at run time, once you have
+ flashed the FLASH and rebooted the machine. Boot time is really
+ not the time you want to find out your ELF payload is broken.
+
+ With this option, LinuxBIOS will direct lar to break each ELF
+ segment into a LAR entry. ELF will not be used at all. Note that
+ (for now) LinuxBIOS is backward compatible -- if you put an ELF
+ payload in, LinuxBIOS can still parse it. We hope to remove ELF
+ entirely in the future.
+
config PAYLOAD_ELF
bool An ELF executable payload file
help
Index: mainboard/adl/msm800sev/initram.c
===
--- mainboard/adl/msm800sev/initram.c (Revision 518)
+++ mainboard/adl/msm800sev/initram.c (Arbeitskopie)
@@ -19,6 +19,7 @@
*/
#define _MAINOBJECT
+
#include types.h
#include lib.h
#include console.h
@@ -33,9 +34,11 @@
#include southbridge/amd/cs5536/cs5536.h
#include northbridge/amd/geodelx/raminit.h
-#define MANUALCONF 0 /* Do automatic strapped PLL config */
-#define PLLMSRHI 0x1490 /* manual settings for the PLL */
+#define MANUALCONF 0 /* Do automatic strapped PLL config. */
+
+#define PLLMSRHI 0x1490 /* Manual settings for the PLL */
#define PLLMSRLO 0x0230
+
#define DIMM0 ((u8) 0xA0)
#define DIMM1 ((u8) 0xA2)
@@ -52,10 +55,10 @@
sdram_set_spd_registers(DIMM0, DIMM1);
sdram_enable(DIMM0, DIMM1);
- /* Check low memory */
- //ram_check(0x, 640*1024);
+ /* Check low memory. */
+ /* ram_check(0, 640 * 1024); */
- /* Switch from Cache as RAM to real RAM */
+ /* Switch from Cache as RAM to real RAM. */
printk(BIOS_SPEW, Before wbinvd\n);
__asm__(wbinvd\n);
printk(BIOS_SPEW, After wbinvd\n);
Index: mainboard/adl/msm800sev/stage1.c
===
--- mainboard/adl/msm800sev/stage1.c (Revision 518)
+++ mainboard/adl/msm800sev/stage1.c (Arbeitskopie)
@@ -32,10 +32,10 @@
#include southbridge/amd/cs5536/cs5536.h
#include superio/winbond/w83627hf/w83627hf.h
-#define SERIAL_DEV W83627HF_SP1
-#define SERIAL_IOBASE 0x3f8
+#define SERIAL_DEV W83627HF_SP1
+#define SERIAL_IOBASE 0x3f8
-/* printk will not yet output anything */
+/* printk() will not yet output anything. */
void hardware_stage1(void)
{
@@ -46,9 +46,9 @@
cs5536_stage1();
- /* NOTE: must do this AFTER the early_setup!
- * it is counting on some early MSR setup
- * for cs5536
+ /*
+ * NOTE: Must do this AFTER the early_setup! It is counting on some
+ * early MSR setup for the CS5536.
*/
cs5536_disable_internal_uart();
w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE);
Index: mainboard/amd/norwich/initram.c
===
--- mainboard/amd/norwich/initram.c (Revision 518)
+++ mainboard/amd/norwich/initram.c (Arbeitskopie)
@@ -31,51 +31,46 @@
#include amd_geodelx.h
#include northbridge/amd/geodelx/raminit.h
-#define MANUALCONF 0 /* Do automatic strapped PLL config */
-#define PLLMSRHI 0x1490 /* manual settings for the PLL */
+#define MANUALCONF 0 /* Do automatic
Re: [LinuxBIOS] [PATCH] Add support for the ASUS MEW-AM
On Fri, Nov 23, 2007 at 11:21:52AM +0100, Stefan Reinauer wrote: * Uwe Hermann [EMAIL PROTECTED] [071122 16:53]: Add support for the ASUS MEW-AM board. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Acked-by: Stefan Reinauer [EMAIL PROTECTED] Thanks, r2980. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: Move string.h contents to string.c
On Fri, Nov 23, 2007 at 11:22:40AM +0100, Stefan Reinauer wrote: * Uwe Hermann [EMAIL PROTECTED] [071121 21:07]: Move the code from strings.h to a C file. We should really avoid to have code in header files. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Have you compared code size before and after this change? No, size was not the main motivation behind this. I doubt there will be a _huge_ difference, though. Acked-by: Stefan Reinauer [EMAIL PROTECTED] Thanks, r518. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] GIGABYTE GA-2761GXDK
On Thu, Nov 22, 2007 at 05:46:06PM +0800, 蔡明耀 (my_tsai) wrote: Looks good, but why disable PS/2 keyboard and mouse? Aren't these connectors available at all on the board or should the keyboard/mouse init be done by the southbridge (there is some code in *_lpc.c)? There is no connector and pin available on board. So it didn't need any resource. OK, makes sense. I updated the comments in Config.lb a bit to reflect that. http://tracker.linuxbios.org/trac/LinuxBIOS/changeset/2978 Attachment is the board's picture. Nice, thanks! Are we allowed to put the picture into the wiki with a free-ish license (e.g. GPL, Creative Commons, BSD, public domain, or something like that)? Now I fill the current status I am certain. Thanks, wiki updated. There is a identical board I have deliverd for Ron Minnich. We can check it with him. Yep, Ron, please feel free to update the table with whatever you can verify/test that it works. http://linuxbios.org/GIGABYTE_GA-2761GXDK_Build_Tutorial Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] Superiotool dump: SMSC LPC47B27x
This is from the ASUS MEW-AM, rev. 1.01. superiotool r2977 Found SMSC LPC47B27x (id=0x51, rev=0x01) at 0x2e Register dump: idx 03 20 21 22 23 24 26 27 28 2a 2b 2c 2d 2e 2f val 00 51 01 39 00 44 2e 00 00 00 00 00 00 00 00 def RR 51 NA 00 00 04 MM MM RR NA NA NA NA NA NA LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0c 00 ff 00 00 def 00 03 f0 06 02 0e 00 ff 00 00 LDN 0x03 (Parallel port) idx 30 60 61 70 74 f0 f1 val 01 03 78 07 04 39 00 def 00 00 00 00 04 3c 00 LDN 0x04 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 00 00 00 00 00 LDN 0x05 (COM2) idx 30 60 61 62 63 70 74 f0 f1 f2 val 01 02 f8 00 00 03 04 00 02 03 def NA 00 00 00 00 00 04 00 02 03 LDN 0x07 (Keyboard) idx 30 70 72 f0 val 01 01 0c 00 def 00 00 00 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 00 00 LDN 0x0a (Power-management events (PME)) idx 30 60 61 f0 f1 val 00 06 00 00 00 def 00 00 00 NA NA LDN 0x0b (MIDI port (MPU-401)) idx 30 60 61 70 val 00 03 30 05 def 00 03 30 05 Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] Add support for the ASUS MEW-AM
See patch. Status table is already available at http://linuxbios.org/ASUS_MEW-AM_Build_Tutorial The board boots to a Linux console and most stuff already works fine. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org Add support for the ASUS MEW-AM board. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Index: src/mainboard/asus/mew-am/Config.lb === --- src/mainboard/asus/mew-am/Config.lb (Revision 0) +++ src/mainboard/asus/mew-am/Config.lb (Revision 0) @@ -0,0 +1,144 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 Uwe Hermann [EMAIL PROTECTED] +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE) +else + default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) + default ROM_SECTION_OFFSET = 0 +end +default CONFIG_ROM_PAYLOAD_START = (0x - ROM_SIZE ++ ROM_SECTION_OFFSET + 1) +default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) +default _ROMBASE = (CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE) +default XIP_ROM_SIZE = 64 * 1024 +default XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE) +arch i386 end +driver mainboard.o +if HAVE_PIRQ_TABLE + object irq_tables.o +end +makerule ./failover.E + depends $(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc + action ./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@ +end +makerule ./failover.inc + depends $(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc + action ./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@ +end +makerule ./auto.E + # depends $(MAINBOARD)/auto.c option_table.h ./romcc + depends $(MAINBOARD)/auto.c ./romcc + # Note: The -mcpu=p2 is important, or else... 'too few registers'. + action ./romcc -mcpu=p2 -E -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@ +end +makerule ./auto.inc + # depends $(MAINBOARD)/auto.c option_table.h ./romcc + depends $(MAINBOARD)/auto.c ./romcc + # Note: The -mcpu=p2 is important, or else... 'too few registers'. + action ./romcc -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@ +end +mainboardinit cpu/x86/16bit/entry16.inc +mainboardinit cpu/x86/32bit/entry32.inc +ldscript /cpu/x86/16bit/entry16.lds +ldscript /cpu/x86/32bit/entry32.lds +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/reset16.inc + ldscript /cpu/x86/16bit/reset16.lds +else + mainboardinit cpu/x86/32bit/reset32.inc + ldscript /cpu/x86/32bit/reset32.lds +end +mainboardinit arch/i386/lib/cpu_reset.inc +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds +if USE_FALLBACK_IMAGE + ldscript /arch/i386/lib/failover.lds + mainboardinit ./failover.inc +end +mainboardinit cpu/x86/fpu/enable_fpu.inc +mainboardinit cpu/x86/mmx/enable_mmx.inc +mainboardinit ./auto.inc +mainboardinit cpu/x86/mmx/disable_mmx.inc + +dir /pc80 +config chip.h + +# TODO: On-board graphics. +chip northbridge/intel/i82810 # Northbridge + device apic_cluster 0 on # APIC cluster +chip cpu/intel/socket_PGA370 # CPU + device apic 0 on end # APIC +end + end + device pci_domain 0 on # PCI domain +device pci 0.0 on end # Graphics Memory Controller Hub (GMCH) +device pci 1.0 on end # Chipset Graphics Controller (CGC) +chip southbridge/intel/i82801xx # Southbridge + device pci 1e.0 on end # PCI bridge + device pci 1f.0 on # ISA bridge +chip superio/smsc/smscsuperio # Super I/O + device pnp 2e.0 on # Floppy +io 0x60 = 0x3f0 +irq 0x70 = 6 +drq 0x74 = 2 + end + device pnp 2e.3 on # Parallel port +io 0x60 = 0x378 +irq 0x70 = 7 +drq 0x74 = 4 + end + device pnp 2e.4 on # COM1 +io 0x60 = 0x3f8 +irq 0x70 = 4 + end + device pnp 2e.5 on # COM2 / IR +io 0x60 = 0x2f8 +irq 0x70 = 3 + end + device pnp 2e.7 on # PS/2 keyboard / mouse +io 0x60 = 0x60 +io
Re: [LinuxBIOS] Superiotool dump: SMSC LPC47B27x
On Thu, Nov 22, 2007 at 04:13:31PM +0100, Uwe Hermann wrote: This is from the ASUS MEW-AM, rev. 1.01. Same box, but this time the current LinuxBIOS dump: superiotool r2977 Found SMSC LPC47B27x (id=0x51, rev=0x01) at 0x2e Register dump: idx 03 20 21 22 23 24 26 27 28 2a 2b 2c 2d 2e 2f val 00 51 01 7d 00 04 2e 00 00 00 00 00 00 00 00 def RR 51 NA 00 00 04 MM MM RR NA NA NA NA NA NA LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0e 00 ff 00 00 def 00 03 f0 06 02 0e 00 ff 00 00 LDN 0x03 (Parallel port) idx 30 60 61 70 74 f0 f1 val 01 03 78 07 04 3c 00 def 00 00 00 00 04 3c 00 LDN 0x04 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 00 00 00 00 00 LDN 0x05 (COM2) idx 30 60 61 62 63 70 74 f0 f1 f2 val 01 02 f8 00 00 03 04 00 02 03 def NA 00 00 00 00 00 04 00 02 03 LDN 0x07 (Keyboard) idx 30 70 72 f0 val 01 01 0c 00 def 00 00 00 00 LDN 0x09 (Game port) idx 30 60 61 val 01 02 01 def 00 00 00 LDN 0x0a (Power-management events (PME)) idx 30 60 61 f0 f1 val 01 06 00 00 00 def 00 00 00 NA NA LDN 0x0b (MIDI port (MPU-401)) idx 30 60 61 70 val 01 03 30 05 def 00 03 30 05 Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: fix compilation due to multiple definitions of printk
On Thu, Nov 22, 2007 at 09:44:03PM +0100, Carl-Daniel Hailfinger wrote: The introduction of the _SHARED macros had one flaw: If multiple files had _SHARED defined during compilation, each of them would contain an assignment of stage0_printk to *printk. During linking, this caused errors as multiple definitions of printk existed. Make sure _SHARED alone gives you only the printk prototype, and iff _MAINOBJECT is defined as well, include the assignment. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Great, thanks a lot! Committed in r516, and I added the commit message as comment too, it's very useful to understand what's going on in that file IMO. I tested this and can confirm that all v3 targets build fine now. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] v3: fix compilation due to multiple definitions of printk
On Fri, Nov 23, 2007 at 12:14:43AM +0100, Stefan Reinauer wrote: * Stefan Reinauer [EMAIL PROTECTED] [071123 00:04]: * Carl-Daniel Hailfinger [EMAIL PROTECTED] [071122 21:44]: The introduction of the _SHARED macros had one flaw: If multiple files had _SHARED defined during compilation, each of them would contain an assignment of stage0_printk to *printk. During linking, this caused errors as multiple definitions of printk existed. Make sure _SHARED alone gives you only the printk prototype, and iff _MAINOBJECT is defined as well, include the assignment. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] I like it, but I suggest to simplify the code further. Uwe was faster. So here's the diff without Carl-Daniel's patch it gets rid of the per-file rules for initram code completely. Very nice! Patch is Signed-off-by: Stefan Reinauer [EMAIL PROTECTED] Acked-by: Uwe Hermann [EMAIL PROTECTED] I think we should go even further and specify the INITRAM_SOURCE instead of INITRAM_OBJ because those are the files we care about. (And it will make proper dependencies easier at some point) Yeah, sounds good. +# ram initialization code can not be linked at a specific address, ram - RAM Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] From slashdot - a company possibly using linuxbios.
On Fri, Nov 16, 2007 at 11:43:30AM -0500, Robert Vogel wrote: Well...yes there is a reason the GA-M57SLI doesn't really work for me. To see why take a look at Ward's tutorial at http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial The obstacles are obvious from the tutorial. Not really. Do you refer to the required hardware hacking? Yes, that's an ugly obstacle IMO, but there are a few other modern boards which are supported and which have a standard socketed ROM which doesn't require any hardware hacking at all. E.g. MSI MS-7260 (K9N Neo), ASUS A8N-E, ASUS A8V-E SE, and others. http://linuxbios.org/Supported_Motherboards http://linuxbios.org/MSI_MS-7260_Build_Tutorial http://linuxbios.org/ASUS_A8N-E_Build_Tutorial http://linuxbios.org/ASUS_A8V-E_SE_Build_Tutorial HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] small fix for iei/juki-511p
On Wed, Nov 21, 2007 at 03:25:32PM +0500, Nikolay Petukhov wrote: Hm, why is this required here? Is it necessary for all GX1/CS5530 boards? If so it should be done in the CS5530 code, I think. Why doesn't the usual copy_pirq_routing_table() suffice here? if kernel builded with Juergen Beisert's patch than no need in it. OK, can you please rewrite this and add it to the generic GX1 code, with a config option for Options.lb, so that it can be overridden per-board? It might be useful to have this fix in, so that you can use stock kernels and you don't have to patch them (even though the correct thing would be to fix the kernel itself, but it seems unlikely that this fix will go into mainline anytime soon). Looks good otherwise, will commit soon. Btw, does this code still work fine for the ROCKY-512 as it seems to have done before? Yes, ROCKY-512 is too work fine. Great. Also, can you please create a status table in the wiki for this board? See http://linuxbios.org/GIGABYTE_GA-2761GXDK_Build_Tutorial for an example. Work in progress. Great, thanks! Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] DFI LANPARTY nF4 SLI-DR superiotool lspci.
On Wed, Nov 21, 2007 at 09:05:01AM -0800, ron minnich wrote:
On Nov 21, 2007 12:37 AM, Jerome Ibanes [EMAIL PROTECTED] wrote:
In set_Trwt():
if ((clocks DTH_TRWT_MIN) || (clocks DTH_TRWT_MAX)) {
die(Unknown Trwt);
}
It might not kill us, or destroy linuxbios as a project, if we did
something like this:
print(Trwt %x is out of range: min %x max %x\n etc. etc. etc.
Yep, definately.
Jerome, can you try two things on the board:
- Only use _one_ DIMM (if you used more for the first test), AFAIK
there are some issues with multiple DIMMs, but I'm not sure yet.
Also check the population rules in the board manual, not all slots
are allowed.
- Try a different DIMM (different speed settings, vendor, whatever).
Please report back if that changes anything.
Also, please change all '#if 0' lines in cache_as_ram_auto.c to '#if 1'
in order to enable more debugging output which might be useful, and
repost the updated minicom log then.
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Fwd: Could original VGA BIOS be responsible for long timeout before LinuxBIOS kicks in?
On Tue, Nov 20, 2007 at 08:00:14PM -0500, Corey Osgood wrote: On 11/20/07, Coquelicot [EMAIL PROTECTED] wrote: Hi all, what can be responsible for long delay before starting LinuxBIOS? I have it on VIA EPIA M-II with LB preppended by original VGA bios extracted from the original BIOS. The delay is ~20 seconds before I get first message on serial console (...In auto.c:main() messages). Correct me if I am wrong: do I need VGA BIOS at all? I want my booting No. On a head-less server for example, you usually don't care about VGA, and you can easily leave it away (no VGA blob to prepend to linuxbios.rom). Disable VGA support in LinuxBIOS with CONFIG_CONSOLE_VGA=0 in Options.lb. Linux kernel to use framebuffer but I guess that original VGA BIOS is not really needed for that, just to be able to control LB/FILO from the local console, right? Depends. LinuxBIOS itself has (AFAIK) two drivers which can enable graphics without executing any VGA blob, one for RageXL and one for Geode GX1. I'm not sure if the Linux framebuffer drivers depend on a VGA blob which has to be executed before they work. Most probably do, but maybe not all. If I had to guess, I'd say your problem is not with the VGA bios, but with ram that doesn't work quite right with the current code for the cle266. Can Yep, possible. I've seen the same effect on a box, but I can't really explain it. It happens _before_ the UART init, i.e. before the first byte of debugging output can be sent, and way before RAM init, though. Haven't looked further into it. you try a different ram stick (of a different size/timings) and see if you get the same results? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] DFI LANPARTY nF4 SLI-DR superiotool lspci.
On Wed, Nov 21, 2007 at 11:22:50AM -0800, Jerome Ibanes wrote: Ron List, print(Trwt %x is out of range: min %x max %x\n etc. etc. etc. [snip] Are you suggesting that I try to boot with less or different memory? I've Yes. Only one DIMM in the slot which the manual says it should be. noticed on the A8N-E page the following: Single DIMM support only. http://linuxbios.org/ASUS_A8N-E_Build_Tutorial Would you happen to know why or what is creating this limitation? I have Not yet, I'm investigating. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [PATCH] v3: Add missing mkdir's
This patch brings us closer to a working v3 build. The remaining thing is the printk/post_code/SHARED issue. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org Add mkdir calls to create the necessary directories. This should probably be factored out together with the rest of the lines in mainboard/* later, but for now it'll do. Signed-off-by: Uwe Hermann [EMAIL PROTECTED] Index: mainboard/adl/msm800sev/Makefile === --- mainboard/adl/msm800sev/Makefile (Revision 513) +++ mainboard/adl/msm800sev/Makefile (Arbeitskopie) @@ -36,10 +36,13 @@ $(obj)/mainboard/$(MAINBOARDDIR)/initram.o: $(src)/mainboard/$(MAINBOARDDIR)/initram.c $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/northbridge/amd/geodelx/raminit.o: $(src)/northbridge/amd/geodelx/raminit.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/southbridge/amd/cs5536/smbus_initram.o: $(src)/southbridge/amd/cs5536/smbus_initram.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/arch/x86/geodelx/geodelx.o: $(src)/arch/x86/geodelx/geodelx.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/linuxbios.initram $(obj)/linuxbios.initram.map: $(obj)/stage0.init $(obj)/stage0-prefixed.o $(INITRAM_OBJ) Index: mainboard/amd/norwich/Makefile === --- mainboard/amd/norwich/Makefile (Revision 513) +++ mainboard/amd/norwich/Makefile (Arbeitskopie) @@ -30,10 +30,13 @@ $(obj)/mainboard/$(MAINBOARDDIR)/initram.o: $(src)/mainboard/$(MAINBOARDDIR)/initram.c $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/northbridge/amd/geodelx/raminit.o: $(src)/northbridge/amd/geodelx/raminit.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/southbridge/amd/cs5536/smbus_initram.o: $(src)/southbridge/amd/cs5536/smbus_initram.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/arch/x86/geodelx/geodelx.o: $(src)/arch/x86/geodelx/geodelx.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ STAGE2_MAINBOARD_OBJ = Index: mainboard/artecgroup/dbe61/Makefile === --- mainboard/artecgroup/dbe61/Makefile (Revision 513) +++ mainboard/artecgroup/dbe61/Makefile (Arbeitskopie) @@ -34,10 +34,13 @@ $(obj)/mainboard/$(MAINBOARDDIR)/initram.o: $(src)/mainboard/$(MAINBOARDDIR)/initram.c $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/northbridge/amd/geodelx/raminit.o: $(src)/northbridge/amd/geodelx/raminit.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/southbridge/amd/cs5536/smbus_initram.o: $(src)/southbridge/amd/cs5536/smbus_initram.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/arch/x86/geodelx/geodelx.o: $(src)/arch/x86/geodelx/geodelx.c + $(Q)mkdir -p $(dir $@) $(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c $ -o $@ $(obj)/linuxbios.initram $(obj)/linuxbios.initram.map: $(obj)/stage0.init $(obj)/stage0-prefixed.o $(INITRAM_OBJ) -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
