* Re: Soft Reset for PPC44x Virtex 5 hangs saying Restarting System
From: srikanth krishnakar @ 2009-07-13 15:39 UTC (permalink / raw)
To: Grant Likely; +Cc: Linuxppc-dev
In-Reply-To: <fa686aa40907130802h3a6875f7gf21d41974974a7e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4358 bytes --]
On Mon, Jul 13, 2009 at 8:32 PM, Grant Likely <grant.likely@secretlab.ca>wrote:
> On Mon, Jul 13, 2009 at 1:16 AM, srikanth
> krishnakar<skrishnakar@gmail.com> wrote:
> > Hi all,
> >
> > Kernel : Linux-2.6.29
> > Arch: Powerpc (ppc44x)
> > Target: Xilinx ML507 Virtex5
> >
> > I have an issue in "Reset System" of Xilinx ML507 target board. I am
> using
> > Compact Flash to boot the target ( using system ACE file to boot the
> > target), during the process reset or reboot command on the target, I am
> not
> > able to reboot the target completely, here is the snapshot:
>
> Where is your boot code located? In BRAM? or SDRAM?
It is located in BRAM.
> If it is in
> RAM, then it is likely that your boot code gets overwritten when the
> Linux kernel boots and so soft resetting the processor will result in
> a hung system (because it doesn't have any boot code to run).
>
> >
> -----------------------------------------------------------------------------------------------------
> >
> > The target again doesn't provide me the boot options as obtained when
> done
> > hard reset :
>
> What boot options are you referring to?
Boot options: console=ttyS0,9600 ip=bootp root=/dev/nfs rw
> SystemACE boot configuration?
Yes. I have created SystemACE file using XMD to boot the target, I place
system.ace file in compact flash with rootfs NFS,
I see current ppc4xx_reset_system has been set to : DBCR_RST_SYSTEM so that
is system reset but leaves the FPGA still programmed, I tried writing
DBCR_RST_CORE to DBCR0 that leads to segmentation fault as ;
void ppc4xx_reset_system(char *cmd)
{
mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_RST_SYSTEM); << Tried
using DBCR0_RST_CORE
while (1)
; /* Just in case the reset doesn't work */
}
--------------------------------------------------------------
root@xilinx-ml507:~# reboot
INIT: Sending processes the TERM signal
INIT: Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid
105)
.
Stopping Vixie-cron.
Stopping network benchmark server: netserverstopped /usr/sbin/netserver (pid
10)
.
Stopping syslogd/klogd: stopped syslogd (pid 1060)
stopped klogd (pid 1062)
done
NOT deconfiguring network interfaces: / is an NFS mount
Sending all processes the TERM signal...
Sending all processes the KILL signal...
hwclock: can't open '/dev/misc/rtc': No such file or directory
Unmounting remote filesystems...
Deactivating swap...
/etc/rc6.d/S40umountfs: line 9: swapoff: not found
Unmounting local filesystems...
umount2: Device or resource busy
umount: none busy - remounted read-only
Rebooting... Restarting system.
Oops: Exception in kernel mode, sig: 11 [#1]
PREEMPT LTT NESTING LEVEL : 0
Xilinx Virtex440
Modules linked in: nls_iso8859_1 ipv6
NIP: fffffffc LR: c000d14c CTR: c0018b64
REGS: cf373d50 TRAP: 0700 Not tainted (2.6.29.6)
MSR: 00000000 <> CR: 22444428 XER: 20000001
TASK = cf9acbf0[1101] 'reboot' THREAD: cf372000
GPR00: 50000000 cf373e00 cf9acbf0 00000000 000018ef ffffffff c026493c
00004000
GPR08: c04a5c8c c04a0000 00003fff 000018ef 22444422 1001a5a0 00008000
ffffffff
GPR16: 00000000 00000000 10000000 00000004 00000001 00000000 00000000
00000001
GPR24: 01230000 00000001 00000000 00000000 00000000 01234567 28121969
00000000
NIP [fffffffc] 0xfffffffc
LR [c000d14c] machine_restart+0x34/0x48
Call Trace:
[cf373e00] [c000d130] machine_restart+0x18/0x48 (unreliable)
[cf373e10] [c0046530] kernel_restart+0x34/0x5c
[cf373e20] [c0046684] sys_reboot+0x124/0x1a4
[cf373f40] [c000e164] ret_from_syscall+0x0/0x3c
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 51d087d0d6d3d0e5 ]---
Segmentation fault
----------------------------------------------------------------------------------
How can I reboot the system, while resetting the FPGA core completely ?
> The current system ace driver doesn't have any support for either
> setting the boot options or using the systemace to reboot the system
> by reconfiguring the FPGA. It shouldn't be hard to do, it just hasn't
> been written.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
Thanks for you patience !
-Srikanth
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 5791 bytes --]
^ permalink raw reply
* [PATCH 2/2] powerpc/qe: Implement set_sync() callback for QE GPIOs
From: Anton Vorontsov @ 2009-07-13 15:19 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090713151911.GA28114@oksana.dev.rtsoft.ru>
This is needed to set GPIO's values synchronously.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/include/asm/gpio.h | 11 +++++++++++
arch/powerpc/sysdev/qe_lib/gpio.c | 27 +++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/gpio.h b/arch/powerpc/include/asm/gpio.h
index ea04632..899f365 100644
--- a/arch/powerpc/include/asm/gpio.h
+++ b/arch/powerpc/include/asm/gpio.h
@@ -33,6 +33,17 @@ static inline void gpio_set_value(unsigned int gpio, int value)
__gpio_set_value(gpio, value);
}
+static inline int gpio_can_set_values_sync(unsigned num, unsigned *gpios)
+{
+ return __gpio_can_set_values_sync(num, gpios);
+}
+
+static inline void gpio_set_values_sync(unsigned num, unsigned *gpios,
+ int *values)
+{
+ __gpio_set_values_sync(num, gpios, values);
+}
+
static inline int gpio_cansleep(unsigned int gpio)
{
return __gpio_cansleep(gpio);
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c b/arch/powerpc/sysdev/qe_lib/gpio.c
index 3485288..6cfe784 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -84,6 +84,32 @@ static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
spin_unlock_irqrestore(&qe_gc->lock, flags);
}
+static void qe_gpio_set_sync(struct gpio_chip *gc, unsigned int num,
+ unsigned int *gpios, int *vals)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+ int i;
+
+ spin_lock_irqsave(&qe_gc->lock, flags);
+
+ for (i = 0; i < num; i++) {
+ unsigned int gpio = gpios[i] - gc->base;
+ u32 pin_mask = 1 << (QE_PIO_PINS - 1 - gpio);
+
+ if (vals[i])
+ qe_gc->cpdata |= pin_mask;
+ else
+ qe_gc->cpdata &= ~pin_mask;
+ }
+
+ out_be32(®s->cpdata, qe_gc->cpdata);
+
+ spin_unlock_irqrestore(&qe_gc->lock, flags);
+}
+
static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
@@ -328,6 +354,7 @@ static int __init qe_add_gpiochips(void)
gc->direction_output = qe_gpio_dir_out;
gc->get = qe_gpio_get;
gc->set = qe_gpio_set;
+ gc->set_sync = qe_gpio_set_sync;
ret = of_mm_gpiochip_add(np, mm_gc);
if (ret)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] gpiolib: Implement gpio_set_values_sync()
From: Anton Vorontsov @ 2009-07-13 15:19 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090713151911.GA28114@oksana.dev.rtsoft.ru>
Sometimes it's necessary to set GPIO values synchronously, e.g.
when CPU's GPIOs go to a FPGA and the FPGA has no latch-enable line,
so intermediate values on GPIO lines may trigger unnecessary actions
by the FPGA.
Another usage is chip-select muxes, e.g. using X GPIOs as address lines
to mux 2^X chip-selects, and setting some amount of GPIOs at once may
be a huge win.
Note that it's not always possible to set up GPIOs synchronously, so
gpio_can_set_values_sync() call is implemented. Currently it checks
for two things:
1. Whether gpio_chip has .set_sync() callback;
2. Whether all passed GPIOs belong to one particular gpio_chip.
Someday we may want to implement chip-specific .can_set_sync() check,
but currently this isn't needed.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/gpio/gpiolib.c | 57 ++++++++++++++++++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 8 ++++++
include/linux/gpio.h | 14 ++++++++++
3 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 51a8d41..cf714ad 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1067,6 +1067,53 @@ void __gpio_set_value(unsigned gpio, int value)
EXPORT_SYMBOL_GPL(__gpio_set_value);
/**
+ * __gpio_can_set_values_sync() - check if gpios can be set synchronously
+ * @num: amount of gpios
+ * @gpios: gpios in question
+ * Context: any
+ *
+ * This is used directly or indirectly to implement gpio_can_set_values_sync().
+ * It returns nonzero if an array of gpios can be set simultaneously.
+ */
+int __gpio_can_set_values_sync(unsigned num, unsigned *gpios)
+{
+ struct gpio_chip *chip;
+ unsigned i;
+
+ chip = gpio_to_chip(gpios[0]);
+ if (!chip->set_sync)
+ return 0;
+
+ for (i = 1; i < num; i++) {
+ if (chip != gpio_to_chip(gpios[i]))
+ return 0;
+ }
+
+ return 1;
+}
+EXPORT_SYMBOL_GPL(__gpio_can_set_values_sync);
+
+/**
+ * __gpio_set_values_sync() - assign gpios' values synchronously
+ * @num: amount of gpios
+ * @gpios: gpios whose value will be assigned
+ * @values: value to assign
+ * Context: any
+ *
+ * This is used directly or indirectly to implement gpio_set_values_sync().
+ * It invokes the associated gpio_chip.set_sync() method.
+ */
+void __gpio_set_values_sync(unsigned num, unsigned *gpios, int *values)
+{
+ struct gpio_chip *chip;
+
+ chip = gpio_to_chip(gpios[0]);
+ WARN_ON(extra_checks && chip->can_sleep);
+ chip->set_sync(chip, num, gpios, values);
+}
+EXPORT_SYMBOL_GPL(__gpio_set_values_sync);
+
+/**
* __gpio_cansleep() - report whether gpio value access will sleep
* @gpio: gpio in question
* Context: any
@@ -1129,6 +1176,16 @@ void gpio_set_value_cansleep(unsigned gpio, int value)
}
EXPORT_SYMBOL_GPL(gpio_set_value_cansleep);
+void gpio_set_values_sync_cansleep(unsigned num, unsigned *gpios, int *values)
+{
+ struct gpio_chip *chip;
+
+ might_sleep_if(extra_checks);
+ chip = gpio_to_chip(gpios[0]);
+ chip->set_sync(chip, num, gpios, values);
+}
+EXPORT_SYMBOL_GPL(gpio_set_values_sync_cansleep);
+
#ifdef CONFIG_DEBUG_FS
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index d6c379d..c181623 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -88,6 +88,10 @@ struct gpio_chip {
unsigned offset, int value);
void (*set)(struct gpio_chip *chip,
unsigned offset, int value);
+ /* NOTE: _sync() version accepts gpios, not offsets. */
+ void (*set_sync)(struct gpio_chip *chip,
+ unsigned num, unsigned *gpios,
+ int *values);
int (*to_irq)(struct gpio_chip *chip,
unsigned offset);
@@ -121,6 +125,8 @@ extern int gpio_direction_output(unsigned gpio, int value);
extern int gpio_get_value_cansleep(unsigned gpio);
extern void gpio_set_value_cansleep(unsigned gpio, int value);
+extern void gpio_set_values_sync_cansleep(unsigned num, unsigned *gpios,
+ int *values);
/* A platform's <asm/gpio.h> code may want to inline the I/O calls when
@@ -129,6 +135,8 @@ extern void gpio_set_value_cansleep(unsigned gpio, int value);
*/
extern int __gpio_get_value(unsigned gpio);
extern void __gpio_set_value(unsigned gpio, int value);
+extern int __gpio_can_set_values_sync(unsigned num, unsigned *gpios);
+extern void __gpio_set_values_sync(unsigned num, unsigned *gpios, int *values);
extern int __gpio_cansleep(unsigned gpio);
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index e10c49a..ff62c1e 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -62,6 +62,20 @@ static inline void gpio_set_value(unsigned gpio, int value)
WARN_ON(1);
}
+static inline int gpio_can_set_values_sync(unsigned num, unsigned *gpios)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_set_values_sync(unsigned num, unsigned *gpios,
+ int *values)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+}
+
static inline int gpio_cansleep(unsigned gpio)
{
/* GPIO can never have been requested or set as {in,out}put */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/2] Setting GPIOs simultaneously
From: Anton Vorontsov @ 2009-07-13 15:19 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-kernel
Hi all,
I've been sitting on these patches for some time, but now it appears
that the set_sync() feature is needed elsewhere. So here are the
patches.
Joakim, I think this is what you need.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Soft Reset for PPC44x Virtex 5 hangs saying Restarting System
From: Grant Likely @ 2009-07-13 15:02 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev
In-Reply-To: <6213bc560907130016n2f2d5066t3dc88032200da8ef@mail.gmail.com>
On Mon, Jul 13, 2009 at 1:16 AM, srikanth
krishnakar<skrishnakar@gmail.com> wrote:
> Hi all,
>
> Kernel : Linux-2.6.29
> Arch: Powerpc (ppc44x)
> Target: Xilinx ML507 Virtex5
>
> I have an issue in "Reset System" of Xilinx ML507 target board. I am using
> Compact Flash to boot the target ( using system ACE file to boot the
> target), during the process reset or reboot command on the target, I am not
> able to reboot the target completely, here is the snapshot:
Where is your boot code located? In BRAM? or SDRAM? If it is in
RAM, then it is likely that your boot code gets overwritten when the
Linux kernel boots and so soft resetting the processor will result in
a hung system (because it doesn't have any boot code to run).
> -----------------------------------------------------------------------------------------------------
>
> The target again doesn't provide me the boot options as obtained when done
> hard reset :
What boot options are you referring to? SystemACE boot configuration?
The current system ace driver doesn't have any support for either
setting the boot options or using the systemace to reboot the system
by reconfiguring the FPGA. It shouldn't be hard to do, it just hasn't
been written.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* SPI driver on mpc5121
From: Canella Matteo @ 2009-07-13 14:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I'm on a mpc5121 platform, kernel 2.6.24.6, and I'm using the mpc512x_psc_s=
pi driver to communicate =A0with a touch screen controller.
I'm sending commands and reading data from the controller using 24-bit pack=
et (3 bytes).
The speed of the SPI is set to 640 KHz.
I thought that I would need 8/640K =3D 12,5 us each byte I send, but this i=
s not true.
I'm verifying the time needed by mpc512x_psc_spi_transfer_rxtx function in =
order to send one byte toggling a digital output when it sets the TX/RX fla=
gs (after it copies data in the transmission buffer) and toggling the outpu=
t again when the empty buffer interrupt is triggered.
I see that the actual 12,5us data transfer is preceded by a 20us delay and =
followed by another 15,6us delay. So the transfer is done in almost 50 us.
Is this a normal behavior? Does the PSC controller need this overhead in th=
e transfer time?
DSCKI and DTL delays are set to zero.
Another doubt I have:
In mpc512x_psc_spi_transfer_rxtx, Mode Register 2 of the PSC is set to zero=
. This is done (as manual says) by access to MR1 (by a read) and then write=
a zero on the same address.:
in_8(&psc->mode);
mdelay(1);
out_8(&psc->mode, 0x0);
mdelay(1);
I don't understand why a 1ms delay is needed. The manual doesn't say anythi=
ng about this.
I tried to comment out these delays and anyway it seems to work correctly.
Best regards,
Matteo Canella
^ permalink raw reply
* Re: mmap() problem in own driver
From: Arnd Bergmann @ 2009-07-13 14:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sauce.Cheng
In-Reply-To: <24457031.post@talk.nabble.com>
On Monday 13 July 2009, Sauce.Cheng wrote:
> I want to get data from kernel space to user space indirectly using mmap()
> but i dont know how I can do , anyone can give me some advices ?
>
> firstly, fetch data by DMA to a memory allocated by "kmalloc"
> then i want to mmap it to user space and save the data as a file
You first need to allocate full pages, e.g. using alloc_pages() instead
of kmalloc, which may not be aligned. To get a streaming mapping on
that memory, use dma_map_single(), which returns a DMA address you
can pass to the device.
For user space access, the easiest is to have a character device,
which uses an mmap() file operation that calls remap_pfn_range()
on the page_to_pfn(pages).
Arnd <><
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-13 10:05 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, linuxppc-dev,
joerg.roedel, mingo
In-Reply-To: <20090713185247W.fujita.tomonori@lab.ntt.co.jp>
On Mon, 2009-07-13 at 18:53 +0900, FUJITA Tomonori wrote:
> On Mon, 13 Jul 2009 10:40:29 +0100
> Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
>
> > On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> > > On Fri, 10 Jul 2009 15:02:00 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >
> > > > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > > > I don't think that we need to take account of dom0 support; we don't
> > > > > have a clear idea about an acceptable dom0 design (it needs to use
> > > > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > > > support in mainline. That's why I didn't CC this patchset to Xen
> > > > > camp.
> > > >
> > > > The core domain 0 patches which were the subject of the discussions a
> > > > few week back are completely orthogonal to the swiotlb side of things
> > >
> > > ? If we don't merge dom0 patch, we don't need dom0 changes to
> > > swiotlb. We don't know we would have dom0 support in mainline. Or I
> > > overlooked something?
> > [...]
> > > As far as I know, you have not posted anything about changes to
> > > swiotlb for domU. I can't discuss it. If you want, please send
> > > patches.
> >
> > There are no separate domU swiotlb patches -- the exact the same patches
> > as we have already been discussing are useful and necessary for both
> > domU and dom0.
>
> Hmm, you guys introduced the swiotlb hooks by saying that it's for
> only dom0.
That was just sloppy wording on our part. domain 0 is the major usecase
today so there is a tendency to think in those terms but the changes are
actually relevant to any domain with access to a physical device that
can do DMA, this includes domU via PCI passthrough.
> I don't see any comments like 'this is useful to dom0 too'. I'm still
^U?
> not sure what exactly part is useful to domU.
All of it...
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 9:53 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, fujita.tomonori,
linuxppc-dev, joerg.roedel, mingo
In-Reply-To: <1247478029.11668.10.camel@zakaz.uk.xensource.com>
On Mon, 13 Jul 2009 10:40:29 +0100
Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> > On Fri, 10 Jul 2009 15:02:00 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > > I don't think that we need to take account of dom0 support; we don't
> > > > have a clear idea about an acceptable dom0 design (it needs to use
> > > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > > support in mainline. That's why I didn't CC this patchset to Xen
> > > > camp.
> > >
> > > The core domain 0 patches which were the subject of the discussions a
> > > few week back are completely orthogonal to the swiotlb side of things
> >
> > ? If we don't merge dom0 patch, we don't need dom0 changes to
> > swiotlb. We don't know we would have dom0 support in mainline. Or I
> > overlooked something?
> [...]
> > As far as I know, you have not posted anything about changes to
> > swiotlb for domU. I can't discuss it. If you want, please send
> > patches.
>
> There are no separate domU swiotlb patches -- the exact the same patches
> as we have already been discussing are useful and necessary for both
> domU and dom0.
Hmm, you guys introduced the swiotlb hooks by saying that it's for
only dom0.
=
http://lkml.org/lkml/2008/12/16/351
Hi Ingo,
Here's some patches to clean up swiotlb to prepare for some Xen dom0
patches. These have been posted before, but undergone a round of
cleanups to address various comments.
=
I don't see any comments like 'this is useful to dom0 too'. I'm still
not sure what exactly part is useful to domU.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-13 9:40 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy@goop.org, tony.luck@intel.com, linux-ia64@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, joerg.roedel@amd.com, mingo@elte.hu
In-Reply-To: <20090713131859N.fujita.tomonori@lab.ntt.co.jp>
On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> On Fri, 10 Jul 2009 15:02:00 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > I don't think that we need to take account of dom0 support; we don't
> > > have a clear idea about an acceptable dom0 design (it needs to use
> > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > support in mainline. That's why I didn't CC this patchset to Xen
> > > camp.
> >
> > The core domain 0 patches which were the subject of the discussions a
> > few week back are completely orthogonal to the swiotlb side of things
>
> ? If we don't merge dom0 patch, we don't need dom0 changes to
> swiotlb. We don't know we would have dom0 support in mainline. Or I
> overlooked something?
[...]
> As far as I know, you have not posted anything about changes to
> swiotlb for domU. I can't discuss it. If you want, please send
> patches.
There are no separate domU swiotlb patches -- the exact the same patches
as we have already been discussing are useful and necessary for both
domU and dom0.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 9:16 UTC (permalink / raw)
To: mingo
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, Ian.Campbell,
linuxppc-dev, joerg.roedel
In-Reply-To: <20090713131157V.fujita.tomonori@lab.ntt.co.jp>
On Mon, 13 Jul 2009 13:20:22 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> On Fri, 10 Jul 2009 16:12:48 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > > functionality and reimplemented the surrounding infrastructure in
> > > terms of that (and incorporating our additional requirements). I
> > > prototyped this (it is currently unworking, in fact it seems to
> > > have developed rather a taste for filesystems :-() but the
> > > diffstat of my WIP patch is:
> > >
> > > arch/x86/kernel/pci-swiotlb.c | 6
> > > arch/x86/xen/pci-swiotlb.c | 2
> > > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > > include/linux/swiotlb.h | 12 +
> > > lib/swiotlb.c | 10 -
> > > 5 files changed, 385 insertions(+), 30 deletions(-)
> > >
> > > where a fair number of the lines in xen-iommu.c are copies of
> > > functions from swiotlb.c with minor modifications. As I say it
> > > doesn't work yet but I think it's roughly indicative of what such
> > > an approach would look like. I don't like it much but am happy to
> > > run with it if it looks to be the most acceptable approach. [...]
> >
> > +400 lines of code to avoid much fewer lines of generic code impact
> > on the lib/swiotlb.c side sounds like a bad technical choice to me.
>
> The amount of code is not the point. The way to impact on the
> lib/swiotlb.c is totally wrong from the perspective of the kernel
> design; it uses architecture code in the very original (xen) way.
btw, '+400 lines of code to avoid much fewer lines of generic code
impact on the lib/swiotlb.c' doesn't sound true to me.
Here is a patch in the way that Xen people want to do:
http://patchwork.kernel.org/patch/26343/
---
arch/x86/Kconfig | 4 +
arch/x86/include/asm/io.h | 2 +
arch/x86/include/asm/pci_x86.h | 1 +
arch/x86/include/asm/xen/iommu.h | 12 ++
arch/x86/kernel/pci-dma.c | 3 +
arch/x86/pci/Makefile | 1 +
arch/x86/pci/init.c | 6 +
arch/x86/pci/xen.c | 51 +++++++
drivers/pci/Makefile | 2 +
drivers/pci/xen-iommu.c | 271 ++++++++++++++++++++++++++++++++++++++
Even with the way that Xen people want to do, drivers/pci/xen-iommu.c
is about 300 lines. And my patchset removes the nice amount of lines
for dom0 support. I don't see much difference wrt lines.
^ permalink raw reply
* Soft Reset for PPC44x Virtex 5 hangs saying Restarting System
From: srikanth krishnakar @ 2009-07-13 7:16 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
Hi all,
Kernel : Linux-2.6.29
Arch: Powerpc (ppc44x)
Target: Xilinx ML507 Virtex5
I have an issue in "Reset System" of Xilinx ML507 target board. I am using
Compact Flash to boot the target ( using system ACE file to boot the
target), during the process reset or reboot command on the target, I am not
able to reboot the target completely, here is the snapshot:
---------------------------------------------------------------------------------------------------
root@ml507:~# reboot
INIT: Sending processes the TERM signalWed Jul
INIT: Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid
1052)
.
Stopping Vixie-cron.
Stopping network benchmark server: netserverstopped /usr/sbin/netserver (pid
1058)
.
Stopping syslogd/klogd: stopped syslogd (pid 1061)
stopped klogd (pid 1063)
done
NOT deconfiguring network interfaces: / is an NFS mount
Sending all processes the TERM signal...
Sending all processes the KILL signal...
hwclock: can't open '/dev/misc/rtc': No such file or directory
Unmounting remote filesystems...
Deactivating swap...
/etc/rc6.d/S40umountfs: line 9: swapoff: not found
Unmounting local filesystems...
umount2: Device or resource busy
umount: none busy - remounted read-only
Rebooting... Restarting system. <--------------- Target
hangs here..
-----------------------------------------------------------------------------------------------------
The target again doesn't provide me the boot options as obtained when done
hard reset :
Welcome to the Xilinx Virtex-5 ML507 Evaluation Platform Bootloader
Menu!
Please choose a demo by typing in the number of the demo you want to
use
Or select a demo using the directional buttons (C,W,S,E,N)
(Then press the center (C) button to start the selected demo)
1. Virtex-5 Slide Show
2. Web Server Demo
3. Simon Game
4. Board Diagnostics (XROM)
5. USB Demo
6. My own ACE file
7. Ring Tone Player
Rebooting to System ACE Configuration Address 6...
zImage starting: loaded at 0x00800000 (sp: 0x00a44fb0)
Allocating 0x4e9138 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080e000:0x00a437cc)...done 0x4a1bcc bytes
Any comments or suggestions are appreciated !!
Thanks
-Sriknt
[-- Attachment #2: Type: text/html, Size: 2616 bytes --]
^ permalink raw reply
* mmap() problem in own driver
From: Sauce.Cheng @ 2009-07-13 7:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everyone
there is a problem of my own driver
I want to get data from kernel space to user space indirectly using mmap()
but i dont know how I can do , anyone can give me some advices ?
firstly, fetch data by DMA to a memory allocated by "kmalloc"
then i want to mmap it to user space and save the data as a file
Cheers everyone~
Martin
--
View this message in context: http://www.nabble.com/mmap%28%29-problem-in-own-driver-tp24457031p24457031.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, fujita.tomonori,
linuxppc-dev, joerg.roedel, mingo
In-Reply-To: <1247234520.4002.418.camel@zakaz.uk.xensource.com>
On Fri, 10 Jul 2009 15:02:00 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > I don't think that we need to take account of dom0 support; we don't
> > have a clear idea about an acceptable dom0 design (it needs to use
> > swiotlb code? I don't know yet), we don't even know we will have dom0
> > support in mainline. That's why I didn't CC this patchset to Xen
> > camp.
>
> The core domain 0 patches which were the subject of the discussions a
> few week back are completely orthogonal to the swiotlb side of things
? If we don't merge dom0 patch, we don't need dom0 changes to
swiotlb. We don't know we would have dom0 support in mainline. Or I
overlooked something?
> and whatever form they eventually take I do not think it will have any
> impact on the shape of the solution which we arrive at for swiotlb. I
> don't think that assuming that domain 0 can never be done in a way which
> everyone finds acceptable and therefore discounting all consideration of
> it is a useful way to make progress with these issues.
>
> The DMA use case is much more tightly tied to the paravirtualized MMU
> (which is already in the kernel for domU purposes) than it is to "the
> domain 0" patches anyway. Although domain 0 is probably the main use
> case, at least today, swiotlb support is also used in a Xen domU as part
> of the support for direct assignment of PCI devices to paravirtualised
> guests (pci passthrough).
>
> The pci frontend driver depends on some bits of the domain 0 physical
> interrupt patches as well as swiotlb which is why I/we haven't tried to
> upstream that particular series yet.
As far as I know, you have not posted anything about changes to
swiotlb for domU. I can't discuss it. If you want, please send
patches.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: mingo
Cc: fujita.tomonori, jeremy, tony.luck, linux-ia64, x86, linux-kernel,
Ian.Campbell, linuxppc-dev, joerg.roedel
In-Reply-To: <20090710141248.GE26264@elte.hu>
On Fri, 10 Jul 2009 16:12:48 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> > functionality and reimplemented the surrounding infrastructure in
> > terms of that (and incorporating our additional requirements). I
> > prototyped this (it is currently unworking, in fact it seems to
> > have developed rather a taste for filesystems :-() but the
> > diffstat of my WIP patch is:
> >
> > arch/x86/kernel/pci-swiotlb.c | 6
> > arch/x86/xen/pci-swiotlb.c | 2
> > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > include/linux/swiotlb.h | 12 +
> > lib/swiotlb.c | 10 -
> > 5 files changed, 385 insertions(+), 30 deletions(-)
> >
> > where a fair number of the lines in xen-iommu.c are copies of
> > functions from swiotlb.c with minor modifications. As I say it
> > doesn't work yet but I think it's roughly indicative of what such
> > an approach would look like. I don't like it much but am happy to
> > run with it if it looks to be the most acceptable approach. [...]
>
> +400 lines of code to avoid much fewer lines of generic code impact
> on the lib/swiotlb.c side sounds like a bad technical choice to me.
The amount of code is not the point. The way to impact on the
lib/swiotlb.c is totally wrong from the perspective of the kernel
design; it uses architecture code in the very original (xen) way.
> It makes the swiotlb code less useful and basically forks a random
> implementation of it in drivers/pci/xen-iommu.c.
I don't think so. We always have the reasonable amount of duplication
rather than integration in a dirty way (at least about IOMMU
code).
> Fujita-san, can you think of a solution that avoids the whole-sale
> copying of hundreds of lines of code?
Ian didn't give a pointer to his code in a public place so I'm not
sure his claim is valid. But if his code does the right thing and
the duplication is less than 400 lines, it doesn't sound that bad to
me.
^ permalink raw reply
* [PATCH 1/5] drivers/char/hvc_console.c: Drop unnecessary NULL test
From: Julia Lawall @ 2009-07-12 20:03 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The result of container_of should not be NULL. In particular, in this case
the argument to the enclosing function has passed though INIT_WORK, which
dereferences it, implying that its container cannot be NULL.
A simplified version of the semantic patch that makes this change is as
follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
identifier fn,work,x,fld;
type T;
expression E1,E2;
statement S;
@@
static fn(struct work_struct *work) {
... when != work = E1
x = container_of(work,T,fld)
... when != x = E2
- if (x == NULL) S
...
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/char/hvc_console.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 94e7e3c..e367630 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -516,8 +516,6 @@ static void hvc_set_winsz(struct work_struct *work)
struct winsize ws;
hp = container_of(work, struct hvc_struct, tty_resize);
- if (!hp)
- return;
spin_lock_irqsave(&hp->lock, hvc_flags);
if (!hp->tty) {
^ permalink raw reply related
* Re: Memory usage of a process
From: Nicholas Mc Guire @ 2009-07-11 10:05 UTC (permalink / raw)
To: G?nter Leonhardt; +Cc: linuxppc-dev
In-Reply-To: <D0B748CCD5DF144CA5C56A9D860A31341DE613@men-exch1.intra.men.de>
On Fri, 10 Jul 2009, G?nter Leonhardt wrote:
>
> Hello,
> analysing the memory usage of a process, I found some questions.
> I'am using a system with 128 MB physical RAM, no disk, 2.6.27 kernel.
>
> Running top, I see 38 MB in use, 90 MB free, but a VSZ for my process of 158 MB.
> Looking at /proc/<pid>/maps, I see that the process uses 140 MB without shared libs.
>
> So how it is possible that the process can allocate more memory than there is, without posibility of swapping?
>
> Why said top that 90 MB free? Does the kernel serve the allocation only if ist really used?
>
an allocation does not actually set aside any physical ram (unless you do an mlock and actually touch the memory) - it only reserves virtual memory areas (vma's) and when your process accesses the respective address the OS page-faults and prvides the physical RAM as needed (and possible) - if you have no swap and you allow overcommitting of memory then you are potentially going to see this application failing as soon as it tries to utilize the memory.
This can be set in the system via /proc/sys/vm/overcommit_memory (see
linux/Documentation/vm/overcommit-accounting for details).
hofrat
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:08 UTC (permalink / raw)
To: Kumar Gala, Scott Wood, linuxppc-dev@ozlabs.org list,
bug-binutils, Edmar Wienskoski-RA8797
In-Reply-To: <20090711000503.GO3181@bubble.grove.modra.org>
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?
/me reads other email. I see you did. Applying.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:05 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <4F69F333-8BCA-4BB8-A5C1-4B25EA5D1287@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
> binutils-2.19 _end is what we expect
> binutils-2.19.1 _end is what we expect
> binutils-2.19.50.0.1 _end is what we expect
> binutils-2.19.51.0.1 _end is 00001000
>
> From the release notes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
Yes, I already have good reason to suspect this patch
2008-10-22 Alan Modra <amodra@bigpond.net.au>
* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
sections.
* emultempl/elf32.em (enum orphan_save_index): Add orphan_nonalloc.
(hold): Likewise.
(gld${EMULATION_NAME}_place_orphan): Handle non-alloc orphans.
causes the change in linker behaviour. Did you try the patch I posted?
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Benjamin Herrenschmidt @ 2009-07-10 23:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2iqi0w83z.fsf@igel.home>
On Fri, 2009-07-10 at 23:17 +0200, Andreas Schwab wrote:
> When moving load_up_altivec to vector.S a typo in a comment caused a
> thinko setting the wrong variable.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Good catch, thanks.
Cheers,
Ben.
> ---
> diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
> index ef36cbb..ea4d646 100644
> --- a/arch/powerpc/kernel/vector.S
> +++ b/arch/powerpc/kernel/vector.S
> @@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
> mtvscr vr0
> REST_32VRS(0,r4,r5)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_altivec to 'current' */
> subi r4,r5,THREAD /* Back to 'current' */
> fromreal(r4)
> - PPC_STL r4,ADDROFF(last_task_used_math)(r3)
> + PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
> #endif /* CONFIG_SMP */
> /* restore registers and return */
> blr
> @@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
> oris r12,r12,MSR_VSX@h
> std r12,_MSR(r1)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_vsx to 'current' */
> ld r4,PACACURRENT(r13)
> std r4,0(r3)
> #endif /* CONFIG_SMP */
>
^ permalink raw reply
* [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Andreas Schwab @ 2009-07-10 21:17 UTC (permalink / raw)
To: linuxppc-dev
When moving load_up_altivec to vector.S a typo in a comment caused a
thinko setting the wrong variable.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index ef36cbb..ea4d646 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
mtvscr vr0
REST_32VRS(0,r4,r5)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_altivec to 'current' */
subi r4,r5,THREAD /* Back to 'current' */
fromreal(r4)
- PPC_STL r4,ADDROFF(last_task_used_math)(r3)
+ PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
#endif /* CONFIG_SMP */
/* restore registers and return */
blr
@@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
oris r12,r12,MSR_VSX@h
std r12,_MSR(r1)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_vsx to 'current' */
ld r4,PACACURRENT(r13)
std r4,0(r3)
#endif /* CONFIG_SMP */
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-10 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <D2ADC85F-2986-42EA-B8AD-03F30E871A55@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:36:20AM -0500, Kumar Gala wrote:
>
> On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>>
>>> Ok, is this the one you want me to push upstream?
>>>
>>
>> Yep, this is the finished version.
>>
>> Thanks,
>> Ira
>>
>>> doug t
>>
>
> is that for .31 or .32? If .31 I'm fine. If for .32 I still have some
> things I like to deal with. (like the other 85xx specific bits)
>
.32 is fine for me. This is a new feature, not really a bugfix. I can
maintain it in my (growing) set of patches against mainline until it
gets merged.
Ira
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-10 15:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090710150420.GA11719@ovro.caltech.edu>
On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>
>> Ok, is this the one you want me to push upstream?
>>
>
> Yep, this is the finished version.
>
> Thanks,
> Ira
>
>> doug t
>
is that for .31 or .32? If .31 I'm fine. If for .32 I still have
some things I like to deal with. (like the other 85xx specific bits)
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:34 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090710041123.GD3181@bubble.grove.modra.org>
On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:
> Hmm, having said all that, the following linker patch seems reasonable
> to me and probably won't break anything else (always some risk).
> Please test it for me.
>
> Index: ld/ldlang.c
> ===================================================================
> RCS file: /cvs/src/src/ld/ldlang.c,v
> retrieving revision 1.311
> diff -u -p -r1.311 ldlang.c
> --- ld/ldlang.c 25 Jun 2009 13:18:46 -0000 1.311
> +++ ld/ldlang.c 10 Jul 2009 04:04:57 -0000
> @@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
> idea is to skip over anything that might be inside a SECTIONS {}
> statement in a script, before we find another output section
> statement. Assignments to "dot" before an output section statement
> - are assumed to belong to it. An exception to this rule is made
> for
> - the first assignment to dot, otherwise we might put an orphan
> - before . = . + SIZEOF_HEADERS or similar assignments that set the
> - initial address. */
> + are assumed to belong to it, except in two cases; The first
> + assignment to dot, and assignments before non-alloc sections.
> + Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
> + similar assignments that set the initial address, or we might
> + insert non-alloc note sections among assignments setting end of
> + image symbols. */
>
> static lang_statement_union_type **
> insert_os_after (lang_output_section_statement_type *after)
> @@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
> continue;
> case lang_output_section_statement_enum:
> if (assign != NULL)
> - where = assign;
> + {
> + asection *s = (*where)->output_section_statement.bfd_section;
> +
> + if (s == NULL || (s->flags & SEC_ALLOC) != 0)
> + where = assign;
> + }
> break;
> case lang_input_statement_enum:
> case lang_address_statement_enum:
>
> --
This patch seems to "fix" things.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Edmar Wienskoski-RA8797,
Alan Modra, bug-binutils
In-Reply-To: <D4C31507-B4F9-4979-A6E1-7971242D644B@kernel.crashing.org>
On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:
>
> On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
>
>> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
>> wrote:
>>> I understand your arguments, but there is something inconsistent
>>> about this.
>>> If I change the script to be:
>>> _end3 = . ;
>>> . = _end3;
>>> . = ALIGN(PAGE_SIZE);
>>> _end = . ;
>>> PROVIDE32 (end = .);
>>> }
>>> The result is corrected:
>>> c067f678 A _end3
>>> c0680000 A _end
>>>
>>> Why the apuinfo section with zero VMA sometimes interfere with "."
>>> and
>>> sometimes not ?
>>
>> I said it was weird in my last email. Not so. The orphan gets
>> placed
>> between
>>
>> _end3 = . ;
>> . = _end3;
>>
>> So dot is restored after the orphan section sets it.
>
> This seems to be a bit of a chick and egg scenario. Older kernel
> linker scripts aren't going to cover all sections and thus may have
> orphan sections. How do we ensure _end can be set properly under
> such conditions?
Not sure if this helps, but I've isolated down the version of binutils
that changes to:
binutils-2.19 _end is what we expect
binutils-2.19.1 _end is what we expect
binutils-2.19.50.0.1 _end is what we expect
binutils-2.19.51.0.1 _end is 00001000
From the release notes:
binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
- k
^ 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