Re: [LinuxBIOS] [PATCH] BCOM WinNET100 improvements
Uwe,
On Sunday 14 October 2007 19:10, Uwe Hermann wrote:
See patch.
Btw, do we need to (or want to) enable the SMI PCI device? I guess not
as we don't use the VSA(?) Do we need it for the VSA-less audio driver?
Btw, Juergen, can you please attach a license to your photos in the
wiki? GPL or CC or public domain, whatever. There are templates such as
{{GPL}} or {{PD-self}} etc.
How does it work? The download accepts the license only for new pictures. I
added new comments, but only the comment of the first picture revision will
be used (or at least it seems so).
Juergen
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Common code base for Intel 440BX boards
Uwe Hermann wrote:: On Sat, Oct 20, 2007 at 08:44:57PM +0200, Stefan Reinauer wrote: Please put generic 440 code in northbridge/, and not in mainboard/440-base/ Having two northbridge directories for the same northbridge sounds complex. Full ack. Northbridge-specific code belongs in src/northbridge/*. However, this is not northbridge specific code. It's more like common code which somewhat similar mainboards share. Theoretically this could include even more (non-440BX) boards which are also similar enough, but for now I concentrated on 440BX boards. Optimally there should only be a config file as the only requirement for a mainboard port. But we are not there yet, unfortunately. These kinds of unifications are false friends IMHO. Packing multiple CONFIG_BOARD_*** thingies in one board config file does not make things easier - at all. It just adds up to the complexity, and at some point, namely the migration to linuxbios v3, makes things a lot harder than they are now. Catting 3 files into one and having the C preprocessor split them up again is not making things simpler, nor cleaner, nor easier, nor less error prone. Sorry, but I think this is the wrong way to go -- NACK! If we later add non-440bx boards (e.g. 430TX or i810 or something) to the same framework, we might rename it to xyz-base (but I have no idea what a good name for xyz would be ;-) Also, I'm a bit undecided if it should be src/mainboard/common/i440bx-base or src/mainboard/i440bx-base (i.e. put the base code parts in an extra directory or not). Opinions? Uwe. -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] Common code base for Intel 440BX boards
[EMAIL PROTECTED] wrote:: Quoting Uwe Hermann [EMAIL PROTECTED]: On Sat, Oct 20, 2007 at 08:44:57PM +0200, Stefan Reinauer wrote: Please put generic 440 code in northbridge/, and not in mainboard/440-base/ Having two northbridge directories for the same northbridge sounds complex. Full ack. Northbridge-specific code belongs in src/northbridge/*. However, this is not northbridge specific code. It's more like common code which somewhat similar mainboards share. Theoretically this could include even more (non-440BX) boards which are also similar enough, but for now I concentrated on 440BX boards. If we later add non-440bx boards (e.g. 430TX or i810 or something) to the same framework, we might rename it to xyz-base (but I have no idea what a good name for xyz would be ;-) Also, I'm a bit undecided if it should be src/mainboard/common/i440bx-base or src/mainboard/i440bx-base (i.e. put the base code parts in an extra directory or not). Opinions? Uwe. Why couldn't there just be a src/northbridge/intel/common/ directory? Because there really is not much those supported chips have in common, yet. The register names are the same - their values and meaning changes. I rather prefer 5 small, clean, linear chunks of code with a duplication of 30% each, than a single big, unreadable and unmaintainable chunk that supports all kinds of machines if you set the correct configuration variables. Stefan -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] [flashrom] request for review: VT8233A support
Hello All! Looking at the lspci output I created simple patch for adding VT8233A support. Unfortunately I can't find out what flash-chip is on my mainboard (it's far away from me so I can perform only software look) but maybe someone else tests whether this patch works or not? Unfortunately guys from Via still don't answer on my request for datasheets... -- With best regards! flashrom-vt8233a-enable.diff Description: Binary data -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
[LinuxBIOS] Flashrom and superiotool on non-x86 platforms?
Hello All!
Does anybody tried to use linuxbios and LB-tools on non-x86 platforms?
There are some issues we need to fir even for compilation (not for
successful usage).
One thing I found so far is excessive usage of non-portable inb/outb
macros. For instance - inb may be emulated as folliwing:
+unsigned char inb (unsigned short int port)
+{
+ static unsigned char in = 0;
+ FILE* f = fopen (/dev/port, a);
+ if (f !=NULL){
+ if (fseek (f, port, SEEK_SET) == port){
+ fread (in, sizeof (unsigned char), 1, f);
+ fclose (f);
+ return in;
+ }
+ }
+ return ERROR;
But I need an advice - I found ppc970 branch of LinuxBIOS - who
maintains it and what's the current status of that port? Does anyone
successfully boots any non-x86 machine using LinuxBIOS?
--
With best regards!
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] [PATCH] flashrom: SPI serial flash: The sector/block erase pitfalls
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [071019 23:39]:
This patch introduces block and sector erase routines, but does not use
them yet.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Stefan Reinauer [EMAIL PROTECTED]
---
Index: util/flashrom/flash.h
===
--- util/flashrom/flash.h (Revision 2876)
+++ util/flashrom/flash.h (Arbeitskopie)
@@ -72,7 +72,7 @@
#define EON_ID 0x1C
/* EN25 chips are SPI, first byte of device id is memory type,
- second byte of device id is log(bitsize)-9 */
+ * second byte of device id is log(bitsize)-9. */
#define EN_25B05 0x2010 /* 2^19 kbit or 2^16 kByte */
#define EN_25B10 0x2011
#define EN_25B20 0x2012
@@ -82,9 +82,8 @@
#define EN_25B32 0x2016
#define MX_ID0xC2/* Macronix (MX) */
-#define MX_29F0020xB0
-/* MX25L chips are SPI, first byte of device id is memory type,
- second byte of device id is log(bitsize)-9 */
+/* MX25 chips are SPI, first byte of device id is memory type,
+ * second byte of device id is log(bitsize)-9. */
#define MX_25L5120x2010 /* 2^19 kbit or 2^16 kByte */
#define MX_25L1005 0x2011
#define MX_25L2005 0x2012
@@ -95,11 +94,22 @@
#define MX_25L6405 0x2017 /* MX25L3205{,D} */
#define MX_25L1635D 0x2415
#define MX_25L3235D 0x2416
+#define MX_29F0020xB0
#define SHARP_ID 0xB0/* Sharp */
#define SHARP_LHF00L04 0xCF
#define SST_ID 0xBF/* SST */
+/* SST25 chips are SPI, first byte of device id is memory type, second
+ * byte of device id is related to log(bitsize) at least for some chips. */
+#define SST_25WF512 0x2501
+#define SST_25WF010 0x2502
+#define SST_25WF020 0x2503
+#define SST_25WF040 0x2504
+#define SST_25VF016B 0x2541
+#define SST_25VF032B 0x254A
+#define SST_25VF040B 0x258D
+#define SST_25VF080B 0x258E
#define SST_29EE020A 0x10
#define SST_28SF040 0x04
#define SST_39SF010 0xB5
@@ -210,7 +220,7 @@
/* spi.c */
int probe_spi(struct flashchip *flash);
int it87xx_probe_spi_flash(const char *name);
-int generic_spi_command(unsigned char writecnt, unsigned char readcnt, const
unsigned char *writearr, unsigned char *readarr);
+int generic_spi_command(unsigned int writecnt, unsigned int readcnt, const
unsigned char *writearr, unsigned char *readarr);
void generic_spi_write_enable();
void generic_spi_write_disable();
int generic_spi_chip_erase(struct flashchip *flash);
Index: util/flashrom/flashchips.c
===
--- util/flashrom/flashchips.c(Revision 2876)
+++ util/flashrom/flashchips.c(Arbeitskopie)
@@ -36,7 +36,7 @@
probe_jedec, erase_chip_jedec, write_jedec},
{At29C020,ATMEL_ID, AT_29C020, 256, 256,
probe_jedec, erase_chip_jedec, write_jedec},
- {Mx29f002,MX_ID, MX_29F002, 256, 64 * 1024,
+ {MX29F002,MX_ID, MX_29F002, 256, 64 * 1024,
probe_29f002, erase_29f002, write_29f002},
{MX25L4005, MX_ID, MX_25L4005, 512, 4 * 1024,
probe_spi, generic_spi_chip_erase, generic_spi_chip_write},
Index: util/flashrom/spi.c
===
--- util/flashrom/spi.c (Revision 2876)
+++ util/flashrom/spi.c (Arbeitskopie)
@@ -45,17 +45,31 @@
#define JEDEC_WRDI_OUTSIZE 0x01
#define JEDEC_WRDI_INSIZE0x00
-/* Both Chip Erase commands below should work */
-/* Chip Erase 0x60 */
+/* Chip Erase 0x60 is supported by Macronix/SST chips. */
#define JEDEC_CE_1 {0x60};
#define JEDEC_CE_1_OUTSIZE 0x01
#define JEDEC_CE_1_INSIZE0x00
-/* Chip Erase 0xc7 */
+/* Chip Erase 0xc7 is supported by EON/Macronix chips. */
#define JEDEC_CE_2 {0xc7};
#define JEDEC_CE_2_OUTSIZE 0x01
#define JEDEC_CE_2_INSIZE0x00
+/* Block Erase 0x52 is supported by SST chips. */
+#define JEDEC_BE_1 {0x52};
+#define JEDEC_BE_1_OUTSIZE 0x04
+#define JEDEC_BE_1_INSIZE0x00
+
+/* Block Erase 0xd8 is supported by EON/Macronix chips. */
+#define JEDEC_BE_2 {0xd8};
+#define JEDEC_BE_2_OUTSIZE 0x04
+#define JEDEC_BE_2_INSIZE0x00
+
+/* Sector Erase 0x20 is supported by Macronix/SST chips. */
+#define JEDEC_SE {0x20};
+#define JEDEC_SE_OUTSIZE 0x04
+#define JEDEC_SE_INSIZE 0x00
+
/* Read Status Register */
#define JEDEC_RDSR {0x05};
#define JEDEC_RDSR_OUTSIZE 0x01
@@ -144,7 +158,7 @@
whereas the IT8716F splits commands internally into address and
non-address
commands with the address in inverse wire order. That's
Re: [LinuxBIOS] [PATCH] Add K8T890CE support
===
--- Config.lb (revision 0)
+++ Config.lb (revision 0)
Missing license header.
Fixed
+static void host_enable(struct device *dev)
Would
const struct device *dev
work? It looks like dev is not being modified(?)
Perhaps yes, but lets change that later.
One empty line only between functions.
fixed.
+void pcie_init(struct device *dev)
+{
+ u8 reg;
+
+ printk_debug(Configuring PCIe PEXs\n);
Is the official name PCIe or PCI-E?
Both.
Looks very similar to above. Does it make sense to merge it somehow?
Probably not, but I figured I should ask nevertheless, just in case.
Well some bits are different. I will need to fix the init when Training fails so
this will be rewritten later.
+static struct pci_driver pcie_drvd3f3 __pci_driver = {
+ .ops = pcie_ops,
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_DEVICE_ID_VIA_K8T890CE_PEX3,
Do you have the device ID for non-CE K8T890, too? Are they different?
Would it make sense to add them, i.e. do you expect the code to
(more or less) work in that case, too?
You mean for the CF? this IDs are 100% same.
Empty line not needed.
fixed.
One empty line only.
fixed.
+ res-base = K8T890_APIC_BASE;
+ res-size = 256;
+ res-limit = res-base + res-size - 1;
+ res-align = 8;
+ res-gran = 8;
+ res-flags = IORESOURCE_MEM | IORESOURCE_FIXED |
+ IORESOURCE_STORED | IORESOURCE_ASSIGNED;
+
+ /* Add a MMCONFIG resource */
+ res = new_resource(dev, K8T890_MMCONFIG_MBAR);
+ res-size = 256 * 1024 * 1024;
Why hardcoded? Is it configurable or _must_ it be hardcoded this way?
(sorry if I already asked that)
What exactly? The BAR addr is computed dynamically.
+ * Modified for K8T890 ROM strap by Rudolf Marek
Uh, trivial (well, let say short ;-) file, so (C) Rudolf Marek should
suffice, IMHO.
Ok. But I will leave it as it is ;)
+ dump_south(dev);
+ /* bit 4 is reserved but set by AW
+ set PCI to HT outstanding requests to 3 */
+ pci_write_config8(dev, 0xa0, 0x13);
+
+ /* disable NVRAM and enable non-posted PCI writes */
+ pci_write_config8(dev, 0xa1, 0x8e);
+
+ /* nvram IO base 0xe00-0xeff but it is disabled
+ some bits are set and reserved */
+ pci_write_config8(dev, 0xa2, 0x0e);
+ /* Arbitration control, some bits are reserved */
Can you specify exactly which bits mean what and which are reversed? As
ost of us will never see the datasheets, this is going to be important
some day, I guess.
I have in plan to somehow document the code one day. some bits reserved means
the the some bits which are not documented are set to 1.
+ /* Update the desired HT LNK caps in NB too */
caps = capabilities?
Ok
+ pci_write_config8(dev, 0x80, 0xff);
+ pci_write_config8(dev, 0x81, 0xff);
+ pci_write_config8(dev, 0x82, 0xff);
+ pci_write_config8(dev, 0x83, 0x30);
Please list the registers and which bits mean what, so we can later
modify if needed without requiring the datasheet.
Ok I tried to document it somehow.
+ regm3 = 0x0;
+ /* page F + Memhole copy */
Shadow page F ?
yep fixed.
+ regm = pci_read_config8(devfun3, 0x83);
+ pci_write_config8(dev, 0x63, regm3 | (regm 0x3F));
+}
+
+static struct device_operations ctrl_ops = {
+ .read_resources = pci_dev_read_resources,
+ .set_resources = pci_dev_set_resources,
+ .enable_resources = pci_dev_enable_resources,
+ .enable = ctrl_enable,
+ .ops_pci = 0,
+};
+
+static struct pci_driver northbridge_driver __pci_driver = {
+ .ops = ctrl_ops,
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_DEVICE_ID_VIA_K8T890CE_7,
+};
Index: k8t890.h
===
--- k8t890.h(revision 0)
+++ k8t890.h(revision 0)
@@ -0,0 +1,32 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Rudolf Marek [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * 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
+ */
+
+#ifndef SOUTHBRIDGE_VIA_K8T890_H
+#define SOUTHBRIDGE_VIA_K8T890_H
SOUTHBRIDGE_VIA_K8T890_K8T890_H
fixed.
+
+/* static resources for K8T890 */
K8T890CE or all versions of it?
I support CE, CF should be very similar.
Re: [LinuxBIOS] question on lx raminit.c
Carl-Daniel Hailfinger wrote: On 20.10.2007 02:44, ron minnich wrote: I offer the following diff and a question: can the use of in these if expressions be wrong? Currently it is: if ((MIN_MOD_BANKS spd_byte) (spd_byte MAX_MOD_BANKS)) You want || because either condition should cause the error message. The current statement will never be true because (MIN_MOD_BANKS MAX_MOD_BANKS) is never true. Patch looks fine to me. Acked-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Carl-Daniel Indeed, I didn't test it with an non-supported dimm Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
