* problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Arun Kumar @ 2006-07-21 14:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 15658 bytes --]
Hi ,
Can anyone help me in this naive problem ?
I am using k 2.4.x based on ppc8245 based .I have a 8MB flash mapped to
adress -0xff800000 .with 4 interleaved AMD flash devices each of size 2Mib .
Inte
The problem I am facing are two :
I am not sure whether my flash read/write routines are working properly
.(cfi_cmdset_0002.c routines )
I am able to detect my flash and do MTD partions too on the flash .But I
cannot see that in my
dev directory .I mean I should see something like /dev/mtd0 ...etc .
As I want to mount JFFS2 and I am not sure of whether i can mount any
Filesystem without seeing it in /dev directory .
Is there way wherein I can invoke mtd->write/mtd/->
read routines so that I can be sure that my CFI driver is working fine ?
these routines are mapped to amdstd_read/write routines in cfi_cmdset_0002
routine .
mtd->read = cfi_amdstd_read;
mtd->write = cfi_amdstd_write;
Here is my dump
################################################################
LSP Revision 1
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications
AB.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xfcf04500 (irq = 13) is a ST16650
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
AMD_FLASH_INIT called *aks *
physmap flash device: 800000 at ff800000 virtual address Number of erase
regions
: 4
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 µs
Maximum byte/word write timeout: 256 µs
Full buffer write not supported
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
Device size: 0x200000 bytes (2 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 4
in amdstd_setup 0:
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
in MTD Partitioning <5>No RedBoot partition table detected in
phys_mapped_flash
Using physmap partition definition
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "foo-ets0"
mtd: Giving out device 0 to foo-ets0
0x00040000-0x001e0000 : "foo-ets1"
mtd: partition "agere-ets1" doesn't end on an erase block -- force read-only
mtd: Giving out device 1 to foo-ets1
0x001e0000-0x00200000 : "foo-ets2"
mtd: partition "foo-ets2" doesn't start on an erase block boundary -- force
re
ad-only
mtd: Giving out device 2 to foo-ets2
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
/dev/console mapped to mkdev 5: minor: 1
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1247k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init
calling sbin/init
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
Starting pid 8, console /dev/ttyS0: '/bin/ash'
/ $ cd /dev
/dev $ ls
console loop2 loop7 ram1 ram14 ram4 ram9 urandom
full loop3 mem ram10 ram15 ram5 random zero
kmem loop4 null ram11 ram16 ram6 tty
loop0 loop5 port ram12 ram2 ram7 tty0
loop1 loop6 ram0 ram13 ram3 ram8 ttyS0
################################################################
#
# Automatically generated make config: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_ADVANCED_OPTIONS is not set
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_440 is not set
# CONFIG_POWER3 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
CONFIG_PPC_STD_MMU=y
# CONFIG_EMBEDDED_OOM_KILLER is not set
# CONFIG_ALL_PPC is not set
# CONFIG_APUS is not set
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_PPMC260 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE is not set
# CONFIG_MENF1 is not set
# CONFIG_PUMA_A is not set
# CONFIG_HXEB100 is not set
# CONFIG_LOPEC is not set
# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
CONFIG_SANDPOINT=y
# CONFIG_POWERK2 is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_ZX4500 is not set
# CONFIG_MPC10X_STORE_GATHERING is not set
# CONFIG_SANDPOINT_X3 is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
CONFIG_PPC_ISATIMER=y
#
# General setup
#
CONFIG_MAX_POSIX_TIMERS=3000
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_HIGHMEM is not set
# CONFIG_ILATENCY is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SEMMNI=128
CONFIG_SYSVIPC_SEMMSL=250
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_MAX_USER_RT_PRIO=100
CONFIG_MAX_RT_PRIO=0
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_MULTITHREADED_CORES=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PCI_NAMES is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
CONFIG_PPC_RTC=m
# CONFIG_CMDLINE_BOOL is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=2
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_B1 is not set
CONFIG_MTD_CFI_B2=y
# CONFIG_MTD_CFI_B4 is not set
# CONFIG_MTD_CFI_B8 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_MOT_MVP is not set
# CONFIG_MTD_POWERPLUS is not set
# CONFIG_MTD_K2 is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD 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_DOCPROBE is not set
#
# Serial Flash Device Drivers
#
# CONFIG_MTD_SFLASH is not set
#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Cryptography support (CryptoAPI)
#
# CONFIG_CRYPTO is not set
#
# 128 bit blocksize
#
#
# 64 bit blocksize
#
#
# Deprecated
#
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
# CONFIG_NET_NEIGH_DEBUG is not set
# CONFIG_NET_RESTRICTED_REUSE is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IPSEC is not set
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
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_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_IPV4_IPSEC_TUNNEL=y
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_IPV6=m
# CONFIG_IPV6_DEBUG is not set
# CONFIG_IPV6_IM is not set
# CONFIG_IPV6_ZONE is not set
# CONFIG_IPV6_DROP_FAKE_V4MAPPED is not set
# CONFIG_IPV6_6TO4_NEXTHOP is not set
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ANYCAST is not set
# CONFIG_IPV6_ISATAP is not set
# CONFIG_IPV6_PREFIXLIST is not set
# CONFIG_IPV6_SUBTREES is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_MLD6_ALL_DONE is not set
# CONFIG_IPV6_NODEINFO is not set
#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set
CONFIG_IPV6_IPSEC_TUNNEL=y
# CONFIG_IPV6_IPV6_TUNNEL is not set
# CONFIG_IPV6_MOBILITY is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Appletalk devices
#
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
# CONFIG_NETDEVICES is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
#
# Macintosh device drivers
#
#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_UNIX98_PTYS is not set
# CONFIG_HVC_CONSOLE is not set
# CONFIG_IXP2000_SLAVE is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_INPUT_SERIO is not set
#
# Joysticks
#
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_LINUX_LED is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_REISERFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=m
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=2
CONFIG_JFFS2_FS_NAND=y
# CONFIG_CRAMFS is not set
# CONFIG_POSIX_MQUEUE_FS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_XFS_FS is not set
# Network File Systems
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SUNRPC is not set
# CONFIG_LOCKD is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_ZISOFS_FS is not set
# Partition Types
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel tracing
#
# CONFIG_TRACE is not set
#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
################################################################
Can any happy soul let me know :--
1)How to mount jffs2 on this flash and also to test mtd->read/write routines
?
2) Is it ok not to see mtd0.. partions in /dev directory .
3 ) Where do I register the mtd partitions to get them noticed here ??
Thanks
Arun
[-- Attachment #2: Type: text/html, Size: 17893 bytes --]
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-21 14:42 UTC (permalink / raw)
To: 'Brian D. Carlstrom', 'Olof Johansson'
Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org]
> On Behalf Of Brian D. Carlstrom
> Sent: Thursday, July 20, 2006 4:57 PM
> To: Olof Johansson
> Cc: 'Paul Mackerras'; 'linuxppc-dev list'
> Subject: Re: AltiVec in the kernel
>
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > > A quick grep memcpy in the recent glibc sources on my
> linux/ppc box
> > > seems to show no where near that level of optimization,
> but I admit
> > > that I could have missed something.
> >
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy
> optimizations seem to be using 64-bit operations and that
> 128-bit AltiVec operations are still being solicited.
"Still"?
http://www.freevec.org/
Been there for months, before the glibc thing. Most of the functions
are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
is.. we've had this there for months. Nobody has contributed a single
update or bugfix or even a performance test as far as I know.
> However, I'm guessing this addon is not something found in
> common distributions for PowerPC like Debian, Fedora, Gentoo,
> Ubuntu, ...
Indeed it's a cute feature but we were scared away by the glibc guys
when it came to glibc-ports (perhaps they just considered it not
ready, but we wanted it in there for the first release, which was
the next one). Hence freevec. Konstantinos will get back in a couple
weeks and post some updates.
The more interesting code is the MySQL stuff. All of this has been
developed by finding good examples of apps, profiling them and then
optimizing the top few functions that are most used.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: Boot strategies and Boot Image formats in arch/powerpc
From: Vitaly Bordug @ 2006-07-21 14:16 UTC (permalink / raw)
To: Claus Gindhart
Cc: Olaf Wepner, Sabine Bielski, Stefan Nickl, linuxppc-embedded
In-Reply-To: <DADA32856852FC458E0F96B664A6F55E011E239F@kom-mailsrv1.kontron-modular.com>
On Fri, 21 Jul 2006 11:35:25 +0200
"Claus Gindhart" <claus.gindhart@kontron.com> wrote:
> Hi all,
>
> currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status.
>
> We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree.
>
> However, i dont understand the following:
>
> In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used.
> This structure was easily adaptable for custom image formats.
>
> Now, these dirs dont exist any more.
Well, in arch/powerpc those stuff had no sense so far.. But it may change - see below.
>
> What is the strategy here (i could assume one the 3 variants below ?
>
> a) Is it now in the responsibility of the bootloader, to support one of the image formats,
> which can be generated here currently ?
>
This way we have started with powerpc merge and it still could be used. there are plenty of such stuff in the list archives, being discussed, and even followed up with patches.
But that imply u-boot firmware so not interesting for you I assume.
> b) Will these subdirs (e.g. "simple") come here, but just where not ported yet ?
>
Currently, Mark is working on a thing similar to this case. the kernel building zImage has to compile devicetree to binary dtb and line stuff up so that booting, the shim has started the kernel and have devicetree passed to it.
> c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format
> be performed outside the kernel source, by proprietary tools
> (e.g. like U-boot does it with the mkimage tool) ?
>
This was yet another way pondered, but I guess b) looked better.
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
>
>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Stephen Rothwell @ 2006-07-21 12:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060721063951.GB8639@monkey.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
Hi Paulus,
On Thu, 20 Jul 2006 23:39:51 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> Move all the Hypervisor call definitions to to a single header file.
> --
> Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
Can you put this one in immediately just to save Mike having to repost it :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Boot strategies and Boot Image formats in arch/powerpc
From: Claus Gindhart @ 2006-07-21 9:35 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Olaf Wepner, Sabine Bielski, Stefan Nickl
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
Hi all,
currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status.
We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree.
However, i dont understand the following:
In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used.
This structure was easily adaptable for custom image formats.
Now, these dirs dont exist any more.
What is the strategy here (i could assume one the 3 variants below ?
a) Is it now in the responsibility of the bootloader, to support one of the image formats,
which can be generated here currently ?
b) Will these subdirs (e.g. "simple") come here, but just where not ported yet ?
c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format
be performed outside the kernel source, by proprietary tools
(e.g. like U-boot does it with the mkimage tool) ?
--
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
[-- Attachment #2: Type: text/html, Size: 3578 bytes --]
^ permalink raw reply
* [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-21 6:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is a version of the instrumentation patches built on top of
Anton's hcall cleanup patch. In addition, I have gathered the
timebase and PURR snapshots in assembly code. However, it still
performs a call out to C code that updates the data structures.
I'd appreciate some comments on the assembly code as it has been
a looooong time since I've written any.
--
Mike
^ permalink raw reply
* [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Mike Kravetz @ 2006-07-21 6:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Move all the Hypervisor call definitions to to a single header file.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/drivers/net/ibmveth.h powerpc.work/drivers/net/ibmveth.h
--- powerpc/drivers/net/ibmveth.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/drivers/net/ibmveth.h 2006-07-21 07:03:44.000000000 +0000
@@ -41,16 +41,6 @@
#define IbmVethMcastRemoveFilter 0x2UL
#define IbmVethMcastClearFilterTable 0x3UL
-/* hcall numbers */
-#define H_VIO_SIGNAL 0x104
-#define H_REGISTER_LOGICAL_LAN 0x114
-#define H_FREE_LOGICAL_LAN 0x118
-#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
-#define H_SEND_LOGICAL_LAN 0x120
-#define H_MULTICAST_CTRL 0x130
-#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
-#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
-
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
plpar_hcall_norets(H_REGISTER_LOGICAL_LAN, ua, buflst, rxq, fltlst, mac)
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:03:44.000000000 +0000
@@ -164,9 +164,15 @@
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
#define H_COPY_RDMA 0x110
+#define H_REGISTER_LOGICAL_LAN 0x114
+#define H_FREE_LOGICAL_LAN 0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN 0x120
+#define H_MULTICAST_CTRL 0x130
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
@@ -196,11 +202,13 @@
#define H_GET_HCA_INFO 0x1B8
#define H_GET_PERF_COUNT 0x1BC
#define H_MANAGE_TRACE 0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define MAX_HCALL_OPCODES (H_ENABLE_CRQ >> 2)
#ifndef __ASSEMBLY__
^ permalink raw reply
* Can't "up" my eth0
From: Denny @ 2006-07-21 7:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1151373673.26257.194.camel@mindpipe>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
Hi,
I am now succefully to bring up my kernel on my PPC440GP custom board, but I failed to up my eth0, the eth0 is link down after the kernel is booting up.
There is no effect, after the command ifconfig eth0 up.
Can anyone tell me what may be the root case, and what reason may cause the eth0 unstable, thanks a lot.
below is my log:
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:01:02:54:12:47
eth0: found Generic MII PHY (0x01)
emac1: can't find PHY!
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
Starting pid 22, console /dev/teth0: link is down
Starting pid 27, console /dev/ttyS1: '/bin/bash'
Starting pid 26, console /dev/ttyS1: '/bin/application'
### Application running ...
Starting pid 29, console /dev/ttyS1: '/bin/application'
Thanks in advance!
- Denny
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
* [PATCH 3/3] powerpc: Instrument Hypervisor Calls: add debugfs file
From: Mike Kravetz @ 2006-07-21 6:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Make statistics available via files in debugfs.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:10:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:11:00.000000000 +0000
@@ -42,3 +42,96 @@ void update_hcall_stats(unsigned long op
hs->purr_total += purr_delta;
hs->num_calls++;
}
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < MAX_HCALL_OPCODES)
+ return (void *)(unsigned long)(*pos + 1);
+
+ return NULL;
+}
+
+static void *hc_next(struct seq_file *m, void *p, loff_t * pos)
+{
+ ++*pos;
+
+ return hc_start(m, pos);
+}
+
+static void hc_stop(struct seq_file *m, void *p)
+{
+}
+
+static int hc_show(struct seq_file *m, void *p)
+{
+ unsigned long h_num = (unsigned long)p;
+ struct hcall_stats *hs = (struct hcall_stats *)m->private;
+
+ if (hs[h_num].num_calls)
+ seq_printf(m, "%lu %lu %lu %lu\n", h_num<<2,
+ hs[h_num].num_calls,
+ hs[h_num].tb_total,
+ hs[h_num].purr_total);
+
+ return 0;
+}
+
+static struct seq_operations hcall_inst_seq_ops = {
+ .start = hc_start,
+ .next = hc_next,
+ .stop = hc_stop,
+ .show = hc_show
+};
+
+static int hcall_inst_seq_open(struct inode *inode, struct file *file)
+{
+ int rc;
+ struct seq_file *seq;
+
+ rc = seq_open(file, &hcall_inst_seq_ops);
+ seq = file->private_data;
+ seq->private = file->f_dentry->d_inode->u.generic_ip;
+
+ return rc;
+}
+
+static struct file_operations hcall_inst_seq_fops = {
+ .open = hcall_inst_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+#define HCALL_ROOT_DIR "hcall_inst"
+#define CPU_NAME_BUF_SIZE 32
+
+static int __init hcall_inst_init(void)
+{
+ struct dentry *hcall_root;
+ struct dentry *hcall_file;
+ char cpu_name_buf[CPU_NAME_BUF_SIZE];
+ int cpu;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return 0;
+
+ hcall_root = debugfs_create_dir(HCALL_ROOT_DIR, NULL);
+ if (!hcall_root)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu) {
+ snprintf(cpu_name_buf, CPU_NAME_BUF_SIZE, "cpu%d", cpu);
+ hcall_file = debugfs_create_file(cpu_name_buf, S_IRUGO,
+ hcall_root,
+ per_cpu(hcall_stats, cpu),
+ &hcall_inst_seq_fops);
+ if (!hcall_file)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+__initcall(hcall_inst_init);
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721064153.GC8639@monkey.ibm.com>
On Thu, Jul 20, 2006 at 11:41:53PM -0700, Mike Kravetz wrote:
> Gather snapshots in the hcall routines and make callout to update data.
Wrong patch!!!! Sorry! Here is the correct one.
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/Kconfig.debug powerpc.work/arch/powerpc/Kconfig.debug
--- powerpc/arch/powerpc/Kconfig.debug 2006-07-19 18:45:58.000000000 +0000
+++ powerpc.work/arch/powerpc/Kconfig.debug 2006-07-21 07:06:49.000000000 +0000
@@ -18,6 +18,20 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES && DEBUG_FS
+ help
+ Adds code to keep track of the number of hypervisor calls made and
+ the amount of time spent in hypervisor calls: both wall time (based
+ on time base) and cpu time (based on PURR). A directory named
+ hcall_inst is added at the root of the debugfs filesystem. Within
+ the hcall_inst directory are files that contain CPU specific call
+ statistics.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr powerpc/arch/powerpc/platforms/pseries/Makefile powerpc.work/arch/powerpc/platforms/pseries/Makefile
--- powerpc/arch/powerpc/platforms/pseries/Makefile 2006-07-19 18:46:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/Makefile 2006-07-21 07:06:49.000000000 +0000
@@ -12,3 +12,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall.S powerpc.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc/arch/powerpc/platforms/pseries/hvCall.S 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall.S 2006-07-21 07:06:49.000000000 +0000
@@ -11,7 +11,57 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
-#define STK_PARM(i) (48 + ((i)-3)*8)
+#define STK_PARM(i) (STACKFRAMESIZE + 48 + ((i)-3)*8)
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#ifdef CONFIG_HCALL_STATS
+#define STACKFRAMESIZE 256
+#define HCALL_INST_PRECALL \
+ /* use stack frame to save a few non-volital regs */ \
+ stdu r1,-STACKFRAMESIZE(r1); \
+ std r31,STK_REG(r31)(r1); \
+ std r30,STK_REG(r30)(r1); \
+ std r29,STK_REG(r29)(r1); \
+ std r28,STK_REG(r28)(r1); \
+ \
+ /* save lr and hcall opcode */ \
+ /* then get time, purr snapshot before hcall */ \
+ mflr r31; \
+ mr r30,r3; \
+ mftb r29; \
+BEGIN_FTR_SECTION; \
+ mfspr r28,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR);
+
+#define HCALL_INST_POSTCALL \
+ /* get time, purr snapshot after hcall */ \
+ mftb r4; \
+BEGIN_FTR_SECTION; \
+ mfspr r5,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ /* setup regs to call routine that stuffs stats */ \
+ /* into per-cpu/per-call structure. */ \
+ subf r4,r29,r4; \
+ subf r5,r28,r5; \
+ mr r29,r3; /* save hcall rc */ \
+ mr r3,r30; \
+ bl .update_hcall_stats; \
+ \
+ /* restore hcall rc, lr and non-volital regs */ \
+ mr r3,r29; \
+ mtlr r31; \
+ ld r31,STK_REG(r31)(r1); \
+ ld r30,STK_REG(r30)(r1); \
+ ld r29,STK_REG(r29)(r1); \
+ ld r28,STK_REG(r28)(r1); \
+ addi r1,r1,STACKFRAMESIZE
+#else
+
+#define STACKFRAMESIZE 0
+#define HCALL_INST_PRECALL nop
+#define HCALL_INST_POSTCALL nop
+#endif
.text
@@ -21,8 +71,12 @@ _GLOBAL(plpar_hcall_norets)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
HVSC /* invoke the hypervisor */
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
blr /* return r3 = status */
@@ -33,6 +87,8 @@ _GLOBAL(plpar_hcall)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -50,6 +106,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +119,8 @@ _GLOBAL(plpar_hcall9)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -86,6 +146,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:08:40.000000000 +0000
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/cpumask.h>
+#include <asm/hvcall.h>
+#include <asm/firmware.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Common update of the per-CPU/per-hcall statistics
+ */
+void update_hcall_stats(unsigned long opcode,
+ unsigned long tb_delta,
+ unsigned long purr_delta)
+{
+ unsigned long op_index = opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ hs->tb_total += tb_delta;
+ hs->purr_total += purr_delta;
+ hs->num_calls++;
+}
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-21 07:04:39.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:06:49.000000000 +0000
@@ -246,6 +246,15 @@ long plpar_hcall(unsigned long opcode, u
#define PLPAR_HCALL9_BUFSIZE 9
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
+/* For hcall instrumentation. One structure per-hcall, per-CPU */
+struct hcall_stats {
+ unsigned long num_calls; /* number of calls (on this CPU) */
+ unsigned long tb_total; /* total wall time (mftb) of calls. */
+ unsigned long purr_total; /* total cpu time (PURR) of calls. */
+};
+void update_hcall_stats(unsigned long opcode, unsigned long tb_delta,
+ unsigned long purr_delta);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17-rc6/arch/powerpc/Kconfig.debug linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug
--- linux-2.6.17-rc6/arch/powerpc/Kconfig.debug 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug 2006-06-13 21:39:24.000000000 +0000
@@ -18,6 +18,16 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES
+ help
+ Adds code to keep track of number of hypervisor calls made and
+ the amount of time spent in hypervisor calls.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile 2006-06-13 21:39:24.000000000 +0000
@@ -9,3 +9,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S 2006-06-13 21:39:24.000000000 +0000
@@ -25,7 +25,11 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_base)
+#else
_GLOBAL(plpar_hcall)
+#endif
HMT_MEDIUM
mfcr r0
@@ -52,7 +56,15 @@ _GLOBAL(plpar_hcall)
/* Simple interface with no output values (other than status) */
+#ifdef CONFIG_HCALL_STATS
_GLOBAL(plpar_hcall_norets)
+ b plpar_hcall_norets_C
+
+
+_GLOBAL(plpar_hcall_norets_base)
+#else
+_GLOBAL(plpar_hcall_norets)
+#endif
HMT_MEDIUM
mfcr r0
@@ -76,7 +88,11 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_8arg_2ret_base)
+#else
_GLOBAL(plpar_hcall_8arg_2ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -102,7 +118,11 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_4out_base)
+#else
_GLOBAL(plpar_hcall_4out)
+#endif
HMT_MEDIUM
mfcr r0
@@ -144,7 +164,11 @@ _GLOBAL(plpar_hcall_4out)
unsigned long *out6, 102(R1)
unsigned long *out7); 100(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_7arg_7ret_base)
+#else
_GLOBAL(plpar_hcall_7arg_7ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -193,7 +217,11 @@ _GLOBAL(plpar_hcall_7arg_7ret)
unsigned long *out8, 94(R1)
unsigned long *out9, 92(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_9arg_9ret_base)
+#else
_GLOBAL(plpar_hcall_9arg_9ret)
+#endif
HMT_MEDIUM
mfcr r0
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-06-13 21:39:24.000000000 +0000
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <asm/hvcall.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+static inline void update_stats(unsigned long opcode, unsigned long t_before)
+{
+ unsigned long op_index= opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ /* racey, but acceptable for non-critical stats */
+ hs->total_time += (mfspr(SPRN_PURR) - t_before);
+ hs->num_calls++;
+}
+
+extern long plpar_hcall_base (unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_norets_base(unsigned long opcode, ...);
+
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_norets_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_8arg_2ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_8arg_2ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, out1);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_4out_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_4out_base(opcode, arg1, arg2, arg3, arg4, out1,
+ out2, out3, out4);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_7arg_7ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_7arg_7ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, out1, out2, out3, out4,
+ out5, out6, out7);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_9arg_9ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_9arg_9ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9, out1, out2,
+ out3, out4, out5, out6, out7, out8,
+ out9);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
diff -Naupr linux-2.6.17-rc6/include/asm-powerpc/hvcall.h linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17-rc6/include/asm-powerpc/hvcall.h 2006-06-13 21:38:45.000000000 +0000
+++ linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h 2006-06-13 21:39:24.000000000 +0000
@@ -292,6 +292,13 @@ long plpar_hcall_9arg_9ret(unsigned long
unsigned long *out8,
unsigned long *out9);
+#ifdef CONFIG_HCALL_STATS
+struct hcall_stats {
+ unsigned long num_calls;
+ unsigned long total_time;
+};
+#endif /* CONFIG_HCALL_STATS */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-21 6:35 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 02:56:33PM -0700, Brian D. Carlstrom wrote:
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
There's always lead time to get things into distros, that would still be
true if you modified glibc instead as well.
-Olof
^ permalink raw reply
* Regarding MAL
From: Sangameshwar Pujari @ 2006-07-21 3:54 UTC (permalink / raw)
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
Hi,
i am porting a EMAC driver from NetBSD to my Xilinix ML403 embeddded =
board . NETBSD code is Having a Media Access Layer (MAL) , which i want =
to know bit , is it the same MAC layer .
regards
sangamesh
^ permalink raw reply
* RE: [Linux-ATM-General] mpc8360sar
From: Li Tony-r64360 @ 2006-07-21 2:36 UTC (permalink / raw)
To: Alex Zeffertt, Kumar Gala, Chu hanjin-r52514
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
In-Reply-To: <44BFABFD.1070904@cambridgebroadband.com>
Alex, we are working on the 8360 upstream. As the similarity between
832x and 8360, if the 8360 has benn accepted, it would be easy for 832x
upstream.
We have submit the 8360 patch to the opensource. But we are waiting it
to be accepted.
BTW, the new version QOC3-ATM card will adopt. The QOC3-ATM card code
need some modification.=20
I send the new code to you if it done. Ok ?
Tony
> -----Original Message-----
> From: Alex Zeffertt [mailto:ajz@cambridgebroadband.com]=20
> Sent: Friday, July 21, 2006 12:15 AM
> To: Kumar Gala
> Cc: Li Tony-r64360; linux-atm-general@lists.sourceforge.net;=20
> linuxppc-embedded@ozlabs.org
> Subject: Re: [Linux-ATM-General] mpc8360sar
>=20
> Kumar Gala wrote:
> >=20
> > On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote:
> >=20
> >>
> >>> Any reason we dont try to get your work up stream into=20
> the mainline=20
> >>> kernel?
> >>> - kumar
> >>
> >> I'd like to see it upstreamed - the more people who use it=20
> the more=20
> >> help I get!
> >>
> >> However, mpc8360sar is built on Freescale's BSP which adds basic=20
> >> support for the board, the MPC832xE-MDS, to the stock=20
> linux kernel. =20
> >> This support consists of the following patches:
> >>
> >> Patch0 : patch-2.6.11.bz2
> >> Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
> >> Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
> >> Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
> >> Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
> >> Patch5 : linux-2.6.11-mpc83xx-sec2.patch
> >> Patch6 : mpc832x-sec2v15-config-1.patch
> >> Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
> >> Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
> >> Patch9 : linux-2.6.11-mpc8360-general-1.patch
> >> Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
> >> Patch11 : linux-2.6.11-mpc832x-basic-4.patch
> >> Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
> >> Patch13 : linux-2.6.11-mpc832x-spi-1.patch
> >> Patch14 : linux-2.6.11-mpc832x-BIT.patch
> >> Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
> >> Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
> >> Patch17 : linux-2.6.11-mpc832x-atm-1.patch
> >>
> >> I guess there's no point upstreaming mpc8360sar until=20
> freescale have=20
> >> upstreamed these patches (and ported them to the current kernel).
> >=20
> > True, a large number of these patches are upstream, and if I had=20
> > access to MPC836x or MPC832x HW I'd work on getting the others that=20
> > are reasonable.
> >=20
> >> Alex
> >>
> >> PS It's probable that mpc8360sar actually only requires a=20
> handful of=20
> >> the above patches to be applied.
> >=20
> > Agreed.
> >=20
> > - kumar
>=20
>=20
> Tony, can you let me know when CONFIG_MPC832XE_MDS support is=20
> upstreamed to a kernel.org kernel. I'll then try to get the=20
> mpc8360sar working with this kernel and then upstream it.
>=20
> Alex
>=20
> PS I'm not entirely sure how "upstreaming" is done.
>=20
^ permalink raw reply
* mpic discovery on JS20
From: Amos Waterland @ 2006-07-20 23:16 UTC (permalink / raw)
To: linuxppc-dev
Current Linus and Paulus trees do this on JS20 blades with SLOF:
Failed to locate the MPIC interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
Maple: Found RTC at IO 0x1070
cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
sp: c00000007ef83d30
msr: 9000000000029032
current = 0xc00000000194d610
paca = 0xc00000000038f180
pid = 1, comm = swapper
kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
Doing a git-bisect produces this:
0ebfff1491ef85d41ddf9c633834838be144f69f is first bad commit
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon Jul 3 21:36:01 2006 +1000
[POWERPC] Add new interrupt mapping core and change platforms to use it
This adds the new irq remapper core and removes the old one. Because
there are some fundamental conflicts with the old code, like the value
of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
etc..., this commit also changes the relevant platform and driver code
over to use the new remapper (so as not to cause difficulties later
in bisecting).
This patch removes the old pre-parsing of the open firmware interrupt
tree along with all the bogus assumptions it made to try to renumber
interrupts according to the platform. This is all to be handled by the
new code now.
For the pSeries XICS interrupt controller, a single remapper host is
created for the whole machine regardless of how many interrupt
presentation and source controllers are found, and it's set to match
any device node that isn't a 8259. That works fine on pSeries and
avoids having to deal with some of the complexities of split source
controllers vs. presentation controllers in the pSeries device trees.
The powerpc i8259 PIC driver now always requests the legacy interrupt
range. It also has the feature of being able to match any device node
(including NULL) if passed no device node as an input. That will help
porting over platforms with broken device-trees like Pegasos who don't
have a proper interrupt tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: AltiVec in the kernel
From: Daniel Ostrow @ 2006-07-20 22:39 UTC (permalink / raw)
To: Brian D. Carlstrom
Cc: Olof Johansson, 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, 2006-07-20 at 14:56 -0700, Brian D. Carlstrom wrote:
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > > seems to show no where near that level of optimization, but I admit
> > > that I could have missed something.
> >
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy optimizations seem
> to be using 64-bit operations and that 128-bit AltiVec operations are
> still being solicited.
>
> I was encouraged to see the following:
>
> If you need to build generic distributions (supporting several
> <cpu_types>) you can leverage the dl_procinfo support built into
> glibc. This mechanism allows for multiple versions of the core
> libraries (libc, libm, librt, libpthread, libpthread_db) to be
> stored in hardware/platform specific subdirectories under /lib[64].
>
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
It has been part of Gentoo's glibc since 2.4 came out.
--Dan
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 21:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720190523.GA27775@pb15.lixom.net>
At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > seems to show no where near that level of optimization, but I admit
> > that I could have missed something.
>
> http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
Very interesting. According to that page, the memcpy optimizations seem
to be using 64-bit operations and that 128-bit AltiVec operations are
still being solicited.
I was encouraged to see the following:
If you need to build generic distributions (supporting several
<cpu_types>) you can leverage the dl_procinfo support built into
glibc. This mechanism allows for multiple versions of the core
libraries (libc, libm, librt, libpthread, libpthread_db) to be
stored in hardware/platform specific subdirectories under /lib[64].
However, I'm guessing this addon is not something found in common
distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
-bri
^ permalink raw reply
* mainly iSeries updates
From: Stephen Rothwell @ 2006-07-20 21:25 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
Hi Paul,
Please pull ozlabs.org:~sfr/kernels/sfr.git to get the following:
Michael Ellerman:
[POWERPC] iseries: Use device tree /system-id in /proc/iSeries/config
[POWERPC] iseries: Move e2a()/strne2a() into their only caller
[POWERPC] iseries: Cleanup e2a() and strne2a()
[POWERPC] iseries: Make ItExtVpdPanel private to iSeries
[POWERPC] iseries: Make HvLpConfig_get(Primary)LpIndex functions
[POWERPC] iseries: Move ItLpNaca into platforms/iseries
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] Fix a compiler warning in mm/tlb_64.c
[POWERPC] iseries: Move iommu_table_cb into platforms/iseries
Stephen Rothwell:
[POWERPC] iseries: A new iSeries console
[POWERPC] Make the hvc_console output buffer size settable
[POWERPC] iseries: Small viotape cleanup allowed by devfs removal
[POWERPC] iseries: Remove unnecessary include of iseries/hv_lp_event.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with ibm_emac driver
From: Eugene Surovegin @ 2006-07-20 19:56 UTC (permalink / raw)
To: Ian Remmler; +Cc: linuxppc-embedded
In-Reply-To: <20060720183242.GA22930@localhost>
On Thu, Jul 20, 2006 at 01:32:42PM -0500, Ian Remmler wrote:
> Hi,
>
> I'm having a problem with the ibm_emac driver for the built in
> gigabit ethernet on the 440gx. I was hoping someone could shed
> some light or at least point me in the right direction.
>
> I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
> problem we are having is this: when we push data over the emac
> interface (eth0 and eth1 both show the problem), we sporadically
> get a "MAL: Rx descriptor error..." from mal_rxde in
> ibm_ocp_mal.c.
>
> Occasionally, the interface will "freeze up" for a few seconds.
> An ifconfig down/up will bring it back, but from then on it will
> freeze up again right away.
>
> It looks to me like this error indicates that we're out of RX
> buffers, but I don't how we would be running out. I'm no kernel
> or networking expert, but I thought the TCP stack would take
> care of throttling itself to prevent that sort of thing. I
> would appreciate any help.
No idea what GMS is, but they seem to use old buggy EMAC driver.
You can use kernel.org's 2.6 or 2.4.31 backport at
http://kernel.ebshome.net/
As a side note, TCP cannot throttle _all_ Rx traffic, think for
example of a fast box sending a lot of small UDP packets to the 440gx.
--
Eugene
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 19:18 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153422097.19682.84.camel@saruman.qstreams.net>
On Jul 20, 2006, at 2:01 PM, Ben Warren wrote:
> Way cool! Thanks a lot. I'll try it out when my hardware comes in...
Cool, I no longer have access the the system that used the mux, so
when I rework the driver can I get you to test it?
- k
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-20 19:05 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <le8xmoktav.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> A quick grep memcpy in the recent glibc sources on my linux/ppc box
> seems to show no where near that level of optimization, but I admit
> that I could have missed something.
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
-Olof
^ permalink raw reply
* Re: I2C with bus muxes
From: Ben Warren @ 2006-07-20 19:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-embedded
In-Reply-To: <61F75343-B9B9-4349-A463-E39C7532A378@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
Way cool! Thanks a lot. I'll try it out when my hardware comes in...
regards,
Ben
On Thu, 2006-07-20 at 13:51 -0500, Kumar Gala wrote:
> On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
>
> > Hello,
> >
> > Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> > under the /sysfs device model? I have some optical transponders on my
> > board that through the wisdom of some committee all have the same
> > fixed
> > I2C address. To get around this, we put them behind muxes, creating
> > 'virtual' I2C busses. I imagine this could be modeled something like
> > the USB hub model, but that's just a first stab.
>
> I'm pretty sure I submitted a set of patches for this upstream.
> However there was some desire to hold off until some other changes.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
> http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
>
> - kumar
>
>
[-- Attachment #2: Type: text/html, Size: 1826 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 18:47 UTC (permalink / raw)
To: Linas Vepstas; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720174255.GP5905@austin.ibm.com>
At Thu, 20 Jul 2006 12:42:55 -0500,
Linas Vepstas wrote:
> > We found glibc sucked for that.
>
> Only because someone was asleep at the wheel, or there was a bug.
>
> When glibc gets ported to a new architecture, one of the earliest
> tasks is to create optimized versions of memcpy and the like.
> Presumably, on powerpc, this would have been done more than a
> decade ago; its hard for me to imagine that there'd be a problem
> there. Now, I haven't looked at the code, but I just can't imagine
> how this would not have been found and fixed by now. Is there
> really a problem wiht glibc performance on powerpc? I mean,
> this is a pretty serious accusation, and something that should
> be fixed asap.
In the course of my work, I use powerpc architecture simulators. When
working on Mac OS X with a G5, I had to implement some of the basic
AltiVec specifically for use by their libc memcpy implementation. A
quick grep memcpy in the recent glibc sources on my linux/ppc box seems
to show no where near that level of optimization, but I admit that I
could have missed something. However, I would not be surprised that
glibc avoided AltiVec specific optimizations since it would add to the
complexity of supporting various architectures with one binary. On Mac
OS X, libc actually delegated a small number of libc calls such as
memcpy via a kernel managed page at the end of the address space that
setup which routines to use based on currently running architecture.
-bri
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 18:51 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153408592.19682.39.camel@saruman.qstreams.net>
On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
> Hello,
>
> Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> under the /sysfs device model? I have some optical transponders on my
> board that through the wisdom of some committee all have the same
> fixed
> I2C address. To get around this, we put them behind muxes, creating
> 'virtual' I2C busses. I imagine this could be modeled something like
> the USB hub model, but that's just a first stab.
I'm pretty sure I submitted a set of patches for this upstream.
However there was some desire to hold off until some other changes.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
- kumar
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Benjamin Herrenschmidt @ 2006-07-20 18:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060719044510.24117.qmail@web36604.mail.mud.yahoo.com>
Only memory mapped into userland contexts can be paged out in the first
place.
Ben.
^ 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