* Problems with busybox or filesystem ...
From: Georg Schardt @ 2008-04-03 10:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi again,
its strange, now i have a filesystem with busybox 1.7.0 working if i
boot from systemace - module.
if i create a jffs2 image with the same filesystem, put it into flash
and try to boot from flash busybox hangs after a few bytes of output.
using kernel 2.6 from git.xilinx.com on a virtex4fx12 minimodul:
Output from kernel, and a few Bytes from busybox:
[ 2.219956] VFS: Mounted root (jffs2 filesystem).
[ 2.224084] Freeing unused kernel memory: 100k init
init
2.6. Lin
and then nothing :)
i tried a few other things:
- put the rootfs in a ramdisk -> same problem, but sometimes a few bytes
more output :)
- change busybox version -> same problem
- change to secretlab kernel -> same problem
- use another gcc glibc version on crosscompiler -> same version
Whats wrong ? Its just a device missing ? Does the kernel unmounts the
rootfs after starting init or something like this ? i this a problem
with the console/serial device ? i have no idea what i can try next.
its very frustrating :)
thanks
georg
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ permalink raw reply
* linux 2.6 and xps_ethernetlite
From: Matteo Vit @ 2008-04-03 9:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm planning to use the xps_ethernetlite with linux 2.6 kernel (xilinx
git for example). Is there support for it ? Can I use the
opb_ethernetlite driver ?
Does anybody use it with the ML403 or Avnet FX12 MM boards ? what are
the performance (for example with netperf) ?
Best regards,
--
Matteo VIT
R&D engineer
DAVE Srl - Electronics System House
via Forniz 2/1 33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
Telefax: +39.0434.1994030
web: www.dave.eu
e-mail: matteo.vit@dave.eu
how to reach us: http://mail.map24.com/dave
^ permalink raw reply
* [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: René Bürgel @ 2008-04-03 8:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
Here is a patch for the lite5200 to get the FEC working again for kernel
>=2.6.25.
The FEC driver is also compatible with the MPC5200, not only with the
MPC5200B, so an according entry was added to the drivers matching list.
Furthermore the settings for the PHY were entered in the dts file for
the Lite5200. Note, that this is not exactly the same as in the
Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
at :00 for the 5200B. I could test the patch on a Lite5200 and a
Lite5200B, both booted a kernel via tftp and mounted the root via nfs
successfully.
I hope, you can include the patch into the official tree.
Signed-off-by: René Bürgel <r.buergel@unicontrol.de>
Kind regards, René Bürgel
--
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 12
Fax: 03 72 06/ 88 73 - 60
E-Mail: r.buergel@unicontrol.de
Internet: www.unicontrol.de
Unicontrol Systemtechnik GmbH
Geschäftsführer: Dipl.-Ing. Siegfried Heinze
Sitz der Gesellschaft: Frankenberg
Registergericht: Amtsgericht Chemnitz, HRB 15 475
Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen können Betriebs- und Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige vertrauliche Informationen
enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen der Status dieser E-Mail bekannt. Bitte benachrichtigen Sie uns in diesem Falle sofort durch
Antwort-Mail und löschen Sie diese E-Mail nebst etwaigen Anlagen aus Ihrem System. Ebenso dürfen Sie diese E-Mail oder ihre Anlagen nicht kopieren oder an Dritte
weitergeben. Vielen Dank!
Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure.
If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your
system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank
you.
[-- Attachment #2: lite5200_fec_on_linux_2.6.25.patch --]
[-- Type: text/plain, Size: 1702 bytes --]
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 0d701c1..09b4e16 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -258,6 +258,21 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
};
ata@3a00 {
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 58b71e6..fe59c27 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -1057,6 +1057,7 @@ static int mpc52xx_fec_of_resume(struct of_device *op)
#endif
static struct of_device_id mpc52xx_fec_match[] = {
+ { .type = "network", .compatible = "fsl,mpc5200b-fec", },
{ .type = "network", .compatible = "fsl,mpc5200-fec", },
{ .type = "network", .compatible = "mpc5200-fec", },
{ }
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 6a3ac4e..1d0cd1d 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -179,6 +179,7 @@ static int mpc52xx_fec_mdio_remove(struct of_device *of)
static struct of_device_id mpc52xx_fec_mdio_match[] = {
{ .compatible = "fsl,mpc5200b-mdio", },
+ { .compatible = "fsl,mpc5200-mdio", },
{ .compatible = "mpc5200b-fec-phy", },
{}
};
^ permalink raw reply related
* RE: Xilinx LLTEMAC driver issues
From: MingLiu @ 2008-04-03 8:28 UTC (permalink / raw)
To: John Bonesio, Johann Baudy; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <20080403003200.CB2BF1968046@mail103-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Dear all,
> The change with the extra parenthesis (in the patch starting with line 133) seems unecessary. I looked at the XLlDma_mBdWrite macro and it appeared to have the correct use of parethesis in the implementation.> So, assuming there's nothing subtle that I missed, it's not needed. However, it does no harm either.
However it really helps after I tried this patch. So there should be some difference after it is used.
One more question, does this mean that the problem is not on the hardware timing, but the device driver?
BR
Ming
_________________________________________________________________
用手机MSN聊天写邮件看空间，无限沟通，分享精彩！
http://mobile.msn.com.cn/
[-- Attachment #2: Type: text/html, Size: 929 bytes --]
^ permalink raw reply
* SD over SPI mpc5200b
From: tosettofabio83 @ 2008-04-03 7:58 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to enable the SD over SPI on a emebedded system with one
processor powerpc mpc5200b,
has someone patches for the Linux 2.6.22 versions?
Thanks Fabio.
^ permalink raw reply
* [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Kumar Gala @ 2008-04-03 6:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: hollisb
Wanted to get any feedback on this initial port of the fixmap support over
from x86. There are a few TODOs:
* change HIGHMEM support to use fixmap
* fixup up VMALLOC config to respect fixmap
(after initial powerpc patch is in tree/accepted):
* rework a few bits of fixmap.h into an asm-generic/fixmap.h
The reason for introducing fixmap into ppc32 is it provides us with a
clean way of getting fixed compile time virtual addresses for things.
Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe
44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump
support on ppc32 can take advantage of it. I'm also told this is useful
for hypervisor interactions.
One question for the guys looking at hypervisor. The x86 code also has a
function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is
this functionality something useful on ppc? If so for what?
- k
---
arch/powerpc/mm/pgtable_32.c | 18 ++++++
include/asm-powerpc/fixmap.h | 123 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 141 insertions(+), 0 deletions(-)
create mode 100644 include/asm-powerpc/fixmap.h
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 64c44bc..fa0e48e 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -29,6 +29,7 @@
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
+#include <asm/fixmap.h>
#include <asm/io.h>
#include "mmu_decl.h"
@@ -387,3 +388,20 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
}
#endif /* CONFIG_DEBUG_PAGEALLOC */
+
+static int fixmaps;
+unsigned long __FIXADDR_TOP = 0xfffff000;
+EXPORT_SYMBOL(__FIXADDR_TOP);
+
+void __set_fixmap (enum fixed_addresses idx, phys_addr_t phys, pgprot_t flags)
+{
+ unsigned long address = __fix_to_virt(idx);
+
+ if (idx >= __end_of_fixed_addresses) {
+ BUG();
+ return;
+ }
+
+ map_page(address, phys, flags);
+ fixmaps++;
+}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
new file mode 100644
index 0000000..7b570e5
--- /dev/null
+++ b/include/asm-powerpc/fixmap.h
@@ -0,0 +1,123 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ *
+ * Copyright 2008 Freescale Semiconductor Inc.
+ * Port to powerpc added by Kumar Gala
+ */
+
+#ifndef _ASM_FIXMAP_H
+#define _ASM_FIXMAP_H
+
+
+/* used by vmalloc.c, vsyscall.lds.S.
+ *
+ * Leave one empty page between vmalloc'ed areas and
+ * the start of the fixmap.
+ */
+extern unsigned long __FIXADDR_TOP;
+#define FIXADDR_USER_START __fix_to_virt(FIX_VDSO)
+#define FIXADDR_USER_END __fix_to_virt(FIX_VDSO - 1)
+
+#ifndef __ASSEMBLY__
+#include <linux/kernel.h>
+#include <asm/page.h>
+#ifdef CONFIG_HIGHMEM
+#include <linux/threads.h>
+#include <asm/kmap_types.h>
+#endif
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xfffff000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+ FIX_VDSO,
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+#ifdef CONFIG_PCI_MMCONFIG
+ FIX_PCIE_MCFG,
+#endif
+ __end_of_fixed_addresses
+};
+
+extern void __set_fixmap (enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define FIXADDR_TOP ((unsigned long)__FIXADDR_TOP)
+
+#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define __FIXADDR_BOOT_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
+#define FIXADDR_BOOT_START (FIXADDR_TOP - __FIXADDR_BOOT_SIZE)
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+extern void __this_fixmap_does_not_exist(void);
+
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without tranlation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ /*
+ * this branch gets completely eliminated after inlining,
+ * except when someone tries to use fixaddr indices in an
+ * illegal way. (such as mixing up address types or using
+ * out-of-range indices).
+ *
+ * If it doesn't get removed, the linker will complain
+ * loudly with a reasonably clear error message..
+ */
+ if (idx >= __end_of_fixed_addresses)
+ __this_fixmap_does_not_exist();
+
+ return __fix_to_virt(idx);
+}
+
+static inline unsigned long virt_to_fix(const unsigned long vaddr)
+{
+ BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+ return __virt_to_fix(vaddr);
+}
+
+#endif /* !__ASSEMBLY__ */
+#endif
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-04-03 6:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18420.31327.633359.619200@cargo.ozlabs.ibm.com>
On Apr 3, 2008, at 1:34 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> For a kdump kernel, at least for 64-bit, the physical address has to
>>> be 32MB. There is no other choice, so there is no possibility of
>>> confusion.
>>
>> But how do you know a vmlinux image is for kdump or not?
>
> By looking at the ELF headers -- either the first PT_LOAD segment or
> the .text section -- and seeing whether the start address is
> 0xc000000002000000 or not.
fair point.
>>> For 85xx, would it be possible to have the kernel figure out what
>>> physical address it has been loaded at, and use that as the base
>>> address, rather than having the base address set at compile time?
>>
>> Yes, that is what CONFIG_RELOCATABLE is all about.
>
> Is there any reason to have that as an option, rather than just always
> doing that?
Concerned about runtime performance of __va() and __pa().
>>> That would solve my objection since it would mean that there would
>>> no
>>> longer be two things that had to be kept in sync. You could pass
>>> any
>>> value to wrapper/mkimage (subject to constraints such as it has to
>>> be
>>> a multiple of 256M) and it would work. That value could even come
>>> from a config option in the case where wrapper is invoked as part of
>>> the kernel build, but that config option shouldn't affect anything
>>> at
>>> all in the vmlinux.
>>
>> Ok, but I still think the issues exists when we config PHYSICAL_START
>> to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys
>> address the PHDR, but I'm not sure how to get the linker to do that.
>
> If we can do that then the wrapper script can dig it out and pass it
> to mkimage, which would solve the problem.
Ok, so on Segher's recommendation I looked at 'AT' and posted a patch
that uses that so now regardless of the kernel the PT_LOAD PHDR will
have the physical address set properly.
So now we can look at the vmlinux and determine the physical offset.
The question is how best to do that. Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that read's the elf and reports back
[looking for suggestion on what direction you want to take]
The other questions is if we'd ever have a vmlinux with more than one
PT_LOAD PHDR. If so which one do we use (the one with the lowest
physical address)?
- k
^ permalink raw reply
* Please pull from 'for-2.6.25' branch [UPDATED]
From: Kumar Gala @ 2008-04-03 6:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
(Added trivial cpm2 fix from Laurent)
- k
arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8379_mds.dts | 8 ++++----
arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 +--
arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc837x_rdb_defconfig | 24 +++++++++++++++++++++++-
arch/powerpc/configs/mpc83xx_defconfig | 24 +++++++++++++++++++++++-
arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++--------
arch/powerpc/configs/mpc8568mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++--------
arch/powerpc/configs/mpc85xx_defconfig | 11 +++--------
arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++--------
arch/powerpc/configs/prpmc2800_defconfig | 11 +++--------
arch/powerpc/configs/storcenter_defconfig | 11 +++--------
arch/powerpc/sysdev/cpm2.c | 1 +
drivers/ata/sata_fsl.c | 5 +----
drivers/dma/fsldma.c | 8 ++++----
20 files changed, 91 insertions(+), 102 deletions(-)
Anton Vorontsov (1):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
Kim Phillips (2):
[POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
[POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata
Kumar Gala (2):
[POWERPC] fsldma: Use compatiable binding as spec
[POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
Laurent Pinchart (1):
[POWERPC] Fix CPM2 SCC1 clock initialization.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
From: Kumar Gala @ 2008-04-03 6:39 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804021646.31765.laurentp@cse-semaphore.com>
On Apr 2, 2008, at 9:46 AM, Laurent Pinchart wrote:
> A missing break statement in a switch caused cpm2_clk_setup() to
> initialize
> SCC2 instead of SCC1. This patch fixes the bug.
>
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> arch/powerpc/sysdev/cpm2.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied.
However your email is malformatted. Since it was a trivial patch I
fixed it up by hand.
- k
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Paul Mackerras @ 2008-04-03 6:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <0F53B076-0A94-4A2D-8D9A-ED507B53ABE6@kernel.crashing.org>
Kumar Gala writes:
> > For a kdump kernel, at least for 64-bit, the physical address has to
> > be 32MB. There is no other choice, so there is no possibility of
> > confusion.
>
> But how do you know a vmlinux image is for kdump or not?
By looking at the ELF headers -- either the first PT_LOAD segment or
the .text section -- and seeing whether the start address is
0xc000000002000000 or not.
> > For 85xx, would it be possible to have the kernel figure out what
> > physical address it has been loaded at, and use that as the base
> > address, rather than having the base address set at compile time?
>
> Yes, that is what CONFIG_RELOCATABLE is all about.
Is there any reason to have that as an option, rather than just always
doing that?
> > That would solve my objection since it would mean that there would no
> > longer be two things that had to be kept in sync. You could pass any
> > value to wrapper/mkimage (subject to constraints such as it has to be
> > a multiple of 256M) and it would work. That value could even come
> > from a config option in the case where wrapper is invoked as part of
> > the kernel build, but that config option shouldn't affect anything at
> > all in the vmlinux.
>
> Ok, but I still think the issues exists when we config PHYSICAL_START
> to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys
> address the PHDR, but I'm not sure how to get the linker to do that.
If we can do that then the wrapper script can dig it out and pass it
to mkimage, which would solve the problem.
Paul.
^ permalink raw reply
* [PATCH] [POWERPC] Update linker script to properly set physical addresses
From: Kumar Gala @ 2008-04-03 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much stolen from how x86 does things in their linker
scripts.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul,
This patch is top of my existing series of mm init cleanup/rework.
- k
arch/powerpc/kernel/vmlinux.lds.S | 47 ++++++++++++++++++-------------------
include/asm-powerpc/page.h | 1 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index b5a76bc..0c3000b 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -31,7 +31,7 @@ SECTIONS
*/
/* Text and gots */
- .text : {
+ .text : AT(ADDR(.text) - LOAD_OFFSET) {
ALIGN_FUNCTION();
*(.text.head)
_text = .;
@@ -56,7 +56,7 @@ SECTIONS
RODATA
/* Exception & bug tables */
- __ex_table : {
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
@@ -72,7 +72,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
- .init.text : {
+ .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
_einittext = .;
@@ -81,11 +81,11 @@ SECTIONS
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
*/
- .exit.text : {
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
EXIT_TEXT
}
- .init.data : {
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
__vtop_table_begin = .;
*(.vtop_fixup);
@@ -101,19 +101,19 @@ SECTIONS
}
. = ALIGN(16);
- .init.setup : {
+ .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
__setup_start = .;
*(.init.setup)
__setup_end = .;
}
- .initcall.init : {
+ .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
__initcall_start = .;
INITCALLS
__initcall_end = .;
}
- .con_initcall.init : {
+ .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
@@ -122,14 +122,14 @@ SECTIONS
SECURITY_INIT
. = ALIGN(8);
- __ftr_fixup : {
+ __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
__start___ftr_fixup = .;
*(__ftr_fixup)
__stop___ftr_fixup = .;
}
#ifdef CONFIG_PPC64
. = ALIGN(8);
- __fw_ftr_fixup : {
+ __fw_ftr_fixup : AT(ADDR(__fw_ftr_fixup) - LOAD_OFFSET) {
__start___fw_ftr_fixup = .;
*(__fw_ftr_fixup)
__stop___fw_ftr_fixup = .;
@@ -137,14 +137,14 @@ SECTIONS
#endif
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(PAGE_SIZE);
- .init.ramfs : {
+ .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
}
#endif
. = ALIGN(PAGE_SIZE);
- .data.percpu : {
+ .data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
*(.data.percpu.shared_aligned)
@@ -152,7 +152,7 @@ SECTIONS
}
. = ALIGN(8);
- .machine.desc : {
+ .machine.desc : AT(ADDR(.machine.desc) - LOAD_OFFSET) {
__machine_desc_start = . ;
*(.machine.desc)
__machine_desc_end = . ;
@@ -170,25 +170,24 @@ SECTIONS
_sdata = .;
#ifdef CONFIG_PPC32
- .data :
- {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.sdata)
*(.got.plt) *(.got)
}
#else
- .data : {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.data.rel*)
*(.toc1)
*(.branch_lt)
}
- .opd : {
+ .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
*(.opd)
}
- .got : {
+ .got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
*(.toc)
@@ -205,26 +204,26 @@ SECTIONS
#else
. = ALIGN(16384);
#endif
- .data.init_task : {
+ .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
*(.data.init_task)
}
. = ALIGN(PAGE_SIZE);
- .data.page_aligned : {
+ .data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
*(.data.page_aligned)
}
- .data.cacheline_aligned : {
+ .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
*(.data.cacheline_aligned)
}
. = ALIGN(L1_CACHE_BYTES);
- .data.read_mostly : {
+ .data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
*(.data.read_mostly)
}
. = ALIGN(PAGE_SIZE);
- __data_nosave : {
+ .data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
__nosave_begin = .;
*(.data.nosave)
. = ALIGN(PAGE_SIZE);
@@ -235,7 +234,7 @@ SECTIONS
* And finally the bss
*/
- .bss : {
+ .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
__bss_start = .;
*(.sbss) *(.scommon)
*(.dynbss)
diff --git a/include/asm-powerpc/page.h b/include/asm-powerpc/page.h
index adf0591..cffdf0e 100644
--- a/include/asm-powerpc/page.h
+++ b/include/asm-powerpc/page.h
@@ -69,6 +69,7 @@
#define KERNELBASE ASM_CONST(CONFIG_KERNEL_START)
#define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
+#define LOAD_OFFSET ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
#ifndef __ASSEMBLY__
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix a mm compile error
From: Kumar Gala @ 2008-04-03 6:20 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev, paulus, linuxppc-embedded
In-Reply-To: <1207177533-30598-1-git-send-email-Emilian.Medve@Freescale.com>
On Apr 2, 2008, at 6:05 PM, Emil Medve wrote:
> arch/powerpc/mm/init_32.c:102: error: conflicting types for
> '__initial_memory_limit_addr'
> arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of
> '__initial_memory_limit_addr' was here
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
> arch/powerpc/mm/init_32.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
> index 555bb7e..63c5e3d 100644
> --- a/arch/powerpc/mm/init_32.c
> +++ b/arch/powerpc/mm/init_32.c
> @@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM;
> * address of the limit of what is accessible with initial MMU setup -
> * 256MB usually, but only 16MB on 601.
> */
> -unsigned long __initial_memory_limit_addr = 0x10000000;
> +phys_addr_t __initial_memory_limit_addr = 0x10000000;
I should have fixed this in my tree, if there are still issues let me
know.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
From: Stefan Roese @ 2008-04-03 5:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080402202546.24ac1a95@zod.rchland.ibm.com>
On Thursday 03 April 2008, Josh Boyer wrote:
> On Thu, 27 Mar 2008 15:43:31 +0100
>
> Stefan Roese <sr@denx.de> wrote:
> > diff --git a/arch/powerpc/platforms/44x/sequoia.c
> > b/arch/powerpc/platforms/44x/sequoia.c index d279db4..1782d41 100644
> > --- a/arch/powerpc/platforms/44x/sequoia.c
> > +++ b/arch/powerpc/platforms/44x/sequoia.c
> > @@ -23,8 +23,6 @@
> > #include <asm/uic.h>
> > #include <asm/pci-bridge.h>
> >
> > -#include "44x.h"
> > -
>
> Almost a perfect patch. Alas, missing a #include <asm/ppc4xx.h> which
> breaks the sequoia build.
>
> I'll fix it up locally :).
Thanks Josh. I missed that one.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Arnd Bergmann @ 2008-04-03 4:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <fa686aa40804021943m208c2ff0va6c6b629a747439f@mail.gmail.com>
On Thursday 03 April 2008, Grant Likely wrote:
> >
> > =A0Since it is not really compatible with ns16550, shouldn't you at lea=
st specify
> > =A0a different "compatible" property? That way, the driver won't do inc=
orrect
> > =A0accesses when you try to use an old driver with a device tree that s=
pecifies
> > =A0one of these.
>=20
> Heh; we've gone back and forth on this issue. =A0The problem is that we
> have a common case of ns16550 like devices that require a little bit
> of register address tweaking that spans a whole range of vendors (so
> adding a compatible match with each of those vendor's prefixes is
> probably non-scalable). =A0So, if "ns16550" is not a good idea, then
> what should be used? =A0"sparse16550" has been suggested more than once.
After another IRC discussion between Grant, Segher and myself, we concluded
that we don't need to invent a new "compatible" value, as only new device
trees with old kernels will have a problem with this, and they don't work
in the first place.
The devices will still have their specific "compatible" value, e.g.
"xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
"ns16450" and "i8250", although the last two do not have an effect
on Linux.
Josh, can you please forward all three patches in their latest version?
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Yinghai Lu @ 2008-04-03 4:16 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel list, Kamalesh Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Balbir Singh
In-Reply-To: <20080402192223.5e8754a0.akpm@linux-foundation.org>
On Wed, Apr 2, 2008 at 7:22 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
>
> > v2 replace:
> > [PATCH] mm: make mem_map allocation continuous.
> > [PATCH] mm: allocate section_map for sparse_init
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> >
>
> err, no.
>
>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index f6a43c0..2881222 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
>
> Sorry, but I'd rather not do it this way. We presently have this:
>
it replaces
> mm-make-mem_map-allocation-continuous.patch
> mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch
> mm-allocate-section_map-for-sparse_init.patch
> mm-allocate-section_map-for-sparse_init-update.patch
> mm-allocate-section_map-for-sparse_init-update-fix.patch
> mm-allocate-section_map-for-sparse_init-powerpc-fix.patch
others still needed
so mm-make-mem-map-allocation-continuous.patch will not break powerpc and ia64
YH
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Yasunori Goto @ 2008-04-03 3:22 UTC (permalink / raw)
To: yhlu.kernel
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Andrew Morton, Ingo Molnar, Balbir Singh
In-Reply-To: <200804021830.24563.yhlu.kernel@gmail.com>
Looks good to me. And ia64 boots up with this patch too.
Thanks.
Acked-by: Yasunori Goto <y-goto@jp.fujitsu.com>
>
> vmemmap allocation current got
> [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
> [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001800000 on node 0
> [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001c00000 on node 0
> [ffffe20000600000-ffffe200007fffff] PMD ->ffff810002000000 on node 0
> [ffffe20000800000-ffffe200009fffff] PMD ->ffff810002400000 on node 0
> ...
>
> there is 2M hole between them.
>
> the rootcause is that usemap (24 bytes) will be allocated after every 2M
> mem_map. and it will push next vmemmap (2M) to next align (2M).
>
> solution:
> try to allocate mem_map continously.
>
> after patch, will get
> [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
> [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
> [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001800000 on node 0
> [ffffe20000600000-ffffe200007fffff] PMD ->ffff810001a00000 on node 0
> [ffffe20000800000-ffffe200009fffff] PMD ->ffff810001c00000 on node 0
> ...
> and usemap will share in page because of they are allocated continuously too.
> sparse_early_usemap_alloc: usemap = ffff810024e00000 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00080 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00100 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00180 size = 24
> ...
>
> so we make the bootmem allocation more compact and use less memory for usemap.
>
> for power pc
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > You have to call sparse_init_one_section() on each pmap and usemap
> > as we allocate - since valid_section() depends on it (which is needed
> > by vmemmap_populate() to check if the section is populated or not).
> > On ppc, we need to call htab_bolted_mapping() on each section and
> > we need to skip existing sections.
>
> so try to allocate usemap at first altogether.
>
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f6a43c0..2881222 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,22 +294,48 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> + unsigned long **usemap_map;
> + int size;
> +
> + /*
> + * map is using big page (aka 2M in x86 64 bit)
> + * usemap is less one page (aka 24 bytes)
> + * so alloc 2M (with 2M align) and 24 bytes in turn will
> + * make next 2M slip to one more 2M later.
> + * then in big system, the memory will have a lot of holes...
> + * here try to allocate 2M pages continously.
> + *
> + * powerpc need to call sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map at first.
> + */
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> + }
>
> - map = sparse_early_mem_map_alloc(pnum);
> - if (!map)
> + for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> + if (!present_section_nr(pnum))
> continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
>
> + map = sparse_early_mem_map_alloc(pnum);
> + if (!map)
> + continue;
> +
> sparse_init_one_section(__nr_to_section(pnum), pnum, map,
> usemap);
> }
> +
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Yasunori Goto
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-03 2:43 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, John Linn
In-Reply-To: <200804030134.11437.arnd@arndb.de>
On Wed, Apr 2, 2008 at 5:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 03 April 2008, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based addressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
> >
> > This code updates the of_serial driver to handle the reg-offset
> > and reg-shift properties to enable this core to be used.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
>
> I may not be the best driver maintainer, but please keep the illusion
> alive for me and Cc me on patches to drivers I wrote ;-)
>
>
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > index 87f4d84..4066ec8 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
> > differ between different families. May be
> > 'virtex2p', 'virtex4', or 'virtex5'.
> >
> > + iv) Xilinx Uart 16550
> > +
> > + Xilinx UART 16550 devices are very similar to the NS16550 but with
> > + different register spacing and an offset from the base address.
> > +
> > + Requred properties:
> > + - clock-frequency : Frequency of the clock input
> > + - reg-offset : A value of 3 is required
> > + - reg-shift : A value of 2 is required
> > +
> > More devices will be defined as this spec matures.
>
> Since it is not really compatible with ns16550, shouldn't you at least specify
> a different "compatible" property? That way, the driver won't do incorrect
> accesses when you try to use an old driver with a device tree that specifies
> one of these.
Heh; we've gone back and forth on this issue. The problem is that we
have a common case of ns16550 like devices that require a little bit
of register address tweaking that spans a whole range of vendors (so
adding a compatible match with each of those vendor's prefixes is
probably non-scalable). So, if "ns16550" is not a good idea, then
what should be used? "sparse16550" has been suggested more than once.
On the other side of the coin; the draft ePAPR spec already redefines
the meaning of "ns16550" to add an optional "reg-shift" property.
Also, in this particular case the problem is most likely more
theoretical than actual. The likely hood of a platform needing these
new properties being handed a kernel which does not support the
"reg-*" properties is very slim.
Anyway, all that just to say that I prefer "ns16550", but I'll put my
vote and support behind "sparse16550" (or any other string) if other
people express consensus with it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Andrew Morton @ 2008-04-03 2:22 UTC (permalink / raw)
To: yhlu.kernel
Cc: Balbir, Kamalesh, kernel list, Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Singh
In-Reply-To: <200804021830.24563.yhlu.kernel@gmail.com>
On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
err, no.
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f6a43c0..2881222 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
Sorry, but I'd rather not do it this way. We presently have this:
mm-make-mem_map-allocation-continuous.patch
mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch
mm-fix-alloc_bootmem_core-to-use-fast-searching-for-all-nodes.patch
mm-allocate-section_map-for-sparse_init.patch
mm-allocate-section_map-for-sparse_init-update.patch
mm-allocate-section_map-for-sparse_init-update-fix.patch
mm-allocate-section_map-for-sparse_init-powerpc-fix.patch
mm-offset-align-in-alloc_bootmem.patch
mm-make-reserve_bootmem-can-crossed-the-nodes.patch
mm-make-reserve_bootmem-can-crossed-the-nodes-checkpatch-fixes.patch
and you purport to throw some of them away and combine them into a single
patch? We assume that the later patches will still apply and work on top
of this newer patch? It is up to me to check that the replacement patch
incorporates the third-party changes to the original patches?
Too hard, too risky. Can't we just do a fix against 2.6.25-rc8-mm1?
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Arnd Bergmann @ 2008-04-03 2:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, John Linn
In-Reply-To: <20080402195600.67b2eaf2@zod.rchland.ibm.com>
On Thursday 03 April 2008, Josh Boyer wrote:
> > > > =C2=A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xil=
inx.com>
> > > > =C2=A0Signed-off-by: John Linn <john.linn@xilinx.com>
> > > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >=20
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>=20
> This is the second time all three of us have Acked this. =C2=A0I'm pulling
> it in my tree.
>=20
Hehe, thanks!
I never know what the right thing to do with of_serial patches is.
In the past, I've sent them to akpm, in the absense of a dedicated
serial driver maintainer, but I'm just as happy when they get into
mainline any other way.
Of course, it feels a bit wrong for me to forward a patch that
was never sent to me personally.
Arnd <><
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 1:43 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel list, Kamalesh Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Balbir Singh
In-Reply-To: <86802c440804021744m7c6e3d94vcb6af3ebcaa71b5b@mail.gmail.com>
On Wed, Apr 2, 2008 at 5:44 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
> On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> >
> > > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> > >
> > > on powerpc,
> > >
> > > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > >
> > > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > > > Andrew Morton wrote:
> > > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > so try to allocate usemap at first altogether.
> >
> > I have to turn all the above crud into a proper changelog. I'd prefer that
> > you do it.
> >
> > Unless this patch should be folded into another one, in which case it
> > doesn't matter.
> >
> >
> > > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> > >
> > > diff --git a/mm/sparse.c b/mm/sparse.c
> > > index d3cb085..782ebe5 100644
> > > --- a/mm/sparse.c
> > > +++ b/mm/sparse.c
> >
> > We shouldn't merge this patch on its own because then that will leave a
> > non-bisectable region in the powerpc history.
> >
> > So which patch is this patch fixing? Lexically it applies to
> > mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
> > that where it logically lies?
>
> yes. we should fold
>
>
> mm-make-mem_map-allocation-continuous.patch
>
> mm-allocate-section_map-for-sparse_init.patch
> and this one
>
please check the big one.
http://lkml.org/lkml/2008/4/2/650
YH
^ permalink raw reply
* [PATCH] mm: make mem_map allocation continuous v2.
From: Yinghai Lu @ 2008-04-03 1:30 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Balbir Singh
In-Reply-To: <86802c440804021744m7c6e3d94vcb6af3ebcaa71b5b@mail.gmail.com>
vmemmap allocation current got
[ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
[ffffe20000200000-ffffe200003fffff] PMD ->ffff810001800000 on node 0
[ffffe20000400000-ffffe200005fffff] PMD ->ffff810001c00000 on node 0
[ffffe20000600000-ffffe200007fffff] PMD ->ffff810002000000 on node 0
[ffffe20000800000-ffffe200009fffff] PMD ->ffff810002400000 on node 0
...
there is 2M hole between them.
the rootcause is that usemap (24 bytes) will be allocated after every 2M
mem_map. and it will push next vmemmap (2M) to next align (2M).
solution:
try to allocate mem_map continously.
after patch, will get
[ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
[ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
[ffffe20000400000-ffffe200005fffff] PMD ->ffff810001800000 on node 0
[ffffe20000600000-ffffe200007fffff] PMD ->ffff810001a00000 on node 0
[ffffe20000800000-ffffe200009fffff] PMD ->ffff810001c00000 on node 0
...
and usemap will share in page because of they are allocated continuously too.
sparse_early_usemap_alloc: usemap = ffff810024e00000 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00080 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00100 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00180 size = 24
...
so we make the bootmem allocation more compact and use less memory for usemap.
for power pc
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
so try to allocate usemap at first altogether.
v2 replace:
[PATCH] mm: make mem_map allocation continuous.
[PATCH] mm: allocate section_map for sparse_init
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/mm/sparse.c b/mm/sparse.c
index f6a43c0..2881222 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,22 +294,48 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
+ unsigned long **usemap_map;
+ int size;
+
+ /*
+ * map is using big page (aka 2M in x86 64 bit)
+ * usemap is less one page (aka 24 bytes)
+ * so alloc 2M (with 2M align) and 24 bytes in turn will
+ * make next 2M slip to one more 2M later.
+ * then in big system, the memory will have a lot of holes...
+ * here try to allocate 2M pages continously.
+ *
+ * powerpc need to call sparse_init_one_section right after each
+ * sparse_early_mem_map_alloc, so allocate usemap_map at first.
+ */
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+ panic("can not allocate usemap_map\n");
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
+ usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
+ }
- map = sparse_early_mem_map_alloc(pnum);
- if (!map)
+ for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+ if (!present_section_nr(pnum))
continue;
- usemap = sparse_early_usemap_alloc(pnum);
+ usemap = usemap_map[pnum];
if (!usemap)
continue;
+ map = sparse_early_mem_map_alloc(pnum);
+ if (!map)
+ continue;
+
sparse_init_one_section(__nr_to_section(pnum), pnum, map,
usemap);
}
+
+ free_bootmem(__pa(usemap_map), size);
}
#ifdef CONFIG_MEMORY_HOTPLUG
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
From: Josh Boyer @ 2008-04-03 1:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1206629011-28821-1-git-send-email-sr@denx.de>
On Thu, 27 Mar 2008 15:43:31 +0100
Stefan Roese <sr@denx.de> wrote:
> diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
> index d279db4..1782d41 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -23,8 +23,6 @@
> #include <asm/uic.h>
> #include <asm/pci-bridge.h>
>
> -#include "44x.h"
> -
Almost a perfect patch. Alas, missing a #include <asm/ppc4xx.h> which
breaks the sequoia build.
I'll fix it up locally :).
josh
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-03 1:16 UTC (permalink / raw)
To: John Linn, linuxppc-dev, grant.likely
In-Reply-To: <20080403000229.GA6663@localhost.localdomain>
On Wed, Apr 2, 2008 at 6:02 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based adressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
> >
> > This code updates the ns16550 driver to use the reg-offset property
> > so that the Xilinx UART 16550 can be used with it. The reg-shift
> > was already being handled.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> > arch/powerpc/boot/ns16550.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> > index f8f1b2f..da9d2c2 100644
> > --- a/arch/powerpc/boot/ns16550.c
> > +++ b/arch/powerpc/boot/ns16550.c
> > @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> > {
> > int n;
> > unsigned long reg_phys;
> > + u32 reg_offset;
> >
> > n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> > if (n != sizeof(reg_base)) {
> > @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> > reg_base = (void *)reg_phys;
> > }
> >
> > + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> > + if (n == sizeof(reg_offset))
> > + reg_base += reg_offset;
>
> Uh... how does the behaviour of reg-offset differ from just bumping
> the address in "reg"?
Mostly because the registers are actually 32 bit registers that can be
accessed with 32bit reads at offset 0. Using this property keeps the
reg property describing the real address range.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Josh Boyer @ 2008-04-03 0:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <200804030139.05497.arnd@arndb.de>
On Thu, 3 Apr 2008 01:39:04 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 02 April 2008, Grant Likely wrote:
> > On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> > > From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > >
> > > =C2=A0The of_serial driver queries the current-speed property and att=
empts
> > > =C2=A0to use it to register the custom_divisor property of the uart_p=
ort.
> > > =C2=A0However, if current-speed is not set, then this code will deref=
erence
> > > =C2=A0a bad pointer. =C2=A0The fix is to only set custom_divisor when=
a
> > > =C2=A0current-speed property appears in the device tree.
> > >
> > > =C2=A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilin=
x.com>
> > > =C2=A0Signed-off-by: John Linn <john.linn@xilinx.com>
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
>=20
> Acked-by: Arnd Bergmann <arnd@arndb.de>
This is the second time all three of us have Acked this. I'm pulling
it in my tree.
josh
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 0:47 UTC (permalink / raw)
To: Badari Pulavarty
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Ingo Molnar, Balbir Singh
In-Reply-To: <1207180285.30407.45.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 4:51 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> > so try to allocate usemap at first altogether.
> >
> > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -294,7 +294,7 @@ void __init sparse_init(void)
> > unsigned long pnum;
> > struct page *map;
> > unsigned long *usemap;
> > - struct page **section_map;
> > + unsigned long **usemap_map;
> > int size;
> > int node;
> >
> > @@ -305,27 +305,31 @@ void __init sparse_init(void)
> > * make next 2M slip to one more 2M later.
> > * then in big system, the memmory will have a lot hole...
> > * here try to allocate 2M pages continously.
>
> Comments are x86-64 specific. On ppc its 16MB chunks :(
>
>
>
> > + *
> > + * powerpc hope to sparse_init_one_section right after each
> > + * sparse_early_mem_map_alloc, so allocate usemap_map
> > + * at first.
> > */
> > - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> > - section_map = alloc_bootmem(size);
> > - if (!section_map)
> > - panic("can not allocate section_map\n");
> > + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> > + usemap_map = alloc_bootmem(size);
> > + if (!usemap_map)
> > + panic("can not allocate usemap_map\n");
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> > - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> > + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> > }
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> >
> > - map = section_map[pnum];
> > + map = sparse_early_mem_map_alloc(pnum);
> > if (!map)
> > continue;
> >
> > - usemap = sparse_early_usemap_alloc(pnum);
> > + usemap = usemap_map[pnum];
> > if (!usemap)
> > continue;
>
> You may want to move this check before doing sparse_early_mem_map_alloc
> (). We are also not handling errors properly (freeing up the unused
> map or usemap) if we "continue". I know the original code is this way,
> but you touched it last :)
Yes. could avoid some leak...
YH
^ 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