Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
Hello Paul, Paul Mundt schrieb: > On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote: >>> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style >>> problems and is ready for submission. >>> >>> Documentation/powerpc/dts-bindings/sm501.txt | 34 + >>> drivers/mfd/sm501.c |9 +- >>> drivers/video/sm501fb.c | 42 >>> -- >>> 3 files changed, 81 insertions(+), 4 deletions(-) >>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt >> This patchset is pending know for a while. I got Acked by from >> >> Samuel Ortiz for the mfd part, see here: >> >> http://www.spinics.net/lists/linux-fbdev/msg02550.html >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html >> >> and for the DTS part from Benjamin Herrenschmidt: >> >> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html >> >> Are there some more issues? >> > Not that I remember off the top of my head, but I think they've been lost > in my backlog. Could you re-send the current series with the appropriate > acked-bys? If there's nothing else obvious outstanding I'll roll them in. Ok, I resend them (I also rebase them to current tree, ok?) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/ptrace: remove BUG_ON when full register set not available
On Wed, Mar 16, 2011 at 08:37:22AM -0500, Michael Wolf wrote: > In some cases during a threaded core dump not all > the threads will have a full register set. This > will cause problems when the sigkill is sent to > the thread. To solve this problem a poison value > (0xdeadbeef) will be placed in the buffer in place > of the actual register values. This will affect > gpr14 to gpr31. To be clear, this happens when the signal causing the core dump races with a thread exiting. The race happens when the exiting thread has entered the kernel for the last time before the signal arrives, but doesn't get far enough through the exit code to avoid being included in the core dump. So we get a thread included in the core dump which is never going to go out to userspace again and only has a partial register set recorded. Normally we would catch each thread as it is about to go into userspace and capture the full register set then. However, this exiting thread is never going to go out to userspace again, so we have no way to capture its full register set. It doesn't really matter, though, as this is a thread which is effectively already dead. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] gianfar: Fall back to software tcp/udp checksum on older controllers
As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,
older revisions of gianfar controllers will be unable to calculate a TCP/UDP
packet checksum for some alignments of the appropriate FCB. This patch checks
for FCB alignment on such controllers and falls back to software checksumming
if the alignment is known to be bad.
Signed-off-by: Alex Dubov
---
Can we, please, proceed with this patch?
The issue is badly annoying, breaking quite a few of the MPC8548 chips.
Changes for v2:
- Make indentation slightly more consistent.
- Replace bizarre switch-based condition with plain boring one.
drivers/net/gianfar.c | 16 ++--
drivers/net/gianfar.h |1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 5ed8f9f..3da19a5 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -950,6 +950,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_A002;
+ /* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
+ if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020) ||
+ (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
+ priv->errata |= GFAR_ERRATA_12;
+
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
priv->errata);
@@ -2156,8 +2161,15 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
/* Set up checksumming */
if (CHECKSUM_PARTIAL == skb->ip_summed) {
fcb = gfar_add_fcb(skb);
- lstatus |= BD_LFLAG(TXBD_TOE);
- gfar_tx_checksum(skb, fcb);
+ /* as specified by errata */
+ if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
+&& ((unsigned long)fcb % 0x20) > 0x18)) {
+ __skb_pull(skb, GMAC_FCB_LEN);
+ skb_checksum_help(skb);
+ } else {
+ lstatus |= BD_LFLAG(TXBD_TOE);
+ gfar_tx_checksum(skb, fcb);
+ }
}
if (vlan_tx_tag_present(skb)) {
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 54de413..ec5d595 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1039,6 +1039,7 @@ enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
GFAR_ERRATA_A002= 0x04,
+ GFAR_ERRATA_12 = 0x08, /* a.k.a errata eTSEC49 */
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] mtd/nand: Add initial support for TWR-MPC5125
Adds NAND Flash Controller driver for MPC5125.
Also adds chip id for Micron's NAND used in TWR-MPC5125.
Driver ported from original Freescale BSP (kernel 2.6.29.1).
Signed-off-by: Vladimir Ermakov
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index a92054e..eb660a8 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -472,6 +472,26 @@ config MTD_NAND_MPC5121_NFC
This enables the driver for the NAND flash controller on the
MPC5121 SoC.
+config MTD_NAND_MPC5125_NFC
+ tristate "MPC5125 built-in NAND Flash Controller support"
+ depends on PPC_MPC512x
+ help
+ This enables the driver for the NAND flash controller on the
+ MPC5125 SoC.
+
+config MTD_NAND_MPC5125_HWECC
+ bool "Enable hardware ECC"
+ depends on MTD_NAND_MPC5125_NFC
+ help
+ This enables the support for Software ECC handling. By
+ default FSL NAND controller Hardware ECC is supported.
+
+config NFC_DMA_ENABLE
+ bool "Enable NAND Flash DMA"
+ depends on MTD_NAND_MPC5125_NFC
+ help
+ This enables the nfc dma support
+
config MTD_NAND_MXC
tristate "MXC NAND support"
depends on IMX_HAVE_PLATFORM_MXC_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 5745d83..bd354cd 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o
obj-$(CONFIG_MTD_NAND_NOMADIK) += nomadik_nand.o
obj-$(CONFIG_MTD_NAND_BCM_UMI) += bcm_umi_nand.o nand_bcm_umi.o
obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_MPC5125_NFC) += mpc5125_nfc.o
obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
diff --git a/drivers/mtd/nand/mpc5125_nfc.c b/drivers/mtd/nand/mpc5125_nfc.c
new file mode 100644
index 000..aea3186
--- /dev/null
+++ b/drivers/mtd/nand/mpc5125_nfc.c
@@ -0,0 +1,1290 @@
+/*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
+ *
+ * MPC5125 Nand driver.
+ *
+ * Based on original driver from Freescale Semiconductor
+ * written by Shaohui Xie on basis
+ * of drivers/mtd/nand/mpc5121_nfc.c.
+ * Modyfied by Cloudy Chen .
+ * Reworked by Vladimir Ermakov .
+ *
+ * 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 Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mpc5125_nfc.h"
+
+#defineDRV_NAME"mpc5125_nfc"
+
+#defineSPARE_BUFFER_MAX_SIZE 0x400
+#defineDATA_BUFFER_MAX_SIZE0x2000
+
+/* Timeouts */
+#define NFC_RESET_TIMEOUT 1000/* 1 ms */
+#define NFC_TIMEOUT(HZ / 10) /* 1/10 s */
+
+#ifdef CONFIG_NFC_DMA_ENABLE
+#define NFC_DMA_ENABLE 1
+#else
+#define NFC_DMA_ENABLE 0
+#endif
+
+struct mpc5125_nfc_prv {
+ struct mtd_info mtd;
+ struct nand_chipchip;
+ int irq;
+ void __iomem*regs;
+ struct clk *clk;
+ wait_queue_head_t irq_waitq;
+ uintcolumn;
+ int spareonly;
+ u32 irq_stat;
+ u32 wait_timeout;
+ void __iomem*csreg;
+ struct device *dev;
+ void*data_buffers;
+ dma_addr_t data_buffers_phyaddr;
+ void*ops_buffer;
+ dma_addr_t ops_buffer_phyaddr;
+ void*tmp_buf;
+ unsigned intsync_flags;
+};
+
+static int get_status;
+static int get_id;
+
+#defineNFC_IRQ_ENABLE (IDLE_EN_MASK|WERR_EN_MASK)
+#defineNFC_IRQ_MASK(IDLE_IRQ_MASK|WERR_IRQ_MASK)
+
+#defineMPC5125_NFC_ECC_STATUS_ADD (NFC_SPARE_AREA(0)+0xf0)
+
+#if 1
+/* for ECC_MODE=0x6 45bytes*2 */
+static struct nand_ecclayout nand_hw_eccoob_4k_128 = {
+ .eccbytes = 90, /* actually 72 but only room for 64 */
+ .eccpos = {
+ /* 9 bytes of ecc for each 512 bytes of data */
+ 19, 20, 21, 22, 23, 24, 25, 26, 27,
+
[PATCH 3/4] fs_enet: Add initial support for TWR-MPC5125
Add PHY interface selection.
On TWR-MPC5125 PHY2 connected through RMII.
Signed-off-by: Vladimir Ermakov
---
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index fc073b5..132966b 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -32,3 +32,16 @@ config FS_ENET_MDIO_FCC
tristate "MDIO driver for FCC"
depends on FS_ENET && CPM2
select MDIO_BITBANG
+
+choice FS_ENET_RCNTRL
+ prompt "PHY connection interface"
+ default FS_ENET_MII
+ depends on FS_ENET_MPC5121_FEC
+
+config FS_ENET_RCNTRL_MII
+ bool "MII"
+
+config FS_ENET_RCNTRL_RMII
+ bool "RMII"
+
+endchoice
diff --git a/drivers/net/fs_enet/fec.h b/drivers/net/fs_enet/fec.h
index e980527..468be6e 100644
--- a/drivers/net/fs_enet/fec.h
+++ b/drivers/net/fs_enet/fec.h
@@ -26,6 +26,7 @@
#define FEC_RCNTRL_BC_REJ 0x0010
#define FEC_RCNTRL_PROM0x0008
#define FEC_RCNTRL_MII_MODE0x0004
+#define FEC_RCNTRL_RMII_MODE 0x0124
#define FEC_RCNTRL_DRT 0x0002
#define FEC_RCNTRL_LOOP0x0001
@@ -33,6 +34,11 @@
#define FEC_TCNTRL_HBC 0x0002
#define FEC_TCNTRL_GTS 0x0001
+#ifdef CONFIG_FS_ENET_RCNTRL_MII
+#define FEC_RCNTRL_PHY_MODE FEC_RCNTRL_MII_MODE
+#else /* CONFIG_FS_ENET_RCNTRL_RMII */
+#define FEC_RCNTRL_PHY_MODE FEC_RCNTRL_RMII_MODE
+#endif
/*
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 61035fc..d43e56d 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -319,13 +319,13 @@ static void restart(struct net_device *dev)
#ifndef CONFIG_FS_ENET_MPC5121_FEC
FW(fecp, ivec, (virq_to_hw(fep->interrupt) / 2) << 29);
- FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
+ FW(fecp, r_cntrl, FEC_RCNTRL_PHY_MODE); /* MII/RMII enable */
#else
/*
-* Only set MII mode - do not touch maximum frame length
+* Only set MII/RMII mode - do not touch maximum frame length
* configured before.
*/
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE);
+ FS(fecp, r_cntrl, FEC_RCNTRL_PHY_MODE);
#endif
/*
* adjust to duplex mode
@@ -381,7 +381,7 @@ static void stop(struct net_device *dev)
/* shut down FEC1? that's where the mii bus is */
if (fpi->has_phy) {
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
+ FS(fecp, r_cntrl, FEC_RCNTRL_PHY_MODE); /* MII/RMII enable */
FS(fecp, ecntrl, FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN);
FW(fecp, ievent, FEC_ENET_MII);
FW(fecp, mii_speed, feci->mii_speed);
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 7e840d3..bb61ff6 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -161,7 +161,7 @@ static int __devinit fs_enet_mdio_probe(struct
platform_device *ofdev)
fec->mii_speed = speed << 1;
- setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+ setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_PHY_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] serial: Add initial support for TWR-MPC5125
Adds PSC UART support for MPC5125 SoC.
MPC5125 has different registers than in MPC5121.
Signed-off-by: Vladimir Ermakov
---
diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h
b/arch/powerpc/include/asm/mpc52xx_psc.h
index 2966df6..7bff52f 100644
--- a/arch/powerpc/include/asm/mpc52xx_psc.h
+++ b/arch/powerpc/include/asm/mpc52xx_psc.h
@@ -150,6 +150,51 @@
/* Structure of the hardware registers */
struct mpc52xx_psc {
+#ifdef CONFIG_PPC_MPC5125
+ u8 mr1;/* PSC + 0x00 */
+ u8 reserved0[3];
+ u8 mr2;/* PSC + 0x04 */
+ u8 reserved1[3];
+ u16 mpc52xx_psc_status; /* PSC + 0x08 */
+ u8 reserved2[2];
+ u8 mpc52xx_psc_clock_select; /* PSC + 0x0c */
+ u8 reserved3[3];
+ u8 command;/* PSC + 0x10 */
+ u8 reserved4[3];
+ union { /* PSC + 0x14 */
+ u8 buffer_8;
+ u16 buffer_16;
+ u32 buffer_32;
+ } buffer;
+#define mpc52xx_psc_buffer_8 buffer.buffer_8
+#define mpc52xx_psc_buffer_16 buffer.buffer_16
+#define mpc52xx_psc_buffer_32 buffer.buffer_32
+ u8 mpc52xx_psc_ipcr; /* PSC + 0x18 */
+ u8 reserved5[3];
+ u8 mpc52xx_psc_acr;/* PSC + 0x1c */
+ u8 reserved6[3];
+ u16 mpc52xx_psc_isr;/* PSC + 0x20 */
+ u8 reserved7[2];
+ u16 mpc52xx_psc_imr;/* PSC + 0x24 */
+ u8 reserved8[2];
+ u8 ctur; /* PSC + 0x28 */
+ u8 reserved9[3];
+ u8 ctlr; /* PSC + 0x2c */
+ u8 reserved10[3];
+ u32 ccr;/* PSC + 0x30 */
+ u32 ac97slots; /* PSC + 0x34 */
+ u32 ac97cmd;/* PSC + 0x38 */
+ u32 ac97data; /* PSC + 0x3c */
+ u8 reserved11[4];
+ u8 ip; /* PSC + 0x44 */
+ u8 reserved12[3];
+ u8 op1;/* PSC + 0x48 */
+ u8 reserved13[3];
+ u8 op0;/* PSC + 0x4c */
+ u8 reserved14[3];
+ u32 sicr; /* PSC + 0x50 */
+ u8 reserved15[4];
+#else
u8 mode; /* PSC + 0x00 */
u8 reserved0[3];
union { /* PSC + 0x04 */
@@ -212,6 +257,7 @@ struct mpc52xx_psc {
u8 reserved16[3];
u8 irfdr; /* PSC + 0x54 */
u8 reserved17[3];
+#endif
};
struct mpc52xx_psc_fifo {
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index a0bcd8a..8e4c6b0 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -128,7 +128,11 @@ static inline void mpc52xx_set_divisor(struct mpc52xx_psc
__iomem *psc,
u16 prescaler, unsigned int divisor)
{
/* select prescaler */
+#ifdef CONFIG_PPC_MPC5125
+ out_8(&psc->mpc52xx_psc_clock_select, prescaler >> 8);
+#else
out_be16(&psc->mpc52xx_psc_clock_select, prescaler);
+#endif
out_8(&psc->ctur, divisor >> 8);
out_8(&psc->ctlr, divisor & 0xff);
}
@@ -345,7 +349,11 @@ static unsigned int psc_fifoc_irq;
static void mpc512x_psc_fifo_init(struct uart_port *port)
{
/* /32 prescaler */
+#ifdef CONFIG_PPC_MPC5125
+ out_8(&PSC(port)->mpc52xx_psc_clock_select, 0xdd);
+#else
out_be16(&PSC(port)->mpc52xx_psc_clock_select, 0xdd00);
+#endif
out_be32(&FIFO_512x(port)->txcmd, MPC512x_PSC_FIFO_RESET_SLICE);
out_be32(&FIFO_512x(port)->txcmd, MPC512x_PSC_FIFO_ENABLE_SLICE);
@@ -816,9 +824,14 @@ mpc52xx_uart_set_termios(struct uart_port *port, struct
ktermios *new,
out_8(&psc->command, MPC52xx_PSC_RST_TX);
/* Send new mode settings */
+#ifdef CONFIG_PPC_MPC5125
+ out_8(&psc->mr1, mr1);
+ out_8(&psc->mr2, mr2);
+#else
out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
out_8(&psc->mode, mr1);
out_8(&psc->mode, mr2);
+#endif
baud = psc_ops->set_baudrate(port, new, old);
/* Update the per-port timeout */
@@ -1107,8 +1120,12 @@ mpc52xx_console_get_options(struct uart_port *port,
pr_debug("mpc52xx_console_get_options(port=%p)\n", port);
/* Read the mode registers */
+#ifdef CONFIG_PPC_MPC5125
+ mr1 = in_8(&psc->mr1);
+#else
out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
mr1 = in_8(&psc->mode);
+#endif
/* CT{U,L}R are write-only ! */
*ba
Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
hi all, here instead the log from serial debug console booting the last working kernel i.e. linux-2.16.62 compiled with arch=ppc . [...] do_load: dev="/ide/disk:0" dlen=11 args="CRUX root=/dev/hdb video=radeonfb:800x600" alen=41 do_load: alstr="" try_load: dev="/ide/disk:0" dlen=11 args="CRUX root=/dev/hdb video=radeonfb:800x600" alen=41 create_well_formed_chain: pkg=0xFD57D58 parent=0xFD53B90 currpkg=0xFD53B90 inst=0xFE6EE50 pkg=/pci@8000 parent=/ currpkg=/ currinst=/ create_well_formed_chain: pkg=0xFD53B90 parent=0x0 currpkg=0xFD53B90 inst=0xFE6EE50 pkg=/ parent= currpkg=/ currinst=/ pkg=0xFD57D58:/pci@8000 parent=0xFE6EE50:/ inst=0xFE6EEA8:/pci@8000 instparent=0xFE6EE50 ata_disk_open: pkg=0xFD5B870 parent=0xFD5B2C8 ata_disk_open: CTLR=0x0 ID=0x0 ata_disk_open: args="0" deblocker open ata_disk_max_transfer: 512 deblocker open: block-size=0x200 max-transfer=0x200 deblocker open: return 0 open-package: ret=0:no error r=-1 ata_disk_open: $open-package deblocker ret=0 ata_disk_open: deblocker=0xFE6EFC8 disk-label open disk-label open: self=0xFE702B0 s->buf=0xFE71000 disk-label open: return 0 open-package: ret=0:no error r=-1 ata_disk_open: $open-package disk-label ret=0 ata_disk_open: disklabel=0xFE70258 disk-label load: addr=0x40 loadargs=CRUX root=/dev/hdb video=radeonfb:800x600 args=0,CRUX root=/dev/hdb video=radeonfb:800x600 file_system: e=0xFD8 disk=0xFE6EF58 loc=0x0 start=0x0 path=0xFE703C0 buf=0xFE71000 size=512 file_system: probing filesys dos-partition dos_partition: enter dos-partition: boot_sect_sig0/1=0x55.0xAA jump=0x0 boot_signature=0x0 drive_number=0x0 dos_partition: partition=0 size=0x32F8E start=0x3F typ=0x6 flag=0x80 shd=0x1 ssect=0x1 scyl=0x0 ehd=0xFE esect=0x3F ecyl=0xC file_system: e=0xFD8 disk=0xFE6EF58 loc=0x7E00 start=0x3F path=0xFE703C2 buf=0xFE71000 size=512 file_system: probing filesys dos-partition file_system: probing filesys dos-fat file_system: return end (-4089) file_system: return end (-4089) disk-label return len=1782093 ret=end (-4089) ata_disk_close disk-label close: checking exec type Fcode fcode_is_exec: load=0x40 loadlen=1782093 checking exec type Forth checking exec type ELF f_go: checking exec type Fcode fcode_is_exec: load=0x40 loadlen=1782093 checking exec type Forth checking exec type ELF alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914 alloc_constrained: min 0x0, max 0x, align 0x1000, mask 0x, size 0x7E, addr 0x30 alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1 0xFD54910 u2 0xFD54914 u3 0xFD54918 alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x30 size 0xFD0 alloc_constrained: fsblock 0x0 alloc_constrained: addr[] 0x30 alloc_constrained: bsize[] 0xFD0 alloc_constrained: passed min check alloc_constrained: addr 0x30, align 0xFFF, off 0x69696969 sum 0x0 alloc_constrained: passed align check alloc_constrained: passed max check alloc_constrained: passed mask check alloc_constrained: passed full size check alloc_constrained: passed size check i'm not an expert but from a quick logs comparison I saw two times the alloc_aligned,alloc_constrained section instead in the working one i see it only one time. Maybe it's an usefull observation. cheers, Nell -- 1861 - 2011: 150 years of Italian Unity ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powerpc/mpc512x: Add initial support for TWR-MPC5125
Adds Freescale TWR-MPC5125 device tree and platform code.
Currently following is supported:
- NAND
- FEC1 and FEC2
- RTC
- PSC UART
Signed-off-by: Vladimir Ermakov
---
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts
b/arch/powerpc/boot/dts/mpc5125twr.dts
new file mode 100644
index 000..54f568f
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -0,0 +1,394 @@
+/*
+ * STx/Freescale ADS5125 MPC5125 silicon
+ *
+ * Copyright (C) 2009 Freescale Semiconductor Inc. All rights reserved.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "mpc5125ads";
+ compatible = "fsl,mpc5125ads";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5125@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <4950>;// 49.5 MHz (csb/4)
+ bus-frequency = <19800>;// 198 MHz csb bus
+ clock-frequency = <39600>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ sram@3000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x3000 0x08000>; // 32K at 0x3000
+ };
+
+ nfc@4000 {
+ compatible = "fsl,mpc5125-nfc";
+ reg = <0x4000 0x10>;// 1M at 0x4000
+ interrupts = <6 0x8>;
+ interrupt-parent = < &ipic >;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <1>;
+ write-size = <4096>;
+ spare-size = <128>;
+ chips = <1>;
+ // NOTE: partition map different than in BSP
+ nand-spl@0 {
+ label = "loader";
+ reg = <0x 0x0010>;
+ read-only;
+ };
+ uboot@10 {
+ label = "uboot";
+ reg = <0x0010 0x0010>;
+ read-only;
+ };
+ uboot-env@20 {
+ label = "uboot-env";
+ reg = <0x0020 0x0010>;
+ read-only;
+ };
+ kernel30 {
+ label = "kernel";
+ reg = <0x0030 0x0080>;
+ };
+ device-tree0 {
+ label = "device-tree";
+ reg = <0x00b0 0x0010>;
+ };
+ ramboot-rootfs@c0 {
+ label = "ramboot-rootfs";
+ reg = <0x00c0 0x0080>;
+ };
+ rootfs@140 {
+ label = "rootfs";
+ reg = <0x0140 0x0140>;
+ };
+ user@280 {
+ label = "user";
+ reg = <0x0280 0x0140>;
+ };
+ SRAM@420 {
+ label = "SRAM"; // NVRAM emul
+ reg = <0x0420 0x0140>;
+ };
+ prom@560 {
+ label = "prom";
+ reg = <0x0560 0x0140>;
+ };
+ //data@280 {
+ // label = "data";
+ // reg = <0x2800 0xeac0>;
+ //};
+ };
+
+ soc@8000 {
+ compatible = "fsl,mpc5121-immr";
+ device_type = "soc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+
Re: [PATCH v2 21/28] powerpc: sysdev/mpc8xxx_gpio irq_data conversion.
> "Lennert" == Lennert Buytenhek writes: Lennert> Signed-off-by: Lennert Buytenhek Lennert> --- Lennert> v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d) Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: perf: Handle events that raise an exception without overflowing
On Wed, 2011-03-16 at 13:50 +0100, Ingo Molnar wrote: > * Anton Blanchard wrote: > > > > > Events on POWER7 can roll back if a speculative event doesn't > > eventually complete. Unfortunately in some rare cases they will > > raise a performance monitor exception. We need to catch this to > > ensure we reset the PMC. In all cases the PMC will be 256 or less > > cycles from overflow. > > > > Signed-off-by: Anton Blanchard > > Cc: sta...@kernel.org > > --- > > > > I would prefer not to add the PVR check, but I think we want to limit > > this workaround to POWER7. Would a cpu feature be preferable? > > There was no objection from the PowerPC folks so i'll send this fix > Linuswards, ok? Ah yes. Ack. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote: > > 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style > > problems and is ready for submission. > > > > Documentation/powerpc/dts-bindings/sm501.txt | 34 + > > drivers/mfd/sm501.c |9 +- > > drivers/video/sm501fb.c | 42 > > -- > > 3 files changed, 81 insertions(+), 4 deletions(-) > > create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt > > This patchset is pending know for a while. I got Acked by from > > Samuel Ortiz for the mfd part, see here: > > http://www.spinics.net/lists/linux-fbdev/msg02550.html > http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html > > and for the DTS part from Benjamin Herrenschmidt: > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html > > Are there some more issues? > Not that I remember off the top of my head, but I think they've been lost in my backlog. Could you re-send the current series with the appropriate acked-bys? If there's nothing else obvious outstanding I'll roll them in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V12 0/4] ptp: IEEE 1588 hardware clock support
On Mon, Feb 28, 2011 at 08:57:03AM +0100, Richard Cochran wrote: > * PHC Patch ChangeLog > ** v12 > *** gianfar_ptp >- fixed up device tree >- inlined the header file >- use platform_ calls instead of deprecated of_ calls >- removed static global single instance >- removed John Stultz's ack from this patch @Thomas and John: Can I get your acks on the remaining patches? Can this be merged for 2.6.39? Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/ptrace: remove BUG_ON when full register set not available
In some cases during a threaded core dump not all
the threads will have a full register set. This
will cause problems when the sigkill is sent to
the thread. To solve this problem a poison value
(0xdeadbeef) will be placed in the buffer in place
of the actual register values. This will affect
gpr14 to gpr31.
Signed-off-by: Mike Wolf
--
--- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/include/asm/ptrace.h
2010-08-31 23:56:50.0 -0500
+++ linux-2.6.32-71.el6.ppc64/arch/powerpc/include/asm/ptrace.h 2011-03-14
11:43:33.176667099 -0500
@@ -123,8 +123,14 @@ extern int ptrace_put_reg(struct task_st
#define TRAP(regs) ((regs)->trap & ~0xF)
#ifdef __powerpc64__
#define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
+#define PARTIAL_REG_FILL 0xdeadbeefdeadbeefUL
+#define PARTIAL_REG_START 14
+#define PARTIAL_REG_END31
#else
#define CHECK_FULL_REGS(regs)\
+#define PARTIAL_REG_FILL 0xdeadbeef
+#define PARTIAL_REG_START 14
+#define PARTIAL_REG_END31
do { \
if ((regs)->trap & 1) \
printk(KERN_CRIT "%s: partial register set\n", __func__); \
--- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/kernel/ptrace.c 2009-12-02
21:51:21.0 -0600
+++ linux-2.6.32-71.el6.ppc64/arch/powerpc/kernel/ptrace.c 2011-03-14
13:01:51.955586126 -0500
@@ -125,11 +125,16 @@ static int gpr_get(struct task_struct *t
void *kbuf, void __user *ubuf)
{
int ret;
+ int partial_reg;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs))
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
+ partial_reg++)
+ target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
target->thread.regs,
@@ -536,11 +541,16 @@ static int gpr32_get(struct task_struct
compat_ulong_t *k = kbuf;
compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
+ int partial_reg;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs))
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
+ partial_reg++)
+ target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
pos /= sizeof(reg);
count /= sizeof(reg);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: perf: Handle events that raise an exception without overflowing
* Anton Blanchard wrote: > > Events on POWER7 can roll back if a speculative event doesn't > eventually complete. Unfortunately in some rare cases they will > raise a performance monitor exception. We need to catch this to > ensure we reset the PMC. In all cases the PMC will be 256 or less > cycles from overflow. > > Signed-off-by: Anton Blanchard > Cc: sta...@kernel.org > --- > > I would prefer not to add the PVR check, but I think we want to limit > this workaround to POWER7. Would a cpu feature be preferable? There was no objection from the PowerPC folks so i'll send this fix Linuswards, ok? Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Powerpc gcc error for mpc8315erdb board
Hi I am facing a problem with my powerpc gcc. Actually i am using a ltib to configure the kernel and the file system for my mpc8315erdb board from linux 2.6 host machine. and the installation of kernel and filesystem is successful. i don't have "make" installed in the board and i wanted to compile cgic library (an ANSI C library for cgi) for the board, hence i compiled it on the linux host machine itself but instead of using gcc i used powerpc-e300c3-linux-gnu-gcc which corresponds to the gcc of the mpc8315erdb board. however i get an error saying powerpc-e300c3-linux-gnu-gcc: error trying to exec 'cc1': execvp: No such file or directory however powerpc-e300c3-linux-gnu-gcc is present in /usr/local/bin on the linux host machine and this directory is part of the path. so powerpc does exist on the host machine. if the error comes on the host linux then i would look for /usr/libexec/gcc/i486-slackware-linux/4.2.4/ but how do i rectify in this scenario. the makefile for the cgic was modified according to the powerpc architecture and i am attaching here below. Kindly help! plz! http://old.nabble.com/file/p31162979/Makefile Makefile -- View this message in context: http://old.nabble.com/Powerpc-gcc-error-for-mpc8315erdb-board-tp31162979p31162979.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Powerpc gcc error for mpc8315erdb board
Hi I am facing a problem with my powerpc gcc. Actually i am using a ltib to configure the kernel and the file system for my mpc8315erdb board from linux 2.6 host machine. and the installation of kernel and filesystem is successful. i don't have "make" installed in the board and i wanted to compile cgic library (an ANSI C library for cgi) for the board, hence i compiled it on the linux host machine itself but instead of using gcc i used powerpc-e300c3-linux-gnu-gcc which corresponds to the gcc of the mpc8315erdb board. however i get an error saying powerpc-e300c3-linux-gnu-gcc: error trying to exec 'cc1': execvp: No such file or directory however powerpc-e300c3-linux-gnu-gcc is present in /usr/local/bin on the linux host machine and this directory is part of the path. so powerpc does exist on the host machine. if the error comes on the host linux then i would look for /usr/libexec/gcc/i486-slackware-linux/4.2.4/ but how do i rectify in this scenario. the makefile for the cgic was modified according to the powerpc architecture and i am attaching here. Kindly help! plz! http://old.nabble.com/file/p31162962/Makefile Makefile -- View this message in context: http://old.nabble.com/Powerpc-gcc-error-for-mpc8315erdb-board-tp31162962p31162962.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, Stephen Rothwell wrote:
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write':
> drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this
> function)
> drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff':
> drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this
> function)
>
> Caused by commit 823ed5091113 ("UBI: allocate write checking buffer on
> demand").
>
> I don't know how to fix this, so I have left it for today.
Fixed, sorry for the hassle and thank you!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 21:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote:
> > On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the final tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write':
> > > drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in
> > > this function)
> > > drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff':
> > > drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in
> > > this function)
> > >
> > > Caused by commit 823ed5091113 ("UBI: allocate write checking buffer on
> > > demand").
> > >
> > > I don't know how to fix this, so I have left it for today.
> >
> > Hmm, strange, include should be enough to use
> > __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll
> > try to look better.
>
> Try adding asm/pgtable.h
Thanks, that's what I was thinking about as well.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write':
> drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this
> function)
> drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff':
> drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this
> function)
>
> Caused by commit 823ed5091113 ("UBI: allocate write checking buffer on
> demand").
>
> I don't know how to fix this, so I have left it for today.
Hmm, strange, include should be enough to use
__vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll
try to look better.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote:
> On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the final tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write':
> > drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in
> > this function)
> > drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff':
> > drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in
> > this function)
> >
> > Caused by commit 823ed5091113 ("UBI: allocate write checking buffer on
> > demand").
> >
> > I don't know how to fix this, so I have left it for today.
>
> Hmm, strange, include should be enough to use
> __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll
> try to look better.
Try adding asm/pgtable.h
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
On Wed, Mar 16, 2011 at 01:23:19AM +0100, acrux wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 15 Mar 2011 22:41:49 +0100 > Sven Luther wrote: > > > On Tue, Mar 15, 2011 at 09:08:55PM +0100, Gerhard Pircher wrote: > > > > > > > Well, since this is long dead hardware not produced anymore, i > > > > don't see how the OF could have unbroken itself by moving to > > > > powerpc. > > > > > > > > It has been age since i looked into this, but to the best of my > > > > knowledge (and i wrote the above code or at least the earlier > > > > versions) it should be still broken. > > > Any idea then, how the workaround can be ported to arch/powerpc/ or > > > if there is a better one available? > > > > Sorry, it has been years since i looked these parts of the linux > > kernel, so i don't really know how the arch/powerpc code handles this > > differently. Your best guess is to hunt for the code yourself, and > > find the place. I don't remember though if debugging at that time is > > easily possible though. > > > > if chrp support doesn't anymore include Pegasos1 it could be nice to > remove all that dead code. Albeit it's fun that nobody cared about for > it during the ppc=>powerpc switch as Pegasos1 was retired in 2003 > and linux-2.6.17 was released in 2006... about three years. Also, the Pegasos2 OF implementation corrected these issues. Notice that 2006 was also the year that debian sabotaged all powerpc work, and had me expulsed because some people in the debian-installer team didn't support technical critics and had more political pull inside debian than myself. This happening after almost a decade of me giving my time to debian, i kind of lost interest at that point, and nobody stepped up to take over my work. And on top of that, Franz Pop commited suicide last year, which could possibly have been avoided if debian's leadership would have showed more maturity and responsability back then. Sorry for the off topic rant, but this is something which did take a really long time for me to get over, and i believe that the debian folk are still not ready to let it go. I am still censored on debian mailing lists today and probably banned from irc channels. Sadly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
