* [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Heiko Schocher @ 2008-03-14 9:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell
Hello,
This add support of the mgsuvd board from keymile to
arch/powerpc. Supported SMC1 (serial console),
SCC3 Ethernet (10Mbps hdx)
Signed-off-by: Heiko Schocher <hs@denx.de>
---
arch/powerpc/boot/dts/mgsuvd.dts | 158 +++++++
arch/powerpc/configs/mgsuvd_defconfig | 827 +++++++++++++++++++++++++++++++++
arch/powerpc/platforms/8xx/Kconfig | 7 +
arch/powerpc/platforms/8xx/Makefile | 1 +
arch/powerpc/platforms/8xx/mgsuvd.c | 135 ++++++
5 files changed, 1128 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgsuvd.dts
create mode 100644 arch/powerpc/configs/mgsuvd_defconfig
create mode 100644 arch/powerpc/platforms/8xx/mgsuvd.c
diff --git a/arch/powerpc/boot/dts/mgsuvd.dts b/arch/powerpc/boot/dts/mgsuvd.dts
new file mode 100644
index 0000000..eb6ad3b
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgsuvd.dts
@@ -0,0 +1,158 @@
+/*
+ * MGSUVD Device Tree Source
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher <hs@denx.de>
+ *
+ * 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.
+ */
+
+
+/ {
+ model = "MGSUVD";
+ compatible = "keymile,mgsuvd";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,852@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <d#16>;
+ i-cache-line-size = <d#16>;
+ d-cache-size = <d#8192>;
+ i-cache-size = <d#8192>;
+ timebase-frequency = <0>; /* Filled in by u-boot */
+ bus-frequency = <0>; /* Filled in by u-boot */
+ clock-frequency = <0>; /* Filled in by u-boot */
+ interrupts = <f 2>; /* decrementer interrupt */
+ interrupt-parent = <&PIC>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 4000000>; /* Filled in by u-boot */
+ };
+
+ localbus@fff00100 {
+ compatible = "fsl,pq1-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <fff00100 40>;
+
+ ranges = <
+ 0 0 f0000000 01000000
+ >; /* Filled in by u-boot */
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 1000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <1>;
+ device-width = <1>;
+ partition@0 {
+ label = "u-boot";
+ reg = <0 80000>;
+ };
+ partition@40000 {
+ label = "env";
+ reg = <80000 20000>;
+ };
+ partition@80000 {
+ label = "user";
+ reg = <a0000 f60000>;
+ };
+ };
+ };
+
+ soc@fff00000 {
+ compatible = "fsl,mpc885", "fsl,pq1-soc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0 fff00000 00004000>;
+
+ PIC: interrupt-controller@0 {
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0 24>;
+ compatible = "fsl,pq1-pic";
+ };
+
+ cpm@9c0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,cpm1";
+ command-proc = <9c0>;
+ interrupts = <0>; /* cpm error interrupt */
+ interrupt-parent = <&CPM_PIC>;
+ reg = <9c0 10>;
+ ranges;
+
+ muram@2000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 2000 2000>;
+
+ data@0 {
+ compatible = "fsl,cpm-muram-data";
+ reg = <800 1800>;
+ };
+ };
+
+ brg@9f0 {
+ compatible = "fsl,mpc885-brg",
+ "fsl,cpm1-brg",
+ "fsl,cpm-brg";
+ reg = <9f0 10>;
+ clock-frequency = <3ef1480>;
+ };
+
+ CPM_PIC: interrupt-controller@930 {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <5 2 0 2 20 2>;
+ interrupt-parent = <&PIC>;
+ reg = <930 20>;
+ compatible = "fsl,cpm1-pic";
+ };
+
+ /* MON-1 */
+ serial@a80 {
+ device_type = "serial";
+ compatible = "cpm_uart",
+ "fsl,cpm1-smc-uart";
+ model = "SMC";
+ device-id = <1>;
+ reg = <a80 10 3fc0 40>;
+ interrupts = <4>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-brg = <1>;
+ fsl,cpm-command = <0090>;
+ current-speed = <0>; /* Filled in by u-boot */
+ };
+
+ ethernet@a40 {
+ device_type = "network";
+ compatible = "fs_enet",
+ "fsl,cpm1-scc-enet";
+ model = "SCC";
+ device-id = <3>;
+ reg = <a40 18 3e00 b0>;
+ mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by u-boot */
+ interrupts = <1c>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <80>;
+ fixed-link = <0 0 a 0 0>;
+ };
+ };
+ };
+};
diff --git a/arch/powerpc/configs/mgsuvd_defconfig b/arch/powerpc/configs/mgsuvd_defconfig
new file mode 100644
index 0000000..b586b97
--- /dev/null
+++ b/arch/powerpc/configs/mgsuvd_defconfig
@@ -0,0 +1,827 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.25-rc3
+# Sun Mar 9 09:36:20 2008
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+CONFIG_PPC_8xx=y
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_8xx=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+# CONFIG_PPC_UDBG_16550 is not set
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+# CONFIG_DEFAULT_UIMAGE is not set
+# CONFIG_PPC_DCR_NATIVE is not set
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=17
+# CONFIG_CGROUPS is not set
+CONFIG_GROUP_SCHED=y
+CONFIG_FAIR_GROUP_SCHED=y
+# CONFIG_RT_GROUP_SCHED is not set
+CONFIG_USER_SCHED=y
+# CONFIG_CGROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+# CONFIG_BLK_DEV_INITRD is not set
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+# CONFIG_SYSCTL_SYSCALL is not set
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+# CONFIG_HOTPLUG is not set
+CONFIG_PRINTK=y
+# CONFIG_BUG is not set
+CONFIG_ELF_CORE=y
+CONFIG_COMPAT_BRK=y
+# CONFIG_BASE_FULL is not set
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+# CONFIG_EPOLL is not set
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+# CONFIG_MARKERS is not set
+CONFIG_HAVE_OPROFILE=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_PROC_PAGE_MONITOR=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=1
+# CONFIG_MODULES is not set
+CONFIG_BLOCK=y
+# CONFIG_LBD is not set
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_CLASSIC_RCU=y
+# CONFIG_PREEMPT_RCU is not set
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC512x is not set
+# CONFIG_PPC_MPC5121 is not set
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+CONFIG_CPM1=y
+# CONFIG_MPC8XXFADS is not set
+# CONFIG_MPC86XADS is not set
+# CONFIG_MPC885ADS is not set
+# CONFIG_PPC_EP88XC is not set
+# CONFIG_PPC_ADDER875 is not set
+CONFIG_PPC_MGSUVD=y
+
+#
+# MPC8xx CPM Options
+#
+
+#
+# Generic MPC8xx Options
+#
+CONFIG_8xx_COPYBACK=y
+CONFIG_8xx_CPU6=y
+CONFIG_8xx_CPU15=y
+# CONFIG_NO_UCODE_PATCH is not set
+# CONFIG_USB_SOF_UCODE_PATCH is not set
+# CONFIG_I2C_SPI_UCODE_PATCH is not set
+CONFIG_I2C_SPI_SMC1_UCODE_PATCH=y
+CONFIG_UCODE_PATCH=y
+# CONFIG_PQ2ADS is not set
+# CONFIG_IPIC is not set
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
+# CONFIG_PPC_INDIRECT_IO is not set
+# CONFIG_GENERIC_IOMAP is not set
+# CONFIG_CPU_FREQ is not set
+CONFIG_PPC_CPM_NEW_BINDING=y
+# CONFIG_FSL_ULI1575 is not set
+CONFIG_CPM=y
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+# CONFIG_HZ_100 is not set
+# CONFIG_HZ_250 is not set
+# CONFIG_HZ_300 is not set
+CONFIG_HZ_1000=y
+CONFIG_HZ=1000
+# CONFIG_SCHED_HRTICK is not set
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_RCU_TRACE=y
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+CONFIG_MATH_EMULATION=y
+# CONFIG_IOMMU_HELPER is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_HAS_WALK_MEMORY=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+# CONFIG_PROC_DEVICETREE is not set
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+# CONFIG_SECCOMP is not set
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+CONFIG_FSL_SOC=y
+# CONFIG_PCI is not set
+# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PCI_SYSCALL is not set
+# CONFIG_PCI_QSPAN is not set
+# CONFIG_ARCH_SUPPORTS_MSI is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xfd000000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x00400000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+CONFIG_XFRM=y
+# CONFIG_XFRM_USER is not set
+# CONFIG_XFRM_SUB_POLICY is not set
+# CONFIG_XFRM_MIGRATE is not set
+# CONFIG_XFRM_STATISTICS is not set
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+# CONFIG_IP_PNP_DHCP is not set
+# CONFIG_IP_PNP_BOOTP is not set
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_XFRM_MODE_TRANSPORT=y
+CONFIG_INET_XFRM_MODE_TUNNEL=y
+CONFIG_INET_XFRM_MODE_BEET=y
+# CONFIG_INET_LRO is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_CAN is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+# CONFIG_SYS_HYPERVISOR is not set
+# CONFIG_CONNECTOR is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_NOSWAP=y
+# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
+# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
+CONFIG_MTD_CFI_GEOMETRY=y
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_OTP is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_CFI_FLAGADM is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
+CONFIG_OF_DEVICE=y
+# CONFIG_PARPORT is not set
+CONFIG_BLK_DEV=y
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+CONFIG_BLK_DEV_LOOP=y
+# CONFIG_BLK_DEV_CRYPTOLOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_RAM is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_MISC_DEVICES is not set
+CONFIG_HAVE_IDE=y
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_DMA is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+# CONFIG_MD is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+CONFIG_PHYLIB=y
+
+#
+# MII PHY device drivers
+#
+# CONFIG_MARVELL_PHY is not set
+# CONFIG_DAVICOM_PHY is not set
+# CONFIG_QSEMI_PHY is not set
+# CONFIG_LXT_PHY is not set
+# CONFIG_CICADA_PHY is not set
+# CONFIG_VITESSE_PHY is not set
+# CONFIG_SMSC_PHY is not set
+# CONFIG_BROADCOM_PHY is not set
+# CONFIG_ICPLUS_PHY is not set
+# CONFIG_REALTEK_PHY is not set
+CONFIG_FIXED_PHY=y
+# CONFIG_MDIO_BITBANG is not set
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
+# CONFIG_IBM_NEW_EMAC_RGMII is not set
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
+# CONFIG_B44 is not set
+CONFIG_FS_ENET=y
+CONFIG_FS_ENET_HAS_SCC=y
+# CONFIG_FS_ENET_HAS_FEC is not set
+# CONFIG_FS_ENET_MDIO_FEC is not set
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_WAN is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+# CONFIG_ISDN is not set
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+# CONFIG_SERIAL_8250 is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_CPM=y
+CONFIG_SERIAL_CPM_CONSOLE=y
+# CONFIG_SERIAL_CPM_SCC1 is not set
+# CONFIG_SERIAL_CPM_SCC2 is not set
+# CONFIG_SERIAL_CPM_SCC3 is not set
+# CONFIG_SERIAL_CPM_SCC4 is not set
+CONFIG_SERIAL_CPM_SMC1=y
+# CONFIG_SERIAL_CPM_SMC2 is not set
+CONFIG_UNIX98_PTYS=y
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_IPMI_HANDLER is not set
+CONFIG_HW_RANDOM=y
+# CONFIG_NVRAM is not set
+CONFIG_GEN_RTC=y
+# CONFIG_GEN_RTC_X is not set
+# CONFIG_R3964 is not set
+# CONFIG_RAW_DRIVER is not set
+# CONFIG_TCG_TPM is not set
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_HWMON is not set
+# CONFIG_THERMAL is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_DAB is not set
+
+#
+# Graphics support
+#
+# CONFIG_VGASTATE is not set
+# CONFIG_VIDEO_OUTPUT_CONTROL is not set
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_MMC is not set
+# CONFIG_MEMSTICK is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_EDAC is not set
+# CONFIG_RTC_CLASS is not set
+
+#
+# Userspace I/O
+#
+# CONFIG_UIO is not set
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+# CONFIG_EXT2_FS_POSIX_ACL is not set
+# CONFIG_EXT2_FS_SECURITY is not set
+# CONFIG_EXT2_FS_XIP is not set
+CONFIG_EXT3_FS=y
+CONFIG_EXT3_FS_XATTR=y
+# CONFIG_EXT3_FS_POSIX_ACL is not set
+# CONFIG_EXT3_FS_SECURITY is not set
+# CONFIG_EXT4DEV_FS is not set
+CONFIG_JBD=y
+# CONFIG_JBD_DEBUG is not set
+CONFIG_FS_MBCACHE=y
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+CONFIG_DNOTIFY=y
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+# CONFIG_PROC_KCORE is not set
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+# CONFIG_JFFS2_LZO is not set
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_ROMFS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+
+#
+# Partition Types
+#
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_ACORN_PARTITION is not set
+# CONFIG_OSF_PARTITION is not set
+# CONFIG_AMIGA_PARTITION is not set
+# CONFIG_ATARI_PARTITION is not set
+# CONFIG_MAC_PARTITION is not set
+CONFIG_MSDOS_PARTITION=y
+# CONFIG_BSD_DISKLABEL is not set
+# CONFIG_MINIX_SUBPARTITION is not set
+# CONFIG_SOLARIS_X86_PARTITION is not set
+# CONFIG_UNIXWARE_DISKLABEL is not set
+# CONFIG_LDM_PARTITION is not set
+# CONFIG_SGI_PARTITION is not set
+# CONFIG_ULTRIX_PARTITION is not set
+# CONFIG_SUN_PARTITION is not set
+# CONFIG_KARMA_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+# CONFIG_SYSV68_PARTITION is not set
+# CONFIG_NLS is not set
+# CONFIG_DLM is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+CONFIG_CRC_CCITT=y
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
+CONFIG_ENABLE_MUST_CHECK=y
+# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_UNUSED_SYMBOLS is not set
+CONFIG_DEBUG_FS=y
+# CONFIG_HEADERS_CHECK is not set
+# CONFIG_DEBUG_KERNEL is not set
+# CONFIG_SAMPLES is not set
+# CONFIG_VIRQ_DEBUG is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
+CONFIG_CRYPTO=y
+# CONFIG_CRYPTO_SEQIV is not set
+# CONFIG_CRYPTO_MANAGER is not set
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+# CONFIG_CRYPTO_MD5 is not set
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+# CONFIG_CRYPTO_ECB is not set
+# CONFIG_CRYPTO_CBC is not set
+# CONFIG_CRYPTO_PCBC is not set
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_XTS is not set
+# CONFIG_CRYPTO_CTR is not set
+# CONFIG_CRYPTO_GCM is not set
+# CONFIG_CRYPTO_CCM is not set
+# CONFIG_CRYPTO_CRYPTD is not set
+# CONFIG_CRYPTO_DES is not set
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_SEED is not set
+# CONFIG_CRYPTO_SALSA20 is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_AUTHENC is not set
+# CONFIG_CRYPTO_LZO is not set
+CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set
+CONFIG_PPC_LIB_RHEAP=y
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..4d14b8a 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -53,6 +53,13 @@ config PPC_ADDER875
This enables support for the Analogue & Micro Adder 875
board.
+config PPC_MGSUVD
+ bool "MGSUVD"
+ select CPM1
+ select PPC_CPM_NEW_BINDING
+ help
+ This enables support for the Keymile MGSUVD board.
+
endchoice
menu "Freescale Ethernet driver platform-specific options"
diff --git a/arch/powerpc/platforms/8xx/Makefile b/arch/powerpc/platforms/8xx/Makefile
index 7b71d9c..bdbfd74 100644
--- a/arch/powerpc/platforms/8xx/Makefile
+++ b/arch/powerpc/platforms/8xx/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
obj-$(CONFIG_MPC86XADS) += mpc86xads_setup.o
obj-$(CONFIG_PPC_EP88XC) += ep88xc.o
obj-$(CONFIG_PPC_ADDER875) += adder875.o
+obj-$(CONFIG_PPC_MGSUVD) += mgsuvd.o
diff --git a/arch/powerpc/platforms/8xx/mgsuvd.c b/arch/powerpc/platforms/8xx/mgsuvd.c
new file mode 100644
index 0000000..c6abb10
--- /dev/null
+++ b/arch/powerpc/platforms/8xx/mgsuvd.c
@@ -0,0 +1,135 @@
+/* arch/powerpc/platforms/8xx/mgsuvd.c
+ *
+ * Platform setup for the Keymile mgsuvd board
+ *
+ * Heiko Schocher <hs@denx.de>
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/root_dev.h>
+#include <linux/of_platform.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/mpc8xx.h>
+#include <asm/8xx_immap.h>
+#include <asm/cpm1.h>
+#include <asm/fs_pd.h>
+#include <asm/prom.h>
+
+#include "mpc8xx.h"
+
+extern void cpm_reset(void);
+struct cpm_pin {
+ int port, pin, flags;
+};
+
+static __initdata struct cpm_pin mgsuvd_pins[] = {
+ /* SMC1 */
+ {CPM_PORTB, 24, CPM_PIN_INPUT}, /* RX */
+ {CPM_PORTB, 25, CPM_PIN_INPUT | CPM_PIN_SECONDARY}, /* TX */
+
+ /* SCC3 */
+ {0, 10, CPM_PIN_INPUT},
+ {0, 11, CPM_PIN_INPUT},
+ {0, 3, CPM_PIN_INPUT},
+ {0, 2, CPM_PIN_INPUT},
+ {2, 13, CPM_PIN_INPUT},
+};
+
+static void __init init_ioports(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mgsuvd_pins); i++) {
+ struct cpm_pin *pin = &mgsuvd_pins[i];
+ cpm1_set_pin(pin->port, pin->pin, pin->flags);
+ }
+
+ setbits16(&mpc8xx_immr->im_ioport.iop_pcso, 0x300);
+ cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK5, CPM_CLK_RX);
+ cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK6, CPM_CLK_TX);
+ setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x300);
+ setbits32(&mpc8xx_immr->im_cpm.cp_pbdir, 0x300);
+
+ cpm1_clk_setup(CPM_CLK_SMC1, CPM_BRG1, CPM_CLK_RTX);
+}
+
+static void __init mgsuvd_setup_arch(void)
+{
+ struct device_node *cpu;
+
+ cpu = of_find_node_by_type(NULL, "cpu");
+ if (cpu != 0) {
+ const unsigned int *fp;
+
+ fp = of_get_property(cpu, "clock-frequency", NULL);
+ if (fp != 0)
+ loops_per_jiffy = *fp / HZ;
+ else
+ loops_per_jiffy = 50000000 / HZ;
+ of_node_put(cpu);
+ }
+
+ cpm_reset();
+
+ init_ioports();
+
+ ROOT_DEV = Root_NFS;
+}
+
+static __initdata struct of_device_id of_bus_ids[] = {
+ { .name = "soc", },
+ { .name = "cpm", },
+ { .name = "localbus", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(mgsuvd, declare_of_platform_devices);
+
+static int __init mgsuvd_probe(void)
+{
+ char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
+ "model", NULL);
+ if (model == NULL)
+ return 0;
+ if (strcmp(model, "MGSUVD"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(mgsuvd) {
+ .name = "MGSUVD",
+ .probe = mgsuvd_probe,
+ .setup_arch = mgsuvd_setup_arch,
+ .init_IRQ = mpc8xx_pics_init,
+ .get_irq = mpc8xx_get_irq,
+ .restart = mpc8xx_restart,
+ .calibrate_decr = mpc8xx_calibrate_decr,
+ .set_rtc_time = mpc8xx_set_rtc_time,
+ .get_rtc_time = mpc8xx_get_rtc_time,
+};
--
1.5.4.2
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-14 8:42 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080314074547.BC48926F995@magilla.localdomain>
>> If this doesn't help, and the failures stay intermittent, I don't
>> think
>> there is a close-to-the-hardware problem here.
>
> I saw no effect from that change. So now we're back to pure mystery,
> I guess.
Hey, we know something now: it's "just" a problem in the kernel :-)
Segher
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Roland McGrath @ 2008-03-14 7:45 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <7d9961563967d5f810a5f597519a7c63@kernel.crashing.org>
> In both these cases, the storage access goes to LSU0, so you're
> not hitting the errata.
I'll take your word for it.
> If this doesn't help, and the failures stay intermittent, I don't think
> there is a close-to-the-hardware problem here.
I saw no effect from that change. So now we're back to pure mystery, I guess.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Paul Mackerras @ 2008-03-14 5:19 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47D8AD9C.2030106@austin.ibm.com>
Manish Ahuja writes:
> If Mike and Paul are okay, then I will leave this bit as is and fix all
> other issues and comments.
Well, part of the problem is the semantic dissonance caused by having
a static variable called "global". Please change the name
"phyp_dump_global" to "phyp_dump_vars" or something similar - that
will only affect two lines of code and will reduce the ugliness a bit.
Paul.
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-03-14 4:20 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47D8AD9C.2030106@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
On Wed, 2008-03-12 at 23:29 -0500, Manish Ahuja wrote:
> If Mike and Paul are okay, then I will leave this bit as is and fix all
> other issues and comments.
Well I still don't like it - it uglifies the code _now_, for a potential
future benefit that may never come. But I don't care that much, if
Paul's happy with it let it go in.
cheers
> Linas Vepstas wrote:
> > On 10/03/2008, Michael Ellerman <michael@ellerman.id.au> wrote:
> >> On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
> >
> >> > +
> >> > +/* Global, used to communicate data between early boot and late boot */
> >> > +static struct phyp_dump phyp_dump_global;
> >> > +struct phyp_dump *phyp_dump_info = &phyp_dump_global;
> >>
> >> I don't see the point of this. You have a static (ie. non-global) struct
> >> called phyp_dump_global, then you create a pointer to it and pass that
> >> around.
> >
> > I did this. This is a style used to minimize disruption due to future
> > design changes. Basically, the idea is that, at some later time, for
> > some unknown reason, we decide that this structure shouldn't
> > be global, or maybe shouldn't be statically allocated, or maybe
> > should be per-cpu, or who knows. By creating a pointer, and
> > just passing that around, you isolate other code from this change.
> >
> > I learned this trick after spending too many months of my life hunting
> > down globals and replacing them by dynamically allocated structs.
> > Its a long and painful process, on many levels, often requiring major
> > code restructuring. Code that touches globals directly is often
> > poorly thought out, designed. But going in the opposite direction
> > is easy: if your code always passes everything it needs as args
> > to subroutines, then you are free & clear ... if one of those args
> > just happens to be a pointer to a global, there's no loss (not even
> > a performance loss -- the arg passing overhead is about the same
> > as a global TOC lookup!)
> >
> > So it may look weird if you're not used to seeing it; but the alternative
> > is almost always worse.
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* MPC8241 GPIO
From: Vincent Teoh @ 2008-03-14 3:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
Hi Folks,
I am using an MPC8241 and how can I access the GPIOs? I read the datasheet, the processor doesn't really have any physical GPIOs. I would like to use and configure, if possible, one of the GPIOs to drive one of the LEDs.
Thank you.
-vincent
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[-- Attachment #2: Type: text/html, Size: 751 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-14 2:11 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080313224234.0A4FB26F993@magilla.localdomain>
> The pointer to the test case was given here before.
Oh, I missed that. Anyway, I wanted to see the asm, and who knows,
with different compiler versions and all that.
> 0x10000984 <child_thread+52>: bl 0x10001750 <sleep>
> 0x10000988 <child_thread+56>: lis r9,4097
> ---> 0x1000098c <child_thread+60>: stw r29,7792(r9)
> 0x0000000010000d4c <child_thread+60>: bl 0x10000a88
> 0x0000000010000d50 <child_thread+64>: ld r2,40(r1)
> 0x0000000010000d54 <child_thread+68>: ld r9,-32688(r2)
> ---> 0x0000000010000d58 <child_thread+72>: std r29,0(r9)
In both these cases, the storage access goes to LSU0, so you're
not hitting the errata.
I noticed set_dabr() doesn't do proper synchronisation insns, could
you try this patch? I doubt it helps, but it changes the code to do
"the right thing".
diff --git a/arch/powerpc/kernel/process.c
b/arch/powerpc/kernel/process.c
index 4846bf5..ee925f5 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -250,7 +250,9 @@ int set_dabr(unsigned long dabr)
/* XXX should we have a CPU_FTR_HAS_DABR ? */
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
+ asm("sync");
mtspr(SPRN_DABR, dabr);
+ asm("isync");
#endif
return 0;
}
(badly copy/pasted, please apply by hand. Will send a real patch later
;-) )
If this doesn't help, and the failures stay intermittent, I don't think
there
is a close-to-the-hardware problem here.
Segher
^ permalink raw reply related
* Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-14 1:40 UTC (permalink / raw)
To: Grant Likely; +Cc: u-boot-users, support.asia, linuxppc-embedded
Hi,friends,
I¡¡made follow define on my MPC8360EMDS.h file. Is it enough? The uboot still did
not fill the zero frequency on dtb. I think the ft_cpu_setup and ft_board_setup
function have been run.
/* pass open firmware flat tree */
#define CONFIG_OF_FLAT_TREE 1
#define CONFIG_OF_BOARD_SETUP 1
/* maximum size of the flat tree (8K) */
#define OF_FLAT_TREE_MAX_SIZE 8192
>From: "Grant Likely" <grant.likely@secretlab.ca>
>Reply-To:
>To: "¹ù¾¢" <guojin02@tsinghua.org.cn>
>Subject: Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device
tree?
>Date:Thu, 13 Mar 2008 13:21:35 -0600
>
>On Thu, Mar 13, 2008 at 9:31 AM, ¹ù¾¢ <guojin02@tsinghua.org.cn> wrote:
>> Hi,friends,
>>
>> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency)
value
>> on device tree file equal to zero, I think those frequency will filled by
u-boot
>> during bootm, but in fact, the u-boot did not fill any frequency. after
bootm,
>> crashed. Why?
>>
>> Why so many document point out that the zero value will be filled by u-boot?
>
>In most cases it will assuming that your u-boot board port is
>configured to fill in those values. You need to make sure that the
>ft_board_setup function is getting called by bootm and that it fills
>in those properties.
>
>g.
>
>--
>Grant Likely, B.Sc., P.Eng.
>Secret Lab Technologies Ltd.
>
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Dan Williams @ 2008-03-14 0:06 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <20080313231442.GA4639@lixom.net>
On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <olof@lixom.net> wrote:
> > Dummy descriptors that do nothing but cause an interrupt is the intent.
>
> Well, it'd be slightly more efficient to do add the interrupt attribute
> to the last issued descriptor when it's known in advance. If the
> underlying driver doesn't support it, adding a separate descriptor would
> be a good fallback.
>
When it is known in advance the interrupt attribute *is* set,
otherwise the descriptor may already be in flight.
> Anyway, this isn't likely to be a performance bottleneck. If it turns
> out to be, I'll refactor it and submit patches.
>
Would not hurt to have another pair of eyes on this part of the code.
A rewrite of the channel switch mechanism is currently pending in
async_tx.git#upstream.
[..]
> > > Can't do that if it's called both from the polling as well as the IRQ
> > > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> > > support it will be needed.
> > >
> >
> > ...do it in a tasklet.
>
> Why? That just adds overhead and latency.
>
The original ioat_dma code used nothing heavier than spin_lock_bh.
Async_tx now assumes that local_bh_disable prevents races with any
channel's cleanup routine. Clients can place the same kind of code in
an async_tx callback as they would in a timer callback. The
assumption is that code using async_tx can afford its extra overhead,
which is true for raid. This is also why you don't see async_memcpy
calls in net_dma.
--
Dan
^ permalink raw reply
* Re: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
From: Roland McGrath @ 2008-03-13 23:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev, paulus, anton, mingo, tglx
In-Reply-To: <20080313143510.9cfb7ab4.akpm@linux-foundation.org>
> This is advertised as a -mm patch but afacit it isn't against -mm. And it
> doesn't seem to be against mainline either? At least, the fourth patch
> fails to apply.
Oops, sorry for the bad labeling. The baseline I used was actually x86/mm.
(This was originally going to be just some x86_64 cleanups destined for
post-2.6.25, before I noticed that powerpc had issues.)
> When trying to apply the fourth patch to -mm I hit a reject due to the new
> BTS support in git-x86. I stopped there because the patch might be invalid
> because of this.
The only differences for that stuff should be to pass any new BTS requests
through to arch_ptrace as is done for e.g. PTRACE_GET_THREAD_AREA. I'll
admit I tried not to think about that since it's disabled now and still in
so much flux.
> Even though this appears to be a signal-related patch it is actually
> ptrace-related, yes?
It is a prerequisite for ptrace cleanups/fixes, yes. The change does not
affect any signals code behavior. It may also be useful for other generic
signals compat code later (though I haven't looked into that yet). I'd
call it "compat-related" really.
> This patch is a prerequisite for "ptrace: compat_ptrace_request siginfo",
> but this patch is independent from that patch (and from all others) and
> hence this patch can be merged on its own into powerpc tree if we wish to
> go that way, yes?
Yes.
> Anwyay, please help me out with the dependencies here, and take a look at
> the x86 BTS stuff?
2/4 depends on 1/4 for powerpc64 to keep building.
3/4 depends on 2/4 for x86_64 kernel's 32-bit ptrace calls to keep working.
4/4 depends on 3/4 for same.
I've become fairly confused about the various trees and the state of the
ill-fated BTS code. It's hard to figure out when it's coming and going
from where lately. But resolving the actual code bits in any conflicts
with that will be trivial.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-13 23:14 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <e9c3a7c20803131529j22db434aqdab0ef6f18891d67@mail.gmail.com>
On Thu, Mar 13, 2008 at 03:29:29PM -0700, Dan Williams wrote:
> On Thu, Mar 13, 2008 at 12:54 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
> >
> > > I notice that the driver does not handle callbacks in its descriptor
> > > cleanup path. This could be ok if your intent is only to support the
> > > net_dma style polled operations, but this will not work for the
> > > raid-offload async_tx case. I think the solution is for async_tx to
> > > ignore channels without the DMA_INTERRUPT capability.
> >
> > Good point, and correct - I have mostly been testing this with the
> > NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
> >
>
> Right, it makes use of any capability it can get its hands on,
> otherwise fall back to software.
Badly worded question, but it got answered anyway. What I really meant
to as was "does async_tx use memcpy", I thought it only used xor. Good
to know.
> > Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
> > "prep_dma_interrupt" function, but that doesn't make sense to me. Don't
> > you want the interrupt associated with a specific transaction instead
> > of added as a separate (empty) transaction?
> >
>
> Yes, and that is what happens in most cases. The additional
> prep_dma_interrupt method is for two special cases:
> 1/ Locations where code is submitting an indeterminate number of
> operations and wants an interrupt (callback) at the completion of the
> chain. Someting like:
> list_for_each_entry()
> async_memcpy()
> async_trigger_callback()
Ok, one could argue that it'd make more sense to have a way to issue a
memcpy (or other op) with a callback. Anyway, both methods work.
> 2/ For supporting channel switching on, for instance, a memcpy->xor
> chain where chan1 supports memcpy and chan2 supports xor. When
> async_tx sees this it injects an interrupt for chan1. The xor
> operation gets kicked off by the bottom half of the chan1 interrupt
> handler. However, if chan1 can do both operations no interrupt is
> needed.
>
> > Once I add the descriptor to the ring, I can't change it to set the
> > interrupt request bit on it. I suppose I could just add a dummy descriptor
> > to the ring, but that doesn't seem quite right either.
> >
>
> Dummy descriptors that do nothing but cause an interrupt is the intent.
Well, it'd be slightly more efficient to do add the interrupt attribute
to the last issued descriptor when it's known in advance. If the
underlying driver doesn't support it, adding a separate descriptor would
be a good fallback.
Anyway, this isn't likely to be a performance bottleneck. If it turns
out to be, I'll refactor it and submit patches.
> > > > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > > > +{
> > > > + int old, new, i;
> > > > + unsigned long flags;
> > > > + struct pasemi_dma_desc *desc;
> > > > + spin_lock_irqsave(&chan->desc_lock, flags);
> > >
> > > Is spin_lock_bh() insufficient here?
> > >
> > > ...that's all that jumps out at the moment.
> >
> > Can't do that if it's called both from the polling as well as the IRQ
> > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> > support it will be needed.
> >
>
> ...do it in a tasklet.
Why? That just adds overhead and latency.
-Olof
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Roland McGrath @ 2008-03-13 22:42 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <2f8f82fe943fcd5103ec4cc39cc1bb26@kernel.crashing.org>
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
That's kind of what I thought, but I couldn't make enough sense of
the #8 text to be very sure.
> You could be happening upon #5, if the non-triggering data breakpoints
> are with vector loads/stores in strange code.
They are not.
> It would help if you could give us the disassembly of some code where the
> breakpoint did not trigger; say, that insn and the previous 20 or so insns.
The pointer to the test case was given here before.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ppc-dabr-race.c?cvsroot=systemtap
-m32 Dump of assembler code for function child_thread:
0x10000950 <child_thread+0>: stwu r1,-32(r1)
0x10000954 <child_thread+4>: li r3,207
0x10000958 <child_thread+8>: mflr r0
0x1000095c <child_thread+12>: stw r29,20(r1)
0x10000960 <child_thread+16>: stw r0,36(r1)
0x10000964 <child_thread+20>: crclr 4*cr1+eq
0x10000968 <child_thread+24>: bl 0x10001680 <syscall>
0x1000096c <child_thread+28>: lis r11,4097
0x10000970 <child_thread+32>: mr r29,r3
0x10000974 <child_thread+36>: li r3,1
0x10000978 <child_thread+40>: lwz r9,7800(r11)
0x1000097c <child_thread+44>: addi r9,r9,1
0x10000980 <child_thread+48>: stw r9,7800(r11)
0x10000984 <child_thread+52>: bl 0x10001750 <sleep>
0x10000988 <child_thread+56>: lis r9,4097
---> 0x1000098c <child_thread+60>: stw r29,7792(r9)
0x10000990 <child_thread+64>: bl 0x10001760 <pause>
0x10000994 <child_thread+68>: bl 0x10001760 <pause>
0x10000998 <child_thread+72>: b 0x10000990 <child_thread+64>
End of assembler dump.
-m64 Dump of assembler code for function child_thread:
0x0000000010000d10 <child_thread+0>: mflr r0
0x0000000010000d14 <child_thread+4>: std r29,-24(r1)
0x0000000010000d18 <child_thread+8>: li r3,207
0x0000000010000d1c <child_thread+12>: std r0,16(r1)
0x0000000010000d20 <child_thread+16>: stdu r1,-144(r1)
0x0000000010000d24 <child_thread+20>: bl 0x10000b68
0x0000000010000d28 <child_thread+24>: ld r2,40(r1)
0x0000000010000d2c <child_thread+28>: ld r11,-32696(r2)
0x0000000010000d30 <child_thread+32>: mr r29,r3
0x0000000010000d34 <child_thread+36>: li r3,1
0x0000000010000d38 <child_thread+40>: extsw r29,r29
0x0000000010000d3c <child_thread+44>: lwz r9,0(r11)
0x0000000010000d40 <child_thread+48>: addi r9,r9,1
0x0000000010000d44 <child_thread+52>: clrldi r9,r9,32
0x0000000010000d48 <child_thread+56>: stw r9,0(r11)
0x0000000010000d4c <child_thread+60>: bl 0x10000a88
0x0000000010000d50 <child_thread+64>: ld r2,40(r1)
0x0000000010000d54 <child_thread+68>: ld r9,-32688(r2)
---> 0x0000000010000d58 <child_thread+72>: std r29,0(r9)
0x0000000010000d5c <child_thread+76>: nop
0x0000000010000d60 <child_thread+80>: bl 0x100009a8
0x0000000010000d64 <child_thread+84>: ld r2,40(r1)
0x0000000010000d68 <child_thread+88>: b 0x10000d60 <child_thread+80>
0x0000000010000d6c <child_thread+92>: .long 0x0
0x0000000010000d70 <child_thread+96>: .long 0x1
0x0000000010000d74 <child_thread+100>: lwz r0,0(r3)
End of assembler dump.
Thanks,
Roland
^ permalink raw reply
* [PATCH] [RFC] [POWERPC] Xilinx: OF Serial: add support for 8250 console
From: y @ 2008-03-13 22:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
From: John Linn <john.linn@xilinx.com>
This change to the OF serial driver causes it to setup a console
which then gets the OF data and sets up the 8250 console. Prior to
this the uart was not setup in time for the 8250 console initialization
to work correct.
It appears that the kernel console uart depends on the bootstrap loader
to setup the uart (baud,etc.) prior to the kernel running. Without the
bootstrap loader uart working correctly, the kernel console uart doesn't
work either, is that expected?
Signed-off-by: <john.linn@xilinx.com>
---
drivers/serial/8250.c | 10 +++-
drivers/serial/of_serial.c | 115 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..d8e211e 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2547,7 +2547,7 @@ static int serial8250_console_early_setup(void)
}
static struct uart_driver serial8250_reg;
-static struct console serial8250_console = {
+struct console serial8250_console = {
.name = "ttyS",
.write = serial8250_console_write,
.device = uart_console_device,
@@ -2558,13 +2558,19 @@ static struct console serial8250_console = {
.data = &serial8250_reg,
};
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
{
serial8250_isa_init_ports();
register_console(&serial8250_console);
return 0;
}
+
+/* when OF is being used with the 8250 console, the OF hooks in the
+ 8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(CONFIG_SERIAL_OF_PLATFORM)
console_initcall(serial8250_console_init);
+#endif
int serial8250_find_port(struct uart_port *p)
{
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..c80198b 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
#include <linux/module.h>
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
+#include <linux/console.h>
#include <asm/of_platform.h>
#include <asm/prom.h>
+#include <asm/io.h>
struct of_serial_info {
int type;
@@ -158,6 +160,119 @@ static void __exit of_platform_serial_exit(void)
};
module_exit(of_platform_serial_exit);
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && defined(CONFIG_SERIAL_OF_PLATFORM)
+
+/* when an 8250 console is being used and OF, the OF needs to
+ setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int __init early_serial_console_setup(struct uart_port *port);
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] = {
+ { .type = "serial", .compatible = "ns16550", },
+ {},
+};
+
+/*
+ * Setup the console based on OF properties
+ */
+static int __init console_of_setup(struct device_node *np,
+ struct uart_port *port)
+{
+ struct resource resource;
+ const unsigned int *clk, *spd, *regshift;
+ int ret;
+
+ memset(port, 0, sizeof *port);
+ spd = of_get_property(np, "current-speed", NULL);
+ regshift = of_get_property(np, "reg-shift", NULL);
+ clk = of_get_property(np, "clock-frequency", NULL);
+ if (!clk) {
+ return -ENODEV;
+ }
+
+ ret = of_address_to_resource(np, 0, &resource);
+ if (ret) {
+ return ret;
+ }
+
+ spin_lock_init(&port->lock);
+ port->irq = irq_of_parse_and_map(np, 0);
+ port->iotype = UPIO_MEM;
+ port->type = PORT_16550;
+ port->uartclk = *clk;
+ port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
+ | UPF_FIXED_PORT;
+ if (spd) {
+ port->custom_divisor = *clk / (16 * (*spd));
+ }
+
+ if (regshift) {
+ port->regshift = *regshift;
+ port->mapbase = resource.start + ((1 << *regshift) - 1);
+ } else {
+ port->mapbase = resource.start;
+ }
+ return 0;
+}
+
+static struct device_node __init *console_of_find_device(int id)
+{
+ struct device_node *np;
+ const struct of_device_id *matches = uart_of_match;
+
+ while (matches->compatible[0]) {
+ for_each_compatible_node(np, NULL, matches->compatible) {
+ if (!of_match_node(matches, np))
+ continue;
+
+ of_node_put(np);
+ return np;
+ }
+ matches++;
+ }
+ return 0;
+}
+
+static int __init console_setup(struct console *co)
+{
+ struct device_node *np;
+
+ /* Find a matching uart port in the device tree */
+ np = console_of_find_device(co->index);
+ if (!np)
+ return -ENODEV;
+
+ if (console_of_setup(np, &of_uart_port))
+ return -ENODEV;
+
+ /* registers mapped yet? */
+ if (!of_uart_port.membase) {
+ of_uart_port.membase = ioremap(of_uart_port.mapbase, 256);
+ if (of_uart_port.membase)
+ return -ENODEV;
+ }
+ return 0;
+}
+
+/* This function sets up the 8250 console by getting the OF data at
+ console init time and then setting up the 8250 uart and console.
+ This solves the problem of the OF uart not being setup in time
+ for the 8250 console to use it.
+*/
+static int __init of_console_init(void)
+{
+ console_setup(&serial8250_console);
+ early_serial_setup(&of_uart_port);
+ serial8250_console_init();
+ return 0;
+}
+
+console_initcall(of_console_init);
+#endif
+
MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Serial Port driver for Open Firmware platform devices");
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Dan Williams @ 2008-03-13 22:29 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <20080313195431.GA1449@lixom.net>
On Thu, Mar 13, 2008 at 12:54 PM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
>
> > I notice that the driver does not handle callbacks in its descriptor
> > cleanup path. This could be ok if your intent is only to support the
> > net_dma style polled operations, but this will not work for the
> > raid-offload async_tx case. I think the solution is for async_tx to
> > ignore channels without the DMA_INTERRUPT capability.
>
> Good point, and correct - I have mostly been testing this with the
> NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
>
Right, it makes use of any capability it can get its hands on,
otherwise fall back to software.
> Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
> "prep_dma_interrupt" function, but that doesn't make sense to me. Don't
> you want the interrupt associated with a specific transaction instead
> of added as a separate (empty) transaction?
>
Yes, and that is what happens in most cases. The additional
prep_dma_interrupt method is for two special cases:
1/ Locations where code is submitting an indeterminate number of
operations and wants an interrupt (callback) at the completion of the
chain. Someting like:
list_for_each_entry()
async_memcpy()
async_trigger_callback()
2/ For supporting channel switching on, for instance, a memcpy->xor
chain where chan1 supports memcpy and chan2 supports xor. When
async_tx sees this it injects an interrupt for chan1. The xor
operation gets kicked off by the bottom half of the chan1 interrupt
handler. However, if chan1 can do both operations no interrupt is
needed.
> Once I add the descriptor to the ring, I can't change it to set the
> interrupt request bit on it. I suppose I could just add a dummy descriptor
> to the ring, but that doesn't seem quite right either.
>
Dummy descriptors that do nothing but cause an interrupt is the intent.
>
> > > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > > +{
> > > + int old, new, i;
> > > + unsigned long flags;
> > > + struct pasemi_dma_desc *desc;
> > > + spin_lock_irqsave(&chan->desc_lock, flags);
> >
> > Is spin_lock_bh() insufficient here?
> >
> > ...that's all that jumps out at the moment.
>
> Can't do that if it's called both from the polling as well as the IRQ
> context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> support it will be needed.
>
...do it in a tasklet.
>
> -Olof
>
Regards,
Dan
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-13 22:20 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080313014745.DE97826F992@magilla.localdomain>
> AFAICT the DABRX register just has two global bits that enable paying
> attention to the DABR register.
It has four bits:
01 match in user mode
02 match in supervisor mode
04 match in hypervisor mode
08 ignore translation field in DABR
If the kernel can write to DABRX, it is running in hypervisor mode, so
it should set 07 instead of 03 (as it currently does) if it wants to
match in kernel mode; or 01, if it doesn't.
OTOH, the Apple version of the 970 is special (it has no separate
hypervisor mode); still, 07 should always work.
> It only needs to be set once at boot time
> (as the cell code does). I don't see how missing that initialization
> could
> ever have explained the behavior we see where DABR matches are
> intermittent.
> If those DABRX bits weren't set then no DABR match would have happened.
> (Apparently they are set before boot on an Apple G5.)
I don't see the Apple boot code initialising DABRX; maybe the bootup
state
for DABRX is 07, dunno. Either way, it would be good if the kernel set
it
properly, esp. if it wants to enable or disable matches in the kernel
itself.
> What we actually see is that DABR matches seem to be reliable when
> things
> are slow, and get intermittent when there are enough threads with DABR
> set.
> I happened across:
>
> http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/
> 79B6E24422AA101287256E93006C957E/$file/
> PowerPC_970FX_errata_DD3.X_V1.7.pdf
>
> which is "IBM PowerPC 970FX RISC Microprocessor Errata List for DD3.X"
> and contains "Erratum #8: DABRX register might not always be updated
> correctly":
> The only machine I have at home for testing powerpc is an Apple G5,
> supplied to me by IBM. It says:
> cpu : PPC970FX, altivec supported
> revision : 3.0 (pvr 003c 0300)
> so I am guessing this document applies to the chips I have.
Indeed.
> Since I can't
> test on other chips myself, it is plausible from what I've seen that
> there
> is no mysterious kernel problem and only this hardware problem. The
> description of the hardware problem would not make me think that it
> would
> behave this way, but it is not very detailed or precise, or at least
> does
> not seem so to a reader not expert on powerpc.
Since the 970 kernel never sets DABRX currently, #8 cannot explain
_intermittent_ problems: either it always works, or never does.
You could be happening upon #5, if the non-triggering data breakpoints
are with vector loads/stores in strange code.
> I don't know what I can do next to tell whether this processor erratum
> is in
> fact what's happening in the test case. If it is, I don't know if
> there
> might be some arcane way to work around it despite "None" cited above.
It would help if you could give us the disassembly of some code where
the
breakpoint did not trigger; say, that insn and the previous 20 or so
insns.
Segher
^ permalink raw reply
* Re: Linux UIO driver cache problem in PowerPC (fix)
From: Grant Likely @ 2008-03-13 21:53 UTC (permalink / raw)
To: Hans-Jürgen Koch, Josh Boyer, linuxppc-embedded
Cc: Jean-Samuel Chenard, LKML, Greg KH
In-Reply-To: <20080313081932.4edee290@dilbert.local>
On Thu, Mar 13, 2008 at 1:19 AM, Hans-J=FCrgen Koch <hjk@linutronix.de> wro=
te:
> Am Wed, 12 Mar 2008 15:22:59 -0400
> schrieb "Jean-Samuel Chenard" <jsamch@gmail.com>:
>
> > Hi,
>
> Hi Jean-Samuel,
> thanks for your report. Please CC LKML if you find bugs like this. I
> also added Grant Likely (PPC Xilinx Virtex maintainer), as it seems to
> be a platform specific problem.
Hmmm. I'm not a memory handling expert so I don't know what's going
on here. Josh, does this look like anything that would be ppc405
related?
g.
>
> >
> > Experimenting with your userspace I/O driver on a Xilinx FPGA (PowerPC
> > 405), I was having problems when reading hardware device registers
> > mapped on my platform using the user-space mmap() call.
> >
> > After some investigation (looking at the driver/char/mspec.c file), I
> > found that preventing caching of the page in uio_mmap_physical fixed
> > my issues with userspace mmap() reading messed-up values.
>
> Hm, we already mark the page with VM_IO. That's sufficient on x86 and
> arm. I'm not sure whether this is a bug in PPC memory handling. Why do
> they cache VM_IO pages?
>
> >
> > This patch is against your initial commit of the UIO driver in the
> > mainline kernel tree.
> >
> > =3D=3D=3D=3D
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 865f32b..36e1123 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -22,6 +22,7 @@
> > #include <linux/string.h>
> > #include <linux/kobject.h>
> > #include <linux/uio_driver.h>
> > +#include <asm/pgtable.h>
> >
> > #define UIO_MAX_DEVICES 255
> >
> > @@ -447,6 +448,8 @@ static int uio_mmap_physical(struct
> > vm_area_struct *vma)
> >
> > vma->vm_flags |=3D VM_IO | VM_RESERVED;
> >
> > + vma->vm_page_prot =3D pgprot_noncached(vma->vm_page_prot);
> > +
> > return remap_pfn_range(vma,
> > vma->vm_start,
> > idev->info->mem[mi].addr >> PAGE_SHIFT,
> > =3D=3D=3D=3D
> >
> > I am a bit unsure if this will break something in any of your uses of
> > the UIO driver (on other platforms than ppc), but it really fixes
> > things for me.
>
> It should be OK, but unneccesary on other platforms. I have no
> objections, but I fear in 6 months we'll see a patch removing that
> line again because it's not needed...
>
> > Let me know if you need more details on what was
> > happening on my platform before I added this statement.
>
> I'd like to hear the opinion of people really involved in PPC memory
> handling.
>
> >
> > Thanks for the great driver for user-space I/O, it will save me lots
> > of time in my research.
> >
> > Regards,
> >
> > Jean-Samuel
>
> Thanks,
> Hans
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: Grant Likely @ 2008-03-13 21:50 UTC (permalink / raw)
To: René Bürgel; +Cc: linuxppc-dev
In-Reply-To: <47D827A5.8040701@unicontrol.de>
On Wed, Mar 12, 2008 at 12:57 PM, Ren=E9 B=FCrgel <r.buergel@unicontrol.de>=
wrote:
> Here is a patch for the lite5200 to get the FEC working again for kernel
> >=3D2.6.24. It was created against Linux 2.6.24.
>
> The FEC driver is also compatible with the MPC5200, not only with the
> MPC5200B, so an according entry was added to the drivers matching list.
> Furthermore the settings for the PHY were entered in the dts file for
> the Lite5200. Note, that this is not exactly the same as in the
> Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
> at :00 for the 5200B. I could test the patch on a Lite5200 and a
> Lite5200B, both booted a kernel via tftp and mounted the root via nfs
> successfully.
> I hope, you can include the patch into the official tree.
Looks good. I'll pick this one up.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
From: Andrew Morton @ 2008-03-13 21:35 UTC (permalink / raw)
To: Roland McGrath; +Cc: linux-kernel, linuxppc-dev, paulus, anton, mingo, tglx
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
Problems.
> Subject: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
This is advertised as a -mm patch but afacit it isn't against -mm. And it
doesn't seem to be against mainline either? At least, the fourth patch
fails to apply.
When trying to apply the fourth patch to -mm I hit a reject due to the new
BTS support in git-x86. I stopped there because the patch might be invalid
because of this.
On Thu, 13 Mar 2008 01:31:07 -0700 (PDT)
Roland McGrath <roland@redhat.com> wrote:
>
> Define the copy_siginfo_from_user32 entry point for powerpc, so
> that generic CONFIG_COMPAT code can call it. We already had the
> code rolled into compat_sys_rt_sigqueueinfo, this just moves it
> out into the canonical function that other arch's define.
>
Even though this appears to be a signal-related patch it is actually
ptrace-related, yes?
This patch is a prerequisite for "ptrace: compat_ptrace_request siginfo",
but this patch is independent from that patch (and from all others) and
hence this patch can be merged on its own into powerpc tree if we wish to go that
way, yes? (Although probably it would be better not to do it that way, for
sanity's sake).
Anwyay, please help me out with the dependencies here, and take a look at
the x86 BTS stuff?
Thanks.
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-13 19:54 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <1205255051.26723.19.camel@dwillia2-linux.ch.intel.com>
On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
> I notice that the driver does not handle callbacks in its descriptor
> cleanup path. This could be ok if your intent is only to support the
> net_dma style polled operations, but this will not work for the
> raid-offload async_tx case. I think the solution is for async_tx to
> ignore channels without the DMA_INTERRUPT capability.
Good point, and correct - I have mostly been testing this with the
NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
"prep_dma_interrupt" function, but that doesn't make sense to me. Don't
you want the interrupt associated with a specific transaction instead
of added as a separate (empty) transaction?
Once I add the descriptor to the ring, I can't change it to set the
interrupt request bit on it. I suppose I could just add a dummy descriptor
to the ring, but that doesn't seem quite right either.
> > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > +{
> > + int old, new, i;
> > + unsigned long flags;
> > + struct pasemi_dma_desc *desc;
> > + spin_lock_irqsave(&chan->desc_lock, flags);
>
> Is spin_lock_bh() insufficient here?
>
> ...that's all that jumps out at the moment.
Can't do that if it's called both from the polling as well as the IRQ
context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
support it will be needed.
-Olof
^ permalink raw reply
* [PATCH] convert pci and eeh code to of_device_is_available
From: Nathan Lynch @ 2008-03-13 19:52 UTC (permalink / raw)
To: linuxppc-dev
A couple of places are duplicating the function of
of_device_is_available; convert them to use it.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
This depends on Josh Boyer's patch "[OF] Add of_device_is_available
function":
http://patchwork.ozlabs.org/linuxppc/patch?id=17100
arch/powerpc/kernel/rtas_pci.c | 19 ++-----------------
arch/powerpc/platforms/pseries/eeh.c | 5 ++---
2 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 433a0a0..39a752b 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -56,21 +56,6 @@ static inline int config_access_valid(struct pci_dn *dn, int where)
return 0;
}
-static int of_device_available(struct device_node * dn)
-{
- const char *status;
-
- status = of_get_property(dn, "status", NULL);
-
- if (!status)
- return 1;
-
- if (!strcmp(status, "okay"))
- return 1;
-
- return 0;
-}
-
int rtas_read_config(struct pci_dn *pdn, int where, int size, u32 *val)
{
int returnval = -1;
@@ -117,7 +102,7 @@ static int rtas_pci_read_config(struct pci_bus *bus,
for (dn = busdn->child; dn; dn = dn->sibling) {
struct pci_dn *pdn = PCI_DN(dn);
if (pdn && pdn->devfn == devfn
- && of_device_available(dn))
+ && of_device_is_available(dn))
return rtas_read_config(pdn, where, size, val);
}
@@ -164,7 +149,7 @@ static int rtas_pci_write_config(struct pci_bus *bus,
for (dn = busdn->child; dn; dn = dn->sibling) {
struct pci_dn *pdn = PCI_DN(dn);
if (pdn && pdn->devfn == devfn
- && of_device_available(dn))
+ && of_device_is_available(dn))
return rtas_write_config(pdn, where, size, val);
}
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 9eb539e..550b2f7 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -945,7 +945,6 @@ static void *early_enable_eeh(struct device_node *dn, void *data)
unsigned int rets[3];
struct eeh_early_enable_info *info = data;
int ret;
- const char *status = of_get_property(dn, "status", NULL);
const u32 *class_code = of_get_property(dn, "class-code", NULL);
const u32 *vendor_id = of_get_property(dn, "vendor-id", NULL);
const u32 *device_id = of_get_property(dn, "device-id", NULL);
@@ -959,8 +958,8 @@ static void *early_enable_eeh(struct device_node *dn, void *data)
pdn->eeh_freeze_count = 0;
pdn->eeh_false_positives = 0;
- if (status && strncmp(status, "ok", 2) != 0)
- return NULL; /* ignore devices with bad status */
+ if (!of_device_is_available(dn))
+ return NULL;
/* Ignore bad nodes. */
if (!class_code || !vendor_id || !device_id)
--
1.5.4.rc5
^ permalink raw reply related
* Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device tree?
From: Grant Likely @ 2008-03-13 19:21 UTC (permalink / raw)
To: 郭劲; +Cc: u-boot-users, support.asia, linuxppc-embedded
In-Reply-To: <405422271.18508@tsinghua.org.cn>
T24gVGh1LCBNYXIgMTMsIDIwMDggYXQgOTozMSBBTSwgufm+oiA8Z3VvamluMDJAdHNpbmdodWEu
b3JnLmNuPiB3cm90ZToKPiBIaSxmcmllbmRzLAo+Cj4gIEkgbWFrZSBhbGwgdGhlIGZyZXF1ZW5j
eSh0aW1lYmFzZS1mcmVxdWVuY3k7YnVzLWZyZXF1ZW5jeTtjbG9jay1mcmVxdWVuY3kpIHZhbHVl
Cj4gIG9uIGRldmljZSB0cmVlIGZpbGUgZXF1YWwgdG8gemVybywgSSB0aGluayB0aG9zZSBmcmVx
dWVuY3kgd2lsbCBmaWxsZWQgYnkgdS1ib290Cj4gIGR1cmluZyBib290bSwgYnV0IGluIGZhY3Qs
IHRoZSB1LWJvb3QgZGlkIG5vdCBmaWxsIGFueSBmcmVxdWVuY3kuIGFmdGVyIGJvb3RtLAo+ICBj
cmFzaGVkLiBXaHk/Cj4KPiAgV2h5IHNvIG1hbnkgZG9jdW1lbnQgcG9pbnQgb3V0IHRoYXQgdGhl
IHplcm8gdmFsdWUgd2lsbCBiZSBmaWxsZWQgYnkgdS1ib290PwoKSW4gbW9zdCBjYXNlcyBpdCB3
aWxsIGFzc3VtaW5nIHRoYXQgeW91ciB1LWJvb3QgYm9hcmQgcG9ydCBpcwpjb25maWd1cmVkIHRv
IGZpbGwgaW4gdGhvc2UgdmFsdWVzLiAgWW91IG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlCmZ0
X2JvYXJkX3NldHVwIGZ1bmN0aW9uIGlzIGdldHRpbmcgY2FsbGVkIGJ5IGJvb3RtIGFuZCB0aGF0
IGl0IGZpbGxzCmluIHRob3NlIHByb3BlcnRpZXMuCgpnLgoKLS0gCkdyYW50IExpa2VseSwgQi5T
Yy4sIFAuRW5nLgpTZWNyZXQgTGFiIFRlY2hub2xvZ2llcyBMdGQuCg==
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: Wood, Robert (GE EntSol, Intelligent Platforms) @ 2008-03-13 16:55 UTC (permalink / raw)
To: Sugathan, Rupesh, linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F251BB1CC@ccomm-ex1.ccomm.com>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
Thanks for the help. The archives were tedious to search but very
enlightening.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
________________________________
From: Sugathan, Rupesh [mailto:rs@carriercomm.com]
Sent: Thursday, March 13, 2008 12:52 PM
To: Wood, Robert (GE EntSol, Intelligent Platforms);
linuxppc-embedded@ozlabs.org
Subject: RE: Using GDB with Abatron's BDI2000 and the ppc405 in the
Xilinx VirtexII Pro
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
See if these helps
http://www.unimax.co.kr/unimax_2003_11/products/datasheets/ManGDBPPC-200
0C5.pdf
http://microcross.com/Debugging_Linux_Kernel.pdf
<http://microcross.com/Debugging_Linux_Kernel.pdf>
http://ultsol.com/pdfs/ <http://ultsol.com/pdfs/>
Thanks
--
Rupesh Sugathan
[-- Attachment #2: Type: text/html, Size: 9561 bytes --]
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers
*Solid grounding in Linux/Unix internals
*Hardware board bringup, ability to read schematic drawings
*PowerPC assembly, a plus
*Familiarity with Clearcase, cvs or other SCM systems
*Ability to document and communicate original designs
*At least a BSCS or BSEE
*Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software
*TCL , PERL, Python or other scripting language
*Knowledge of Cisco's Data Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company=20
* Experience with the bring-up of complex PC boards with advanced CPU,
DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale)=20
* Linux experience=20
* UBoot experience=20
* ATCA experience highly desirable=20
* Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education=20
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:57 UTC (permalink / raw)
To: linuxppc-dev
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers *Solid grounding
in Linux/Unix internals *Hardware board bringup, ability to read
schematic drawings *PowerPC assembly, a plus *Familiarity with
Clearcase, cvs or other SCM systems *Ability to document and communicate
original designs *At least a BSCS or BSEE *Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software *TCL ,
PERL, Python or other scripting language *Knowledge of Cisco's Data
Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company * Experience with the bring-up of complex PC boards with
advanced CPU, DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale) * Linux
experience * UBoot experience * ATCA experience highly desirable *
Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ permalink raw reply
* console kernel parameter problem
From: Fabio Ubaldi @ 2008-03-13 16:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm working with a board with a MPC8548 processor. I built the uboot,
the DTS file (myboard.dtb) and a kernel 2.6.21 .
When I try to boot the kernel via NFS I have some exception mode when
parsing the kernel parameters. Specifically I obtained an error during
the parsing of "console" parameter.
My host computer is connected to the board via console using a standard
8250 port.
I append the log in this post.
Has anyone any suggestion?
Thanks in advance for the reply.
root=/dev/nfs rw nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
=>
=>
=> run nfsboot
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'uImage'.
Load address: 0x1000000
Loading: *\b
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'myboard.dtb'.
Load address: 0x3000000
Loading: *\b
## Booting image at 01000000 ...
Image Name: Linux-2.6.21.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1509390 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x3000000
Loading Device Tree to 007fc000, end 007fd313 ... OK
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
early options: Parameter `root'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `root'
early options: Parameter `rw'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `rw'
early options: Parameter `nfsroot'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `nfsroot'
early options: Parameter `ip'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `ip'
early options: Parameter `console'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `console'
Using MYBOARD machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=256Mb residual: 256Mb
Linux version 2.6.21.7 (gcc version 4.1.2 ) #2 PREEMPT Thu Mar 13
16:30:01 GMT 2008
setup_arch: bootmem
setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 262144
early_node_map[1] active PFN ranges
0: 0 -> 262144
Built 1 zonelists. Total pages: 260096
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Booting kernel: Parameter `root'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `root=/dev/nfs'
Booting kernel: Parameter `rw'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `rw'
Booting kernel: Parameter `nfsroot'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs'
Booting kernel: Parameter `ip'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off'
Booting kernel: Parameter `console'
Unknown argument: calling c02dc318
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
Modules linked in:
NIP: C02E7B30 LR: C02E7C28 CTR: 00000000
REGS: c031be80 TRAP: 0700 Not tainted (2.6.21.7)
MSR: 00021000 <ME> CR: 24084022 XER: 00000000
TASK = c02fe5b8[0] 'swapper' THREAD: c031a000
GPR00: 00000000 C031BF30 C02FE5B8 C0332184 C031BF58 C035595A C031BF5E
C0300000
GPR08: 0000000A C0332184 00000001 C0332184 00000000 60000000 3FFFC400
03000000
GPR16: 00000001 00000000 007FFF00 00000000 00000000 007FFEB0 00000000
C02D6000
GPR24: 00000044 00021000 00000000 C035595A 00000001 C031BF58 C0332184
00000000
NIP [C02E7B30] add_preferred_console+0xac/0xd8
LR [C02E7C28] console_setup+0xcc/0xe4
Call Trace:
[C031BF30] [C03017C0] 0xc03017c0 (unreliable)
[C031BF50] [C02E7C28] console_setup+0xcc/0xe4
[C031BF70] [C02DC400] unknown_bootoption+0xe8/0x260
[C031BF90] [C003DDC8] parse_args+0x1f8/0x310
[C031BFC0] [C02DC7F4] start_kernel+0x16c/0x2b4
[C031BFF0] [C0000388] skpinv+0x2b8/0x2f4
Instruction dump:
48000048 3d20c030 38600000 93e9ff98 48000038 3d20c030 93e9ff98 3d20c033
39292184 57eb2036 7d6b4a14 38000000 <7d3d44aa> 7d2b45aa 38600000 938b0008
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
^ 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