* [PATCH] ppc32: cleanup AMCC PPC40x eval boards to support U-Boot
From: Stefan Roese @ 2005-09-30 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200509191320.09661.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Cleanup PPC40x eval boards (bubinga, walnut and sycamore) to support
U-Boot as bootloader. The OpenBIOS bd_info struct is not used in the
kernel anymore (only U-Boot now).
uImage (U-Boot) tested on walnut, sycamore and bubinga
zImage (OpenBIOS) tested on sycamore, bubinga and ebony
Signed-off-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
[-- Attachment #2: ppc40x_u-boot_ver3.patch --]
[-- Type: text/x-diff, Size: 24788 bytes --]
[PATCH] ppc32: cleanup AMCC PPC40x eval boards to support U-Boot
Cleanup PPC40x eval boards (bubinga, walnut and sycamore) to support
U-Boot as bootloader. The OpenBIOS bd_info struct is not used in the
kernel anymore (only U-Boot now).
uImage (U-Boot) tested on walnut, sycamore and bubinga
zImage (OpenBIOS) tested on sycamore, bubinga and ebony
Signed-off-by: Stefan Roese <sr@denx.de>
---
commit 19ab675965e6f687530ad346f20809a5f530a3a2
tree fe91729c3f1256f9239b9c9395fc8fb52c66a028
parent 8ddec7460d2f5db3ac35812c03676b1473d1d668
author Stefan Roese <sr@denx.de> Fri, 30 Sep 2005 13:51:39 +0200
committer Stefan Roese <sr@denx.de> Fri, 30 Sep 2005 13:51:39 +0200
arch/ppc/boot/simple/Makefile | 21 +++++++
arch/ppc/boot/simple/misc.c | 16 +++++-
arch/ppc/boot/simple/openbios.c | 106 +++++++++++++++++++++++++++++++++++--
arch/ppc/platforms/4xx/Kconfig | 2 -
arch/ppc/platforms/4xx/bubinga.c | 2 -
arch/ppc/platforms/4xx/bubinga.h | 64 +++++++++-------------
arch/ppc/platforms/4xx/ebony.h | 4 +
arch/ppc/platforms/4xx/sycamore.c | 7 +-
arch/ppc/platforms/4xx/sycamore.h | 67 +++++++++--------------
arch/ppc/platforms/4xx/walnut.c | 2 -
arch/ppc/platforms/4xx/walnut.h | 67 +++++++++--------------
include/asm-ppc/ibm_ocp.h | 19 ++++++-
include/asm-ppc/ppcboot.h | 6 +-
13 files changed, 237 insertions(+), 146 deletions(-)
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -67,6 +67,12 @@ zimageinitrd-$(CONFIG_BAMBOO) := zImage
entrypoint-$(CONFIG_BAMBOO) := 0x01000000
extra.o-$(CONFIG_BAMBOO) := pibs.o
+ zimage-$(CONFIG_BUBINGA) := zImage-TREE
+zimageinitrd-$(CONFIG_BUBINGA) := zImage.initrd-TREE
+ end-$(CONFIG_BUBINGA) := bubinga
+ entrypoint-$(CONFIG_BUBINGA) := 0x01000000
+ extra.o-$(CONFIG_BUBINGA) := openbios.o
+
zimage-$(CONFIG_EBONY) := zImage-TREE
zimageinitrd-$(CONFIG_EBONY) := zImage.initrd-TREE
end-$(CONFIG_EBONY) := ebony
@@ -85,6 +91,18 @@ zimageinitrd-$(CONFIG_OCOTEA) := zImage
entrypoint-$(CONFIG_OCOTEA) := 0x01000000
extra.o-$(CONFIG_OCOTEA) := pibs.o
+ zimage-$(CONFIG_SYCAMORE) := zImage-TREE
+zimageinitrd-$(CONFIG_SYCAMORE) := zImage.initrd-TREE
+ end-$(CONFIG_SYCAMORE) := sycamore
+ entrypoint-$(CONFIG_SYCAMORE) := 0x01000000
+ extra.o-$(CONFIG_SYCAMORE) := openbios.o
+
+ zimage-$(CONFIG_WALNUT) := zImage-TREE
+zimageinitrd-$(CONFIG_WALNUT) := zImage.initrd-TREE
+ end-$(CONFIG_WALNUT) := walnut
+ entrypoint-$(CONFIG_WALNUT) := 0x01000000
+ extra.o-$(CONFIG_WALNUT) := openbios.o
+
extra.o-$(CONFIG_EV64260) := misc-ev64260.o
end-$(CONFIG_EV64260) := ev64260
cacheflag-$(CONFIG_EV64260) := -include $(clear_L2_L3)
@@ -162,7 +180,8 @@ OBJCOPY_ARGS := -O elf32-powerpc
# head.o and relocate.o must be at the start.
boot-y := head.o relocate.o $(extra.o-y) $(misc-y)
-boot-$(CONFIG_40x) += embed_config.o
+boot-$(CONFIG_REDWOOD_5) += embed_config.o
+boot-$(CONFIG_REDWOOD_6) += embed_config.o
boot-$(CONFIG_8xx) += embed_config.o
boot-$(CONFIG_8260) += embed_config.o
boot-$(CONFIG_BSEIP) += iic.o
diff --git a/arch/ppc/boot/simple/misc.c b/arch/ppc/boot/simple/misc.c
--- a/arch/ppc/boot/simple/misc.c
+++ b/arch/ppc/boot/simple/misc.c
@@ -23,7 +23,7 @@
#include <asm/page.h>
#include <asm/mmu.h>
#include <asm/bootinfo.h>
-#ifdef CONFIG_44x
+#ifdef CONFIG_4xx
#include <asm/ibm4xx.h>
#endif
#include <asm/reg.h>
@@ -88,6 +88,14 @@ get_mem_size(void)
return 0;
}
+#if defined(CONFIG_40x)
+#define PPC4xx_EMAC0_MR0 EMAC0_BASE
+#endif
+
+#if defined(CONFIG_44x) && defined(PPC44x_EMAC0_MR0)
+#define PPC4xx_EMAC0_MR0 PPC44x_EMAC0_MR0
+#endif
+
struct bi_record *
decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum)
{
@@ -103,13 +111,13 @@ decompress_kernel(unsigned long load_add
com_port = serial_init(0, NULL);
#endif
-#if defined(CONFIG_44x) && defined(PPC44x_EMAC0_MR0)
+#if defined(PPC4xx_EMAC0_MR0)
/* Reset MAL */
mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
/* Wait for reset */
while (mfdcr(DCRN_MALCR(DCRN_MAL_BASE)) & MALCR_MMSR) {};
/* Reset EMAC */
- *(volatile unsigned long *)PPC44x_EMAC0_MR0 = 0x20000000;
+ *(volatile unsigned long *)PPC4xx_EMAC0_MR0 = 0x20000000;
__asm__ __volatile__("eieio");
#endif
@@ -164,7 +172,9 @@ decompress_kernel(unsigned long load_add
puts(" "); puthex((unsigned long)(&__ramdisk_end));puts("\n");
}
+#ifndef CONFIG_40x /* don't overwrite the 40x image located at 0x00400000! */
avail_ram = (char *)0x00400000;
+#endif
end_avail = (char *)0x00800000;
puts("avail ram: "); puthex((unsigned long)avail_ram); puts(" ");
puthex((unsigned long)end_avail); puts("\n");
diff --git a/arch/ppc/boot/simple/openbios.c b/arch/ppc/boot/simple/openbios.c
--- a/arch/ppc/boot/simple/openbios.c
+++ b/arch/ppc/boot/simple/openbios.c
@@ -1,19 +1,43 @@
/*
* arch/ppc/boot/simple/openbios.c
*
- * 2005 (c) SYSGO AG - g.jaeger@sysgo.com
+ * Copyright (c) 2005 DENX Software Engineering
+ * Stefan Roese <sr@denx.de>
+ *
+ * Based on original work by
+ * 2005 (c) SYSGO AG - g.jaeger@sysgo.com
+ *
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
*
- * Derived from arch/ppc/boot/simple/pibs.c (from MontaVista)
*/
#include <linux/types.h>
#include <linux/config.h>
#include <linux/string.h>
#include <asm/ppcboot.h>
-#include <platforms/4xx/ebony.h>
+#include <asm/ibm4xx.h>
+#include <asm/reg.h>
+#ifdef CONFIG_40x
+#include <asm/io.h>
+#endif
+
+#if defined(CONFIG_BUBINGA)
+#define BOARD_INFO_VECTOR 0xFFF80B50 /* openbios 1.19 moved this vector down - armin */
+#else
+#define BOARD_INFO_VECTOR 0xFFFE0B50
+#endif
+
+#ifdef CONFIG_40x
+/* Supply a default Ethernet address for those eval boards that don't
+ * ship with one. This is an address from the MBX board I have, so
+ * it is unlikely you will find it on your network.
+ */
+static ushort def_enet_addr[] = { 0x0800, 0x3e26, 0x1559 };
+
+extern unsigned long timebase_period_ns;
+#endif /* CONFIG_40x */
extern unsigned long decompress_kernel(unsigned long load_addr, int num_words,
unsigned long cksum);
@@ -23,15 +47,85 @@ extern unsigned long decompress_kernel(u
bd_t hold_resid_buf __attribute__ ((__section__ (".data.boot")));
bd_t *hold_residual = &hold_resid_buf;
+typedef struct openbios_board_info {
+ unsigned char bi_s_version[4]; /* Version of this structure */
+ unsigned char bi_r_version[30]; /* Version of the IBM ROM */
+ unsigned int bi_memsize; /* DRAM installed, in bytes */
+#ifdef CONFIG_405EP
+ unsigned char bi_enetaddr[2][6]; /* Local Ethernet MAC address */
+#else /* CONFIG_405EP */
+ unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
+#endif /* CONFIG_405EP */
+ unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
+ unsigned int bi_intfreq; /* Processor speed, in Hz */
+ unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
+ unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
+#ifdef CONFIG_405EP
+ unsigned int bi_opb_busfreq; /* OPB Bus speed, in Hz */
+ unsigned int bi_pllouta_freq; /* PLL OUTA speed, in Hz */
+#endif /* CONFIG_405EP */
+} openbios_bd_t;
+
void *
load_kernel(unsigned long load_addr, int num_words, unsigned long cksum,
void *ign1, void *ign2)
{
- decompress_kernel(load_addr, num_words, cksum);
+#ifdef CONFIG_40x
+ openbios_bd_t *openbios_bd = NULL;
+ openbios_bd_t *(*get_board_info)(void) =
+ (openbios_bd_t *(*)(void))(*(unsigned long *)BOARD_INFO_VECTOR);
+
+ /*
+ * On 40x platforms we not only need the MAC-addresses, but also the
+ * clocks and memsize. Now try to get all values using the OpenBIOS
+ * "get_board_info()" callback.
+ */
+ if ((openbios_bd = get_board_info()) != NULL) {
+ /*
+ * Copy bd_info from OpenBIOS struct into U-Boot struct
+ * used by kernel
+ */
+ hold_residual->bi_memsize = openbios_bd->bi_memsize;
+ hold_residual->bi_intfreq = openbios_bd->bi_intfreq;
+ hold_residual->bi_busfreq = openbios_bd->bi_busfreq;
+ hold_residual->bi_pci_busfreq = openbios_bd->bi_pci_busfreq;
+ memcpy(hold_residual->bi_pci_enetaddr, openbios_bd->bi_pci_enetaddr, 6);
+#ifdef CONFIG_405EP
+ memcpy(hold_residual->bi_enetaddr, openbios_bd->bi_enetaddr[0], 6);
+ memcpy(hold_residual->bi_enet1addr, openbios_bd->bi_enetaddr[1], 6);
+ hold_residual->bi_opbfreq = openbios_bd->bi_opb_busfreq;
+ hold_residual->bi_procfreq = openbios_bd->bi_pllouta_freq;
+#else /* CONFIG_405EP */
+ memcpy(hold_residual->bi_enetaddr, openbios_bd->bi_enetaddr, 6);
+#endif /* CONFIG_405EP */
+ } else {
+ /* Hmmm...better try to stuff some defaults.
+ */
+ hold_residual->bi_memsize = 16 * 1024 * 1024;
+ hold_residual->bi_intfreq = 200000000;
+ hold_residual->bi_busfreq = 100000000;
+ hold_residual->bi_pci_busfreq = 66666666;
+
+ /*
+ * Only supply one mac-address in this fallback
+ */
+ memcpy(hold_residual->bi_enetaddr, (void *)def_enet_addr, 6);
+#ifdef CONFIG_405EP
+ hold_residual->bi_opbfreq = 50000000;
+ hold_residual->bi_procfreq = 200000000;
+#endif /* CONFIG_405EP */
+ }
+
+ timebase_period_ns = 1000000000 / hold_residual->bi_intfreq;
+#endif /* CONFIG_40x */
+#ifdef CONFIG_440GP
/* simply copy the MAC addresses */
- memcpy(hold_residual->bi_enetaddr, (char *)EBONY_OPENBIOS_MAC_BASE, 6);
- memcpy(hold_residual->bi_enet1addr, (char *)(EBONY_OPENBIOS_MAC_BASE+EBONY_OPENBIOS_MAC_OFFSET), 6);
+ memcpy(hold_residual->bi_enetaddr, (char *)OPENBIOS_MAC_BASE, 6);
+ memcpy(hold_residual->bi_enet1addr, (char *)(OPENBIOS_MAC_BASE+OPENBIOS_MAC_OFFSET), 6);
+#endif /* CONFIG_440GP */
+
+ decompress_kernel(load_addr, num_words, cksum);
return (void *)hold_residual;
}
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -214,7 +214,7 @@ config EMBEDDEDBOOT
config IBM_OPENBIOS
bool
- depends on ASH || BUBINGA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
+ depends on ASH || REDWOOD_5 || REDWOOD_6
default y
config PPC4xx_DMA
diff --git a/arch/ppc/platforms/4xx/bubinga.c b/arch/ppc/platforms/4xx/bubinga.c
--- a/arch/ppc/platforms/4xx/bubinga.c
+++ b/arch/ppc/platforms/4xx/bubinga.c
@@ -89,7 +89,7 @@ bubinga_early_serial_map(void)
* by 16.
*/
uart_div = (mfdcr(DCRN_CPC0_UCR_BASE) & DCRN_CPC0_UCR_U0DIV);
- uart_clock = __res.bi_pllouta_freq / uart_div;
+ uart_clock = __res.bi_procfreq / uart_div;
/* Setup serial port access */
memset(&port, 0, sizeof(port));
diff --git a/arch/ppc/platforms/4xx/bubinga.h b/arch/ppc/platforms/4xx/bubinga.h
--- a/arch/ppc/platforms/4xx/bubinga.h
+++ b/arch/ppc/platforms/4xx/bubinga.h
@@ -1,52 +1,34 @@
/*
- * Support for IBM PPC 405EP evaluation board (Bubinga).
+ * arch/ppc/platforms/4xx/bubinga.h
*
- * Author: SAW (IBM), derived from walnut.h.
- * Maintained by MontaVista Software <source@mvista.com>
+ * Bubinga board definitions
+ *
+ * Copyright (c) 2005 DENX Software Engineering
+ * Stefan Roese <sr@denx.de>
+ *
+ * Based on original work by
+ * SAW (IBM)
+ * 2003 (c) MontaVista Softare Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
*
- * 2003 (c) MontaVista Softare Inc. This file is licensed under the
- * terms of the GNU General Public License version 2. This program is
- * licensed "as is" without any warranty of any kind, whether express
- * or implied.
*/
#ifdef __KERNEL__
#ifndef __BUBINGA_H__
#define __BUBINGA_H__
-/* 405EP */
+#include <linux/config.h>
#include <platforms/4xx/ibm405ep.h>
-
-#ifndef __ASSEMBLY__
-/*
- * Data structure defining board information maintained by the boot
- * ROM on IBM's evaluation board. An effort has been made to
- * keep the field names consistent with the 8xx 'bd_t' board info
- * structures.
- */
-
-typedef struct board_info {
- unsigned char bi_s_version[4]; /* Version of this structure */
- unsigned char bi_r_version[30]; /* Version of the IBM ROM */
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[2][6]; /* Local Ethernet MAC address */ unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
- unsigned int bi_opb_busfreq; /* OPB Bus speed, in Hz */
- unsigned int bi_pllouta_freq; /* PLL OUTA speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
-
+#include <asm/ppcboot.h>
/* Memory map for the Bubinga board.
* Generic 4xx plus RTC.
*/
-extern void *bubinga_rtc_base;
#define BUBINGA_RTC_PADDR ((uint)0xf0000000)
#define BUBINGA_RTC_VADDR BUBINGA_RTC_PADDR
#define BUBINGA_RTC_SIZE ((uint)8*1024)
@@ -58,12 +40,18 @@ extern void *bubinga_rtc_base;
* for typical configurations at various CPU speeds.
* The base baud is calculated as (FWDA / EXT UART DIV / 16)
*/
-#define BASE_BAUD 0
+#define BASE_BAUD 0
-#define BUBINGA_FPGA_BASE 0xF0300000
+/* Flash */
+#define PPC40x_FPGA_BASE 0xF0300000
+#define PPC40x_FPGA_REG_OFFS 1 /* offset to flash map reg */
+#define PPC40x_FLASH_ONBD_N(x) (x & 0x02)
+#define PPC40x_FLASH_SRAM_SEL(x) (x & 0x01)
+#define PPC40x_FLASH_LOW 0xFFF00000
+#define PPC40x_FLASH_HIGH 0xFFF80000
+#define PPC40x_FLASH_SIZE 0x80000
-#define PPC4xx_MACHINE_NAME "IBM Bubinga"
+#define PPC4xx_MACHINE_NAME "IBM Bubinga"
-#endif /* !__ASSEMBLY__ */
#endif /* __BUBINGA_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/ebony.h b/arch/ppc/platforms/4xx/ebony.h
--- a/arch/ppc/platforms/4xx/ebony.h
+++ b/arch/ppc/platforms/4xx/ebony.h
@@ -24,8 +24,8 @@
#define PPC44x_EMAC0_MR0 0xE0000800
/* Where to find the MAC info */
-#define EBONY_OPENBIOS_MAC_BASE 0xfffffe0c
-#define EBONY_OPENBIOS_MAC_OFFSET 0x0c
+#define OPENBIOS_MAC_BASE 0xfffffe0c
+#define OPENBIOS_MAC_OFFSET 0x0c
/* Default clock rates for Rev. B and Rev. C silicon */
#define EBONY_440GP_RB_SYSCLK 33000000
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -88,9 +88,6 @@ ppc405_map_irq(struct pci_dev *dev, unsi
void __init
sycamore_setup_arch(void)
{
-#define SYCAMORE_PS2_BASE 0xF0100000
-#define SYCAMORE_FPGA_BASE 0xF0300000
-
void *fpga_brdc;
unsigned char fpga_brdc_data;
void *fpga_enable;
@@ -100,7 +97,7 @@ sycamore_setup_arch(void)
ppc4xx_setup_arch();
- ibm_ocp_set_emac(0, 1);
+ ibm_ocp_set_emac(0, 0);
kb_data = ioremap(SYCAMORE_PS2_BASE, 8);
if (!kb_data) {
@@ -111,7 +108,7 @@ sycamore_setup_arch(void)
kb_cs = kb_data + 1;
- fpga_status = ioremap(SYCAMORE_FPGA_BASE, 8);
+ fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
if (!fpga_status) {
printk(KERN_CRIT
"sycamore_setup_arch() fpga_status ioremap failed\n");
diff --git a/arch/ppc/platforms/4xx/sycamore.h b/arch/ppc/platforms/4xx/sycamore.h
--- a/arch/ppc/platforms/4xx/sycamore.h
+++ b/arch/ppc/platforms/4xx/sycamore.h
@@ -1,67 +1,52 @@
/*
* arch/ppc/platforms/4xx/sycamore.h
*
- * Macros, definitions, and data structures specific to the IBM PowerPC
- * 405GPr "Sycamore" evaluation board.
+ * Sycamore board definitions
*
- * Author: Armin Kuster <akuster@mvista.com>
+ * Copyright (c) 2005 DENX Software Engineering
+ * Stefan Roese <sr@denx.de>
+ *
+ * Based on original work by
+ * Armin Kuster <akuster@mvista.com>
+ * 2000 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
*
- * 2000 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
*/
#ifdef __KERNEL__
#ifndef __ASM_SYCAMORE_H__
#define __ASM_SYCAMORE_H__
+#include <linux/config.h>
#include <platforms/4xx/ibm405gpr.h>
+#include <asm/ppcboot.h>
-#ifndef __ASSEMBLY__
-/*
- * Data structure defining board information maintained by the boot
- * ROM on IBM's "Sycamore" evaluation board. An effort has been made to
- * keep the field names consistent with the 8xx 'bd_t' board info
- * structures.
- */
-
-typedef struct board_info {
- unsigned char bi_s_version[4]; /* Version of this structure */
- unsigned char bi_r_version[30]; /* Version of the IBM ROM */
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
-
-
-/* Memory map for the IBM "Sycamore" 405GP evaluation board.
+/* Memory map for the IBM "Sycamore" 405GPr evaluation board.
* Generic 4xx plus RTC.
*/
-extern void *sycamore_rtc_base;
#define SYCAMORE_RTC_PADDR ((uint)0xf0000000)
#define SYCAMORE_RTC_VADDR SYCAMORE_RTC_PADDR
-#define SYCAMORE_RTC_SIZE ((uint)8*1024)
+#define SYCAMORE_RTC_SIZE ((uint)8*1024)
-#ifdef CONFIG_PPC405GP_INTERNAL_CLOCK
-#define BASE_BAUD 201600
-#else
#define BASE_BAUD 691200
-#endif
-#define SYCAMORE_PS2_BASE 0xF0100000
-#define SYCAMORE_FPGA_BASE 0xF0300000
+#define SYCAMORE_PS2_BASE 0xF0100000
+
+/* Flash */
+#define PPC40x_FPGA_BASE 0xF0300000
+#define PPC40x_FPGA_REG_OFFS 5 /* offset to flash map reg */
+#define PPC40x_FLASH_ONBD_N(x) (x & 0x02)
+#define PPC40x_FLASH_SRAM_SEL(x) (x & 0x01)
+#define PPC40x_FLASH_LOW 0xFFF00000
+#define PPC40x_FLASH_HIGH 0xFFF80000
+#define PPC40x_FLASH_SIZE 0x80000
#define PPC4xx_MACHINE_NAME "IBM Sycamore"
-#endif /* !__ASSEMBLY__ */
#endif /* __ASM_SYCAMORE_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/walnut.c b/arch/ppc/platforms/4xx/walnut.c
--- a/arch/ppc/platforms/4xx/walnut.c
+++ b/arch/ppc/platforms/4xx/walnut.c
@@ -90,7 +90,7 @@ walnut_setup_arch(void)
kb_cs = kb_data + 1;
- fpga_status = ioremap(WALNUT_FPGA_BASE, 8);
+ fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
if (!fpga_status) {
printk(KERN_CRIT
"walnut_setup_arch() fpga_status ioremap failed\n");
diff --git a/arch/ppc/platforms/4xx/walnut.h b/arch/ppc/platforms/4xx/walnut.h
--- a/arch/ppc/platforms/4xx/walnut.h
+++ b/arch/ppc/platforms/4xx/walnut.h
@@ -1,72 +1,55 @@
/*
* arch/ppc/platforms/4xx/walnut.h
*
- * Macros, definitions, and data structures specific to the IBM PowerPC
- * 405GP "Walnut" evaluation board.
+ * Walnut board definitions
*
- * Authors: Grant Erickson <grant@lcse.umn.edu>, Frank Rowand
- * <frank_rowand@mvista.com>, Debbie Chu <debbie_chu@mvista.com> or
- * source@mvista.com
+ * Copyright (c) 2005 DENX Software Engineering
+ * Stefan Roese <sr@denx.de>
*
- * Copyright (c) 1999 Grant Erickson <grant@lcse.umn.edu>
+ * Based on original work by
+ * Copyright (c) 1999 Grant Erickson <grant@lcse.umn.edu>
+ * Frank Rowand <frank_rowand@mvista.com>
+ * Debbie Chu <debbie_chu@mvista.com>
+ * 2000 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
*
- * 2000 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
*/
#ifdef __KERNEL__
#ifndef __ASM_WALNUT_H__
#define __ASM_WALNUT_H__
-/* We have a 405GP core */
+#include <linux/config.h>
#include <platforms/4xx/ibm405gp.h>
-
-#ifndef __ASSEMBLY__
-/*
- * Data structure defining board information maintained by the boot
- * ROM on IBM's "Walnut" evaluation board. An effort has been made to
- * keep the field names consistent with the 8xx 'bd_t' board info
- * structures.
- */
-
-typedef struct board_info {
- unsigned char bi_s_version[4]; /* Version of this structure */
- unsigned char bi_r_version[30]; /* Version of the IBM ROM */
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
-
+#include <asm/ppcboot.h>
/* Memory map for the IBM "Walnut" 405GP evaluation board.
* Generic 4xx plus RTC.
*/
-extern void *walnut_rtc_base;
#define WALNUT_RTC_PADDR ((uint)0xf0000000)
#define WALNUT_RTC_VADDR WALNUT_RTC_PADDR
#define WALNUT_RTC_SIZE ((uint)8*1024)
-#ifdef CONFIG_PPC405GP_INTERNAL_CLOCK
-#define BASE_BAUD 201600
-#else
#define BASE_BAUD 691200
-#endif
#define WALNUT_PS2_BASE 0xF0100000
-#define WALNUT_FPGA_BASE 0xF0300000
+
+/* Flash */
+#define PPC40x_FPGA_BASE 0xF0300000
+#define PPC40x_FPGA_REG_OFFS 5 /* offset to flash map reg */
+#define PPC40x_FLASH_ONBD_N(x) (x & 0x02)
+#define PPC40x_FLASH_SRAM_SEL(x) (x & 0x01)
+#define PPC40x_FLASH_LOW 0xFFF00000
+#define PPC40x_FLASH_HIGH 0xFFF80000
+#define PPC40x_FLASH_SIZE 0x80000
+#define WALNUT_FPGA_BASE PPC40x_FPGA_BASE
#define PPC4xx_MACHINE_NAME "IBM Walnut"
-#endif /* !__ASSEMBLY__ */
#endif /* __ASM_WALNUT_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -131,9 +131,22 @@ static inline void ibm_ocp_set_emac(int
/* Copy MAC addresses to EMAC additions */
for (i=start; i<=end; i++) {
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, i);
- memcpy(((struct ocp_func_emac_data *)def->additions)->mac_addr,
- &__res.bi_enetaddr[i],
- 6);
+ if (i == 0)
+ memcpy(((struct ocp_func_emac_data *)def->additions)->mac_addr,
+ __res.bi_enetaddr, 6);
+#if defined(CONFIG_405EP) || defined(CONFIG_44x)
+ else if (i == 1)
+ memcpy(((struct ocp_func_emac_data *)def->additions)->mac_addr,
+ __res.bi_enet1addr, 6);
+#endif
+#if defined(CONFIG_440GX)
+ else if (i == 2)
+ memcpy(((struct ocp_func_emac_data *)def->additions)->mac_addr,
+ __res.bi_enet2addr, 6);
+ else if (i == 3)
+ memcpy(((struct ocp_func_emac_data *)def->additions)->mac_addr,
+ __res.bi_enet3addr, 6);
+#endif
}
}
#endif
diff --git a/include/asm-ppc/ppcboot.h b/include/asm-ppc/ppcboot.h
--- a/include/asm-ppc/ppcboot.h
+++ b/include/asm-ppc/ppcboot.h
@@ -73,8 +73,8 @@ typedef struct bd_info {
#if defined(CONFIG_HYMOD)
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
-#if defined(CONFIG_EVB64260) || defined(CONFIG_44x) || defined(CONFIG_85xx) ||\
- defined(CONFIG_83xx)
+#if defined(CONFIG_EVB64260) || defined(CONFIG_405EP) || defined(CONFIG_44x) || \
+ defined(CONFIG_85xx) || defined(CONFIG_83xx)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#endif
@@ -96,5 +96,7 @@ typedef struct bd_info {
#endif
} bd_t;
+#define bi_tbfreq bi_intfreq
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_PPCBOOT_H__ */
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: mpc8xx and LCD
From: Mark Chambers @ 2005-09-30 12:50 UTC (permalink / raw)
To: Fend, Matthias, linuxppc-embedded
In-Reply-To: <8D4C69676E66D511A1CB00508BBBB192052D4395@ranmx1.cs.myharris.net>
>
> Do you think it's possible to write the device driver in such a way that
> he also translates the pixel data into the indirect register mode of the
> S1D13700 ?
>
No, not directly. The thing about frame buffer devices is that applications
write directly into the pixel memory (via mmap) so that's why hardware
compatibility is important. But as Chuck Meade pointed out, you can make
most anything work by writing a driver that copies from a virtual
framebuffer
to your hardware.
But if this is a new design, forget these indirect chips. Step one, you
have
to find a controller that can drive your LCD. Step two, make sure the
controller allows random access to pixels on the host side. Step three,
if it comes with a driver, great, but if not, framebuffer drivers (for an
LCD)
are pretty simple and you should be able to modify one of the stock
kernel drivers to work for you. Basically you just have to initialize your
chip and then implement a couple of IOCTLs to query and optionally set
the format of your pixels (and the mmap(), of course).
--Mark
^ permalink raw reply
* AW: mpc8xx and LCD
From: Fend, Matthias @ 2005-09-30 11:07 UTC (permalink / raw)
To: linuxppc-embedded
first thank you all for your inputs, but there are some questions left.
> Well, check carefully. As I recall, those parts have been
> discontinued. Although there is software, you may not be able to
> build products once it is done. I'd suggest looking first at
> Fujitsu, and second at Silicon Motion. Both of these companies
> have claimed to be dedicated to providing the embedded
> parts for a long time.
As I know at least the S1D13700 is brand new (the people from Epson are working
on a
Linux driver at the moment).
Do you think it's possible to write the device driver in such a way that
he also translates the pixel data into the indirect register mode of the
S1D13700 ?
> > Has anybody else implemented a LCD into a mpc8xx (not 823) board
> > successfully ?
> Of course. It has an internal LCD/video controller, and there should be
> drivers in various kernels.
? You mean the 823 has an internal LCD controller - I know that but I want to
use a 860 or 855 (we already use them in other products).
Do you think it would be the best way to use an 823 and a driver-only display ?
As there are so many devices with LCD display in use, I thought there could be a
an easy going standard solution for this, but it seems to be a little bit tricky
...
matthias
hi,
>>Can you send a couple of links to the modules you are considering?
>there are some 320x240 from EDT (Emerging Display Technologies) with
S1D13305
>S1D13700
>http://www.actron.de/graphic_displays_edt.htm
>
>also from Powertip a 320x240 with S1D13305/ S1D13704 is available
>http://www.actron.de/graphic_displays_powertip.htm
>
>and also from ampire is one ... (available /w or w/o Epson's S1D
controller)
>http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf
>
Ok, I see the problem with the S1D13305, but the S1D13704 looks ok.
In order to work as a linux framebuffer, the cpu must be able to directly
address
pixels. You can't have a controller like the 13305 that makes you write a
pixel address and then write the pixel. A controller like the 13704 just
makes
the pixel memory look like RAM, so it's easy to interface. The only thing
different is that you must be able to handle wait states, because the pixel
memory is shared between the controller and the cpu. The 13704 manual
has a section showing how to interface to an MPC821, so that's basically
the same as MPC860. However, watch your DSACK0 signal closely - this
signal is shared with 8xx internal logic. It must be synchronized with the
cpu clock, and you may not be able to just let a pullup resistor handle the
rising edge - if that rising edge leaks into the succeeding cycle you can
see
some weird intermittent problems. So plan on needing to run WAIT from any
controller through some glue logic to clean it up for the 8xx.
Or you may be able to just get by with making your cycle time long enough
that you can ignore WAIT. It sounds a bit ugly but as a practical matter
it won't affect performance much.
Mark Chambers
^ permalink raw reply
* Re: iMac G5: experimental thermal & cpufreq support
From: Benjamin Herrenschmidt @ 2005-09-30 7:12 UTC (permalink / raw)
To: linuxppc64-dev
Cc: linuxppc-dev list, debian-powerpc@lists.debian.org,
Linux Kernel list
In-Reply-To: <1127983229.6102.60.camel@gaston>
On Thu, 2005-09-29 at 18:40 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2005-09-29 at 17:20 +1000, Benjamin Herrenschmidt wrote:
>
> > http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
>
> You may want to re-download this one if you got it already, I just fixed
> a bug in the calculations of the CPU control loop. It's now getting
> results much more consistant with OS X. I still have to add some
> overtemp handling and I'll remove the debug stuff and work on supporting
> the PowerMac9,1 desktop model.
Ok, I've updated it. News are:
- It now requires cpufreq support (it won't start if the cpufreq clamp
sensor isn't loaded). I also changed the Kconfig stuff a bit, you'll
need to enable 2 options now
- It has some totally untested support for PowerMac9,1
- It has overtemp support (will slow CPU down and blow fans full speed
if the machine goes overtemp)
- It has some basic sysfs interface to read values
in /sys/devices/platform/windfarm.0
- DEBUG is disabled by default
Enjoy !
Ben.
^ permalink raw reply
* [PATCH] useless includes of linux/irq.h (arch/ppc)
From: Al Viro @ 2005-09-30 4:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/4xx/bamboo.c current/arch/ppc/platforms/4xx/bamboo.c
--- RC14-rc2-git6-base/arch/ppc/platforms/4xx/bamboo.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/platforms/4xx/bamboo.c 2005-09-29 23:44:23.000000000 -0400
@@ -27,7 +27,6 @@
#include <linux/delay.h>
#include <linux/ide.h>
#include <linux/initrd.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/tty.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/4xx/ebony.c current/arch/ppc/platforms/4xx/ebony.c
--- RC14-rc2-git6-base/arch/ppc/platforms/4xx/ebony.c 2005-09-10 16:33:27.000000000 -0400
+++ current/arch/ppc/platforms/4xx/ebony.c 2005-09-29 23:44:29.000000000 -0400
@@ -30,7 +30,6 @@
#include <linux/delay.h>
#include <linux/ide.h>
#include <linux/initrd.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/tty.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/4xx/luan.c current/arch/ppc/platforms/4xx/luan.c
--- RC14-rc2-git6-base/arch/ppc/platforms/4xx/luan.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/platforms/4xx/luan.c 2005-09-29 23:44:40.000000000 -0400
@@ -28,7 +28,6 @@
#include <linux/delay.h>
#include <linux/ide.h>
#include <linux/initrd.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/tty.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/4xx/ocotea.c current/arch/ppc/platforms/4xx/ocotea.c
--- RC14-rc2-git6-base/arch/ppc/platforms/4xx/ocotea.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/platforms/4xx/ocotea.c 2005-09-29 23:44:47.000000000 -0400
@@ -28,7 +28,6 @@
#include <linux/delay.h>
#include <linux/ide.h>
#include <linux/initrd.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/tty.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/83xx/mpc834x_sys.c current/arch/ppc/platforms/83xx/mpc834x_sys.c
--- RC14-rc2-git6-base/arch/ppc/platforms/83xx/mpc834x_sys.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/platforms/83xx/mpc834x_sys.c 2005-09-29 23:40:41.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/serial.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc8540_ads.c current/arch/ppc/platforms/85xx/mpc8540_ads.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-09-29 23:37:53.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/serial.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc8560_ads.c current/arch/ppc/platforms/85xx/mpc8560_ads.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-09-29 23:37:40.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/serial.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc85xx_ads_common.c current/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-09-29 23:37:29.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/serial.h>
#include <linux/module.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc85xx_cds_common.c current/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-09-29 23:34:52.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/serial.h>
#include <linux/module.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/sbc8560.c current/arch/ppc/platforms/85xx/sbc8560.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/sbc8560.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/sbc8560.c 2005-09-29 23:40:54.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/serial.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/sbc85xx.c current/arch/ppc/platforms/85xx/sbc85xx.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/sbc85xx.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/sbc85xx.c 2005-09-29 23:41:03.000000000 -0400
@@ -23,7 +23,6 @@
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/serial.h>
#include <linux/module.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/85xx/stx_gp3.c current/arch/ppc/platforms/85xx/stx_gp3.c
--- RC14-rc2-git6-base/arch/ppc/platforms/85xx/stx_gp3.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/85xx/stx_gp3.c 2005-09-29 23:41:11.000000000 -0400
@@ -30,7 +30,6 @@
#include <linux/blkdev.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/root_dev.h>
#include <linux/seq_file.h>
#include <linux/serial.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/chestnut.c current/arch/ppc/platforms/chestnut.c
--- RC14-rc2-git6-base/arch/ppc/platforms/chestnut.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/chestnut.c 2005-09-29 23:52:49.000000000 -0400
@@ -35,7 +35,6 @@
#include <asm/time.h>
#include <asm/dma.h>
#include <asm/io.h>
-#include <linux/irq.h>
#include <asm/hw_irq.h>
#include <asm/machdep.h>
#include <asm/kgdb.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/chrp_setup.c current/arch/ppc/platforms/chrp_setup.c
--- RC14-rc2-git6-base/arch/ppc/platforms/chrp_setup.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/chrp_setup.c 2005-09-29 23:34:37.000000000 -0400
@@ -32,7 +32,6 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/ide.h>
-#include <linux/irq.h>
#include <linux/console.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/gemini_setup.c current/arch/ppc/platforms/gemini_setup.c
--- RC14-rc2-git6-base/arch/ppc/platforms/gemini_setup.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/gemini_setup.c 2005-09-29 23:38:35.000000000 -0400
@@ -21,7 +21,6 @@
#include <linux/major.h>
#include <linux/initrd.h>
#include <linux/console.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/bcd.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/mvme5100.c current/arch/ppc/platforms/mvme5100.c
--- RC14-rc2-git6-base/arch/ppc/platforms/mvme5100.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/mvme5100.c 2005-09-29 23:35:04.000000000 -0400
@@ -20,7 +20,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/ide.h>
#include <linux/seq_file.h>
#include <linux/kdev_t.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/pmac_setup.c current/arch/ppc/platforms/pmac_setup.c
--- RC14-rc2-git6-base/arch/ppc/platforms/pmac_setup.c 2005-09-23 22:04:24.000000000 -0400
+++ current/arch/ppc/platforms/pmac_setup.c 2005-09-29 23:49:10.000000000 -0400
@@ -48,7 +48,6 @@
#include <linux/adb.h>
#include <linux/cuda.h>
#include <linux/pmu.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/bitops.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/powerpmc250.c current/arch/ppc/platforms/powerpmc250.c
--- RC14-rc2-git6-base/arch/ppc/platforms/powerpmc250.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/powerpmc250.c 2005-09-29 23:39:05.000000000 -0400
@@ -26,7 +26,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/ide.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/pplus.c current/arch/ppc/platforms/pplus.c
--- RC14-rc2-git6-base/arch/ppc/platforms/pplus.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/pplus.c 2005-09-29 23:35:14.000000000 -0400
@@ -22,7 +22,6 @@
#include <linux/ioport.h>
#include <linux/console.h>
#include <linux/pci.h>
-#include <linux/irq.h>
#include <linux/ide.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/prpmc750.c current/arch/ppc/platforms/prpmc750.c
--- RC14-rc2-git6-base/arch/ppc/platforms/prpmc750.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/prpmc750.c 2005-09-29 23:39:17.000000000 -0400
@@ -24,7 +24,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/ide.h>
#include <linux/root_dev.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/prpmc800.c current/arch/ppc/platforms/prpmc800.c
--- RC14-rc2-git6-base/arch/ppc/platforms/prpmc800.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/prpmc800.c 2005-09-29 23:39:23.000000000 -0400
@@ -22,7 +22,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/ide.h>
#include <linux/root_dev.h>
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/radstone_ppc7d.c current/arch/ppc/platforms/radstone_ppc7d.c
--- RC14-rc2-git6-base/arch/ppc/platforms/radstone_ppc7d.c 2005-06-17 15:48:29.000000000 -0400
+++ current/arch/ppc/platforms/radstone_ppc7d.c 2005-09-29 23:35:33.000000000 -0400
@@ -32,7 +32,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/ide.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
@@ -59,7 +58,6 @@
#include <asm/mpc10x.h>
#include <asm/pci-bridge.h>
#include <asm/mv64x60.h>
-#include <asm/i8259.h>
#include "radstone_ppc7d.h"
diff -urN RC14-rc2-git6-base/arch/ppc/platforms/sandpoint.c current/arch/ppc/platforms/sandpoint.c
--- RC14-rc2-git6-base/arch/ppc/platforms/sandpoint.c 2005-08-28 23:09:40.000000000 -0400
+++ current/arch/ppc/platforms/sandpoint.c 2005-09-29 23:35:41.000000000 -0400
@@ -74,7 +74,6 @@
#include <linux/initrd.h>
#include <linux/console.h>
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/ide.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
diff -urN RC14-rc2-git6-base/arch/ppc/syslib/open_pic.c current/arch/ppc/syslib/open_pic.c
--- RC14-rc2-git6-base/arch/ppc/syslib/open_pic.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/syslib/open_pic.c 2005-09-29 23:35:55.000000000 -0400
@@ -13,7 +13,6 @@
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/init.h>
-#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/sysdev.h>
#include <linux/errno.h>
diff -urN RC14-rc2-git6-base/arch/ppc/syslib/open_pic2.c current/arch/ppc/syslib/open_pic2.c
--- RC14-rc2-git6-base/arch/ppc/syslib/open_pic2.c 2005-09-19 02:18:03.000000000 -0400
+++ current/arch/ppc/syslib/open_pic2.c 2005-09-29 23:36:01.000000000 -0400
@@ -17,7 +17,6 @@
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/init.h>
-#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/sysdev.h>
#include <linux/errno.h>
diff -urN RC14-rc2-git6-base/arch/ppc/syslib/ppc4xx_setup.c current/arch/ppc/syslib/ppc4xx_setup.c
--- RC14-rc2-git6-base/arch/ppc/syslib/ppc4xx_setup.c 2005-09-05 07:05:13.000000000 -0400
+++ current/arch/ppc/syslib/ppc4xx_setup.c 2005-09-29 23:45:27.000000000 -0400
@@ -18,7 +18,6 @@
#include <linux/smp.h>
#include <linux/threads.h>
#include <linux/spinlock.h>
-#include <linux/irq.h>
#include <linux/reboot.h>
#include <linux/param.h>
#include <linux/string.h>
^ permalink raw reply
* [PATCH] missing qualifiers in readb() et.al. on ppc
From: Al Viro @ 2005-09-30 3:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc2-git6-base/include/asm-ppc/io.h current/include/asm-ppc/io.h
--- RC14-rc2-git6-base/include/asm-ppc/io.h 2005-06-17 15:48:29.000000000 -0400
+++ current/include/asm-ppc/io.h 2005-09-29 22:47:06.000000000 -0400
@@ -56,7 +56,7 @@
* is actually performed (i.e. the data has come back) before we start
* executing any following instructions.
*/
-extern inline int in_8(volatile unsigned char __iomem *addr)
+extern inline int in_8(const volatile unsigned char __iomem *addr)
{
int ret;
@@ -72,7 +72,7 @@
__asm__ __volatile__("stb%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val));
}
-extern inline int in_le16(volatile unsigned short __iomem *addr)
+extern inline int in_le16(const volatile unsigned short __iomem *addr)
{
int ret;
@@ -83,7 +83,7 @@
return ret;
}
-extern inline int in_be16(volatile unsigned short __iomem *addr)
+extern inline int in_be16(const volatile unsigned short __iomem *addr)
{
int ret;
@@ -104,7 +104,7 @@
__asm__ __volatile__("sth%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val));
}
-extern inline unsigned in_le32(volatile unsigned __iomem *addr)
+extern inline unsigned in_le32(const volatile unsigned __iomem *addr)
{
unsigned ret;
@@ -115,7 +115,7 @@
return ret;
}
-extern inline unsigned in_be32(volatile unsigned __iomem *addr)
+extern inline unsigned in_be32(const volatile unsigned __iomem *addr)
{
unsigned ret;
@@ -139,7 +139,7 @@
#define readb(addr) in_8((volatile u8 *)(addr))
#define writeb(b,addr) out_8((volatile u8 *)(addr), (b))
#else
-static inline __u8 readb(volatile void __iomem *addr)
+static inline __u8 readb(const volatile void __iomem *addr)
{
return in_8(addr);
}
@@ -150,11 +150,11 @@
#endif
#if defined(CONFIG_APUS)
-static inline __u16 readw(volatile void __iomem *addr)
+static inline __u16 readw(const volatile void __iomem *addr)
{
return *(__force volatile __u16 *)(addr);
}
-static inline __u32 readl(volatile void __iomem *addr)
+static inline __u32 readl(const volatile void __iomem *addr)
{
return *(__force volatile __u32 *)(addr);
}
@@ -173,11 +173,11 @@
#define writew(b,addr) out_le16((volatile u16 *)(addr),(b))
#define writel(b,addr) out_le32((volatile u32 *)(addr),(b))
#else
-static inline __u16 readw(volatile void __iomem *addr)
+static inline __u16 readw(const volatile void __iomem *addr)
{
return in_le16(addr);
}
-static inline __u32 readl(volatile void __iomem *addr)
+static inline __u32 readl(const volatile void __iomem *addr)
{
return in_le32(addr);
}
^ permalink raw reply
* Re: iMac G5: experimental thermal & cpufreq support
From: Dean Hamstead @ 2005-09-30 1:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc64-dev, debian-powerpc@lists.debian.org,
Linux Kernel list, linuxppc-dev list
In-Reply-To: <1128040019.31197.3.camel@gaston>
Although i dont have an imac g5, i think that in general ben is on the
right track. its better to have something in place than nothing.
not putting down the feedback, but im not sure just how much fiddling
people will really want, and its not a huge audience. which
brings me back to the point of just getting something in place and
then people can change it as IMO linux kernel code is more likely to be
fiddled with (and better 'documentation' - whatever that is) than darwin
code.
go ben, keep working hard. and keep chasing the mpeg decoder in the ati
cards of apple ibook and friends!
Dean
On Fri, September 30, 2005 10:26 am, Benjamin Herrenschmidt said:
> On Thu, 2005-09-29 at 16:28 -0700, Geoff Levand wrote:
>> Benjamin Herrenschmidt wrote:
>> > The algorithm itself is extracted from darwin. However, it's a rather
>> > complex modified version of the PID algorithm, and thus it could use
>> > some review to make sure I got everything right.
>> >
>>
>> As we are already in the digital domain, I would think it would be
>> more savvy to use a digital controller than try to simulate an
>> analog controller... Why don't you abstract the control algorithm
>> such that you can plug in others as they are developed.
>
> Because I don't know much about those control algorithms, and all the
> calibration data provided by the firmware is in the form of factors for
> these algorithms, I wouldn't know how to "unmangle" them to use with
> different ones.
>
> Actually, the control algorithms (PID and modified PID) are in a
> "helper", so it's fairly easy for the platform module to use whatever it
> wants, feel free to submit other algorithms :) But for Apple machines,
> I'd rather use what I have calibration data for, unless you can produce
> something that works without any...
>
> Ben.
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
^ permalink raw reply
* Re: iMac G5: experimental thermal & cpufreq support
From: Benjamin Herrenschmidt @ 2005-09-30 0:26 UTC (permalink / raw)
To: Geoff Levand
Cc: linuxppc64-dev, debian-powerpc@lists.debian.org,
Linux Kernel list, linuxppc-dev list
In-Reply-To: <433C7882.20000@am.sony.com>
On Thu, 2005-09-29 at 16:28 -0700, Geoff Levand wrote:
> Benjamin Herrenschmidt wrote:
> > The algorithm itself is extracted from darwin. However, it's a rather
> > complex modified version of the PID algorithm, and thus it could use
> > some review to make sure I got everything right.
> >
>
> As we are already in the digital domain, I would think it would be
> more savvy to use a digital controller than try to simulate an
> analog controller... Why don't you abstract the control algorithm
> such that you can plug in others as they are developed.
Because I don't know much about those control algorithms, and all the
calibration data provided by the firmware is in the form of factors for
these algorithms, I wouldn't know how to "unmangle" them to use with
different ones.
Actually, the control algorithms (PID and modified PID) are in a
"helper", so it's fairly easy for the platform module to use whatever it
wants, feel free to submit other algorithms :) But for Apple machines,
I'd rather use what I have calibration data for, unless you can produce
something that works without any...
Ben.
^ permalink raw reply
* Re: linuxppc-2.4.30-pre1 crashes with root fs on Xilinx SystemACE
From: Keith J Outwater @ 2005-09-29 23:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <433A631B.6000602@xilinx.com>
Peter -
That's about the throughput I saw on my system. It's pretty slow!
Tony -
I did get things working by applying a "sysace nointr" patch that had been
posted to the list some
time ago in response to comments that SystemACE interrupts were not
working as expected on
Memec boards. I did my initial development on a Memec board and had lots
of problems until
I disabled SystemACE interrupts. Some day I may actually go back and try
to figure out
what is going on, but for the time being, I can live with what I have.
Peter Ryser <peter.ryser@xilinx.com> wrote on 09/28/2005 02:32:11 AM:
> Some time ago we did some tests with bonnie++ on Linux running on
> the PPC405 in a Virtex-II Pro FPGA. You can expect the following
performance:
> Read peak: 629 KB/s
> Write peak: 299 KB/s
> Not considering network overhead, a 10MB file should take less than
> a minute to update.
>
> - Peter
>
>
> Tony Lee wrote:
> Keith,
>
> Some suggestions, before you verify your hw board/FPGA works fine
> with SYSACE,
> * don't use sysace as root fs.
> * use a ram fs as root fs.
> * Next, load sysace driver a loadable driver module. It works,
> I tried it.
> * check mount read only and see if it works.
> * Next, mount it writable.
>
> We have some issues with sysace driver initially, everything works
> out fine later.
> There were small errors in our HW layout.
>
> I had to hack the sysace driver left and right to id the problem. But
at the
> end, after I fixed the layout problem from the fpga's ucf file, the
> original driver
> run perfectly without any modification.
>
> In my experiences, the ppc linux distribution and its linux sysace
> driver are good
> if everything is setup correctly.
>
> One minor issues: The sysace driver's write performance sucks. I
> have to explain
> to others why the upgrade 10 MBytes files with usb flash writer takes
tens of
> seconds. When we do it from linux (nfs or ftp), it tooks minutes to
sync.
>
> Peter, maybe you can push the xilinx a bit on sysace write performance?
:-)
>
> -Tony
> On 8/29/05, Peter Ryser <peter.ryser@xilinx.com> wrote:
> Hi Keith,
>
> I sent you a private email but for other interested people:
> Downloading the latest linuxppc-2.4 kernel I could boot from and access
> System ACE CF without problems on a ML403 (Virtex-4, 4VFX12) and a ML310
> (Virtex-II Pro, 2VP30) using EDK 7.1.2. In both cases I started with
> config_xilinx_ml300.
>
> - Peter
>
>
>
> Keith J Outwater wrote:
>
> >Hello -
> >Per a previous suggestion from this list, I rsynced the linuxppc-2.4
> >kernel sources from MontaVista and modified the kernel to run on my
custom
> >ppc405/VirtexII Pro based system with U-Boot as the bootloader.
> >When I try to use the SystemACE device as the root filesystem, the
kernel
> >crashes with a sig 11. Looking at the 'oops' output it appears the
> >SystemACE driver may be to blame. The crash is random - sometimes I
get
> >all the way to login as root and then things crash on a file copy or a
> >file read.
> >Before I start digging deeper, is anyone running a VirtexIIPro based
> >system with the root filesystem in the CF card attached to a SystemACE?
> >I'm wondering if I really have the best kernel and SystemACE driver.
> >BTW, I'm developing the hardware design using Xilinx EDK 7.02i.
> >Thanks,
> >Keith
> >_______________________________________________
> >Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> --
> -Tony
> Having fun with FPGA HW + ppc + Linux
^ permalink raw reply
* Re: iMac G5: experimental thermal & cpufreq support
From: Geoff Levand @ 2005-09-29 23:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc64-dev, debian-powerpc@lists.debian.org,
Linux Kernel list, linuxppc-dev list
In-Reply-To: <1127978432.6102.53.camel@gaston>
Benjamin Herrenschmidt wrote:
> The algorithm itself is extracted from darwin. However, it's a rather
> complex modified version of the PID algorithm, and thus it could use
> some review to make sure I got everything right.
>
As we are already in the digital domain, I would think it would be
more savvy to use a digital controller than try to simulate an
analog controller... Why don't you abstract the control algorithm
such that you can plug in others as they are developed.
-Geoff
^ permalink raw reply
* Re: MV64x60 watchdog timer driver updates
From: Mark A. Greer @ 2005-09-29 20:36 UTC (permalink / raw)
To: Corey Minyard; +Cc: linuxppc-dev
In-Reply-To: <20050929183221.GA17292@i2.minyard.local>
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'.
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.
Mark
^ permalink raw reply
* RE: mpc8xx and LCD
From: Chuck Meade @ 2005-09-29 17:31 UTC (permalink / raw)
To: Mark Chambers, Fend, Matthias, linuxppc-embedded
In-Reply-To: <00c501c5c504$96c59780$0301a8c0@chuck2>
> >>Can you send a couple of links to the modules you are considering?
>
> >there are some 320x240 from EDT (Emerging Display Technologies) with
> S1D13305
> >S1D13700
> >http://www.actron.de/graphic_displays_edt.htm
> >
> >also from Powertip a 320x240 with S1D13305/ S1D13704 is available
> >http://www.actron.de/graphic_displays_powertip.htm
> >
> >and also from ampire is one ... (available /w or w/o Epson's S1D
> controller)
> >http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf
> >
>
> Ok, I see the problem with the S1D13305, but the S1D13704 looks ok.
> In order to work as a linux framebuffer, the cpu must be able to directly
> address
> pixels. You can't have a controller like the 13305 that makes you write a
> pixel address and then write the pixel. A controller like the 13704 just
> makes
> the pixel memory look like RAM, so it's easy to interface.
I have done this in the past when the cpu could not directly access the
pixels. I created a virtual framebuffer in RAM, and had a timer-driven
routine that regularly sent the contents of the virtual framebuffer to
the LCD device through the "register bottleneck" of the LCD device interface.
It actually worked well. I expected a big performance hit with all the
additional bus activity, but it was not bad (no, I don't remember any
numbers). The platform had a 48 MHz mpc8xx if I remember correctly,
and the LCD device was an old Epson chip that had a registered interface
(no direct access to pixels).
It is not an optimal situation, but if you find yourself stuck with an LCD
device that does not provide a RAM-like interface to the pixels, then it is
at least a known-working solution.
Chuck Meade
The PTR Group
^ permalink raw reply
* Re: Available user-level tool for I2C device?
From: Tolunay Orkun @ 2005-09-29 18:59 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050929123535.66570.qmail@web15803.mail.cnb.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
Sam,
Sam Song wrote:
> Hi all,
>
> I'd like to ask whether there is user-level utility
> for I2C device registers access like lspci/setpci for
> PCI device?
>
> I have a RTC chip DS1337 on a 8248 target. It can
> work right in u-boot and linux. If no similar utility,
> I will switch to change hwclock.c in busybox to make
> it. Any idea?
>
> Thanks in advance,
>
> Sam
I've a hwclock.c implementation for DS1307/DS1338. I do not know how
close DS1337 was but it should not be too difficult to adapt.
Best regards,
Tolunay
[-- Attachment #2: hwclock_ds1307.c --]
[-- Type: text/x-csrc, Size: 6803 bytes --]
/*
* Mini hwclock implementation suitable for DS1307/DS1338 RTC chips
*
* Copyright (C) 2004 NextIO Inc. - Tolunay Orkun <torkun@nextio.com>
*
* Based on GPL licensed code from Busybox and U-boot projects
*
* 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#include <sys/ioctl.h>
#include <sys/time.h>
#include <time.h>
#include <unistd.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdio.h>
#include <libgen.h>
#include <stdlib.h>
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
#define DS1307_ADDR 0x68
struct i2c_ioctl_rdwr_data {
struct i2c_msg *msgs;
int nmsgs;
};
int i2c_xfer(int addr, char *wbuf, int wcount, char *rbuf, int rcount)
{
int fd, i;
int val, nmsgs;
struct i2c_msg msg[2];
struct i2c_ioctl_rdwr_data ioctl_rdwr_data;
memset(msg, 0, sizeof(msg));
memset(&ioctl_rdwr_data, 0, sizeof(ioctl_rdwr_data));
nmsgs = 0;
if (wcount > 0) {
msg[nmsgs].addr = addr;
msg[nmsgs].flags = 0;
msg[nmsgs].len = wcount;
msg[nmsgs].buf = wbuf;
nmsgs++;
}
if (rcount > 0) {
msg[nmsgs].addr = addr;
msg[nmsgs].flags = I2C_M_RD;
msg[nmsgs].len = rcount;
msg[nmsgs].buf = rbuf;
nmsgs++;
}
ioctl_rdwr_data.msgs = msg;
ioctl_rdwr_data.nmsgs = nmsgs;
#ifdef DEBUG
if (wcount > 0) {
printf("Writing i2c...\n");
printf("Addr : %3d (0x%02x)\n", addr, addr);
printf("Count: %3d (0x%02x)\n", wcount, wcount);
printf("Data :\n");
for (i = 0; i < wcount; i++) {
val = wbuf[i];
printf("%3d (0x%02x) = %3d (0x%02x)\n", i, i, val, val);
}
printf("\n");
}
if (rcount > 0) {
printf("Reading i2c...\n");
printf("Addr : %3d (0x%02x)\n", addr, addr);
printf("Count: %3d (0x%02x)\n", rcount, rcount);
}
#endif
fd = open("/dev/i2c0", O_RDWR);
if (fd < 0) {
fd = open("/dev/i2c/0", O_RDWR);
if (fd < 0) {
printf("Can't open i2c\n");
return 1;
}
}
if (ioctl(fd, I2C_RDWR, &ioctl_rdwr_data) < 0) {
printf("I2C I/O Error\n");
close(fd);
return 2;
}
#ifdef DEBUG
if (rcount > 0) {
printf("Data :\n");
for (i = 0; i < rcount; i++) {
val = rbuf[i];
printf("%3d (0x%02x) = %3d (0x%02x)\n", i, i, val, val);
}
printf("\n");
}
#endif
close(fd);
return 0;
}
unsigned int bcd2bin(unsigned char n)
{
return ((((n >> 4) & 0x0f) * 10) + (n & 0x0f));
}
unsigned char bin2bcd(unsigned int n)
{
return (((n / 10) << 4) | (n % 10));
}
time_t read_rtc(int utc)
{
char reg = 0; /* register start address for transfer */
char buf[8];
struct tm tm;
char *oldtz = NULL;
time_t t = 0;
if (i2c_xfer(DS1307_ADDR, ®, sizeof(reg), buf, sizeof(buf)) != 0)
return -1;
memset(&tm, 0, sizeof(struct tm));
tm.tm_sec = bcd2bin(buf[0] & 0x7f);
tm.tm_min = bcd2bin(buf[1] & 0x7f);
tm.tm_hour = bcd2bin(buf[2] & 0x3f);
tm.tm_wday = bcd2bin(buf[3] & 0x07) - 1;
tm.tm_mday = bcd2bin(buf[4] & 0x3f);
tm.tm_mon = bcd2bin(buf[5] & 0x1f) - 1;
tm.tm_year = bcd2bin(buf[6]) + 100;
tm.tm_isdst = -1; /* unknown */
if (utc) {
oldtz = getenv("TZ");
setenv("TZ", "UTC 0", 1);
tzset();
}
t = mktime(&tm);
if (utc) {
if (oldtz)
setenv("TZ", oldtz, 1);
else
unsetenv("TZ");
tzset();
}
return t;
}
int write_rtc(time_t t, int utc)
{
char buf[8];
struct tm tm;
tm = *(utc ? gmtime(&t) : localtime(&t));
buf[0] = 0; /* register start address for transfer */
buf[1] = bin2bcd(tm.tm_sec);
buf[2] = bin2bcd(tm.tm_min);
buf[3] = bin2bcd(tm.tm_hour);
buf[4] = bin2bcd(tm.tm_wday + 1);
buf[5] = bin2bcd(tm.tm_mday);
buf[6] = bin2bcd(tm.tm_mon + 1);
buf[7] = bin2bcd(tm.tm_year - 100);
if (i2c_xfer(DS1307_ADDR, buf, sizeof(buf), NULL, 0) != 0)
return -1;
return 0;
}
int show_clock(int utc)
{
time_t t;
char buffer[64];
char *p;
int len;
buffer[0] = '\0';
t = read_rtc(utc);
p = ctime(&t);
if (p) {
len = strlen(p) - 1; /* strip newline */
if (len >= sizeof(buffer))
len = sizeof(buffer) - 1;
memcpy(buffer, p, len);
buffer[len] = '\0';
}
printf("%s 0.000000 seconds\n", buffer);
return 0;
}
int to_sys_clock(int utc)
{
struct timeval tv;
memset(&tv, 0, sizeof(tv));
tv.tv_sec = read_rtc(utc);
return settimeofday(&tv, NULL);
}
int from_sys_clock(int utc)
{
struct timeval tv;
memset(&tv, 0, sizeof(tv));
gettimeofday(&tv, NULL);
return write_rtc(tv.tv_sec, utc);
}
void show_usage(char *progname)
{
char buf[64];
strncpy(buf, progname, sizeof(buf));
buf[sizeof(buf) - 1] = '\0';
basename(buf);
printf("%s - query and set the hardware clock (DS1307/1338 RTC)\n\n", buf);
printf("Usage: %s [options...]\n\n", buf);
printf("Options:\n");
printf("\t-r, --show\tread hardware clock and print result\n");
printf("\t-s, --hctosys\tset the system time from the hardware clock\n");
printf("\t-w, --systohc\tset the hardware clock to the current system time\n\n");
printf("\t-u, --utc\tthe hardware clock is kept in universal time\n");
printf("\t-l, --localtime\tthe hardware clock is kept in local time\n\n");
exit(-1);
}
int main(int argc, char *argv[])
{
int opt_help = 0;
int opt_localtime = 0;
int opt_utc = 0;
int func_show = 0;
int func_hctosys = 0;
int func_systohc = 0;
int func_count;
int utc;
int c;
static struct option long_options[] = {
{ "show", 0, 0, 'r' },
{ "hctosys", 0, 0, 's' },
{ "systohc", 0, 0, 'w' },
{ "localtime", 0, 0, 'l' },
{ "utc", 0, 0, 'u' },
{ "help", 0, 0, '?' },
{ 0, 0, 0, 0 }
};
int opt_idx = 0;
while (1) {
c = getopt_long(argc, argv, "rswlu?h", long_options, &opt_idx);
if (c == -1)
break;
switch (c) {
case 'r':
func_show = 1;
break;
case 's':
func_hctosys = 1;
break;
case 'w':
func_systohc = 1;
break;
case 'l':
opt_localtime = 1;
break;
case 'u':
opt_utc = 1;
break;
default:
opt_help = 1;
break;
}
}
func_count = func_show + func_hctosys + func_systohc;
if (func_count > 1)
show_usage(argv[0]);
if (opt_localtime && opt_utc)
show_usage(argv[0]);
if (opt_help)
show_usage(argv[0]);
if (func_hctosys)
return to_sys_clock(opt_utc);
else if (func_systohc)
return from_sys_clock(opt_utc);
else
return show_clock(opt_utc);
return 0;
}
/* ex: set sw=4 ts=4: */
^ permalink raw reply
* MV64x60 watchdog timer driver updates
From: Corey Minyard @ 2005-09-29 18:32 UTC (permalink / raw)
To: linuxppc-dev
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.
-Corey
----
The mv64x60 watchdog timer driver didn't allow dynamically setting
the timeout value. The hardware is settable, and setting the value
is rather important (especially with such a small default). So
this patch adds that function.
It also does the following:
* Modifies the returned timeout to be seconds, not jiffies,
as seconds is the standard.
* Adds a semaphore around the various critical data structures
and access to the device registers. The former operations
could be racy.
* Adds enable and disable operations.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Index: linux-2.6.14-rc2/drivers/char/watchdog/mv64x60_wdt.c
===================================================================
--- linux-2.6.14-rc2.orig/drivers/char/watchdog/mv64x60_wdt.c
+++ linux-2.6.14-rc2/drivers/char/watchdog/mv64x60_wdt.c
@@ -25,12 +25,14 @@
#include <asm/mv64x60.h>
#include <asm/uaccess.h>
#include <asm/io.h>
+#include <asm/semaphore.h>
/* MV64x60 WDC (config) register access definitions */
#define MV64x60_WDC_CTL1_MASK (3 << 24)
#define MV64x60_WDC_CTL1(val) ((val & 3) << 24)
#define MV64x60_WDC_CTL2_MASK (3 << 26)
#define MV64x60_WDC_CTL2(val) ((val & 3) << 26)
+#define MV64x60_WDC_ENABLE (1 << 31)
/* Flags bits */
#define MV64x60_WDOG_FLAG_OPENED 0
@@ -39,44 +41,77 @@
static unsigned long wdt_flags;
static int wdt_status;
static void __iomem *mv64x60_regs;
+static int mv64x60_bus_clk = 133000000;
static int mv64x60_wdt_timeout;
+static u32 mv64x60_wdt_control_val;
+
+static DECLARE_MUTEX(mv64x60_sem);
+
+static u32 mv64x60_wdt_read_reg(void)
+{
+ return readl(mv64x60_regs + MV64x60_WDT_WDC);
+}
static void mv64x60_wdt_reg_write(u32 val)
{
/* Allow write only to CTL1 / CTL2 fields, retaining values in
* other fields.
*/
- u32 data = readl(mv64x60_regs + MV64x60_WDT_WDC);
- data &= ~(MV64x60_WDC_CTL1_MASK | MV64x60_WDC_CTL2_MASK);
- data |= val;
+ u32 data = mv64x60_wdt_control_val | val;
writel(data, mv64x60_regs + MV64x60_WDT_WDC);
}
static void mv64x60_wdt_service(void)
{
/* Write 01 followed by 10 to CTL2 */
+ down(&mv64x60_sem);
mv64x60_wdt_reg_write(MV64x60_WDC_CTL2(0x01));
mv64x60_wdt_reg_write(MV64x60_WDC_CTL2(0x02));
+ up(&mv64x60_sem);
+}
+
+static int mv64x60_set_timeout(int timeout)
+{
+ u32 cnt;
+
+ if (timeout > (0xffffffff / mv64x60_bus_clk))
+ return -EINVAL;
+
+ down(&mv64x60_sem);
+ mv64x60_wdt_timeout = timeout;
+
+ /* Put into u32 first so shift will be unsigned. */
+ cnt = timeout * mv64x60_bus_clk;
+ mv64x60_wdt_control_val = cnt >> 8;
+ up(&mv64x60_sem);
+
+ if (test_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags))
+ mv64x60_wdt_service();
+ return 0;
}
static void mv64x60_wdt_handler_disable(void)
{
+ down(&mv64x60_sem);
if (test_and_clear_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags)) {
/* Write 01 followed by 10 to CTL1 */
mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x01));
mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x02));
printk(KERN_NOTICE "mv64x60_wdt: watchdog deactivated\n");
}
+ up(&mv64x60_sem);
}
static void mv64x60_wdt_handler_enable(void)
{
+ down(&mv64x60_sem);
if (!test_and_set_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags)) {
/* Write 01 followed by 10 to CTL1 */
mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x01));
mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x02));
printk(KERN_NOTICE "mv64x60_wdt: watchdog activated\n");
}
+ up(&mv64x60_sem);
}
static int mv64x60_wdt_open(struct inode *inode, struct file *file)
@@ -119,6 +154,7 @@ static int mv64x60_wdt_ioctl(struct inod
unsigned int cmd, unsigned long arg)
{
int timeout;
+ int val;
static struct watchdog_info info = {
.options = WDIOF_KEEPALIVEPING,
.firmware_version = 0,
@@ -142,7 +178,14 @@ static int mv64x60_wdt_ioctl(struct inod
return -EOPNOTSUPP;
case WDIOC_SETOPTIONS:
- return -EOPNOTSUPP;
+ if (copy_from_user(&val, (int *) arg, sizeof(int)))
+ return -EFAULT;
+ if (val & WDIOS_DISABLECARD)
+ mv64x60_wdt_handler_disable();
+
+ if (val & WDIOS_ENABLECARD)
+ mv64x60_wdt_handler_enable();
+ return 0;
case WDIOC_KEEPALIVE:
mv64x60_wdt_service();
@@ -150,13 +193,15 @@ static int mv64x60_wdt_ioctl(struct inod
break;
case WDIOC_SETTIMEOUT:
- return -EOPNOTSUPP;
+ if (get_user(timeout, (int *)arg))
+ return -EFAULT;
+ return mv64x60_set_timeout(timeout);
case WDIOC_GETTIMEOUT:
- timeout = mv64x60_wdt_timeout * HZ;
- if (put_user(timeout, (int *)arg))
- return -EFAULT;
- break;
+ timeout = mv64x60_wdt_timeout;
+ if (put_user(timeout, (int *)arg))
+ return -EFAULT;
+ break;
default:
return -ENOIOCTLCMD;
@@ -184,18 +229,25 @@ static int __devinit mv64x60_wdt_probe(s
{
struct platform_device *pd = to_platform_device(dev);
struct mv64x60_wdt_pdata *pdata = pd->dev.platform_data;
- int bus_clk = 133;
+ int timeout = 10;
- mv64x60_wdt_timeout = 10;
if (pdata) {
- mv64x60_wdt_timeout = pdata->timeout;
- bus_clk = pdata->bus_clk;
+ timeout = pdata->timeout;
+ mv64x60_bus_clk = pdata->bus_clk * 1000000;
+ }
+ if (mv64x60_set_timeout(timeout)) {
+ printk("mv64x60_wdt: Default timeout too large, setting to"
+ " maximum value\n");
+ mv64x60_set_timeout(0xffffffff / mv64x60_bus_clk);
}
mv64x60_regs = mv64x60_get_bridge_vbase();
- writel((mv64x60_wdt_timeout * (bus_clk * 1000000)) >> 8,
- mv64x60_regs + MV64x60_WDT_WDC);
+ if (mv64x60_wdt_read_reg() & MV64x60_WDC_ENABLE) {
+ /* Watchdog was already running, disable it */
+ set_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags);
+ mv64x60_wdt_handler_disable();
+ }
return misc_register(&mv64x60_wdt_miscdev);
}
^ permalink raw reply
* Re: Available user-level tool for I2C device?
From: Eugene Surovegin @ 2005-09-29 16:57 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050929123535.66570.qmail@web15803.mail.cnb.yahoo.com>
On Thu, Sep 29, 2005 at 08:35:35PM +0800, Sam Song wrote:
> I have a RTC chip DS1337 on a 8248 target. It can
> work right in u-boot and linux. If no similar utility,
> I will switch to change hwclock.c in busybox to make
> it. Any idea?
Right approach would be making standard in-kernel RTC driver for this
chip. In fact, such driver was already posted to lm-sensors list some
time ago.
--
Eugene
^ permalink raw reply
* Re: where to find mkfs utility
From: Wolfgang Denk @ 2005-09-29 15:29 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linux-ppc-embedded
In-Reply-To: <20050929125154.00375683D1@ozlabs.org>
In message <20050929125154.00375683D1@ozlabs.org> you wrote:
>
> When can I found mkfs.mkdos, mkfs.vfat and mkfs.ntfs utilities.
>
> Are all these in the same package, and what is this package name?
mkfs.msdos and mkfs.vfat are part of the dosfstools package.
Never heard of mkfs.ntfs yet.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Why is an average signature file longer than an average Perl script??
^ permalink raw reply
* Re: mpc8xx and LCD
From: Mark Chambers @ 2005-09-29 14:44 UTC (permalink / raw)
To: Fend, Matthias, linuxppc-embedded
In-Reply-To: <8D4C69676E66D511A1CB00508BBBB192052D435D@ranmx1.cs.myharris.net>
hi,
>>Can you send a couple of links to the modules you are considering?
>there are some 320x240 from EDT (Emerging Display Technologies) with
S1D13305
>S1D13700
>http://www.actron.de/graphic_displays_edt.htm
>
>also from Powertip a 320x240 with S1D13305/ S1D13704 is available
>http://www.actron.de/graphic_displays_powertip.htm
>
>and also from ampire is one ... (available /w or w/o Epson's S1D
controller)
>http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf
>
Ok, I see the problem with the S1D13305, but the S1D13704 looks ok.
In order to work as a linux framebuffer, the cpu must be able to directly
address
pixels. You can't have a controller like the 13305 that makes you write a
pixel address and then write the pixel. A controller like the 13704 just
makes
the pixel memory look like RAM, so it's easy to interface. The only thing
different is that you must be able to handle wait states, because the pixel
memory is shared between the controller and the cpu. The 13704 manual
has a section showing how to interface to an MPC821, so that's basically
the same as MPC860. However, watch your DSACK0 signal closely - this
signal is shared with 8xx internal logic. It must be synchronized with the
cpu clock, and you may not be able to just let a pullup resistor handle the
rising edge - if that rising edge leaks into the succeeding cycle you can
see
some weird intermittent problems. So plan on needing to run WAIT from any
controller through some glue logic to clean it up for the 8xx.
Or you may be able to just get by with making your cycle time long enough
that you can ignore WAIT. It sounds a bit ugly but as a practical matter
it won't affect performance much.
Mark Chambers
^ permalink raw reply
* Re: fix-up GIANFAR driver timer bug
From: Andy Fleming @ 2005-09-29 14:30 UTC (permalink / raw)
To: sun; +Cc: linuxppc-embedded
In-Reply-To: <011901c5c49a$9aa01fc0$3f13180a@utsfd.cs.fujitsu.co.jp>
The reported issue no longer exists in the latest version of the
driver, which should be in linus' tree soon (it's in the netdev
tree). However, it may have crept into the PHY Layer, so I will
investigate. Thank you for reporting this!
Andy
On Sep 28, 2005, at 21:07, sun wrote:
> Repeat executing a command series like the attached descript will
> cause
> system hanging or kernel panic shown below on a GIANFAR used system.
> The attached patch is for fix the above issue.
> The issue and the solution have been confirmed on
> MPC8560ADS and MPC85555CDS evaluation boards.
>
> ----------
> -sh-3.00# ./net_setting.sh
> eth1 setting start
> ###set ip-address
>
> ###net Trying to free free IRQ103
> down
>
> ###set MAC address
>
> ###net up
> kernel BUG in cascade at kernel/timer.c:419!
> Oops: Exception in kernel mode, sig: 5 [#1]
> NIP: C0029090 LR: C00290A0 SP: CCD69B20 REGS: ccd69a70 TRAP:
> 0700 Not tainted
> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = cde58080[170] 'ifconfig' THREAD: ccd68000
> Last syscall: 54
> GPR00: 00000001 CCD69B20 CDE58080 C0311DD4 C031269C FFFBD700
> C0311F4C C0311E94
> GPR08: FFFBD869 00003B60 00000169 00003B5F FFFBD700 1010A204
> 00000000 00000000
> GPR16: 00000000 1001C094 00000000 00000000 C07D2400 FFFF8914
> C03092C0 C0310000
> GPR24: C0310000 C0310000 C0280000 C0311DD4 00000017 C0311DD4
> C0312694 C031269C
> NIP [c0029090] cascade+0x40/0x78
> LR [c00290a0] cascade+0x50/0x78
> Call trace:
> [c002923c] run_timer_softirq+0x174/0x1d8
> [c0024b4c] __do_softirq+0x80/0xf4
> [c0024c18] do_softirq+0x58/0x60
> [c0003930] timer_interrupt+0xa0/0x208
> [c0002598] ret_from_except+0x0/0x18
> [c001f694] release_console_sem+0xc4/0x234
> [c001f95c] vprintk+0x158/0x1c0
> [c001fa14] printk+0x50/0x60
> [c014d91c] get_phy_info+0xcc/0xe4
> [c014b30c] gfar_enet_open+0x2ec/0x390
> [c01a7630] dev_open+0xb0/0xd8
> [c01a8dc4] dev_change_flags+0x6c/0x144
> [c01e6eec] devinet_ioctl+0x618/0x764
> [c01e8250] inet_ioctl+0x10c/0x120
> [c019dbcc] sock_ioctl+0x1ac/0x288
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> <0>Rebooting in 1 seconds..U-Boot 1.1.2 (Aug 19 2005 - 09:55:23)
>
>
> <fixIFCONFIGpanic.patch>
> <net_setting.sh>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: mpc8xx and LCD
From: Dan Malek @ 2005-09-29 14:03 UTC (permalink / raw)
To: Fend, Matthias; +Cc: linuxppc-embedded
In-Reply-To: <8D4C69676E66D511A1CB00508BBBB192052D42EF@ranmx1.cs.myharris.net>
On Sep 29, 2005, at 2:53 AM, Fend, Matthias wrote:
> At the moment I think we should use a lcd controller from Epson
> (S1D13700 or S1D13305) since they are
> working on Linux framebuffer device driver for it.
Well, check carefully. As I recall, those parts have been
discontinued. Although there is software, you may not be able to
build products once it is done. I'd suggest looking first at
Fujitsu, and second at Silicon Motion. Both of these companies
have claimed to be dedicated to providing the embedded
parts for a long time.
> Has anybody else implemented a LCD into a mpc8xx (not 823) board
> successfully ?
Of course. It has an internal LCD/video controller, and there should be
drivers in various kernels.
Thanks.
-- Dan
^ permalink raw reply
* AW: mpc8xx and LCD
From: Fend, Matthias @ 2005-09-29 13:45 UTC (permalink / raw)
To: linuxppc-embedded
hi,=20
>>Can you send a couple of links to the modules you are considering?
there are some 320x240 from EDT (Emerging Display Technologies) with =
S1D13305
S1D13700
http://www.actron.de/graphic_displays_edt.htm
also from Powertip a 320x240 with S1D13305/ S1D13704 is available
http://www.actron.de/graphic_displays_powertip.htm
and also from ampire is one ... (available /w or w/o Epson's S1D =
controller)
http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf
matthias
-----Urspr=FCngliche Nachricht-----
Von: Mark Chambers [mailto:markc@mail.com]=20
Gesendet: Donnerstag, 29. September 2005 14:52
An: Fend, Matthias; linuxppc-embedded@ozlabs.org
Betreff: Re: mpc8xx and LCD
mpc8xx and LCD>hello,
>We want to use mpc860/855 with a 320x240 graphic lcd module.
>Now there are many possibilities to interface such a module, but I =
guess
this is not the first time
>someone will need a LCD display. So I'm trying to find out the most =
common
way to implement the
>desired functionality.
>At the moment I think we should use a lcd controller from Epson =
(S1D13700
or S1D13305) since they are
>working on Linux framebuffer device driver for it. But I'm not sure =
how to
design the hardware interface ... all
>the LCD modules I found provide only a reduced number of port pins so =
that
the controller only can be used
>in indirect-mode, so I'm not sure whether to connect the module =
directly to
the CPUs bus or use some
>GPIO pins for this...
>Has anybody else implemented a LCD into a mpc8xx (not 823) board
successfully ?
>Are there some good resources somewhere in the web about this topic ?
>thanks for your recommendations,
> mattthias
Can you send a couple of links to the modules you are considering?
Mark Chambers
^ permalink raw reply
* RE: How to use SPE on MPC8541
From: Gérard Guével @ 2005-09-29 13:23 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <AD2A3D43-57D8-4198-BAD3-FB5E3B549361@freescale.com>
> Hmm... This is very strange, because Dhrystone is exactly the
> benchmark this was tested on. How did you determine that the SPE
> functions are called?
I prefix the strcpy and strcmp functions with a "v" in dhry21a.c and
dhry21b.c. Then I statically compile the c files with the freescale
assembly source S files and not with the library libcfsl_e500.a.
If I don't add the S files the ld fails else it succeeds.
I retreive the symbols vstr... in the binary dhrystone with readelf.
So I presume that it is the right code that is called.
> I'm not sure why you aren't seeing a performance gain, but I assure
> you that, if SPE instructions weren't working, Dhrystone would
> crash.
I confirm that if I try to run this binary without SPE in Linux kernel
I get an exception.
> The only other possibility I can think of is that the SPE
> versions of the functions aren't being called.
I don't understand what you say.
Perhaps have you a pre-compiled dhrystone for Linux 2.6
I can try and compare on my board
Thanks
Gérard
^ permalink raw reply
* Re: mpc8xx and LCD
From: Mark Chambers @ 2005-09-29 12:52 UTC (permalink / raw)
To: Fend, Matthias, linuxppc-embedded
In-Reply-To: <8D4C69676E66D511A1CB00508BBBB192052D42EF@ranmx1.cs.myharris.net>
mpc8xx and LCD>hello,
>We want to use mpc860/855 with a 320x240 graphic lcd module.
>Now there are many possibilities to interface such a module, but I guess
this is not the first time
>someone will need a LCD display. So I'm trying to find out the most common
way to implement the
>desired functionality.
>At the moment I think we should use a lcd controller from Epson (S1D13700
or S1D13305) since they are
>working on Linux framebuffer device driver for it. But I'm not sure how to
design the hardware interface ... all
>the LCD modules I found provide only a reduced number of port pins so that
the controller only can be used
>in indirect-mode, so I'm not sure whether to connect the module directly to
the CPUs bus or use some
>GPIO pins for this...
>Has anybody else implemented a LCD into a mpc8xx (not 823) board
successfully ?
>Are there some good resources somewhere in the web about this topic ?
>thanks for your recommendations,
> mattthias
Can you send a couple of links to the modules you are considering?
Mark Chambers
^ permalink raw reply
* MPC8555 and USB2
From: Laurent Lagrange @ 2005-09-29 13:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000a01c5c4f4$1a5f1370$5201a8c0@GEG2400>
Hi,
Does anyone knows if an USB2 host controller (EHCI) driver
(even experimental) is available for a MPC8555 ?
Thanks for any idea
Laurent
^ permalink raw reply
* where to find mkfs utility
From: JohnsonCheng @ 2005-09-29 12:51 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 173 bytes --]
Dear All,
When can I found mkfs.mkdos, mkfs.vfat and mkfs.ntfs utilities.
Are all these in the same package, and what is this package name?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 2428 bytes --]
^ permalink raw reply
* Re: CPM2 early console
From: Dan Malek @ 2005-09-29 12:50 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <433BDCE7.2060206@iki.fi>
On Sep 29, 2005, at 8:24 AM, Kalle Pokki wrote:
> flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;
>
> in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on
> this kind of a hack, should it?
This is clearly wrong since other 82xx processors work fine. Something
is amiss with your boot rom or other setup of this processor.
Thanks.
-- Dan
^ 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