* mpic_alloc() parameter change in 2.6.18-rc4 - must update users
From: Guennadi Liakhovetski @ 2006-08-20 22:16 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
have all platforms been updated for the mpic_alloc() change in -rc4 since
then? AFAICS, at least 85xx/mpc85xx_cds.c, 86xx/mpc86xx_hpcn.c,
embedded6xx/mpc7448_hpc2.c in -rc4 are new and are calling it with the old
parameters. Or has it already been fixed in some tree?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* [PATCH] Add adder87x board support to 2.6.x
From: Bryan O'Donoghue @ 2006-08-20 19:36 UTC (permalink / raw)
To: marcelo, linuxppc-embedded
Greetings all.
This set of patches adds support for the Analogue & Micro Adder87x to Linux.
The port is based on mpc885ads in the 2.6.18-rc4 tree.
The patches are very simple really consisting of a stripped down version of
mpc885ads renamed to adder87x*blah, a defconfig and appropriate entries in
arch/ppc/Kconfig, arch/ppc/platforms/Makefile and include/asm-ppc/mpc8xx.h.
I've spent a bit of time testing this out, and I'm reasonably happy that this
should be useful to others using this development board.
Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
modified: arch/ppc/Kconfig
new file: arch/ppc/configs/adder87x_defconfig
modified: arch/ppc/platforms/Makefile
new file: arch/ppc/platforms/adder87x.h
new file: arch/ppc/platforms/adder87x_setup.c
modified: include/asm-ppc/mpc8xx.h
---
arch/ppc/Kconfig | 5
arch/ppc/configs/adder87x_defconfig | 767 +++++++++++++++++++++++++++++++++++
arch/ppc/platforms/Makefile | 1
arch/ppc/platforms/adder87x.h | 32 +
arch/ppc/platforms/adder87x_setup.c | 276 +++++++++++++
include/asm-ppc/mpc8xx.h | 4
6 files changed, 1085 insertions(+), 0 deletions(-)
create mode 100644 arch/ppc/configs/adder87x_defconfig
create mode 100644 arch/ppc/platforms/adder87x.h
create mode 100644 arch/ppc/platforms/adder87x_setup.c
79f0a05e41edfca35038448810959aa6a1f8c943
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -478,6 +478,11 @@ config WINCEPT
MPC821 PowerPC, introduced in 1998 and designed to be used in
thin-client machines. Say Y to support it directly.
+config ADDER87X
+ bool "ADDER87X"
+ help
+ The Analogue and Micro Adder87x, with Das U-Boot as a bootloader.
+
endchoice
menu "Freescale Ethernet driver platform-specific options"
diff --git a/arch/ppc/configs/adder87x_defconfig b/arch/ppc/configs/adder87x_defconfig
new file mode 100644
--- /dev/null
+++ b/arch/ppc/configs/adder87x_defconfig
@@ -0,0 +1,767 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.18-rc4
+# Sun Aug 20 17:03:31 2006
+#
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_PPC=y
+CONFIG_PPC32=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+CONFIG_SYSCTL=y
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+# CONFIG_RELAY is not set
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EMBEDDED=y
+# CONFIG_KALLSYMS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_RT_MUTEXES=y
+CONFIG_FUTEX=y
+# CONFIG_EPOLL is not set
+CONFIG_SHMEM=y
+CONFIG_SLAB=y
+CONFIG_VM_EVENT_COUNTERS=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+# CONFIG_SLOB is not set
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+# CONFIG_MODULE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+# CONFIG_KMOD is not set
+
+#
+# Block layer
+#
+# CONFIG_LBD is not set
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+# CONFIG_IOSCHED_AS is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_DEFAULT_AS is not set
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+CONFIG_DEFAULT_NOOP=y
+CONFIG_DEFAULT_IOSCHED="noop"
+
+#
+# Processor
+#
+# CONFIG_6xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+CONFIG_8xx=y
+# CONFIG_E200 is not set
+# CONFIG_E500 is not set
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_KEXEC is not set
+# CONFIG_CPU_FREQ is not set
+# CONFIG_WANT_EARLY_SERIAL is not set
+CONFIG_EMBEDDEDBOOT=y
+CONFIG_NOT_COHERENT_CACHE=y
+
+#
+# Platform options
+#
+# CONFIG_RPXLITE is not set
+# CONFIG_RPXCLASSIC is not set
+# CONFIG_BSEIP is not set
+# CONFIG_MPC8XXFADS is not set
+# CONFIG_MPC86XADS is not set
+# CONFIG_MPC885ADS is not set
+# CONFIG_TQM823L is not set
+# CONFIG_TQM850L is not set
+# CONFIG_TQM855L is not set
+# CONFIG_TQM860L is not set
+# CONFIG_FPS850L is not set
+# CONFIG_IVMS8 is not set
+# CONFIG_IVML24 is not set
+# CONFIG_HERMES_PRO is not set
+# CONFIG_IP860 is not set
+# CONFIG_LWMON is not set
+# CONFIG_PCU_E is not set
+# CONFIG_CCM is not set
+# CONFIG_LANTEC is not set
+# CONFIG_MBX is not set
+# CONFIG_WINCEPT is not set
+CONFIG_ADDER87X=y
+
+#
+# Freescale Ethernet driver platform-specific options
+#
+CONFIG_CPM1=y
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+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_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+# CONFIG_SOFTWARE_SUSPEND is not set
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PCI is not set
+# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PCI_QSPAN is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_HIGHMEM_START=0xfe000000
+# CONFIG_LOWMEM_SIZE_BOOL is not set
+CONFIG_LOWMEM_SIZE=0x30000000
+# CONFIG_KERNEL_START_BOOL is not set
+CONFIG_KERNEL_START=0xc0000000
+# CONFIG_TASK_SIZE_BOOL is not set
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START_BOOL=y
+CONFIG_CONSISTENT_START=0xff400000
+CONFIG_CONSISTENT_SIZE_BOOL=y
+CONFIG_CONSISTENT_SIZE=0x00200000
+# CONFIG_BOOT_LOAD_BOOL is not set
+CONFIG_BOOT_LOAD=0x00400000
+# CONFIG_PIN_TLB is not set
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+# CONFIG_NETDEBUG is not set
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+CONFIG_XFRM=y
+# CONFIG_XFRM_USER is not set
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# 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_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+# 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
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+
+#
+# TIPC Configuration (EXPERIMENTAL)
+#
+# 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_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_SYS_HYPERVISOR is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+# CONFIG_CONNECTOR is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_RAM is not set
+# CONFIG_BLK_DEV_INITRD is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+# CONFIG_FUSION is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+
+#
+# I2O device support
+#
+
+#
+# Macintosh device drivers
+#
+# CONFIG_WINDFARM is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# PHY device support
+#
+# CONFIG_PHYLIB is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+# CONFIG_FEC_8XX is not set
+CONFIG_FS_ENET=y
+# CONFIG_FS_ENET_HAS_SCC is not set
+CONFIG_FS_ENET_HAS_FEC=y
+
+#
+# Ethernet (1000 Mbit)
+#
+
+#
+# Ethernet (10000 Mbit)
+#
+
+#
+# Token Ring devices
+#
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+CONFIG_PPP=y
+# CONFIG_PPP_MULTILINK is not set
+# CONFIG_PPP_FILTER is not set
+CONFIG_PPP_ASYNC=y
+CONFIG_PPP_SYNC_TTY=y
+CONFIG_PPP_DEFLATE=y
+# CONFIG_PPP_BSDCOMP is not set
+# CONFIG_PPP_MPPE is not set
+# CONFIG_PPPOE is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# 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_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=y
+CONFIG_UNIX98_PTYS=y
+# CONFIG_LEGACY_PTYS is not set
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+
+#
+# Watchdog Cards
+#
+# CONFIG_WATCHDOG is not set
+CONFIG_HW_RANDOM=y
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+
+#
+# Dallas's 1-wire bus
+#
+
+#
+# Hardware Monitoring support
+#
+CONFIG_HWMON=y
+# CONFIG_HWMON_VID is not set
+# CONFIG_SENSORS_ABITUGURU is not set
+# CONFIG_SENSORS_F71805F is not set
+# CONFIG_HWMON_DEBUG_CHIP is not set
+
+#
+# Misc devices
+#
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+CONFIG_VIDEO_V4L2=y
+
+#
+# Digital Video Broadcasting Devices
+#
+# CONFIG_DVB is not set
+
+#
+# Graphics support
+#
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+# CONFIG_USB_ARCH_HAS_HCD is not set
+# CONFIG_USB_ARCH_HAS_OHCI is not set
+# CONFIG_USB_ARCH_HAS_EHCI is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+
+#
+# MMC/SD Card support
+#
+# CONFIG_MMC is not set
+
+#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
+# InfiniBand support
+#
+
+#
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
+#
+
+#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=m
+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=m
+CONFIG_EXT3_FS_XATTR=y
+# CONFIG_EXT3_FS_POSIX_ACL is not set
+# CONFIG_EXT3_FS_SECURITY is not set
+CONFIG_JBD=m
+# CONFIG_JBD_DEBUG is not set
+CONFIG_FS_MBCACHE=m
+# 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_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+# CONFIG_DNOTIFY 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_SYSFS=y
+# CONFIG_TMPFS is not set
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# 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_CRAMFS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+# CONFIG_NFS_V3 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_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# 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
+# CONFIG_9P_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
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# MPC8xx CPM Options
+#
+# CONFIG_SCC_ENET is not set
+# CONFIG_FEC_ENET is not set
+
+#
+# Generic MPC8xx Options
+#
+CONFIG_8xx_COPYBACK=y
+CONFIG_8xx_CPU6=y
+CONFIG_NO_UCODE_PATCH=y
+# CONFIG_USB_SOF_UCODE_PATCH is not set
+# CONFIG_I2C_SPI_UCODE_PATCH is not set
+# CONFIG_I2C_SPI_SMC1_UCODE_PATCH is not set
+
+#
+# Library routines
+#
+CONFIG_CRC_CCITT=y
+# CONFIG_CRC16 is not set
+# CONFIG_CRC32 is not set
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
+CONFIG_PLIST=y
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_KERNEL is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_DEBUG_FS is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+# CONFIG_CRYPTO is not set
+
+#
+# Hardware crypto devices
+#
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_EV64360) += ev64360.o
obj-$(CONFIG_MPC86XADS) += mpc866ads_setup.o
obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
obj-$(CONFIG_ADS8272) += mpc8272ads_setup.o
+obj-$(CONFIG_ADDER87X) += adder87x_setup.o
diff --git a/arch/ppc/platforms/adder87x.h b/arch/ppc/platforms/adder87x.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/adder87x.h
@@ -0,0 +1,32 @@
+/*
+ * Support for Analogue & Micro Adder87x
+ * mostly a cloned config of mpc885ads.h
+ *
+ * Bryan O'Donoghue, CodeHermit Software Engineering
+ * bodonoghue@codehermit.ie
+ *
+ * 2006 (c) CodeHermit Software Engineering.
+ * Released under the GNU General Public License version 2.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ADDER87X_H__
+#define __ADDER87X_H__
+
+#include <asm/ppcboot.h>
+
+#define BOARD_CHIP_NAME "MPC885"
+#define IMAP_ADDR ((uint)0xff000000)
+#define IMAP_SIZE ((uint)(64 * 1024))
+
+/* Interrupt level assignments */
+#define PHY_INTERRUPT SIU_IRQ7 /* PHY link change interrupt */
+#define SIU_INT_FEC1 SIU_LEVEL1 /* FEC1 interrupt */
+#define SIU_INT_FEC2 SIU_LEVEL3 /* FEC2 interrupt */
+#define FEC_INTERRUPT SIU_INT_FEC1 /* FEC interrupt */
+
+/* We don't use the 8259 */
+#define NR_8259_INTS 0
+
+#endif /* __ADDER87X_H__ */
+#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/adder87x_setup.c b/arch/ppc/platforms/adder87x_setup.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/adder87x_setup.c
@@ -0,0 +1,276 @@
+/*
+ * Support for Analogue & Micro Adder87x
+ *
+ * Bryan O'Donoghue, CodeHermit Software Engineering
+ * bodonoghue@codehermit.ie
+ *
+ * Cloned/stripped down from mpc885ads_setup.c
+ *
+ * 2006 (c) CodeHermit Software Engineering.
+ * Released under the GNU General Public License version 2.
+ */
+
+#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/fs_enet_pd.h>
+#include <linux/fs_uart_pd.h>
+#include <linux/mii.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/ppcboot.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+#include <asm/ppc_sys.h>
+
+/* TODO: Get LEDs on PB29 & PB30 working with LEDs subsystem */
+
+extern unsigned char __res[];
+static void setup_smc1_ioports(void);
+
+static struct fs_uart_platform_info mpc875_uart_pdata[] = {
+ [fsid_smc1_uart] = {
+ .brg = 1,
+ .fs_no = fsid_smc1_uart,
+ .init_ioports = setup_smc1_ioports,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+};
+
+static struct fs_mii_bus_info fec_mii_bus_info = {
+ .method = fsmii_fec,
+ .id = 0,
+};
+
+static struct fs_platform_info mpc8xx_fec_pdata[] = {
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 0,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ },
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 1,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ }
+};
+
+void __init board_init(void)
+{
+ volatile cpm8xx_t *cp = cpmp;
+
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
+ cp->cp_smc[0].smc_smcm |= (SMCM_RX | SMCM_TX);
+ cp->cp_smc[0].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
+#else
+ cp->cp_smc[0].smc_smcmr = 0;
+ cp->cp_smc[0].smc_smce = 0;
+#endif
+
+}
+
+static void setup_fec1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC1 pins */
+ setbits16(&immap->im_ioport.iop_papar, 0xf830);
+ setbits16(&immap->im_ioport.iop_padir, 0x0830);
+ clrbits16(&immap->im_ioport.iop_padir, 0xf000);
+ setbits32(&immap->im_cpm.cp_pbpar, 0x00001001);
+
+ clrbits32(&immap->im_cpm.cp_pbdir, 0x00001001);
+ setbits16(&immap->im_ioport.iop_pcpar, 0x000c);
+ clrbits16(&immap->im_ioport.iop_pcdir, 0x000c);
+ setbits32(&immap->im_cpm.cp_pepar, 0x00000003);
+
+ setbits32(&immap->im_cpm.cp_pedir, 0x00000003);
+ clrbits32(&immap->im_cpm.cp_peso, 0x00000003);
+ clrbits32(&immap->im_cpm.cp_cptr, 0x00000100);
+}
+
+static void setup_fec2_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC2 pins */
+ setbits32(&immap->im_cpm.cp_pepar, 0x0003fffc);
+ setbits32(&immap->im_cpm.cp_pedir, 0x0003fffc);
+ setbits32(&immap->im_cpm.cp_peso, 0x00037800);
+ clrbits32(&immap->im_cpm.cp_peso, 0x000087fc);
+ clrbits32(&immap->im_cpm.cp_cptr, 0x00000080);
+}
+
+static void adder87x_fixup_enet_pdata(struct platform_device *pdev, int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+ break;
+ case fsid_fec2:
+ fpi = &mpc8xx_fec_pdata[1];
+ fpi->init_ioports = &setup_fec2_ioports;
+ break;
+ default:
+ printk(KERN_WARNING"Device %s is not supported!\n", pdev->name);
+ return;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void adder87x_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (!pdev || !pdev->name || (!strstr(pdev->name, "fsl-cpm-fec"))){
+ return;
+ }
+ adder87x_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void setup_smc1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned int iobits = 0x000000c0;
+
+ setbits32(&immap->im_cpm.cp_pbpar, iobits);
+ clrbits32(&immap->im_cpm.cp_pbdir, iobits);
+ clrbits16(&immap->im_cpm.cp_pbodr, iobits);
+}
+
+
+static void __init adder87x_fixup_uart_pdata(struct platform_device *pdev,
+ int idx)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+ int num = ARRAY_SIZE(mpc875_uart_pdata);
+
+ int id = fs_uart_id_smc2fsid(idx);
+
+ /* no need to alter anything if console */
+ if ((id <= num) && (!pdev->dev.platform_data)) {
+ pinfo = &mpc875_uart_pdata[id];
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ }
+}
+
+static int adder87x_platform_notify(struct device *dev)
+{
+
+ static const struct platform_notify_dev_map dev_map[] = {
+ {
+ .bus_id = "fsl-cpm-fec",
+ .rtn = adder87x_fixup_fec_enet_pdata,
+ },
+ {
+ .bus_id = "fsl-cpm-smc:uart",
+ .rtn = adder87x_fixup_uart_pdata
+ },
+ {
+ .bus_id = NULL
+ }
+ };
+
+ platform_notify_map(dev_map,dev);
+
+ return 0;
+}
+
+int __init adder87x_init(void)
+{
+ printk(KERN_NOTICE "adder87x: Init\n");
+
+ platform_notify = adder87x_platform_notify;
+
+ ppc_sys_device_initfunc();
+ ppc_sys_device_disable_all();
+
+ ppc_sys_device_enable(MPC8xx_CPM_FEC1);
+ ppc_sys_device_enable(MPC8xx_CPM_FEC2);
+
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ ppc_sys_device_enable(MPC8xx_CPM_SMC1);
+ ppc_sys_device_setfunc(MPC8xx_CPM_SMC1, PPC_SYS_FUNC_UART);
+#endif
+
+ return 0;
+}
+
+arch_initcall(adder87x_init);
+
+/*
+ To prevent confusion, console selection is gross:
+ by 0 assumed SMC1 and by 1 assumed SMC2
+ */
+struct platform_device* early_uart_get_pdev(int index)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+
+ struct platform_device* pdev = NULL;
+ if(index) { /*assume SMC2 here*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC2];
+ pinfo = &mpc875_uart_pdata[1];
+ } else { /*over SMC1*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC1];
+ pinfo = &mpc875_uart_pdata[0];
+ }
+
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ return NULL;
+}
+
+
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -67,6 +67,10 @@
#include <platforms/mpc885ads.h>
#endif
+#if defined(CONFIG_ADDER87X)
+#include <platforms/adder87x.h>
+#endif
+
/* Currently, all 8xx boards that support a processor to PCI/ISA bridge
* use the same memory map.
*/
^ permalink raw reply
* [RFC v2] HOWTO use NAPI to reduce TX interrupts
From: Arnd Bergmann @ 2006-08-20 17:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller
In-Reply-To: <200608191325.19557.arnd@arndb.de>
A recent discussion about the spidernet driver resulted in the dicovery
that network drivers are supposed to use NAPI for both their receive and
transmit paths, but this is documented nowhere.
In order to help the next person writing a NAPI based driver, I wrote
down what I found missing about this.
Please tell me if anything in here is still wrong or could use better
wording.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This is the second version of my mini howto, after a few comments
I got from Stephen Hemminger and Avuton Olrich.
Index: linux-cg/Documentation/networking/NAPI_HOWTO.txt
===================================================================
--- linux-cg.orig/Documentation/networking/NAPI_HOWTO.txt 2006-08-20 16:51:12.000000000 +0200
+++ linux-cg/Documentation/networking/NAPI_HOWTO.txt 2006-08-20 19:42:20.000000000 +0200
@@ -1,11 +1,6 @@
-HISTORY:
-February 16/2002 -- revision 0.2.1:
-COR typo corrected
-February 10/2002 -- revision 0.2:
-some spell checking ;->
-January 12/2002 -- revision 0.1
-This is still work in progress so may change.
-To keep up to date please watch this space.
+Note: this document could use a serious cleanup by a good writer.
+It would be nice to split out the reference parts into a kerneldoc
+document and turn the rest into a tutorial.
Introduction to NAPI
====================
@@ -738,6 +733,64 @@
root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0)
root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated
+
+APPENDIX 4: Using NAPI for TX skb cleanup
+=========================================
+
+While most of the discussion is focused on optimizing the receive path, in
+most drivers it is also beneficial to free TX buffers from the dev->poll()
+function. Many devices trigger an interrupt for each packet that has been
+sent out to notify the driver that it can free the skb. This results in
+a large amount of interrupt processing that we want to avoid. It is also
+suboptimal to free skbs in a hardirq context, because dev_kfree_skb_irq()
+needs to schedule a softirq to do the actual work. Calling dev_kfree_skb()
+from dev->poll() directly avoids these extra softirq schedules.
+
+The simplistic approach of setting a long kernel timer to clean up
+descriptors results in poor throughput because a user process that tries
+to send out a lot of data then blocks on its socket send buffer, while
+the driver never frees up the skbs in that buffer until the timeout.
+
+Trying the cleanup every time that hard_start_xmit() is entered provides
+relatively good throughput, but typically causes extra processing overhead
+because of mmio accesses and/or spinlocks, so you normally want to batch
+skb reclaim.
+
+In order to get optimal throughput on transmit, the sent skbs need to be
+cleaned up before the chip runs out of data to transmit, so relying on
+an end of queue interrupt means that in the window between the interrupt
+and the time that new user packets have arrived in the adapter, there is
+no outgoing data on the wire, even if user data is available. It may
+also be bad to defer freeing skbs too long because they may consume a
+significant amount of memory.
+
+Experience shows that combination of events that trigger skb reclaim
+works best. These events include:
+- new packets coming in through hard_start_xmit()
+- packets coming in from the network through dev->poll()
+- time has passed since the first packet was send over the wire
+ but has not been reclaimed (tx_coalesce_usecs)
+- a number of packets have been sent (tx_max_coalesced_frames)
+
+We can avoid expensive locking between these by using the poll() function
+as the only place to call skb reclaim. This also means that in the
+interrupt handler, we always call netif_rx_schedule() for any interrupt,
+including those for tx or e.g. PHY handling. This is particularly
+helpful if reading the IRQ status does an auto mask operation.
+
+Depending on the actual hardware, slightly different methods for coalesced
+tx interrupts may be used:
+- a timer that starts with the successful transmission of a packet
+ may need to be replaced with a timer that is started at when a packet
+ is submitted to the adapter.
+- instead of an interrupt that is triggered after a fixed number
+ of transmitted packets, it may be possible to mark a specific packet
+ so it generates an interrupt after processing.
+- If the adapter knows about the number of packets that have been
+ queued, a low-watermark interrupt may be used that fires when the
+ number drops below a user-defined value.
+
+
--------------------------------------------------------------------
relevant sites:
@@ -764,3 +817,4 @@
Manfred Spraul <manfred@colorfullife.com>
Donald Becker <becker@scyld.com>
Jeff Garzik <jgarzik@pobox.com>
+Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-20 17:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17631.62819.24167.555967@cargo.ozlabs.ibm.com>
On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > This kernel patch implements no-execute protection (like x86 "NX bit")
> > for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> > PowerPC processors in the 6xx, 7xx, and 7xxx families.
>
> I'd be interested in benchmark comparisons with/without this patch, if
> anyone cares to run lmbench, kernbench etc. with and without... If
> the performance impact is minimal I'll be happy to apply it. If the
> impact is noticeable then it might need to be selectable with a config
> option.
With no special effort at optimization, the patch appears to be harmless.
Actually most things are a tad faster, which is entirely illogical.
I must have gotten lucky with the cache.
Note that lmbench sucks. It won't compile out of the box. The Debian
package is unavailable for PowerPC, and anyway places files in all
sorts of unusual and annoying root-only locations. One of the tests
gets SIGSEGV while trying to do Sun RPC. The nice summary report
contains no data. I did find the raw results after digging around in
various directories though.
Before:
Simple syscall: 0.3180 microseconds
Simple read: 1.1413 microseconds
Simple write: 1.0040 microseconds
Simple stat: 5.5255 microseconds
Simple fstat: 1.6198 microseconds
Simple open/close: 8.3318 microseconds
Select on 10 fd's: 2.3284 microseconds
Select on 100 fd's: 18.2500 microseconds
Select on 250 fd's: 45.2063 microseconds
Select on 500 fd's: 89.6290 microseconds
Select on 10 tcp fd's: 2.6409 microseconds
Select on 100 tcp fd's: 31.1889 microseconds
Select on 250 tcp fd's: 79.1831 microseconds
Select on 500 tcp fd's: 160.2571 microseconds
Signal handler installation: 1.5846 microseconds
Signal handler overhead: 7.8899 microseconds
Protection fault: 0.7714 microseconds
Pipe latency: 24.4466 microseconds
AF_UNIX sock stream latency: 34.4834 microseconds
Process fork+exit: 671.3750 microseconds
Process fork+execve: 2417.0000 microseconds
Process fork+/bin/sh -c: 10904.0000 microseconds
File /tmp/XXX write bandwidth: 25636 KB/sec
Pagefaults on /tmp/XXX: 3.9404 microseconds
After:
Simple syscall: 0.3179 microseconds
Simple read: 1.1355 microseconds
Simple write: 0.9964 microseconds
Simple stat: 5.5497 microseconds
Simple fstat: 1.6473 microseconds
Simple open/close: 8.0965 microseconds
Select on 10 fd's: 2.3278 microseconds
Select on 100 fd's: 18.0789 microseconds
Select on 250 fd's: 44.1440 microseconds
Select on 500 fd's: 88.1935 microseconds
Select on 10 tcp fd's: 2.6399 microseconds
Select on 100 tcp fd's: 30.8939 microseconds
Select on 250 tcp fd's: 77.5070 microseconds
Select on 500 tcp fd's: 156.3438 microseconds
Signal handler installation: 1.5741 microseconds
Signal handler overhead: 7.8997 microseconds
Protection fault: 0.8085 microseconds
Pipe latency: 24.2050 microseconds
AF_UNIX sock stream latency: 33.7037 microseconds
Process fork+exit: 656.6250 microseconds
Process fork+execve: 2392.3333 microseconds
Process fork+/bin/sh -c: 10454.0000 microseconds
File /tmp/XXX write bandwidth: 25911 KB/sec
Pagefaults on /tmp/XXX: 3.6414 microseconds
Right now I have the code doing printk() rather than killing processes
that misbehave, and I'm doing something about the heap too. It seems
that GNOME things like to execute the heap, while non-GNOME things
do not. Perhaps libORBit is at fault. Things that execute the heap
include:
abiword
firefox-bin
gedit
gimp
gnome-panel
gnome-settings-
gnome-vfs-daemo
metacity
x-session-manag
Apps that behave well include xterm, xcalc, and xli.
I haven't found anything unusual in the ELF section flags. Both libORBit
and libX11 (which is fine) have flags like this:
[ 7] .rela.plt RELA 000138e4 0138e4 001824 12 A 2 23 4
[22] .sbss NOBITS 000f2f34 0e2f34 000140 0 WA 0 0 4
[23] .plt NOBITS 000f3074 0e2f34 00186c 0 WAX 0 0 4
[24] .bss NOBITS 000f48e0 0e2f34 000328 0 WA 0 0 4
Firefox is less than a month old. It's newer than xterm.
^ permalink raw reply
* boot problems on pseries
From: dtutty @ 2006-08-20 17:00 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm switching from an IBM 486 and purchasing an IBM H50 (7026-H50), so
I'm new to the PPC. My vendor wants to ensure that it boots linux
before he ships it. I burned and sent him a few different distro CDs to
try and none boot. We can get yaboot to boot then get stuck at the
yaboot command line and can't get futher. As a fall-back, I was hoping
to use OF to boot the kernel directly and get a kernel-panic when it
can't find init but we can't get that far either. The error message
'claim failed' is returned immediatly with no indication that the kernel
tried to start.
I'm told by several people that the H50 is the same as the F50 in a
different format and that the F50 is known to work. Since the task at
hand is to get any linux to boot and not to actually install linux, I
need a kernel that will boot. Even a simple boot-floppy set would be
great.
Does anyone have a link to a boot/root floppy set that will work?
Hardware details: IBM 7026-H50, 256 MB ram, dual PPC 604e 332 MHz, 9.1
GB HD in Bay 2, standard CD-ROM, PowerGXT130P graphics accelerator.
Thanks,
Doug.
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Arnd Bergmann @ 2006-08-20 10:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <1156055509.5803.77.camel@localhost.localdomain>
On Sunday 20 August 2006 08:31, Benjamin Herrenschmidt wrote:
> > card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> > mb();
> > card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> > card->low_watermark = card->low_watermark->next;
> >
> > when we queue another frame for TX.
>
> I would have expected those to be racy vs. the hardware... what if the
> hardware is updating dmac_cmd_status just as your are trying to and the
> bit out of it ?
Right, that doesn't work. It is the only bit we use in that byte though,
so maybe it can be done with a single byte write.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Benjamin Herrenschmidt @ 2006-08-20 6:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <200608190109.15129.arnd@arndb.de>
> card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> mb();
> card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> card->low_watermark = card->low_watermark->next;
>
> when we queue another frame for TX.
I would have expected those to be racy vs. the hardware... what if the
hardware is updating dmac_cmd_status just as your are trying to and the
bit out of it ?
Ben
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-20 1:31 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <44E6D634.3000207@s5r6.in-berlin.de>
Hi Stefan
Thanks a lot for your very detailed explanations of the 1394
et al. drivers. It helps me a lot ...
On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:
[ ... ]
>
> If you have got the TiBook around, you could connect it with the AlBook
> and look what gscanbus or OS X's system profiler have to say about it.
> If possible, also try the TiBook in target disk mode and see if it
> appears as a disk for Linux' sbp2 or under OS X.
I tested this, not on OSX, but Linux:
Target disk mode works excellent on the new Powerbook5,8 (alubook): I
booted the old TitaniumIV (tibook) -- connected via the FW cable to
the alubook -- in target disk mode. Very quickly after the tibook
started I was asked by KDE on the alubook what to do with the newly
detected disks. And some news icons appeared on the KDE desktop, 2 of
them correctly representing the 2 main partitions on the tibook.
Here's /var/log/kern.log on the alubook, at about the time when I
started the tibook in target disk mode
------------------------------------
Aug 20 02:04:18 debby1-6 kernel: [ 8644.941230] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 02:04:18 debby1-6 kernel: [ 8644.941295] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484415] ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484580] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Aug 20 02:05:53 debby1-6 kernel: [ 8740.212617] PM: Removing info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315023] PM: Adding info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315180] scsi1 : SBP-2 IEEE-1394
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315199] PM: Adding info for No Bus:host1
Aug 20 02:06:01 debby1-6 kernel: [ 8747.416987] ieee1394: sbp2: Logged into SBP-2 device
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417194] ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417232] PM: Adding info for No Bus:target1:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417738] Vendor: AAPL Model: FireWire Target Rev: 0000
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417767] Type: Direct-Access-RBC ANSI SCSI revision: 03
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417791] PM: Adding info for scsi:1:0:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.485838] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486345] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486354] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486774] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486781] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487400] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487721] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487728] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488150] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488156] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488437] sda: [mac] sda1 sda2 sda3 sda4 sda5
Aug 20 02:06:01 debby1-6 kernel: [ 8747.492435] sd 1:0:0:0: Attached scsi disk sda
--------------------------------------
So at least it looks now as if the Firewire 400 Hardware on the
alubook is not broken. Correct? Would be a great relief as I hate it
to have it away at the repair service.
I could mount the 2 tibook partitions easily on the alubook.
On the alubook:
-----------------------------------------
# mount
/dev/hda7 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda6 on /home type ext3 (rw)
/dev/hda5 on /var type ext3 (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
nfsd on /proc/fs/nfsd type nfsd (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda4 on /media/usbdisk type ext3 (rw,noexec,nosuid,nodev)
/dev/sda5 on /media/usbdisk-1 type ext3 (rw,noexec,nosuid,nodev)
--------------------------------
sd4/sda5 must be the 2 main partitions on the tibook ..
I mounted them, and a few seconds after unmounting them this must have
been the corresponding kern.log:
-------------------------------------------
Aug 20 03:05:20 debby1-6 kernel: [12306.976988] ieee1394: sbp2: Error logging into SBP-2 device - login timed-out
Aug 20 03:05:20 debby1-6 kernel: [12306.977004] ieee1394: sbp2: Failed to reconnect to sbp2 device!
Aug 20 03:05:20 debby1-6 kernel: [12306.977410] PM: Removing info for scsi:1:0:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977482] PM: Removing info for No Bus:target1:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977558] PM: Removing info for No Bus:host1
Aug 20 03:05:20 debby1-6 kernel: [12307.233256] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 03:05:20 debby1-6 kernel: [12307.233324] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
--------------------------------------------
OTOH: Connecting the alubook and tibook with Linux up and running on
both machines did not create a working (FW) connection between them ..
I'll try the latter later again -- even perhaps with OSX on the
alubook and Linux on the tibook ...
>
> The fact that Linux on the AlBook gets at least as far as "ieee1394:
> Error parsing configrom for node 0-00:1023" indicates that not all hope
> is lost. If you have got the time, compile the 1394 drivers for verbose
> logging and send the log. Don't crosspost the log if it gets too big.
I'll compile a fresh git kernel next week, Tuesday or Wednesday, with
verbose logging for the 1394 drivers. And I'll put the corresponding
logs for the 1394 tests on my homepage instead of sending them via
email anywhere, only the URL's for the logs will be sent in my
messages. Please let me know if you disagree ...
BTW: Do you know how to switch off verbose logging for the 1394
drivers once they're compiled into the kernel, via some
echo "<some-value>" to /sys/*/* ?
I didn't find any entry there until now for that purpose ...
Until then, and thanks a lot for your time.
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Bill Fink @ 2006-08-20 0:18 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, linuxppc-dev
In-Reply-To: <44E6DAB9.50304@s5r6.in-berlin.de>
On Sat, 19 Aug 2006, Stefan Richter wrote:
> Bill Fink wrote:
> ...
> > on my desktop PowerMac systems, I need a "sleep 2"
> > before the modprobe for sbp2, to get my Firewire disks to work
> > properly.
>
> What happens if you don't put the pause in there? What disks do you have
> and what bridge chips are built in? (Please apologize if you reported
> this before and we didn't come to a solution then.)
First of all this was on a somewhat older 2.6.11.8 kernel without
any hotplug (I'll probably be trying this again soon with a newer
2.6.15-rc5 kernel). And I was actually booting off this Firewire
disk. Without the pause I would get:
Loading sb2.ko module
sb2: $rev 1219 ...
Creating block devices
Creating root device
Mkrootdev: label fw1-root not found
Then it wouldn't be able to mount the root filesystem, which would
be followed shortly by a kernel panic.
If I put the "sleep 2" before the "modprobe sbp2" then everything
works. There's a message about initializing SCSI emulation for SBP-2,
followed by the discovery of the Firewire disk and the creation of
the sda device, which then allows the successful mounting of the
root filesystem.
Here's the full linuxrc nash script from the initrd for the working case:
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading ieee1394.ko module"
insmod /lib/ieee1394.ko
echo "Loading ohci1394.ko module"
insmod /lib/ohci1394.ko
sleep 2
echo "Loading raw1394.ko module"
insmod /lib/raw1394.ko
echo "Loading sbp2.ko module"
insmod /lib/sbp2.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc
The disk is an 80 GB LaCie Firewire disk, reported by the kernel as:
Aug 19 19:48:01 gwiz kernel: ieee1394: sbp2: Logged into SBP-2 device
Aug 19 19:48:01 gwiz kernel: Vendor: ST380021 Model: A Rev: 3.05
Aug 19 19:48:01 gwiz kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel: sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi disk sda
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi generic sg0 type 14
The above messages are actually from booting (non-Firewire) the
newer 2.6.15-rc5 kernel.
-Bill
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 23:32 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus, segher
In-Reply-To: <200608192219.03178.arnd@arndb.de>
>> > Is that the right check? The other similar traps check against a
>> mask of 0x7c0007fe.
>>
>> I hope you mean 0xfc0007fe?
>>
>
> No, the code in question is
>
> #define INST_MFSPR_PVR········0x7c1f42a6
> #define INST_MFSPR_PVR_MASK····0xfc1fffff
>
> #define INST_DCBA·············0x7c0005ec
> #define INST_DCBA_MASK········0x7c0007fe
>
> #define INST_MCRXR············0x7c000400
> #define INST_MCRXR_MASK·······0x7c0007fe
>
> #define INST_STRING···········0x7c00042a
> #define INST_STRING_MASK·······0x7c0007fe
> #define INST_STRING_GEN_MASK···0x7c00067e
> #define INST_LSWI·············0x7c0004aa
> #define INST_LSWX·············0x7c00042a
> #define INST_STSWI············0x7c0005aa
> #define INST_STSWX············0x7c00052a
>
> What does the MSB do in our instructions?
Bits 0..5 are the primary opcode, for all insns;
bits 21..30 are the secondary opcode, for insns that
have one (all in primary opcode 31 do).
So we have a bug here; could you take care of it please
Arnd?
Segher
^ permalink raw reply
* Re: HDLC drivers on 8260
From: Mich Lanners @ 2006-08-19 20:10 UTC (permalink / raw)
To: alexfestss; +Cc: linuxppc-dev
In-Reply-To: <BAY106-F227AE7DF98822643447FA7DB430@phx.gbl>
Hi,
On 19 Aug, this message from Alejandro C echoed through cyberspace:
> I've just started developing a driver to use the four SCCs (CPM of the
> Motorola
> MPC8260) in the HDLC mode. I've found references to a HDLC driver
> somewhere on the internet, but I haven't been able to locate the
> source code. Does anyone know where to find this or something else I
> can use as an example/starting point?
I don't know a thing about the SCCs in the MPC8260, but you may want to
have a look at the Cyclades PC300 driver in the kernel. It does HDLC
(but I don't remember whether it's the PC300 driver or a generic HDLC
driver in the kernel). What HDLC do you wnat to implement? There is no
generic HDLC per se, but different framings using a HDLC-like framing.
Examples would be Cisco's IP over HDLC, or PPP.
For Cisco's HDLC, I added IP address autoconfiguration to the PC300
(submitted to the maintainer, but never found it's way into the official
kernels).
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Arnd Bergmann @ 2006-08-19 20:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, segher
In-Reply-To: <50883.84.105.60.119.1156014614.squirrel@gate.crashing.org>
T24gU2F0dXJkYXkgMTkgQXVndXN0IDIwMDYgMjE6MTAsIHNlZ2hlckBnYXRlLmNyYXNoaW5nLm9y
ZyB3cm90ZToKPiA+IElzIHRoYXQgdGhlIHJpZ2h0IGNoZWNrPyBUaGUgb3RoZXIgc2ltaWxhciB0
cmFwcyBjaGVjayBhZ2FpbnN0IGEKPiA+IG1hc2sgb2YgMHg3YzAwMDdmZS4KPiAKPiBJIGhvcGUg
eW91IG1lYW4gMHhmYzAwMDdmZT8KPiAKCk5vLCB0aGUgY29kZSBpbiBxdWVzdGlvbiBpcyAKCiNk
ZWZpbmUgSU5TVF9NRlNQUl9QVlKtt623t7e3t7e3MHg3YzFmNDJhNgojZGVmaW5lIElOU1RfTUZT
UFJfUFZSX01BU0utt7e3tzB4ZmMxZmZmZmYKCiNkZWZpbmUgSU5TVF9EQ0JBrbe3t7e3t623t7e3
t7e3MHg3YzAwMDVlYwojZGVmaW5lIElOU1RfRENCQV9NQVNLrbett7e3t7e3tzB4N2MwMDA3ZmUK
CiNkZWZpbmUgSU5TVF9NQ1JYUq23t7e3t623t7e3t7e3MHg3YzAwMDQwMAojZGVmaW5lIElOU1Rf
TUNSWFJfTUFTS62tt7e3t7e3tzB4N2MwMDA3ZmUKCiNkZWZpbmUgSU5TVF9TVFJJTkett7e3t623
t7e3t7e3MHg3YzAwMDQyYQojZGVmaW5lIElOU1RfU1RSSU5HX01BU0utt7e3t7e3tzB4N2MwMDA3
ZmUKI2RlZmluZSBJTlNUX1NUUklOR19HRU5fTUFTS623t7cweDdjMDAwNjdlCiNkZWZpbmUgSU5T
VF9MU1dJrbe3t7e3t623t7e3t7e3MHg3YzAwMDRhYQojZGVmaW5lIElOU1RfTFNXWK23t7e3t7et
t7e3t7e3tzB4N2MwMDA0MmEKI2RlZmluZSBJTlNUX1NUU1dJrbe3t7e3rbe3t7e3t7cweDdjMDAw
NWFhCiNkZWZpbmUgSU5TVF9TVFNXWK23t7e3t623t7e3t7e3MHg3YzAwMDUyYQoKV2hhdCBkb2Vz
IHRoZSBNU0IgZG8gaW4gb3VyIGluc3RydWN0aW9ucz8KCglBcm5kIDw+PAo=
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 19:10 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <200608182105.45264.arnd@arndb.de>
>> +#define INST_POPCNTB 0x7c0000f4
>> +
>
>> + /* Emulate the popcntb (Population Count Bytes) instruction.
>> */ + if ((instword & INST_POPCNTB) == INST_POPCNTB) {
>> + return emulate_popcntb_inst(regs, instword);
>> + }
>> +
>
> Is that the right check? The other similar traps check against a
> mask of 0x7c0007fe.
I hope you mean 0xfc0007fe?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 19:09 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, paulus
In-Reply-To: <FE1A4DBD-9AAB-434A-B487-06B68AC61CC0@kernel.crashing.org>
>> +static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
>> +{
>> + u32 ra,rs;
>> + unsigned long tmp;
>> +
>> + ra = (instword >> 16) & 0x1f;
>> + rs = (instword >> 21) & 0x1f;
>> +
>> + tmp = regs->gpr[rs];
>> + tmp = tmp - ((tmp >> 1) & 0x5555555555555555);
>> + tmp = (tmp & 0x3333333333333333) + ((tmp >> 2) &
>> 0x3333333333333333);
>> + tmp = (tmp + (tmp >> 4)) & 0x0f0f0f0f0f0f0f0f;
>> + regs->gpr[ra] = tmp;
>> +
>> + return 0;
>> +}
>
> This is going to give warnings on ppc32 kernel compiles, maybe
> something like:
>
> (unsigned long) 0x5555555555555555ull
Nah, just make "tmp" an u64. And/or don't do this emulation on
32-bit machines at all.
And if the compiler warns about the non-qualified constants --
well, we should compile with -std=gnu99 anyway, eh?
Segher
^ permalink raw reply
* Re: [PATCH] Add 85xx DTS files to powerpc
From: Sergei Shtylyov @ 2006-08-19 18:27 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.61.0608181803160.2878@ld0175-tx32.am.freescale.net>
Hello.
Andy Fleming wrote:
> Added the mpc85xx family of dts files to the powerpc tree
> ---
> arch/powerpc/boot/dts/mpc8540ads.dts | 257 ++++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8541cds.dts | 244 +++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8548cds.dts | 287 ++++++++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8555cds.dts | 244 +++++++++++++++++++++++++++++
> 4 files changed, 1032 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
> new file mode 100644
> index 0000000..93d2c2d
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8540ads.dts
[...]
> + ethernet-phy@2 {
> + linux,phandle = <2452002>;
> + interrupt-parent = <40000>;
> + interrupts = <37 1>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
Well, there's PHYs #2 and #3 on the board, #2 is probably not tied to
anything though.
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <26000 1000>;
> + address = [ 00 E0 0C 00 73 02 ];
> + local-mac-address = [ 00 E0 0C 00 73 02 ];
> + interrupts = <19 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452002>;
> + };
Shouldn't it be "FEC" instead? The third controller is actually Fast
Ethernet and fsl_soc.c differs TSEC and FEC WRT the interrupts (FEC has only
one). So, this entry looks incorrect...
> + pic@40000 {
> + linux,phandle = <40000>;
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <40000 40000>;
> + built-in;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
Spaces instead of tabs in this line...
> + };
> + };
> +};
WBR, Sergei
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 8:10 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <20060817230347.GC3440@localhost>
Wolfgang Pfeiffer wrote:
> The SCSI/FW routines seem to work like a charm with a LSILogic Model/
> SYM13FW500-Disk on my old Macintosh titanium-IV laptop, with exactly
> the same relatively fresh git-kernel that does not work on the
> PowerBook5,8. That is I compiled the kernel on the Apple Powerbook5,8
> and installed it on both machines.
>
> SCSI/FW didn't work ever on the new PowerBook5,8.
[...]
> #!/bin/sh -x
> /bin/sh -n /home/shorty/scripts/scsi.start.sh && \
>
> modprobe raw1394 && \
> modprobe ieee1394 disable_irm=0 disable_nodemgr=1 && \
> modprobe ohci1394 && \
> modprobe eth1394 && \
> modprobe sbp2 max_speed=3 workarounds=0x1 serialize_io=0 && \
> sleep 4 && \
> chown root.shorty /dev/raw1394
This script doesn't work as you may expect.
"modprobe raw1394" pulls ieee1394 in. Therefore all the parameters you
give to ieee1394 in the next line are ignored. If you want to run
ieee1394 with non-default parameters, load it first before any other
1394 driver or put the parameters into /etc/modprobe.d/xyz or
/etc/modprobe.conf.
"disable_nodemgr=1" will also enforce disable_irm=0 because some of the
IRMs functionality requires the nodemgr kernel daemon.
The nodemgr is also the bridge between the 1394 bus and Linux' driver
core. Some of the IEEE 1394 high-level drivers, including sbp2, don't
find devices on their own but work on top of the driver core's device
representations created by nodemgr. IOW sbp2 won't work with
disable_nodemgr=1.
"modprobe eth1394" is not necessary if you have hotplug scripts.
ieee1394 is, according to your log, configured to always adds an
IP-over-1394 ROM entry to the local node's configuration ROM (it's
actually RAM but works like ROM for other 1394 nodes), and there will be
hotplug events generated for this entry as soon as the local node
(driven by ohci1394) became operational.
(Similarly, sbp2 is usually loaded by hotplug scripts when an SBP-2
device was detected. But if you rely on hotplug, you would have of
course to supply any non-default module parameters to sbp2 via
/etc/modprobe.d/xyz or /etc/modprobe.conf.)
"max_speed=3" i.e. S800 is the default and will stay so for the time
being. It doesn't seem like S1600 hardware (standardized by IEEE 1394b)
or even S3200 hardware (not standardized yet) will ever become available.
"workarounds=1" or 0x1 isn't precisely the default. But there is also
sbp2's parameter max_sectors whose default value of 255 means exactly
the same as the bit 1 in the workarounds bit field. The bit 1 exists in
the workarounds parameter only to fully reflect what can be stuffed into
sbp2's hardcoded blacklist (or "whitelist" depending on the point of view).
"serialize_io=0" has always been --- and still is --- unsafe. I recently
started work to make it safe but am not done yet. serialize_io=0 does
work with many devices though (by fortunate circumstances rather than by
principle) and gains a measurable but hardly noticeable throughput
advantage with some devices, AFAIK especially with S800 devices.
However all my comments to your script do not relate to the problem you
are seeing with
[...]
> Aug 18 00:24:03 debby1-6 kernel: [38907.611119] ieee1394: Initialized config rom entry `ip1394'
> Aug 18 00:24:03 debby1-6 kernel: [38907.628475] ieee1394: raw1394: /dev/raw1394 device initialized
Here you are seeing proof for my comment on "modprobe raw1394": ieee1394
is up earlier than raw1394...
> Aug 18 00:24:03 debby1-6 kernel: [38907.692766] PM: Adding info for ieee1394:fw-host0
> Aug 18 00:24:03 debby1-6 kernel: [38907.764726] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[40] MMIO=[f5000000-f50007ff] Max Packet=[4096] IR/IT contexts=[8/8]
> Aug 18 00:24:03 debby1-6 kernel: [38907.912614] eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
> Aug 18 00:24:04 debby1-6 kernel: [38909.170610] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
> Aug 18 00:24:05 debby1-6 kernel: [38910.425599] ieee1394: Error parsing configrom for node 0-00:1023
...and you are using it with irm and nodemgr enabled.
AFAIK:
Node 0-00:1023 is the enclosure's SYM13FW501 which seems to be a link
layer controller with integrated minimal PHY. (Node IDs are associated
with PHYs, not links.) Node 0-01:1023 is an extra PHY in the enclosure,
the PHY that actually drives the cable port (ports?). This is the
TSB41LV03A on the bridge board. To take up two nodes, i.e. show the
presence of two daisy-chained PHYs to the bus instead of one PHY, is
apparently a property of some or all bridge boards with the old Symbios
SBP-2 controller.
Node 0-02:1023 is of course the fw-host0.
"Error parsing configrom" often means that ieee1394 was unable to read
anything from a devices ROM in the first place. This is often a normal
condition for SBP-2 devices until their attached drive is fully
operational. They then send a bus reset and publish a proper ROM,
ieee1394 reads it, and Linux' driver core attaches the sbp2 driver as
the matching protocol driver to it.
What if you force a bus reset about 5 seconds or more later, using
gscanbus or 1394commander? Would ieee1349 detect the disk's SBP-2
capability?
What if you load ieee1394 with disable_irm=1? (Before raw1394 of
course.) Nodemgr takes care to run the IRM code in a very non-intrusive
manner in newer Linux releases, but there is still the "selecting a new
root node and resetting" routine which can't be avoided by an IRM that
wants to be fully compliant to the specs.
> Aug 18 00:24:05 debby1-6 kernel: [38910.425992] PM: Adding info for ieee1394:001451fffe3148be
> Aug 18 00:24:05 debby1-6 kernel: [38910.426064] ieee1394: Host added: ID:BUS[0-02:1023] GUID[001451fffe3148be]
> Aug 18 00:24:05 debby1-6 kernel: [38910.426209] PM: Adding info for ieee1394:001451fffe3148be-0
These two "Adding info for..." are of course related to the host
adapter. The first one is the fw-host0 itself and the second one the
ip1394 a.k.a. RFC 2734 unit that ieee1394 added to it (and eth1394 was
bound to). 0x001451 is Apple's OUI.
[...]
> And gscanbus says this for:
> "Unknown
> Linux - ohci1394":
>
> --------------------------
> SelfID Info
> -----------
> Physical ID: 2
[...]
> And this for "S400 unknown":
>
> ---------------------------------
> SelfID Info
> -----------
> Physical ID: 1
> Link active: No
This is the TSB41LV03A.
> Gap Count: 63
> PHY Speed: S400
> PHY Delay: <=144ns
> IRM Capable: No
> Power Class: -1W
> Port 0: Connected to parent node
> Port 1: Not connected
> Port 2: Connected to child node
> Init. reset: No
[...]
There should be a third node, i.e. the node with physical ID 0 == the
child node of the TSB41LV03A's node. Doesn't show gscanbus anything
about that node? I expect that you at least see an icon and SelfID info.
CSR ROM info might be missing; although the fact that ieee1394 failed to
read the ROM doesn't mean that gscanbus will be unable to do so.
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Jeff Garzik @ 2006-08-19 14:40 UTC (permalink / raw)
To: Andy Gay
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder,
Alexey Dobriyan
In-Reply-To: <1155970112.7302.434.camel@tahini.andynet.net>
Andy Gay wrote:
> fs/bio.c:169: warning: 'idx' may be used uninitialized in this function
> fs/eventpoll.c:500: warning: 'fd' may be used uninitialized in this function
> fs/isofs/namei.c:162: warning: 'offset' may be used uninitialized in this function
> fs/isofs/namei.c:162: warning: 'block' may be used uninitialized in this function
> fs/nfsd/nfsctl.c:292: warning: 'maxsize' may be used uninitialized in this function
> fs/udf/balloc.c:751: warning: 'goal_eloc.logicalBlockNum' may be used uninitialized in this function
> fs/udf/super.c:1358: warning: 'ino.partitionReferenceNum' may be used uninitialized in this function
> fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_startblock' may be used uninitialized in this function
> fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_blockcount' may be used uninitialized in this function
> fs/xfs/xfs_bmap.c:2498: warning: 'rtx' is used uninitialized in this function
> fs/xfs/xfs_bmap_btree.c:753: warning: 'nkey.br_startoff' may be used uninitialized in this function
> fs/xfs/xfs_da_btree.c:151: warning: 'action' may be used uninitialized in this function
> fs/xfs/xfs_dir.c:363: warning: 'totallen' may be used uninitialized in this function
> fs/xfs/xfs_dir.c:363: warning: 'count' may be used uninitialized in this function
> fs/xfs/xfs_ialloc_btree.c:545: warning: 'nkey.ir_startino' may be used uninitialized in this function
> fs/xfs/xfs_inode.c:1958: warning: 'last_dip' may be used uninitialized in this function
> fs/xfs/xfs_inode.c:1960: warning: 'last_offset' may be used uninitialized in this function
> fs/xfs/xfs_log.c:1749: warning: 'iclog' may be used uninitialized in this function
> fs/xfs/xfs_log_recover.c:523: warning: 'first_blk' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.qbytes' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.mode' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.mode' may be used uninitialized in this function
> drivers/md/dm-table.c:431: warning: 'dev' may be used uninitialized in this function
> drivers/md/dm-ioctl.c:1388: warning: 'param' may be used uninitialized in this function
> net/sched/sch_cbq.c:409: warning: 'ret' may be used uninitialized in this function
> lib/zlib_inflate/inftrees.c:121: warning: 'r.base' may be used uninitialized in this function
These are gcc bugs. We don't patch the kernel for gcc bugs.
Jeff
^ permalink raw reply
* Re: ioremap() twice on same memory mapped area?
From: Dan Malek @ 2006-08-19 14:13 UTC (permalink / raw)
To: Parav Pandit; +Cc: Linuxppc-embedded
In-Reply-To: <20060819065247.10235.qmail@web36608.mail.mud.yahoo.com>
On Aug 19, 2006, at 2:52 AM, Parav Pandit wrote:
> Question is:
> Can both the driver call the ioremap() on the same space and get
> the different virtual address?
Yes, and depending upon the implementation and optimizations,
they may also get the same virtual address. It will work as you
intend.
-- Dan
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Arnd Bergmann @ 2006-08-19 13:47 UTC (permalink / raw)
To: linuxppc-dev, michael
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, Christoph Raisch, Marcus Eder, Andy Gay,
Alexey Dobriyan
In-Reply-To: <1155976887.1388.17.camel@localhost.localdomain>
On Saturday 19 August 2006 10:41, Michael Ellerman wrote:
> A lot of these have started appearing recently, which I think is due to
> GCC becoming more vocal. Unfortunately many of them are false positives
> caused by GCC not seeming to grok that this is ok:
>
> void foo(int *x) { *x = 1; }
> ...
> int x;
> foo(&x);
> return x;
>
It's more subtle than this, gcc only gets it wrong when multiple
things come together, the most common one seems to be:
- it tries to inline foo()
- foo has a path where it initializes *x and another one where it
doesn't
- x is accessed after foo() returns, but only when foo indeed has
initialized it.
The problem is that gcc now is more aggressive about inlining
functions. It used to assume that all functions initialize their
pointer arguments, now it does some more checking, but not enough,
so there are lots of false positives. Every gcc-4.x release seems
to fix some of these cases, but a few others remain.
Arnd <><
^ permalink raw reply
* HDLC drivers on 8260
From: Alejandro C @ 2006-08-19 12:10 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I've just started developing a driver to use the four SCCs (CPM of the
Motorola
MPC8260) in the HDLC mode. I've found references to a HDLC driver somewhere
on the internet, but I haven't been able to locate the source code. Does
anyone know where to find this or something else I can use as an
example/starting point?
Thanx,
Alex
_________________________________________________________________
Un amor, una aventura, compañía para un viaje. Regístrate gratis en MSN Amor
& Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Arnd Bergmann @ 2006-08-19 11:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller
In-Reply-To: <44E7BB7F.7030204@osdl.org>
On Sunday 20 August 2006 03:31, Stephen Hemminger wrote:
>=20
> The reason reclaim via poll() is efficient is because it avoid causing a=
=20
> softirq that is
> necessary when skb_free_irq() is done. Instead it reuses the softirq=20
> from the poll() routine.=20
Ok, I completely missed this point so far, thanks for the info.
> Like all Rx NAPI, using poll() for reclaim means:=20
> =A0 =A0 + aggregating multiple frames in one irq
> =A0 =A0 - increased overhead of twiddling with the IRQ mask
> =A0 =A0 - more ways to get driver stuck
What is the best way to treat the IRQ mask for TX interrupts?
I guess it should be roughly:
=2D off when we expect ->poll() to be called, i.e. after calling
netif_rx_schedule() or returning after a partial rx from poll().
=2D off when there are no packets left in the TX queue
=2D on while RX interrupts are on and we're waiting for packets
to be transmitted.
> Some drivers do all their irq work in the poll() routine (including PHY=20
> handling).
> This is good if reading the IRQ status does an auto mask operation.
>=20
> The whole NAPI documentation area is a mess and needs a good writer
> to do some major restructuring. It should also be split into reference=20
> information,
> tutorial and guide sections.
I won't be able to do that work, I'm neither a good writer nor a networking
person.
Do you think we should still merge a section like the text I wrote up, even
if it makes the text even less well structured? Should I maybe add it
somewhere else than the appendix?
Arnd <><
^ permalink raw reply
* e2fsck error on compact flash.
From: Srinivasa Hebbar @ 2006-08-19 10:30 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: sshebbar
Hello,
Problem:
e2fsck is unable to determine the size of the physical device on a compact flash.
/dev/hda is a compact flash disk with 4 partitions. (3primary+1extended).
ls -l /dev/hda* shows all the devices.
If I mount any partition on /dev/hda* to /tmp/tmp
(for eg: /dev/hda1 to /tmp/tmp) and run e2fsck
on /dev/hda3 (or any other), e2fsck runs fine without problem.
All 4 partitions on the CF disk are ext3.
The output of the commands are below.
Any help is appreciated.
Thanks,
Hebbar.
# e2fsck -v /dev/hda3
e2fsck 1.38 (30-Jun-2005)
Error determining size of the physical device: No such file or directory
# ls -l /dev/hda*
brw-rw---- 1 0 0 3, 5 /dev/hda5
brw-rw---- 1 0 0 3, 4 /dev/hda4
brw-rw---- 1 0 0 3, 3 /dev/hda3
brw-rw---- 1 0 0 3, 2 /dev/hda2
brw-rw---- 1 0 0 3, 1 /dev/hda1
brw-rw---- 1 0 0 3, 0 /dev/hda
#mount -t ext3 /dev/hda1 /tmp/tmp
# e2fsck -v /dev/hda3
e2fsck 1.38 (30-Jun-2005)
/dev/hda3 has been mounted 21 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 9:32 UTC (permalink / raw)
To: Bill Fink; +Cc: linux1394-devel, linuxppc-dev
In-Reply-To: <20060818012824.22e70b0f.billfink@mindspring.com>
Bill Fink wrote:
...
> on my desktop PowerMac systems, I need a "sleep 2"
> before the modprobe for sbp2, to get my Firewire disks to work
> properly.
What happens if you don't put the pause in there? What disks do you have
and what bridge chips are built in? (Please apologize if you reported
this before and we didn't come to a solution then.)
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 9:13 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <20060818234930.GB2662@localhost>
Wolfgang Pfeiffer wrote:
>> The SCSI/FW routines seem to work like a charm with a LSILogic Model/
>> SYM13FW500-Disk on my old Macintosh titanium-IV laptop, with exactly
>> the same relatively fresh git-kernel that does not work on the
>> PowerBook5,8. That is I compiled the kernel on the Apple Powerbook5,8
>> and installed it on both machines.
> [ ... ]
>
> In the meantime I suspect a hardware problem.
>
> Here's why:
>
> I connected the FW disk I was reporting about in previous postings to
> both an older Apple titanium Powerbook and to the newer Apple alubook
> 5,8.
>
> In both instances I rebooted the machines with the accompanying
> different Apple OS X install CD's. Both CD's have a so-called "Disk
> Utility" tool with them, a tool that generally detects and repairs
> disks. The tool clearly detected the FW disk attached to my old
> titanium. And the same tool didn't detect the same FW disk on the
> newer alubook 5,8 ... :)
>
> In both instances I connected the FW disk to the FW 400 connector of
> the machines.
>
> So unless there are differing FW 400 versions available on both
> machines I'd suspect a hardware prob with the 5,8.
>
> [Note: Do there actually exist different Firewire 400 versions?]
Yes, there are, but they should be fully interoperable --- with one
exception that doesn't apply to Powerbooks.
A) There are old IEEE 1394-1995 only compliant PHYs. Such PHYs have not
been used by manufacturers anymore since long ago.
B) There are IEEE 1394a-2000 compliant PHYs. IEEE 1394a added, among
else, enhanced asynchronous arbitration, but AFAIU this is fully
interoperable with 1394-1995 PHYs. The bridge board of your enclosure
has a 1394a-2000 PHY (the TSB41LV03A). The SYM13FW501 appears to be only
a 1394-1995 compliant link layer controller (probably with integrated
PHY) but this shouldn't matter.
C) IEEE 1394b-2002 compliant PHYs with monolingual S400A port(s). They
behave exactly like 1394a-2000 PHYs.
D) IEEE 1394b-2002 compliant PHYs with monolingual S400B port(s). These
are not interoperable with neither of A, B, C. Therefore such ports need
to have a 9-pin socket whose formfactor is coded as a monolingual port.
Therefore it is physically impossible to connect such a port with ports
of type A, B, or C. I don't know if there are actual products with
monolingual S400B ports.
IEEE 1394b-2002 compliant PHYs may have
- bilingual ports,
- Beta-only ports (Beta mode is a new signaling mode introduced by
1394b which is not interoperable with 1394-1995 and 1394a),
- and/or ports that are forced to only use legacy signaling, i.e. the
same as of IEEE 1394a PHYs.
The S800 9-pin port of the AlBook is a bilingual port; the S400 6-pin
port should be a 1394b port which is forced to use only legacy signaling.
BTW, I have a portable CD-RW which I suspect to have a similar or the
same bridge chip as your HDD. This is because it also shows two nodes
instead of one node and because it suffered the same problem related to
the BROADCAST_CHANNEL register as the Datafab HDD. I cannot open the
CD-RW without damaging it therefore I cannot confirm the actual chips in
there. This CD-RW works fine on a bilingual 1394b PCI adapter with 9-pin
to 6-pin cable.
> I'll make this issue clear next week with a trip to the shop where I
> bought the alubook.
>
> And I'll be back as soon as I know more ...
If you have got the TiBook around, you could connect it with the AlBook
and look what gscanbus or OS X's system profiler have to say about it.
If possible, also try the TiBook in target disk mode and see if it
appears as a disk for Linux' sbp2 or under OS X.
The fact that Linux on the AlBook gets at least as far as "ieee1394:
Error parsing configrom for node 0-00:1023" indicates that not all hope
is lost. If you have got the time, compile the 1394 drivers for verbose
logging and send the log. Don't crosspost the log if it gets too big.
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Michael Ellerman @ 2006-08-19 8:41 UTC (permalink / raw)
To: Andy Gay
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder,
Alexey Dobriyan
In-Reply-To: <1155970112.7302.434.camel@tahini.andynet.net>
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
On Sat, 2006-08-19 at 02:48 -0400, Andy Gay wrote:
> On Sat, 2006-08-19 at 16:18 +1000, Michael Ellerman wrote:
>
> >
> > If you try to return an uninitialized value the compiler will warn you,
> > you'll then look at the code and realise you missed a case, you might
> > save yourself a bug.
>
> You *should* look at the code :)
>
> So should we be reporting these as bugs?
No you're better off sending patches ;)
A lot of these have started appearing recently, which I think is due to
GCC becoming more vocal. Unfortunately many of them are false positives
caused by GCC not seeming to grok that this is ok:
void foo(int *x) { *x = 1; }
...
int x;
foo(&x);
return x;
It's a pity because it creates noise, but still it's beside the point.
New code going into the kernel should be 100% warning free, and so if
the eHEA guys had missed an error case they'd spot the warning before
they submitted it.
Doing the initialise-to-some-value "trick" means you only spot the bug
via testing.
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ 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