* (no subject)
From: Bob Brose @ 2005-10-03 1:00 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to fix some of the AX25 code in the 2.6 kernel and traced down
a problem to the use of a char var which was being assigned
the value of -1. On x86 when the var was compared to -1 it succeded but
on PPC it failed. So I tried a simple test:
main()
{
char atest;
atest=-1;
printf("%i,%X\n",atest,atest);
}
With GCC 3.3.5 on 2.6.14-rc1 x86 I get:
./atest
-1,FFFFFFFF
With GCC 3.3.5 on 2.6.14-rc1 PPC I get:
./atest
255,FF
If I change the declaration of atest to a signed char on PPC I get the
same result as x86.
Does this mean the char in x86 is signed and in PPC it's unsigned?
Has it always been thus?
^ permalink raw reply
* Q: signed vs unsigned char, PPC vs x86 gcc 3.3.5 compiler differences
From: Bob Brose @ 2005-10-03 2:11 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to fix some of the AX25 code in the 2.6 kernel and traced down
a problem to the use of a char var which was being assigned
the value of -1. On x86 when the var was compared to -1 it succeded but
on PPC it failed. So I tried a simple test:
main()
{
char atest;
atest=-1;
printf("%i,%X\n",atest,atest);
}
With GCC 3.3.5 on 2.6.14-rc1 x86 I get:
./atest
-1,FFFFFFFF
With GCC 3.3.5 on 2.6.14-rc1 PPC I get:
./atest
255,FF
If I change the declaration of atest to a signed char on PPC I get the
same result as x86.
Does this mean the char in x86 is signed and in PPC it's unsigned?
Has it always been thus?
^ permalink raw reply
* Re: Q: signed vs unsigned char, PPC vs x86 gcc 3.3.5 compiler differences
From: Hollis Blanchard @ 2005-10-03 2:22 UTC (permalink / raw)
To: Bob Brose; +Cc: linuxppc-dev
In-Reply-To: <20051003021129.20564.qmail@kunk.qbjnet.com>
On Oct 2, 2005, at 9:11 PM, Bob Brose wrote:
> If I change the declaration of atest to a signed char on PPC I get the
> same result as x86.
>
> Does this mean the char in x86 is signed and in PPC it's unsigned?
> Has it always been thus?
Yes, and yes. If it matters to you, you should explicitly use "signed
char" or "unsigned char"...
-Hollis
^ permalink raw reply
* Re: Q: signed vs unsigned char, PPC vs x86 gcc 3.3.5 compiler differences
From: Christopher Friesen @ 2005-10-03 5:07 UTC (permalink / raw)
To: Bob Brose; +Cc: linuxppc-dev
In-Reply-To: <20051003021129.20564.qmail@kunk.qbjnet.com>
Bob Brose wrote:
> Does this mean the char in x86 is signed and in PPC it's unsigned?
> Has it always been thus?
From K+R:
"Whether plain chars are signed or unsigned is machine-dependent, but
printable characters are always positive."
Chris
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-10-03 7:04 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <26a6f673ac9438729eccfe0c376c6b3d@embeddedalley.com>
Dan Malek wrote:
> What about just trying to boot the new kernel from PlanetCore boot rom?
I do use PlanetCore to boot the system. Basically the only funtionality
in my own custom boot loader with this board is to carry the image of
the Linux kernel, decompress, and launch it. I have disabled all the
initialisation code since it was previously written for another board,
and PlanetCore does all the initialisations anyway. I didn't care to
erase PlanetCore from the flash just yet, since I can just as well
develop the real initialisations later with the custom board.
PlanetCore itself is not usable for booting any other Linux kernel than
the pre-installed one. It just allows me to launch some launcher of the
Linux kernel... Probably it's the launcher that does the tricks to make
Linux run correctly.
> Of course, if you are doing your own boot rom and have a board to
> bring up,
> you should have invested in something like a BDI2000 long ago because
> it will
> have paid for itself many times over by the time you are done :-) It
> would have
> also allowed you to debug this problem rather quickly.
>
You are right, this would be a lot easier with a good debugger. I just
have delayed purchasing it since I wasn't previously sure if we'd use
the PowerQUICC II family or not. I already have Lauterbach for 8xx, but
the Linux community seems to prefer the BDI2000. Do you know if it fits
better in Linux development? At least it seems to be a lot less
expensive than a new Lautherbach license for the 82xx family.
^ permalink raw reply
* Re: (no subject)
From: Andreas Schwab @ 2005-10-03 7:07 UTC (permalink / raw)
To: Bob Brose; +Cc: linuxppc-dev
In-Reply-To: <20051003010039.20105.qmail@kunk.qbjnet.com>
Bob Brose <linuxppcdev@qbjnet.com> writes:
> Does this mean the char in x86 is signed and in PPC it's unsigned?
Yes.
> Has it always been thus?
Yes.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH 2/3][PPC32] PCI-X support for Yucca
From: Ruslan V. Sushko @ 2005-10-03 8:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 192 bytes --]
This patch adds PCIX support for Yucca PPC440SPe board. The patch is
implemented for Roland Dreier git tree for Yucca PPC440SPe board.
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pcix.patch --]
[-- Type: text/x-patch, Size: 6828 bytes --]
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -86,19 +86,23 @@ yucca_map_irq(struct pci_dev *dev, unsig
struct pci_controller *hose = pci_bus_to_hose(dev->bus->number);
/* PCIX */
- if (hose->index == 3) {
+ if (hose->index == 0) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
- { 81, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
+ { 49, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
};
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
- return PCI_IRQ_TABLE_LOOKUP;
+ mtdcr(DCRN_UIC_PR(UIC1),
+ mfdcr(DCRN_UIC_PR(UIC1)) & ~0x00004000); /* Set PCI interrupt
+ (EXT IRQ12) plarity
+ to Negative */
+ return PCI_IRQ_TABLE_LOOKUP;
/* PCIE0 */
- } else if (hose->index == 0) {
+ } else if (hose->index == 1) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -110,7 +114,7 @@ yucca_map_irq(struct pci_dev *dev, unsig
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
/* PCIE1 */
- } else if (hose->index == 1) {
+ } else if (hose->index == 2) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -122,7 +126,7 @@ yucca_map_irq(struct pci_dev *dev, unsig
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
/* PCIE2 */
- } else if (hose->index == 2) {
+ } else if (hose->index == 3) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -150,10 +154,123 @@ static void __init yucca_set_emacdata(vo
memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
}
+#define PCIX_READW(offset) \
+ (readw((void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEW(value, offset) \
+ (writew(value, (void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEL(value, offset) \
+ (writel(value, (void *)((u32)pcix_reg_base+offset)))
+
+static void __init
+yucca_setup_pcix(void)
+{
+ void *pcix_reg_base;
+
+ pcix_reg_base = ioremap64(PCIX0_REG_BASE, PCIX_REG_SIZE);
+
+ /* Disable all windows */
+ PCIX_WRITEL(0, PCIX0_POM0SA);
+ PCIX_WRITEL(0, PCIX0_POM1SA);
+ PCIX_WRITEL(0, PCIX0_POM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SAH);
+ PCIX_WRITEL(0, PCIX0_PIM1SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SAH);
+
+ /*
+ * Setup 512MB PLB->PCI outbound mem window
+ * (a_n000_0000->0_n000_0000)
+ * */
+ PCIX_WRITEL(0x0000000d, PCIX0_POM0LAH);
+ PCIX_WRITEL(0x80000000, PCIX0_POM0LAL);
+ PCIX_WRITEL(0x00000000, PCIX0_POM0PCIAH);
+ PCIX_WRITEL(0x80000000, PCIX0_POM0PCIAL);
+ PCIX_WRITEL(0xe0000001, PCIX0_POM0SA);
+
+ /* Setup 1GB PCI->PLB inbound memory window at 0, enable MSIs */
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAH);
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAL);
+ PCIX_WRITEL(0xc0000007, PCIX0_PIM0SA);
+ PCIX_WRITEL(0xffffffff, PCIX0_PIM0SAH);
+
+ /* Enable PCIX0 I/O, Mem, and Busmaster cycles */
+ PCIX_WRITEW(PCIX_READW(PCIX0_COMMAND) | PCI_COMMAND_MEMORY |
+ PCI_COMMAND_MASTER, PCIX0_COMMAND);
+
+ iounmap(pcix_reg_base);
+ eieio();
+}
+
+static void __init
+yucca_setup_hose(struct pci_controller *hose,
+ int lower_mem,
+ int upper_mem,
+ int cfga,
+ int cfgd,
+ u64 pcix_io_base)
+{
+ char name[20];
+
+ sprintf(name, "PCIX%d host bridge", hose->index);
+
+ hose->pci_mem_offset = YUCCA_PCIX_MEM_OFFSET;
+
+ pci_init_resource(&hose->io_resource,
+ YUCCA_PCIX_LOWER_IO,
+ YUCCA_PCIX_UPPER_IO,
+ IORESOURCE_IO,
+ name);
+
+ pci_init_resource(&hose->mem_resources[0],
+ lower_mem,
+ upper_mem,
+ IORESOURCE_MEM,
+ name);
+
+ hose->io_space.start = YUCCA_PCIX_LOWER_IO;
+ hose->io_space.end = YUCCA_PCIX_UPPER_IO;
+ hose->mem_space.start = lower_mem;
+ hose->mem_space.end = upper_mem;
+ isa_io_base =
+ (unsigned long)ioremap64(pcix_io_base, PCIX_IO_SIZE);
+ hose->io_base_virt = (void *)isa_io_base;
+
+ setup_indirect_pci(hose, cfga, cfgd);
+ hose->set_cfg_type = 1;
+}
+
+
static void __init
yucca_setup_hoses(void)
{
+ struct pci_controller *hose;
+
+ /* Configure windows on the PCI-X host bridge */
+ yucca_setup_pcix();
+
+ /* Allocate hoses for PCIX0 */
+ hose = pcibios_alloc_controller();
+ if (!hose)
+ return;
+
+ /* Setup PCIX0 */
+ hose->first_busno = 0;
+ hose->last_busno = 0xff;
+
+ yucca_setup_hose(hose,
+ YUCCA_PCIX_LOWER_MEM,
+ YUCCA_PCIX_UPPER_MEM,
+ PCIX0_CFGA,
+ PCIX0_CFGD,
+ PCIX0_IO_BASE);
+
+ hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+ ppc_md.pci_swizzle = common_swizzle;
+ ppc_md.pci_map_irq = yucca_map_irq;
}
TODC_ALLOC();
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_GT64260) += gt64260_pic.o
obj-$(CONFIG_LOPEC) += i8259.o pci_auto.o todc_time.o
obj-$(CONFIG_HDPU) += pci_auto.o
obj-$(CONFIG_LUAN) += indirect_pci.o pci_auto.o todc_time.o
+obj-$(CONFIG_YUCCA) += indirect_pci.o pci_auto.o
obj-$(CONFIG_KATANA) += pci_auto.o
obj-$(CONFIG_MV64360) += mv64360_pic.o
obj-$(CONFIG_MV64X60) += mv64x60.o mv64x60_win.o indirect_pci.o
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -64,6 +64,11 @@
#define PPC44x_PCICFG_PAGE 0x0000000900000000ULL
#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
#define PPC44x_PCIMEM_PAGE 0x0000000a00000000ULL
+#elif defined(CONFIG_440SPE)
+#define PPC44x_IO_PAGE 0x0000000400000000ULL
+#define PPC44x_PCICFG_PAGE 0x0000000C00000000ULL
+#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
+#define PPC44x_PCIMEM_PAGE 0x0000000D00000000ULL
#elif defined(CONFIG_440EP)
#define PPC44x_IO_PAGE 0x0000000000000000ULL
#define PPC44x_PCICFG_PAGE 0x0000000000000000ULL
@@ -552,12 +557,19 @@
#define PCIX1_CFGD 0x1ec00004UL
#define PCIX2_CFGD 0x2ec00004UL
+#if defined (CONFIG_440SPE)
+#define PCIX0_IO_BASE 0x0000000C08000000ULL
+#else /* !CONFIG_440SPE */
#define PCIX0_IO_BASE 0x0000000908000000ULL
#define PCIX1_IO_BASE 0x0000000908000000ULL
#define PCIX2_IO_BASE 0x0000000908000000ULL
+#endif /* CONFIG_440SPE */
+
#define PCIX_IO_SIZE 0x00010000
-#ifdef CONFIG_440SP
+#if defined (CONFIG_440SPE)
+#define PCIX0_REG_BASE 0x0000000c0ec80000ULL
+#elif defefined(CONFIG_440SP)
#define PCIX0_REG_BASE 0x000000090ec80000ULL
#else
#define PCIX0_REG_BASE 0x000000020ec80000ULL
^ permalink raw reply
* [PATCH 3/3][PPC32] MTD driver for Yucca board
From: Ruslan V. Sushko @ 2005-10-03 8:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
This patch adds MTD driver for Yucca ppc440SPe board. The patch
implemented for Roland Dreier git tree for Yucca 440SPe board
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_mtd.patch --]
[-- Type: text/x-patch, Size: 14332 bytes --]
diff --git a/arch/ppc/platforms/4xx/yucca.h b/arch/ppc/platforms/4xx/yucca.h
--- a/arch/ppc/platforms/4xx/yucca.h
+++ b/arch/ppc/platforms/4xx/yucca.h
@@ -32,12 +32,91 @@
/* External timer clock frequency */
#define YUCCA_TMR_CLK 25000000
+
+
+/* System Memory map (physical address, not effective address)
+ * Flash and other devices via EBC.
+ *
+ * This should be the same mapping as done by PIBS in the
+ * (not mandatory but ease code reading between two codes)
+ * xxx/boardlib/ebc.c
+ *
+ * depending of the switch setting off the board, the location of devices
+ * in the address map are not the same:
+ */
+/* Common definitions */
+
+#define BOARD_SMALL_FLASH_SIZE 0x100000 /* 1M */
+#define BOARD_FRAM_SIZE 0x8000
+#define BOARD_SRAM_SIZE 0x100000
+#define BOARD_OPER_FLASH_SIZE 0x400000 /* 4M */
+
+
+/* Configuration 1:
+ * the small flash and sram are placed on top (CS0)
+ * the Large flash is placed below (CS2)
+ * The FPGA and FRAM at the end (CS1)
+ * xxxx----xxxx----
+ */
+#define BOARD_CONF1_SMALL_FLASH 0x00000004FFF00000ull
+#define BOARD_CONF1_FRAM 0x00000004FF000000ull
+#define BOARD_CONF1_OPER_FLASH 0x00000004E7C00000ull
+#define BOARD_CONF1_SRAM 0x00000004E7000000ull
+
+/* Configuration 2:
+ * the small flash and sram are placed on top (CS0)
+ * but now sram before smal flash
+ * the Large flash is placed below (no change) (CS2)
+ * The FPGA and FRAM stay in same place. (CS1)
+ * xxxx----xxxx----
+ */
+#define BOARD_CONF2_OPER_FLASH 0x00000004FFC00000ull
+#define BOARD_CONF2_SRAM 0x00000004FF000000ull
+#define BOARD_CONF2_SMALL_FLASH 0x00000004E7F00000ull
+#define BOARD_CONF2_FRAM 0x00000004E7000000ull
+
+/* Configuration 3:
+ * the Large flash is placed on top, (CS0)
+ * the small flash and sram are placed below. (CS2)
+ * The FPGA and FRAM stay in same place. (CS1)
+ * xxxx----xxxx----
+ */
+#define BOARD_CONF3_SRAM 0x00000004FFF00000ull
+#define BOARD_CONF3_OPER_FLASH 0x00000004FF000000ull
+#define BOARD_CONF3_SMALL_FLASH 0x00000004E7F00000ull
+#define BOARD_CONF3_FRAM 0x00000004E7000000ull
+
+
/*
* FPGA registers
*/
#define YUCCA_FPGA_REG_BASE 0x00000004e2000000ULL
#define YUCCA_FPGA_REG_SIZE 0x24
+#define FPGA_REG10 0x10 /* Ethernet/Reset/Boot
+ configs */
+#define FPGA_REG10_ETH_MODE10 0x8000
+#define FPGA_REG10_ETH_MODE100 0x4000
+#define FPGA_REG10_ETH_MODE1000 0x2000
+#define FPGA_REG10_ETH_FORCE_DUPLEX 0x1000
+#define FPGA_REG10_LOG_RESET_ETHERNET 0x0800
+#define FPGA_REG10_ETH_AUTO_NEGO 0x0400
+#define FPGA_REG10_LOG_INT_ETH 0x0200
+#define FPGA_REG10_LOG_RESET_HISR 0x0080
+#define FPGA_REG10_LOG_RESET_DISPLAY 0x0040
+#define FPGA_REG10_LOG_RESET_SDRAM 0x0020
+#define FPGA_REG10_LOG_OPBOOT 0x0010
+#define FPGA_REG10_LOG_SRAM_BOOT 0x0008
+#define FPGA_REG10_LOG_BTBOOT 0x0004
+
+/*Boot configurations */
+#define BOARD_CONFIG_MASK (0x001C)
+#define BOARD_CONFIG_1 (0x0018)
+#define BOARD_CONFIG_2 (0x000C)
+#define BOARD_CONFIG_3 (0x0014)
+#define BOARD_BOOT_OPER_FLASH(x) (((x) & BOARD_CONFIG_MASK) == \
+ BOARD_CONFIG_2)
+
#define FPGA_REG1A 0x1a
#define FPGA_REG1A_PE0_GLED 0x8000
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -332,6 +332,14 @@ config MTD_OCOTEA
Ocotea board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
+config MTD_YUCCA
+ tristate "Flash devices mapped on IBM 440SPe Yucca"
+ depends on MTD_CFI && PPC32 && 44x && YUCCA
+ help
+ This enables access routines for the flash chips on the IBM 440SPe
+ Yucca board. If you have one of these boards and would like to
+ use the flash chips on it, say 'Y'.
+
config MTD_REDWOOD
tristate "CFI Flash devices mapped on IBM Redwood"
depends on MTD_CFI && PPC32 && 4xx && 40x && ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
obj-$(CONFIG_MTD_EBONY) += ebony.o
obj-$(CONFIG_MTD_OCOTEA) += ocotea.o
+obj-$(CONFIG_MTD_YUCCA) += yucca_flash.o
obj-$(CONFIG_MTD_BEECH) += beech-mtd.o
obj-$(CONFIG_MTD_ARCTIC) += arctic-mtd.o
obj-$(CONFIG_MTD_WALNUT) += walnut.o
diff --git a/drivers/mtd/maps/yucca_flash.c b/drivers/mtd/maps/yucca_flash.c
new file mode 100644
--- /dev/null
+++ b/drivers/mtd/maps/yucca_flash.c
@@ -0,0 +1,278 @@
+/*
+ * Mapping for Yucca user flash
+ *
+ * This was derived from the luan.c
+ *
+ * Ruslan Sushko <rsushko@ru.mvista.com>
+ * Matt Porter <mporter@mvista.com>
+ *
+ * Copyright (C) 2002-2005 MontaVista Software Inc.
+ * (C) Copyright IBM Corp. 2004
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/config.h>
+#include <linux/version.h>
+#include <asm/io.h>
+
+static struct mtd_info *oper_flash_mtd = NULL;
+static struct mtd_info *small_flash_mtd = NULL;
+static struct mtd_info *fram_mtd = NULL;
+static struct mtd_info *sram_mtd = NULL;
+
+static struct map_info yucca_sram_map = {
+ .name = "Yucca SRAM",
+ .size = BOARD_SRAM_SIZE,
+ .bankwidth = 2,
+};
+
+static struct map_info yucca_fram_map = {
+ .name = "Yucca FRAM",
+ .size = BOARD_FRAM_SIZE,
+ .bankwidth = 1,
+};
+
+static struct map_info yucca_small_map = {
+ .name = "Yucca small flash",
+ .size = BOARD_SMALL_FLASH_SIZE,
+ .bankwidth = 1,
+};
+
+static struct map_info yucca_oper_map = {
+ .name = "Yucca Operational flash",
+ .size = BOARD_OPER_FLASH_SIZE,
+ .bankwidth = 2,
+};
+
+static struct mtd_partition yucca_sram_partitions[] = {
+ {
+ .name = "SRAM",
+ .offset = 0x0,
+ .size = 0x100000,
+ }
+};
+
+static struct mtd_partition yucca_fram_partitions[] = {
+ {
+ .name = "FRAM",
+ .offset = 0x0,
+ .size = 0x8000,
+ }
+};
+
+static struct mtd_partition yucca_small_partitions[] = {
+ {
+ .name = "U-boot",
+ .offset = 0x0,
+ .size = 0x100000,
+ }
+};
+
+static struct mtd_partition yucca_oper_partitions[] = {
+ {
+ .name = "Linux Kernel",
+ .offset = 0,
+ .size = 0x100000,
+ },
+ {
+ .name = "Free Area",
+ .offset = 0x100000,
+ .size = 0x300000,
+ }
+};
+
+#define NB_OF(x) (sizeof(x)/sizeof(x[0]))
+
+
+int __init init_yucca(void)
+{
+ u16 fpga10_reg; u16 *fpga_adr;
+ unsigned long long small_flash_base, oper_flash_base;
+ unsigned long long sram_base, fram_base;
+ int memconfig = 0;
+
+ fpga_adr = ioremap64(YUCCA_FPGA_REG_BASE, YUCCA_FPGA_REG_SIZE);
+ if (!fpga_adr)
+ return -ENOMEM;
+
+
+ fpga10_reg = *((u16*)((u32)fpga_adr + FPGA_REG10));
+ iounmap(fpga_adr);
+ switch (fpga10_reg & BOARD_CONFIG_MASK) {
+ default:
+ printk("Memory config switches are invalid: "
+ "fpga10_reg= %x. Using default configuration\n",
+ fpga10_reg);
+ case BOARD_CONFIG_1:
+ memconfig = 1;
+ small_flash_base = BOARD_CONF1_SMALL_FLASH;
+ oper_flash_base = BOARD_CONF1_OPER_FLASH;
+ sram_base = BOARD_CONF1_SRAM;
+ fram_base = BOARD_CONF1_FRAM;
+ break;
+ case BOARD_CONFIG_2:
+ memconfig = 2;
+ small_flash_base = BOARD_CONF2_SMALL_FLASH;
+ oper_flash_base = BOARD_CONF2_OPER_FLASH;
+ sram_base = BOARD_CONF2_SRAM;
+ fram_base = BOARD_CONF3_FRAM;
+ break;
+ case BOARD_CONFIG_3:
+ memconfig = 3;
+ small_flash_base = BOARD_CONF3_SMALL_FLASH;
+ oper_flash_base = BOARD_CONF3_OPER_FLASH;
+ sram_base = BOARD_CONF3_SRAM;
+ fram_base = BOARD_CONF3_FRAM;
+ break;
+ }
+
+ printk("Using EBC memory configuration #%d\n", memconfig);
+
+ yucca_small_map.phys = small_flash_base;
+ yucca_small_map.virt = ioremap64(small_flash_base,
+ yucca_small_map.size);
+
+ if (!yucca_small_map.virt) {
+ printk("Failed to ioremap small flash\n");
+ return -EIO;
+ }
+
+ simple_map_init(&yucca_small_map);
+
+ small_flash_mtd = do_map_probe("map_rom", &yucca_small_map);
+ if (small_flash_mtd) {
+ small_flash_mtd->owner = THIS_MODULE;
+ add_mtd_partitions(small_flash_mtd, yucca_small_partitions,
+ NB_OF(yucca_small_partitions));
+ } else {
+ printk("map probe failed for small flash\n");
+ return -ENXIO;
+ }
+
+ yucca_oper_map.phys = oper_flash_base;
+ yucca_oper_map.virt = ioremap64(oper_flash_base,
+ yucca_oper_map.size);
+
+ if (!yucca_oper_map.virt) {
+ printk("Failed to ioremap oper flash\n");
+ return -EIO;
+ }
+
+ simple_map_init(&yucca_oper_map);
+
+ oper_flash_mtd = do_map_probe("cfi_probe", &yucca_oper_map);
+ if (oper_flash_mtd) {
+ oper_flash_mtd->owner = THIS_MODULE;
+ add_mtd_partitions(oper_flash_mtd, yucca_oper_partitions,
+ NB_OF(yucca_oper_partitions));
+ } else {
+ printk("map probe failed for oper flash\n");
+ return -ENXIO;
+ }
+
+ yucca_sram_map.phys = sram_base;
+ yucca_sram_map.virt = ioremap64(sram_base,
+ yucca_sram_map.size);
+
+ if (!yucca_sram_map.virt) {
+ printk("Failed to ioremap SRAM\n");
+ return -EIO;
+ }
+
+ simple_map_init(&yucca_sram_map);
+
+ sram_mtd = do_map_probe("map_ram", &yucca_sram_map);
+ if (sram_mtd) {
+ sram_mtd->owner = THIS_MODULE;
+ add_mtd_partitions(sram_mtd, yucca_sram_partitions,
+ NB_OF(yucca_sram_partitions));
+ } else {
+ printk("map probe failed for SRAM\n");
+ return -ENXIO;
+ }
+
+ yucca_fram_map.phys = fram_base;
+ yucca_fram_map.virt = ioremap64(fram_base,
+ yucca_fram_map.size);
+
+ if (!yucca_fram_map.virt) {
+ printk("Failed to ioremap FRAM\n");
+ return -EIO;
+ }
+
+ simple_map_init(&yucca_fram_map);
+
+ fram_mtd = do_map_probe("map_ram", &yucca_fram_map);
+ if (fram_mtd) {
+ fram_mtd->owner = THIS_MODULE;
+ add_mtd_partitions(fram_mtd, yucca_fram_partitions,
+ NB_OF(yucca_fram_partitions));
+ } else {
+ printk("map probe failed for FRAM\n");
+ return -ENXIO;
+ }
+ return 0;
+}
+
+static void __exit cleanup_yucca(void)
+{
+ if (yucca_small_map.virt) {
+ iounmap((void *)yucca_small_map.virt);
+ yucca_small_map.virt = 0;
+ }
+
+ if (yucca_oper_map.virt) {
+ iounmap((void *)yucca_oper_map.virt);
+ yucca_oper_map.virt = 0;
+ }
+
+ if (yucca_fram_map.virt) {
+ iounmap((void *)yucca_fram_map.virt);
+ yucca_fram_map.virt = 0;
+ }
+
+ if (yucca_sram_map.virt) {
+ iounmap((void *)yucca_sram_map.virt);
+ yucca_sram_map.virt = 0;
+ }
+
+ if (oper_flash_mtd) {
+ del_mtd_partitions(oper_flash_mtd);
+ map_destroy(oper_flash_mtd);
+ }
+
+ if (small_flash_mtd) {
+ del_mtd_partitions(small_flash_mtd);
+ map_destroy(small_flash_mtd);
+ }
+
+ if (fram_mtd) {
+ del_mtd_partitions(fram_mtd);
+ map_destroy(fram_mtd);
+ }
+
+ if (sram_mtd) {
+ del_mtd_partitions(sram_mtd);
+ map_destroy(sram_mtd);
+ }
+
+}
+
+module_init(init_yucca);
+module_exit(cleanup_yucca);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ruslan V. Sushko <rsushko@ru.mvista.com>");
+MODULE_DESCRIPTION("MTD map and partitions for AMCC 440SPe Yucca boards");
+
^ permalink raw reply
* [PATCH 1/3] [PPC32] I2C and GPIO controlers addresses fix on Yucca board
From: Ruslan V. Sushko @ 2005-10-03 8:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 259 bytes --]
This patch fixes physical address for I2C and GPIO controllers on Yucca
PPC440SPe board. The fixes below allows to enable ibm ocp i2c driver to
access to Yucca peripheral devices. The patch is implemented for Roland
Dreier git tree for Yucca PPC440SPe board.
[-- Attachment #2: yucca_i2c.patch --]
[-- Type: text/x-patch, Size: 972 bytes --]
diff --git a/arch/ppc/platforms/4xx/ppc440spe.c b/arch/ppc/platforms/4xx/ppc440spe.c
--- a/arch/ppc/platforms/4xx/ppc440spe.c
+++ b/arch/ppc/platforms/4xx/ppc440spe.c
@@ -90,7 +90,7 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_IBM,
.function = OCP_FUNC_IIC,
.index = 0,
- .paddr = 0x00000001f0000400ULL,
+ .paddr = 0x00000004f0000400ULL,
.irq = 2,
.pm = IBM_CPM_IIC0,
.additions = &ppc440spe_iic0_def,
@@ -99,7 +99,7 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_IBM,
.function = OCP_FUNC_IIC,
.index = 1,
- .paddr = 0x00000001f0000500ULL,
+ .paddr = 0x00000004f0000500ULL,
.irq = 3,
.pm = IBM_CPM_IIC1,
.additions = &ppc440spe_iic1_def,
@@ -108,7 +108,7 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_IBM,
.function = OCP_FUNC_GPIO,
.index = 0,
- .paddr = 0x00000001f0000700ULL,
+ .paddr = 0x00000004f0000700ULL,
.irq = OCP_IRQ_NA,
.pm = IBM_CPM_GPIO0,
},
^ permalink raw reply
* Is the PCI-to-PCI Bridge supported on AMCC440EP ?
From: KylongMu @ 2005-10-03 13:44 UTC (permalink / raw)
To: wd; +Cc: Linuxppc-embedded
In-Reply-To: <20050920181045.21320353AB3@atlas.denx.de>
Hi, Denk
I've already engaged the Yosemite board from AVNET ,but not
in my hands , and I noted that only one PCI slot on the board , I'm going
to add more than one PCI peripheral on it , so I engaged another PCI
extend card with PCI 6150 PCI-to-PCI Bridge , I don't know if the new
release 2.6.14 kernel and the AMCC440EP will support this Bridge ?
Another question is I'm going to add the Hard Disk on this system
with promise20268 PCI-IDE chard , how about this ?
And if I need add a Video card through the PCI , which chip is
be good supported?
Best Regards,
KylongMu
^ permalink raw reply
* RE: mpc5200 and pcmcia
From: Derycke, Johan @ 2005-10-03 13:56 UTC (permalink / raw)
To: Andrew Dennison; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
Hi Andrew,
I am looking forward to your patch.
If there is anything you want me to test let me know...
Does it support 32bit cards?
Br,
Johan
-----Original Message-----
From: Andrew Dennison [mailto:andrewd.lists@gmail.com]
Sent: donderdag 29 september 2005 1:26
To: Derycke, Johan
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: mpc5200 and pcmcia
On 9/28/05, Derycke, Johan <johan.derycke@barco.com> wrote:
>
> I am working on a custom board based on the Lite5200.
> It is expanded with a PCI1410 PC Card Controller on the PCI bus.
>
> In the history of this list I found a patch against an older kernel
version
> to solve some issues:
> http://ozlabs.org/pipermail/linuxppc-embedded/2004-December/016273.html
>
> I took the old 2.4.23 kernel and applied the patch.
> I could get my 3c589 network adaptor to work.
Nice to get some feedback, Your the second person that has used it.
> Is this patch available for the current 2.4.25 kernel?
>
It will work conceptually with 2.4.25 as I'm currently running a
relatively recent denx kernel with similar changes. I haven't
published a recent patch yet as there wasn't much feedback last
time...
I've recently done some more work on this to clean it up, for example
USB didn't work with that previous patch but they now coesist happily.
I'll look at posting a patch soon when it's merged into my shiny new GIT
tree.
Andrew
- - - - - - - DISCLAIMER - - - - - - - -
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this message and/or
attachments is strictly prohibited. The company accepts no liability for any
damage caused by any virus transmitted by this email. Furthermore, the
company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays. If you have
received this message in error, please contact the sender and delete the
message. Thank you.
[-- Attachment #2: Type: text/html, Size: 3618 bytes --]
^ permalink raw reply
* RE: clock skew on B/W G3
From: Rune Torgersen @ 2005-10-03 14:18 UTC (permalink / raw)
To: Marc, linuxppc-dev, linux-kernel
> -----Original Message-----
> From: Marc
> Sent: Sunday, October 02, 2005 11:46
>=20
> Some additions to the previous mail: I was able to isolate=20
> the problem to the=20
> introduction of a user specificable value of HZ (in=20
> include/asm-ppc/parm.h).=20
> I used a value of 250 while the former default was 1000.=20
> Setting it back to=20
> 1000 makes the clock tick right again.
>=20
> Is the CONFIG_HZ known to be broken on PPC ?
>=20
CONFIG_HZ is not broken, but the whole clock configuration is.
(I poseded something about it for 8260 earlier this summer)
Basic problem is that CLOCK_TICK_RATE which is used for setting up the
variables used for advancing the clock, is hardcoded to a value that
only makes sence for an i386. (it is default set at 1193180Hz which
happens to be the timer clock for timer1 on an i386 machine)
Another problem here is that that value apparently hve to be #define'd
which means you cannot insert the decrementer frequency from the
boot-loader either.
^ permalink raw reply
* Re: [PATCH 2/3][PPC32] PCI-X support for Yucca
From: Eugene Surovegin @ 2005-10-03 16:15 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1128328568.21396.7.camel@mephisto.spb.rtsoft.ru>
On Mon, Oct 03, 2005 at 12:36:08PM +0400, Ruslan V. Sushko wrote:
> This patch adds PCIX support for Yucca PPC440SPe board. The patch is
> implemented for Roland Dreier git tree for Yucca PPC440SPe board.
>
> Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[snip]
> + mtdcr(DCRN_UIC_PR(UIC1),
> + mfdcr(DCRN_UIC_PR(UIC1)) & ~0x00004000); /* Set PCI interrupt
> + (EXT IRQ12) plarity
> + to Negative */
Don't mess with UIC registers directly. Take a look how this type of
setup is done in other 4xx ports (e.g. Ebony) and use the same
approach (hint: ppc4xx_uic_ext_irq_cfg).
--
Eugene
^ permalink raw reply
* MPC 8260/70 MCC SI Clocking and TSA Sync
From: Manish Joshi @ 2005-10-03 16:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
Hi,
I am trying to bring up MCC (Multi Channel Communication controller) on MPC8270 board for T1/E1.
The overall configuration looks fine since I am able to have a communication properly if I do a T1 Cross over Loopback and tx/rx HDLC data.
The things do not work smoothly if I connect my T1 line with an external device and start HDLC.
I am seeing 'NO' (Rx Non-Octet Alligned Frame) errors in my rx buffers. Sometimes I also see Rx abort errors.
I do not see this issue on the tx side i.e the external device does not report any of these when I tx HDLC data to it.
Does anybody have any experience dealing with this ?
As far as clocking and sync with TSA is concerned, I have just configured
CMXSI2CR register with 0x00 ( I have only TDM2A driven by CLK1) and nothing else.
Do I need to do something more for clocking etc? Also I am doing this before SI initialisation.
I will also try doing it just after TDM init and see if it helps.
Please help.
Thanks,
-Manish
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
[-- Attachment #2: Type: text/html, Size: 1412 bytes --]
^ permalink raw reply
* Re: MV64x60 watchdog timer driver updates
From: Mark A. Greer @ 2005-10-03 20:46 UTC (permalink / raw)
To: Corey Minyard; +Cc: linuxppc-dev
In-Reply-To: <433D557C.4020301@acm.org>
On Fri, Sep 30, 2005 at 10:10:52AM -0500, Corey Minyard wrote:
> Mark A. Greer wrote:
>
> >On Thu, Sep 29, 2005 at 01:32:21PM -0500, Corey Minyard wrote:
> >
> >
> >>James looked at an earlier version and said it was ok, and suggested
> >>a few changes. This has been tested against 2.6.14-rc2 on a Katana.
> >>
> >>Note that the bus_clk value from the platform information seems to
> >>be in MHZ, but the actual frequency is generally 133,333,333, not
> >>133,000,000. I don't think the inaccuracy matters here, but it seems
> >>a little odd.
> >>
> >>
> >
> >Yes, it makes more sense to me to pass the actual frequency and not do
> >the '* 1000000'.
> >
> >
> The only trouble is if you go over 4GHZ... Maybe it should be in KHZ
> instead of MHZ? or 64-bits? Or maybe we don't worry about >4GHZ busses?
My vote is to worry about it when the time comes. IIRC, the fastest a
Marvell bridge part can be clocked right now is 200 MHz so there's some time.
> Also, how would one go about changing this? Would you need something like:
>
> if (bus_clk < 1000)
> bus_clk *= 1000000
>
> for backwards compatability?
When I didn't see anyone passing that value in via platform_data so
there's no compatibility issue. I could have missed something though...
> >Also--I should have thought of this earlier--there should probably be a
> >patch to add a default platform_data entry in arch/ppc/syslib/mv64x60.c
> >and a patch for katana.c if the defaults in mv64x60.c aren't correct
> >for the katana. At least, that's how things are done now.
> >
> >
> I'm not sure I understand completely. How would you go about setting
> the platform data?
Look near the top of arch/ppc/syslib/mv64x60.c and you will see a bunch
of default platform_data being set up for marvell bridges. They can then
be tweaked by the platform specific code via the platform_notify() hook
(see arch/ppc/platforms/katana.c:katana_platform_notify(), et. al.).
Mark
^ permalink raw reply
* Re: mpc5200 and pcmcia
From: Andrew Dennison @ 2005-10-04 4:31 UTC (permalink / raw)
To: Derycke, Johan; +Cc: linuxppc-embedded
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB08D9613C@kuumex05.barco.com>
On 10/3/05, Derycke, Johan <johan.derycke@barco.com> wrote:
>
> If there is anything you want me to test let me know...
> Does it support 32bit cards?
Cardbus support is a problem at the moment. Not sure if it's my
hardware or a 5200 PCI configuration issue.
Apparnetly it's working in 2.6 but I haven't had time to sort this out.
^ permalink raw reply
* Re: clock skew on B/W G3
From: Marc @ 2005-10-04 6:14 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859476@ismail.innsys.innovsys.com>
Hi,
given that this option causes problems on non i386 systems, may I propose t=
o=20
mark CONFIG_HZ as broken on these architectures and/or use a default value =
of=20
1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.
Marc
Le Montag 03 Oktober 2005 16:18, Rune Torgersen a =E9crit :
> > -----Original Message-----
> > From: Marc
> > Sent: Sunday, October 02, 2005 11:46
> >
> > Some additions to the previous mail: I was able to isolate
> > the problem to the
> > introduction of a user specificable value of HZ (in
> > include/asm-ppc/parm.h).
> > I used a value of 250 while the former default was 1000.
> > Setting it back to
> > 1000 makes the clock tick right again.
> >
> > Is the CONFIG_HZ known to be broken on PPC ?
>
> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
>
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)
>
> Another problem here is that that value apparently hve to be #define'd
> which means you cannot insert the decrementer frequency from the
> boot-loader either.
^ permalink raw reply
* Re: mpc5200 and pcmcia
From: Sylvain Munaut @ 2005-10-04 6:21 UTC (permalink / raw)
To: Andrew Dennison; +Cc: linuxppc-embedded
In-Reply-To: <54823def0510032131mee19acft6250ed99ce55ef21@mail.gmail.com>
Andrew Dennison wrote:
> On 10/3/05, Derycke, Johan <johan.derycke@barco.com> wrote:
>
>>If there is anything you want me to test let me know...
>>Does it support 32bit cards?
>
>
> Cardbus support is a problem at the moment. Not sure if it's my
> hardware or a 5200 PCI configuration issue.
IIRC, there is an errata wrt configuration cycle thru bridges.
> Apparnetly it's working in 2.6 but I haven't had time to sort this out.
Is it ? not sure. I remember seeing a patch about it but it removed
the "always 32 bit access" in all cases and not just in the needed case
iirc. Make me think I forgot to sort that out ...
Sylvain
^ permalink raw reply
* serial console
From: KokHow Teh @ 2005-10-04 6:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi;
I have debian linux running on my PQ2FADS-ZU with devfs and seria=
l
driver compiled in. I have read Documentation/serial-console.txt and I =
have
tried both passing "console=3D" option as well as without passing that =
to the
kernel and both don't give me the expected results.
When I pass "console=3Dtts/0,115200n8" to the kernel, I don't get=
any
console output until the login prompt which I set to 115200 in
/etc/inittab. When I don't pass "console=3D" option to the kernel, I ge=
t
console output all the way until "Freeing unused kernel memory:" and th=
e
console output is garbled and I don't see any login prompt. Here is the=
/dev/* content:
(none) login:
Debian GNU/Linux 3.1 (none) tts/0
Password:
Last login: Thu Jan 1 02:29:06 1970 on tts/0
The programs included with the Debian GNU/Linux system are free softwar=
e;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
(none):~# l /dev
total 0
crw------- 1 root root 8, 0 Jan 1 02:00 .devfsd
lr-xr-xr-x 1 root root 13 Jan 1 02:37 MAKEDEV -> /sbin/MAKEDEV
crw------- 1 root root 5, 1 Jan 1 02:00 console
drwxr-xr-x 1 root root 0 Jan 1 02:00 discs
crw-rw-rw- 1 root root 1, 7 Jan 1 02:00 full
drwxr-xr-x 1 root root 0 Jan 1 02:00 ide
prw------- 1 root root 0 Jan 1 02:37 initctl
crw-r----- 1 root root 1, 2 Jan 1 02:00 kmem
srw-rw-rw- 1 root root 0 Jan 1 02:37 log
crw-r----- 1 root root 1, 1 Jan 1 02:00 mem
drwxr-xr-x 1 root root 0 Jan 1 02:00 misc
drwxr-xr-x 1 root root 0 Jan 1 02:00 mtd
drwxr-xr-x 1 root root 0 Jan 1 02:00 mtdblock
crw-rw-rw- 1 root root 1, 3 Jan 1 02:00 null
crw-r----- 1 root root 1, 4 Jan 1 02:00 port
crw-rw-rw- 1 root root 5, 2 Jan 1 02:00 ptmx
drwxr-xr-x 1 root root 0 Jan 1 02:00 pts
drwxr-xr-x 1 root root 0 Jan 1 02:00 pty
crw-r--r-- 1 root root 1, 8 Jan 1 02:00 random
drwxr-xr-x 1 root root 0 Jan 1 02:00 rd
lr-xr-xr-x 1 root root 33 Jan 1 02:37 root -> ide/host0/bus0/target=
0/lun0/part2
drwxrwxrwt 3 root root 60 Jan 1 02:37 shm
drwxr-xr-x 1 root root 0 Jan 1 02:00 soc
drwxr-xr-x 1 root root 0 Jan 1 02:00 tts
crw-rw-rw- 1 root root 5, 0 Jan 1 02:00 tty
crw-r--r-- 1 root root 1, 9 Jan 1 02:37 urandom
prw-r----- 1 root adm 0 Jan 1 02:37 xconsole
crw-rw-rw- 1 root root 1, 5 Jan 1 02:00 zero
(none):~#
This is what I end up without "console=3D" option passed to the k=
ernel:
<snip>
Mounted devfs on /dev
Freeing unused kernel memory: 232k init 4k prep
..=EF=BF=BD=EF=BF=BD=EF=BF=BD.=EF=BF=BD...=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD.=EF=BF=BD=EF=BF=BD.=EF=BF=BD=
...=EF=BF=BD...=EF=BF=BD=EF=BF=BD=EF=BF=BD......=EF=BF=BD..=EF=BF=BD...=
=EF=BF=BD=EF=BF=BD=EF=BF=BD..=EF=BF=BD.=EF=BF=BD.=EF=BF=BD=EF=BF=BD.=EF=
=BF=BD=EF=BF=BD.....=EF=BF=BD=EF=BF=BD[42;124H.
<no login prompt>
My question is, how can I get a complete serial console output al=
l
the way from bootup to the login prompt? I am missing something. It is
either the kernel configuration or I have to tweak the codes somewhere.=
Any
input and insight is appreciated.
Regards,
TEH
=
^ permalink raw reply
* Re: mpc5200 and pcmcia
From: Andrew Dennison @ 2005-10-04 7:11 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <43421F87.2070501@246tNt.com>
On 10/4/05, Sylvain Munaut <tnt@246tnt.com> wrote:
>
> IIRC, there is an errata wrt configuration cycle thru bridges.
I've got support for this (it's in my December patch). Configuration
cycles work but some cardbus cards / drivers cause a TEA when the
device is enabled driver loads Netgear FA511), while with a prism
based WLAN card (Netcomm NP5430) I can load the firmware into the card
but it doesn't run correctly - iwconfig can cause a TEA.
I haven't had time to work out how to debug these properly - other
more important things to do.
>
> > Apparnetly it's working in 2.6 but I haven't had time to sort this out.
>
> Is it ? not sure. I remember seeing a patch about it but it removed
> the "always 32 bit access" in all cases and not just in the needed case
> iirc. Make me think I forgot to sort that out ...
At one stange you mentioned you had a patch from someone for cardbus
support on 2.6 - it just fixed the configuration cycle errata so I
assumed this meant the rest "just worked". Maybe that was a bad
assumption...
Andrew
^ permalink raw reply
* Re: mpc5200 and pcmcia
From: Asier Llano Palacios @ 2005-10-04 7:30 UTC (permalink / raw)
To: Andrew Dennison; +Cc: linuxppc-embedded
In-Reply-To: <54823def0510040011m3e2ecfe6yae0d07187d5baeee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4750 bytes --]
I've developed the following patch.
It is not tested against the last git revision (I have to update my tree
as soon as I have enough time) and I sent it to Sylvain so it may be
partially commited.
Sorry, but this patch solves (or tries to solve) several problems.
You will have to have a look at the patch manually to understand every
of the issues it tries to solve.
PCI bus initialization: If you boot the MPC5200 with u-boot without PCI
support you will end up with some linux initialization problems. It is
because of the reset process (which leaves the PCI bus in its previous
state, that is reset by default, unless u-boot touches it). It does also
need to initialize some configuration elements of the PCI bus.
+ tmp = in_be32(&pci_regs->scr);
+ tmp |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ out_be32(&pci_regs->scr, tmp);
and
- out_be32(&pci_regs->gscr, tmp);
+ out_be32(&pci_regs->gscr, tmp & ~MPC52xx_PCI_GSCR_PR);
Flags for hotplug: The function mpc52xx_pci_fixup_resources is called
for every PCI device (included cardbus) so if it is called from cardbus
it cannot be __init (it caused a big problem). Removing the __init is
enough.
-static void __init mpc52xx_pci_fixup_resources(struct pci_dev *dev) {
+static void mpc52xx_pci_fixup_resources(struct pci_dev *dev) {
Introduced Delay: A udelay(1) is introduced before configuration cycles.
Otherwise it crashes for me. Sylvain told me that the PCI should wait
some time after reset before it is used. I've not tested including the
delay in other parts.
Workaround for bug of MPC5200: MPC5200 has a bug with PCI type 1
configuration frames so the workaround proposed by freescale is
splitting them. Sylvain told me that some PCI cards have problems
reading or writting operations that are not 32 bits. So this code should
be rewritten a little bit. (I think I should rewrite it near in the
future).
(This is everything else in the patch).
I would thank very much to anyone that splits this patch, introduces the
workaround for the bug of MPC5200 while using only 32 bit operation on
type 0 frames, and sends it to Sylvain. (I feel like writting my Xmas
letter to Santa. XoD).
I hope this helps.
Asier Llano
El mar, 04-10-2005 a las 17:11 +1000, Andrew Dennison escribió:
> On 10/4/05, Sylvain Munaut <tnt@246tnt.com> wrote:
> >
> > IIRC, there is an errata wrt configuration cycle thru bridges.
>
> I've got support for this (it's in my December patch). Configuration
> cycles work but some cardbus cards / drivers cause a TEA when the
> device is enabled driver loads Netgear FA511), while with a prism
> based WLAN card (Netcomm NP5430) I can load the firmware into the card
> but it doesn't run correctly - iwconfig can cause a TEA.
>
> I haven't had time to work out how to debug these properly - other
> more important things to do.
>
> >
> > > Apparnetly it's working in 2.6 but I haven't had time to sort this out.
> >
> > Is it ? not sure. I remember seeing a patch about it but it removed
> > the "always 32 bit access" in all cases and not just in the needed case
> > iirc. Make me think I forgot to sort that out ...
>
> At one stange you mentioned you had a patch from someone for cardbus
> support on 2.6 - it just fixed the configuration cycle errata so I
> assumed this meant the rest "just worked". Maybe that was a bad
> assumption...
>
> Andrew
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Asier Llano Palacios <a.llano@usyscom.com>
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged.
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
µSysCom uses virus scanning software but excludes any liability for viruses contained in any attachment.
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal.
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.
µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.
[-- Attachment #2: mpc5200_pci.patch --]
[-- Type: text/x-patch, Size: 3089 bytes --]
diff -urP linux-2.6.10-mpc5200/arch/ppc/syslib/mpc52xx_pci.c linux-2.6.10-mpc5200-pci/arch/ppc/syslib/mpc52xx_pci.c
--- linux-2.6.10-mpc5200/arch/ppc/syslib/mpc52xx_pci.c 2005-01-14 18:44:43.000000000 +0100
+++ linux-2.6.10-mpc5200-pci/arch/ppc/syslib/mpc52xx_pci.c 2005-02-10 09:50:23.000000000 +0100
@@ -22,6 +22,10 @@
#include <asm/delay.h>
+/* This macro is defined to activate the workaround for the bug
+ 435 of the MPC5200 (L25R) */
+#define MPC5200_BUG_435_WORKAROUND
+
static int mpc52xx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
@@ -39,11 +43,24 @@
(devfn << 8) |
(offset & 0xfc));
- value = in_le32((u32*)hose->cfg_data);
+ udelay( 1 );
- if (len != 4) {
- value >>= ((offset & 0x3) << 3);
- value &= 0xffffffff >> (32 - (len << 3));
+ switch( len )
+ {
+ case 1:
+ value = in_8(((u8*)hose->cfg_data) + (offset&0x3));
+ break;
+ case 2:
+ value = in_le16(((u16*)hose->cfg_data) + ((offset>>1)&1));
+ break;
+ default:
+#ifdef MPC5200_BUG_435_WORKAROUND
+ if( bus->number != hose->bus_offset )
+ value = in_le16((u16*)hose->cfg_data) | (in_le16(((u16*)hose->cfg_data) + 1) << 16);
+ else
+#endif
+ value = in_le32((u32*)hose->cfg_data);
+ break;
}
*val = value;
@@ -57,7 +74,6 @@
int offset, int len, u32 val)
{
struct pci_controller *hose = bus->sysdata;
- u32 value, mask;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(bus->number, devfn))
@@ -69,19 +85,27 @@
(devfn << 8) |
(offset & 0xfc));
- if (len != 4) {
- value = in_le32((u32*)hose->cfg_data);
-
- offset = (offset & 0x3) << 3;
- mask = (0xffffffff >> (32 - (len << 3)));
- mask <<= offset;
-
- value &= ~mask;
- val = value | ((val << offset) & mask);
+ switch( len )
+ {
+ case 1:
+ out_8(((u8*)hose->cfg_data) + (offset&0x3), val);
+ break;
+ case 2:
+ out_le16(((u16*)hose->cfg_data) + ((offset>>1)&1), val);
+ break;
+ default:
+#ifdef MPC5200_BUG_435_WORKAROUND
+ if( bus->number != hose->bus_offset )
+ {
+ out_le16((u16*)hose->cfg_data, (u16)val);
+ out_le16(((u16*)hose->cfg_data) + 1, (u16)(val>>16));
+ }
+ else
+#endif
+ out_le32((u32*)hose->cfg_data, val);
+ break;
}
- out_le32((u32*)hose->cfg_data, val);
-
out_be32(hose->cfg_addr, 0);
return PCIBIOS_SUCCESSFUL;
@@ -98,6 +122,9 @@
u32 tmp;
/* Setup control regs */
+ tmp = in_be32(&pci_regs->scr);
+ tmp |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ out_be32(&pci_regs->scr, tmp);
/* Setup windows */
out_be32(&pci_regs->iw0btar, MPC52xx_PCI_IWBTAR_TRANSLATION(
@@ -138,10 +165,10 @@
tmp = in_be32(&pci_regs->gscr);
out_be32(&pci_regs->gscr, tmp | MPC52xx_PCI_GSCR_PR);
udelay(50);
- out_be32(&pci_regs->gscr, tmp);
+ out_be32(&pci_regs->gscr, tmp & ~MPC52xx_PCI_GSCR_PR);
}
-static void __init mpc52xx_pci_fixup_resources(struct pci_dev *dev) {
+static void mpc52xx_pci_fixup_resources(struct pci_dev *dev) {
int i;
/* We don't rely on boot loader for PCI and resets all
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-10-04 8:13 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <4340D7EF.2040709@iki.fi>
I found it. It's in the MPC8272 family errata. When setting pipeline
depth to one everything works. Can you Alex confirm this works also for
you? This errata should probably be included in the Linux kernel, since
it really depends on it. Right now I set this from the boot loader, but
perhaps head.S in the kernel would be the just as good.
Part I System Interface Unit (SIU) Errata
SIU18: ARTRY assertion when using pipeline depth of 0.
Devices:
MPC8272, MPC8271, MPC8248, MPC8247
Description:
Internal (60x) slave maintains a pipeline depth of zero by asserting
AACK only after TA. When ARTRY is
asserted, the 60x bus access is terminated and TA is not asserted. The
internal (60x) slave does not assert
AACK, since TA was not asserted.
Workaround:
Use a pipeline depth of one (BCR[PLDP]=0) for applications that require
memory coherency.
Fix Plan:
No fix plan at this time.
^ permalink raw reply
* Re: CPM2 early console
From: Alex Zeffertt @ 2005-10-04 9:59 UTC (permalink / raw)
To: Kalle Pokki; +Cc: dan, linuxppc-embedded
In-Reply-To: <43423996.7090403@iki.fi>
On Tue, 04 Oct 2005 10:13:10 +0200
Kalle Pokki <kalle.pokki@iki.fi> wrote:
> I found it. It's in the MPC8272 family errata. When setting pipeline
> depth to one everything works. Can you Alex confirm this works also
> for you?
Hi Kalle, I've just checked and it makes no difference to the ATM
driver. In fact, on my platform (PM828+u-boot-1.1.3) the pipeline
depth was already set to 1.
You are probably right that the pipeline depth was the cause of your
problem- but my problem is something else. I think that Freescale
simply overlooked the ATM external connection table case when
designing the cache coherency protocol - because they offered no way
to assert GBL when external connection tables are accessed.
Alex
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-10-04 10:16 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: dan, linuxppc-embedded
In-Reply-To: <20051004105917.27d93a91.ajz@cambridgebroadband.com>
Alex Zeffertt wrote:
>Hi Kalle, I've just checked and it makes no difference to the ATM
>driver. In fact, on my platform (PM828+u-boot-1.1.3) the pipeline
>depth was already set to 1.
>
>You are probably right that the pipeline depth was the cause of your
>problem- but my problem is something else. I think that Freescale
>simply overlooked the ATM external connection table case when
>designing the cache coherency protocol - because they offered no way
>to assert GBL when external connection tables are accessed.
>
>
The ATM in 8260 seems to have a huge errata list. Just quickly looking
at those at least CPM71: CPM does not snoop MCC buffer descriptors
sounds related, but it may be some other issue also. Do you already use
the microcode patch provided by Freescale?
I'm confident my problem was fixed with the correct setting of the
pipeline depth. I had trouble with everything related to cache
coherency, not just a single communication protocol.
^ permalink raw reply
* RE: clock skew on B/W G3
From: Paul Mackerras @ 2005-10-04 12:48 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859476@ismail.innsys.innovsys.com>
Rune Torgersen writes:
> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
>
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)
I do not believe CLOCK_TICK_RATE affects timekeeping at all on ppc or
ppc64 machines, but I could be wrong. Can you show us where and how
CLOCK_TICK_RATE affects things?
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox