* Re: uboot environment variables size for Yosemite board.
From: Wolfgang Denk @ 2006-07-17 7:00 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net>
In message <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net> you wrote:
>
> I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
Note that this is off topic here. You should have posted this on the
U-Boot-Users mailing list instead.
> this uboot from DENX site. It uses EEPROM to store environment
> variables. Since EEPROM on Yosemite board is only 512 bytes, there can
> not be more environment variables which is not very convenient.
Thisi s wrong. The Yosemite configuration uses (like most (all?) AMCC
eval boards - two redundand flash sectors to store the environment.
And available environment size is 8 kB:
=> print
...
Environment size: 1355/8187 bytes
> There is theoretical possibility to save these variables on flash (64M
> from which I use only part) and yosemite.h header file even has defines,
> allowing this option. But is it going work in reality? What is simplest
> way for Yosemite board to increase environment variables storage space?
I have no idea where you got your board configuration from, but it is
definitely not current code, nor the binary image at
ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/u-boot.bin
The current code does use (redundand) flash for environment storage.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
^ permalink raw reply
* Re: setup arch
From: Robin H. Johnson @ 2006-07-17 7:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060709170909.90774.qmail@web35812.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
(I tried to sent this before, but my mailserver wasn't playing nice).
On Sun, Jul 09, 2006 at 10:09:09AM -0700, Paul Smith wrote:
> I hesitate to lay this one out here because you all
> are way over my head. The regular forums have not
> responded to this in any meaningful way.
> Hi,
>
>
> Box:
> Quad 2.5 PPC
> 4.5 GB non ecc 533 Ram
> RocketRaid2320
> Nvida 6600 256mb
>
>
> software resources:
[snip the wrong iso files]
Look in the experimental directory of your local Gentoo mirror for
install-ppc64-minimal-dual-core-2006.0-32ul.iso
I believe this was because the dual-core patches aren't available in time for
the actual release media creation, and this was created later to make the newer
systems usable.
Additionally, unless you're planning on contributing the the Noveau driver for
accelerated 2D/3D support on the Nvidia cards, you won't be getting far with
the nvidia card.
Getting an ATI card will give you working 3D in most cases. See this list for
what's supported at the bleeding edge:
http://dri.freedesktop.org/wiki/ATIRadeon#head-298bd23baafb9c2fad1774d1d2fa54bd2aa55e7d
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* What is "request_module: runaway loop modprobe binfmt-4c46"?
From: Zhou Rui @ 2006-07-17 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 14686 bytes --]
Hi,
I tried to compile kernel for PowerPC405EP Octobus board with ELDK4.0. I used the kernel source 2.6.15 contained in ELDK4.0. I cross-compiled the kernel with "ARCH=ppc CROSS_COMPILE=ppc_4xx-". The filesystem was based on NFS. I tried to boot the image from ram in u-boot, but the boot procedure stopped at
"VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k init
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46
request_module: runaway loop modprobe binfmt-4c46"
So would you like to tell me what the matter is with this? Thanks a lot.
My .config file for 2.6.15 kernel is like this:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15
# Wed Aug 23 14:58:08 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD 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=y
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_MATH_EMULATION=y
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
# CONFIG_WANT_EARLY_SERIAL is not set
#
# IBM 4xx options
#
# CONFIG_BUBINGA is not set
# CONFIG_CPCI405 is not set
# CONFIG_EP405 is not set
CONFIG_PPChameleonEVB=y
# CONFIG_REDWOOD_5 is not set
# CONFIG_REDWOOD_6 is not set
# CONFIG_SYCAMORE is not set
# CONFIG_WALNUT is not set
# CONFIG_XILINX_ML300 is not set
CONFIG_IBM_OCP=y
CONFIG_405EP=y
CONFIG_PPC4xx_DMA=y
CONFIG_PPC4xx_EDMA=y
CONFIG_PPC_GEN550=y
CONFIG_UART0_TTYS0=y
# CONFIG_UART0_TTYS1 is not set
CONFIG_NOT_COHERENT_CACHE=y
#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
# CONFIG_HIGHMEM is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
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_BINFMT_ELF is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyS0,115200 console=tty0 root=/dev/nfs"
# CONFIG_PM is not set
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
# CONFIG_PPC_I8259 is not set
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS 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 is not set
CONFIG_CONSISTENT_START=0xff100000
# CONFIG_CONSISTENT_SIZE_BOOL is not set
CONFIG_CONSISTENT_SIZE=0x00200000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00400000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
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_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP 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 is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER 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=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# 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=y
# 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 is not set
CONFIG_IBM_EMAC=y
CONFIG_IBM_EMAC_RXB=128
CONFIG_IBM_EMAC_TXB=64
CONFIG_IBM_EMAC_POLL_WEIGHT=32
CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
# CONFIG_IBM_EMAC_DEBUG is not set
#
# 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 is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_LIBPS2 is not set
CONFIG_SERIO_RAW=y
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# 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_AGP is not set
# 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
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI 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
#
# InfiniBand support
#
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# 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=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_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=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# 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 is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
# CONFIG_NLS is not set
#
# IBM 40x options
#
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
CONFIG_BDI_SWITCH=y
CONFIG_SERIAL_TEXT_DEBUG=y
CONFIG_PPC_OCP=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
Zhou Rui
Distributed & Embedded System Lab
School of Information Science & Engineering
Lanzhou University, P. R. China
http://dslab.lzu.edu.cn/~zr/
---------------------------------
抢注雅虎免费邮箱-3.5G容量，20M附件！
[-- Attachment #2: Type: text/html, Size: 17050 bytes --]
^ permalink raw reply
* Re: uboot environment variables size for Yosemite board.
From: John Otken @ 2006-07-17 11:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <20060717070018.21ED1353C61@atlas.denx.de>
Wolfgang Denk wrote:
> In message <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net> you wrote:
>> I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
>
> Note that this is off topic here. You should have posted this on the
> U-Boot-Users mailing list instead.
>
>> this uboot from DENX site. It uses EEPROM to store environment
>> variables. Since EEPROM on Yosemite board is only 512 bytes, there can
>> not be more environment variables which is not very convenient.
>
> Thisi s wrong. The Yosemite configuration uses (like most (all?) AMCC
> eval boards - two redundand flash sectors to store the environment.
> And available environment size is 8 kB:
He has an older Yosemite. The original Yosemite U-Boot used the EEPROM
for environment variables.
> => print
> ...
> Environment size: 1355/8187 bytes
>
>> There is theoretical possibility to save these variables on flash (64M
>> from which I use only part) and yosemite.h header file even has defines,
>> allowing this option. But is it going work in reality? What is simplest
>> way for Yosemite board to increase environment variables storage space?
>
> I have no idea where you got your board configuration from, but it is
> definitely not current code, nor the binary image at
> ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/u-boot.bin
>
> The current code does use (redundand) flash for environment storage.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* [PATCH] panic_on_oops: remove ssleep()
From: Horms @ 2006-07-17 16:17 UTC (permalink / raw)
To: Russell King, Tony Luck, Paul Mackerras, Anton Blanchard,
Andi Kleen, Chris Zankel, Andrew Morton
Cc: linuxppc-dev, linux-ia64, linux-kernel, discuss
This patch is part of an effort to unify the panic_on_oops behaviour
across all architectures that implement it.
It was pointed out to me by Andi Kleen that if an oops has occured
in interrupt context, then calling sleep() in the oops path will only cause
a panic, and that it would be really better for it not to be in the path at
all.
This patch removes the ssleep() call and reworks the console message
accordinly. I have a slght concern that the resulting console message is
too long, feedback welcome.
For powerpc it also unifies the 32bit and 64bit behaviour.
Fror x86_64, this patch only updates the console message, as
ssleep() is already not present.
Signed-Off-By: Horms <horms@verge.net.au>
arch/arm/kernel/traps.c | 7 ++-----
arch/i386/kernel/traps.c | 8 +++-----
arch/ia64/kernel/traps.c | 7 ++-----
arch/powerpc/kernel/traps.c | 10 +++-------
arch/x86_64/kernel/traps.c | 2 +-
arch/xtensa/kernel/traps.c | 8 +++-----
6 files changed, 14 insertions(+), 28 deletions(-)
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -232,11 +232,8 @@ NORET_TYPE void die(const char *str, str
bust_spinlocks(0);
spin_unlock_irq(&die_lock);
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
do_exit(SIGSEGV);
}
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -442,11 +442,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
oops_exit();
do_exit(SIGSEGV);
}
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -117,11 +117,8 @@ die (const char *str, struct pt_regs *re
die.lock_owner = -1;
spin_unlock_irq(&die.lock);
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
do_exit(SIGSEGV);
}
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -150,13 +150,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
-#ifdef CONFIG_PPC64
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
-#endif
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
do_exit(err);
return 0;
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -521,7 +521,7 @@ void __kprobes oops_end(unsigned long fl
/* Nest count reaches zero, release the lock. */
spin_unlock_irqrestore(&die_lock, flags);
if (panic_on_oops)
- panic("Oops");
+ panic("Fatal exception: panic_on_oops");
}
void __kprobes __die(const char * str, struct pt_regs * regs, long err)
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -487,11 +487,9 @@ #endif
if (in_interrupt())
panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
do_exit(err);
}
^ permalink raw reply
* XUP Linux Envirnment, Hi Everyone!
From: scott @ 2006-07-17 16:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
Hey list, I'm new here so I thought I'd introduce myself a bit. I'm a grad student at the University of Colorado Boulder, and am researching novel FPGA reconfiguration techniques this summer. Our focus is on Xilinx parts and their partial reconfiguration features. Our goal is to use active reconfiguration to move functional blocks around an FPGA as needed for space-based mission survivability.
Anyway, in order to do this I first need to get a Linux envirnment up and running on my Xilinx XUP board. This board has a Virtex II Pro FPGA with dual PPC405 cores built-in. I have a basic Linux install built up using the EMPART tutorial (http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml) and other pages it references. I have followed these instructions exactly, including busybox and Linux kernel versions (1.1.0 and 2.4.26, respectively) and everything looks swell EXCEPT: I can't manage to communicate with my custom IP hanging off the OPB bus. Actually, I can't manage to communicate with any peripherals at all off the OPB bus.
As per the EMPART tutorial's recommendations, here's how I attempt IP access:
fd = open("/dev/mem", O_RDWR);
ptr = MAP_FAILED; // Initialize to bad value
ptr = (int *) mmap(0, 256, PROT_READ|PROT_WRITE, MAP_SHARED, fd, USER_LOGIC_BASEADDR);
if(ptr==MAP_FAILED) {
printf("Err: cannot access address!\n");
return -1;
}
*ptr = 0xA;
The mmap call appears to work, and returns a pointer to virtual memory that supposedly references the physical address my IP is located at. However, when I try to read or write to this pointer I just get a rather ambiguous "bus error".
Some random things I have tried:
- setting dugging for devfs
- returns no unusual messages
- numerous scans through kernel config params looking for some sort of MMU settings or something
- setting a pointer directly to the physical address of the peripheral
- yeah, right...
- mapping a pointer to another established IP, in this case UART
- same problem
Anyone have any experience with this topic? Any suggestions at all? Do you think it has something to do w/ the MMU of the PPC405, or am I way off base here? I know this isn't an FPGA forum, but then I don't think there exists a forum which exactly meets my needs. :)
Thanks much, --scott
[-- Attachment #2: Type: text/html, Size: 3989 bytes --]
^ permalink raw reply
* where is the kernel source for ppc embedded?(may sound stupid)
From: Lei Sun @ 2006-07-17 15:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am taking another guys porting work, he downloaded 2.4.30 for ppc.
I was looking at http://www.denx.de/, and kernel.org, didn't feel like
it was from there, since the current source tree only have arch/ppc
directory, no other arch specific tree.
So where i should download 2.4.30 with all patch applied?
Thanks
ls
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Grant Likely @ 2006-07-17 17:15 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607170844v1626009at43766449872bd25f@mail.gmail.com>
On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> Hi:
> I am taking another guys porting work, he downloaded 2.4.30 for ppc.
> I was looking at http://www.denx.de/, and kernel.org, didn't feel like
> it was from there, since the current source tree only have arch/ppc
> directory, no other arch specific tree.
> So where i should download 2.4.30 with all patch applied?
http://penguinppc.org/kernel/
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Lei Sun @ 2006-07-17 18:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0607171015i5a6048aaje2d9ec557fbde22d@mail.gmail.com>
I looked at that website, and it suggested downloading kernel from
kernel.org. I've downloaded , but apparently, it's different with what
I have right now, there is no ADS8260 and PQ2FADS-VR board type . I
think there are some patch for that board already, where can I find
those patches?
Thanks
ls
On 7/17/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> > Hi:
> > I am taking another guys porting work, he downloaded 2.4.30 for ppc.
> > I was looking at http://www.denx.de/, and kernel.org, didn't feel like
> > it was from there, since the current source tree only have arch/ppc
> > directory, no other arch specific tree.
> > So where i should download 2.4.30 with all patch applied?
>
> http://penguinppc.org/kernel/
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Grant Likely @ 2006-07-17 18:52 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607171129r3b541087l73a57bc3c8108e43@mail.gmail.com>
On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> I looked at that website, and it suggested downloading kernel from
> kernel.org. I've downloaded , but apparently, it's different with what
> I have right now, there is no ADS8260 and PQ2FADS-VR board type . I
> think there are some patch for that board already, where can I find
> those patches?
Try the "no longer used" tree listed at the bottom of the page if you
want a 2.4 kernel.
If you want 2.6, use kernel.org
I don't know if ADS8260 or PQ2FADS-VR support is in either tree.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-17 19:16 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <a0bc9bf80607140921y5d11bf37r3f18e2dbdd03b017@mail.gmail.com>
On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
> On 7/14/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Nack, my expectation is this is all setup by the boot loader.
>
> That's a good wish. ;) However, USB is not required by bootloader. So
> it is not likely to be initialized there. And if we put it in
> bootloader, it will be hard to change the mode(MPH/DR), which requires
> a re-burn of bootloader. It's better that we make sure it's correctly
> configured here.
I disagree. You are coming from this from a board that does
everything under the sun. I'd like to avoid having this type of
initialization in the kernel. There is a whole additional kitchen
sink that could move into the kernel as well.
- kumar
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Hollis Blanchard @ 2006-07-17 20:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <A4F686A1-9558-4DD0-BF4C-BB64494BB719@kernel.crashing.org>
On Mon, 2006-07-17 at 14:16 -0500, Kumar Gala wrote:
> On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
>
> > On 7/14/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Nack, my expectation is this is all setup by the boot loader.
> >
> > That's a good wish. ;) However, USB is not required by bootloader. So
> > it is not likely to be initialized there. And if we put it in
> > bootloader, it will be hard to change the mode(MPH/DR), which requires
> > a re-burn of bootloader. It's better that we make sure it's correctly
> > configured here.
>
> I disagree. You are coming from this from a board that does
> everything under the sun. I'd like to avoid having this type of
> initialization in the kernel. There is a whole additional kitchen
> sink that could move into the kernel as well.
Seems to me that it's far better to have init code in the kernel than
firmware. For one example, look at the x86 video card init problem
PowerPC Linux has. It's also far easier to fix/deploy Linux code than
firmware code, as Li observed, and on top of that it's less work for
non-UBoot firmwares in the future.
-Hollis
^ permalink raw reply
* kernel memory map/usage/holes?
From: Chris Friesen @ 2006-07-17 20:06 UTC (permalink / raw)
To: linuxppc-dev
I've got a Maple board with 4GB of memory running a modified 2.6.10
kernel. When it boots, I see the following in the logs:
Top of RAM: 0x180000000, Total RAM: 0x100000000
On node 0 totalpages: 1048576
DMA zone: 1048576 pages, LIFO batch:16
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Then a bit later, I see:
Memory: 4006976k/6291456k available (3408k kernel code, 2284124k
reserved, 1656k data, 448k bss, 220k init)
1048576 pages works out to 4194304kB, so what happened to the 187328kB
that is the difference between the "Total RAM" and "Memory:" lines?
We've got an app that wants as much memory as possible, so I need to
explain where this 183MB of memory is being used.
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-17 20:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <A4F686A1-9558-4DD0-BF4C-BB64494BB719@kernel.crashing.org>
On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
> I disagree. You are coming from this from a board that does
> everything under the sun. I'd like to avoid having this type of
> initialization in the kernel. There is a whole additional kitchen
> sink that could move into the kernel as well.
Well, I'm going to have to disagree with your disagreement :-)
The kernel should not assume things are properly initialized
and rely on the boot rom to do such things. I have several
reasons for this. One is that we are always pressed to make
embedded systems boot more quickly, and taking time to
initialize things in the boot rom just makes that a totally
inflexible system design. We don't need to initialize things
we don't use, or can postpone until later. Two, it makes
us dependent upon a particular boot rom, or boot rom
behavior, that not all boards may choose to support.
Three, board designs may have external logic that requires
a certain start up sequence or control register access
that complicates the boot rom in it's ability to share
code or implementation.
There are more, but I think you see the trend. In my
years of doing this kind of development, you can't
assume a boot rom is going to do much more than initialize
memory and load the kernel. I prefer the flexibility
to be in the kernel, and not in the boot rom, because it
is so much easier to develop and control.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-17 21:39 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <5C69B7C2-1637-4B9A-BDCA-596DBE70A7DC@embeddedalley.com>
On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
>
> On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
>
>> I disagree. You are coming from this from a board that does
>> everything under the sun. I'd like to avoid having this type of
>> initialization in the kernel. There is a whole additional kitchen
>> sink that could move into the kernel as well.
>
> Well, I'm going to have to disagree with your disagreement :-)
> The kernel should not assume things are properly initialized
> and rely on the boot rom to do such things. I have several
> reasons for this. One is that we are always pressed to make
> embedded systems boot more quickly, and taking time to
> initialize things in the boot rom just makes that a totally
> inflexible system design. We don't need to initialize things
> we don't use, or can postpone until later. Two, it makes
> us dependent upon a particular boot rom, or boot rom
> behavior, that not all boards may choose to support.
> Three, board designs may have external logic that requires
> a certain start up sequence or control register access
> that complicates the boot rom in it's ability to share
> code or implementation.
Well, I think there is a coupling that exists between whatever your
boot rom is and the kernel. If you are trying to optimize boot time
I'd say one thing you would want is to avoid multiple writing the
same configuration registers.
I dont have an issue if a fixed function board decides to do these
things in their kernel init instead of their boot rom. I however,
don't want thousand and one config options to support all the various
ways one can configure the Freescale board.
> There are more, but I think you see the trend. In my
> years of doing this kind of development, you can't
> assume a boot rom is going to do much more than initialize
> memory and load the kernel. I prefer the flexibility
> to be in the kernel, and not in the boot rom, because it
> is so much easier to develop and control.
- kumar
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-17 22:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <71D808D5-8227-4B0D-AF41-FADFC4B12463@kernel.crashing.org>
On Jul 17, 2006, at 5:39 PM, Kumar Gala wrote:
> Well, I think there is a coupling that exists between whatever your
> boot rom is and the kernel.
There shouldn't be, I've always said that, but Freescale
seems to want to insist on it :-) The problem is people
creating this evaluation/demo boards seem to think
they are workstations, which they are not. There is
such a minimal amount of information needed to
actually get a system from the boot rom to the kernel
that I don't understand why we are complicating this
process for embedded systems.
Here is my product development experience. People
buy these evaluation boards to test a few of the features
they need for a product. These boards try to be everything
to everyone, but in reality have never done what someone
has wanted very well. Products developed using Linux
and many different boot roms are very focused on a particular
set of features. Their requirements are nothing like that of
an evaluation board, and all of these cute workstation
features we are pushing into these evaluation board ports
do nothing to help get these products customized for market.
> If you are trying to optimize boot time I'd say one thing you would
> want is to avoid multiple writing the same configuration registers.
That's what I said. Just do it in Linux when the feature is
started, either as a built-in driver or loadable module. No
need to do this in a boot rom if there isn't any need for it.
> I dont have an issue if a fixed function board decides to do these
> things in their kernel init instead of their boot rom. I however,
> don't want thousand and one config options to support all the
> various ways one can configure the Freescale board.
I don't understand how configuration options fit into this
discussion. In this particular discussion, if you have selected
the USB option, then include the proper initialization code
in the kernel for the board. No additional options needed.
Thanks.
-- Dan
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: Sylvain Munaut @ 2006-07-17 22:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded
In-Reply-To: <1151710395.27137.7.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>> But anyway, it's mainly internal cleanup and adapting drivers
>> from the public version on my git tree to this newest/cleaner
>> version is a 15 min work ;)
>>
>
> Any reason why you aren't regulary submitting those patches for upstream
> inclusion ?
>
Yes. What's in there and not in main streams adds quite a lot to
arch/ppc ... So
MPC5200 should be adapted to arch/powerpc first and then those changes.
And since
no-one did that yet and I haven't done it yet either ... (I must admit I
had a quick look
and I didn't understand much on how to do the change ...)
Sylvain
PS: Sorry for the lag (like 15 days...) you know email
problem/appartement change/vacation/... the usual ;)
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Andi Kleen @ 2006-07-17 22:27 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
On Monday 17 July 2006 18:17, Horms wrote:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
>
> It was pointed out to me by Andi Kleen that if an oops has occured
> in interrupt context, then calling sleep() in the oops path will only cause
> a panic, and that it would be really better for it not to be in the path at
> all.
>
> This patch removes the ssleep() call and reworks the console message
> accordinly. I have a slght concern that the resulting console message is
> too long, feedback welcome.
Keeping the delay might be actually useful so that you can see the panic
before system reboots when reboot on panic is enabled. I would just use a loop
of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
inbetween.
-Andi
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: David Brownell @ 2006-07-17 22:57 UTC (permalink / raw)
To: linux-usb-devel; +Cc: linuxppc-dev
In-Reply-To: <1153166894.4459.4.camel@basalt.austin.ibm.com>
On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote:
>
> Seems to me that it's far better to have init code in the kernel than
> firmware.
If there's a general Linux policy on the issue, I think that'd be it.
Plus, remember that boot firmware _can't_ always be changed/bugfixed;
sometimes it can, but not as a general rule.
- Dave
> For one example, look at the x86 video card init problem
> PowerPC Linux has. It's also far easier to fix/deploy Linux code than
> firmware code, as Li observed, and on top of that it's less work for
> non-UBoot firmwares in the future.
>
> -Hollis
>
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Horms @ 2006-07-17 23:10 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Russell King
In-Reply-To: <200607180027.51986.ak@suse.de>
On Tue, Jul 18, 2006 at 12:27:51AM +0200, Andi Kleen wrote:
> On Monday 17 July 2006 18:17, Horms wrote:
> > This patch is part of an effort to unify the panic_on_oops behaviour
> > across all architectures that implement it.
> >
> > It was pointed out to me by Andi Kleen that if an oops has occured
> > in interrupt context, then calling sleep() in the oops path will only cause
> > a panic, and that it would be really better for it not to be in the path at
> > all.
> >
> > This patch removes the ssleep() call and reworks the console message
> > accordinly. I have a slght concern that the resulting console message is
> > too long, feedback welcome.
>
> Keeping the delay might be actually useful so that you can see the panic
> before system reboots when reboot on panic is enabled. I would just use a loop
> of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
> inbetween.
Ok, I will look into making that happen. I agree that the pause is
quite useful.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Andrew Morton @ 2006-07-18 0:23 UTC (permalink / raw)
To: Horms
Cc: chris, tony.luck, linux-ia64, discuss, ak, linux-kernel,
linuxppc-dev, paulus, anton, rmk
In-Reply-To: <20060717231056.GC12463@verge.net.au>
On Mon, 17 Jul 2006 19:10:59 -0400
Horms <horms@verge.net.au> wrote:
> On Tue, Jul 18, 2006 at 12:27:51AM +0200, Andi Kleen wrote:
> > On Monday 17 July 2006 18:17, Horms wrote:
> > ...
> > Keeping the delay might be actually useful so that you can see the panic
> > before system reboots when reboot on panic is enabled. I would just use a loop
> > of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
> > inbetween.
>
> Ok, I will look into making that happen. I agree that the pause is
> quite useful.
It's kind-of already implemented, via pause_on_oops. Perhaps doing
something like
if (panic_on_oops)
pause_on_oops = max(pause_on_oops, 5*HZ);
would be sufficient.
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Chuck Ebbert @ 2006-07-18 1:22 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
Andi Kleen, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
On Mon, 17 Jul 2006 12:17:20 -0400, Horms wrote:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
>
> It was pointed out to me by Andi Kleen that if an oops has occured
> in interrupt context, then calling sleep() in the oops path will only cause
> a panic, and that it would be really better for it not to be in the path at
> all.
i386 already checks in_interrupt() and panics immediately:
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -442,11 +442,9 @@ #endif
===> if (in_interrupt())
===> panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
oops_exit();
do_exit(SIGSEGV);
}
--
Chuck
And did we tell you the name of the game, boy, we call it Riding the Gravy Train.
^ permalink raw reply
* reboot on PQ2FADS board.
From: Lei Sun @ 2006-07-18 3:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I have linux 2.4.30 runnning on this board, the "reboot -f"
command cause machine check and kernel ooops. The problem seems in
the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
the warm start address, I changed it to 0xFF800100, that's where the
u-boot's _start_warm lives, I have verified that address by typing "g
ff800100" in u-boot console, which cause the board reset.
I assume the m8260_gorom has been heavily tested for other
boards. I wonder if anyone got a PQ2FADS-VR board that has the similar
problem? I am not familar with the assembly code for PPC. Any
suggestions?
Thanks
lei
^ permalink raw reply
* RE: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-18 6:34 UTC (permalink / raw)
To: David Brownell, linux-usb-devel, linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <200607171557.50368.david-b@pacbell.net>
> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Tuesday, July 18, 2006 6:58 AM
> To: linux-usb-devel@lists.sourceforge.net
> Cc: Hollis Blanchard; Kumar Gala; linuxppc-dev@ozlabs.org; Li
Yang-r58472
> Subject: Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform
support
>=20
> On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote:
> >
> > Seems to me that it's far better to have init code in the kernel
than
> > firmware.
>=20
> If there's a general Linux policy on the issue, I think that'd be it.
Do we have a general policy for this now?
>=20
> Plus, remember that boot firmware _can't_ always be changed/bugfixed;
> sometimes it can, but not as a general rule.
>=20
> - Dave
>=20
>=20
> > For one example, look at the x86 video card init problem
> > PowerPC Linux has. It's also far easier to fix/deploy Linux code
than
> > firmware code, as Li observed, and on top of that it's less work for
> > non-UBoot firmwares in the future.
> >
> > -Hollis
> >
^ permalink raw reply
* RE: [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-18 7:40 UTC (permalink / raw)
To: Kumar Gala, Dan Malek; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <71D808D5-8227-4B0D-AF41-FADFC4B12463@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, July 18, 2006 5:39 AM
> To: Dan Malek
> Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org;
linux-usb-devel@lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
>=20
>=20
> On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
>=20
> >
> > On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
> >
> >> I disagree. You are coming from this from a board that does
> >> everything under the sun. I'd like to avoid having this type of
> >> initialization in the kernel. There is a whole additional kitchen
> >> sink that could move into the kernel as well.
> >
> > Well, I'm going to have to disagree with your disagreement :-)
> > The kernel should not assume things are properly initialized
> > and rely on the boot rom to do such things. I have several
> > reasons for this. One is that we are always pressed to make
> > embedded systems boot more quickly, and taking time to
> > initialize things in the boot rom just makes that a totally
> > inflexible system design. We don't need to initialize things
> > we don't use, or can postpone until later. Two, it makes
> > us dependent upon a particular boot rom, or boot rom
> > behavior, that not all boards may choose to support.
> > Three, board designs may have external logic that requires
> > a certain start up sequence or control register access
> > that complicates the boot rom in it's ability to share
> > code or implementation.
>=20
> Well, I think there is a coupling that exists between whatever your
> boot rom is and the kernel. If you are trying to optimize boot time
> I'd say one thing you would want is to avoid multiple writing the
> same configuration registers.
>=20
> I dont have an issue if a fixed function board decides to do these
> things in their kernel init instead of their boot rom. I however,
> don't want thousand and one config options to support all the various
> ways one can configure the Freescale board.
We won't have the thousand and one config options, making use of the
device
tree. So this is not a problem.
>=20
> > There are more, but I think you see the trend. In my
> > years of doing this kind of development, you can't
> > assume a boot rom is going to do much more than initialize
> > memory and load the kernel. I prefer the flexibility
> > to be in the kernel, and not in the boot rom, because it
> > is so much easier to develop and control.
>=20
> - kumar
^ 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