* Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: Paul Jackson @ 2007-09-28 9:49 UTC (permalink / raw)
To: travis; +Cc: linux-mm, ak, linux-kernel, linuxppc-dev, sparclinux, akpm,
clameter
In-Reply-To: <20070912015647.214306428@sgi.com>
Mike,
I think there is a bug either in this ia64 patch, or in the related
generic arch patch: Convert cpu_sibling_map to be a per cpu variable
(v3).
It dies early in boot on me, on the SGI internal 8 processor IA64
system that you and I know as 'margin'. The death is a hard hang, due
to a corrupt stack, due to a bogus cpu index.
I haven't tracked it down all the way, but have gotten this far. If I add
the following patch, I get a panic on the BUG_ON if I have these two patches
in 2.6.23-rc8-mm1, but it boots just fine if I don't have these two patches.
It seems that the "cpu_sibling_map[cpu]" cpumask_t is empty (all zero
bits) with your two patches applied, but has some non-zero bits
otherwise, which leads to 'group' being NR_CPUS instead of a useful CPU
number. Unfortunately, I have no idea why the "cpu_sibling_map[cpu]"
cpumask_t is empty -- good luck on that part.
The patch that catches this bug earlier is this:
--- 2.6.23-rc8-mm1.orig/kernel/sched.c 2007-09-28 01:42:20.144561024 -0700
+++ 2.6.23-rc8-mm1/kernel/sched.c 2007-09-28 02:27:14.239075497 -0700
@@ -5905,6 +5905,7 @@ static int cpu_to_phys_group(int cpu, co
#else
group = cpu;
#endif
+ BUG_ON(group == NR_CPUS);
if (sg)
*sg = &per_cpu(sched_group_phys, group);
return group;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Segher Boessenkool @ 2007-09-28 9:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault
> happens
> that leads to a register dump, the kernel currently prints XXXXXXXX
> because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC
> into a
> virtual address.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> OK, just CONFIG_BOOKE this time. :-P
You forgot to fix the commit message ;-P
Segher
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-28 9:29 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070928.170401.-1300520897.kouish@swc.toshiba.co.jp>
On Fri, 2007-09-28 at 17:04 +0900, Ishizaki Kou wrote:
> Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
> kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
> the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
> function breaks the SLB table since it is called before setting up
> PACA.
>
> Thank you for your hint.
Ah yes, there was a temporary breakage there that got fixed indeed,
I remember.
Cheers,
Ben.
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FC8EFE.2000108@mock.com>
Jeff Mock-2 wrote:
>
>
>
> Misbah khan wrote:
>>
>>
>> Scott Wood-2 wrote:
>>> Misbah khan wrote:
>>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>>> provided by the Linux kernel. I want to know that if anybody is used it
>>>> and have full faith in its operation then please let me know. Driver in
>>>> the while loop is calling these API's hence i want to make sure that
>>>> its
>>>> operation will remain stable.
>>> They're used all over the place. Is there anything about them that you
>>> find suspect?
>>>
>>> -Scott
>>>
>>> I have devloped a character driver for FPGA which is memory mapped and
>>> using these API's to test a bit , set a bit or to clear a bit in the
>>> memory for eg :-
>>>
>>> /* poll till data is transfered from sdram to dpram */
>>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>>> && (delay < MAX_DELAY_BUSY))
>>> {
>>> KDEBUG3(" In the Dfr delay loop \n");
>>> mdelay(DELAY);
>>> delay+=DELAY;
>>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>>
>>> if(delay==MAX_DELAY_BUSY)
>>> {
>>> KDEBUG1("Out of the the Dfr busy loop \n");
>>> return -1;
>>> }
>>>
>>> People working for FPGA are sure that they are not making the bit high
>>> where in my driver is returning -1 from the kernel space aborting it
>>> after
>>> running for few minutes or so . Please let me know that This function is
>>> stable and i should tell them that the driver is stable in its operation
>>> and they should check it from there side.
>>>
>
>
> I think a more more likely source of the problem is that the FPGA
> pointer is not cast volatile, or perhaps the FPGA is mapped cached and
> the hardware doesn't always get touched when you think it does. The bit
> manipulation macros are probably fine.
>
> jeff
>
> FPGA is Indeed mapped non cashed here is the part of the code
>
> /* Physical bus memory is mapped */
> mmap_reg_ptr=(UINT32 *)ioremap_nocache(PHY_MEM_ADDR,PHY_MEM_SIZE);
>
> And is it ok if I caste FPGA pointer volatile like this will reduce the
> probability of failure
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(volatile UINT32 *)(\
> (volatile UINT32 *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return CASHEL_FAILURE;
> }
> __________________
>
> is there anything else that we could do to rely fully in our code.
>
> Misbah
> _____________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12937117
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBF9B7.9010007@freescale.com>
On Thursday 27 September 2007 20:43, Scott Wood wrote:
> Jon Smirl wrote:
> > The call to msleep() is inside a block protected with
> >
> > :#define in_interrupt() (irq_count())
> >
> > if (!in_interrupt)
> >
> > The stack trace looks like it is in a timer interrupt so shouldn't
> > irq_count be non-zero?
> > Could there be some lack of coordination on irq_count and the timer
> > tick with the preempt patch applied? Or does irq_count() not count
> > soft irqs?
> >
> > (!in_interrupt) may be the wrong way to protect this code.
>
> I think in_atomic() is what you want.
I tried with in_atomic(). The BUG report is gone, but the problem still=20
exists.=20
While network stress testing:=20
[...]
NETDEV WATCHDOG: eth0: transmit timed out
net eth0: transmit timed out
net eth0: queues didn't drain
net eth0: tx: index: 35, outdex: 36
net eth0: rx: index: 24, outdex: 25
PHY: f0003000:00 - Link is Down
PHY: f0003000:00 - Link is Up - 100/Full
The link is up again, but any connection is dead (no answers to ping etc.).=
=20
But the serial console is still working. I'm not sure if the RT-Preempt pat=
ch=20
*causes* this behavior or only *discover* it. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <Pine.LNX.4.62.0709271344130.10467@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
On Thu, 2007-09-27 at 13:53 +0200, Geert Uytterhoeven wrote:
> On Thu, 27 Sep 2007, Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> > > Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> > > used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> > > (ps3fb):
> > > [1] ps3av: eliminate unneeded temporary variables
> > > [2] ps3av: eliminate PS3AV_DEBUG
> > > [3] ps3av: use PS3 video mode ids in autodetect code
> > > [4] ps3av: treat DVI-D like HDMI in autodetect
> > > [5] ps3av: add autodetection for VESA modes
> > > [6] ps3av: add quirk database for broken monitors
> > > [7] ps3av: remove unused ps3av_set_mode()
> > > [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> > >
> > > Please review, and queue for 2.6.24 if they're ok. Thanks!
> > >
> > > Question: As several DVI-D displays advertise they support 1080i modes while
> > > they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> > > modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> > > better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> Well, this code has been in Geoff's git tree for a while, and it's been several
> weeks ago I got complaints (which have been adressed by adding displays to the
> quirk database). The new kboot (from Distro Kit 1.4.1) also uses it.
Well yeah. Your instructions for diagnosing a quirk are to add #define
DEBUG to ps3av.c and then send the _output from the kernel log_ ... ?
Not to mention that for every quirk reported there's probably 50 users
who just figured Linux on PS3 was broken and gave up.
> The only 100% (sic) mode is 480p (actual usable resolution is 576x384), which
> is quite limited due to the very low resolution. This is what the current
> mainline kernel uses by default, causing complaints from people who don't like
> their shiny expensive full-HD displays being driven by 480p by default.
Sure that's annoying, but not quite as annoying as getting a completely
black screen that you can do nothing about - short of hacking the kernel
and building your own otheros.bld.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:40 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
Antonino A. Daplas
In-Reply-To: <46FBE6FD.3030605@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
> Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> >> Hi,
> >>
> >> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> >> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> >> (ps3fb):
> >> [1] ps3av: eliminate unneeded temporary variables
> >> [2] ps3av: eliminate PS3AV_DEBUG
> >> [3] ps3av: use PS3 video mode ids in autodetect code
> >> [4] ps3av: treat DVI-D like HDMI in autodetect
> >> [5] ps3av: add autodetection for VESA modes
> >> [6] ps3av: add quirk database for broken monitors
> >> [7] ps3av: remove unused ps3av_set_mode()
> >> [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> >>
> >> Please review, and queue for 2.6.24 if they're ok. Thanks!
> >>
> >> Question: As several DVI-D displays advertise they support 1080i modes while
> >> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> >> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> >> better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> It is not that bad. If a bootloader is configued to use autodetection
> so that it is shown at best video mode, then it should have advertised
> key sequences to default to known video modes, with at least a 480p 'safe'
> mode.
Oh OK, that is a good idea. What's the "safe mode" key sequence for the
otheros.bld you provide on kernel.org?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Ishizaki Kou @ 2007-09-28 8:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190932629.6158.37.camel@pasglop>
Ben-san,
> > It should have been set in setup_64.c, in setup_paca() (which is
called
> > twice) in that statement:
> >
> > local_paca = &paca[cpu];
> >
> > As local_paca is defined as being a variable held in register r13.
Maybe
> > something bad's happening with the compiler ?
> Can you check early_setup disassembly, see if r13 is assigned (it
should
> be in two spots) and if it's clobbered by the compiler somewhere ?
> Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
> makefile and let us know if it makes a difference... r13 is marked
> reserved by the ABI but segher seems to imply that gcc may decide to
ues
> it anyway (ouch !)
I reviewed early_setup() disassembly sets r13 correctly. Now I found
the kernel works well without our hack, so I think I can decline the
patch [1/7].
Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
function breaks the SLB table since it is called before setting up
PACA.
Thank you for your hint.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Ishizaki Kou @ 2007-09-28 6:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190881866.6158.13.camel@pasglop>
> On Thu, 2007-09-27 at 16:53 +0900, Ishizaki Kou wrote:
> > This is a patch kit to work with new Guest OS Interface
> > to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
> > automatically.
>
> You may also consider adding an API to Beat to invalidate ranges of
> addresses. We could us that through the batch invalidate mechanism to
> speed up significantly process tear down and forks typically.
Thank you for your suggestion, we'll consider it for next release of
Beat.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH] Make sure to of_node_get() the result of pci_device_to_OF_node()
From: Michael Ellerman @ 2007-09-28 6:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann
In-Reply-To: <8183225ab4b14684bb0939e0c5258caaf5b8102f.1190008974.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
On Mon, 2007-09-17 at 16:03 +1000, Michael Ellerman wrote:
> pci_device_to_OF_node() returns the device node attached to a PCI device,
> but doesn't actually grab a reference - we need to do it ourselves.
Hi Paul,
Can you stick this in your 24 tree for the moment, the warnings it fixes
are giving people the willys. I'll look at the proper fix of having
pci_device_to_OF_node() take the reference and fixing all the callers.
cheers
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
> index 57a6149..2b2dfcc 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
> const phandle *ph;
> struct axon_msic *msic = NULL;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return NULL;
> @@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
> int len;
> const u32 *prop;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return -ENODEV;
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* libfdt: Make unit address optional for finding nodes
From: David Gibson @ 2007-09-28 5:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the fdt_subnode_offset() and fdt_path_offset() functions
in libfdt require the exact name of the nodes in question be passed,
including unit address.
This is contrary to traditional OF-like finddevice() behaviour, which
allows the unit address to be omitted (which is useful when the device
name is unambiguous without the address).
This patch introduces similar behaviour to
fdt_subnode_offset_namelen(), and hence to fdt_subnode_offset() and
fdt_path_offset() which are implemented in terms of the former. The
unit address can be omitted from the given node name. If this is
ambiguous, the first such node in the flattened tree will be selected
(this behaviour is consistent with IEEE1275 which specifies only that
an arbitrary node matching the given information be selected).
This very small change is then followed by many more diffs which
change the test examples and testcases to exercise this behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Jon, I initially considered making this behaviour optional,
i.e. adding a flag to subnode_offset() determining if it needed exact
matches or name-without-address matches. I couldn't see that it was
actually any use, though.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-09-27 18:36:03.000000000 +1000
@@ -62,8 +62,8 @@
return err; \
}
-static int offset_streq(const void *fdt, int offset,
- const char *s, int len)
+static int nodename_eq(const void *fdt, int offset,
+ const char *s, int len)
{
const char *p = fdt_offset_ptr(fdt, offset, len+1);
@@ -74,10 +74,12 @@ static int offset_streq(const void *fdt,
if (memcmp(p, s, len) != 0)
return 0;
- if (p[len] != '\0')
+ if (p[len] == '\0')
+ return 1;
+ else if (!memchr(s, '@', len) && (p[len] == '@'))
+ return 1;
+ else
return 0;
-
- return 1;
}
char *fdt_string(const void *fdt, int stroffset)
@@ -110,7 +112,7 @@ int fdt_subnode_offset_namelen(const voi
level++;
if (level != 1)
continue;
- if (offset_streq(fdt, offset+FDT_TAGSIZE, name, namelen))
+ if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
/* Found it! */
return offset;
break;
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/trees.S 2007-09-27 17:58:54.000000000 +1000
@@ -78,7 +78,7 @@ test_tree1_struct:
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
PROP_STR(test_tree1, prop_str, TEST_STRING_1)
- BEGIN_NODE("subnode1")
+ BEGIN_NODE("subnode@1")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
BEGIN_NODE("subsubnode")
@@ -86,10 +86,10 @@ test_tree1_struct:
END_NODE
END_NODE
- BEGIN_NODE("subnode2")
+ BEGIN_NODE("subnode@2")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
- BEGIN_NODE("subsubnode")
+ BEGIN_NODE("subsubnode@0")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
END_NODE
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/subnode_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(struct fdt_header *fdt
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -59,13 +59,13 @@ int main(int argc, char *argv[])
{
void *fdt;
int subnode1_offset, subnode2_offset;
- int subsubnode1_offset, subsubnode2_offset;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
if (subnode1_offset == subnode2_offset)
FAIL("Different subnodes have same offset");
@@ -74,10 +74,15 @@ int main(int argc, char *argv[])
check_property_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
check_property_typed(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
check_property_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_typed(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
+
+ if (subsubnode2_offset != subsubnode2_offset2)
+ FAIL("Different offsets with and without unit address");
PASS();
}
Index: dtc/tests/path_offset.c
===================================================================
--- dtc.orig/tests/path_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/path_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(void *fdt, int parent,
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -61,8 +61,8 @@ int main(int argc, char *argv[])
int root_offset;
int subnode1_offset, subnode2_offset;
int subnode1_offset_p, subnode2_offset_p;
- int subsubnode1_offset, subsubnode2_offset;
- int subsubnode1_offset_p, subsubnode2_offset_p;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
+ int subsubnode1_offset_p, subsubnode2_offset_p, subsubnode2_offset2_p;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
@@ -74,11 +74,11 @@ int main(int argc, char *argv[])
else if (root_offset != 0)
FAIL("fdt_path_offset(\"/\") returns incorrect offset %d",
root_offset);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
- subnode1_offset_p = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset_p = fdt_path_offset(fdt, "/subnode2");
+ subnode1_offset_p = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset_p = fdt_path_offset(fdt, "/subnode@2");
if (subnode1_offset != subnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
@@ -89,10 +89,12 @@ int main(int argc, char *argv[])
subnode2_offset, subnode2_offset_p);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
- subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
+ subsubnode2_offset2_p = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode1_offset != subsubnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
Index: dtc/tests/tests.h
===================================================================
--- dtc.orig/tests/tests.h 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/tests.h 2007-09-27 17:58:54.000000000 +1000
@@ -126,6 +126,7 @@ const void *check_getprop(void *fdt, int
})
#define check_getprop_string(fdt, nodeoffset, name, s) \
check_getprop((fdt), (nodeoffset), (name), strlen(s)+1, (s))
+int nodename_eq(const char *s1, const char *s2);
//void *load_blob(const char *filename);
void *load_blob_arg(int argc, char *argv[]);
void save_blob(const char *filename, void *blob);
Index: dtc/tests/testutils.c
===================================================================
--- dtc.orig/tests/testutils.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/testutils.c 2007-09-27 17:58:54.000000000 +1000
@@ -125,6 +125,21 @@ const void *check_getprop(void *fdt, int
return propval;
}
+int nodename_eq(const char *s1, const char *s2)
+{
+ int len = strlen(s2);
+
+ len = strlen(s2);
+ if (strncmp(s1, s2, len) != 0)
+ return 0;
+ if (s1[len] == '\0')
+ return 1;
+ else if (!memchr(s2, '@', len) && (s1[len] == '@'))
+ return 1;
+ else
+ return 0;
+}
+
#define CHUNKSIZE 128
void *load_blob(const char *filename)
Index: dtc/tests/get_name.c
===================================================================
--- dtc.orig/tests/get_name.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_name.c 2007-09-27 17:58:54.000000000 +1000
@@ -74,10 +74,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_name(fdt, "/");
- check_name(fdt, "/subnode1");
- check_name(fdt, "/subnode2");
- check_name(fdt, "/subnode1/subsubnode");
- check_name(fdt, "/subnode2/subsubnode");
+ check_name(fdt, "/subnode@1");
+ check_name(fdt, "/subnode@2");
+ check_name(fdt, "/subnode@1/subsubnode");
+ check_name(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/get_path.c
===================================================================
--- dtc.orig/tests/get_path.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_path.c 2007-09-27 17:58:54.000000000 +1000
@@ -82,10 +82,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/supernode_atdepth_offset.c
===================================================================
--- dtc.orig/tests/supernode_atdepth_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/supernode_atdepth_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -135,10 +135,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/node_offset_by_prop_value.c
===================================================================
--- dtc.orig/tests/node_offset_by_prop_value.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/node_offset_by_prop_value.c 2007-09-27 17:58:54.000000000 +1000
@@ -83,10 +83,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
- subsubnode1_offset = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
+ subsubnode1_offset = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
if ((subnode1_offset < 0) || (subnode2_offset < 0)
|| (subsubnode1_offset < 0) || (subsubnode2_offset < 0))
Index: dtc/tests/nop_node.c
===================================================================
--- dtc.orig/tests/nop_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/nop_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -39,21 +39,21 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -61,21 +61,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -83,19 +83,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/notfound.c
===================================================================
--- dtc.orig/tests/notfound.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/notfound.c 2007-09-27 17:58:54.000000000 +1000
@@ -53,7 +53,7 @@ int main(int argc, char *argv[])
val = fdt_getprop(fdt, 0, "nonexistant-property", &lenerr);
check_error("fdt_getprop(\"nonexistant-property\"", lenerr);
- subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode1");
+ subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find subnode1: %s", fdt_strerror(subnode1_offset));
Index: dtc/tests/parent_offset.c
===================================================================
--- dtc.orig/tests/parent_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/parent_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -77,10 +77,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
err = fdt_parent_offset(fdt, 0);
if (err != -FDT_ERR_NOTFOUND)
FAIL("fdt_parent_offset(/) returns %d instead of "
Index: dtc/tests/del_node.c
===================================================================
--- dtc.orig/tests/del_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/del_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -42,21 +42,21 @@ int main(int argc, char *argv[])
oldsize = fdt_totalsize(fdt);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
- FAIL("Couldn't find \"/subnode1\": %s",
+ FAIL("Couldn't find \"/subnode@1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2\": %s",
+ FAIL("Couldn't find \"/subnode@2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -64,21 +64,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -86,19 +86,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/sw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -54,16 +54,16 @@ int main(int argc, char *argv[])
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_property_string(fdt, "prop-str", TEST_STRING_1));
- CHECK(fdt_begin_node(fdt, "subnode1"));
+ CHECK(fdt_begin_node(fdt, "subnode@1"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
- CHECK(fdt_begin_node(fdt, "subnode2"));
+ CHECK(fdt_begin_node(fdt, "subnode@2"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
- CHECK(fdt_begin_node(fdt, "subsubnode"));
+ CHECK(fdt_begin_node(fdt, "subsubnode@0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/rw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -72,14 +72,14 @@ int main(int argc, char *argv[])
CHECK(fdt_setprop_typed(fdt, 0, "prop-int", TEST_VALUE_1));
CHECK(fdt_setprop_string(fdt, 0, "prop-str", TEST_STRING_1));
- OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode1"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
- OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode2"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@2"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
- OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
Index: dtc/tests/test_tree1.dts
===================================================================
--- dtc.orig/tests/test_tree1.dts 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/test_tree1.dts 2007-09-27 17:58:54.000000000 +1000
@@ -2,7 +2,7 @@
prop-int = <deadbeef>;
prop-str = "hello world";
- subnode1 {
+ subnode@1 {
prop-int = <deadbeef>;
subsubnode {
@@ -10,10 +10,10 @@
};
};
- subnode2 {
+ subnode@2 {
prop-int = <abcd1234>;
- subsubnode {
+ subsubnode@0 {
prop-int = <abcd1234>;
};
};
--
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: libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 5:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070928151322.a9dee5d9.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, Sep 28, 2007 at 03:13:22PM +1000, Stephen Rothwell wrote:
> On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > 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.
>
> So why doesn't fdt.h include libfdt_env.h, then?
Because libfdt_env.h is specifically for libfdt, whereas fdt.h
contains passive structures only, related to the flat tree structure
but without reference to any particular code for handling it.
Basically, fdt.h includes no other headers as a compromise to make it
more easily usable in various contexts. In fact the only thing it
needs is the C99 fixed-width integer types, but I want it to be also
usable in contexts which don't have a <stdint.h> (e.g. the kernel
bootwrapper).
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Jeff Mock @ 2007-09-28 5:19 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12934517.post@talk.nabble.com>
Misbah khan wrote:
>
>
> Scott Wood-2 wrote:
>> Misbah khan wrote:
>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>> provided by the Linux kernel. I want to know that if anybody is used it
>>> and have full faith in its operation then please let me know. Driver in
>>> the while loop is calling these API's hence i want to make sure that its
>>> operation will remain stable.
>> They're used all over the place. Is there anything about them that you
>> find suspect?
>>
>> -Scott
>>
>> I have devloped a character driver for FPGA which is memory mapped and
>> using these API's to test a bit , set a bit or to clear a bit in the
>> memory for eg :-
>>
>> /* poll till data is transfered from sdram to dpram */
>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>> && (delay < MAX_DELAY_BUSY))
>> {
>> KDEBUG3(" In the Dfr delay loop \n");
>> mdelay(DELAY);
>> delay+=DELAY;
>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>
>> if(delay==MAX_DELAY_BUSY)
>> {
>> KDEBUG1("Out of the the Dfr busy loop \n");
>> return -1;
>> }
>>
>> People working for FPGA are sure that they are not making the bit high
>> where in my driver is returning -1 from the kernel space aborting it after
>> running for few minutes or so . Please let me know that This function is
>> stable and i should tell them that the driver is stable in its operation
>> and they should check it from there side.
>>
I think a more more likely source of the problem is that the FPGA
pointer is not cast volatile, or perhaps the FPGA is mapped cached and
the hardware doesn't always get touched when you think it does. The bit
manipulation macros are probably fine.
jeff
^ permalink raw reply
* Re: libfdt: libfdt_env.h must be included first
From: Stephen Rothwell @ 2007-09-28 5:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070928045206.GA25743@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
>
> 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.
So why doesn't fdt.h include libfdt_env.h, then?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* libfdt: Test rw functions on more trees
From: David Gibson @ 2007-09-28 4:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the testcases for read/write functions (setprop,
del_property and del_node) are only invoked on the single
asm-generated tree, not on any of the other tree images which should
be equivalent. The functions in question will (correctly) not work on
the "unfinished" tree output from sw_tree1, but should work on most of
the others.
This patch extends the run_tests script to invoke the r/w testcases on
more example trees. The testsuite still passes clean with this
addition.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-09-27 17:49:29.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-09-27 17:57:00.000000000 +1000
@@ -49,6 +49,15 @@ tree1_tests () {
run_test nop_node $TREE
}
+tree1_tests_rw () {
+ TREE=$1
+
+ # Read-write tests
+ run_test setprop $TREE
+ run_test del_property $TREE
+ run_test del_node $TREE
+}
+
libfdt_tests () {
# Make sure we don't have stale blobs lying around
rm -f *.test.dtb
@@ -76,11 +85,16 @@ libfdt_tests () {
tree1_tests opened.$tree
tree1_tests repacked.$tree
done
- run_test setprop test_tree1.dtb
- run_test del_property test_tree1.dtb
- run_test del_node test_tree1.dtb
+
+ for tree in test_tree1.dtb sw_tree1.test.dtb; do
+ tree1_tests_rw $tree
+ tree1_tests_rw moved.$tree
+ tree1_tests_rw shunted.$tree
+ tree1_tests_rw deshunted.$tree
+ done
run_test rw_tree1
tree1_tests rw_tree1.test.dtb
+ tree1_tests_rw rw_tree1.test.dtb
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
@@ -92,6 +106,7 @@ 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
}
while getopts "vdt:" ARG ; do
--
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
* libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 4:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
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>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-09-27 15:23:10.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-09-27 15:23:50.000000000 +1000
@@ -51,8 +51,8 @@
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include <fdt.h>
#include <libfdt_env.h>
+#include <fdt.h>
#define FDT_FIRST_SUPPORTED_VERSION 0x10
#define FDT_LAST_SUPPORTED_VERSION 0x11
--
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: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 4:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBD483.6090403@freescale.com>
Scott Wood-2 wrote:
>
> Misbah khan wrote:
>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>> provided by the Linux kernel. I want to know that if anybody is used it
>> and have full faith in its operation then please let me know. Driver in
>> the while loop is calling these API's hence i want to make sure that its
>> operation will remain stable.
>
> They're used all over the place. Is there anything about them that you
> find suspect?
>
> -Scott
>
> I have devloped a character driver for FPGA which is memory mapped and
> using these API's to test a bit , set a bit or to clear a bit in the
> memory for eg :-
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(UINT32 *)(\
> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return -1;
> }
>
> People working for FPGA are sure that they are not making the bit high
> where in my driver is returning -1 from the kernel space aborting it after
> running for few minutes or so . Please let me know that This function is
> stable and i should tell them that the driver is stable in its operation
> and they should check it from there side.
>
> Misbah
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12934517
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: David Gibson @ 2007-09-28 2:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <9c20d018e890250443516b886317ceb9@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote:
> >>> Hrm... we probably want an "i2c" device_type class, but I don't think
> >>> we've actually defined one, which is a problem
> >>
> >> By defining new device_type's, or new semantics for device_type,
> >> you open the door to (accidentally) becoming incompatible with
> >> "real" OF.
> >
> > Hrm... perhaps. But is it a realistic danger - I'll have to think
> > more about that.
>
> It is trivial to avoid these dangers completely by not overloading
> the meaning of "device_type".
Hrm. Perhaps.
> >>> I think we want to think a bit more carefully about how to do
> >>> bindings
> >>> for RTC devices. No "rtc" device_type is defined, but again we might
> >>> want to.
> >>
> >> Actually, "device_type" = "rtc" _is_ defined (in the "device support
> >> extensions" recommended practice), and there is no useful way a flat
> >> device tree can implement it (it merely defines get-time and set-time
> >> methods).
> >
> > Ah.. right. That changes things a bit, in that we might want to
> > include device_type purely for similarity with real OF tree.
>
> You should include the device_type only if you implement its binding,
> and a flat device tree does not, and cannot. (In almost all cases,
> a flat device tree cannot implement device_type's semantics -- this
> means that pretty much the only case where a flat tree should use
> device_type is to have it as a workaround for bad kernel requirements).
I really don't think there's an ambiguity here. A flat-tree can
clearly never implement runtime binding features. This is also true
for a flat tree derived from a real OF, and so full of device_type all
over the place.
> > Real OF has a device_type == "nvram" too, doesn't it?
>
> Yes, same "device support extensions" document.
Erm.. I've lost track amongst our various threads. Which same
document?
> > AFAICT the real
> > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM
> > chips) the RTC is labelled as "nvram" rather than "rtc".
>
> Sounds buggy.
Why?
[snip]
> > I did find one real OF binding for a different Dallas RTC (and NVRAM),
> > see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-
> > it.txt
> >
> > It's a little different from the example above.
>
> That is a binding for the nvram part only, not for the RTC.
Hrm. So how do you suggest we do bindings for combined devices?
--
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: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: David Gibson @ 2007-09-28 2:40 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <41180fced14196db80f261d2ac1909e0@bga.com>
On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>
> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
[snip]
> >> What's your souce for saying the were supposed to be backwards
> >> compatable? That dtc fills out the struct header so?
> >
> > Sitting next to BenH and knowing he always intended them to be so.
> >
> >> My source is my involvment when v2 was defined (they were discovered
> >> while writing my device tree generation code):
> >>
> >> The actual binary structure is compatable, just not the contents of
> >> the
> >> properties nor how any slave cpus wait (for some trees it doesn't
> >> matter).
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
> >> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
> >> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
> >
> > An old version of fs2dt is hardly definitive. It could just be Plain
> > Wrong, nothing to do with the dt version.
>
> Sorry, copy and paste error. I was tring to point out this changelog
> in 2.6.10:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
> a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
Hrm, I see, yes that seems conclusive enough. Yuck.
In which case, I think we should try to forget that v1 ever existed.
I don't think anyone ever generated v1 trees other than kernels which
also consumed them, and I doubt current kernels will correctly deal
with v1 trees in this form.
In any case, this is all rather beside the point. My basic point is
that this bootwrapper stuff should not attempt to be a general
backwards compatibility layer for every broken early dt format that
ever existed. In general we should try to make sure nothing ever uses
<v16 trees. We want, here, to do the minimum we can get away with to
support the specific v2 trees produced by kexec-tools, as an interim
measure while kexec-tools itself is fixed to produce v17 trees (say,
by replacing fs2dt with dtc plus a libfdt based post-processing
program).
--
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: [PATCH] add Altivec/VMX state to coredumps
From: Michael Ellerman @ 2007-09-27 23:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <1D8E59FD-E8B1-446C-ABEE-D41F5496B518@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:
> >>> You're probably right :)
> >>>
> >>> What cores have SPE at the moment? Also, perhaps more importantly,
> >>> are there any plans to have Altivec and SPE in the same core?
> >>
> >> The e500 cores's from Freescale.
> >>
> >> No, they are pretty much mutually exclusive.
> >>
> >>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
> >>> the GDB side of this.
> >>
> >> From comments it looks like the expectation is that the combination
> >> of note type and name which is expected to be unique.
> >>
> >> I'm wondering if we should handle this via
> >> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
> >> Does GDB care about the order it sees the various sections in?
> >
> > I don't think those callbacks will work in this case, they're only
> > called for the primary thread that's doing the coredump, not for each
> > thread. Perhaps there's a way to adapt it though.
> >
> > I think the easiest solution for now is just to make the note type a
> > #define and create a new value for Altivec.
>
> Oh, well. It shouldn't be too difficult to abstract vector handler
> similar to how we do GPRs today to the core dump code.
I'm not sure I follow, you mean elf_core_copy_regs() ?
If so, that's basically what we've done, the problem is that as with
elf_core_copy_regs(), although the content is abstracted and overridden
by arch code, the note type is not. But making the vector note type
configurable seems easy enough.
eg:
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..7c8a145 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, struct pt_regs *regs,
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREGS_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 23:34 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927221031.GY3899@parisc-linux.org>
On Thu, Sep 27, 2007 at 04:10:31PM -0600, Matthew Wilcox wrote:
> In the error handler, we wait_for_completion(io_reset_wait).
> In sym2_io_error_detected, we init_completion(io_reset_wait).
> Isn't it possible that we hit the error handler before we hit the
> io_error_detected path, and thus the completion wait is lost?
> Since the completion is already initialised in sym_attach(), I don't
> think we need to initialise it in sym2_io_error_detected().
> Makes sense to just delete it?
Good catch. But no ... and I had to study this a bit. Bear with me:
It is enough to call init_completion() once, and not once per use:
it initializes spinlocks, which shouldn't be intialized twice.
But, that completion might be used multiple times when there are
multiple errors, and so, before using it a second time, one must
set completion->done = 0. The INIT_COMPLETION() macro does this.
One must have completion->done = 0 before every use, as otherwise,
wait_for_completion() won't actually wait. And since complete_all()
sets x->done += UINT_MAX/2, I'm pretty sure x->done won't be zero
the next time we use it, unless we make it so.
So I need to find a place to safely call INIT_COMPLETION() again,
after the completion has been used. At the moment, I'm stumped
as to where to do this.
---- [think ... think ... think] ----
I think the race you describe above is harmless. The first time
that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
in it doesn't matter if we lose that, since the device is hosed
anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
miss those, since, by now, sym2_io_error_detected() will have run.
So, by my reading, I'd say that init_completion() in
sym2_io_error_detected() has to stay (although perhaps
it should be replaced by the INIT_COMPLETION() macro.)
Removing it will prevent correct operation on the second
and subsequent errors.
--Linas
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Paul Mackerras @ 2007-09-27 23:31 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927191233.201980@gmx.net>
Gerhard Pircher writes:
> I'm working on a 2.6.23 kernel for the AmigaOne. I implemented the device
> tree and the platform setup code, which all compiles fine. I built a
> cuImage target, loaded it on my target machine with TFTP and booted it.
> The kernel passes the platform setup code and then dies somewhere in the
> driver init code (AFAICT), but before the keyboard driver is initialized
> (thus magic sysrq key doesn't work). Can somebody help me to track down
> this problem?
You appear to have a working 16550-style serial port which the udbg
infrastructure sees. Thus you should be able to use xmon, talking to
it via the serial port. Put "xmon" on the kernel command line and the
kernel will drop into xmon early in the boot process (in setup_arch).
Then, either the kernel will oops at some point and drop into xmon,
and you can then inspect memory and registers and get a stack trace,
or it will hang at some point. If it hangs, you can work out where it
hangs by putting in breakpoints at various points and seeing which
breakpoints you get to (this might take several boots).
Paul.
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Scott Wood @ 2007-09-27 23:01 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190933846.6601.1.camel@concordia>
Michael Ellerman wrote:
> On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
>> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
>> that leads to a register dump, the kernel currently prints XXXXXXXX because
>> it doesn't realize that PC is a physical address.
>>
>> This patch checks the state of the IMMU, and if necessary converts PC into a
>> virtual address.
>
> IMMU ?
Instruction Memory Management Unit.
-Scott
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Michael Ellerman @ 2007-09-27 22:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
> that leads to a register dump, the kernel currently prints XXXXXXXX because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC into a
> virtual address.
IMMU ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Detlev Zundel @ 2007-09-27 15:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <12900017.post@talk.nabble.com>
Hi Nethra,
> The other options I am wondering about,
> -c, --cleanmarker=SIZE Size of cleanmarker (default 12)
> -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
> cleanmaker size will it help the cause?
Skimming through the thread I cannot tell whether you use NAND or NOR,
but on NAND flash, the cleanmarkers are actually in the out-of-band
area and thus *should not* be in the image, so for NAND we need the -n
option.
I don't think you should have to adjust the size, at least I never
needed this.
Best wishes
Detlev
--
I've been examining the existing [linux] kernel configuration system, and I
have about concluded that the best favor we could do everybody involved with
it is to take it out behind the barn and shoot it through the head.
-- Eric S. Raymond on linux-kbuild Mar 2000
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ 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