* help linux for linux2.6
From: vincent.liu @ 2007-11-09 6:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200711091434079212507@bmrtech.com>
Hi
These days I am working on a MPC8270 based board with linux 2.6.10 kernel.
When I use the default kernel and load the uImage to the target board.
The kernel hangs after uncompressing kernel image ... ok .
I am freshman in the embedded linux area,So I do not know how to go on this project.
>From internet , I searched many articles,and no gain.
Please help me .
Thanks a lot.
--------------
vincent.liu
2007-11-09
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-09 7:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194564017.6561.21.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Fri, 09 Nov 2007 10:20:17 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
>
> On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I tested my patches for the AmigaOne platform with the lastest
> > 2.6.24-rc2 kernel snapshot. The kernel runs through all initcalls, but
> > locks up completely after calling INIT (/sbin/init) by kernel_execve().
> > Thus I couldn't capture any kernel oops or panic output. Also the magic
> > sysrq key doesn't work. Enabling debug code for soft lockups and
> > spinlock debugging didn't reveal any information.
> > I'm not sure, but I think it is the same problem I had with all kernels
> > >= 2.6.17. All of these kernels lock up shortly before or right at
> > calling the init program (resp. as soon as the kernel forks some kernel
> > theads).
> > Any suggestions on how to track down this problem?
>
> You don't have a HW debugger or anything like that ?
>
> Ben.
Unfortunately, no. A BDI2000 is too costly for me.
I tried to use /bin/sh as init program and was able to enter a command,
but then the machine locked up, too.
Could that be a problem with a CPU sleeping/idle code?
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-09 7:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071109074155.266120@gmx.net>
> I tried to use /bin/sh as init program and was able to enter a command,
> but then the machine locked up, too.
> Could that be a problem with a CPU sleeping/idle code?
That's possibly an issue, try disabling power save if any for that CPU
type. If it worked and broke, you may have to bisect tho.
Ben.
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Domen Puncer @ 2007-11-09 9:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, netdev
In-Reply-To: <9e4733910711082131v70c4b7bm2b00445b7e62c33f@mail.gmail.com>
On 09/11/07 00:31 -0500, Jon Smirl wrote:
> This is the reason I couldn't get user space started or connect to my
> nfs server. Patch is against current linus git.
>
> mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> where the wrong skb buffer was being referenced.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Domen Puncer <domen.puncer@telargo.com>
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
>
> ---
>
> drivers/net/fec_mpc52xx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index a8a0ee2..ddfcc0b 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
From: Kumar Gala @ 2007-11-09 9:58 UTC (permalink / raw)
To: linuxppc-dev
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
---
include/asm-powerpc/tlbflush.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
--
1.5.3.3
^ permalink raw reply related
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-11-09 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
arch/powerpc/Makefile | 3 +++
arch/powerpc/sysdev/cpm_common.c | 4 +---
include/asm-powerpc/tlbflush.h | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
Kumar Gala (2):
[POWERPC] Add -mno-spe for ARCH=powerpc builds
[POWERPC] Fix oops related to 4xx flush_tlb_page modification
Scott Wood (1):
[POWERPC] cpm: Fix a couple minor issues in cpm_common.c.
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 12:07 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W14EEE9667CD669878D3BD0B28A0@phx.gbl>
Hi again,
i've learned a little bit :)
- I have download the zImage.elf via the EDK flash loader
- The flash loader creates a bootloader, this is also running on start up=
:)
But ... It stops with an error-message after a few seconds:
EDK Bootloader:
Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted=
What now ?
Georg
MingLiu wrote:
> Dear Georg,
> I guess you were talking about the booting process of the system, both =
HW and the SW, from the flash memory. This process should be like this:
>
> 1. Store your HW bitstream and Linux kernel in flash memories. If neede=
d, perhaps you want another bootloader program, such as U-boot also insid=
e.=20
>
> 2. In your HW bitstream, you need one bootloader which helps you to loa=
d the software and execute it in DDR-ram. EDK helps you to generate such =
a bootloader when you design.=20
>
> 3. Durong Power on, HW bitstream (with an EDK bootloader included) will=
be loaded into FPGA and configure the FPGA, then the EDK bootloader will=
load your Linux kernel into DDR-Ram and execute it there. Thus your linu=
x could run.=20
>
> This is a normal process. If you want to execute the program in flash d=
irectly, that's another story. Also you should know, for the booting proc=
ess, MTD driver is not necessary. The driver is only used when you want t=
o access flash memories when you booted your Linux kernel.
>
> Clear or not? :)
>
> Best Regards
> Ming
>
> ----------------------------------------> Date: Wed, 7 Nov 2007 13:00:3=
5 +0100> From: g.schardt@fz-juelich.de> To: Linuxppc-embedded@ozlabs.org>=
Subject: Bootloader & Flash>> Hi,>> i use the AVnet Xilinx4 FX12 Minimod=
ule and until now, i use system-ace> to configure the fpga and boot the l=
inux kernel.> But now, i want to boot from the on board flash memory and =
have no idea> where to start.>> I think i have to:> - save the fpga confi=
guration in the fpga-prom> - use/program some kind of bootloader store in=
fpga block ram to jump to> the flash-adress where the executable linux k=
ernel resist> - use the mtd-device driver to mount root fs on the same fl=
ash some> address later>> Is this the right way ?>>> Regards> Georg>>>>>>=
> -----------------------------------------------------------------------=
------------------> -----------------------------------------------------=
------------------------------------> Forschungszentrum J=C3=BClich GmbH>=
52425 J=C3=BClich>> Sitz der Gesellschaft: J=C3=BClich> Eingetragen im H=
andelsregister des Amtsgerichts D=C3=BCren Nr. HR B 3498> Vorsitzende des=
Aufsichtsrats: MinDirig'in B=C3=A4rbel Brumme-Bothe> Gesch=C3=A4ftsf=C3=BC=
hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.>=
Vorsitzender)> ---------------------------------------------------------=
--------------------------------> ---------------------------------------=
--------------------------------------------------> _____________________=
__________________________> Linuxppc-embedded mailing list> Linuxppc-embe=
dded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> MSN =E4=B8=AD=E6=96=87=E7=BD=91=EF=BC=8C=E6=9C=80=E6=96=B0=E6=97=B6=E5=B0=
=9A=E7=94=9F=E6=B4=BB=E8=B5=84=E8=AE=AF=EF=BC=8C=E7=99=BD=E9=A2=86=E8=81=9A=
=E9=9B=86=E9=97=A8=E6=88=B7=E3=80=82
> http://cn.msn.com
=0A=0A-------------------------------------------------------------------------=
----------------=0A-----------------------------------------------------------=
------------------------------=0AForschungszentrum J=C3=BClich GmbH=0A52425 J=C3=BClich=
=0A=0ASitz der Gesellschaft: J=C3=BClich=0AEingetragen im Handelsregister des Amtsgeri=
chts D=C3=BCren Nr. HR B 3498=0AVorsitzende des Aufsichtsrats: MinDirig'in B=C3=A4rbel=
Brumme-Bothe=0AGesch=C3=A4ftsf=C3=BChrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr.=
Ulrich Krafft (stellv. =0AVorsitzender)=0A-------------------------------------=
----------------------------------------------------=0A-----------------------=
------------------------------------------------------------------=0A
^ permalink raw reply
* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-09 12:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47333EDA.4080907@ru.mvista.com>
Valentine Barshak wrote:
> Roel Kluin wrote:
>> I guess it should be done after the last usage of kb_data or fpga_status?
>
> I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
> = kb_data + 1) is used by the serio driver
> (drivers/input/serio/i8042-ppcio.h).
> Please note that we just ioremap and assign pointers here, not actually
> reading the registers.
> Also, looks like you unmap the fpga registers too early.
> Thanks,
> Valentine.
Thanks for your pointers. I'm new, so I'm not sure how this should be done. I
have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower.
possibly the latter could be done before the sycamore_rtc_base assignment?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..6ce4815 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -132,6 +132,7 @@ sycamore_setup_arch(void)
sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR;
TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base,
sycamore_rtc_base, 8);
+ iounmap(fpga_status);
/* Identify the system */
printk(KERN_INFO "IBM Sycamore (IBM405GPr) Platform\n");
^ permalink raw reply related
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 12:51 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47344D70.4050308@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hi,
> - I have download the zImage.elf via the EDK flash loader> - The flash loader creates a bootloader, this is also running on start up :)
What you need to store in flash memory, is not the .elf file. Before you use EDK flash loader to burn your linux kernel in flash, .elf file should be transfered into .srec file, just like the below reminds you: SREC line is corrupted.
> But ... It stops with an error-message after a few seconds:> > EDK Bootloader:> Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted> > What now ?
Hopefully it helps.
BR
Ming
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* Appletouch going wild
From: Andreas Schwab @ 2007-11-09 12:58 UTC (permalink / raw)
To: linux-input; +Cc: linuxppc-dev
Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is
going wild, emitting random movement events even when not being touched.
That started only with 2.6.24-rc1. The only way to stop it is to reload
the appletouch module. My guess would be that reinitializing the
touchpad can result in some kind of race condition.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* auto soft reset after kernel crash?
From: robert lazarski @ 2007-11-09 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to read the __log_buf after a kernel crash on a custom
board via a software reset. While I'm waiting for the hardware guys to
give me a sw reset button, I've noticed that the particular 2.6.22
kernel I'm using software resets itself around 7 minutes after a
crash. I tried a 2.6.23 kernel to see if my problem was related to
kernel version and it doesn't reset itself. Is this reset indeed a
kernel feature? How do I enable / disable it and set the amount of
time it waits before it resets? I went thru the menuconfig features
and couldn't enable a sw reset. Any ideas?
Thanks,
Robert
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Michael Neuling, Jan-Bernd Themann, netdev, linux-kernel,
linux-ppc, Christoph Raisch, Paul Mackerras, Marcus Eder,
Stefan Roscher
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Grant Likely @ 2007-11-09 13:57 UTC (permalink / raw)
To: Domen Puncer, Jeff Garzik; +Cc: PowerPC dev list, netdev
In-Reply-To: <20071109091245.GA3148@nd47.coderock.org>
On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > This is the reason I couldn't get user space started or connect to my
> > nfs server. Patch is against current linus git.
> >
> > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Jeff, can you please pick this up for .24?
Thanks,
g.
>
> I can't test it at the moment, but the patch is obviously correct,
> mapped buffer should be the _same_ as submitted.
>
> >
> > ---
> >
> > drivers/net/fec_mpc52xx.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > index a8a0ee2..ddfcc0b 100644
> > --- a/drivers/net/fec_mpc52xx.c
> > +++ b/drivers/net/fec_mpc52xx.c
> > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> >
> > rskb =3D bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > (struct bcom_bd **)&bd);
> > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FRO=
M_DEVICE);
> > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FR=
OM_DEVICE);
> >
> > /* Test for errors in received frame */
> > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> > bcom_prepare_next_buffer(priv->rx_dmatsk);
> >
> > bd->status =3D FEC_RX_BUFFER_SIZE;
> > - bd->skb_pa =3D dma_map_single(&dev->dev, rskb->data,
> > + bd->skb_pa =3D dma_map_single(&dev->dev, skb->data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>
> --
> Domen Puncer | Research & Development
> .........................................................................=
....................
> Telargo d.o.o. | Zagreb=9Aka cesta 20 | 2000 Maribor | Slovenia
> .........................................................................=
....................
> www.telargo.com
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 14:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071107133426.63593b98.sfr@canb.auug.org.au>
Hi Stephen,
Stephen Rothwell wrote:
>
> On Tue, 06 Nov 2007 21:05:20 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +
>> +#include <linux/pci.h>
>> +#include <linux/of.h>
>> +#include <asm/time.h>
>> +#include <asm/io.h>
>
> Its not clear to me that you need any of the above four includes.
#include <asm/time.h> is needed for generic_calibrate_decr() but other
few includes are in fact not necessary. Thanks.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3 07/13] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-11-09 14:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106223646.GD31367@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 06, 2007 at 09:05:48PM +0100, Marian Balakowicz wrote:
>> Add device tree source file for TQM5200 board.
> [snip]
>> + usb@1000 {
>> + device_type = "usb-ohci-be";
>
> This device_type is bogus. Remember having a valid device_type is the
> exception not the rule. Really the only common device_type values are
> "cpu", "memory", "network" and "serial".
Ok, rechecked this one, doesn't seem necessary, removed.
>> + serial@2000 { // PSC1
>> + device_type = "serial";
>> + compatible = "mpc5200-psc-uart";
>> + port-number = <0>; // Logical port assignment
>
> I know you said this is still needed, but the driver really needs to
> be fixed. This is not a proper way of using the device tree for
> logical numbering.
True, driver needs fixing, but there are also other boards that use
that driver, and I am not able to test them right now. And, as I
recall Grant mentioned that he's working on straightening this up.
Cheers,
m.
^ permalink raw reply
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 14:16 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W21A6D92355C81BE1341628B2840@phx.gbl>
Argl :)
The error was so ... simple.
The Flash device is broken. I take a new MiniModul and all things are
running.
Thanks a lot
Georg
MingLiu wrote:
> Hi,
>
> > - I have download the zImage.elf via the EDK flash loader
> > - The flash loader creates a bootloader, this is also running on
> start up :)
>
> What you need to store in flash memory, is not the .elf file. Before
> you use EDK flash loader to burn your linux kernel in flash, .elf file
> should be transfered into .srec file, just like the below reminds you:
> SREC line is corrupted.
>
>
> > But ... It stops with an error-message after a few seconds:
> >
> > EDK Bootloader:
> > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is
> corrupted
> >
> > What now ?
>
> Hopefully it helps.
>
> BR
> Ming
>
> -----------------------------------------------------------------------=
-
> =D3=C3 Windows Live Spaces =D5=B9=CA=BE=B8=F6=D0=D4=D7=D4=CE=D2=A3=AC=D3=
=EB=BA=C3=D3=D1=B7=D6=CF=ED=C9=FA=BB=EE=A3=A1 =C1=CB=BD=E2=B8=FC=B6=E0=D0=
=C5=CF=A2=A3=A1
> <http://spaces.live.com/?page=3DHP>
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
Forschungszentrum J=A8=B9lich GmbH
52425 J=A8=B9lich
Sitz der Gesellschaft: J=A8=B9lich
Eingetragen im Handelsregister des Amtsgerichts D=A8=B9ren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe
Gesch"aftsf=A8=B9hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich=
Krafft (stellv.=20
Vorsitzender)
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
^ permalink raw reply
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 14:19 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47346BB7.2000009@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Sometimes the simplest error is the most diffucult one to be found. :)
Have fun.
BR
Ming
> Date: Fri, 9 Nov 2007 15:16:23 +0100> From: g.schardt@fz-juelich.de> To: eemingliu@hotmail.com> CC: linuxppc-embedded@ozlabs.org> Subject: Re: Bootloader & Flash> > Argl :)> > The error was so ... simple.> The Flash device is broken. I take a new MiniModul and all things are> running.> > Thanks a lot> Georg> > MingLiu wrote:> > Hi,> >> > > - I have download the zImage.elf via the EDK flash loader> > > - The flash loader creates a bootloader, this is also running on> > start up :)> >> > What you need to store in flash memory, is not the .elf file. Before> > you use EDK flash loader to burn your linux kernel in flash, .elf file> > should be transfered into .srec file, just like the below reminds you:> > SREC line is corrupted.> >> >> > > But ... It stops with an error-message after a few seconds:> > >> > > EDK Bootloader:> > > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is> > corrupted> > >> > > What now ?> >> > Hopefully it helps.> >> > BR> > Ming> >> > ------------------------------------------------------------------------> > 用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！> > <http://spaces.live.com/?page=HP>> > > > -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------> Forschungszentrum Jülich GmbH> 52425 Jülich> > Sitz der Gesellschaft: Jülich> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498> Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe> Gesch"aftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. > Vorsitzender)> -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 2852 bytes --]
^ permalink raw reply
* Re: [PATCH v3 12/13] [POWERPC] Promess Motion-PRO DTS
From: Marian Balakowicz @ 2007-11-09 14:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106224200.GE31367@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 06, 2007 at 09:06:34PM +0100, Marian Balakowicz wrote:
>> Add device tree source file for Motion-PRO board.
> [snip]
>> + motionpro-statusled@660 { // Motion-PRO status LED
>> + compatible = "promess,motionpro-statusled";
>> + reg = <660 10>;
>> + interrupts = <1 f 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + blink-delay = <64>; // 100 msec
>> + };
>> +
>> + motionpro-readyled@670 { // Motion-PRO ready LED
>> + compatible = "promess,motionpro-readyled";
>> + reg = <670 10>;
>> + interrupts = <1 10 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + };
>
> Is there actually any difference in behaviour betweeen the two LEDs?
> If not, they should probably have the same compatible value, and
> perhaps a "label" property or some such to associate them with a
> particular LED.
In fact they are identical, so I have used the same compatible
property and added label property do distinguish them.
> [snip]
>> + spi@f00 {
>> + device_type = "spi";
>
> No device_type!
Removed.
>> + compatible = "mpc5200b-spi","mpc5200-spi";
>> + reg = <f00 20>;
>> + interrupts = <2 d 0 2 e 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + };
>> +
>> + usb@1000 {
>> + device_type = "usb-ohci-be";
>
> Nor here.
Removed.
> [snip]
>> + // PSC2 in spi master mode
>> + spi@2200 { // PSC2
>> + compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
>> + cell-index = <1>;
>
>>From your description, this is an incorrect usage of cell-index - it
> should *only* be used to index into SoC shared registers; never for
> logical numbering.
Again true, but the situation is similar to the one with the "serial"
node.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: Jon Loeliger @ 2007-11-09 14:32 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071109001345.GD18592@localhost.localdomain>
So, like, the other day David Gibson mumbled:
>
> But you do take a hit w.r.t. *minimum* representation size - there's
> no form amongst all the possibilities here more compact than pure hex.
> Especially since spaces are optional in the old form. The fact that
> [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
> original form.
>
> The point of [] is for random binary data which is neither strings
> (even with the odd strange character) nor sensibly organized into
> 32-bit (or larger) integers. Wanting something other than hex here is
> much rarer than in the < > case.
>
> You're seeing < > and [ ] as basically the same thing - a list of
> values - with the only difference being the size of those values.
> That's not wrong, but it's not the only way to look at it - and it's
> not the way I was thinking of [ ] when I invented it. Your proposal
> makes perfect sense while you think of [] as a list of values - but
> not so much when it's thought of as a direct binary representation.
>
> So I'm thinking perhaps we need two different things here: a "list of
> values" representation, which can accomodate expressions and can also
> have multiple sizes (because expressions which are evaluated to a
> 16-bit or 64-bit value could also be useful under the right
> circumstances), and the [ ] "bytestring
> literal" representation. Perhaps something like:
>
> (32-bit values)
> <0xdeadbeef (1+1)>
> or <.32 0xdeadbeef (1+1)>
>
> (64-bit values)
> <.64 (0xdeadbeef << 32) (-1)>
> (8-bit values)
> <.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
>
> i.e. < > is list of values form, with size of each value as a sort of
> parameter (defaulting to 32-bit, of course). I'm not sure I like that
> particular syntax, it's just the first thing I came up with to
> demonstrate the idea.
Ah ha! I see. You want this, then:
x = <.srec 0000 C001C0DEGE75BABE F1>
OK. That was entirely joking. We all know that
the cool code does NOT get the babe.
Seriously though, I see your point, and I don't really
have a strong opinion here, so in the interest of making
some headway, we can just leave it as is for now.
If it turns out to be a bad decision later, we'll fix it. :-)
And with that issue behind us....
I'm going to post these patches to introduce the new DTS format!
Any last straggler comments?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 14:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711061525y79f9f99eneda32b09a77ddcd5@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> On 11/6/07, Wolfgang Denk <wd@denx.de> wrote:
>>
>> in message <fa686aa40711061304k4779d01cu7fd1b17d1d34e5a2@mail.gmail.com> you wrote:
>>> In other words; make the assumption that it is easier to change the
>>> kernel than it is to change the device tree.
>> Are you serious about this?
>>
>> Reading this from someone with your experience with device trees if
>> feeding my worst fears...
>
> I think I better clarify.
>
> Once a device tree is written and shipped on a deployed board, it may
> never change again. Or, the kernel version may be updated more
> frequently than the device tree.
>
> Say, for example, that in kernel 2.6.25 tqm5200 and cm5200 are both
> handled by the same platform code. And lets say that in 2.6.26 we
> decide that they really need to have separate platform code (perhaps
> due to a firmware bug that needs to be worked around on one board).
> In this case, "mpc5200-simple-platform" has suddenly become useless.
> Or, does mpc5200-simple-platform now describe the cm5200 or the
> tqm5200? (an assumption which cannot be made due to deployed boards
> of both types claiming "mpc5200-simple-platform").
>
> Trying to claim "compatible" at the board level is far more difficult
> than claiming it at the device level.
>
> Segher suggested on IRC: "for boards it is pretty much useless most of
> the time, i think -- use "model" instead"
I can imagine that we may get into various trouble (or at least the
situation is less flexible) if we are unable to update .dts file along
with the kernel image on a deployed board. If so, then in fact there
is little sens in using "mpc5200-simple-platform" compatible.
But how serious is that, does such situation frequently happen in
field? If we are able to update kernel image than what prevents .dts
file update?
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Grant Likely @ 2007-11-09 14:52 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4734721A.6030603@semihalf.com>
On 11/9/07, Marian Balakowicz <m8@semihalf.com> wrote:
> I can imagine that we may get into various trouble (or at least the
> situation is less flexible) if we are unable to update .dts file along
> with the kernel image on a deployed board. If so, then in fact there
> is little sens in using "mpc5200-simple-platform" compatible.
>
> But how serious is that, does such situation frequently happen in
> field? If we are able to update kernel image than what prevents .dts
> file update?
Not everything in the device tree is in the .dts file. U-boot or
other firmware can modify the device tree before passing it to the
kernel. It may not always be possible to update the device tree
without also updating the firmware. I already know of changes that
I'd like to make to the lite5200 tree which I know will break u-boot.
That isn't the situation in this particular case, but we must always
keep it in mind.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Scott Wood @ 2007-11-09 15:59 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4733AF6B.60807@gmail.com>
Jerry Van Baren wrote:
> My concern from the u-boot side is that u-boot has to know exactly
> *where* to put the expanded blob because it has to pass it to linux and
> keep it out of linux' way so it doesn't get "stepped on." Linux has an
> advantage in that it "owns" all of memory and can allocate and
> deallocate whatever and wherever and it won't step on itself (hopefully).
Linux is pretty careful not to step on the device tree; it marks the
area as reserved, and moves it if it really has to. The only scenario I
think would be problematic is if the kernel is started somewhere other
than zero, and has to relocate itself, and the relocation clobbers the
device tree. That's easily avoided by making sure the device tree is at
a higher address than the kernel -- and is really not much different
than the old bd_t mechanism, which didn't use a user provided address AFAIK.
> I'm assuming your boot wedge has the advantage of being able to use
> linux's malloc() and thus don't have to worry about coordinating with
> linux on memory allocation.
No, it uses its own malloc.
> With the current u-boot fdt command, you can resize the blob, and this
> can be done in a script with all the (somewhat limited) capabilities of
> the u-boot shell (an adaptation of hush).
OK, I'm just going by the behavior of the default boot commands on (at
least some of) our boards, which just give you an error if the blob
isn't already enlarged.
Maybe I should just poke Kim et al. about fixing our default environment
-- though I'm guessing it'd still have to know from the script how much
to enlarge the blob.
> In the u-boot world, we fixate on memory maps and putting things in
> specific places.
I've noticed. :-)
-Scott
^ 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