* MPC8560ADS config for Vanilla 2.6.10
From: Turconi Ennio Angelo @ 2005-05-20 11:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
I have had some trouble in finding out the right configuration of kernel 2.6.10 for MPC8560ADS.
The fact is that "mpc8560_ads_defconfig" is included only from 2.6.11 on.
The same default configuration can be used in 2.6.10, too, without any problem.
Anyway find attached a minimum (but with useful debugging option activated) config version for 2.6.10.
I couldn't understand why not including the "math emulation" option, the kernel "works only a little".
What I can see is that the kernel is running, but the bash (running) gives no output. Anyone can tell me why?
Thanks,
Ennio
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Turconi International.vcf --]
[-- Type: text/x-vcard; name="Turconi International.vcf", Size: 482 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Turconi;Ennio
FN:Ennio Turconi
ORG:ITALTEL S.p.A.;Business Unit Products - TPD GPMSMP
TITLE:Senior Fw Designer
TEL;WORK;VOICE:+39 02 4388 5710
TEL;WORK;FAX:+39 02 4388 8705
ADR;WORK:;;Loc. Castelletto C29/1;Settimo Mil. MI;;20019;Italy
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Loc. Castelletto C29/1=0D=0ASettimo Mil. MI 20019=0D=0AItaly
URL;WORK:http://www.italtel.com
EMAIL;PREF;INTERNET:Ennio.Turconi@italtel.it
REV:20050520T105253Z
END:VCARD
[-- Attachment #3: config_mpc8560ads_nonet --]
[-- Type: application/octet-stream, Size: 10488 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10
# Fri May 20 11:27:27 2005
#
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="GoGoGo"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT 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_ALL is not set
# 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=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
#
# Processor
#
# CONFIG_6xx is not set
# 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=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
# CONFIG_SPE is not set
CONFIG_MATH_EMULATION=y
# CONFIG_CPU_FREQ is not set
CONFIG_85xx=y
CONFIG_PPC_INDIRECT_PCI_BE=y
#
# Freescale 85xx options
#
# CONFIG_MPC8540_ADS is not set
# CONFIG_MPC8555_CDS is not set
CONFIG_MPC8560_ADS=y
# CONFIG_SBC8560 is not set
CONFIG_MPC8560=y
CONFIG_FSL_OCP=y
#
# Platform options
#
CONFIG_CPM2=y
# CONFIG_PC_KEYBOARD is not set
# 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 is not set
#
# Bus options
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_BOOT_LOAD=0x00800000
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER 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_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=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=180000
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 is not set
# 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 I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
# CONFIG_SERIO_SERPORT is not set
# 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_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SCC1=y
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
# CONFIG_SERIAL_CPM_SMC1 is not set
# CONFIG_SERIAL_CPM_SMC2 is not set
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=y
CONFIG_GEN_RTC_X=y
# 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 is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# 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_STUB 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_ADM1026 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
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR 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 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=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
# CONFIG_NLS is not set
#
# CPM2 Options
#
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
# 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_KGDB_CONSOLE is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
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
* Re: regarding kernel for montavista
From: Alex Zeffertt @ 2005-05-20 9:31 UTC (permalink / raw)
To: Gopala Krishnam Raju; +Cc: linuxppc-embedded
In-Reply-To: <83986B58C72FC447AAC98F916BAB6A5735D90B@postman.facetime.com>
> presently i am using x86 board.
>
Then you won't get much help from a linuxPPC (PowerPC) mailing list.
^ permalink raw reply
* Re: regarding kernel for montavista
From: Alex Zeffertt @ 2005-05-20 8:54 UTC (permalink / raw)
To: Gopala Krishnam Raju; +Cc: linuxppc-embedded
In-Reply-To: <83986B58C72FC447AAC98F916BAB6A5735D90A@postman.facetime.com>
You haven't said a lot of things.
1. What board are you using (and how did you create .config)
2. What was the last thing the kernel said (i.e. where did it crash)
3. Did it oops? If so where did the oops say it crashed
(read man ksymoops; generate output; post it to the list)
Alex
On Fri, 20 May 2005 09:55:57 +0530
"Gopala Krishnam Raju" <graju@facetime.com> wrote:
> hello
>
> 1. I have compiled the montavista kernel
>
> 2. I have done made the make dep
>
> 3. I have done make install
>
> 4. I have done makeinitrd-pxe also
>
> Every thing went well but when i boot this on the target it is giving
> the kernel panic error. I tried with enforcing=0 also then also the
> problem is not solved.
>
> please help me out
>
> Thanks in advance
>
> Regards
>
> GGKRAJU
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Benjamin Herrenschmidt @ 2005-05-20 7:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17037.32285.607543.859030@cargo.ozlabs.ibm.com>
On Fri, 2005-05-20 at 16:05 +1000, Paul Mackerras wrote:
> Here is a revised version of my patch to set the cpu type explicitly
> for gcc when compiling the kernel. Setting the cpu type is a good
> idea in any case, and particularly if you have a biarch gcc. This
> sets the type for all of the ppc cpu families we support.
>
> Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
> and 85xx respectively? I used -mcpu=power4 rather than -mcpu=970
> because the former works with gcc-3.6.6 as in debian and the latter
> doesn't. Unfortunately -mcpu=440 doesn't work either in gcc 3.3,
> though it does in gcc 3.4 (as does -mcpu=970).
The problem is the same as ppc64 isn't it ?, -maltivec doesn't work with
-mcpu=power4 on gcc 3.4 does it ? That would mean no RAID6...
Ben.
^ permalink raw reply
* [PATCH] ppc32: remove unused computation
From: Paul Mackerras @ 2005-05-20 7:15 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
We are computing phys in the code below and never using. This patch
takes out the redundant computation.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/syslib/open_pic.c pmac-2.5/arch/ppc/syslib/open_pic.c
--- linux-2.6/arch/ppc/syslib/open_pic.c 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/syslib/open_pic.c 2005-04-26 20:34:39.000000000 +1000
@@ -557,12 +557,10 @@
*/
void openpic_cause_IPI(u_int ipi, cpumask_t cpumask)
{
- cpumask_t phys;
DECL_THIS_CPU;
CHECK_THIS_CPU;
check_arg_ipi(ipi);
- phys = physmask(cpumask);
openpic_write(&OpenPIC->THIS_CPU.IPI_Dispatch(ipi),
cpus_addr(physmask(cpumask))[0]);
}
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Wolfgang Denk @ 2005-05-20 6:59 UTC (permalink / raw)
To: Hollis Blanchard
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
In-Reply-To: <6fcc07be88e5091ac1428e9bbde6d92f@penguinppc.org>
In message <6fcc07be88e5091ac1428e9bbde6d92f@penguinppc.org> you wrote:
>
> > Maybe you want to post the RFC to lkml, or at least to the
> > linux-arm-kernel and linux-mips mailing lists?
>
> As you observe, having multiple incompatible communication mechanisms
> is an issue of u-boot code maintenance. Since you are the most affected
No, it's vice versa. U-Boot has always been just implementing what
the kernel does. There are many other boot loaders around that all
have to adhere to the interface(s) imposed on them by the kernel.
> In the meantime, it sounds like this device tree stuff solves ppc64's
> problem in a way the maintainers are happy with, so it's hard to ask
> them to come up with a solution to a problem they don't have.
Well, actually nobody has problems: the ARM and MIPS folks have
working solutions, too. The next architecture will implement yet
another way of passing information to the kernel, implement it and
state that they will not accept any other solution, and so on.
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
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
^ permalink raw reply
* [PATCH] ppc32: don't call progress functions after boot
From: Paul Mackerras @ 2005-05-20 6:57 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
On ppc32, the platform code can supply a "progress" function that is
used to show progress through the boot. These functions are usually
in an init section and so can't be called after the init pages are
freed. Now that the cpu bringup code can be called after the system
is booted (for hotplug cpu) we can get the situation where the
progress function can be called after boot. The simple fix is to set
the progress function pointer to NULL when the init pages are freed,
and that is what this patch does (note that all callers already check
whether the function pointer is NULL before trying to call it).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/mm/init.c pmac-2.5/arch/ppc/mm/init.c
--- linux-2.6/arch/ppc/mm/init.c 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/mm/init.c 2005-04-26 20:34:00.000000000 +1000
@@ -179,6 +179,7 @@
if (!have_of)
FREESEC(openfirmware);
printk("\n");
+ ppc_md.progress = NULL;
#undef FREESEC
}
^ permalink raw reply
* [PATCH] ppc32: Fix __copy_tofrom_user return value
From: Paul Mackerras @ 2005-05-20 6:50 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
Recently the __copy_tofrom_user routine was modified to avoid doing
prefetches past the end of the source array. However, in doing so we
introduced a bug in that it now returns the wrong value for the number
of bytes not copied when a fault is encountered. This fixes it to
return the correct number.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/lib/string.S pmac-2.5/arch/ppc/lib/string.S
--- linux-2.6/arch/ppc/lib/string.S 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/lib/string.S 2005-04-26 20:33:39.000000000 +1000
@@ -446,6 +446,7 @@
#ifdef CONFIG_8xx
/* Don't use prefetch on 8xx */
mtctr r0
+ li r0,0
53: COPY_16_BYTES_WITHEX(0)
bdnz 53b
@@ -564,7 +565,9 @@
/* or write fault in cacheline loop */
105: li r9,1
92: li r3,LG_CACHELINE_BYTES
- b 99f
+ mfctr r8
+ add r0,r0,r8
+ b 106f
/* read fault in final word loop */
108: li r9,0
b 93f
@@ -585,7 +588,7 @@
* r5 + (ctr << r3), and r9 is 0 for read or 1 for write.
*/
99: mfctr r0
- slw r3,r0,r3
+106: slw r3,r0,r3
add. r3,r3,r5
beq 120f /* shouldn't happen */
cmpwi 0,r9,0
^ permalink raw reply
* [PATCH] ppx32: Fix uninitialized variable in set_preferred_console
From: Paul Mackerras @ 2005-05-20 6:45 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
This patch fixes an uninitialized variable warning in
arch/ppc/kernel/setup.c, and this time gcc is actually right, there is
a path that could result in offset being uninitialized. Zero is a
sane default in this instance.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/kernel/setup.c pmac-2.5/arch/ppc/kernel/setup.c
--- linux-2.6/arch/ppc/kernel/setup.c 2005-05-18 10:53:54.000000000 +1000
+++ pmac-2.5/arch/ppc/kernel/setup.c 2005-05-18 14:11:33.000000000 +1000
@@ -499,7 +499,7 @@
{
struct device_node *prom_stdout;
char *name;
- int offset;
+ int offset = 0;
if (of_stdout_device == NULL)
return -ENODEV;
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Stefan Nickl @ 2005-05-20 6:44 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
In-Reply-To: <20050519231446.29487C1512@atlas.denx.de>
On Fri, 2005-05-20 at 01:14 +0200, Wolfgang Denk wrote:
> > ppc64 kernel anyways ? I don't think that is very relevant. On the
>
> I am aware that you think so, and I try to raise your awareness of
> the fact that there is a huge number of small machines out there.
>
> Please keep in mind that the same interface will be forced sooner or
> later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.
I don't seem to be getting the point: As you proved conclusively on your
website, 2.6 (and IMHO very likely anything that will come after it)
does not scale down well to small systems like the 8xx any more anyways.
And I don't think such a major change will be "forced" upon the mostly
frozen 2.4 tree.
So why try to stop the folks that want to unite the current "mess" in a
proven superset datastructure that seems to suit quite fine with all
chips that came into production for (at least) the last five years?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* [PATCH] Set cpu type explicitly, take 2
From: Paul Mackerras @ 2005-05-20 6:05 UTC (permalink / raw)
To: linuxppc-dev
Here is a revised version of my patch to set the cpu type explicitly
for gcc when compiling the kernel. Setting the cpu type is a good
idea in any case, and particularly if you have a biarch gcc. This
sets the type for all of the ppc cpu families we support.
Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
and 85xx respectively? I used -mcpu=power4 rather than -mcpu=970
because the former works with gcc-3.6.6 as in debian and the latter
doesn't. Unfortunately -mcpu=440 doesn't work either in gcc 3.3,
though it does in gcc 3.4 (as does -mcpu=970).
Paul.
diff -urN linux-2.6/arch/ppc/Makefile pmac-2.5/arch/ppc/Makefile
--- linux-2.6/arch/ppc/Makefile 2005-05-02 08:29:36.000000000 +1000
+++ pmac-2.5/arch/ppc/Makefile 2005-05-19 15:26:42.000000000 +1000
@@ -23,15 +23,20 @@
LDFLAGS_vmlinux := -Ttext $(KERNELLOAD) -Bstatic
CPPFLAGS += -Iarch/$(ARCH)
AFLAGS += -Iarch/$(ARCH)
-CFLAGS += -Iarch/$(ARCH) -msoft-float -pipe \
- -ffixed-r2 -mmultiple
+CFLAGS += -Iarch/$(ARCH) -msoft-float -pipe -ffixed-r2 -mmultiple
CPP = $(CC) -E $(CFLAGS)
CHECKFLAGS += -D__powerpc__
-ifndef CONFIG_E500
-CFLAGS += -mstring
-endif
+cpu-opt-$(CONFIG_6xx) += -mcpu=750 -mtune=7450
+cpu-opt-$(CONFIG_40x) += -mcpu=405
+cpu-opt-$(CONFIG_44x) += -mcpu=440
+cpu-opt-$(CONFIG_POWER3) += -mcpu=power3
+cpu-opt-$(CONFIG_POWER4) += -mcpu=power4
+cpu-opt-$(CONFIG_8xx) += -mcpu=860
+cpu-opt-$(CONFIG_E500) += -mcpu=8540
+
+CFLAGS += $(cpu-opt-y)
cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
cpu-as-$(CONFIG_4xx) += -Wa,-m405
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Paul Mackerras @ 2005-05-20 4:28 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc64-dev, linuxppc-embedded, u-boot-users,
linuxppc-dev
In-Reply-To: <17037.26222.23591.13083@cargo.ozlabs.ibm.com>
I wrote:
> Ben's proposal is for ppc64, at least as present. If the ppc32
> embedded developers decide they want to use a device tree, that would
> be good, but it will proceed by
... and got interrupted. I meant to write "proceed by persuasion and
consensus, not fiat".
Paul.
^ permalink raw reply
* regarding kernel for montavista
From: Gopala Krishnam Raju @ 2005-05-20 4:25 UTC (permalink / raw)
To: linuxppc-embedded
hello
1. I have compiled the montavista kernel
2. I have done made the make dep
3. I have done make install
4. I have done makeinitrd-pxe also=20
Every thing went well but when i boot this on the target it is giving =
the kernel panic error. I tried with enforcing=3D0 also then also the =
problem is not solved.
please help me out=20
Thanks in advance
Regards
GGKRAJU
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Paul Mackerras @ 2005-05-20 4:24 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
Wolfgang Denk writes:
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
I am familiar with birecs and I have looked at the ARM atags
structure, which is the same as birecs at an abstract level, i.e. a
list of arbitrary blobs of data, each with a binary tag and a size.
As far as MIPS is concerned, there didn't seem to be any single
consistent way of passing information from the bootloader to the
kernel. They seem to be in a similar mess to ppc32 in this respect.
I want to avoid that mess for ppc64 by stating now, while there is
only one embedded ppc64 board that runs linux (the Maple eval board)
that there is one true way to pass information into the kernel at boot
time, and that is a flattened device tree.
Birecs and atags are both OK at representing a specified, limited set
of items of information, such as the location and size of an initrd
image or the total amount of memory in a system. They fall down when
it comes to giving information about the devices in the system and
their interconnections. For instance, atags has a structure for
representing a frame buffer - but what if you have two video cards in
your system?
Essentially, each element in the birecs/atags list is like a property
in a device tree that has only one node, and the entire birecs/atags
list is like a 1-node device tree. What the device tree gives you is
the ability to organize those pieces of information hierarchically so
that it becomes obvious when you have multiple instances of a device
(e.g. a PCI host bridge), what pieces of information apply to which
device instances, and which devices have to be used to get to certain
other devices.
Thus, my opinion is that the device tree is technically superior to
the birecs/atags approach. The device tree has also proven itself to
be capable of representing the information that the kernel needs about
all sorts of systems from the very small to the very large. Unless
you can come up with something even better, ppc64 won't be changing.
In particular we're not going to go back to anything like birecs or
atags.
Also, given that a minimal flattened device tree fits in well under
1kB, any arguments about "excessive" memory usage will need to be
accompanied by specific code and data sizes of a real-world example.
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
U-Boot currently doesn't support any ppc64 machines, does it? So
how is there a backward compatibility issue?
Ben's proposal is for ppc64, at least as present. If the ppc32
embedded developers decide they want to use a device tree, that would
be good, but it will proceed by
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
Other architectures are welcome to move to using a device tree. The
problem is going to be convincing them to spend the effort to make the
change. None of the other architectures currently have a solution
that is appealing.
Paul.
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Hollis Blanchard @ 2005-05-20 3:51 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
On May 19, 2005, at 8:18 AM, Wolfgang Denk wrote:
>
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
>
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
>
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
>
> Maybe you want to post the RFC to lkml, or at least to the
> linux-arm-kernel and linux-mips mailing lists?
As you observe, having multiple incompatible communication mechanisms
is an issue of u-boot code maintenance. Since you are the most affected
party, perhaps you could propose something for all the architectures?
You're obviously much more in tune with the needs of ARM and MIPS...
In the meantime, it sounds like this device tree stuff solves ppc64's
problem in a way the maintainers are happy with, so it's hard to ask
them to come up with a solution to a problem they don't have.
-Hollis
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Benjamin Herrenschmidt @ 2005-05-19 23:28 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <20050519231446.29487C1512@atlas.denx.de>
> I am aware that you think so, and I try to raise your awareness of
> the fact that there is a huge number of small machines out there.
>
> Please keep in mind that the same interface will be forced sooner or
> later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.
I will not force it, but others may find it a good idea to do so :)
> It is IMHO wrong to have only the boot loader side in mind. We should
> consider the whole system.
I do have the kernel in mind as well. The fact is the ppc64 kernel
relies on an Open Firmware device tree and we do not want at any cost to
get into the mess that is ppc32. We decided to define this flattened
format for that purpose, and to allow kexec functionality. I did my best
to keep the format as compact as possible (maybe a little bit more could
be saved by changing the way the full path are layed out, maybe we could
even do a new version which gzip's the while blob, but overall, it's
fairly small).
On the kernel side, as I wrote as well, the code for dealing with the
device-tree isn't that big, and will get smaller as I remove the
post-processing of nodes in prom.c that we still have here. And as I
wrote, if other platforms want to re-use that mecanism, they may want to
just use the compact/flattened format directly. The function for
scanning nodes in the flattened tree is about 40 lines of C and the
function for accessing a property in a flattened node is about as much.
>
> I think you are aware that there are several people out there working
> on a similar boot interface for the "small" PPC systems, too.
I know, and I was at the origin of the bi_rec proposal, a few years ago.
I've simply never seen anything actually happening.
> > No other solution will be accepted on the kernel side. At least for
> > ppc64
>
> This is not exactly a constructive position. When each architecture
> comes up with it's own solution for the same problem and then claims
> that no other solution will be accepted we will stick with what we
> have now: a mess.
>
> If this is really your position we may as well stop here.
The ppc64 kernel relies on an open firmware style device tree. That will
not change any time soon. This proposal is a way to define a subset of
this device-tree along with a compact & flattened format so that one
don't have to do a full Open Firmware implementation and so that mimal
trees can be used.
> Yes, of course. And using ATAGS is the only supported way to boot an
> ARM kernel, and so on.
>
> If everybody claims that his way of doing things is the only accepted
> solution we can really save all the time we are wasting on such a
> discussion.
Maybe. I'd rather have this proposal completed and have actual comments
about the _content_ of it rather than such a debate at this point. Once
we have that working, we can talk about extending it.
> > talks about backporting support for that to ppc32 as well. Other
> > architectures are welcome to use it too though :) The device-tree in the
>
> Ummm.. Ben, I have really high respect for you, but such a position
> is simply arrogant. With the same right the ARM folks can say that
> ATAGS is the way to go and other architectures are welcome to use it.
> Actually they might have older rights.
May well be. But that out of topic. The decision has been made already.
> > > Why don't we try to come up with a solution that is acceptable to the
> > > other architectures as well?
> >
> > This has been discussed over and over again, that is the best way to
> > never come up with a solution as everybody will want something different
> > and nobody will ever agree.
>
> With such a position I really wonder why you ever asked?
I'm asking for comments about the content of the proposal and posting to
inform people of what's going on. You are the one wanting to extend it
to other architectures :)
> > The present proposal is implemented today on the ppc64 kernel already,
> > and we have decided to not go backward on this requirement.
>
> The why the heck do you call this a RFC or a proposal? To me it seems
> that you don't propose but dictate a solution - a solution which
> pretty much ignores everything but your own requirements. If
> everything has been decided already I can as well shut up.
I'm asking for comments about the actual details of it, if something was
overlooked in the format (though that actually works today), if my
wording is wrong in parts, if we should define in more details some
aspect of it.
> But please never claim that this has been _discusssed_.
No, what I meant earlier is that trying to come up with something like
that, as you stated earlier, has been discussed again and again and
again without any useful result.
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Wolfgang Denk @ 2005-05-19 23:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <1116541230.5153.8.camel@gaston>
Dear Ben,
in message <1116541230.5153.8.camel@gaston> you wrote:
>
> > I have some concerns about the memory foot print and increased boot
> > time that will result from the proposed solution.
>
> Like everybody it seems, which is funny in a way as I expect pretty much
> none (or a few Kb maybe). The kernel side code for managing a
> device-tree may represent more, but heh, have you seen the size of a
I am not so narrow-minded to think only about U-Boot. I try to think
about the whole system, including boot loader, kernel, and any data
that might need to get passed between these two.
And please believe me, there are many, many systems out there where
"a few Kb" really matter.
> ppc64 kernel anyways ? I don't think that is very relevant. On the
I am aware that you think so, and I try to raise your awareness of
the fact that there is a huge number of small machines out there.
Please keep in mind that the same interface will be forced sooner or
later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
RAM.
And when you sell 100,000 of these units per year then "a few Kb" may
cost a lot of money. Or may cause that other, prorietary OS get used.
> bootloader side, I don't expect any significant impact. The device-tree
> can be very small, and the code required on the bootloader side ranges
> from nothing for a pre-built one, to a little bit if the bootloader has
> to be able to change/add properties/nodes.
It is IMHO wrong to have only the boot loader side in mind. We should
consider the whole system.
> > There are many embedded systems where resources are tight and requirements
> > are aven tighter.
>
> Amen. (Though heh, this is ppc64, you can't be _that_ tight :)
I think you are aware that there are several people out there working
on a similar boot interface for the "small" PPC systems, too.
> >It would be probably a good idea to also ask for feedback
> > from these folks - for example by posting your RFC on the celinux-dev
> > mailing list.
>
> I will do when I have a little bit more mature proposal.
Thanks in advance.
> > But my biggest concern is that we should try to come up with a
> > solution that has a wider acceptance.
>
> No other solution will be accepted on the kernel side. At least for
> ppc64
This is not exactly a constructive position. When each architecture
comes up with it's own solution for the same problem and then claims
that no other solution will be accepted we will stick with what we
have now: a mess.
If this is really your position we may as well stop here.
> > As is, your proposal will add just another incompatible way of doing
> > the same thing (of course we will have to stay backward compatible
> > with U-Boot to allow booting older kernels, too).
>
> My proposal is the only supported way to boot a ppc64 kernel. There are
Yes, of course. And using ATAGS is the only supported way to boot an
ARM kernel, and so on.
If everybody claims that his way of doing things is the only accepted
solution we can really save all the time we are wasting on such a
discussion.
> talks about backporting support for that to ppc32 as well. Other
> architectures are welcome to use it too though :) The device-tree in the
Ummm.. Ben, I have really high respect for you, but such a position
is simply arrogant. With the same right the ARM folks can say that
ATAGS is the way to go and other architectures are welcome to use it.
Actually they might have older rights.
> > Why don't we try to come up with a solution that is acceptable to the
> > other architectures as well?
>
> This has been discussed over and over again, that is the best way to
> never come up with a solution as everybody will want something different
> and nobody will ever agree.
With such a position I really wonder why you ever asked?
> The present proposal is implemented today on the ppc64 kernel already,
> and we have decided to not go backward on this requirement.
The why the heck do you call this a RFC or a proposal? To me it seems
that you don't propose but dictate a solution - a solution which
pretty much ignores everything but your own requirements. If
everything has been decided already I can as well shut up.
But please never claim that this has been _discusssed_.
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
I have made mistakes, but have never made the mistake of claiming I
never made one. - James G. Bennet
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Benjamin Herrenschmidt @ 2005-05-19 22:20 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
On Thu, 2005-05-19 at 15:18 +0200, Wolfgang Denk wrote:
> Dear Ben,
>
> in message <1116478614.918.75.camel@gaston> you wrote:
> >
> > And here is a second draft with more infos.
> >
> > Booting the Linux/ppc64 kernel without Open Firmware
>
> Thanks a lot for taking the initiative to come to an agreement about
> the kernel boot interface.
>
> I have some concerns about the memory foot print and increased boot
> time that will result from the proposed solution.
Like everybody it seems, which is funny in a way as I expect pretty much
none (or a few Kb maybe). The kernel side code for managing a
device-tree may represent more, but heh, have you seen the size of a
ppc64 kernel anyways ? I don't think that is very relevant. On the
bootloader side, I don't expect any significant impact. The device-tree
can be very small, and the code required on the bootloader side ranges
from nothing for a pre-built one, to a little bit if the bootloader has
to be able to change/add properties/nodes.
> There are many embedded systems where resources are tight and requirements
> are aven tighter.
Amen. (Though heh, this is ppc64, you can't be _that_ tight :)
>It would be probably a good idea to also ask for feedback
> from these folks - for example by posting your RFC on the celinux-dev
> mailing list.
I will do when I have a little bit more mature proposal.
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance.
No other solution will be accepted on the kernel side. At least for
ppc64
> Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
True.
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
My proposal is the only supported way to boot a ppc64 kernel. There are
talks about backporting support for that to ppc32 as well. Other
architectures are welcome to use it too though :) The device-tree in the
kernel is fully expanded into a tree structure on ppc, since it's
heavily used by various pieces of code all over the place, but for other
architectures that would like to use that, it's possible to limit
themselves to the flattened format. The ppc64 kernel contains some code
to access nodes & properties directly from the flattened format (used
early during boot) which represents very little code.
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
This has been discussed over and over again, that is the best way to
never come up with a solution as everybody will want something different
and nobody will ever agree.
The present proposal is implemented today on the ppc64 kernel already,
and we have decided to not go backward on this requirement.
> Maybe you want to post the RFC to lkml, or at least to the
> linux-arm-kernel and linux-mips mailing lists?
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 20:36 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CF693.5030100@mrv.com>
[-- Attachment #1: Type: text/plain, Size: 2997 bytes --]
One thought though, if the event register is cleared _before_ the event
is processed (clearing the cause), will the cpm set the bit again
(before we have time to clear the cause) ? That would generate 2
interrupts for the same event ? Am I right ?
Guillaume Autran wrote:
> You are right, moving the event clearing statement is much easier and
> cleaner. Let the interrupt be the loop.
> Thanks Dan !
>
>
> Dan Malek wrote:
>
>>
>> On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
>>
>>> Is it better like this ?
>>
>>
>>
>> Yes, but now I see one problem with it. :-)
>>
>> We have to clear all events even though we may not
>> handle all of them. Your while loop filters only the events
>> we process, but there could be others causing the interrupt
>> which will never get cleared. In this case we end up with
>> an infinite interrupt loop where we don't process anything,
>> but we don't make the interrupt go away, either. It may be
>> easier to forget the loop, just read/clear the event register
>> up front, then process based on the events based upon
>> what we found. It's what we tend to do in the other drivers.
>>
>> The functions called to do the rx/tx processing have loops
>> in them to process all of the data they find, so it isn't likely
>> you have left anything behind. If you want to try to save
>> the interrupt overhead, change it to do/while, check again
>> at the end before the exit.
>>
>> Thanks.
>>
>>
>> -- Dan
>>
>
>------------------------------------------------------------------------
>
>diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
>--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
>+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 16:23:13.000000000 -0400
>@@ -336,22 +336,22 @@
>
> if (IS_SMC(pinfo)) {
> events = smcp->smc_smce;
>+ smcp->smc_smce = events;
> if (events & SMCM_BRKE)
> uart_handle_break(port);
> if (events & SMCM_RX)
> cpm_uart_int_rx(port, regs);
> if (events & SMCM_TX)
> cpm_uart_int_tx(port, regs);
>- smcp->smc_smce = events;
> } else {
> events = sccp->scc_scce;
>+ sccp->scc_scce = events;
> if (events & UART_SCCM_BRKE)
> uart_handle_break(port);
> if (events & UART_SCCM_RX)
> cpm_uart_int_rx(port, regs);
> if (events & UART_SCCM_TX)
> cpm_uart_int_tx(port, regs);
>- sccp->scc_scce = events;
> }
> return (events) ? IRQ_HANDLED : IRQ_NONE;
> }
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 3900 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Dan Malek @ 2005-05-19 20:32 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CF693.5030100@mrv.com>
On May 19, 2005, at 4:26 PM, Guillaume Autran wrote:
> You are right, moving the event clearing statement is much easier and
> cleaner. Let the interrupt be the loop.
I also just had the thought we could check the events for non-zero,
clear them, and process only the ones we wanted. That would save
the interrupt overhead if we had high speed ports (which I really
don't like for normal RS-232 anyway :-)).
I'll move this patch ahead.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 20:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <5e493590088edcf959e30390363e798d@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
You are right, moving the event clearing statement is much easier and
cleaner. Let the interrupt be the loop.
Thanks Dan !
Dan Malek wrote:
>
> On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
>
>> Is it better like this ?
>
>
> Yes, but now I see one problem with it. :-)
>
> We have to clear all events even though we may not
> handle all of them. Your while loop filters only the events
> we process, but there could be others causing the interrupt
> which will never get cleared. In this case we end up with
> an infinite interrupt loop where we don't process anything,
> but we don't make the interrupt go away, either. It may be
> easier to forget the loop, just read/clear the event register
> up front, then process based on the events based upon
> what we found. It's what we tend to do in the other drivers.
>
> The functions called to do the rx/tx processing have loops
> in them to process all of the data they find, so it isn't likely
> you have left anything behind. If you want to try to save
> the interrupt overhead, change it to do/while, check again
> at the end before the exit.
>
> Thanks.
>
>
> -- Dan
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: cpm_uart_core.patch --]
[-- Type: text/plain, Size: 970 bytes --]
diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 16:23:13.000000000 -0400
@@ -336,22 +336,22 @@
if (IS_SMC(pinfo)) {
events = smcp->smc_smce;
+ smcp->smc_smce = events;
if (events & SMCM_BRKE)
uart_handle_break(port);
if (events & SMCM_RX)
cpm_uart_int_rx(port, regs);
if (events & SMCM_TX)
cpm_uart_int_tx(port, regs);
- smcp->smc_smce = events;
} else {
events = sccp->scc_scce;
+ sccp->scc_scce = events;
if (events & UART_SCCM_BRKE)
uart_handle_break(port);
if (events & UART_SCCM_RX)
cpm_uart_int_rx(port, regs);
if (events & UART_SCCM_TX)
cpm_uart_int_tx(port, regs);
- sccp->scc_scce = events;
}
return (events) ? IRQ_HANDLED : IRQ_NONE;
}
^ permalink raw reply
* Re: tah reset?
From: Eugene Surovegin @ 2005-05-19 20:13 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA21A7B9E@exchange.tsi-telsys.com>
On Thu, May 19, 2005 at 03:45:50PM -0400, Sanjay Bajaj wrote:
> Eugene,
>
> Yes, TAH0 in SDR0_MFR register is enabled.
>
> EMAC is able to reset correctly, but TAH isn't at the same location
> [in emac_probe()]. PHY is connected to EMAC and TAH is behind EMAC.
> I do not understand how the RX clock from PHY will reach TAH? Any suggestions ?
E.g. TAH RX path is clocked from the same source as EMAC, I think
it's quite obvious, but I digress.
What are you doing? Having problems with EMAC driver? What kernel
version? What board?
You can try my new NAPI EMAC driver (http://kernel.ebshome.net/).
--
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Dan Malek @ 2005-05-19 19:54 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CEA55.1040904@mrv.com>
On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
> Is it better like this ?
Yes, but now I see one problem with it. :-)
We have to clear all events even though we may not
handle all of them. Your while loop filters only the events
we process, but there could be others causing the interrupt
which will never get cleared. In this case we end up with
an infinite interrupt loop where we don't process anything,
but we don't make the interrupt go away, either. It may be
easier to forget the loop, just read/clear the event register
up front, then process based on the events based upon
what we found. It's what we tend to do in the other drivers.
The functions called to do the rx/tx processing have loops
in them to process all of the data they find, so it isn't likely
you have left anything behind. If you want to try to save
the interrupt overhead, change it to do/while, check again
at the end before the exit.
Thanks.
-- Dan
^ permalink raw reply
* RE: tah reset?
From: Sanjay Bajaj @ 2005-05-19 19:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Eugene,
Yes, TAH0 in SDR0_MFR register is enabled.
EMAC is able to reset correctly, but TAH isn't at the same location [in =
emac_probe()]. PHY is connected to EMAC and TAH is behind EMAC. I do not =
understand how the RX clock from PHY will reach TAH? Any suggestions ?
Thanks,
Sanjay
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Thursday, May 19, 2005 2:23 PM
To: Sanjay Bajaj
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: tah reset?
On Thu, May 19, 2005 at 02:14:20PM -0400, Sanjay Bajaj wrote:
> While trying to reset the TAH on emac2 of PPC440GX, the Soft Reset=20
> (SR) bit never resets itself to 0. Does anybody know the reason for=20
> it?
Did you enable TAH0 in SDR0_MFR register?
Also, I don't remember for sure, but TAH may have the same problem as=20
EMAC, namely, it won't go out of reset if there is no RX clock from=20
PHY.
--=20
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 19:34 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <2376d87e3df664106a6cf626f9575d90@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Is it better like this ?
Dan Malek wrote:
>
> On May 19, 2005, at 1:59 PM, Guillaume Autran wrote:
>
>> Any comment ?
>
>
> The idea is fine. Read Documentation/CodingStyle and try again .....
>
> Thanks.
>
>
> -- Dan
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: cpm_uart_core.patch --]
[-- Type: text/plain, Size: 1560 bytes --]
diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 15:31:03.000000000 -0400
@@ -335,23 +335,25 @@
pr_debug("CPM uart[%d]:IRQ\n", port->line);
if (IS_SMC(pinfo)) {
- events = smcp->smc_smce;
- if (events & SMCM_BRKE)
- uart_handle_break(port);
- if (events & SMCM_RX)
- cpm_uart_int_rx(port, regs);
- if (events & SMCM_TX)
- cpm_uart_int_tx(port, regs);
- smcp->smc_smce = events;
+ while ((events = smcp->smc_smce) & (SMCM_BRKE | SMCM_RX | SMCM_TX)) {
+ smcp->smc_smce = events;
+ if (events & SMCM_BRKE)
+ uart_handle_break(port);
+ if (events & SMCM_RX)
+ cpm_uart_int_rx(port, regs);
+ if (events & SMCM_TX)
+ cpm_uart_int_tx(port, regs);
+ }
} else {
- events = sccp->scc_scce;
- if (events & UART_SCCM_BRKE)
- uart_handle_break(port);
- if (events & UART_SCCM_RX)
- cpm_uart_int_rx(port, regs);
- if (events & UART_SCCM_TX)
- cpm_uart_int_tx(port, regs);
- sccp->scc_scce = events;
+ while ((events = sccp->scc_scce) & (UART_SCCM_BRKE | UART_SCCM_RX | UART_SCCM_TX)) {
+ sccp->scc_scce = events;
+ if (events & UART_SCCM_BRKE)
+ uart_handle_break(port);
+ if (events & UART_SCCM_RX)
+ cpm_uart_int_rx(port, regs);
+ if (events & UART_SCCM_TX)
+ cpm_uart_int_tx(port, regs);
+ }
}
return (events) ? IRQ_HANDLED : IRQ_NONE;
}
^ 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