* I2C node in device tree breaks old-style drivers
From: Timur Tabi @ 2008-07-29 19:43 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
I'm trying to debug an I2C problem I've found in my old-style driver:
sound/soc/codecs/cs4270.c. My I2C probe function is working, but the I2C
subsystem cannot find my device. I know it's there, because U-Boot can probe it
just fine.
At first, I thought my problem was this:
static struct i2c_driver cs4270_i2c_driver = {
.driver = {
.name = "CS4270 I2C",
.owner = THIS_MODULE,
},
.id = I2C_DRIVERID_CS4270,
.attach_adapter = cs4270_i2c_attach,
.detach_client = cs4270_i2c_detach,
};
In a slightly older kernel (still 2.6.27), I had to change "CS4270 I2C" to
"cs4270" to get it to work. However, that change no longer makes a difference.
I turned on debugging and this is what I see:
i2c-core: driver [CS4270 I2C] registered
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x48
i2c-adapter i2c-0: master_xfer[0] W, addr=0x48, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x49
i2c-adapter i2c-0: master_xfer[0] W, addr=0x49, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4a
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4a, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4b
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4b, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4c
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4c, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4d
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4d, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4e
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4e, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4f
My device is at address 4F. The device tree defines a node for this device.
You can see it in arch/powerpc/boot/dts/mpc8610_hpcd.dts.
When I change the device tree so that it lists the device at an address other
than 4F, (e.g. "reg = <0x48>"), then my driver works.
So my conclusion is that specifying an I2C node in the device tree *requires*
that the driver be new-style. Is there any way we can fix this? I'm not going
to have time to update the CS4270 driver to a new-style interface before the
2.6.27 window closes.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Scott Wood @ 2008-07-29 19:39 UTC (permalink / raw)
To: Matvejchikov Ilya; +Cc: Ben Gardiner, linuxppc-embedded
In-Reply-To: <8496f91a0807291136v172b3b16t170088faf3f30b5b@mail.gmail.com>
On Tue, Jul 29, 2008 at 10:36:30PM +0400, Matvejchikov Ilya wrote:
> Have you tired to run 2.6.25 kernel? With 2.6.25.4 my console works
> fine! I suspect there is something like a regression....
Did you use CONFIG_PPC_CPM_NEW_BINDING in 2.6.25? It became mandatory in
2.6.26. Also, try commenting out cpm_setbrg() calls in case the
frequency is not being set properly.
2.6.26 introduced the allocation of the CPM2 SMC parameter RAM area; what
did your device node look like in 2.6.25? What happens if you use that
device tree with 2.6.26?
-Scott
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Scott Wood @ 2008-07-29 19:36 UTC (permalink / raw)
To: Ben Gardiner; +Cc: linuxppc-embedded
In-Reply-To: <488F385B.9030504@nanometrics.ca>
On Tue, Jul 29, 2008 at 11:33:47AM -0400, Ben Gardiner wrote:
> And my serial console output is stopping around the same point as
> Matvejchikov. I have baud 9600, so I'm guessing that it's cutoff because
> of this (please excuse me if this is wrong). NB: the console=ttyS0
> bootarg is there to get a working console when I boot back to 2.4.
> <snip console>
> Memory <- <0x0 0x8000000> (128MB)
> ENET0: local-mac-address <- 00:11:40:02:00:18
> CPU clock-frequency <- 0x3f940aa (67MHz)
> CPU timebase-frequency <- 0x1fce17 (2MHz)
> CPU bus-frequency <- 0x1fce170 (33MHz)
Try commenting out calls to cpm_setbrg(), to see if the frequency is bad.
-Scott
^ permalink raw reply
* Re: No output from SCC1 console
From: Scott Wood @ 2008-07-29 19:33 UTC (permalink / raw)
To: Fabien Oriede; +Cc: linuxppc-embedded
In-Reply-To: <828666.17571.qm@web27407.mail.ukl.yahoo.com>
On Tue, Jul 29, 2008 at 08:47:00AM +0000, Fabien Oriede wrote:
> < 6 > cpm_uart : WARNING : no UART devices found on platorm bus! –
> < 6 > cpm_uart : the driver will guess configuration, but this mode is no longer supported. –
Enable CONFIG_PPC_CPM_NEW_BINDING (or better, upgrade to the latest
kernel), and ensure that the device tree node and pin/brg setup is
correct.
Try commenting out calls to set the BRG as a test, to see if it's getting
a bad frequency.
-Scott
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-29 19:26 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200807291645.03382.bzolnier@gmail.com>
On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
> > > On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > Well, all I do is call into Bart's new helpers to scan for or
> > > > unregister
> > > > > devices ...
> > > >
> > > > The switch to these helpers happened _before_ 2.6.26 and it shouldn't
> > > > bring
> > > > such behavior change (ditto for new IDE host addition/removal
> > > > helpers)...
> > > >
> > > > Please try to git-bisect it when you have some time.
> > >
> > > Ok, I will. I worked fine when I last tried your patches. I'll see if I
> > > can track it down too. Been a bit too busy lately as you can imagine.
> > >
> > > Do you have something that exercise the same code path you can use ?
> >
> > I'll see if I can reproduce it with IDE warm-plug support later...
>
> OK, I reproduced it here with IDE warm-plug support
> (echo -n "1" > /sys/class/ide_port/ide*/delete_devices)
> for devices driven by ide-cd.
>
> It is also reproducible under qemu so I'm scripting it
> into git-bisect run now...
I WON!!!
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: fix regression caused by ide_device_{get,put}() addition
On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
[...]
> Vector: 300 (Data Access) at [c58b7b80]
> pc: c014f264: elv_may_queue+0x10/0x44
> lr: c0152750: get_request+0x2c/0x2c0
> sp: c58b7c30
> msr: 1032
> dar: c
> dsisr: 40000000
> current = 0xc58aaae0
> pid = 854, comm = media-bay
> enter ? for help
> mon> t
> [c58b7c40] c0152750 get_request+0x2c/0x2c0
> [c58b7c70] c0152a08 get_request_wait+0x24/0xec
> [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
> [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
> [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
> [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
> [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
> [c58b7e50] c022395c ide_cd_release+0x80/0x84
> [c58b7e70] c0163650 kref_put+0x54/0x6c
> [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
> [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
> [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
> [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
> [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
> [c58b7f00] c01e7424 device_del+0x104/0x198
> [c58b7f20] c01e74d0 device_unregister+0x18/0x30
> [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
> [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
> [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
> [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
> [c58b7fd0] c00485c0 kthread+0x48/0x84
> [c58b7ff0] c0011b20 kernel_thread+0x44/0x60
The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3
("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called
before kref_put() in ide_cd_put() so IDE device is already gone by the time
ide_cd_release() is reached.
Fix it by calling ide_device_get() before kref_get() and ide_device_put()
after kref_put() in all affected device drivers.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-cd.c | 10 +++++-----
drivers/ide/ide-disk.c | 9 ++++-----
drivers/ide/ide-floppy.c | 9 ++++-----
drivers/ide/ide-tape.c | 9 ++++-----
drivers/scsi/ide-scsi.c | 9 ++++-----
5 files changed, 21 insertions(+), 25 deletions(-)
Index: b/drivers/ide/ide-cd.c
===================================================================
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -66,11 +66,11 @@ static struct cdrom_info *ide_cd_get(str
mutex_lock(&idecd_ref_mutex);
cd = ide_cd_g(disk);
if (cd) {
- kref_get(&cd->kref);
- if (ide_device_get(cd->drive)) {
- kref_put(&cd->kref, ide_cd_release);
+ if (ide_device_get(cd->drive))
cd = NULL;
- }
+ else
+ kref_get(&cd->kref);
+
}
mutex_unlock(&idecd_ref_mutex);
return cd;
@@ -79,8 +79,8 @@ static struct cdrom_info *ide_cd_get(str
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(&idecd_ref_mutex);
- ide_device_put(cd->drive);
kref_put(&cd->kref, ide_cd_release);
+ ide_device_put(cd->drive);
mutex_unlock(&idecd_ref_mutex);
}
Index: b/drivers/ide/ide-disk.c
===================================================================
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -65,11 +65,10 @@ static struct ide_disk_obj *ide_disk_get
mutex_lock(&idedisk_ref_mutex);
idkp = ide_disk_g(disk);
if (idkp) {
- kref_get(&idkp->kref);
- if (ide_device_get(idkp->drive)) {
- kref_put(&idkp->kref, ide_disk_release);
+ if (ide_device_get(idkp->drive))
idkp = NULL;
- }
+ else
+ kref_get(&idkp->kref);
}
mutex_unlock(&idedisk_ref_mutex);
return idkp;
@@ -78,8 +77,8 @@ static struct ide_disk_obj *ide_disk_get
static void ide_disk_put(struct ide_disk_obj *idkp)
{
mutex_lock(&idedisk_ref_mutex);
- ide_device_put(idkp->drive);
kref_put(&idkp->kref, ide_disk_release);
+ ide_device_put(idkp->drive);
mutex_unlock(&idedisk_ref_mutex);
}
Index: b/drivers/ide/ide-floppy.c
===================================================================
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -167,11 +167,10 @@ static struct ide_floppy_obj *ide_floppy
mutex_lock(&idefloppy_ref_mutex);
floppy = ide_floppy_g(disk);
if (floppy) {
- kref_get(&floppy->kref);
- if (ide_device_get(floppy->drive)) {
- kref_put(&floppy->kref, idefloppy_cleanup_obj);
+ if (ide_device_get(floppy->drive))
floppy = NULL;
- }
+ else
+ kref_get(&floppy->kref);
}
mutex_unlock(&idefloppy_ref_mutex);
return floppy;
@@ -180,8 +179,8 @@ static struct ide_floppy_obj *ide_floppy
static void ide_floppy_put(struct ide_floppy_obj *floppy)
{
mutex_lock(&idefloppy_ref_mutex);
- ide_device_put(floppy->drive);
kref_put(&floppy->kref, idefloppy_cleanup_obj);
+ ide_device_put(floppy->drive);
mutex_unlock(&idefloppy_ref_mutex);
}
Index: b/drivers/ide/ide-tape.c
===================================================================
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -331,11 +331,10 @@ static struct ide_tape_obj *ide_tape_get
mutex_lock(&idetape_ref_mutex);
tape = ide_tape_g(disk);
if (tape) {
- kref_get(&tape->kref);
- if (ide_device_get(tape->drive)) {
- kref_put(&tape->kref, ide_tape_release);
+ if (ide_device_get(tape->drive))
tape = NULL;
- }
+ else
+ kref_get(&tape->kref);
}
mutex_unlock(&idetape_ref_mutex);
return tape;
@@ -344,8 +343,8 @@ static struct ide_tape_obj *ide_tape_get
static void ide_tape_put(struct ide_tape_obj *tape)
{
mutex_lock(&idetape_ref_mutex);
- ide_device_put(tape->drive);
kref_put(&tape->kref, ide_tape_release);
+ ide_device_put(tape->drive);
mutex_unlock(&idetape_ref_mutex);
}
Index: b/drivers/scsi/ide-scsi.c
===================================================================
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -102,11 +102,10 @@ static struct ide_scsi_obj *ide_scsi_get
mutex_lock(&idescsi_ref_mutex);
scsi = ide_scsi_g(disk);
if (scsi) {
- scsi_host_get(scsi->host);
- if (ide_device_get(scsi->drive)) {
- scsi_host_put(scsi->host);
+ if (ide_device_get(scsi->drive))
scsi = NULL;
- }
+ else
+ scsi_host_get(scsi->host);
}
mutex_unlock(&idescsi_ref_mutex);
return scsi;
@@ -115,8 +114,8 @@ static struct ide_scsi_obj *ide_scsi_get
static void ide_scsi_put(struct ide_scsi_obj *scsi)
{
mutex_lock(&idescsi_ref_mutex);
- ide_device_put(scsi->drive);
scsi_host_put(scsi->host);
+ ide_device_put(scsi->drive);
mutex_unlock(&idescsi_ref_mutex);
}
^ permalink raw reply
* mpc8349mITX developement repository
From: Sparks, Sam @ 2008-07-29 19:26 UTC (permalink / raw)
To: linuxppc-dev
Which repository on kernel.org should I use to pick up the
latest-greatest software for the mpc8349mITX?
=20
I've tried linux/kernel/git/vitb/linux-2.6-8xx.git, but the dts doesn't
contain compact flash nodes.
I've tried linux/kernel/git/paulus/powerpc.git, but the kernel hangs
while trying to uncompress.
=20
TIA,
Sam
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Matvejchikov Ilya @ 2008-07-29 18:36 UTC (permalink / raw)
To: Ben Gardiner; +Cc: linuxppc-embedded
In-Reply-To: <488F385B.9030504@nanometrics.ca>
Hello Ben,
Have you tired to run 2.6.25 kernel? With 2.6.25.4 my console works
fine! I suspect there is something like a regression....
Ilya.
^ permalink raw reply
* Re: [bugme-daemon@bugzilla.kernel.org: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card]
From: Dominik Brodowski @ 2008-07-29 18:28 UTC (permalink / raw)
To: linuxppc-dev, paulus, benh
In-Reply-To: <20080717091444.GA22596@isilmar.linta.de>
Ben, Paul,
any ideas?
Best,
Dominik
On Thu, Jul 17, 2008 at 11:14:44AM +0200, Dominik Brodowski wrote:
> Hi,
>
> on an Apple Powerbook G3 (Lombard) with a PPC 740 running at 333 MHz, the
> PCI host bridge is condigured to allow "downstream" devices to use iomem
>
> 0xfd000000 - 0xfdffffff
>
> However, when using it for PCMCIA purposes, there's a machine check. Any
> ideas on why this PCI host bridge is mis-configured, and how to resolve this
> issue (besides adding reserved=0xfd000000,0xffffff as kernel boot option)?
>
> Best,
> Dominik
>
>
> ----- Forwarded message from bugme-daemon@bugzilla.kernel.org -----
>
> Subject: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card
> To: linux-pcmcia@lists.infradead.org
> From: bugme-daemon@bugzilla.kernel.org
> Date: Thu, 17 Jul 2008 01:45:44 -0700 (PDT)
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7306
>
>
>
>
>
> ------- Comment #17 from linux@brodo.de 2008-07-17 01:45 -------
> Now this contains interesting information:
>
> pcmcia: parent PCI bridge Memory window:
>
> means the PCI host bridge is configured to allow "downstream" devices to use
> this memory area. However, when the PCMCIA socket tries to do so, you get the
> machine check. So my question would be to the powerpc folks: why is the PCI
> host bridge configured this way, even if this memory area is not usable?
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
> _______________________________________________
> Linux PCMCIA reimplementation list
> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
>
> ----- End forwarded message -----
^ permalink raw reply
* 2.6.27-rc1 problems
From: Sean MacLennan @ 2008-07-29 18:06 UTC (permalink / raw)
To: linuxppc-dev
I am seeing a lot of problems with 2.6.27-rc1.
Merge conflicts that make no sense.
Files missing (tracehook.h).
Lots of compile errors.
Anybody else seeing problems, or is it just me? I am starting
to wonder if my git repository has gotten corrupted.
Cheers,
Sean
^ permalink raw reply
* Read but not write on a PCI bus!
From: Tachwali @ 2008-07-29 16:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am facing a problem in writing to PMC module on cPCI board through local
PCI bus. The cPCI board is equipped with an mpc7447/7448 powerpc processor
as well as a Marvell system controller (mv64462). The board is working on
Gentoo Linux (kernel version 2.6.9 built using arch/ppc).
I can read registers on a PMC module via local PCI interface, but we can't
write to any registers. I am wondering about the possible causes of such
behaviour. I need to mention that:
1- the same PMC module and driver works Ok on many x86 based systems.
2- The PCI config space seems to be OK since the PMC module can be detected
by scanpci Linux command. The PMC module registers are in Bar0 mem space
(BASE0 0x23ffff88 addr 0x23ffff80 MEM PREFETCHABLE)
3- I checked MV64462 PCI config registers carefully, and the "write protect"
and "access protect" bits in these registers are not set.
4- I have tried another debugging utility which does a basic read/write to
memory and this utility experience the same problem as our driver (it can
only read the address space of the PCI bus but cannot write to it).
I am wondering if "posted writes" option in MV64462 can cause this problem.
Did anybody encounter any problem with this option or have any hints on the
possible causes of blocking writes to the PCI bus?
Thank you in advance for your help!
--
View this message in context: http://www.nabble.com/Read-but-not-write-on-a-PCI-bus%21-tp18716235p18716235.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Ben Gardiner @ 2008-07-29 15:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <8496f91a0807282310r5e70fe01v85b2ff2da7a80416@mail.gmail.com>
In 'Re: No output from SMC1 console with the 2.6.26 kernel (PQ2FADS
based board)' Matvejchikov Ilya wrote:
> No, it's not working for me :(
>
> My pins is configured by u-boot so I disable init_ioports() function
> call. Moreover the udbg0 console forks fine... I have no output at all
> after "udbg_putc = NULL" line in the cpm_uart driver. As I see it the
> cpm_uart driver doesn't run properly after udbg console has turned
> off.....
>
I think I'm having a similar problem with an 8xx based board.
I am calling cpm_reset() and cpm1_set_pin().
<snip nmx_setup.c>
...
static struct cpm_pin nmx_pins[] = {
/* SMC1 */
{CPM_PORTB, 24, CPM_PIN_INPUT}, /* RX */
{CPM_PORTB, 25, CPM_PIN_INPUT | CPM_PIN_SECONDARY}, /* TX */
};
static void __init init_ioports(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(nmx_pins); i++) {
struct cpm_pin *pin = &nmx_pins[i];
cpm1_set_pin(pin->port, pin->pin, pin->flags);
}
cpm1_clk_setup(CPM_CLK_SMC1, CPM_BRG1, CPM_CLK_RTX);
}
static void __init nmx_setup_arch(void)
{
cpm_reset();
init_ioports();
...
<snip>
I have a cpm dts entry copied from the mpc866ads.dts. I've also added
the compatible = "simple-bus".
<snip nmx-taurus.dts>
...
cpm@9c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc866-cpm", "fsl,cpm1", "simple-bus";
ranges;
reg = <0x9c0 0x40>;
brg-frequency = <0>;
interrupts = <0 2>; // cpm error interrupt
interrupt-parent = <&CPM_PIC>;
muram@2000 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2000 0x2000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x1c00>;
};
};
brg@9f0 {
compatible = "fsl,mpc866-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
reg = <0x9f0 0x10>;
clock-frequency = <0>;
};
CPM_PIC: pic@930 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
interrupts = <5 2 0 2>;
interrupt-parent = <&PIC>;
reg = <0x930 0x20>;
compatible = "fsl,mpc866-cpm-pic",
"fsl,cpm1-pic";
};
serial@a80 {
device_type = "serial";
compatible = "fsl,mpc866-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa80 0x10 0x3e80 0x40>;
interrupts = <4>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x90>;
};
serial@a90 {
device_type = "serial";
compatible = "fsl,mpc866-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa90 0x10 0x3f80 0x40>;
interrupts = <3>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <0xd0>;
};
};
};
...
<snip>
I have CPM console SMC1 enabled
<snip .config>
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SMC1=y
<snip>
And my serial console output is stopping around the same point as
Matvejchikov. I have baud 9600, so I'm guessing that it's cutoff because
of this (please excuse me if this is wrong). NB: the console=ttyS0
bootarg is there to get a working console when I boot back to 2.4.
<snip console>
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:11:40:02:00:18
CPU clock-frequency <- 0x3f940aa (67MHz)
CPU timebase-frequency <- 0x1fce17 (2MHz)
CPU bus-frequency <- 0x1fce170 (33MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07f77908)
Allocating 0x127c50 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00538390)...done 0x11a680 bytes
Linux/PowerPC load: root=/dev/mtdblock2 rw panic=10 console=ttyCPM0
console=ttyS0
Finalizing device tree... flat tree at 0x545300
Xid mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using NMX Taurus machine description
Linux version 2.6.26-dirty (BenGardiner@penguin.nanometrics.ca) (gcc
version 4.0.1) #1 Tue Jul 2
9 10:43:11 EDT 2008
console [udbg0] enabled
Entering add_active_range(0, 0, 32768) 0 entries of 256 used
setup_arch: bootmem
arch: exit
Top of RAM: 0x8000000, Total RAM: 0x8000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
On node 0 totalpages: 32768
DMA zone: 256 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 32512 pages, LIFO batch:7
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: root=/dev/mtdblock2 rw panic=10 console=ttyCPM0
console=ttyS0
PID hash table entries: 512 (order: 9, 2048 bytes)
Decrementer Frequency = 0x3f940a
time_init: decrementer frequency = 4.166666 MHz
time_init: processor frequency = 66.666666 MHz
clocksource: timebase mult[3c0000a1] shift[22] registered
clockevent: decremente
<snip>
I've had the same behaviour with gcc 4.0.1 and gcc 4.3.0. Also with
CONFIG_SERIAL_CPM_SCC1=y defined and not. Also with the smc2 dts entry
removed and not. Also with ',9600' on the console=CPM0 bootarg and not.
Please excuse me for jumping in late. I hope this can help track down
the problem.
,Ben
^ permalink raw reply
* ML507 EDK 10.1 SP2
From: somshekar c kadam @ 2008-07-30 2:26 UTC (permalink / raw)
To: John Linn; +Cc: skaushik, nbhat, pnarasim, linuxppc-embedded
In-Reply-To: <20080602143551.54964C80052@mail135-wa4.bigfish.com>
Hi John Linn,
We are using ML507 EDK 10.1 with latest SP2.
We have took your help in getting up the Xilinx git kernel up on ML507
using bsb image donwload.bit from xilinx website and dts file part of
the kernel. The kernel boots successfully. thanks for all your support.
Well we now want to modify bsb image by creating new download.bit using
EDK 10.1 SP2 and generate dts file for it.
Problem now we are facing is we follow the steps mentioned XIlinx ML507
pdf to create donwload.bit and generate dts file for it. using the same
xilinx kernel but the board doesn't boot.
Can you throw some light on any specific steps we are missing apart from
the pdf mentioned to create bsb image download.bit and corresponding dts
file.
Just we need to use uartlite instead of 16650 uart.
Also we are trying on ML403 we are not able to create a sample
donwload.bit which boots.
Please mention any steps we are missing or any pointers will help as we
are stuck in this problem from long.
For ml403 we even tried older edk 9.1 sp2 , 8.1 sp2 and 7.1 sp2 neither
works .
Waiting for your inputs
Thanks In advance
Regards
Neelu
On Mon, 2008-06-02 at 08:35 -0600, John Linn wrote:
> Hi Neelu,
>
> The easiest way to get a good baseline with the board and the kernel is
> to use the bitstream for the board that we provide in the file,
> linux_support.tar.gz, on http://git.xilinx.com.
>
> In the PPC440 directory of the support file, there's a bit stream for
> the board. If you don't use a Xilinx probe to download to the board, you
> will need to create an ACE file from that bit stream, but it sounds like
> you know how to do that.
>
> I know the state of the Xilinx Git tree, but I don't know the state of
> Grant's for sure. We have baselined our Git tree such that you should be
> able to make it work quick and easy (that's our goal).
>
> To build arch/powerpc, the following commands should create zImage in
> the arch/powerpc/boot directory that can be used with the bitstream from
> the linux_support.tar.gz file. I am currently using the ELDK 4.1 tools
> to build the kernel.
>
> > make ARCH=powerpc ml507_defconfig
> > make ARCH=powerpc zImage
>
> We also provide a ramdisk image in the support file, you can build it
> also after copying the ramdisk images into the arch/powerpc/boot
> directory. The default command line of the kernel, in the ml507.dts
> file in the arch/powerpc/boot/dts directory, is setup to use the
> ramdisk.
>
> > make ARCH=powerpc zImage.initrd
>
> Hope that helps,
> John Linn
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
> Behalf Of somshekar c kadam
> Sent: Monday, June 02, 2008 4:19 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: ML507 EDK 10.1
>
> Hi All,
>
> Currently I am working with ML507 Base Reference design. I have
> installed Eval 10.1 edk I am bale to create ace file using xmd with base
> download.bit. and able to boot the board. Now I want to boot the board
> with Xilinx Linux kernel from Xilinx git tree. I am facing compilation
> problem with zImage.dts for ml507_defconfig.
>
>
>
>
> now I need to create ace file for Linux for ML507.
> I tried creating zImage.dts its failing. Kernel error see below
>
> Please help or give some pointers wherein I can compile zImge.dts. this
> is from latest git tree. Seems for me arch/powerpc wrapper code is
> broken. Please suggest.
> currently I have no bdi I need to stick to Ace compact Flash booting.
> Also bit confused where we have two git tree one is Xilinx git tree one
> more from Grant Likely which should I use ?
>
> Thanks In Advance
>
> Neelu
>
> ---------------------------------------------------
> WRAP arch/powerpc/boot/zImage.dts
> DTC: dts->dtb on file
> "/home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/bo
> ot/dts/ml507.dts"
> objcopy: Unable to recognise the format of the input file `vmlinux'
> make[1]: *** [arch/powerpc/boot/zImage.dts] Error 1
> make: *** [zImage.dts] Error 2
>
>
>
>
> WIth Verbose =1
>
>
> /bin/sh
> /home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/boo
> t/wrapper -c -o arch/powerpc/boot/zImage.dts -p dts -s
> /home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/boo
> t/dts/ml507.dts vmlinux
> + kernel=
> + ofile=zImage
> + platform=of
> + initrd=
> + dtb=
> + dts=
> + cacheit=
> + binary=
> + gzip=.gz
> + CROSS=
> + object=arch/powerpc/boot
> + objbin=arch/powerpc/boot
> + tmpdir=.
> + '[' 8 -gt 0 ']'
> + case "$1" in
> + cacheit=y
> + shift
> + '[' 7 -gt 0 ']'
> + case "$1" in
> + shift
> + '[' 6 -gt 0 ']'
> + ofile=arch/powerpc/boot/zImage.dts
> + shift
> + '[' 5 -gt 0 ']'
> + case "$1" in
> + shift
> + '[' 4 -gt 0 ']'
> + platform=dts
> + shift
> + '[' 3 -gt 0 ']'
> + case "$1" in
> + shift
> + '[' 2 -gt 0 ']'
> +
> dts=/home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc
> /boot/dts/ml507.dts
> + shift
> + '[' 1 -gt 0 ']'
> + case "$1" in
> + '[' -z '' ']'
> + kernel=vmlinux
> + shift
> + '[' 0 -gt 0 ']'
> + '['
> -n
> /home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/boo
> t/dts/ml507.dts ']'
> + '[' '!'
> -r
> /home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/boo
> t/dts/ml507.dts -a -r
> arch/powerpc/boot/dts//home/neelu/xilinx/xilinx_gittree/test44/linux-2.6
> -xlnx/arch/powerpc/boot/dts/ml507.dts ']'
> + '[' -z '' ']'
> + dtb=dts.dtb
> + arch/powerpc/boot/dtc -O dtb -o dts.dtb -b
> 0
> /home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/boo
> t/dts/ml507.dts
> DTC: dts->dtb on file
> "/home/neelu/xilinx/xilinx_gittree/test44/linux-2.6-xlnx/arch/powerpc/bo
> ot/dts/ml507.dts"
> + '[' -z vmlinux ']'
> + platformo=arch/powerpc/boot/dts.o
> + lds=arch/powerpc/boot/zImage.lds
> + ext=strip
> + objflags=-S
> + tmp=./zImage.24209.o
> + ksection=.kernel:vmlinux.strip
> + isection=.kernel:initrd
> + case "$platform" in
> ++ basename vmlinux
> + vmz=./vmlinux.strip
> + '[' -z y -o '!' -f ./vmlinux.strip.gz -o ./vmlinux.strip.gz -ot
> vmlinux ']'
> + objcopy -S vmlinux ./vmlinux.strip.24209
> objcopy: Unable to recognise the format of the input file `vmlinux'
> make[1]: *** [arch/powerpc/boot/zImage.dts] Error 1
> make: *** [zImage.dts] Error 2
>
>
>
>
>
> ------------------------------------------------------------------------
> ------------------
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-29 14:45 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200807291404.46906.bzolnier@gmail.com>
On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > Well, all I do is call into Bart's new helpers to scan for or
> > > unregister
> > > > devices ...
> > >
> > > The switch to these helpers happened _before_ 2.6.26 and it shouldn't
> > > bring
> > > such behavior change (ditto for new IDE host addition/removal
> > > helpers)...
> > >
> > > Please try to git-bisect it when you have some time.
> >
> > Ok, I will. I worked fine when I last tried your patches. I'll see if I
> > can track it down too. Been a bit too busy lately as you can imagine.
> >
> > Do you have something that exercise the same code path you can use ?
>
> I'll see if I can reproduce it with IDE warm-plug support later...
OK, I reproduced it here with IDE warm-plug support
(echo -n "1" > /sys/class/ide_port/ide*/delete_devices)
for devices driven by ide-cd.
It is also reproducible under qemu so I'm scripting it
into git-bisect run now...
Thanks,
Bart
^ permalink raw reply
* [PATCH] kdump: Make elfcorehdr_addr independent of CONFIG_PROC_VMCORE
From: Vivek Goyal @ 2008-07-29 14:41 UTC (permalink / raw)
To: linux kernel mailing list, Kexec Mailing List
Cc: Tony Luck, linux-ia64, Paul Mundt, linuxppc-dev, Terry Loftin,
Horms, Eric W. Biederman, Ingo Molnar, Linus Torvalds,
Morton Andrew Morton
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
o I don't see sh setup code parsing the command line for elfcorehdr_addr. I
am wondering how does vmcore interface work on sh. Anyway, I am atleast
defining elfcoredhr_addr so that compilation is not broken on sh.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Paul Mundt <lethal@linux-sh.org>
---
arch/ia64/kernel/crash_dump.c | 4 ++++
arch/ia64/kernel/setup.c | 9 ++++++++-
arch/powerpc/kernel/crash_dump.c | 10 ++++++++--
arch/sh/kernel/crash_dump.c | 3 +++
arch/x86/kernel/crash_dump_32.c | 3 +++
arch/x86/kernel/crash_dump_64.c | 3 +++
arch/x86/kernel/setup.c | 8 +++++++-
fs/proc/vmcore.c | 3 ---
include/linux/crash_dump.h | 14 ++++++++++----
9 files changed, 46 insertions(+), 11 deletions(-)
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore include/linux/crash_dump.h
--- linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 12:00:44.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h 2008-07-28 12:00:56.000000000 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore fs/proc/vmcore.c
--- linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 09:19:50.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.000000000 -0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore arch/x86/kernel/crash_dump_32.c
--- linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:28:26.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_32.c 2008-07-29 05:28:26.000000000 -0400
@@ -13,6 +13,9 @@
static void *kdump_buf_page;
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
diff -puN arch/x86/kernel/crash_dump_64.c~remove-elfcore-hdr-addr-definition-vmcore arch/x86/kernel/crash_dump_64.c
--- linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_64.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:28:26.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_64.c 2008-07-29 05:28:26.000000000 -0400
@@ -11,6 +11,9 @@
#include <asm/uaccess.h>
#include <asm/io.h>
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
diff -puN arch/x86/kernel/setup.c~remove-elfcore-hdr-addr-definition-vmcore arch/x86/kernel/setup.c
--- linux-2.6.27-pre-rc1/arch/x86/kernel/setup.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:28:26.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/setup.c 2008-07-29 05:28:26.000000000 -0400
@@ -558,7 +558,13 @@ static void __init reserve_standard_io_r
}
-#ifdef CONFIG_PROC_VMCORE
+/*
+ * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
+ * is_kdump_kernel() to determine if we are booting after a panic. Hence
+ * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
+ */
+
+#ifdef CONFIG_CRASH_DUMP
/* elfcorehdr= specifies the location of elf core header
* stored by the crashed kernel. This option will be passed
* by kexec loader to the capture kernel.
diff -puN arch/powerpc/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore arch/powerpc/kernel/crash_dump.c
--- linux-2.6.27-pre-rc1/arch/powerpc/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:30:33.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/powerpc/kernel/crash_dump.c 2008-07-29 05:30:33.000000000 -0400
@@ -27,6 +27,9 @@
#define DBG(fmt...)
#endif
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
void __init reserve_kdump_trampoline(void)
{
lmb_reserve(0, KDUMP_RESERVE_LIMIT);
@@ -66,7 +69,11 @@ void __init setup_kdump_trampoline(void)
DBG(" <- setup_kdump_trampoline()\n");
}
-#ifdef CONFIG_PROC_VMCORE
+/*
+ * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
+ * is_kdump_kernel() to determine if we are booting after a panic. Hence
+ * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
+ */
static int __init parse_elfcorehdr(char *p)
{
if (p)
@@ -75,7 +82,6 @@ static int __init parse_elfcorehdr(char
return 1;
}
__setup("elfcorehdr=", parse_elfcorehdr);
-#endif
static int __init parse_savemaxmem(char *p)
{
diff -puN arch/ia64/kernel/setup.c~remove-elfcore-hdr-addr-definition-vmcore arch/ia64/kernel/setup.c
--- linux-2.6.27-pre-rc1/arch/ia64/kernel/setup.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:30:54.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/ia64/kernel/setup.c 2008-07-29 05:30:54.000000000 -0400
@@ -478,7 +478,12 @@ static __init int setup_nomca(char *s)
}
early_param("nomca", setup_nomca);
-#ifdef CONFIG_PROC_VMCORE
+/*
+ * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
+ * is_kdump_kernel() to determine if we are booting after a panic. Hence
+ * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
+ */
+#ifdef CONFIG_CRASH_DUMP
/* elfcorehdr= specifies the location of elf core header
* stored by the crashed kernel.
*/
@@ -491,7 +496,9 @@ static int __init parse_elfcorehdr(char
return 0;
}
early_param("elfcorehdr", parse_elfcorehdr);
+#endif
+#ifdef CONFIG_PROC_VMCORE
int __init reserve_elfcorehdr(unsigned long *start, unsigned long *end)
{
unsigned long length;
diff -puN arch/ia64/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore arch/ia64/kernel/crash_dump.c
--- linux-2.6.27-pre-rc1/arch/ia64/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:37:10.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/ia64/kernel/crash_dump.c 2008-07-29 05:37:58.000000000 -0400
@@ -8,10 +8,14 @@
#include <linux/errno.h>
#include <linux/types.h>
+#include <linux/crash_dump.h>
#include <asm/page.h>
#include <asm/uaccess.h>
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
diff -puN arch/sh/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore arch/sh/kernel/crash_dump.c
--- linux-2.6.27-pre-rc1/arch/sh/kernel/crash_dump.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-29 05:31:04.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/arch/sh/kernel/crash_dump.c 2008-07-29 05:31:04.000000000 -0400
@@ -10,6 +10,9 @@
#include <linux/io.h>
#include <asm/uaccess.h>
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
_
^ permalink raw reply
* Re: [PATCH 5/5] sh: Define elfcorehdr_addr in arch dependent section
From: Paul Mundt @ 2008-07-29 14:18 UTC (permalink / raw)
To: Vivek Goyal
Cc: Tony Luck, linux-ia64, kexec, linux-kernel, linuxppc-dev,
Terry Loftin, Simon Horman, Paul Mackerras, Eric W. Biederman,
Andrew Morton, Linus Torvalds, Ingo Molnar
In-Reply-To: <20080728211514.GE9985@redhat.com>
On Mon, Jul 28, 2008 at 05:15:14PM -0400, Vivek Goyal wrote:
> o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
> equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
> CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
> used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
> not.
>
> o I don't see sh setup code parsing the command line for elfcorehdr_addr. I
> am wondering how does vmcore interface work on sh. Anyway, I am atleast
> defining elfcoredhr_addr so that compilation is not broken on sh.
>
Hmm, you are correct, it seems like it was either lost in a merge
somewhere or I simply neglected to check it in it when I was testing this
stuff initially. Thanks for noticing!
> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: Level IRQ handling on Xilinx INTC with ARCH=powerpc
From: David Howells @ 2008-07-29 14:14 UTC (permalink / raw)
To: Sergey Temerkhanov; +Cc: linuxppc-dev
In-Reply-To: <360961217332693@webmail22.yandex.ru>
Sergey Temerkhanov <temerkhanov@yandex.ru> wrote:
> And handle_level_irq() which is currently used as high-level IRQ handler for
> Xilinx INTC only tries to acknowledge IRQ before ISR call. So that the IRQ
> remains asserted in INTC and after the call to desc->chip->unmask() causes
> spurious attempt to process the same IRQ again. However, call to
> desc->chip->ack() this time finishes the required procedure of IRQ
> acknowledge.
I think I'm seeing the same on the MN10300 arch with its builtin PIC. My
soultion was to make unmask() also clear the IRQ latch in the PIC for that
channel. We perhaps want an unmask_ack() op.
David
^ permalink raw reply
* Re: [PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent section
From: Vivek Goyal @ 2008-07-29 13:53 UTC (permalink / raw)
To: Simon Horman
Cc: Tony Luck, linux-ia64, kexec, linux-kernel, linuxppc-dev,
Terry Loftin, Paul Mundt, Paul Mackerras, Eric W. Biederman,
Andrew Morton, Linus Torvalds, Ingo Molnar
In-Reply-To: <20080729044241.GA23514@verge.net.au>
On Tue, Jul 29, 2008 at 02:42:43PM +1000, Simon Horman wrote:
> On Mon, Jul 28, 2008 at 05:13:14PM -0400, Vivek Goyal wrote:
> >
> > o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
> > equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
> > CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
> > used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
> > not.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> >
> > arch/ia64/kernel/setup.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff -puN arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64 arch/ia64/kernel/setup.c
> > --- linux-2.6.27-pre-rc1/arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64 2008-07-28 12:16:40.000000000 -0400
> > +++ linux-2.6.27-pre-rc1-root/arch/ia64/kernel/setup.c 2008-07-28 12:16:40.000000000 -0400
> > @@ -478,7 +478,12 @@ static __init int setup_nomca(char *s)
> > }
> > early_param("nomca", setup_nomca);
> >
> > -#ifdef CONFIG_PROC_VMCORE
> > +/*
> > + * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
> > + * is_kdump_kernel() to determine if we are booting after a panic. Hence
> > + * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
> > + */
> > +#ifdef CONFIG_CRASH_DUMP
> > /* elfcorehdr= specifies the location of elf core header
> > * stored by the crashed kernel.
> > */
> > @@ -491,7 +496,9 @@ static int __init parse_elfcorehdr(char
> > return 0;
> > }
> > early_param("elfcorehdr", parse_elfcorehdr);
> > +#endif
> >
> > +#ifdef CONFIG_PROC_VMCORE
> > int __init reserve_elfcorehdr(unsigned long *start, unsigned long *end)
> > {
> > unsigned long length;
> > _
>
> Hi Vivek,
>
> I think that you also need the following in arch/ia64/kernel/crash_dump.c.
> With this change your code compiles on ia64.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
>
Thanks Simon. I had done these changes locally but somehow forgot to
include the changes in patches.
I will include these changes in my next posting of consolidated single
patch.
Thanks
Vivek
^ permalink raw reply
* Re: linux kernel for ppc as elf relocatable
From: Kumar Gala @ 2008-07-29 13:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, mihaela elena grigore
In-Reply-To: <20080729101735.BAF07248B9@gemini.denx.de>
On Jul 29, 2008, at 5:17 AM, Wolfgang Denk wrote:
> In message <488E1134.6010109@criticalsoftware.com> you wrote:
>> Can somebody help me with a few indications regarding how to obtain a
>> relocatable vmlinux when compiling the linux kernel for ppc32 ?
>
> Why exactly would you want to do that?
Any for what specific ppc32 sub-arch do you want to do this for?
- k
^ permalink raw reply
* Level IRQ handling on Xilinx INTC with ARCH=powerpc
From: Sergey Temerkhanov @ 2008-07-29 11:58 UTC (permalink / raw)
To: linuxppc-dev
Hi, all!
I'm currently in process of development of Xilinx I2C IP core driver and I've run into the problem: the ISR for level-based IRQ is called twice.
It looks like level IRQ handling on Xilinx INTC with ARCH=powerpc is currently broken as Xilinx INTC requires IRQ acknowledge with IRQ signal deasserted (i.e. after ISR call). ISR is supposed to acknowledge level IRQ in the core which asserted it thus deasserting appropriate IRQ signal.
And handle_level_irq() which is currently used as high-level IRQ handler for Xilinx INTC only tries to acknowledge IRQ before ISR call. So that the IRQ remains asserted in INTC and after the call to desc->chip->unmask() causes spurious attempt to process the same IRQ again. However, call to desc->chip->ack() this time finishes the required procedure of IRQ acknowledge.
I see a few ways to resolve this:
1. Change high-level handler to __do_IRQ() (as for ARCH=ppc) with proper methods modification (which is deprecated).
2. Change handle_level_irq() so that it calls desc->chip->ack() or desc->chip->end() (and set chip->end to point to xilinx_intc_ack() for Xilinx INTC) before desc->chip->unmask() (may potentially cause breakage for other arches. But I've tried it and it works).
3. Acknowledge IRQ at INTC in ISR (quick'n'dirty hack).
Regards, Sergey Temerkhanov
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-29 12:04 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <1217332971.11188.249.camel@pasglop>
On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > Well, all I do is call into Bart's new helpers to scan for or
> > unregister
> > > devices ...
> >
> > The switch to these helpers happened _before_ 2.6.26 and it shouldn't
> > bring
> > such behavior change (ditto for new IDE host addition/removal
> > helpers)...
> >
> > Please try to git-bisect it when you have some time.
>
> Ok, I will. I worked fine when I last tried your patches. I'll see if I
> can track it down too. Been a bit too busy lately as you can imagine.
>
> Do you have something that exercise the same code path you can use ?
I'll see if I can reproduce it with IDE warm-plug support later...
Thanks,
Bart
^ permalink raw reply
* Re: ide pmac breakage
From: Benjamin Herrenschmidt @ 2008-07-29 12:02 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200807291341.14724.bzolnier@gmail.com>
On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Well, all I do is call into Bart's new helpers to scan for or
> unregister
> > devices ...
>
> The switch to these helpers happened _before_ 2.6.26 and it shouldn't
> bring
> such behavior change (ditto for new IDE host addition/removal
> helpers)...
>
> Please try to git-bisect it when you have some time.
Ok, I will. I worked fine when I last tried your patches. I'll see if I
can track it down too. Been a bit too busy lately as you can imagine.
Do you have something that exercise the same code path you can use ?
Ben.
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-29 11:41 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <1217308857.11188.237.camel@pasglop>
On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote:
> > If q->elevator is NULL, the media-bay code might mess up the ref
> > counting of the request queue...
>
> Well, all I do is call into Bart's new helpers to scan for or unregister
> devices ...
The switch to these helpers happened _before_ 2.6.26 and it shouldn't bring
such behavior change (ditto for new IDE host addition/removal helpers)...
Please try to git-bisect it when you have some time.
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH] Fix powerpc64 build if CONFIG_EPOLL=n
From: Jimi Xenidis @ 2008-07-29 10:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev list
In-Reply-To: <20080728002336.4a7883f1.sfr@canb.auug.org.au>
On Jul 27, 2008, at 10:23 AM, Stephen Rothwell wrote:
> Hi Jimi,
>
> On Sun, 27 Jul 2008 08:48:09 -0400 Jimi Xenidis
> <jimix@watson.ibm.com> wrote:
>>
>> Declate compat_sys_epoll_pwait as a conditional syscall like the rest
>> of the epoll interfaces.
>> We could have put an #ifdef around the entry in include/asm-powerpc/
>> systbl.h, but IMHO this is ultimately correct patch.
>
> Already in Linus' tree - commit
> 5f17156fc55abac476d180e480bedb0f07f01b14
> "Fix build on COMPAT platforms when CONFIG_EPOLL is disabled"
Wow, missed by less than a week.
Thanks for the pointer.
-JX
>
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: linux kernel for ppc as elf relocatable
From: Wolfgang Denk @ 2008-07-29 10:17 UTC (permalink / raw)
To: mihaela elena grigore; +Cc: linuxppc-dev
In-Reply-To: <488E1134.6010109@criticalsoftware.com>
In message <488E1134.6010109@criticalsoftware.com> you wrote:
> Can somebody help me with a few indications regarding how to obtain a
> relocatable vmlinux when compiling the linux kernel for ppc32 ?
Why exactly would you want to do that?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Success in marriage is not so much finding the right person as it is
being the right person.
^ permalink raw reply
* Re : No output from SCC1 console
From: Fabien Oriede @ 2008-07-29 9:48 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
Hi Jochen,
Thanks for your answer, now I have all messages of my "log_buf" on my terminal.
I will now go to put a filesystem on my board.
Fabien.
----- Message d'origine ----
De : Jochen Friedrich <jochen@scram.de>
À : Fabien Oriede <fabien.oriede@yahoo.fr>
Cc : linuxppc-embedded@ozlabs.org
Envoyé le : Mardi, 29 Juillet 2008, 11h19mn 19s
Objet : Re: No output from SCC1 console
Hi Fabien,
> In my
> U-Boot's environnement variables, I have "bootargs=console=ttyS0,38400".
Make this console=ttyCPM0,38400
> < 6 > ttyCPM0 at MMIO 0xffe00a00 (irq = 46) is a CPM UART –
Thanks,
Jochen
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ 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