* DTC Updates
From: Jon Loeliger @ 2007-10-16 13:32 UTC (permalink / raw)
To: linuxppc-dev
Guys and Dolls,
I pushed out all of David's recent DTC and libfdt patches.
I also jammed the following patch into the mix as well.
HTH,
jdl
commit 9e32930ebcacfcf7cb7c1c2b8e776eb3957cf6cb
Author: Jon Loeliger <jdl@freescale.com>
Date: Tue Oct 16 07:35:38 2007 -0500
Restore warning message about bison expected output.
It was dropped in ad9593f229362782b953da4b805df713e8468df0.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
diff --git a/Makefile b/Makefile
index 84f0efe..d7d1af5 100644
--- a/Makefile
+++ b/Makefile
@@ -207,6 +207,7 @@ clean: libfdt_clean tests_clean
%.tab.c %.tab.h %.output: %.y
@$(VECHO) BISON $@
+ @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
$(BISON) -d $<
FORCE:
^ permalink raw reply related
* Re: Merge dtc
From: Grant Likely @ 2007-10-16 13:17 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer, linuxppc-dev
In-Reply-To: <20071016050217.GA9052@localhost.localdomain>
On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> This very large patch incorporates a copy of dtc into the kernel
> source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> longer an external dependency to build kernels with configurations
> which need a dtb file.
Powerpc is probably not going to be the only user of dtc. Microblaze
will be using it too. Can it be put somewhere more common?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: dtc: Improve support for string escapes
From: Jon Loeliger @ 2007-10-16 13:14 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071016064202.GC9052@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> dtc supports the use of C-style escapes (\n, \t and so forth) in
> string property definitions via the data_copy_escape_string()
> function. However, while it supports the most common escape
> characters, it doesn't support the full set that C does, which is a
> potential gotcha.
>
> Worse, a bug in the lexer means that while data_copy_escape_string()
> can handle the \" escape, a string with such an escape won't lex
> correctly.
>
> This patch fixes both problems, extending data_copy_escape_string() to
> support the missing escapes, and fixing the regex for strings in the
> lexer to handle internal escaped quotes.
>
> This also adds a testcase for string escape functionality.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Excellent. Thanks.
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ dtc/tests/string_escapes.c 2007-10-16 16:34:20.000000000 +1000
> @@ -0,0 +1,42 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Testcase for strinc escapes in dtc
Applied, modulo fixing that typo.
jdl
^ permalink raw reply
* Re: libfdt: Add functions for handling the "compatible" property
From: Jon Loeliger @ 2007-10-16 12:43 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071016035825.GR26787@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds functions for dealing with the compatible property.
> fdt_node_check_compatible() can be used to determine whether a node is
> compatible with a given string and fdt_node_offset_by_compatible()
> locates nodes with a given compatible string.
>
> Testcases for these functions are also included.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: dtc: Don't delete *.test.dtb between testgroups
From: Jon Loeliger @ 2007-10-16 12:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071016035320.GQ26787@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The dtc/libfdt testsuite creates a number of .dtb files during its
> run. To ensure a clean test run, these are currently deleted before
> each group of tests.
>
> This is, in fact, a mistake, since if something goes wrong in the
> first group of tests, deleting the .dtb at the beginning of the second
> group of tests makes it harder to figure out what the problem was.
>
> This patch changes the script to only delete the files once, before
> the whole test run.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: libfdt_env.h must be included first
From: Jon Loeliger @ 2007-10-16 12:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071016035034.GP26787@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> incorrect, because depending on the environment into which libfdt is
> embedded, libfdt_env.h may be needed to define datatypes used in
> fdt.h. This patch corrects the problem.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> I've sent this one before, but I guess it got lost in the backlog.
Sorry. There was some froohah around it and I didn't track
where it landed.
Applied.
jdl
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-10-16 10:53 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1192514497.19073.29.camel@pasglop>
On Tue, 2007-10-16 at 16:01 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
> > Just out of interest who's complaining? We don't include mkimage
> > for
> > u-boot related builds and I haven't seen any gripes related to that.
>
> It's a pain in the neck since those are built even for things that don't
> need them (such as 4xx where I use the treeboot images).
You might not need them, but others with 4xx boards do. Boards like
Sequoia, etc don't use OpenBIOS. And your compile didn't fail. It just
didn't create the cuImage.
Anyway, I said a couple months ago we should include mkimage in the
kernel and I never got around to doing it. I'll add it to the list.
josh
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Anton Vorontsov @ 2007-10-16 10:55 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4713A474.1000301@ru.mvista.com>
On Mon, Oct 15, 2007 at 09:33:40PM +0400, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
>> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
>> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
>> b/arch/powerpc/boot/dts/mpc8568mds.dts
>> index 8e15dba..1198363 100644
>> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
>> @@ -47,12 +47,45 @@
>> #address-cells = <2>;
>> #size-cells = <1>;
>> reg = <e0005000 d8>;
>> - ranges = <1 0 f8000000 0008000>;
>> + ranges = <1 0 f8000000 0008000
>> + 0 0 fe000000 2000000>;
>> bcsr@1,0 {
>> device_type = "board-control";
>> reg = <1 0 8000>;
>> };
>> +
>> + flash@0,0 {
>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>> + reg = <0 0 2000000>;
>> + probe-type = "CFI";
>
> I don't get it -- has physmap_of.c rewrite been already committed?
> If yes, you don't need probe_type; if no, your "compatible" won't work...
I see.
/* Helper function to handle probing of the obsolete "direct-mapped"
* compatible binding, which has an extra "probe-type" property [...]
Obsolete, very good.
> Well, I see that the driver rewrite has been committed (when I wasn't
> looking 8-)...
>> + bank-width = <2>;
>> + device-width = <1>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + hrcw@0 {
>> + label = "hrcw";
>> + reg = <0 20001>;
>
> What?! Odd sized partition? Don't try to follow both the old and new
> partition device tree specs -- you'll only get yourself into trouble with
> this. The size-cell doesn't bear r/o flag in the new paritions spec.
Thanks for spotting this. It's, of course, forward-porting "thinko".
>> + read-only;
>> + };
>> +
>> + kernel@20000 {
>> + label = "kernel";
>> + reg = <20000 200000>;
>> + };
>> +
>> + rootfs@220000 {
>> + label = "rootfs";
>> + reg = <220000 1d60000>;
>> + };
>> +
>> + uboot@1f80000 {
>> + label = "u-boot";
>> + reg = <1f80000 80000>;
>> + read-only;
>
> Well, this is not even consistent... :-)
Yup, it was a thinko in the hrcw node, not something I really
meant to spread over all ro nodes.
>> + };
>> + };
>> };
>
> WBR, Sergei
Much thanks for the review,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc32 vDSO: linker script indentation
From: Benjamin Herrenschmidt @ 2007-10-16 10:24 UTC (permalink / raw)
To: Roland McGrath
Cc: Linus Torvalds, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Andrew Morton, Sam Ravnborg
In-Reply-To: <20071016034414.BAB4F4D0389@magilla.localdomain>
On Mon, 2007-10-15 at 20:44 -0700, Roland McGrath wrote:
> This cleans up the formatting in the vDSO linker script, mostly just the
> use of whitespace. It's intended to approximate the kernel standard
> conventions for indenting C, treating elements of the linker script about
> like initialized variable definitions.
>
> Signed-off-by: Roland McGrath <roland@redhat.com>
> CC: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/vdso32/vdso32.lds.S | 219 +++++++++++++++++--------------
> 1 files changed, 118 insertions(+), 101 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
> index 26e138c..9352ab5 100644
> --- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
> +++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
> @@ -1,130 +1,147 @@
> -
> /*
> * This is the infamous ld script for the 32 bits vdso
> * library
> */
> #include <asm/vdso.h>
>
> -/* Default link addresses for the vDSOs */
> OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
> OUTPUT_ARCH(powerpc:common)
> ENTRY(_start)
>
> SECTIONS
> {
> - . = VDSO32_LBASE + SIZEOF_HEADERS;
> - .hash : { *(.hash) } :text
> - .gnu.hash : { *(.gnu.hash) }
> - .dynsym : { *(.dynsym) }
> - .dynstr : { *(.dynstr) }
> - .gnu.version : { *(.gnu.version) }
> - .gnu.version_d : { *(.gnu.version_d) }
> - .gnu.version_r : { *(.gnu.version_r) }
> -
> - .note : { *(.note.*) } :text :note
> -
> - . = ALIGN (16);
> - .text :
> - {
> - *(.text .stub .text.* .gnu.linkonce.t.*)
> - }
> - PROVIDE (__etext = .);
> - PROVIDE (_etext = .);
> - PROVIDE (etext = .);
> -
> - . = ALIGN(8);
> - __ftr_fixup : {
> - *(__ftr_fixup)
> - }
> + . = VDSO32_LBASE + SIZEOF_HEADERS;
> +
> + .hash : { *(.hash) } :text
> + .gnu.hash : { *(.gnu.hash) }
> + .dynsym : { *(.dynsym) }
> + .dynstr : { *(.dynstr) }
> + .gnu.version : { *(.gnu.version) }
> + .gnu.version_d : { *(.gnu.version_d) }
> + .gnu.version_r : { *(.gnu.version_r) }
> +
> + .note : { *(.note.*) } :text :note
> +
> + . = ALIGN(16);
> + .text : {
> + *(.text .stub .text.* .gnu.linkonce.t.*)
> + }
> + PROVIDE(__etext = .);
> + PROVIDE(_etext = .);
> + PROVIDE(etext = .);
> +
> + . = ALIGN(8);
> + __ftr_fixup : { *(__ftr_fixup) }
>
> #ifdef CONFIG_PPC64
> - . = ALIGN(8);
> - __fw_ftr_fixup : {
> - *(__fw_ftr_fixup)
> - }
> + . = ALIGN(8);
> + __fw_ftr_fixup : { *(__fw_ftr_fixup) }
> #endif
>
> - /* Other stuff is appended to the text segment: */
> - .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
> - .rodata1 : { *(.rodata1) }
> -
> - .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
> - .eh_frame : { KEEP (*(.eh_frame)) } :text
> - .gcc_except_table : { *(.gcc_except_table) }
> - .fixup : { *(.fixup) }
> -
> - .dynamic : { *(.dynamic) } :text :dynamic
> - .got : { *(.got) }
> - .plt : { *(.plt) }
> -
> - _end = .;
> - __end = .;
> - PROVIDE (end = .);
> -
> -
> - /* Stabs debugging sections are here too
> - */
> - .stab 0 : { *(.stab) }
> - .stabstr 0 : { *(.stabstr) }
> - .stab.excl 0 : { *(.stab.excl) }
> - .stab.exclstr 0 : { *(.stab.exclstr) }
> - .stab.index 0 : { *(.stab.index) }
> - .stab.indexstr 0 : { *(.stab.indexstr) }
> - .comment 0 : { *(.comment) }
> - .debug 0 : { *(.debug) }
> - .line 0 : { *(.line) }
> -
> - .debug_srcinfo 0 : { *(.debug_srcinfo) }
> - .debug_sfnames 0 : { *(.debug_sfnames) }
> -
> - .debug_aranges 0 : { *(.debug_aranges) }
> - .debug_pubnames 0 : { *(.debug_pubnames) }
> -
> - .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
> - .debug_abbrev 0 : { *(.debug_abbrev) }
> - .debug_line 0 : { *(.debug_line) }
> - .debug_frame 0 : { *(.debug_frame) }
> - .debug_str 0 : { *(.debug_str) }
> - .debug_loc 0 : { *(.debug_loc) }
> - .debug_macinfo 0 : { *(.debug_macinfo) }
> -
> - .debug_weaknames 0 : { *(.debug_weaknames) }
> - .debug_funcnames 0 : { *(.debug_funcnames) }
> - .debug_typenames 0 : { *(.debug_typenames) }
> - .debug_varnames 0 : { *(.debug_varnames) }
> -
> - /DISCARD/ : { *(.note.GNU-stack) }
> - /DISCARD/ : { *(.data .data.* .gnu.linkonce.d.* .sdata*) }
> - /DISCARD/ : { *(.bss .sbss .dynbss .dynsbss) }
> + /*
> + * Other stuff is appended to the text segment:
> + */
> + .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
> + .rodata1 : { *(.rodata1) }
> +
> + .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
> + .eh_frame : { KEEP (*(.eh_frame)) } :text
> + .gcc_except_table : { *(.gcc_except_table) }
> + .fixup : { *(.fixup) }
> +
> + .dynamic : { *(.dynamic) } :text :dynamic
> + .got : { *(.got) }
> + .plt : { *(.plt) }
> +
> + _end = .;
> + __end = .;
> + PROVIDE(end = .);
> +
> + /*
> + * Stabs debugging sections are here too.
> + */
> + .stab 0 : { *(.stab) }
> + .stabstr 0 : { *(.stabstr) }
> + .stab.excl 0 : { *(.stab.excl) }
> + .stab.exclstr 0 : { *(.stab.exclstr) }
> + .stab.index 0 : { *(.stab.index) }
> + .stab.indexstr 0 : { *(.stab.indexstr) }
> + .comment 0 : { *(.comment) }
> +
> + /*
> + * DWARF debug sections.
> + * Symbols in the DWARF debugging sections are relative to the beginning
> + * of the section so we begin them at 0.
> + */
> + /* DWARF 1 */
> + .debug 0 : { *(.debug) }
> + .line 0 : { *(.line) }
> + /* GNU DWARF 1 extensions */
> + .debug_srcinfo 0 : { *(.debug_srcinfo) }
> + .debug_sfnames 0 : { *(.debug_sfnames) }
> + /* DWARF 1.1 and DWARF 2 */
> + .debug_aranges 0 : { *(.debug_aranges) }
> + .debug_pubnames 0 : { *(.debug_pubnames) }
> + /* DWARF 2 */
> + .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
> + .debug_abbrev 0 : { *(.debug_abbrev) }
> + .debug_line 0 : { *(.debug_line) }
> + .debug_frame 0 : { *(.debug_frame) }
> + .debug_str 0 : { *(.debug_str) }
> + .debug_loc 0 : { *(.debug_loc) }
> + .debug_macinfo 0 : { *(.debug_macinfo) }
> + /* SGI/MIPS DWARF 2 extensions */
> + .debug_weaknames 0 : { *(.debug_weaknames) }
> + .debug_funcnames 0 : { *(.debug_funcnames) }
> + .debug_typenames 0 : { *(.debug_typenames) }
> + .debug_varnames 0 : { *(.debug_varnames) }
> +
> + /DISCARD/ : {
> + *(.note.GNU-stack)
> + *(.data .data.* .gnu.linkonce.d.* .sdata*)
> + *(.bss .sbss .dynbss .dynsbss)
> + }
> }
>
> +/*
> + * Very old versions of ld do not recognize this name token; use the constant.
> + */
> +#define PT_GNU_EH_FRAME 0x6474e550
>
> +/*
> + * We must supply the ELF program headers explicitly to get just one
> + * PT_LOAD segment, and set the flags explicitly to make segments read-only.
> + */
> PHDRS
> {
> - text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
> - note PT_NOTE FLAGS(4); /* PF_R */
> - dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
> - eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
> + text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
> + dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
> + note PT_NOTE FLAGS(4); /* PF_R */
> + eh_frame_hdr PT_GNU_EH_FRAME;
> }
>
> -
> /*
> * This controls what symbols we export from the DSO.
> */
> VERSION
> {
> - VDSO_VERSION_STRING {
> - global:
> - __kernel_datapage_offset; /* Has to be there for the kernel to find */
> - __kernel_get_syscall_map;
> - __kernel_gettimeofday;
> - __kernel_clock_gettime;
> - __kernel_clock_getres;
> - __kernel_get_tbfreq;
> - __kernel_sync_dicache;
> - __kernel_sync_dicache_p5;
> - __kernel_sigtramp32;
> - __kernel_sigtramp_rt32;
> - local: *;
> - };
> + VDSO_VERSION_STRING {
> + global:
> + /*
> + * Has to be there for the kernel to find
> + */
> + __kernel_datapage_offset;
> +
> + __kernel_get_syscall_map;
> + __kernel_gettimeofday;
> + __kernel_clock_gettime;
> + __kernel_clock_getres;
> + __kernel_get_tbfreq;
> + __kernel_sync_dicache;
> + __kernel_sync_dicache_p5;
> + __kernel_sigtramp32;
> + __kernel_sigtramp_rt32;
> +
> + local: *;
> + };
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc64 vDSO: linker script indentation
From: Benjamin Herrenschmidt @ 2007-10-16 10:23 UTC (permalink / raw)
To: Roland McGrath
Cc: Linus Torvalds, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Andrew Morton, Sam Ravnborg
In-Reply-To: <20071016034333.19BEE4D0389@magilla.localdomain>
On Mon, 2007-10-15 at 20:43 -0700, Roland McGrath wrote:
> This cleans up the formatting in the vDSO linker script, mostly just the
> use of whitespace. It's intended to approximate the kernel standard
> conventions for indenting C, treating elements of the linker script about
> like initialized variable definitions.
>
> Signed-off-by: Roland McGrath <roland@redhat.com>
> CC: Sam Ravnborg <sam@ravnborg.org>
Thanks Roland !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/vdso64/vdso64.lds.S | 225 +++++++++++++++++--------------
> 1 files changed, 122 insertions(+), 103 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S b/arch/powerpc/kernel/vdso64/vdso64.lds.S
> index 2d70f35..932b3fd 100644
> --- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
> +++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
> @@ -10,100 +10,114 @@ ENTRY(_start)
>
> SECTIONS
> {
> - . = VDSO64_LBASE + SIZEOF_HEADERS;
> - .hash : { *(.hash) } :text
> - .gnu.hash : { *(.gnu.hash) }
> - .dynsym : { *(.dynsym) }
> - .dynstr : { *(.dynstr) }
> - .gnu.version : { *(.gnu.version) }
> - .gnu.version_d : { *(.gnu.version_d) }
> - .gnu.version_r : { *(.gnu.version_r) }
> -
> - .note : { *(.note.*) } :text :note
> -
> - . = ALIGN (16);
> - .text :
> - {
> - *(.text .stub .text.* .gnu.linkonce.t.*)
> - *(.sfpr .glink)
> - } :text
> - PROVIDE (__etext = .);
> - PROVIDE (_etext = .);
> - PROVIDE (etext = .);
> -
> - . = ALIGN(8);
> - __ftr_fixup : {
> - *(__ftr_fixup)
> - }
> -
> - . = ALIGN(8);
> - __fw_ftr_fixup : {
> - *(__fw_ftr_fixup)
> - }
> -
> - /* Other stuff is appended to the text segment: */
> - .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
> - .rodata1 : { *(.rodata1) }
> - .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
> - .eh_frame : { KEEP (*(.eh_frame)) } :text
> - .gcc_except_table : { *(.gcc_except_table) }
> -
> - .opd ALIGN(8) : { KEEP (*(.opd)) }
> - .got ALIGN(8) : { *(.got .toc) }
> - .rela.dyn ALIGN(8) : { *(.rela.dyn) }
> -
> - .dynamic : { *(.dynamic) } :text :dynamic
> -
> - _end = .;
> - PROVIDE (end = .);
> -
> - /* Stabs debugging sections are here too
> - */
> - .stab 0 : { *(.stab) }
> - .stabstr 0 : { *(.stabstr) }
> - .stab.excl 0 : { *(.stab.excl) }
> - .stab.exclstr 0 : { *(.stab.exclstr) }
> - .stab.index 0 : { *(.stab.index) }
> - .stab.indexstr 0 : { *(.stab.indexstr) }
> - .comment 0 : { *(.comment) }
> - /* DWARF debug sectio/ns.
> - Symbols in the DWARF debugging sections are relative to the beginning
> - of the section so we begin them at 0. */
> - /* DWARF 1 */
> - .debug 0 : { *(.debug) }
> - .line 0 : { *(.line) }
> - /* GNU DWARF 1 extensions */
> - .debug_srcinfo 0 : { *(.debug_srcinfo) }
> - .debug_sfnames 0 : { *(.debug_sfnames) }
> - /* DWARF 1.1 and DWARF 2 */
> - .debug_aranges 0 : { *(.debug_aranges) }
> - .debug_pubnames 0 : { *(.debug_pubnames) }
> - /* DWARF 2 */
> - .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
> - .debug_abbrev 0 : { *(.debug_abbrev) }
> - .debug_line 0 : { *(.debug_line) }
> - .debug_frame 0 : { *(.debug_frame) }
> - .debug_str 0 : { *(.debug_str) }
> - .debug_loc 0 : { *(.debug_loc) }
> - .debug_macinfo 0 : { *(.debug_macinfo) }
> - /* SGI/MIPS DWARF 2 extensions */
> - .debug_weaknames 0 : { *(.debug_weaknames) }
> - .debug_funcnames 0 : { *(.debug_funcnames) }
> - .debug_typenames 0 : { *(.debug_typenames) }
> - .debug_varnames 0 : { *(.debug_varnames) }
> -
> - /DISCARD/ : { *(.note.GNU-stack) }
> - /DISCARD/ : { *(.branch_lt) }
> - /DISCARD/ : { *(.data .data.* .gnu.linkonce.d.*) }
> - /DISCARD/ : { *(.bss .sbss .dynbss .dynsbss) }
> + . = VDSO64_LBASE + SIZEOF_HEADERS;
> +
> + .hash : { *(.hash) } :text
> + .gnu.hash : { *(.gnu.hash) }
> + .dynsym : { *(.dynsym) }
> + .dynstr : { *(.dynstr) }
> + .gnu.version : { *(.gnu.version) }
> + .gnu.version_d : { *(.gnu.version_d) }
> + .gnu.version_r : { *(.gnu.version_r) }
> +
> + .note : { *(.note.*) } :text :note
> +
> + . = ALIGN(16);
> + .text : {
> + *(.text .stub .text.* .gnu.linkonce.t.*)
> + *(.sfpr .glink)
> + } :text
> + PROVIDE(__etext = .);
> + PROVIDE(_etext = .);
> + PROVIDE(etext = .);
> +
> + . = ALIGN(8);
> + __ftr_fixup : { *(__ftr_fixup) }
> +
> + . = ALIGN(8);
> + __fw_ftr_fixup : { *(__fw_ftr_fixup) }
> +
> + /*
> + * Other stuff is appended to the text segment:
> + */
> + .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
> + .rodata1 : { *(.rodata1) }
> +
> + .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
> + .eh_frame : { KEEP (*(.eh_frame)) } :text
> + .gcc_except_table : { *(.gcc_except_table) }
> +
> + .opd ALIGN(8) : { KEEP (*(.opd)) }
> + .got ALIGN(8) : { *(.got .toc) }
> + .rela.dyn ALIGN(8) : { *(.rela.dyn) }
> +
> + .dynamic : { *(.dynamic) } :text :dynamic
> +
> + _end = .;
> + PROVIDE(end = .);
> +
> + /*
> + * Stabs debugging sections are here too.
> + */
> + .stab 0 : { *(.stab) }
> + .stabstr 0 : { *(.stabstr) }
> + .stab.excl 0 : { *(.stab.excl) }
> + .stab.exclstr 0 : { *(.stab.exclstr) }
> + .stab.index 0 : { *(.stab.index) }
> + .stab.indexstr 0 : { *(.stab.indexstr) }
> + .comment 0 : { *(.comment) }
> +
> + /*
> + * DWARF debug sections.
> + * Symbols in the DWARF debugging sections are relative to the beginning
> + * of the section so we begin them at 0.
> + */
> + /* DWARF 1 */
> + .debug 0 : { *(.debug) }
> + .line 0 : { *(.line) }
> + /* GNU DWARF 1 extensions */
> + .debug_srcinfo 0 : { *(.debug_srcinfo) }
> + .debug_sfnames 0 : { *(.debug_sfnames) }
> + /* DWARF 1.1 and DWARF 2 */
> + .debug_aranges 0 : { *(.debug_aranges) }
> + .debug_pubnames 0 : { *(.debug_pubnames) }
> + /* DWARF 2 */
> + .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
> + .debug_abbrev 0 : { *(.debug_abbrev) }
> + .debug_line 0 : { *(.debug_line) }
> + .debug_frame 0 : { *(.debug_frame) }
> + .debug_str 0 : { *(.debug_str) }
> + .debug_loc 0 : { *(.debug_loc) }
> + .debug_macinfo 0 : { *(.debug_macinfo) }
> + /* SGI/MIPS DWARF 2 extensions */
> + .debug_weaknames 0 : { *(.debug_weaknames) }
> + .debug_funcnames 0 : { *(.debug_funcnames) }
> + .debug_typenames 0 : { *(.debug_typenames) }
> + .debug_varnames 0 : { *(.debug_varnames) }
> +
> + /DISCARD/ : {
> + *(.note.GNU-stack)
> + *(.branch_lt)
> + *(.data .data.* .gnu.linkonce.d.* .sdata*)
> + *(.bss .sbss .dynbss .dynsbss)
> + }
> }
>
> +/*
> + * Very old versions of ld do not recognize this name token; use the constant.
> + */
> +#define PT_GNU_EH_FRAME 0x6474e550
> +
> +/*
> + * We must supply the ELF program headers explicitly to get just one
> + * PT_LOAD segment, and set the flags explicitly to make segments read-only.
> + */
> PHDRS
> {
> - text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
> - note PT_NOTE FLAGS(4); /* PF_R */
> - dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
> - eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
> + text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
> + dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
> + note PT_NOTE FLAGS(4); /* PF_R */
> + eh_frame_hdr PT_GNU_EH_FRAME;
> }
>
> /*
> @@ -111,17 +125,22 @@ PHDRS
> */
> VERSION
> {
> - VDSO_VERSION_STRING {
> - global:
> - __kernel_datapage_offset; /* Has to be there for the kernel to find */
> - __kernel_get_syscall_map;
> - __kernel_gettimeofday;
> - __kernel_clock_gettime;
> - __kernel_clock_getres;
> - __kernel_get_tbfreq;
> - __kernel_sync_dicache;
> - __kernel_sync_dicache_p5;
> - __kernel_sigtramp_rt64;
> - local: *;
> - };
> + VDSO_VERSION_STRING {
> + global:
> + /*
> + * Has to be there for the kernel to find
> + */
> + __kernel_datapage_offset;
> +
> + __kernel_get_syscall_map;
> + __kernel_gettimeofday;
> + __kernel_clock_gettime;
> + __kernel_clock_getres;
> + __kernel_get_tbfreq;
> + __kernel_sync_dicache;
> + __kernel_sync_dicache_p5;
> + __kernel_sigtramp_rt64;
> +
> + local: *;
> + };
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: David Miller @ 2007-10-16 7:44 UTC (permalink / raw)
To: benh; +Cc: netdev, rdreier, shemminger, herbert, linuxppc-dev
In-Reply-To: <1192520223.7205.5.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 16 Oct 2007 17:37:03 +1000
>
> On Tue, 2007-10-16 at 14:06 +0800, Herbert Xu wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > Note: I use msleep_interruptible(1); just like napi_disable(). However
> > > I'm not too happy that the "hot" loop that results of a pending signal
> > > here will spin without even a cpu_relax ... what do you guys think would
> > > be the best way to handle this ?
> >
> > Well since the loop does not check signals at all, it should
> > just use msleep.
> >
> > Granted the process will end up in the D state and contribute
> > to the load average. But if this loop executes long enough
> > for that to be noticed then we've got bigger problems to worry
> > about.
>
> If Dave & Stephen agree, I'll send a patch changing napi_disable() too
> then.
I agree with the msleep() change.
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 7:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, rdreier, shemminger, davem, linuxppc-dev
In-Reply-To: <E1IhfZr-0002FE-00@gondolin.me.apana.org.au>
On Tue, 2007-10-16 at 14:06 +0800, Herbert Xu wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Note: I use msleep_interruptible(1); just like napi_disable(). However
> > I'm not too happy that the "hot" loop that results of a pending signal
> > here will spin without even a cpu_relax ... what do you guys think would
> > be the best way to handle this ?
>
> Well since the loop does not check signals at all, it should
> just use msleep.
>
> Granted the process will end up in the D state and contribute
> to the load average. But if this loop executes long enough
> for that to be noticed then we've got bigger problems to worry
> about.
If Dave & Stephen agree, I'll send a patch changing napi_disable() too
then.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch 12/13] fb: Move and rename extern declaration for global_mode_option
From: Geert Uytterhoeven @ 2007-10-16 7:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20071015144340.167d1cda.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1880 bytes --]
On Mon, 15 Oct 2007, Andrew Morton wrote:
> On Fri, 12 Oct 2007 16:51:04 +0200
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> > - if (mode_option || (mode_option = global_mode_option)) {
> > + if (mode_option || (mode_option = fb_mode_option)) {
>
> I guess that equals-which-looks-like-it-should-be-equals-equals really
> is intended to be an assignment?
>
> I guess. After staring at it for a while. It's a pretty obnoxious way
> of coding it, especially in kernel context where such things are unexpected...
Subject: fb modedb: Refactor confusing mode_option assignment
fb modedb: Refactor confusing mode_option assignment
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/modedb.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -510,7 +510,9 @@ int fb_find_mode(struct fb_var_screeninf
default_bpp = 8;
/* Did the user specify a video mode? */
- if (mode_option || (mode_option = fb_mode_option)) {
+ if (!mode_option)
+ mode_option = fb_mode_option;
+ if (mode_option) {
const char *name = mode_option;
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Herbert Xu @ 2007-10-16 6:06 UTC (permalink / raw)
To: benh; +Cc: netdev, rdreier, shemminger, davem, linuxppc-dev
In-Reply-To: <1192513792.19073.23.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handle this ?
Well since the loop does not check signals at all, it should
just use msleep.
Granted the process will end up in the D state and contribute
to the load average. But if this loop executes long enough
for that to be noticed then we've got bigger problems to worry
about.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* dtc: Improve support for string escapes
From: David Gibson @ 2007-10-16 6:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
dtc supports the use of C-style escapes (\n, \t and so forth) in
string property definitions via the data_copy_escape_string()
function. However, while it supports the most common escape
characters, it doesn't support the full set that C does, which is a
potential gotcha.
Worse, a bug in the lexer means that while data_copy_escape_string()
can handle the \" escape, a string with such an escape won't lex
correctly.
This patch fixes both problems, extending data_copy_escape_string() to
support the missing escapes, and fixing the regex for strings in the
lexer to handle internal escaped quotes.
This also adds a testcase for string escape functionality.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2007-10-16 16:29:37.000000000 +1000
+++ dtc/data.c 2007-10-16 16:29:37.000000000 +1000
@@ -150,12 +150,24 @@ struct data data_copy_escape_string(char
c = s[i++];
assert(c);
switch (c) {
+ case 'a':
+ q[d.len++] = '\a';
+ break;
+ case 'b':
+ q[d.len++] = '\b';
+ break;
case 't':
q[d.len++] = '\t';
break;
case 'n':
q[d.len++] = '\n';
break;
+ case 'v':
+ q[d.len++] = '\v';
+ break;
+ case 'f':
+ q[d.len++] = '\f';
+ break;
case 'r':
q[d.len++] = '\r';
break;
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2007-10-16 16:29:37.000000000 +1000
+++ dtc/dtc-lexer.l 2007-10-16 16:38:03.000000000 +1000
@@ -69,7 +69,7 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
}
}
-\"[^"]*\" {
+\"([^\\"]|\\.)*\" {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("String: %s\n", yytext);
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-10-16 16:29:37.000000000 +1000
+++ dtc/tests/testdata.h 2007-10-16 16:29:37.000000000 +1000
@@ -24,6 +24,7 @@
#define TEST_VALUE_2 cell_to_fdt(0xabcd1234)
#define TEST_STRING_1 "hello world"
+#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\"\xff"
#ifndef __ASSEMBLY__
extern struct fdt_header _test_tree1;
Index: dtc/tests/escapes.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/escapes.dts 2007-10-16 16:29:37.000000000 +1000
@@ -0,0 +1,4 @@
+/ {
+ compatible = "test_string_escapes";
+ escape-str = "nastystring: \a\b\t\n\v\f\r\\\"\xff";
+};
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-10-16 16:29:37.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-10-16 16:30:13.000000000 +1000
@@ -104,6 +104,9 @@ dtc_tests () {
run_test dtc.sh -f -I dts -O dtb -o dtc_tree1.test.dtb test_tree1.dts
tree1_tests dtc_tree1.test.dtb
tree1_tests_rw dtc_tree1.test.dtb
+
+ run_test dtc.sh -f -I dts -O dtb -o dtc_escapes.test.dtb escapes.dts
+ run_test string_escapes dtc_escapes.test.dtb
}
while getopts "vdt:" ARG ; do
Index: dtc/tests/string_escapes.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/string_escapes.c 2007-10-16 16:34:20.000000000 +1000
@@ -0,0 +1,42 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for strinc escapes in dtc
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_getprop(fdt, 0, "escape-str",
+ strlen(TEST_STRING_2)+1, TEST_STRING_2);
+
+ PASS();
+}
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-10-16 16:31:44.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-10-16 16:32:41.000000000 +1000
@@ -7,7 +7,8 @@ LIB_TESTS_L = get_mem_rsv \
setprop_inplace nop_property nop_node \
sw_tree1 \
move_and_save \
- open_pack rw_tree1 setprop del_property del_node
+ open_pack rw_tree1 setprop del_property del_node \
+ string_escapes
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 6:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1192514455.19073.27.camel@pasglop>
On Oct 16, 2007, at 1:00 AM, Benjamin Herrenschmidt wrote:
>
>> You must have missed the thread where various people where
>> complaining
>> about how powerpc is the only architecture where they can't build
>> kernels without some external tool that they don't have, etc., etc.
>>
>> We thought about shipping compiled DTBs for various platforms, but
>> the
>> problem there is that they can't be updated with a patch, so whoever
>> commits a patch to the relevant .dts would have to remember to run
>> dtc
>> and commit the updated .dtb as well, which seems a bit error-prone.
>>
>> In the end, dtc isn't all that much code. We already have several
>> other programs that run on the host in the process of making a
>> zImage,
>> such as wrapper, hack-coff, and addnote, not to mention the various C
>> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>>
>> So I think there definitely is a precedent for including dtc.
>
> Note that I just tried to build a 4xx kernel today ... and failed
> due to
> the lack of mkimage ..
>
> Another one that we need to either add to the kernel or make the
> building of cuImage's optional.
I think if we add dtc we add mkimage since its even smaller.
- k
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 6:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1192514497.19073.29.camel@pasglop>
On Oct 16, 2007, at 1:01 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
>> Just out of interest who's complaining? We don't include mkimage
>> for
>> u-boot related builds and I haven't seen any gripes related to that.
>
> It's a pain in the neck since those are built even for things that
> don't
> need them (such as 4xx where I use the treeboot images).
That was Paul's decision :)
- k
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Stefan Roese @ 2007-10-16 6:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org>
On Tuesday 16 October 2007, Kumar Gala wrote:
> On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> > On Tuesday 16 October 2007, Kumar Gala wrote:
> >>>> I'm willing to look into doing the port over, but would need some
> >>>> help testing.
> >>>
> >>> Yes, it would be greatly appreciated if you could start this
> >>> TQM85xx port. I
> >>> will of course do the testing.
> >>
> >> Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
> >>
> >> 1. what processors does this actually support/run on. I'm guessing
> >> MPC8541, MPC8555? But not really sure
> >
> > IIRC there are 4 different versions of the board:
> > - 8540, 8541, 8555 & 8560
>
> do they all boot/run with the code that exists in arch/ppc ?
Yes. I have to admit though, that I'm not sure if the denx arch/ppc version
differs from the kernel.org version.
Best regards,
Stefan
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Wolfgang Denk @ 2007-10-16 6:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org>
Dear Kumar,
in message <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org> you wrote:
>
> >> 1. what processors does this actually support/run on. I'm guessing
> >> MPC8541, MPC8555? But not really sure
> >
> > IIRC there are 4 different versions of the board:
> > - 8540, 8541, 8555 & 8560
>
> do they all boot/run with the code that exists in arch/ppc ?
Yes, they do.
> thanks for the other info, that's exactly what I needed.
Just let us know what you need...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Technology is dominated by those who manage what they do not under-
stand.
^ permalink raw reply
* Re: Merge dtc
From: Benjamin Herrenschmidt @ 2007-10-16 6:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <5E3B6FCC-5930-4C76-AB4B-86B35551B9E0@kernel.crashing.org>
On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
> Just out of interest who's complaining? We don't include mkimage
> for
> u-boot related builds and I haven't seen any gripes related to that.
It's a pain in the neck since those are built even for things that don't
need them (such as 4xx where I use the treeboot images).
Ben.
^ permalink raw reply
* Re: Merge dtc
From: Benjamin Herrenschmidt @ 2007-10-16 6:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <18196.20112.728499.256646@cargo.ozlabs.ibm.com>
> You must have missed the thread where various people where complaining
> about how powerpc is the only architecture where they can't build
> kernels without some external tool that they don't have, etc., etc.
>
> We thought about shipping compiled DTBs for various platforms, but the
> problem there is that they can't be updated with a patch, so whoever
> commits a patch to the relevant .dts would have to remember to run dtc
> and commit the updated .dtb as well, which seems a bit error-prone.
>
> In the end, dtc isn't all that much code. We already have several
> other programs that run on the host in the process of making a zImage,
> such as wrapper, hack-coff, and addnote, not to mention the various C
> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>
> So I think there definitely is a precedent for including dtc.
Note that I just tried to build a 4xx kernel today ... and failed due to
the lack of mkimage ..
Another one that we need to either add to the kernel or make the
building of cuImage's optional.
Ben.
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Kumar Gala @ 2007-10-16 5:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <200710160728.38897.sr@denx.de>
On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> On Tuesday 16 October 2007, Kumar Gala wrote:
>>>> I'm willing to look into doing the port over, but would need some
>>>> help testing.
>>>
>>> Yes, it would be greatly appreciated if you could start this
>>> TQM85xx port. I
>>> will of course do the testing.
>>
>> Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
>>
>> 1. what processors does this actually support/run on. I'm guessing
>> MPC8541, MPC8555? But not really sure
>
> IIRC there are 4 different versions of the board:
> - 8540, 8541, 8555 & 8560
do they all boot/run with the code that exists in arch/ppc ?
thanks for the other info, that's exactly what I needed.
- k
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 5:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <18196.20112.728499.256646@cargo.ozlabs.ibm.com>
On Oct 16, 2007, at 12:39 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Dare I ask why we are including dtc in the kernel source tree? We
>> don't really have precedence for this and there are users outside of
>> linux for dtc.
>
> You must have missed the thread where various people where complaining
> about how powerpc is the only architecture where they can't build
> kernels without some external tool that they don't have, etc., etc.
I must have missed this thread.
> We thought about shipping compiled DTBs for various platforms, but the
> problem there is that they can't be updated with a patch, so whoever
> commits a patch to the relevant .dts would have to remember to run dtc
> and commit the updated .dtb as well, which seems a bit error-prone.
agreed, would seem .S would have been a better choice than .dtb, but
I agree the keeping a .dts and .S form insync would be a bit of a pain.
> In the end, dtc isn't all that much code. We already have several
> other programs that run on the host in the process of making a zImage,
> such as wrapper, hack-coff, and addnote, not to mention the various C
> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>
> So I think there definitely is a precedent for including dtc.
Just out of interest who's complaining? We don't include mkimage for
u-boot related builds and I haven't seen any gripes related to that.
- k
^ permalink raw reply
* [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 5:49 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
(Use correct address for Stephen this time)
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the "hot" loop that results of a pending signal
here will spin without even a cpu_relax ... what do you guys think would
be the best way to handle this ?
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-16 15:27:27.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-16 15:27:38.000000000 +1000
@@ -394,6 +394,21 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep_interruptible(1);
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* [PATCH] net: Fix new EMAC driver for NAPI changes
From: Benjamin Herrenschmidt @ 2007-10-16 5:40 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
net: Fix new EMAC driver for NAPI changes
This fixes the new EMAC driver for the NAPI updates. The previous patch
by Roland Dreier (already applied) to do that doesn't actually work. This
applies on top of it makes it work on my test Ebony machine.
This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
posted previously.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
The old EMAC driver does things a bit differently (doesn't do useful
locking :-) and seems to work with Roland patch. So I'm not going to
touch it unless somebody reports me that it has problems
Index: linux-work/drivers/net/ibm_newemac/mal.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2007-10-16 14:51:11.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c 2007-10-16 14:59:23.000000000 +1000
@@ -45,6 +45,8 @@ int __devinit mal_register_commac(struct
return -EBUSY;
}
+ if (list_empty(&mal->list))
+ napi_enable(&mal->napi);
mal->tx_chan_mask |= commac->tx_chan_mask;
mal->rx_chan_mask |= commac->rx_chan_mask;
list_add(&commac->list, &mal->list);
@@ -67,6 +69,8 @@ void __devexit mal_unregister_commac(str
mal->tx_chan_mask &= ~commac->tx_chan_mask;
mal->rx_chan_mask &= ~commac->rx_chan_mask;
list_del_init(&commac->list);
+ if (list_empty(&mal->list))
+ napi_disable(&mal->napi);
spin_unlock_irqrestore(&mal->lock, flags);
}
@@ -182,7 +186,7 @@ static inline void mal_enable_eob_irq(st
set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
}
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+/* synchronized by NAPI state */
static inline void mal_disable_eob_irq(struct mal_instance *mal)
{
// XXX might want to cache MAL_CFG as the DCR read can be slooooow
@@ -317,8 +321,8 @@ void mal_poll_disable(struct mal_instanc
while (test_and_set_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags))
msleep(1);
- /* Synchronize with the MAL NAPI poller. */
- napi_disable(&mal->napi);
+ /* Synchronize with the MAL NAPI poller */
+ __napi_synchronize(&mal->napi);
}
void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac)
@@ -326,7 +330,12 @@ void mal_poll_enable(struct mal_instance
smp_wmb();
clear_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags);
- // XXX might want to kick a poll now...
+ /* Feels better to trigger a poll here to catch up with events that
+ * may have happened on this channel while disabled. It will most
+ * probably be delayed until the next interrupt but that's mostly a
+ * non-issue in the context where this is called.
+ */
+ napi_schedule(&mal->napi);
}
static int mal_poll(struct napi_struct *napi, int budget)
@@ -336,8 +345,7 @@ static int mal_poll(struct napi_struct *
int received = 0;
unsigned long flags;
- MAL_DBG2(mal, "poll(%d) %d ->" NL, *budget,
- rx_work_limit);
+ MAL_DBG2(mal, "poll(%d)" NL, budget);
again:
/* Process TX skbs */
list_for_each(l, &mal->poll_list) {
@@ -528,11 +536,12 @@ static int __devinit mal_probe(struct of
}
INIT_LIST_HEAD(&mal->poll_list);
- mal->napi.weight = CONFIG_IBM_NEW_EMAC_POLL_WEIGHT;
- mal->napi.poll = mal_poll;
INIT_LIST_HEAD(&mal->list);
spin_lock_init(&mal->lock);
+ netif_napi_add(NULL, &mal->napi, mal_poll,
+ CONFIG_IBM_NEW_EMAC_POLL_WEIGHT);
+
/* Load power-on reset defaults */
mal_reset(mal);
^ 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