* [PATCH 4/4] Inline u3msi_compose_msi_msg()
From: Michael Ellerman @ 2007-09-20 6:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3034ec8fd939bd5cfcdb7ac65206ae2771dc9b2c.1190270165.git.michael@ellerman.id.au>
In the MPIC U3 MSI code, we call u3msi_compose_msi_msg() once for each MSI.
This is overkill, as the address is per pci device, not per MSI. So setup
the address once, and just set the data per MSI.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/sysdev/mpic_u3msi.c | 24 +++++++++---------------
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 4e50d1c..027fe01 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -107,26 +107,17 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
return;
}
-static void u3msi_compose_msi_msg(struct pci_dev *pdev, int virq,
- struct msi_msg *msg)
-{
- u64 addr;
-
- addr = find_ht_magic_addr(pdev);
- msg->address_lo = addr & 0xFFFFFFFF;
- msg->address_hi = addr >> 32;
- msg->data = virq_to_hw(virq);
-
- pr_debug("u3msi: allocated virq 0x%x (hw 0x%lx) at address 0x%lx\n",
- virq, virq_to_hw(virq), addr);
-}
-
static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
irq_hw_number_t hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
+ u64 addr;
+
+ addr = find_ht_magic_addr(pdev);
+ msg.address_lo = addr & 0xFFFFFFFF;
+ msg.address_hi = addr >> 32;
list_for_each_entry(entry, &pdev->msi_list, list) {
hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
@@ -146,7 +137,10 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
set_irq_chip(virq, &mpic_u3msi_chip);
set_irq_type(virq, IRQ_TYPE_EDGE_RISING);
- u3msi_compose_msi_msg(pdev, virq, &msg);
+ pr_debug("u3msi: allocated virq 0x%x (hw 0x%lx) addr 0x%lx\n",
+ virq, hwirq, addr);
+
+ msg.data = hwirq;
write_msi_msg(virq, &msg);
hwirq++;
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath
From: Kamalesh Babulal @ 2007-09-20 8:25 UTC (permalink / raw)
To: Satyam Sharma; +Cc: linuxppc-dev, Paul Mackerras, Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.0.999.0709180511070.8863@enigma.security.iitk.ac.in>
Satyam Sharma wrote:
>> ------------[ cut here ]------------
>> Badness at arch/powerpc/kernel/smp.c:202
>>
>
> comes when smp_call_function_map() has been called with irqs disabled,
> which is illegal. However, there is a special case, the panic() codepath,
> when we do not want to warn about this -- warning at that time is pointless
> anyway, and only serves to scroll away the *real* cause of the panic and
> distracts from the real bug.
>
> * So let's extract the WARN_ON() from smp_call_function_map() into all its
> callers -- smp_call_function() and smp_call_function_single()
>
> * Also, introduce another caller of smp_call_function_map(), namely
> __smp_call_function() (and make smp_call_function() a wrapper over this)
> which does *not* warn about disabled irqs
>
> * Use this __smp_call_function() from the panic codepath's smp_send_stop()
>
> We also end having to move code of smp_send_stop() below the definition
> of __smp_call_function().
>
> Signed-off-by: Satyam Sharma <satyam@infradead.org>
>
> ---
>
> Untested (not even compile-tested) patch.
> Could someone point me to ppc32/64 cross-compilers for i386?
>
> arch/powerpc/kernel/smp.c | 27 ++++++++++++++++++---------
> 1 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 1ea4316..b24dcba 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -152,11 +152,6 @@ static void stop_this_cpu(void *dummy)
> ;
> }
>
> -void smp_send_stop(void)
> -{
> - smp_call_function(stop_this_cpu, NULL, 1, 0);
> -}
> -
> /*
> * Structure and data for smp_call_function(). This is designed to minimise
> * static memory requirements. It also looks cleaner.
> @@ -198,9 +193,6 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
> int cpu;
> u64 timeout;
>
> - /* Can deadlock when called with interrupts disabled */
> - WARN_ON(irqs_disabled());
> -
> if (unlikely(smp_ops == NULL))
> return ret;
>
> @@ -270,10 +262,19 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
> return ret;
> }
>
> +static int __smp_call_function(void (*func)(void *info), void *info,
> + int nonatomic, int wait)
> +{
> + return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
> +}
> +
> int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
> int wait)
> {
> - return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
> + /* Can deadlock when called with interrupts disabled */
> + WARN_ON(irqs_disabled());
> +
> + return __smp_call_function(func, info, nonatomic, wait);
> }
> EXPORT_SYMBOL(smp_call_function);
>
> @@ -283,6 +284,9 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
> cpumask_t map = CPU_MASK_NONE;
> int ret = 0;
>
> + /* Can deadlock when called with interrupts disabled */
> + WARN_ON(irqs_disabled());
> +
> if (!cpu_online(cpu))
> return -EINVAL;
>
> @@ -299,6 +303,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
> }
> EXPORT_SYMBOL(smp_call_function_single);
>
> +void smp_send_stop(void)
> +{
> + __smp_call_function(stop_this_cpu, NULL, 1, 0);
> +}
> +
> void smp_call_function_interrupt(void)
> {
> void (*func) (void *info);
>
Hi,
This patch solves the badness oops we get on the powerpc.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] [POWERPC] Create and use CONFIG_WORD_SIZE
From: Stephen Rothwell @ 2007-09-20 8:08 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Linus made this suggestion for the x86 merge and this starts the process
for powerpc. We assume that CONFIG_PPC64 implies CONFIG_PPC_MERGE and
CONFIG_PPC_STD_MMU_32 implies CONFIG_PPC_STD_MMU.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 5 +++++
arch/powerpc/Makefile | 15 ++++++---------
arch/powerpc/kernel/Makefile | 30 +++++++++++++-----------------
arch/powerpc/lib/Makefile | 7 ++++---
arch/powerpc/mm/Makefile | 13 ++++++++-----
arch/ppc/Kconfig | 4 ++++
6 files changed, 40 insertions(+), 34 deletions(-)
Built for ARCH=powerpc all defconfigs and ARCH=ppc all defconfigs (most
of which failed for (I am pretty sure) reasons unrelated to this patch).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3295..de886ec 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -14,6 +14,11 @@ config 64BIT
bool
default y if PPC64
+config WORD_SIZE
+ int
+ default 64 if PPC64
+ default 32 if !PPC64
+
config PPC_MERGE
def_bool y
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6015a92..9de1833 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -39,7 +39,6 @@ KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
ifeq ($(CONFIG_PPC64),y)
OLDARCH := ppc64
-SZ := 64
new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi)
@@ -49,16 +48,15 @@ endif
else
OLDARCH := ppc
-SZ := 32
endif
UTS_MACHINE := $(OLDARCH)
ifeq ($(HAS_BIARCH),y)
-override AS += -a$(SZ)
-override LD += -m elf$(SZ)ppc
-override CC += -m$(SZ)
-override AR := GNUTARGET=elf$(SZ)-powerpc $(AR)
+override AS += -a$(CONFIG_WORD_SIZE)
+override LD += -m elf$(CONFIG_WORD_SIZE)ppc
+override CC += -m$(CONFIG_WORD_SIZE)
+override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
endif
LDFLAGS_vmlinux := -Bstatic
@@ -72,7 +70,7 @@ AFLAGS += $(AFLAGS-y)
CFLAGS += -msoft-float -pipe $(CFLAGS-y)
CPP = $(CC) -E $(CFLAGS)
-CHECKFLAGS += -m$(SZ) -D__powerpc__ -D__powerpc$(SZ)__
+CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
ifeq ($(CONFIG_PPC64),y)
GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y"; fi)
@@ -116,8 +114,7 @@ cpu-as-$(CONFIG_E200) += -Wa,-me200
AFLAGS += $(cpu-as-y)
CFLAGS += $(cpu-as-y)
-head-y := arch/powerpc/kernel/head_32.o
-head-$(CONFIG_PPC64) := arch/powerpc/kernel/head_64.o
+head-y := arch/powerpc/kernel/head_$(CONFIG_WORD_SIZE).o
head-$(CONFIG_8xx) := arch/powerpc/kernel/head_8xx.o
head-$(CONFIG_40x) := arch/powerpc/kernel/head_40x.o
head-$(CONFIG_44x) := arch/powerpc/kernel/head_44x.o
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 967afc5..ef3633f 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -37,10 +37,10 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
-obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
-obj32-$(CONFIG_HIBERNATION) += swsusp_32.o
-obj64-$(CONFIG_HIBERNATION) += swsusp_64.o swsusp_asm64.o
-obj32-$(CONFIG_MODULES) += module_32.o
+obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
+ swsusp_$(CONFIG_WORD_SIZE).o
+obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
+obj-$(CONFIG_MODULES) += module_$(CONFIG_WORD_SIZE).o
ifeq ($(CONFIG_PPC_MERGE),y)
@@ -53,9 +53,10 @@ extra-$(CONFIG_8xx) := head_8xx.o
extra-y += vmlinux.lds
obj-y += time.o prom.o traps.o setup-common.o \
- udbg.o misc.o io.o
-obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
-obj-$(CONFIG_PPC64) += misc_64.o dma_64.o iommu.o
+ udbg.o misc.o io.o \
+ misc_$(CONFIG_WORD_SIZE).o
+obj-$(CONFIG_PPC32) += entry_32.o setup_32.o
+obj-$(CONFIG_PPC64) += dma_64.o iommu.o
obj-$(CONFIG_PPC_MULTIPLATFORM) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_BOOTX_TEXT) += btext.o
@@ -63,16 +64,12 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
-module-$(CONFIG_PPC64) += module_64.o
-obj-$(CONFIG_MODULES) += $(module-y)
-
-pci64-$(CONFIG_PPC64) += pci_64.o pci_dn.o isa-bridge.o
-pci32-$(CONFIG_PPC32) := pci_32.o
-obj-$(CONFIG_PCI) += $(pci64-y) $(pci32-y) pci-common.o
+pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
+obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
+ pci-common.o
obj-$(CONFIG_PCI_MSI) += msi.o
-kexec-$(CONFIG_PPC64) := machine_kexec_64.o
-kexec-$(CONFIG_PPC32) := machine_kexec_32.o
-obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o $(kexec-y)
+obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o \
+ machine_kexec_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_AUDIT) += audit.o
obj64-$(CONFIG_AUDIT) += compat_audit.o
@@ -86,7 +83,6 @@ smpobj-$(CONFIG_SMP) += smp.o
endif
-obj-$(CONFIG_PPC32) += $(obj32-y)
obj-$(CONFIG_PPC64) += $(obj64-y)
extra-$(CONFIG_PPC_FPU) += fpu.o
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 23bbb1e..65d492e 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -7,11 +7,12 @@ EXTRA_CFLAGS += -mno-minimal-toc
endif
ifeq ($(CONFIG_PPC_MERGE),y)
-obj-y := string.o alloc.o
-obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
+obj-y := string.o alloc.o \
+ checksum_$(CONFIG_WORD_SIZE).o
+obj-$(CONFIG_PPC32) += div64.o copy_32.o
endif
-obj-$(CONFIG_PPC64) += checksum_64.o copypage_64.o copyuser_64.o \
+obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o
obj-$(CONFIG_QUICC_ENGINE) += rheap.o
obj-$(CONFIG_XMON) += sstep.o
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index bf20fa6..20629ae 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -6,13 +6,16 @@ ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
-obj-y := fault.o mem.o lmb.o
-obj-$(CONFIG_PPC32) += init_32.o pgtable_32.o mmu_context_32.o
+obj-y := fault.o mem.o lmb.o \
+ init_$(CONFIG_WORD_SIZE).o \
+ pgtable_$(CONFIG_WORD_SIZE).o \
+ mmu_context_$(CONFIG_WORD_SIZE).o
hash-$(CONFIG_PPC_NATIVE) := hash_native_64.o
-obj-$(CONFIG_PPC64) += init_64.o pgtable_64.o mmu_context_64.o \
- hash_utils_64.o hash_low_64.o tlb_64.o \
+obj-$(CONFIG_PPC64) += hash_utils_64.o \
slb_low.o slb.o stab.o mmap.o $(hash-y)
-obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o hash_low_32.o tlb_32.o
+obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o
+obj-$(CONFIG_PPC_STD_MMU) += hash_low_$(CONFIG_WORD_SIZE).o \
+ tlb_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_40x) += 40x_mmu.o
obj-$(CONFIG_44x) += 44x_mmu.o
obj-$(CONFIG_FSL_BOOKE) += fsl_booke_mmu.o
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index c1b34eb..c2087f6 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -4,6 +4,10 @@
mainmenu "Linux/PowerPC Kernel Configuration"
+config WORD_SIZE
+ int
+ default 32
+
config MMU
bool
default y
--
1.5.3.1
^ permalink raw reply related
* Re: Configuration-Problem ext-interrupt on mpc52xx
From: S. Fricke @ 2007-09-20 8:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070919234016.GA14404@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
Hello,
> > I have read it! But another driver on Boot-time pulled my interrupt
>
> Erm.. if the interrupt is shared with something else which expects a
> different trigger/polarity, you're kind of stuffed....
YEEeess! An incomplete documentation is suboptimal! In german, we would
say: "[...] Das es die Sau krausst [...]"
I have now used an another Interrupt and it works.
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH) TEL: (+49)8330-911278
Linux-Entwicklung JABBER: fricke@jabber.org
-- Steinbacher Strasse 18, D-87764 Legau -----------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 8270 & Watchdog - early start
From: Matias Sundman @ 2007-09-20 8:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
Hi,
I have a custom MPC8270 board running Linux and u-boot.
Now, I enabled the watchdog on the 8270 and need to kick it regularly by
writing ;
0x556c
0xaa39
To the internal register @ 0x0x1000e.
When I am coming out from head.S to start_kernel I was thinking of
kicking
it a couple times "manually"
before a timer interrupt is inserted which will take care of it until a
"superdaemon" is taking over.
I tried to serve the register as follows;
*((volatile unsigned int*)(0xf001000e))=0x556c;
*((volatile unsigned int*)(0xf001000e))=0xaa39;
But it does not take effect. I thought that since u-boot had set up the
IMMR
to 0xf000'0000 I could
directly write to the register as above.
Any clues why this does not work?
Thx // Matias
[-- Attachment #2: Type: text/html, Size: 2068 bytes --]
^ permalink raw reply
* Re: 8270 & Watchdog - early start
From: Laurent Pinchart @ 2007-09-20 8:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <AEA1A32F001C6B4F98614B5B80D7647D02D73DEB@esealmw115.eemea.ericsson.se>
Hi Matias,
On Thursday 20 September 2007 10:19, Matias Sundman wrote:
> Hi,
> I have a custom MPC8270 board running Linux and u-boot.
> Now, I enabled the watchdog on the 8270 and need to kick it regularly by
> writing ;
>
> 0x556c
> 0xaa39
>
> To the internal register @ 0x0x1000e.
>
> When I am coming out from head.S to start_kernel I was thinking of
> kicking it a couple times "manually" before a timer interrupt is inserted
> which will take care of it until a "superdaemon" is taking over.
>
> I tried to serve the register as follows;
>
> *((volatile unsigned int*)(0xf001000e))=3D0x556c;
> *((volatile unsigned int*)(0xf001000e))=3D0xaa39;
>
> But it does not take effect. I thought that since u-boot had set up the
> IMMR to 0xf000'0000 I could directly write to the register as above.
>
> Any clues why this does not work?
The Software Service Register (SWSR) is 16-bit wide. Unsigned int on the 82=
70=20
is 32-bit wide.
You must not reference physical addresses directly after the MMU has been=20
turned on. Use ioremap/iounmap to map/unmaap the CPM registers. If you're=20
using ARCH=3Dppc, you can also use the global CPM mapping cpm2_immr.
Use the out_* macros/functions to write to I/O space.
out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0x556c);
out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0xaa39);
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=C3=A9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* The ds1337 chip on fsl_mp8313E RDB REVA 3 doesn't work properly
From: Andrew Liu @ 2007-09-20 9:09 UTC (permalink / raw)
To: linuxppc-embedded
Hello All,
The same u-boot/kernel/rootfs on fsl_mp8313E RDB REVA 2, DS1337 RTC
chip can work,
but on sl_mp8313E RDB REVA 3, it doesn't work, its time don't change.
This RTC chip specific bad behavior on sl_mp8313E RDB REVA 3 as follows:
(1) On U-Boot (from Freescale), run command:
=> i2c md 0x68 0x0
0000: 32 33 10 04 20 89 08 84 00 20 53 00 42 16 18 80 23.. .... S.B...
after a while
=> i2c md 0x68 0x0
0000: 32 33 10 04 20 89 08 84 00 20 53 00 42 16 18 80 23.. .... S.B...
The first value(second value) is unchanged always, but on fsl_mp8313E
RDB REVA 2, it changes.
meanwhile, we can change this value through i2c nm 0x68 0xX on
fsl_mp8313E RDB REVA 3.
SO the core of this problem is the time always keeps same.
(2) during Linux kernel bootup, we can see:
oing write 0 bytes to 0x68 - 1 of 1 messages
i2c_adapter i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c_adapter i2c-0: master_xfer[1] R, addr=0x68, len=8
Doing write 1 bytes to 0x68 - 1 of 2 messages
Doing read 8 bytes to 0x68 - 2 of 2 messages
i2c_adapter i2c-0: client [ds1307] registered with bus id 0-0068
ds1307 0-0068: rtc intf: sysfs
ds1307 0-0068: rtc intf: proc
ds1307 0-0068: rtc intf: dev (254:0)
ds1307 0-0068: rtc core: registered ds1307 as rtc0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x68
i2c_adapter i2c-1: master_xfer[0] W, addr=0x68, len=0
Doing write 0 bytes to 0x68 - 1 of 1 messages
I2C: No RXAK
..............................
i2c_adapter i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c_adapter i2c-0: master_xfer[1] R, addr=0x68, len=7
Doing write 1 bytes to 0x68 - 1 of 2 messages
Doing read 7 bytes to 0x68 - 2 of 2 messages
ds1307 0-0068: read: 32 33 10 04 20 89 08
ds1307 0-0068: read secs=32, mins=33, hours=10, mday=20, mon=8,
year=108, wday=3
ds1307 0-0068: setting the system clock to 2008-09-20 10:33:32 (1221906812)
it indicates can read and write RTC chip through I2C. but after system
boot up, we can see the time always same.
After adjusting these configurations on U-Boot environment according
to fsl_mp8313E RDB REVA 2, it still doesn't work.
Who can give me some advice or suggestion ? currently I doubt this
hardware, but what a shame I have only one fsl_mp8313E RDB REVA 3 board,
can't do comparison experiment.
Thanks in advance.
Andrew Liu
^ permalink raw reply
* (no subject)
From: - Reyneke @ 2007-09-20 10:04 UTC (permalink / raw)
To: jwboyer, jeynergilcaga; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]
>>Where did you get your kernel from? 2.6.19 doesn't have any 440EPx support in it
Linux kernel is from DENX, and yes it has full 440EPx support.
>> In you statement, initialise correctly (i.e. receive and transmit), did you use like ping or ftp to do it?
>> What do you mean by the word initialise?
I think the best response will be to provide a short example via u-boot output.
The board has just booted up. Eth1 is connected and has a 1Gb link (as per PHY and connected switch LEDS). Eth0 is NOT cabled.
...
ver=U-Boot 1.2.0 (Sep 18 2007 - 15:51:19)
=> setenv netdev eth1
=> setenv ethact ppc_4xx_eth1
=> ping 10.1.12.90
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection
Using ppc_4xx_eth1 device
ping failed; host 10.1.12.90 is not alive
<At this point, we plug in a Ethernet cable into eth0 and wait for link status>
=> ping 10.1.12.90
ENET Speed is 1000 Mbps - FULL duplex connection
Using ppc_4xx_eth1 device
host 10.1.12.90 is alive
=>
At this point, the Eth0 link can be removed. Eth1 will from now send and receive as expected.
So, it looks like some kind of initialisation issue. What we would like to know is whether anyone else have come across a similar problem.
Other interesting point is that we tried the same test on a AMCC Sequoia (same type of board, different PHYs). And it worked fine. So it suggest that it is ether something we are doing wrong in our board initialisation, or it's the EMAC - PHY combination.
On Wed, 19 Sep 2007 13:54:35 +0000
"- Reyneke" <reynekejunk@hotmail.com> wrote:
> HI,
>
> We've run into a bit of an odd problem and we are not sure where to go and
> look for the cause.
>
> We have some 440EPx based hardware with two GIG-Ethernet ports using RGMII
> and 2x ET1011C PHY's. Problem is that eth1 will only initialise correctly
> (i.e. receive and transmit) if eth0 has a link. Eth0 always work OK,
> regardless of eth1 status. Eth1 will work OK if eth0 has a link (i.e.
> initialised) at time of setup. Once initialised, eth0 status is irrelevant.
> All this is during Linux boot process.
>
> Any ideas?
_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
^ permalink raw reply
* [patch 0/3] fsl_soc / mpc8349emitx patches
From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw)
To: linuxppc-dev, galak
Various small fsl_soc / mpc8349emitx patches.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 2/3] fsl_soc: rtc-ds1307 support
From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: G. Liakhovetski
In-Reply-To: <20070920104211.896143373@sunsite.dk>
Add support for the I2C devices handled by the rtc-ds1307 driver to
of_register_i2c_devices.
Cc: G. Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/sysdev/fsl_soc.c | 6 ++++++
1 file changed, 6 insertions(+)
Index: linux/arch/powerpc/sysdev/fsl_soc.c
===================================================================
--- linux.orig/arch/powerpc/sysdev/fsl_soc.c
+++ linux/arch/powerpc/sysdev/fsl_soc.c
@@ -319,6 +319,12 @@
{"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
{"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
{"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
+ {"dallas,ds1307", "rtc-ds1307", "ds1307",},
+ {"dallas,ds1337", "rtc-ds1307", "ds1337",},
+ {"dallas,ds1338", "rtc-ds1307", "ds1338",},
+ {"dallas,ds1339", "rtc-ds1307", "ds1339",},
+ {"dallas,ds1340", "rtc-ds1307", "ds1340",},
+ {"stm,m41t00", "rtc-ds1307", "m41t00"},
};
static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Timur Tabi
In-Reply-To: <20070920104211.896143373@sunsite.dk>
Add ds1339 I2C RTC chip as child of 2nd I2C controller.
Cc: Timur Tabi <timur@freescale.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 7 +++++++
1 file changed, 7 insertions(+)
Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts
===================================================================
--- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -68,6 +68,13 @@
interrupts = <f 8>;
interrupt-parent = < &ipic >;
dfsrr;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <68 4>;
+ };
+
};
spi@7000 {
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 1/3] fsl_soc: Fix trivial printk typo.
From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: G. Liakhovetski
In-Reply-To: <20070920104211.896143373@sunsite.dk>
Fix a trivial printk typo in fsl_soc.
Cc: G. Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/sysdev/fsl_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/powerpc/sysdev/fsl_soc.c
===================================================================
--- linux.orig/arch/powerpc/sysdev/fsl_soc.c
+++ linux/arch/powerpc/sysdev/fsl_soc.c
@@ -346,7 +346,7 @@
addr = of_get_property(node, "reg", &len);
if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_ioc.c: invalid i2c device entry\n");
+ printk(KERN_WARNING "fsl_soc.c: invalid i2c device entry\n");
continue;
}
--
Bye, Peter Korsgaard
^ permalink raw reply
* 8270 & Watchdog - early start - II
From: Matias Sundman @ 2007-09-20 10:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <AEA1A32F001C6B4F98614B5B80D7647D02D73DEB@esealmw115.eemea.ericsson.se>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
Hi Guys,
The Software Service Register (SWSR) is 16-bit wide which Laurent
Pinchart [laurentp@cse-semaphore.com] so nicely pointed out for me.
So it actually works with;
*((volatile unsigned short*)(0xf001000e))=0x556c;
*((volatile unsigned short*)(0xf001000e))=0xaa39;
Thx // Matias
________________________________
From: linuxppc-embedded-bounces+matias.sundman=ericsson.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+matias.sundman=ericsson.com@ozlabs.org
] On Behalf Of Matias Sundman
Sent: den 20 september 2007 10:19
To: linuxppc-embedded@ozlabs.org
Subject: 8270 & Watchdog - early start
Hi,
I have a custom MPC8270 board running Linux and u-boot.
Now, I enabled the watchdog on the 8270 and need to kick it regularly by
writing ;
0x556c
0xaa39
To the internal register @ 0x0x1000e.
When I am coming out from head.S to start_kernel I was thinking of
kicking
it a couple times "manually"
before a timer interrupt is inserted which will take care of it until a
"superdaemon" is taking over.
I tried to serve the register as follows;
*((volatile unsigned int*)(0xf001000e))=0x556c;
*((volatile unsigned int*)(0xf001000e))=0xaa39;
But it does not take effect. I thought that since u-boot had set up the
IMMR
to 0xf000'0000 I could
directly write to the register as above.
Any clues why this does not work?
Thx // Matias
[-- Attachment #2: Type: text/html, Size: 3550 bytes --]
^ permalink raw reply
* Re: 8270 & Watchdog - early start - II
From: Laurent Pinchart @ 2007-09-20 11:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <AEA1A32F001C6B4F98614B5B80D7647D02D73F76@esealmw115.eemea.ericsson.se>
On Thursday 20 September 2007 12:06, Matias Sundman wrote:
> Hi Guys,
> The Software Service Register (SWSR) is 16-bit wide which Laurent
> Pinchart [laurentp@cse-semaphore.com] so nicely pointed out for me.
> So it actually works with;
> *((volatile unsigned short*)(0xf001000e))=3D0x556c;
> *((volatile unsigned short*)(0xf001000e))=3D0xaa39;
You still shouldn't use direct access with MMU enabled. Use the global CPM=
=20
mapping and the I/O access macros.
out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0x556c);
out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0xaa39);
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=C3=A9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: 8270 & Watchdog - early start - II
From: Laurent Pinchart @ 2007-09-20 11:44 UTC (permalink / raw)
To: samppa; +Cc: linuxppc-embedded
In-Reply-To: <14733.194.237.142.6.1190286678.squirrel@www.sundmangroup.com>
On Thursday 20 September 2007 13:11, samppa@sundmangroup.com wrote:
> > You still shouldn't use direct access with MMU enabled. Use the global
> > CPM mapping and the I/O access macros.
>
> I understand, but I need to kick on the WDT before "cpm2_immr"
> is initialized dur to timing constraints.
You can then probably get away with the BAT mapping. However you should sti=
ll=20
use the I/O access macro out_be16.
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: 8270 & Watchdog - early start - II
From: samppa @ 2007-09-20 11:11 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200709201322.08359.laurentp@cse-semaphore.com>
>>> You still shouldn't use direct access with MMU enabled. Use the global
CPM
> mapping and the I/O access macros.
I understand, but I need to kick on the WDT before "cpm2_immr"
is initialized dur to timing constraints.
Cheers // Matias
> On Thursday 20 September 2007 12:06, Matias Sundman wrote:
>> Hi Guys,
>> The Software Service Register (SWSR) is 16-bit wide which Laurent
>> Pinchart [laurentp@cse-semaphore.com] so nicely pointed out for me.
>> So it actually works with;
>> *((volatile unsigned short*)(0xf001000e))=0x556c;
>> *((volatile unsigned short*)(0xf001000e))=0xaa39;
>
> You still shouldn't use direct access with MMU enabled. Use the global CPM
> mapping and the I/O access macros.
>
> out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0x556c);
> out_be16(&cpm2_immr->im_siu_conf.siu_82xx.sc_swsr, 0xaa39);
>
> Best regards,
>
> --
> Laurent Pinchart
> CSE Semaphore Belgium
>
> Chaussée de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Cleanups for physmap_of.c (v2)
From: Josh Boyer @ 2007-09-20 12:33 UTC (permalink / raw)
To: David Gibson; +Cc: David Woodhouse, Vitaly Wool, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070920012225.GG14404@localhost.localdomain>
On Thu, 20 Sep 2007 11:22:25 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> This patch includes a whole batch of smallish cleanups for
> drivers/mtd/physmap_of.c.
>
> - A bunch of uneeded #includes are removed
> - We switch to the modern linux/of.h etc. in place of
> asm/prom.h
> - Use some helper macros to avoid some ugly inline #ifdefs
> - A few lines of unreachable code are removed
> - A number of indentation / line-wrapping fixes
> - More consistent use of kernel idioms such as if (!p) instead
> of if (p == NULL)
> - Clarify some printk()s and other informative strings.
> - parse_obsolete_partitions() now returns 0 if no partition
> information is found, instead of returning -ENOENT which the caller
> had to handle specially.
> - (the big one) Despite the name, this driver really has
> nothing to do with drivers/mtd/physmap.c. The fact that the flash
> chips must be physically direct mapped is a constrant, but doesn't
> really say anything about the actual purpose of this driver, which is
> to instantiate MTD devices based on information from the device tree.
> Therefore the physmap name is replaced everywhere within the file with
> "of_flash". The file itself and the Kconfig option is not renamed for
> now (so that the diff is actually a diff). That can come later.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Looks great this time. Tested on Ebony and Walnut. I've applied it to
my tree.
josh
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-09-20 12:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git for-2.6.24
to receive the following updates:
David Gibson (1):
[POWERPC] Cleanups for physmap_of.c (v2)
Hollis Blanchard (1):
[POWERPC] 4xx: Implement udbg_getc() for 440
Josh Boyer (5):
[POWERPC] cuimage for Bamboo board
[POWERPC] Make partitions optional in physmap_of
[POWERPC] 4xx: Convert Walnut flash mappings to new binding
[POWERPC] 4xx: Convert Seqouia flash mappings to new binding
[POWERPC] Update PowerPC 4xx entry in MAINTAINERS
Valentine Barshak (3):
[POWERPC] Add 64-bit resources support to pci_iomap
[POWERPC] 4xx: Fix Bamboo MAL0 dts entry.
[POWERPC] 4xx: Fix Sequoia MAL0 and EMAC dts entries.
MAINTAINERS | 3 +
arch/powerpc/boot/44x.h | 2 +-
arch/powerpc/boot/Makefile | 4 +-
arch/powerpc/boot/bamboo.c | 8 +-
arch/powerpc/boot/cuboot-bamboo.c | 30 +++++
arch/powerpc/boot/dts/bamboo.dts | 2 +-
arch/powerpc/boot/dts/sequoia.dts | 46 +++++--
arch/powerpc/boot/dts/walnut.dts | 17 ++-
arch/powerpc/boot/treeboot-bamboo.c | 22 +++-
arch/powerpc/configs/sequoia_defconfig | 91 +++++++++++++-
arch/powerpc/kernel/iomap.c | 4 +-
arch/powerpc/kernel/udbg_16550.c | 11 ++
drivers/mtd/maps/physmap_of.c | 222 ++++++++++++++------------------
13 files changed, 304 insertions(+), 158 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-bamboo.c
^ permalink raw reply
* 4xx git tree moved
From: Josh Boyer @ 2007-09-20 12:42 UTC (permalink / raw)
To: linuxppc-dev
For those interested in 4xx, I've moved my git tree to kernel.org. You
can find it here:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc.git
josh
^ permalink raw reply
* [PATCH] [POWERPC] Fix QEIC->MPIC cascading
From: Anton Vorontsov @ 2007-09-20 13:02 UTC (permalink / raw)
To: linuxppc-dev
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
Patch adds flow level "end" handler to the MPIC, and QEIC calls
it when QEIC's interrupt processing finished.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/mpic.c | 3 +++
arch/powerpc/sysdev/qe_lib/qe_ic.c | 6 ++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8de29f2..bee2d5b 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -846,6 +846,7 @@ static struct irq_chip mpic_irq_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_irq,
.eoi = mpic_end_irq,
+ .end = mpic_end_irq,
.set_type = mpic_set_irq_type,
};
@@ -854,6 +855,7 @@ static struct irq_chip mpic_ipi_chip = {
.mask = mpic_mask_ipi,
.unmask = mpic_unmask_ipi,
.eoi = mpic_end_ipi,
+ .end = mpic_end_ipi,
};
#endif /* CONFIG_SMP */
@@ -864,6 +866,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_ht_irq,
.eoi = mpic_end_ht_irq,
+ .end = mpic_end_ht_irq,
.set_type = mpic_set_irq_type,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 55e6f39..8e743e0 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -328,6 +328,9 @@ void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
@@ -337,6 +340,9 @@ void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void __init qe_ic_init(struct device_node *node, unsigned int flags)
--
1.5.0.6
^ permalink raw reply related
* Kernel 2.6 and INITRAMFS in one file booting problem on ml403
From: Mirek23 @ 2007-09-20 13:03 UTC (permalink / raw)
To: linuxppc-embedded
Dear All,
I am dealing with kernel 2.6.23 (by Grant) on virtex-4 (ml403 like
evaluation board with ppc405 built-in processor). The kernel boots fine by
means of u-boot 1.2.0 when using nfs mounted root files system.
My Board has 32MB of RAM memory (0x00000000 - 0x1ffffff)
Right now I wanted to combine the linux kernel and the root file system in
one file in order to store it in the Flash memory.
I was able to build sucessfuly the kernel image which conatins the rootfile
system. Unfortunately during booting the rootfile system is not recognized.
My linux image with built-in the root fs has 6.7 MB. The uncompressed
rootfile system has 17 MB.
Steps which I have done are as following:
On my embedded system I use u-boot 1.2.0
1. I load via tftp the the uImageWithRamFs
tftp 0x1500000 uImageWithRamFs
2. Next I execute the image
bootm 0x1500000
The output is as following:
## Booting image at 01500000 ...
Image Name: Linux-2.6.23-rc2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 6983377 Bytes = 6.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
[ 0.000000] Linux version 2.6.23-rc2 (root@pc5215) (gcc version 4.0.2)
#13 Thu Sep 20 13:49:26 CEST 2007
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 8192
[ 0.000000] Normal 8192 -> 8192
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 8192
[ 0.000000] Built 1 zonelists in Zone order. Total pages: 8128
[ 0.000000] Kernel command line: console=ttyUL0 root=/dev/ram rw
ip=129.118.144.82:129.118.144.113:129.118.144.1:255.255.255.0:virtex4-mirek:eth0:off
panic=1
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
[ 0.000000] PID hash table entries: 128 (order: 7, 512 bytes)
[ 0.000289] Console: colour dummy device 80x25
[ 0.000615] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.001181] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.009923] Memory: 24304k available (1656k kernel code, 544k data, 5968k
init, 0k highmem)
[ 0.097097] Mount-cache hash table entries: 512
[ 0.103761] NET: Registered protocol family 16
[ 0.144382] NET: Registered protocol family 2
[ 0.180548] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.181582] TCP established hash table entries: 1024 (order: 1, 8192
bytes)
[ 0.181903] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.182122] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.182200] TCP reno registered
[ 7.835360] io scheduler noop registered
[ 7.835446] io scheduler anticipatory registered (default)
[ 7.835524] io scheduler deadline registered
[ 7.835801] io scheduler cfq registered
[ 8.529280] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a uartlite
[ 8.530949] console [ttyUL0] enabled
[ 10.549186] RAMDISK driver initialized: 2 RAM disks of 16384K size 1024
blocksize
[ 10.648123] loop: module loaded
[ 10.688195] tun: Universal TUN/TAP device driver, 1.6
[ 10.749201] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 10.825474] XTemac: using FIFO direct interrupt driven mode.
[ 10.893905] eth%d: XTemac: PHY detected at address 3.
[ 10.956872] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC3020000,
irq=0
[ 11.040788] eth0: XTemac id 1.0f, block id 5, type 8
[ 11.101628] mice: PS/2 mouse device common for all mice
[ 11.164837] TCP cubic registered
[ 11.203869] NET: Registered protocol family 1
[ 11.256350] NET: Registered protocol family 17
[ 11.813548] eth0: XTemac: Options: 0xb8f2
[ 15.835154] eth0: XTemac: We renegotiated the speed to: 100
[ 15.901906] eth0: XTemac: speed set to 100Mb/s
[ 16.985905] IP-Config: Complete:
[ 17.022598] device=eth0, addr=129.118.144.82, mask=255.255.255.0,
gw=129.118.144.1,
[ 17.119958] host=virtex4-mirek, domain=, nis-domain=(none),
[ 17.192276] bootserver=129.118.144.113, rootserver=129.118.144.113,
rootpath=
[ 17.292444] List of all partitions:
[ 17.334388] No filesystem could mount root, tried: ext2 msdos vfat
[ 17.409805] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
[ 17.509374] Rebooting in 1 seconds..<NULL>
[ 18.563180] Oops: Exception in kernel mode, sig: 4 [#1]
[ 18.625695] NIP: c07e0000 LR: c085fe70 CTR: c085fee0
[ 18.685072] REGS: c085fdb0 TRAP: 2000000 Not tainted (2.6.23-rc2)
[ 18.761190] MSR: 00000f13 <DR> CR: c01ca858 XER: c00e8c80
[ 18.827869] TASK = c085cba0[1] 'swapper' THREAD: c085e000
[ 18.890350] GPR00: c085fdd0 c000437c 00000000 00008000 c01c37e0 000003e5
c01c3858 00008000
My .config file which is used to build the linux kernel has following
settings which refer to the initramfs:
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_INITRAMFS_SOURCE="smallRootFs.cpio"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_NVRAM is not set
CONFIG_RAMFS=y
I appreciate any hint on that why the root fs is not recognized
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Kernel-2.6-and-INITRAMFS-in-one-file-booting-problem-on-ml403-tf4487411.html#a12796771
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c
From: Mel Gorman @ 2007-09-20 13:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-ide, linux-kernel, jeff, linuxppc-dev
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
doesn't show up on other arches because this driver is specific to the
architecture.
drivers/ata/pata_scc.c: In function `scc_bmdma_status':
drivers/ata/pata_scc.c:734: error: structure has no member named `active_tag'
drivers/ata/pata_scc.c: In function `scc_pata_prereset':
drivers/ata/pata_scc.c:866: warning: passing arg 1 of `ata_std_prereset' from incompatible pointer type
drivers/ata/pata_scc.c: In function `scc_error_handler':
drivers/ata/pata_scc.c:908: warning: passing arg 2 of `ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 3 of `ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 5 of `ata_bmdma_drive_eh' from incompatible pointer type
make[2]: *** [drivers/ata/pata_scc.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2
The problem seems to be in git-libata-all.patch but based on similar
changes in this patch, the following patch should be the fix.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
drivers/ata/pata_scc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/drivers/ata/pata_scc.c linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/ata/pata_scc.c
--- linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/drivers/ata/pata_scc.c 2007-09-18 11:29:26.000000000 +0100
+++ linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/ata/pata_scc.c 2007-09-20 11:51:01.000000000 +0100
@@ -731,7 +731,7 @@ static u8 scc_bmdma_status (struct ata_p
void __iomem *mmio = ap->ioaddr.bmdma_addr;
u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
u32 int_status = in_be32(mmio + SCC_DMA_INTST);
- struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
+ struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
static int retry = 0;
/* return if IOS_SS is cleared */
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Build failure on ppc64 drivers/block/ps3disk.c
From: Mel Gorman @ 2007-09-20 13:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, jens.axboe
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
allmodconfig on ppc64 fails to build with the following error
drivers/block/ps3disk.c: In function `ps3disk_probe':
drivers/block/ps3disk.c:509: error: implicit declaration of function `blk_queue_issue_flush_fn'
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The problem seems to be coming from git-block.patch. Jens, glancing through
the patch, the function blk_queue_issue_flush_fn() seems to be have been
made redundant. Based on that, this looks like the correct fix but it needs
a review. Thanks
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
drivers/block/ps3disk.c | 21 ---------------------
1 file changed, 21 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c
--- linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c 2007-09-11 03:50:29.000000000 +0100
+++ linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c 2007-09-20 14:17:43.000000000 +0100
@@ -414,26 +414,6 @@ static void ps3disk_prepare_flush(struct
req->cmd_type = REQ_TYPE_FLUSH;
}
-static int ps3disk_issue_flush(struct request_queue *q, struct gendisk *gendisk,
- sector_t *sector)
-{
- struct ps3_storage_device *dev = q->queuedata;
- struct request *req;
- int res;
-
- dev_dbg(&dev->sbd.core, "%s:%u\n", __func__, __LINE__);
-
- req = blk_get_request(q, WRITE, __GFP_WAIT);
- ps3disk_prepare_flush(q, req);
- res = blk_execute_rq(q, gendisk, req, 0);
- if (res)
- dev_err(&dev->sbd.core, "%s:%u: flush request failed %d\n",
- __func__, __LINE__, res);
- blk_put_request(req);
- return res;
-}
-
-
static unsigned long ps3disk_mask;
static DEFINE_MUTEX(ps3disk_mask_mutex);
@@ -506,7 +486,6 @@ static int __devinit ps3disk_probe(struc
blk_queue_dma_alignment(queue, dev->blk_size-1);
blk_queue_hardsect_size(queue, dev->blk_size);
- blk_queue_issue_flush_fn(queue, ps3disk_issue_flush);
blk_queue_ordered(queue, QUEUE_ORDERED_DRAIN_FLUSH,
ps3disk_prepare_flush);
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Build failure on ppc64 drivers/block/ps3disk.c
From: Jens Axboe @ 2007-09-20 13:32 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20070920132512.GF24105@skynet.ie>
On Thu, Sep 20 2007, Mel Gorman wrote:
> allmodconfig on ppc64 fails to build with the following error
>
> drivers/block/ps3disk.c: In function `ps3disk_probe':
> drivers/block/ps3disk.c:509: error: implicit declaration of function `blk_queue_issue_flush_fn'
> make[2]: *** [drivers/block/ps3disk.o] Error 1
> make[1]: *** [drivers/block] Error 2
> make: *** [drivers] Error 2
>
> The problem seems to be coming from git-block.patch. Jens, glancing through
> the patch, the function blk_queue_issue_flush_fn() seems to be have been
> made redundant. Based on that, this looks like the correct fix but it needs
> a review. Thanks
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> ---
> drivers/block/ps3disk.c | 21 ---------------------
> 1 file changed, 21 deletions(-)
>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c
> --- linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c 2007-09-11 03:50:29.000000000 +0100
> +++ linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c 2007-09-20 14:17:43.000000000 +0100
> @@ -414,26 +414,6 @@ static void ps3disk_prepare_flush(struct
> req->cmd_type = REQ_TYPE_FLUSH;
> }
>
> -static int ps3disk_issue_flush(struct request_queue *q, struct gendisk *gendisk,
> - sector_t *sector)
> -{
> - struct ps3_storage_device *dev = q->queuedata;
> - struct request *req;
> - int res;
> -
> - dev_dbg(&dev->sbd.core, "%s:%u\n", __func__, __LINE__);
> -
> - req = blk_get_request(q, WRITE, __GFP_WAIT);
> - ps3disk_prepare_flush(q, req);
> - res = blk_execute_rq(q, gendisk, req, 0);
> - if (res)
> - dev_err(&dev->sbd.core, "%s:%u: flush request failed %d\n",
> - __func__, __LINE__, res);
> - blk_put_request(req);
> - return res;
> -}
> -
> -
> static unsigned long ps3disk_mask;
>
> static DEFINE_MUTEX(ps3disk_mask_mutex);
> @@ -506,7 +486,6 @@ static int __devinit ps3disk_probe(struc
> blk_queue_dma_alignment(queue, dev->blk_size-1);
> blk_queue_hardsect_size(queue, dev->blk_size);
>
> - blk_queue_issue_flush_fn(queue, ps3disk_issue_flush);
> blk_queue_ordered(queue, QUEUE_ORDERED_DRAIN_FLUSH,
> ps3disk_prepare_flush);
Thanks! The patch is correct, the prepare_flush() hook is now all that
is needed. I will apply this to my barrier branch, where this originates
from.
--
Jens Axboe
^ permalink raw reply
* 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-20 13:37 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List
In-Reply-To: <20070920132512.GF24105@skynet.ie>
On Thu, 20 Sep 2007, Mel Gorman wrote:
>
> allmodconfig on ppc64 fails to build with the following error
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/ata/pata_scc.c
drivers/md/raid6int8.c
drivers/net/spider_net.c
drivers/net/pasemi_mac.c
drivers/pci/hotplug/rpadlpar_sysfs.c
I was in a hurry so didn't record the errors, just noted down the files
and disabled them from .config and continued building ... I'll get back
to fixing these up tonight (if you don't do that by then already).
Satyam
^ 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