* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: David Gibson @ 2008-01-14 0:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200705.GA696@loki.buserror.net>
On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> + aliases {
> + console = &console;
> + enet0 = ð0;
> + enet1 = ð1;
I think most other boards are settling on aliases "ethernet0"
etc. instead of "enet0" (though there's no reason you couldn't have
both.
--
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: I2C and CAN bus on MPC5200B device tree
From: Grant Likely @ 2008-01-14 0:35 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <478A967E.7080201@genesi-usa.com>
On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
>
> Hi guys,
>
> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> for it) and have not found any CAN bus documentation for device trees.
>
> I want to update the firmware tree to add these but, am basically looking
> for those docs, or someone to go over a few points.. is there some kind of
> tree standard I should be looking at, or some patch I missed which has
> a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut (v2)
From: David Gibson @ 2008-01-14 4:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080111172957.c0431145.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
On Fri, Jan 11, 2008 at 05:29:57PM +1100, Stephen Rothwell wrote:
> On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson <dwg@au1.ibm.com> wrote:
> >
> > +++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.000000000 +1100
>
> > +static __initdata struct {
> > + const char *compatible;
>
> If you make this an array, then the string will become __initdata as well.
Well, yes, but then I'd have to pick a specific size for the string.
Since this is supposed to be a stopgap until I can build a more
general constructor mechanism..
> > + char *plat_name;
> > +} of_rtc_table[] = {
> > + { "ds1743-nvram", "rtc-ds1742" },
> > +};
>
> > + platform_device_register_simple(plat_name, -1, res, 1);
>
> Do we care if this fails?
Well.. sort of, but there's not really any sane way of reporting it.
This will be called from early platform init code, failures shouldn't
cause us not to boot, and failure to register one rtc shouldn't cause
us not to attempt to register others if they're present.
--
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: I2C and CAN bus on MPC5200B device tree
From: Olof Johansson @ 2008-01-14 4:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <fa686aa40801131635o499c8c08i6a2667cd7df1a72e@mail.gmail.com>
On Sun, Jan 13, 2008 at 05:35:09PM -0700, Grant Likely wrote:
> On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >
> > Hi guys,
> >
> > I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> > for it) and have not found any CAN bus documentation for device trees.
> >
> > I want to update the firmware tree to add these but, am basically looking
> > for those docs, or someone to go over a few points.. is there some kind of
> > tree standard I should be looking at, or some patch I missed which has
> > a driver which implements something that looks at a compatible tree?
>
> I think some consensus has been achieved for describing i2c busses and
> their attached devices, but I don't think booting-without-of.txt has
> been updated with the details yet. I need to look into that more.
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
-Olof
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-14 4:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
>
>> +#ifdef CONFIG_TACO
>> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
>> + * the taco!
>> + */
>>
>
> We definitely don't want to see such board specific stuff in the common
> NDFC driver. And I really doubt that you need this change for your board.
> We are using this ndfc driver on multiple boards, and all have no
> problems accessing the controller with 32bit read/writes. So you most
> likely have a problem with your board port. Perhaps something with
> with the EBC setup. Please re-check and compare with boards that are know
> to work, like Sequoia.
>
How about adding a config option that lets you specify 8 bit access?
Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
put a little blurb that says something like:
On some platforms the 32bit read/writes cause a machine access
exception. If you get a machine access exception while reading the NAND
bad block table, try turning on 8 bit access.
Cheers,
Sean
^ permalink raw reply
* Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-14 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having trouble with getting Linux to boot farther than early_init.
Things start to go obviously wrong after early_init calls memset to
clear the .bss section. The first symptom I noticed was that the
stack (which currently contains the link register) was getting zeroed
by memset. This doesn't make any sense because the stack does not
intersect the .bss section; I confirmed that the do not intersect by
using JTAG+xmd to read the registers and also by inserting print
statements.
So, I experimented further and discovered that different memory
regions seem to be aliased on to each other every 2*32*256 bytes.
e.g.:
char * ptr = 0;
unsigned long addr = 0xc0001234; // pick some address
int n = 1; // pick some integer
// Now write values to two different addresses:
ptr[addr] = 42;
ptr[addr + n*2*32*256] = 24;
volatile asm ("nop");
// Now mysteriously, ptr[addr] == 24
The reason I have written 32*256 is because that corresponds to the
number of bytes per cache line times the number of cache lines ...
because I was suspicious this might be related to caching. However,
with experimentation, I found that the aliasing does not occur every
32*256 bytes, but rather every 32*512 bytes (hence 2*32*256).
Anyways, I looked in embed_config (and confirmed by dumping zImage.elf
with objdump) that the cache is being invalidated with "dccci".
"dccci" is being called, as expected, and therefore everything looks
good in the code.
I am completely perplexed. The cache appears to be initialized
properly. I don't have any trouble in real mode. But as soon the
kernel switches into virtual mode (in head_4xx.S), then this memory
aliasing problem happens. I wrote a completely standalone assembler
script that initializes the cache, TLBs, and virtual mode in the same
way as embed_config and head_4xx.S and so I am able to reproduce the
problem outside of the kernel. I can attach that code if someone
thinks it will be useful - just let me know.
Does anyone have an idea about what might be going wrong? I can send
more information or test anything that you want me to.
-David
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Olof Johansson @ 2008-01-14 5:24 UTC (permalink / raw)
To: Linas Vepstas; +Cc: lkessler, linuxppc-dev, Nathan Lynch, mahuja, strosake
In-Reply-To: <3ae3aa420801110857l5e43fd56s5bd1c24ffac939f3@mail.gmail.com>
On Fri, Jan 11, 2008 at 10:57:51AM -0600, Linas Vepstas wrote:
> On 10/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> > Mike Strosaker wrote:
> > >
> > > At the risk of repeating what others have already said, the PHYP-assistance
> > > method provides some advantages that the kexec method cannot:
> > > - Availability of the system for production use before the dump data is
> > > collected. As was mentioned before, some production systems may choose not
> > > to operate with the limited memory initially available after the reboot,
> > > but it sure is nice to provide the option.
> >
> > I'm more concerned that this design encourages the user to resume a
> > workload *which is almost certainly known to result in a system crash*
> > before collection of crash data is complete. Maybe the gamble will
> > pay off most of the time, but I wouldn't want to be working support
> > when it doesn't.
>
> Workloads that cause crashes within hours of startup tend to be
> weeded-out/discovered during pre-production test of the system
> to be deployed. Since its pre-production test, dumps can be
> taken in a leisurely manner. Heck, even a session at the
> xmon prompt can be contemplated.
>
> The problem is when the crash only reproduces after days or
> weeks of uptime, on a production machine. Since the machine
> is in production, its got to be brought back up ASAP. Since
> its crashing only after days/weeks, the dump should have
> plenty of time to complete. (And if it crashes quickly after
> that reboot ... well, support people always welcome ways
> in which a bug can be reproduced more quickly/easily).
How do you expect to have it in full production if you don't have all
resources available for it? It's not until the dump has finished that you
can return all memory to the production environment and use it.
This can very easily be argued in both direction, with no clear winner:
If the crash is stress-induced (say a slashdotted website), for those
cases it seems more rational to take the time, collect _good data_ even
if it takes a little longer, and then go back into production. Especially
if the alternative is to go back into production immediately, collect
about half of the data, and then crash again. Rinse and repeat.
Anyway -- I can agree that some of the arguments w.r.t robustness and
reliability of collecting dumps can be higher using this approach. It
really surprises me that there's no way to reset a device through PHYP
though. Seems like such a fundamental feature.
I think people are overly optimistic if they think it'll be possible
to do all of this reliably (as in with consistent performance) without
a second reboot though. At least without similar amounts of work being
done as it would have taken to fix kdump's reliability in the first place.
Speaking of reboots. PHYP isn't known for being quick at rebooting a
partition, it used to take in the order of minutes even on a small
machine. Has that been fixed? If not, the avoiding an extra reboot
argument hardly seems like a benefit versus kdump+kexec, which reboots
nearly instantly and without involvement from PHYP.
-Olof
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Stephen Rothwell @ 2008-01-14 5:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200742.GB696@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:07:42 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/82xx/ep8248e.c
> +static struct mdiobb_ops ep8248e_mdio_ops = {
const, please.
> +static struct of_platform_driver ep8248e_mdio_driver = {
.driver = {
> + .name = "ep8248e-mdio-bitbang",
},
> +static const struct cpm_pin ep8248_pins[] = {
Could be __initdata
> +static void __init ep8248_setup_arch(void)
> +{
> + ep8248e_bcsr_node =
> + of_find_compatible_node(NULL, NULL, "fsl,ep8248e-bcsr");
> + if (!ep8248e_bcsr_node) {
> + printk(KERN_ERR "No bcsr in device tree\n");
> + return;
> + }
> +
> + ep8248e_bcsr = of_iomap(ep8248e_bcsr_node, 0);
> + if (!ep8248e_bcsr) {
> + printk(KERN_ERR "Cannot map BCSR registers\n");
of_node_put(ep8248e_bcsr_node);
ep8248e_bcsr_node = NULL;
> + return;
> +static int __init declare_of_platform_devices(void)
> +{
> + if (!machine_is(ep8248))
> + return 0;
> +
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> + of_register_platform_driver(&ep8248e_mdio_driver);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
machine_device_initcall(ep8248, declare_of_platform_devices);
Then remove the machine_is test above.
--
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
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-14 6:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204316.GB11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:16 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/drivers/mtd/ofpart.c
> +int __devinit of_mtd_parse_partitions(struct device *dev,
> + nr_parts = 0;
> + for (pp = node->child; pp; pp = pp->sibling)
for_each_child_of_node(node, pp)
> + nr_parts++;
> + for (pp = of_get_next_child(node, NULL), i = 0; pp;
> + pp = of_get_next_child(node, pp), i++) {
i = 0;
for_each_child_of_node(node, pp) {
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
Spaces around '*'.
> + of_node_put(pp);
> + dev_err(dev, "Invalid 'reg' on %s\n", node->full_name);
> + kfree(*pparts);
> + *pparts = NULL;
> + return -EINVAL;
> + }
> + (*pparts)[i].offset = reg[0];
> + (*pparts)[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + (*pparts)[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + (*pparts)[i].mask_flags = MTD_WRITEABLE;
i++;
> + }
--
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
* Re: [PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
From: Stephen Rothwell @ 2008-01-14 6:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204320.GC11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:20 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + child = NULL;
> + while ((child = of_get_next_child(ofdev->node, child)))
for_each_child_of_node(of_dev->node, child)
> + if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
> + fsl_elbc_chip_probe(ctrl, child);
> +static struct of_device_id fsl_elbc_match[] = {
const, please.
> +static struct of_platform_driver fsl_elbc_ctrl_driver = {
.driver = {
> + .name = "fsl-elbc",
},
> + .match_table = fsl_elbc_match,
> + .probe = fsl_elbc_ctrl_probe,
> + .remove = __devexit_p(fsl_elbc_ctrl_remove),
> +};
--
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
* Re: [PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
From: Stephen Rothwell @ 2008-01-14 6:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi Scott,
[Corrected list address.]
On Fri, 11 Jan 2008 14:43:20 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + child = NULL;
> + while ((child = of_get_next_child(ofdev->node, child)))
for_each_child_of_node(of_dev->node, child)
> + if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
> + fsl_elbc_chip_probe(ctrl, child);
> +static struct of_device_id fsl_elbc_match[] = {
const, please.
> +static struct of_platform_driver fsl_elbc_ctrl_driver = {
.driver = {
> + .name = "fsl-elbc",
},
> + .match_table = fsl_elbc_match,
> + .probe = fsl_elbc_ctrl_probe,
> + .remove = __devexit_p(fsl_elbc_ctrl_remove),
> +};
--
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
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-14 6:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Hi Scott,
[Corrected list address.]
On Fri, 11 Jan 2008 14:43:16 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/drivers/mtd/ofpart.c
> +int __devinit of_mtd_parse_partitions(struct device *dev,
> + nr_parts = 0;
> + for (pp = node->child; pp; pp = pp->sibling)
for_each_child_of_node(node, pp)
> + nr_parts++;
> + for (pp = of_get_next_child(node, NULL), i = 0; pp;
> + pp = of_get_next_child(node, pp), i++) {
i = 0;
for_each_child_of_node(node, pp) {
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
Spaces around '*'.
> + of_node_put(pp);
> + dev_err(dev, "Invalid 'reg' on %s\n", node->full_name);
> + kfree(*pparts);
> + *pparts = NULL;
> + return -EINVAL;
> + }
> + (*pparts)[i].offset = reg[0];
> + (*pparts)[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + (*pparts)[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + (*pparts)[i].mask_flags = MTD_WRITEABLE;
i++;
> + }
--
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
* [PATCH] [POWERPC] make ibmebus use of_(un)register_driver
From: Stephen Rothwell @ 2008-01-14 6:46 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Heiko J Schick, Joachim Fenkes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/ibmebus.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 1844359..2a6a388 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -197,16 +197,13 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv->match_table);
- drv->driver.name = drv->name;
- drv->driver.bus = &ibmebus_bus_type;
-
- return driver_register(&drv->driver);
+ return of_register_driver(drv, &ibmebus_bus_type);
}
EXPORT_SYMBOL(ibmebus_register_driver);
void ibmebus_unregister_driver(struct of_platform_driver *drv)
{
- driver_unregister(&drv->driver);
+ of_unregister_driver(drv);
}
EXPORT_SYMBOL(ibmebus_unregister_driver);
--
1.5.3.8
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: I2C and CAN bus on MPC5200B device tree
From: Wolfgang Grandegger @ 2008-01-14 8:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <fa686aa40801131635o499c8c08i6a2667cd7df1a72e@mail.gmail.com>
Grant Likely wrote:
> On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Hi guys,
>>
>> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
>> for it) and have not found any CAN bus documentation for device trees.
>>
>> I want to update the firmware tree to add these but, am basically looking
>> for those docs, or someone to go over a few points.. is there some kind of
>> tree standard I should be looking at, or some patch I missed which has
>> a driver which implements something that looks at a compatible tree?
>
> I think some consensus has been achieved for describing i2c busses and
> their attached devices, but I don't think booting-without-of.txt has
> been updated with the details yet. I need to look into that more.
>
> I don't think anyone has tackled CAN. Best bet is to draft a tree in
> the way you think it should be described and post it to the list.
> That will give a starting point for us to discuss it and come to
> consensus.
For MSCAN on the MPC5200 we currently have:
mscan@900 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <900 80>;
};
mscan@980 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <980 80>;
};
The only thing missing is a property defining the routing of the CAN
signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
make sense to describe CAN devices on the CAN bus like for I2C.
Wolfgang.
^ permalink raw reply
* Re: Problem booting Linux 2.6 on Virtex-4
From: Enno Lübbers @ 2008-01-14 8:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <440abda90801132112y76f2899by4ef582c9b58fd6b6@mail.gmail.com>
Hello David,
Am 14.01.2008 um 06:12 schrieb David Baird:
> I'm having trouble with getting Linux to boot farther than early_init.
> [...]
> So, I experimented further and discovered that different memory
> regions seem to be aliased on to each other every 2*32*256 bytes.
This sounds either like a wrong programming of an BRx/ORx memory
controller register pair (which, AFAIK, the PPC405 does not have), or
like a messed up address map in EDK. My guess is that an optimized/
sloppy implementation of the address decoder for some peripheral in an
EDK system could produce something like you described; or there's a
block RAM that's attached to a controller in the wrong way; or the
bank/address parameters of the DDR controller don't match the physical
setup... there's a lot that can go wrong obviously on a configurable
SoC.
Can you be more specific about your hardware platform? Is this a
reference design? What board are you using?
Regards
- Enno
--
Dipl.-Ing. Enno Luebbers
Computer Engineering Group
University of Paderborn
Warburger Str. 100
33098 Paderborn
http://wwwcs.upb.de/cs/ag-platzner
phone: 05251 / 60-5397
fax: 05251 / 60-5377
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Josh Boyer @ 2008-01-14 8:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478AEB39.70106@pikatech.com>
On Sun, 13 Jan 2008 23:55:21 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Stefan Roese wrote:
> >
> >> +#ifdef CONFIG_TACO
> >> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
> >> + * the taco!
> >> + */
> >>
> >
> > We definitely don't want to see such board specific stuff in the common
> > NDFC driver. And I really doubt that you need this change for your board.
> > We are using this ndfc driver on multiple boards, and all have no
> > problems accessing the controller with 32bit read/writes. So you most
> > likely have a problem with your board port. Perhaps something with
> > with the EBC setup. Please re-check and compare with boards that are know
> > to work, like Sequoia.
> >
> How about adding a config option that lets you specify 8 bit access?
> Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
> put a little blurb that says something like:
>
> On some platforms the 32bit read/writes cause a machine access
> exception. If you get a machine access exception while reading the NAND
> bad block table, try turning on 8 bit access.
But did you go back and verify the EBC settings were correct on your
board? This shouldn't be needed at all if the EBC bank settings and
timings are correct.
josh
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Geert Uytterhoeven @ 2008-01-14 10:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801131004i669276e2pde04b195dd10bd90@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2464 bytes --]
On Sun, 13 Jan 2008, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > > Teach module-init-tools about the i2c subsystem.
> > > > > >
> > > > > > Can you please explain what this patch does and why it is needed?
> > > > >
> > > > > It generates the entries needed for the user space module tools to
> > > > > work with the aliases. For example modprobe/depmod. It is a standard
> > > > > part of the kernel module system.
> > > >
> > > > What entries, where? What can you do after applying your patch that you
> > > > couldn't do before?
> > >
> > > The drivers you are testing with don't depend on other drivers.
> >
> > They do. I'm testing with the lm90 driver, which depends on the hwmon
> > driver. Both load automatically when the underlying i2c-parport driver
> > instantiate an "adm1032" i2c device.
>
> I don't know exactly what those modules tables are used for. I just
> copied what the other subsystems do. Maybe they are used when you make
> an initrd to know which drivers to copy into the image.
Module-init-tools needs those table to create module aliases in the *.ko
files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
on the device IDs when the devices appear in sysfs.
That's the generic part. How this applies to i2c devices on platforms
without Open Firmware device trees is another question. I guess that's
where Jean gets confused (i2c_device_id got _removed_ last year,
because it didn't make sense (at the time?)).
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] [POWERPC] make ibmebus use of_(un)register_driver
From: Joachim Fenkes @ 2008-01-14 12:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Heiko J Schick, ppc-dev, Christoph Raisch, paulus, Stefan Roscher
In-Reply-To: <20080114174648.bca30b55.sfr@canb.auug.org.au>
On Monday 14 January 2008 07:46, Stephen Rothwell wrote:
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index 1844359..2a6a388 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -197,16 +197,13 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
> /* If the driver uses devices that ibmebus doesn't know, add them */
> ibmebus_create_devices(drv->match_table);
>
> - drv->driver.name = drv->name;
> - drv->driver.bus = &ibmebus_bus_type;
> -
> - return driver_register(&drv->driver);
> + return of_register_driver(drv, &ibmebus_bus_type);
> }
> EXPORT_SYMBOL(ibmebus_register_driver);
>
> void ibmebus_unregister_driver(struct of_platform_driver *drv)
> {
> - driver_unregister(&drv->driver);
> + of_unregister_driver(drv);
> }
> EXPORT_SYMBOL(ibmebus_unregister_driver);
Looks like a transparent change to me. Good one.
Joachim
Acked-by: Joachim Fenkes <fenkes@de.ibm.com>
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-14 14:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0801141154420.3058@vixen.sonytel.be>
On 1/14/08, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Sun, 13 Jan 2008, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > > > Teach module-init-tools about the i2c subsystem.
> > > > > > >
> > > > > > > Can you please explain what this patch does and why it is nee=
ded?
> > > > > >
> > > > > > It generates the entries needed for the user space module tools=
to
> > > > > > work with the aliases. For example modprobe/depmod. It is a sta=
ndard
> > > > > > part of the kernel module system.
> > > > >
> > > > > What entries, where? What can you do after applying your patch th=
at you
> > > > > couldn't do before?
> > > >
> > > > The drivers you are testing with don't depend on other drivers.
> > >
> > > They do. I'm testing with the lm90 driver, which depends on the hwmon
> > > driver. Both load automatically when the underlying i2c-parport drive=
r
> > > instantiate an "adm1032" i2c device.
> >
> > I don't know exactly what those modules tables are used for. I just
> > copied what the other subsystems do. Maybe they are used when you make
> > an initrd to know which drivers to copy into the image.
>
> Module-init-tools needs those table to create module aliases in the *.ko
> files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> on the device IDs when the devices appear in sysfs.
>
> That's the generic part. How this applies to i2c devices on platforms
> without Open Firmware device trees is another question. I guess that's
> where Jean gets confused (i2c_device_id got _removed_ last year,
> because it didn't make sense (at the time?)).
Last year i2c modules weren't dynamically loadable so it wasn't needed.
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
> Sony Network and Software Technology Center Europe
> The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgi=
um
>
> 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 =B7 B-1840 Londerzeel =B7 Belgium
> VAT BE 0413.825.160 =B7 RPR Brussels
> Fortis Bank Zaventem =B7 Swift GEBABEBB08A =B7 IBAN BE39001382358619
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Grant Likely @ 2008-01-14 14:28 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <478B18D9.6020201@grandegger.com>
On 1/14/08, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Grant Likely wrote:
> > On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Hi guys,
> >>
> >> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> >> for it) and have not found any CAN bus documentation for device trees.
> >>
> >> I want to update the firmware tree to add these but, am basically looking
> >> for those docs, or someone to go over a few points.. is there some kind of
> >> tree standard I should be looking at, or some patch I missed which has
> >> a driver which implements something that looks at a compatible tree?
> >
> > I think some consensus has been achieved for describing i2c busses and
> > their attached devices, but I don't think booting-without-of.txt has
> > been updated with the details yet. I need to look into that more.
> >
> > I don't think anyone has tackled CAN. Best bet is to draft a tree in
> > the way you think it should be described and post it to the list.
> > That will give a starting point for us to discuss it and come to
> > consensus.
>
> For MSCAN on the MPC5200 we currently have:
>
> mscan@900 {
> device_type = "mscan";
> compatible = "mpc5200b-mscan","mpc5200-mscan";
> cell-index = <0>;
> interrupts = <2 11 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <900 80>;
> };
>
> mscan@980 {
> device_type = "mscan";
> compatible = "mpc5200b-mscan","mpc5200-mscan";
> cell-index = <1>;
> interrupts = <2 12 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <980 80>;
> };
>
> The only thing missing is a property defining the routing of the CAN
> signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
> make sense to describe CAN devices on the CAN bus like for I2C.
I don't think that pin routing matters much for the device tree.
Ideally, firmware should be responsible for port_config, and as long
as it is already configured, the CAN device can find it's devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-14 15:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: lkessler, linuxppc-dev, Nathan Lynch, mahuja, strosake
In-Reply-To: <20080114052402.GA23786@lixom.net>
On 13/01/2008, Olof Johansson <olof@lixom.net> wrote:
>
> How do you expect to have it in full production if you don't have all
> resources available for it? It's not until the dump has finished that you
> can return all memory to the production environment and use it.
With the PHYP dump, each chunk of RAM is returned for
general use immediately after being dumped; so its not
an all-or-nothing proposition. Production systems don't
often hit 100% RAM use right out of the gate, they often
take hours or days to get there, so again, there should
be time to dump.
> This can very easily be argued in both direction, with no clear winner:
> If the crash is stress-induced (say a slashdotted website), for those
> cases it seems more rational to take the time, collect _good data_ even
> if it takes a little longer, and then go back into production. Especially
> if the alternative is to go back into production immediately, collect
> about half of the data, and then crash again. Rinse and repeat.
Again, the mode of operation for the phyp dump is that you'll
always have all of the data from the *first* crash, even if there
are multiple crashes. That's because the the as-yet undumped
RAM is not put back into production.
> really surprises me that there's no way to reset a device through PHYP
> though. Seems like such a fundamental feature.
I don't know who said that; that's not right. The EEH function
certainly does allow you to halt/restart PCI traffic to a particular
device and also to reset the device. So, yes, the pSeries
kexec code should call into the eeh subsystem to rationalize
the device state.
> I think people are overly optimistic if they think it'll be possible
> to do all of this reliably (as in with consistent performance) without
> a second reboot though.
The NUMA issues do concern me. But then, the whole virtualized,
fractional-cpu, tickless operation stuff sounds like a performance
tuning nightmare to begin with.
> At least without similar amounts of work being
> done as it would have taken to fix kdump's reliability in the first place.
:-)
> Speaking of reboots. PHYP isn't known for being quick at rebooting a
> partition, it used to take in the order of minutes even on a small
> machine. Has that been fixed?
Dunno. Probably not.
> If not, the avoiding an extra reboot
> argument hardly seems like a benefit versus kdump+kexec, which reboots
> nearly instantly and without involvement from PHYP.
OK, let me tell you what I'm up against right now.
I'm dealing with sporadic corruption on my home box.
About a month ago, I bought a whizzy ASUS M2NE
motherboard & an AMD64 2-core cpu, and two sticks
of RAM, 1GB per stick. I have one new hard drive,
SATA, and one old hard drive, from my old machine,
the PATA. The two disks are mirrored in a RAID-1
config. Running Ubuntu.
During install/upgrade a month ago, I noticed some of
the install files seemed to have gotten corrupted, but
that downloading them again got me a working version.
This put a serious frown on my face: maybe a bad ethernet
card or connection !?
Two weeks ago, gcc stopped working one morning, although
it worked fine the night before. I'd done nothing in the interim
but sleep. Reinstalling it made it work again. Yesterday,
something else stopped working. I found the offending
library, I compared file checksums against a known-good
version, and they were off. (!!!) Disk corruption?
Then apt-get stopped working. The /var/lib/dpkg/status file
had randomly corrupted single bytes. Its ascii, I hand
repaired it; it had maybe 10 bad bytes out of 2MB total size.
I installed tripwire. Between the first run of tripwire, and the
second, less than an hour later, it reported several dozen
files have changed checksums. Manual inspection of some
of these files against known-good versions show that, at least
this morning, that's no longer the case.
System hasn't crashed in a month, since first boot. So
what's going on? Is it possible that one of the two disks
is serving up bad data, which explains the funny checksum
behaviour? Or maybe its bad RAM, so that a fresh disk
read shows good data? If its bad ram, why doesn't the
system crash? I forced fsck last night, fsck came back
spotless.
So ... moral of the story: If phyp is doing some sort of
hardware checks and validation, that's great. I wish I could
afford a pSeries system for my home computer, because
my impression is that they are very stable, and don't do
things like data corruption. I'm such a friggin cheapskate
that I can't bear to spend many thousands instead of many
hundreds of dollars. However, I will trade a longer boot
for the dream of higher reliability.
--linas
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Scott Wood @ 2008-01-14 15:28 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-dev
In-Reply-To: <1200234372.3990.24.camel@neuromancer.mindspace>
On Sun, Jan 13, 2008 at 02:26:12PM +0000, Bryan O'Donoghue wrote:
> I've applied your code against Linus' git v2.6.26-rc7 as at today.
> I have to apply
It should apply against paulus's tree.
> make adder87x-uboot_defconfig
>
> make uImage
make zImage, not uImage.
> cp arch/powerpc/boot/uImage /tftpboot - which is my tftpd root
> directory.
Use cuImage.8xx, not uImage.
> In U-Boot then.
>
> => tftpboot 0x400000 uImage
> => bootm 0x400000
0x400000 is where u-boot is going to want to relocate the image to, so
loading the uImage there may not work.
> Which doesn't boot.
>
> Attaching a BDI2000 to the target board I see that the kernel is
> panicing somewhere around line 104 of arch/powerpc/kernel/prom.c in
> of_scan_flat_dt - presumably because the kernel cannot find an
> OpenFirmware tree..
Yes, a uImage target will be expecting to be handed a device tree. The
cuImage target has a device tree embedded and accepts the old-style bd_t.
> I admit not understanding everything I should about where the output
> of .dts & dtc "go" with respect to booting Linux.... but, didn't want to
> ask on the list - lest I display a "lack of knowledge" ...
Nothing wrong with asking... doing so on the list just means a larger
pool of people to respond, and that others with the same question can see
the answer.
> /* pass open firmware flat tree */
> #define CONFIG_OF_LIBFDT 1
> #undef CONFIG_OF_FLAT_TREE
> #define CONFIG_OF_BOARD_SETUP 1
> #define CONFIG_OF_HAS_BD_T 1
> #define CONFIG_OF_HAS_UBOOT_ENV 1
>
> #define OF_CPU "PowerPC,875 at 0"
> #define OF_SOC "soc875 at ff000000"
> #define OF_TBCLK (bd->bi_busfreq / 4)
You'll probably need some 8xx-specific code if you want to go this route.
You'd also need to change the bootm command line to the three-argument
version, with the third argument being the address of the device tree
blob (the second argument can be - if there's no initrd).
If you're not comfortable with the device tree stuff, I recommend just
using cuImage for now.
-Scott
^ permalink raw reply
* Re: Quick Engine Support on Kernel 2.4
From: Timur Tabi @ 2008-01-14 15:59 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev
In-Reply-To: <5c9cd53b0801111521v25d0c1dt21ee59373826298@mail.gmail.com>
mike zheng wrote:
> Is there any BSP on Linux Kernel 2.4 support Quick Engine of MPC8568?
> If not, which BSP shall I start the porting? The BSP(on Kernel2.6) of
> MPC8568MDS from Freescale supports CPM2, but not QE. What the
> difference between CPM2 and QE?
Think of the QE as CPM3.
"Supporting the QE" means many things. The 2.6 kernel has core support for the
QE as well as support for several QE devices. You'll need to be more specific.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Scott Wood @ 2008-01-14 16:29 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The reg property in fsl soc nodes should be removed.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/fsl_soc.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..7502e03 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
soc = of_find_node_by_type(NULL, "soc");
if (soc) {
int size;
- const void *prop = of_get_property(soc, "reg", &size);
+ u32 naddr;
+ const u32 *prop = of_get_property(soc, "#address-cells", &size);
+
+ if (prop && size == 4)
+ naddr = *prop;
+ else
+ naddr = 2;
+
+ prop = of_get_property(soc, "ranges", &size);
+ if (prop && size == 12)
+ immrbase = of_translate_address(soc, prop + naddr);
- if (prop)
- immrbase = of_translate_address(soc, prop);
of_node_put(soc);
}
--
1.5.3
^ permalink raw reply related
* [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: Scott Wood @ 2008-01-14 16:30 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
ft_get_next_node() enumerates children of a given node.
ft_get_next_prop() enumerates propreties of a given node.
ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
than a node offset and property name; it is primarily intended for use
with ft_get_next_prop().
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
libfdt/fdt_ro.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++
libfdt/fdt_strerror.c | 1 +
libfdt/libfdt.h | 123 ++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 251 insertions(+), 7 deletions(-)
diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
index 12a37d5..27c943a 100644
--- a/libfdt/fdt_ro.c
+++ b/libfdt/fdt_ro.c
@@ -293,6 +293,51 @@ const void *fdt_getprop(const void *fdt, int nodeoffset,
return prop->data;
}
+const void *fdt_getprop_offset(const void *fdt, int propoffset,
+ const char **name, int *lenp)
+{
+ uint32_t tag;
+ const struct fdt_property *prop;
+ int namestroff;
+ int err, len;
+
+ err = fdt_check_header(fdt);
+ if (err)
+ goto fail;
+
+ tag = fdt_next_tag(fdt,propoffset, NULL);
+ if (tag != FDT_PROP) {
+ err = -FDT_ERR_BADOFFSET;
+ goto fail;
+ }
+
+ err = -FDT_ERR_BADSTRUCTURE;
+ prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop));
+ if (!prop)
+ goto fail;
+
+ if (name) {
+ namestroff = fdt32_to_cpu(prop->nameoff);
+ *name = fdt_string(fdt, namestroff);
+ }
+
+ len = fdt32_to_cpu(prop->len);
+ if (lenp)
+ *lenp = len;
+
+ prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop) + len);
+ if (!prop)
+ goto fail;
+
+ return prop->data;
+
+fail:
+ if (lenp)
+ *lenp = err;
+
+ return NULL;
+}
+
uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
{
const uint32_t *php;
@@ -581,3 +626,92 @@ int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
return -FDT_ERR_NOTFOUND;
}
+
+int fdt_get_next_node(const void *fdt, int startoffset,
+ int *depth, int recursive)
+{
+ uint32_t tag;
+ int offset, nextoffset;
+
+ CHECK_HEADER(fdt);
+
+ if (startoffset >= 0) {
+ tag = fdt_next_tag(fdt, startoffset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+ } else {
+ nextoffset = 0;
+ }
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_BEGIN_NODE:
+ if ((*depth)++ == 0 || recursive) {
+ return offset;
+ }
+
+ break;
+
+ case FDT_END_NODE:
+ if (--*depth < 0)
+ return -FDT_ERR_NOTFOUND;
+
+ break;
+
+ case FDT_PROP:
+ case FDT_END:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (tag != FDT_END);
+
+ if (depth != 0)
+ return -FDT_ERR_BADSTRUCTURE;
+
+ return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_get_next_prop(const void *fdt, int startoffset)
+{
+ uint32_t tag;
+ int offset, nextoffset;
+
+ CHECK_HEADER(fdt);
+
+ if (startoffset >= 0) {
+ tag = fdt_next_tag(fdt, startoffset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE && tag != FDT_PROP)
+ return -FDT_ERR_BADOFFSET;
+ } else {
+ nextoffset = 0;
+ }
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_BEGIN_NODE:
+ case FDT_END_NODE:
+ return -FDT_ERR_NOTFOUND;
+
+ case FDT_PROP:
+ return offset;
+
+ case FDT_END:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (tag != FDT_END);
+
+ return -FDT_ERR_BADSTRUCTURE;
+}
diff --git a/libfdt/fdt_strerror.c b/libfdt/fdt_strerror.c
index f9d32ef..4e87550 100644
--- a/libfdt/fdt_strerror.c
+++ b/libfdt/fdt_strerror.c
@@ -70,6 +70,7 @@ static struct errtabent errtable[] = {
ERRTABENT(FDT_ERR_BADOFFSET),
ERRTABENT(FDT_ERR_BADPATH),
ERRTABENT(FDT_ERR_BADSTATE),
+ ERRTABENT(FDT_ERR_BADDEPTH),
ERRTABENT(FDT_ERR_TRUNCATED),
ERRTABENT(FDT_ERR_BADMAGIC),
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index d053689..6c5d4a9 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -85,25 +85,28 @@
/* FDT_ERR_BADSTATE: Function was passed an incomplete device
* tree created by the sequential-write functions, which is
* not sufficiently complete for the requested operation. */
+#define FDT_ERR_BADDEPTH 8
+ /* FDT_ERR_BADDEPTH: Function was passed a negative
+ * (or otherwise invalid) depth. */
/* Error codes: codes for bad device tree blobs */
-#define FDT_ERR_TRUNCATED 8
+#define FDT_ERR_TRUNCATED 9
/* FDT_ERR_TRUNCATED: Structure block of the given device tree
* ends without an FDT_END tag. */
-#define FDT_ERR_BADMAGIC 9
+#define FDT_ERR_BADMAGIC 10
/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
* device tree at all - it is missing the flattened device
* tree magic number. */
-#define FDT_ERR_BADVERSION 10
+#define FDT_ERR_BADVERSION 11
/* FDT_ERR_BADVERSION: Given device tree has a version which
* can't be handled by the requested operation. For
* read-write functions, this may mean that fdt_open_into() is
* required to convert the tree to the expected version. */
-#define FDT_ERR_BADSTRUCTURE 11
+#define FDT_ERR_BADSTRUCTURE 12
/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
* structure block or other serious error (e.g. misnested
* nodes, or subnodes preceding properties). */
-#define FDT_ERR_BADLAYOUT 12
+#define FDT_ERR_BADLAYOUT 13
/* FDT_ERR_BADLAYOUT: For read-write functions, the given
* device tree has it's sub-blocks in an order that the
* function can't handle (memory reserve map, then structure,
@@ -111,12 +114,12 @@
* into a form suitable for the read-write operations. */
/* "Can't happen" error indicating a bug in libfdt */
-#define FDT_ERR_INTERNAL 13
+#define FDT_ERR_INTERNAL 14
/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
* Should never be returned, if it is, it indicates a bug in
* libfdt itself. */
-#define FDT_ERR_MAX 13
+#define FDT_ERR_MAX 14
/**********************************************************************/
/* Low-level functions (you probably don't need these) */
@@ -409,6 +412,41 @@ static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
}
/**
+ * fdt_getprop_offset - retrieve the value of a given property by offset
+ * @fdt: pointer to the device tree blob
+ * @propoffset: offset of the property to read
+ * @name: pointer to a character pointer (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the property's value
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_offset(const void *fdt, int propoffset,
+ const char **name, int *lenp);
+static inline void *fdt_getprop_offset_w(void *fdt, int propoffset,
+ const char **name, int *lenp)
+{
+ return (void *)fdt_getprop_offset(fdt, propoffset, name, lenp);
+}
+
+/**
* fdt_get_phandle - retreive the phandle of a given node
* @fdt: pointer to the device tree blob
* @nodeoffset: structure block offset of the node
@@ -651,6 +689,77 @@ int fdt_node_check_compatible(const void *fdt, int nodeoffset,
int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
const char *compatible);
+/**
+ * fdt_get_next_node - enumerate children of a node
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @depth: depth of the node, should be zero upon first call
+ * @recursive: only find immediate children if zero
+ *
+ * fdt_get_next_node() returns the offset of the first node after
+ * startoffset, until depth returns to zero.
+ *
+ * To iterate through all children, the following idiom can be used:
+ * depth = 0;
+ * offset = parent node offset;
+ * while (1) {
+ * offset = fdt_get_next_node(fdt, offset, &depth, recursive);
+ * if (offset < 0)
+ * break;
+ *
+ * // other code here
+ * }
+ *
+ * To find all the children of the root node, set the initial
+ * offset to zero. To find all nodes *including* the root
+ * node, set the initial offset and depth to -1.
+ *
+ * returns:
+ * structure block offset of the located node (>= 0, >startoffset),
+ * on success
+ * -FDT_ERR_NOTFOUND, no more child nodes exist after startoffset
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADDEPTH, standard meanings
+ */
+int fdt_get_next_node(const void *fdt, int startoffset,
+ int *depth, int recursive);
+
+/**
+ * fdt_get_next_prop - enumerate properties of a node
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ *
+ * fdt_get_next_prop() returns the offset of the first property after
+ * startoffset.
+ *
+ * To iterate through all properties, the following idiom can be used:
+ * offset = node offset;
+ * while (1) {
+ * offset = fdt_get_next_prop(fdt, offset);
+ * if (offset < 0)
+ * break;
+ *
+ * // other code here
+ * }
+ *
+ * returns:
+ * structure block offset of the located property (>= 0, >startoffset),
+ * on success
+ * -FDT_ERR_NOTFOUND, no more properties exist in the current node
+ * after startoffset
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * or a PROP tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_next_prop(const void *fdt, int startoffset);
+
/**********************************************************************/
/* Write-in-place functions */
/**********************************************************************/
--
1.5.3
^ permalink raw reply related
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