* booting linux-2.5-mpc52xx
From: ivica @ 2004-12-07 18:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
Hi!
I have a lite5200 "clone" board on which I successfully booted several
2.4 kernels.
-kernel from DENX ELDK 3.1
-kernel from DENX CVS
-metrowerks 2.4 kernel
The only problem was I couldn't get first two kernels to boot file
system over NFS.
Third one worked.
Looks like I will have to write support for RX-8025 RTC chip which is
I2C bus
interface-compliant. This will be my first attempt to write a kernel
driver so I'm
taking all the curves I can. And I'm in a hurry.(aren't we all :D )
While looking trough menuconfig of Sylvain's kernel tree I noticed a
chip from
Epson(8564) that is also a RTC based on I2C. I though I would take it as
a base
and change the code according to my specs. Also I like the nice
structure of 2.6
tree(I2C dir). It makes things much more clear for a first timer. But I
could be
wrong of course and implementing it with 2.4 could be easier.
Anyway, first I need to boot the 2.6 kernel. After countless menuconfigs
and compiles I'm still
stuck at the beginning. This is the point I get to:
-----------------------------------------------------------------------------------------------
=> bootm 200000
## Booting image at 00200000 ...
Image Name: Linux-2.6.10-rc2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 598930 Bytes = 584.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
----------------------------------------------------------------------------------------------------
I found out this are the last functions in arc/ppc/kernel/setup.c .
Where does the startup process go from here? What could be causing problems?
Any help would be greatly appreciated. I'm kind of stuck here.
I will attach my config file.
TIA,
Ivica
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 11188 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc2
# Tue Dec 7 19:06:28 2004
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
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
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Processor
#
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E500 is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
# CONFIG_CPU_FREQ is not set
CONFIG_FSL_OCP=y
CONFIG_PPC_STD_MMU=y
#
# Platform options
#
# CONFIG_PPC_MULTIPLATFORM is not set
# CONFIG_APUS is not set
# CONFIG_WILLOW is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE 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 is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
# CONFIG_SBC82xx is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_ADS8272 is not set
CONFIG_LITE5200=y
CONFIG_PPC_MPC52xx=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyS0 root=/dev/ram0 rw"
#
# Bus options
#
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_NAMES 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_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00800000
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
#
# 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_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_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
#
# Networking support
#
# CONFIG_NET is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
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=y
CONFIG_INPUT_EVBUG=y
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW 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
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_MPC52xx=y
CONFIG_SERIAL_MPC52xx_CONSOLE=y
CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=9600
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
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
CONFIG_I2C_MPC=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Misc devices
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
#
# Graphics support
#
# CONFIG_FB is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_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=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# 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
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
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 is not set
^ permalink raw reply
* [PATCH][EMAC] Add netpoll support
From: Matt Porter @ 2004-12-07 17:54 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-embedded
Add netpoll support to the EMAC driver.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== drivers/net/ibm_emac/ibm_emac_core.c 1.5 vs edited =====
--- 1.5/drivers/net/ibm_emac/ibm_emac_core.c 2004-12-03 00:25:48 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2004-12-07 10:06:23 -07:00
@@ -1700,6 +1700,15 @@
.rxde = &emac_rxde_dev,
};
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static int emac_netpoll(struct net_device *ndev)
+{
+ emac_rxeob_dev((void *)ndev, 0);
+ emac_txeob_dev((void *)ndev, 0);
+ return 0;
+}
+#endif
+
static int emac_init_device(struct ocp_device *ocpdev, struct ibm_ocp_mal *mal)
{
int deferred_init = 0;
@@ -1882,6 +1891,9 @@
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
if (emacdata->tah_idx >= 0)
ndev->features = NETIF_F_IP_CSUM | NETIF_F_SG;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = emac_netpoll;
+#endif
SET_MODULE_OWNER(ndev);
^ permalink raw reply
* [PATCH][EMAC] allow rx of the maximum sized VLAN tagged packets
From: Matt Porter @ 2004-12-07 17:52 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-embedded
Patch enables EMAC to receive maximum sized VLAN tagged packets.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== drivers/net/ibm_emac/ibm_emac.h 1.1 vs edited =====
--- 1.1/drivers/net/ibm_emac/ibm_emac.h 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac.h 2004-08-24 12:19:41 -07:00
@@ -98,7 +98,7 @@
#endif /* CONFIG_IBM_EMAC4 */
#define EMAC_M1_BASE (EMAC_M1_TX_FIFO_2K | \
EMAC_M1_APP | \
- EMAC_M1_TR)
+ EMAC_M1_TR | EMAC_M1_VLE)
/* Transmit Mode Register 0 */
#define EMAC_TMR0_GNP0 0x80000000
===== drivers/net/ibm_emac/ibm_emac_core.c 1.2 vs edited =====
--- 1.2/drivers/net/ibm_emac/ibm_emac_core.c 2004-06-04 08:50:36 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2004-08-24 12:18:27 -07:00
@@ -1335,6 +1335,9 @@
/* set frame gap */
out_be32(&emacp->em0ipgvr, CONFIG_IBM_EMAC_FGAP);
+
+ /* set VLAN Tag Protocol Identifier */
+ out_be32(&emacp->em0vtpid, 0x8100);
/* Init ring buffers */
emac_init_rings(fep->ndev);
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/dma-mapping.h macro patch
From: Christoph Hellwig @ 2004-12-07 15:03 UTC (permalink / raw)
To: Jason McMullan; +Cc: linuxppc-dev, linux-kernel, linuxppc-embedded
In-Reply-To: <20041207132031.GA23542@jmcmullan.timesys>
> +#define dma_cache_inv(_start,_size) do { (void)(_start); (void)(_size); } while (0)
this looks really horrible. What about turning these into inlines?
^ permalink raw reply
* Re: Second Attempt: Driver model usage on embedded processors
From: Dan Malek @ 2004-12-07 14:53 UTC (permalink / raw)
To: Kumar Gala
Cc: Linux/PPC Development, Embedded PPC Linux list, linux-arm-kernel,
Linux Kernel Development
In-Reply-To: <48C50EC3-480D-11D9-8A5A-000393DBC2E8@freescale.com>
On Dec 7, 2004, at 12:03 AM, Kumar Gala wrote:
> The intent was that I would use the platform_data pointer to pass
> board specific information to the driver. We would have board
> specific code which would fill in the information. The question I
> have is how to handle the device variant information which is really
> static?
Why don't you just use the feature_call() model like we currently
use for PowerPC on the PMac? Isolate those places in the driver
that need that information and call the function with a
selector/information
request (and varargs) to get it. This seems much more flexible
because we don't have to ensure the data structure contains all possible
information for all platforms, we don't have to invent a list of
functions to call that just return that information, and worse, have
to go back and update everyone when we realize we forgot a
piece of necessary information for one particular implementation.
There can be a standard list of information requests, it can easily
be extended for boards that may need to do some special processing
either to enable or retrieve such information, and the driver can
determine an appropriate course of action if the function returns a
status that it can't handle the request.
> The issue I've got with #2 is that some of these devices (and therefor
> drivers) will end up existing on various parts from Freescale that
> might have an ARM core or PPC core.
If the configuration options are truly static, we can do just like we
do today
with processor cores that share similar peripherals. Just #define
those things
that are constants and compile them into the driver. These could be
address
offsets, functional support (like RMON), and so on. There are examples
of these drivers that work fine today and could work even better with
minor
touch ups of the configuration options. You have already #define'd this
stuff in the board/processor configuration files. Why put them into a
static
data structure and then find some complex method to access it? These
are embedded systems, after all, that want to minimize overhead.
For those things that are dynamic or based upon a particular set of
drivers selected (either as loadable modules or static linked), you can
use the feature_call() (or whatever we want to name it). For example,
a driver could:
feature_call(SOC_FTR, Fast_Ethernet1, INIT_IO_PINS);
to configure the IO pins associated with the device, then it could:
feature_call(SOC_FTR, Fast_Ethernet1, GET_CLKS, &txclk, &rxclk);
to get the routing for the transmit and receive clocks, and finally:
feature_call(SOC_FTR, Fast_Ethernet1, GET_PHY_IRQ, &phy_irq);
to get the external interrupt number associated with the PHY.
If the feature_call() returns a status that the request couldn't be
processed,
the driver can choose a default course of action. This could be to
simply bail out with an error, or it could choose some common and
reasonable default configuration. In the case of a PHY interrupt,
it could simply enter a polled mode if an interrupt is not provided.
Using the call out function doesn't place any restrictions on the driver
data structure formats. The board can choose how it wishes to represent
the data, which it could fetch from flash, from a command line argument,
from some start up configuration, whatever it wishes. It can also
perform
any board specific operation necessary to enable/activate the
peripheral.
For example, as part of INIT_IO_PINS, it could also configure some board
control register if there is external routing of signals through a
logic device
or to enable power to the PHY. It also allows "extending" the driver if
some board/processor needs an additional set up or control that others
don't. The board/processors that don't need that function can simply
return from the call doing nothing, so no harm done (and requiring no
software updates to existing board ports), while this new
board/processor
gets the needed function call.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] include/asm-ppc/dma-mapping.h macro patch
From: Jason McMullan @ 2004-12-07 13:20 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded, linux-kernel
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Summary: [ppc] dma-mapping.h - Fix macro semantics
Description:
This patch makes the macros for dma_* semantically
equivalent to the functions they mask. For example,
dma_cache_inv(func_with_side_effects(), sizeof(foo))
will execure 'func_with_side_effects()' in the function
case, but would not execute it in the macro case.
This patch fixes this discrepancy.
Comment: More landmines like this may be all over the kernel.
Janitor project, anyone?
--- linux-2.6.9.old/include/asm-ppc/dma-mapping.h 2004-12-07 08:14:32.769502853 -0500
+++ linux-2.6.9/include/asm-ppc/dma-mapping.h 2004-12-07 08:14:02.777362775 -0500
@@ -36,22 +36,22 @@
* Cache coherent cores.
*/
-#define dma_cache_inv(_start,_size) do { } while (0)
-#define dma_cache_wback(_start,_size) do { } while (0)
-#define dma_cache_wback_inv(_start,_size) do { } while (0)
-
-#define __dma_alloc_coherent(gfp, size, handle) NULL
-#define __dma_free_coherent(size, addr) do { } while (0)
-#define __dma_sync(addr, size, rw) do { } while (0)
-#define __dma_sync_page(pg, off, sz, rw) do { } while (0)
+#define dma_cache_inv(_start,_size) do { (void)(_start); (void)(_size); } while (0)
+#define dma_cache_wback(_start,_size) do { (void)(_start); (void)(_size); } while (0)
+#define dma_cache_wback_inv(_start,_size) do { (void)(_start); (void)(_size); } while (0)
+
+#define __dma_alloc_coherent(gfp, size, handle) ((void)(gfp),(void)(size),(void)(handle),NULL)
+#define __dma_free_coherent(size, addr) do { (void)(size); (void)(addr); } while (0)
+#define __dma_sync(addr, size, rw) do { (void)(addr); (void)(size); (void)(rw); } while (0)
+#define __dma_sync_page(pg, off, sz, rw) do { (void)(pg); (void)(off); (void)(sz); (void)(rw); } while (0)
#endif /* ! CONFIG_NOT_COHERENT_CACHE */
-#define dma_supported(dev, mask) (1)
+#define dma_supported(dev, mask) ((void)(dev), (void)(mask), 1)
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!dev->dma_mask || !dma_supported(dev, mask))
+ if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
*dev->dma_mask = dma_mask;
@@ -121,7 +121,7 @@
}
/* We do nothing. */
-#define dma_unmap_page(dev, handle, size, dir) do { } while (0)
+#define dma_unmap_page(dev, handle, size, dir) do { (void)(dev); (void)(handle); (void)(size); (void)(dir); } while (0)
static inline int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
@@ -141,7 +141,7 @@
}
/* We don't do anything here. */
-#define dma_unmap_sg(dev, sg, nents, dir) do { } while (0)
+#define dma_unmap_sg(dev, sg, nents, dir) do { (void)(dev); (void)(sg); (void)(nents); (void)(dir); } while (0)
static inline void
dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
@@ -190,9 +190,9 @@
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
#ifdef CONFIG_NOT_COHERENT_CACHE
-#define dma_is_consistent(d) (0)
+#define dma_is_consistent(d) ((void)(d), 0)
#else
-#define dma_is_consistent(d) (1)
+#define dma_is_consistent(d) ((void)(d), 1)
#endif
static inline int dma_get_cache_alignment(void)
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
^ permalink raw reply
* Re: Second Attempt: Driver model usage on embedded processors
From: McMullan, Jason @ 2004-12-07 12:02 UTC (permalink / raw)
To: Kumar Gala
Cc: Linux/PPC Development, Embedded PPC Linux list,
Linux Kernel Development, linux-arm-kernel
In-Reply-To: <48C50EC3-480D-11D9-8A5A-000393DBC2E8@freescale.com>
On Mon, 2004-12-06 at 23:03 -0600, Kumar Gala wrote:
> The intent was that I would use the platform_data pointer to pass =
board=20
> specific information to the driver. We would have board specific code =
> which would fill in the information. The question I have is how to=20
> handle the device variant information which is really static?
I use a 'struct device_ethernet_data' in my MPC85xx platform-device
patches at http://www.evillabs.net/~gus/patches
That seems to work well, and we could move it from
include/asm-ppc/device-ethernet.h to include/linux/device-ethernet.h to
make it more arch-independant. That covers MAC addrs and phy locations.
As for PHY IRQ, that's a thornier issue. For now, I put that in the
ethernet device's resource list.
--=20
Jason McMullan <jason.mcmullan@timesys.com>
^ permalink raw reply
* What's the problem could be?
From: Sam Song @ 2004-12-07 11:36 UTC (permalink / raw)
To: Embedded PPC Linux list
Hi, all
An system application crash running on 2.4.18 was
happened on my custom 8xx board every now and then,
especially recently. Yeah, the probelm is becoming
more and more obvious. Personally, I deem it as an
default of application software because there are some
complicated application softwares like GUI and a
browser. But I also suspect that my custom keyboard
did it because there were about 70-80 PCMCIA
interrupts created once I hit just one key. I used
PCMCIA interrupt to accept the rubber keyboard input.
Still one thing, for development convenience, I just
use one SDRAM init setting and process for bus freq.
at 24MHZ/48MHZ. Which one could be the killer? Any
other possibility?
Thanks in advance!
=====
Best regards,
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* Second Attempt: Driver model usage on embedded processors
From: Kumar Gala @ 2004-12-07 5:03 UTC (permalink / raw)
To: Linux Kernel Development
Cc: Linux/PPC Development, linux-arm-kernel, Embedded PPC Linux list
I'm looking at moving support for PowerPC System on a Chip devices to
using the 2.6 driver model. I think may issues may apply to any system
on a chip device. I have a few issues, however one is holding up
progress. I think the best way to ask my question is with an example:
On a given chip we have an ethernet controller that is directly
available to the CPU. The ideas is that this device would be a
platform device. The issue is that this controller may have several
minor variations on the same chip or between chip models. We have
written a single driver to handle these variants. Variants may
include, support for Gigabit, support for RMON, support for interrupt
coalescing. Additionally, the driver needs to be based some
information that is board specific. Such as which PHY, at what PHY id,
does the PHY have an interrupt, etc.
The intent was that I would use the platform_data pointer to pass board
specific information to the driver. We would have board specific code
which would fill in the information. The question I have is how to
handle the device variant information which is really static?
Possible solutions I've come up with:
1. use a struct resource for the flags that describe ethernet variants
- Add a new resource type
- steal a bus specific resource type
2. create a super structure that platform_data points to which contains
the flags and a board_data pointer
The issue I've got with #2 is that some of these devices (and therefor
drivers) will end up existing on various parts from Freescale that
might have an ARM core or PPC core. I'd prefer a solution that did not
impose restrictions on how an arch does things.
I a few other questions about headers and were to put things, but
that's secondary.
- kumar
^ permalink raw reply
* Re: 440GX MMU
From: Matt Porter @ 2004-12-06 20:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: Barbier, Renaud (GE Infrastructure), linuxppc-embedded
In-Reply-To: <35B36824-47B6-11D9-8BFE-000393DBC2E8@freescale.com>
On Mon, Dec 06, 2004 at 12:39:49PM -0600, Kumar Gala wrote:
> The TS provides an additional bit of address space on Book-E processors
> (440, e500, etc). An exception automatically clears the MSR[IS, DS]
> fields which are used to compare against the TLB's TS field.
>
> It was the case at one point in time (may still be) that on 440, the
> interrupt context was TS = 0, everything else was TS = 1. Matt was
> going to (or may have) changed it so everything is TS = 0 so we could
> save a few TLB entries.
It's changed in 2.6 (all AS=0), in 2.4 I never got around to finishing
the update to the MMU handling. Since then, 2.6 has gone way beyond
2.4 in features/fixes so I don't intend to do anything more with
2.4. Patches are welcome for linuxppc-2.4, though.
-Matt
^ permalink raw reply
* Re: [PATCH] linux 2.6 not^Wnow working with PReP (ppc32)
From: Christian @ 2004-12-06 19:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20041206184921.GD7153@smtp.west.cox.net>
On Mon, December 6, 2004 19:49, Tom Rini said:
>
> This doesn't cause anything bad to happen on mine (and it shouldn't,
> being a Blackhawk and all :)), so I'll send this on. Thanks.
oh, fine! sounds good!
thanks,
Christian.
--
make bzImage, not war
^ permalink raw reply
* [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Tom Rini @ 2004-12-06 18:54 UTC (permalink / raw)
To: Linus Torvalds, Kernel Mailing List, linuxppc-dev
Cc: Sven Hartge, Meelis Roos, Christian Kujau
The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
incorrect, but this breakage wasn't exposed until 2.5, and finally fixed
until recently by Sebastian Heutling <sheutlin@gmx.de>.
Signed-off-by: Christian Kujau <evil@g-house.de>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.32/arch/ppc/platforms/prep_pci.c 2004-10-12 14:29:11 -07:00
+++ edited/arch/ppc/platforms/prep_pci.c 2004-12-06 09:20:52 -07:00
@@ -49,10 +49,10 @@
0, /* Slot 1 - unused */
5, /* Slot 2 - SCSI - NCR825A */
0, /* Slot 3 - unused */
- 1, /* Slot 4 - Ethernet - DEC2114x */
+ 3, /* Slot 4 - Ethernet - DEC2114x */
0, /* Slot 5 - unused */
- 3, /* Slot 6 - PCI Card slot #1 */
- 4, /* Slot 7 - PCI Card slot #2 */
+ 2, /* Slot 6 - PCI Card slot #1 */
+ 3, /* Slot 7 - PCI Card slot #2 */
5, /* Slot 8 - PCI Card slot #3 */
5, /* Slot 9 - PCI Bridge */
/* added here in case we ever support PCI bridges */
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] linux 2.6 not^Wnow working with PReP (ppc32)
From: Tom Rini @ 2004-12-06 18:49 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, Sven Hartge, linux-kernel
In-Reply-To: <41B36845.4080004@g-house.de>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Sun, Dec 05, 2004 at 08:57:57PM +0100, Christian Kujau wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> whoops! a bit too early, i had to change 3 lines, not one.
>
>
> Signed-off-by: Christian Kujau <evil@g-house.de>
>
>
> (new patch attached; credits should go to Sebastian Heutling aka
> sheutlin@gmx.de)
This doesn't cause anything bad to happen on mine (and it shouldn't,
being a Blackhawk and all :)), so I'll send this on. Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 440GX MMU
From: Kumar Gala @ 2004-12-06 18:39 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure); +Cc: linuxppc-embedded
In-Reply-To: <45ABD2373C33C4459D42B40EC4F346F204912B38@FTWMLVEM03.e2k.ad.ge.com>
The TS provides an additional bit of address space on Book-E processors
(440, e500, etc). An exception automatically clears the MSR[IS, DS]
fields which are used to compare against the TLB's TS field.
It was the case at one point in time (may still be) that on 440, the
interrupt context was TS = 0, everything else was TS = 1. Matt was
going to (or may have) changed it so everything is TS = 0 so we could
save a few TLB entries.
- kumar
On Dec 6, 2004, at 12:23 PM, Barbier, Renaud ((GE Infrastructure))
wrote:
>
>
> can someone explain to me the purpose of the TS bit in the 440GX TLBs?
>
> In the 440GX BSP, what is the point to map twice memory offset 0 (once
> with TS=0 and once with TS=1).
> Is that for context switch?
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 440GX MMU
From: Barbier, Renaud (GE Infrastructure) @ 2004-12-06 18:23 UTC (permalink / raw)
To: linuxppc-embedded
can someone explain to me the purpose of the TS bit in the 440GX TLBs?
In the 440GX BSP, what is the point to map twice memory offset 0 (once =
with TS=3D0 and once with TS=3D1).
Is that for context switch?
^ permalink raw reply
* Re: [FYI] linux 2.6 still not^Wnow working with PReP (ppc32)
From: Christian Kujau @ 2004-12-06 4:15 UTC (permalink / raw)
To: sheutlin; +Cc: linuxppc-dev, Sven Hartge
In-Reply-To: <1102297574.7138.17.camel@weizen.left.earth>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Heutling schrieb:
>
> Pure trial and error in the first time. When realising that something is
> wrong with the assigned interrupts (looking at the kernel output) we
> tried to set the ones that were working in a 2.4 kernel. When the
> machine finally booted a "lspci" showed that the slot number changed.
lspci, sounds easy ;-)
but i never would have looked at slot numbering....
>
> Is it that onboard network tulip kind of thingy? Do you have some other
> PCI cards installed?
the card is onboard. since i had some issues with this card in early 2.4
kernels too, i used to have another NIC. in fact, very often i only
compiled with 3c59x enabled - OF cared about the onboard NIC (tulip) and
once the kernel is loaded, the tulip is not needed any more and 3c59x
takes over.
http://nerdbynature.de/bits/sheep/2.6.10-rc3/ has some details.
> I used to have an extra symbios logic scsi-host-adapter installed.
> On high network load and loading/writing to a HD (using onboard scsi), I
> noticed a lot of problems: either the scsi-host-adapter lost the
> interrupt or the network driver lost some packets or both. After having
> removed the extra scsi-host-adapter it works fine now.
hm, when i had 3 scsi-disks in this machine (fine IBM ones, hmmmm..) i
only used the on-board scsi-bus. there was no other scsi-host-adapter
inside, but i noticed the very same problems: upon massive i/o, the
machine got stuck for 30sec, sometimes longer, load increased to 30..40 or
so, then the machine got back, with a syslog full of scsi errors.
it's still so incredible that a 3-liner solved this issue. the bug-report
was opened over a year ago...
thanks again,
Christian.
- --
BOFH excuse #13:
we're waiting for [the phone company] to fix that line
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs9zX+A7rjkF8z0wRArwBAKDZ2ywiukQl/b/uPTG1/1jWHrIsxQCeIcKb
ltnS8407uSUM+J6jiJABxxc=
=Ts4X
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Sebastian Heutling @ 2004-12-06 1:46 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, Sven Hartge, linux-kernel
In-Reply-To: <41B34863.3090007@g-house.de>
On Sun, 2004-12-05 at 18:41 +0100, Christian Kujau wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sebastian Heutling schrieb:
> > You got the powerstack booting from scsi (reading and interpreting the
>
> yes, but now the disk is gone and i have to use nfsroot.
>
> > bug report). I had problems booting 2.6 kernels as well (never tested
> > any 2.5 kernels). It turned out that the pci slot numbering has changed
> > sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
> > After having set up the slot0...slot8 using the values of
> > slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
> > of the box), the machine booted a 2.6 kernel (2.6.8).
>
> boy! this *is* an early christmas present, for sure! how did you come to
> this conclusion? something *must* have changed in the pci setup after
:-)
Pure trial and error in the first time. When realising that something is
wrong with the assigned interrupts (looking at the kernel output) we
tried to set the ones that were working in a 2.4 kernel. When the
machine finally booted a "lspci" showed that the slot number changed.
> 2.5.30, because the problem did not go away when i used a different NIC
> driver. but i could not fiddle out the changeset to blame here, because i
> failed to compile many kernels > 2.5.30.
>
> changing one line in arch/ppc/platforms/prep_pci.c made my PReP booting a
> recent 2.6-BK, patch attached.
>
> it's booting now, "init=/bin/bash" is working, but i still can't ping to
> the outside world, which is still a bit strange, but i hope i can work it out.
Is it that onboard network tulip kind of thingy? Do you have some other
PCI cards installed?
I used to have an extra symbios logic scsi-host-adapter installed.
On high network load and loading/writing to a HD (using onboard scsi), I
noticed a lot of problems: either the scsi-host-adapter lost the
interrupt or the network driver lost some packets or both. After having
removed the extra scsi-host-adapter it works fine now.
>
> tausend dank (really),
You are welcome!
Sebastian
^ permalink raw reply
* [PATCH] linux 2.6 not^Wnow working with PReP (ppc32)
From: Christian Kujau @ 2004-12-05 19:57 UTC (permalink / raw)
To: sheutlin; +Cc: linuxppc-dev, Sven Hartge, linux-kernel
In-Reply-To: <1102207299.6778.16.camel@weizen.left.earth>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
whoops! a bit too early, i had to change 3 lines, not one.
Signed-off-by: Christian Kujau <evil@g-house.de>
(new patch attached; credits should go to Sebastian Heutling aka
sheutlin@gmx.de)
thanks,
Christian.
- --
BOFH excuse #304:
routing problems on the neural net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs2hE+A7rjkF8z0wRAi+3AJ42GZlqMZen6lqMwtyQSMbS61tkbwCeMNET
nKgGhTpgwAcCJJ0hWUKoFqg=
=xyi5
-----END PGP SIGNATURE-----
[-- Attachment #2: prep_pci_renumbered-2.6.10-rc3.patch --]
[-- Type: text/x-patch, Size: 793 bytes --]
--- linux-2.6-BK/arch/ppc/platforms/prep_pci.c 2004-12-05 20:46:33.000000000 +0100
+++ linux-2.6-BK/arch/ppc/platforms/prep_pci.c.edited 2004-12-05 20:45:55.000000000 +0100
@@ -49,10 +49,10 @@
0, /* Slot 1 - unused */
5, /* Slot 2 - SCSI - NCR825A */
0, /* Slot 3 - unused */
- 1, /* Slot 4 - Ethernet - DEC2114x */
+ 3, /* Slot 4 - Ethernet - DEC2114x */
0, /* Slot 5 - unused */
- 3, /* Slot 6 - PCI Card slot #1 */
- 4, /* Slot 7 - PCI Card slot #2 */
+ 2, /* Slot 6 - PCI Card slot #1 */
+ 3, /* Slot 7 - PCI Card slot #2 */
5, /* Slot 8 - PCI Card slot #3 */
5, /* Slot 9 - PCI Bridge */
/* added here in case we ever support PCI bridges */
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Christian Kujau @ 2004-12-05 17:41 UTC (permalink / raw)
To: sheutlin; +Cc: linuxppc-dev, Sven Hartge, linux-kernel
In-Reply-To: <1102207299.6778.16.camel@weizen.left.earth>
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Heutling schrieb:
> You got the powerstack booting from scsi (reading and interpreting the
yes, but now the disk is gone and i have to use nfsroot.
> bug report). I had problems booting 2.6 kernels as well (never tested
> any 2.5 kernels). It turned out that the pci slot numbering has changed
> sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
> After having set up the slot0...slot8 using the values of
> slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
> of the box), the machine booted a 2.6 kernel (2.6.8).
boy! this *is* an early christmas present, for sure! how did you come to
this conclusion? something *must* have changed in the pci setup after
2.5.30, because the problem did not go away when i used a different NIC
driver. but i could not fiddle out the changeset to blame here, because i
failed to compile many kernels > 2.5.30.
changing one line in arch/ppc/platforms/prep_pci.c made my PReP booting a
recent 2.6-BK, patch attached.
it's booting now, "init=/bin/bash" is working, but i still can't ping to
the outside world, which is still a bit strange, but i hope i can work it out.
tausend dank (really),
Christian.
- --
BOFH excuse #304:
routing problems on the neural net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBs0hj+A7rjkF8z0wRAo3RAKDF+QYA6cosLH+kWtiAmiWtRzlQkQCeKcpx
FXOiNRfl9/vOynE8d4hDJJg=
=sKOm
-----END PGP SIGNATURE-----
[-- Attachment #2: prep_pci_2.6.10-rc2.patch --]
[-- Type: text/x-patch, Size: 499 bytes --]
--- linux-2.5-PPC-BK/arch/ppc/platforms/prep_pci.c 2004-12-05 18:20:04.000000000 +0100
+++ linux-2.5-PPC-BK/arch/ppc/platforms/prep_pci.c.edited 2004-12-05 18:21:33.000000000 +0100
@@ -61,7 +61,7 @@
0, /* Slot 11 - unused */
5, /* Slot 12 - SCSI - NCR825A */
0, /* Slot 13 - unused */
- 3, /* Slot 14 - enet */
+ 1, /* Slot 14 - enet */
0, /* Slot 15 - unused */
2, /* Slot 16 - unused */
3, /* Slot 17 - unused */
^ permalink raw reply
* TEST: Sleep patch #7
From: Benjamin Herrenschmidt @ 2004-12-05 10:34 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list,
gentoo-ppc-user, fedora-ppc
(As usual, I'm cross posting several lists, please don't reply to all of them,
and CC me as I'm not subscribed to all of them neither)
Ok, here's the 7th version of the sleep patch for ATI based albooks &
iBook G4. Other machine users, please test too as it may cause
regressions (or improvements) as well.
The cache flush problem happens to not be completely fixed yet :( There is
something going on that I don't completely explain yet, might be related to
an errata of some CPU revisions. This version of the patch adds a load/flush
loop before the L2 HW flush on the 745x that appear to make the thing stable
on the machines I've tested on. It's a good enough workaround for now, I'm
working with freescale to find out what's really going on though.
http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff
Ben.
^ permalink raw reply
* TEST: Sleep patch #6
From: Benjamin Herrenschmidt @ 2004-12-05 10:25 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list,
gentoo-ppc-user, fedora-ppc
(As usual, I'm cross posting several lists, please don't reply to all of them,
and CC me as I'm not subscribed to all of them neither)
Ok, here's the 7th version of the sleep patch for ATI based albooks &
iBook G4. Other machine users, please test too as it may cause
regressions (or improvements) as well.
The cache flush problem happens to not be completely fixed yet :( There is
something going on that I don't completely explain yet, might be related to
an errata of some CPU revisions. This version of the patch adds a load/flush
loop before the L2 HW flush on the 745x that appear to make the thing stable
on the machines I've tested on. It's a good enough workaround for now, I'm
working with freescale to find out what's really going on though.
http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff
Ben.
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Sebastian Heutling @ 2004-12-05 0:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <41B23DF2.4010303@g-house.de>
You got the powerstack booting from scsi (reading and interpreting the
bug report). I had problems booting 2.6 kernels as well (never tested
any 2.5 kernels). It turned out that the pci slot numbering has changed
sometime and this wasn't reflected in arch/ppc/platforms/prep_pci.c.
After having set up the slot0...slot8 using the values of
slot10...slot18 (except for slot1 which got value 4 so IDE is usable out
of the box), the machine booted a 2.6 kernel (2.6.8).
Sebastian
On Sat, 2004-12-04 at 23:45 +0100, Christian Kujau wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> upon receiving some calls about the status on this issue, i decided to
> update http://bugme.osdl.org/show_bug.cgi?id=1494 , which i reported a
> while back. yes, this is "just a PReP" and i am fully aware that PReP is
> not used in recent setups any more and i too will not my PReP for HPC
> applications. but perhaps someone has an idea about what's goin on here.
>
> the bugreport should give you th full details, in short: linux 2.5.30 is
> the last working kernel for ppc32/PReP with networking enabled.
> (net)booting a recent 2.6 kernels spit out lots of these:
>
> (with tulip NIC)
> Dec 3 23:56:39 192.168.10.9 irq 9: nobody cared!
> Dec 3 23:56:39 192.168.10.9 Call trace:
> Dec 3 23:56:39 192.168.10.9 [c002e99c] __report_bad_irq+0x34/0xac
> Dec 3 23:56:39 192.168.10.9 [c002eb00] note_interrupt+0xd0/0x104
> Dec 3 23:56:39 192.168.10.9 [c002e480] __do_IRQ+0x174/0x184
> Dec 3 23:56:39 192.168.10.9 [c00053e0] do_IRQ+0x38/0x98
> Dec 3 23:56:39 192.168.10.9 [c00044cc] ret_from_except+0x0/0x14
> Dec 3 23:56:39 192.168.10.9 [c002e748] setup_irq+0xd8/0x138
> Dec 3 23:56:39 192.168.10.9 [c002e938] request_irq+0x90/0xc0
> Dec 3 23:56:39 192.168.10.9 [c0103504] tulip_open+0x30/0xb6c
> Dec 3 23:56:39 192.168.10.9 [c0117274] dev_open+0xb0/0xd8
> Dec 3 23:56:39 192.168.10.9 [c0118a7c] dev_change_flags+0x6c/0x144
> Dec 3 23:56:39 192.168.10.9 [c0123db4] netpoll_setup+0x1c4/0x364
> Dec 3 23:56:39 192.168.10.9 [c0106fe0] init_netconsole+0x3c/0x94
> Dec 3 23:56:39 192.168.10.9 [c0003a64] init+0xb8/0x230
> Dec 3 23:56:39 192.168.10.9 [c0006524] kernel_thread+0x44/0x60
> Dec 3 23:56:39 192.168.10.9 handlers:
> Dec 3 23:56:39 192.168.10.9 [<c010101c>] (tulip_interrupt+0x0/0xd3c)
> Dec 3 23:56:39 192.168.10.9 Disabling IRQ #9
>
> (with 3c59x NIC)
> 192.168.10.9 NETDEV WATCHDOG: eth0: transmit timed out
> 192.168.10.9 eth0: transmit timed out, tx_status 00 status e800.
> 192.168.10.9 diagnostics: net 0cc0 media 8802 dma 002000b3 fifo 0000
> 192.168.10.9 eth0: Interrupt posted but not delivered -- IRQ blocked by
> another device?
> 192.168.10.9 Flags; bus-master 1, dirty 67(3) current 68(4)
> 192.168.10.9 Transmit list 806fe480 vs. c06fe3e0.
> 192.168.10.9 0: @c06fe200 length 80000054 status 00000054
> 192.168.10.9 1: @c06fe2a0 length 8000005e status 0000005e
> 192.168.10.9 2: @c06fe340 length 80000064 status 00000064
> 192.168.10.9 3: @c06fe3e0 length 80000075 status 00000075
> 192.168.10.9 4: @c06fe480 length 8000005b status 0000005b
> 192.168.10.9 5: @c06fe520 length 80000051 status 00000051
> 192.168.10.9 6: @c06fe5c0 length 8000005a status 0000005a
> 192.168.10.9 7: @c06fe660 length 8000005a status 0000005a
> 192.168.10.9 8: @c06fe700 length 8000005a status 0000005a
> 192.168.10.9 9: @c06fe7a0 length 8000005a status 0000005a
> 192.168.10.9 10: @c06fe840 length 8000005a status 0000005a
> 192.168.10.9 11: @c06fe8e0 length 8000005a status 0000005a
> 192.168.10.9 12: @c06fe980 length 8000005a status 0000005a
> 192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
> 192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
> 192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
> 192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
> 192.168.10.9 15: @c06feb60 length 8000005a status 0000005a
>
> is it possible to use another irq for the network-device driver?
> Documentation/kernel-parameters.txt gives some options about other
> drivers, but i can't tell how to specify "use this irq" for tulip/3c59x.
>
> especially the "IRQ blocked by another device?" message makes me think,
> that manual irq config could help here. but maybe i'm wrong.
>
> the results posted on http://nerdbynature.de/bits/sheep/2.6.10-rc2/ are
> from current 2.6 kernels: the offical tree and the linuxppc25 tree was used.
>
> thank you for comments,
> Christian.
> - --
> BOFH excuse #441:
>
> Hash table has woodworm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBsj3y+A7rjkF8z0wRAldLAJ9QFTfr8UeOtXbnSCGWBVJr7IAAKgCgiHRV
> iB/ozetyCDIMSfAa+1MRxVc=
> =b5BK
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [FYI] linux 2.6 still not working with PReP (ppc32)
From: Christian Kujau @ 2004-12-04 22:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
upon receiving some calls about the status on this issue, i decided to
update http://bugme.osdl.org/show_bug.cgi?id=1494 , which i reported a
while back. yes, this is "just a PReP" and i am fully aware that PReP is
not used in recent setups any more and i too will not my PReP for HPC
applications. but perhaps someone has an idea about what's goin on here.
the bugreport should give you th full details, in short: linux 2.5.30 is
the last working kernel for ppc32/PReP with networking enabled.
(net)booting a recent 2.6 kernels spit out lots of these:
(with tulip NIC)
Dec 3 23:56:39 192.168.10.9 irq 9: nobody cared!
Dec 3 23:56:39 192.168.10.9 Call trace:
Dec 3 23:56:39 192.168.10.9 [c002e99c] __report_bad_irq+0x34/0xac
Dec 3 23:56:39 192.168.10.9 [c002eb00] note_interrupt+0xd0/0x104
Dec 3 23:56:39 192.168.10.9 [c002e480] __do_IRQ+0x174/0x184
Dec 3 23:56:39 192.168.10.9 [c00053e0] do_IRQ+0x38/0x98
Dec 3 23:56:39 192.168.10.9 [c00044cc] ret_from_except+0x0/0x14
Dec 3 23:56:39 192.168.10.9 [c002e748] setup_irq+0xd8/0x138
Dec 3 23:56:39 192.168.10.9 [c002e938] request_irq+0x90/0xc0
Dec 3 23:56:39 192.168.10.9 [c0103504] tulip_open+0x30/0xb6c
Dec 3 23:56:39 192.168.10.9 [c0117274] dev_open+0xb0/0xd8
Dec 3 23:56:39 192.168.10.9 [c0118a7c] dev_change_flags+0x6c/0x144
Dec 3 23:56:39 192.168.10.9 [c0123db4] netpoll_setup+0x1c4/0x364
Dec 3 23:56:39 192.168.10.9 [c0106fe0] init_netconsole+0x3c/0x94
Dec 3 23:56:39 192.168.10.9 [c0003a64] init+0xb8/0x230
Dec 3 23:56:39 192.168.10.9 [c0006524] kernel_thread+0x44/0x60
Dec 3 23:56:39 192.168.10.9 handlers:
Dec 3 23:56:39 192.168.10.9 [<c010101c>] (tulip_interrupt+0x0/0xd3c)
Dec 3 23:56:39 192.168.10.9 Disabling IRQ #9
(with 3c59x NIC)
192.168.10.9 NETDEV WATCHDOG: eth0: transmit timed out
192.168.10.9 eth0: transmit timed out, tx_status 00 status e800.
192.168.10.9 diagnostics: net 0cc0 media 8802 dma 002000b3 fifo 0000
192.168.10.9 eth0: Interrupt posted but not delivered -- IRQ blocked by
another device?
192.168.10.9 Flags; bus-master 1, dirty 67(3) current 68(4)
192.168.10.9 Transmit list 806fe480 vs. c06fe3e0.
192.168.10.9 0: @c06fe200 length 80000054 status 00000054
192.168.10.9 1: @c06fe2a0 length 8000005e status 0000005e
192.168.10.9 2: @c06fe340 length 80000064 status 00000064
192.168.10.9 3: @c06fe3e0 length 80000075 status 00000075
192.168.10.9 4: @c06fe480 length 8000005b status 0000005b
192.168.10.9 5: @c06fe520 length 80000051 status 00000051
192.168.10.9 6: @c06fe5c0 length 8000005a status 0000005a
192.168.10.9 7: @c06fe660 length 8000005a status 0000005a
192.168.10.9 8: @c06fe700 length 8000005a status 0000005a
192.168.10.9 9: @c06fe7a0 length 8000005a status 0000005a
192.168.10.9 10: @c06fe840 length 8000005a status 0000005a
192.168.10.9 11: @c06fe8e0 length 8000005a status 0000005a
192.168.10.9 12: @c06fe980 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 13: @c06fea20 length 8000005a status 0000005a
192.168.10.9 14: @c06feac0 length 8000005a status 0000005a
192.168.10.9 15: @c06feb60 length 8000005a status 0000005a
is it possible to use another irq for the network-device driver?
Documentation/kernel-parameters.txt gives some options about other
drivers, but i can't tell how to specify "use this irq" for tulip/3c59x.
especially the "IRQ blocked by another device?" message makes me think,
that manual irq config could help here. but maybe i'm wrong.
the results posted on http://nerdbynature.de/bits/sheep/2.6.10-rc2/ are
from current 2.6 kernels: the offical tree and the linuxppc25 tree was used.
thank you for comments,
Christian.
- --
BOFH excuse #441:
Hash table has woodworm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBsj3y+A7rjkF8z0wRAldLAJ9QFTfr8UeOtXbnSCGWBVJr7IAAKgCgiHRV
iB/ozetyCDIMSfAa+1MRxVc=
=b5BK
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: (Very) Simple question(s) compared to group topics
From: Jon Masters @ 2004-12-04 16:42 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <005201c4da13$2807f360$0301a8c0@chuck2>
On Sat, 4 Dec 2004 10:08:42 -0500, Mark Chambers <markc@mail.com> wrote:
> All settop box designs that
> I'm aware of have some kind of MPEG decode coprocessor
IBM have a reference board based on 4xx which does just this -
although the drivers are disputedly non-GPL (there's a campaign
website about that at this point).
Jon.
^ permalink raw reply
* Re: (Very) Simple question(s) compared to group topics
From: Mark Chambers @ 2004-12-04 15:08 UTC (permalink / raw)
To: Bora Þahin, linuxppc-embedded
In-Reply-To: <8316506505.20041204160411@ttnet.net.tr>
If you go by MIPS, it takes very approximately 1000MIPS to decode DVD
quality MPEG2.
I don't think floating point helps with MPEG2, not sure about MPEG4. You
also have to
think about memory bandwidth with an application like video. All settop box
designs that
I'm aware of have some kind of MPEG decode coprocessor, either a separate
chip or built
into the main processor (like ATI Xilleon).
Mark Chambers
wvcomputronics.com
----- Original Message -----
From: "Bora Þahin" <bora.sahin@ttnet.net.tr>
To: <linuxppc-embedded@ozlabs.org>
Sent: Saturday, December 04, 2004 9:04 AM
Subject: (Very) Simple question(s) compared to group topics
> Hi,
>
> I was subscribed to list a few days ago. I dont know this group is
eligible for my very simple or
> basic questions compared to list topics. In one side asm codes is
discussed like one jump command
> why not reach to symbol and the other side interrupt handling routines
is discussed like whether
> or not critical interrupt handling is used in 405 EP. Subsequently, my
simple question is to stay
> very basic. However if i get an answer(s) or redirections to correct
places, I can be very
> grateful.
>
> A bit summary about me...
>
> So far, let say until the last one week or a bit over, I havent done any
work out of x86 including
> any RISC cpu. I know inner workings of x86(asm) like segmentation,
paging, booting etc. not to be
> very detailed. Before, I have dealt with mem. mag. especially in the
means of mm initialization,
> booting, ...etc on the x86 imp. of the Linux kernel.
>
> The subject...
>
> PPC and 4xx series of it is absolutely new to me. We think to decode
"mpeg 4/level 5" coded films
> on the 4xx series of ppc if it is possible. I examined a bit these cpus.
4xx series go to 700/800
> MHZ clock freq but most of them dont contain floating point unit.(Only
one of them has fpu if my
> memory dont serve me. I cant say it is connected. If i understand the
doc correctly, you can
> connect a fpu to the system) This is just a point. I know clock freq is
not alone on the cpu
> performance. I would like to hear experianced users testimonals or
thought about decoding of mpeg
> performance of these cpus...
>
> --
> Bora Sahin
> borasahin.port5.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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