* Re: [PATCH 3/5] Use dcr_host_t.base in ibm_emac_mal
From: Benjamin Herrenschmidt @ 2007-07-12 0:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <3e7d30667d5ac0b6aabc197fb5d500b9c6c82feb.1182493056.git.michael@ellerman.id.au>
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> This requires us to do a sort-of fake dcr_map(), so that base is set
> properly. This will be fixed/removed when the device-tree-aware emac driver
> is merged.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/net/ibm_emac/ibm_emac_mal.c | 5 ++++-
> drivers/net/ibm_emac/ibm_emac_mal.h | 5 ++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c b/drivers/net/ibm_emac/ibm_emac_mal.c
> index cabd984..b08da96 100644
> --- a/drivers/net/ibm_emac/ibm_emac_mal.c
> +++ b/drivers/net/ibm_emac/ibm_emac_mal.c
> @@ -421,7 +421,10 @@ static int __init mal_probe(struct ocp_device *ocpdev)
> ocpdev->def->index);
> return -ENOMEM;
> }
> - mal->dcrbase = maldata->dcr_base;
> +
> + /* XXX This only works for native dcr for now */
> + mal->dcrhost = dcr_map(NULL, maldata->dcr_base, 0);
> +
> mal->def = ocpdev->def;
>
> INIT_LIST_HEAD(&mal->poll_list);
> diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
> index 64bc338..6b1fbeb 100644
> --- a/drivers/net/ibm_emac/ibm_emac_mal.h
> +++ b/drivers/net/ibm_emac/ibm_emac_mal.h
> @@ -191,7 +191,6 @@ struct mal_commac {
> };
>
> struct ibm_ocp_mal {
> - int dcrbase;
> dcr_host_t dcrhost;
>
> struct list_head poll_list;
> @@ -209,12 +208,12 @@ struct ibm_ocp_mal {
>
> static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
> {
> - return dcr_read(mal->dcrhost, mal->dcrbase + reg);
> + return dcr_read(mal->dcrhost, mal->dcrhost.base + reg);
> }
>
> static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
> {
> - dcr_write(mal->dcrhost, mal->dcrbase + reg, val);
> + dcr_write(mal->dcrhost, mal->dcrhost.base + reg, val);
> }
>
> /* Register MAL devices */
^ permalink raw reply
* Re: [PATCH 2/5] Update mpic to use dcr_host_t.base
From: Benjamin Herrenschmidt @ 2007-07-12 0:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <cdcb4a9477581e28def3ccc8dab5427d0662b0ba.1182493056.git.michael@ellerman.id.au>
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the mpic
> code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/sysdev/mpic.c | 28 +++++++++++-----------------
> include/asm-powerpc/mpic.h | 6 ------
> 2 files changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 75aad38..6c2e467 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -156,8 +156,7 @@ static inline u32 _mpic_read(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_read(rb->dhost,
> - rb->dbase + reg + rb->doff);
> + return dcr_read(rb->dhost, rb->dhost.base + reg);
> #endif
> case mpic_access_mmio_be:
> return in_be32(rb->base + (reg >> 2));
> @@ -174,8 +173,7 @@ static inline void _mpic_write(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_write(rb->dhost,
> - rb->dbase + reg + rb->doff, value);
> + return dcr_write(rb->dhost, rb->dhost.base + reg, value);
> #endif
> case mpic_access_mmio_be:
> return out_be32(rb->base + (reg >> 2), value);
> @@ -269,9 +267,11 @@ static void _mpic_map_mmio(struct mpic *mpic, unsigned long phys_addr,
> static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
> unsigned int offset, unsigned int size)
> {
> - rb->dbase = mpic->dcr_base;
> - rb->doff = offset;
> - rb->dhost = dcr_map(mpic->of_node, rb->dbase + rb->doff, size);
> + const u32 *dbasep;
> +
> + dbasep = of_get_property(mpic->of_node, "dcr-reg", NULL);
> +
> + rb->dhost = dcr_map(mpic->of_node, *dbasep + offset, size);
> BUG_ON(!DCR_MAP_OK(rb->dhost));
> }
>
> @@ -1047,20 +1047,14 @@ struct mpic * __init mpic_alloc(struct device_node *node,
> BUG_ON(paddr == 0 && node == NULL);
>
> /* If no physical address passed in, check if it's dcr based */
> - if (paddr == 0 && of_get_property(node, "dcr-reg", NULL) != NULL)
> - mpic->flags |= MPIC_USES_DCR;
> -
> + if (paddr == 0 && of_get_property(node, "dcr-reg", NULL) != NULL) {
> #ifdef CONFIG_PPC_DCR
> - if (mpic->flags & MPIC_USES_DCR) {
> - const u32 *dbasep;
> - dbasep = of_get_property(node, "dcr-reg", NULL);
> - BUG_ON(dbasep == NULL);
> - mpic->dcr_base = *dbasep;
> + mpic->flags |= MPIC_USES_DCR;
> mpic->reg_type = mpic_access_dcr;
> - }
> #else
> - BUG_ON (mpic->flags & MPIC_USES_DCR);
> + BUG();
> #endif /* CONFIG_PPC_DCR */
> + }
>
> /* If the MPIC is not DCR based, and no physical address was passed
> * in, try to obtain one
> diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
> index 2ffb06a..11b8e51 100644
> --- a/include/asm-powerpc/mpic.h
> +++ b/include/asm-powerpc/mpic.h
> @@ -224,8 +224,6 @@ struct mpic_reg_bank {
> u32 __iomem *base;
> #ifdef CONFIG_PPC_DCR
> dcr_host_t dhost;
> - unsigned int dbase;
> - unsigned int doff;
> #endif /* CONFIG_PPC_DCR */
> };
>
> @@ -292,10 +290,6 @@ struct mpic
> struct mpic_reg_bank cpuregs[MPIC_MAX_CPUS];
> struct mpic_reg_bank isus[MPIC_MAX_ISU];
>
> -#ifdef CONFIG_PPC_DCR
> - unsigned int dcr_base;
> -#endif
> -
> #ifdef CONFIG_MPIC_WEIRD
> /* Pointer to HW info array */
> u32 *hw_set;
^ permalink raw reply
* Re: [PATCH 1/5] Store the base address in dcr_host_t
From: Benjamin Herrenschmidt @ 2007-07-12 0:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <3cdc6bd05b505600609a79667f3674168e2e855b.1182493056.git.michael@ellerman.id.au>
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> In its current form, dcr_map() doesn't remember the base address you passed
> it, which means you need to store it somewhere else. Rather than adding the
> base to another struct it seems simpler to store it in the dcr_host_t.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/sysdev/dcr.c | 2 +-
> include/asm-powerpc/dcr-mmio.h | 6 +++++-
> include/asm-powerpc/dcr-native.h | 6 ++++--
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index 574b6ef..f3c5646 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -102,7 +102,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
> dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> unsigned int dcr_c)
> {
> - dcr_host_t ret = { .token = NULL, .stride = 0 };
> + dcr_host_t ret = { .token = NULL, .stride = 0, .base = dcr_n };
> u64 addr;
>
> pr_debug("dcr_map(%s, 0x%x, 0x%x)\n",
> diff --git a/include/asm-powerpc/dcr-mmio.h b/include/asm-powerpc/dcr-mmio.h
> index 5dbfca8..6b82c3b 100644
> --- a/include/asm-powerpc/dcr-mmio.h
> +++ b/include/asm-powerpc/dcr-mmio.h
> @@ -23,7 +23,11 @@
>
> #include <asm/io.h>
>
> -typedef struct { void __iomem *token; unsigned int stride; } dcr_host_t;
> +typedef struct {
> + void __iomem *token;
> + unsigned int stride;
> + unsigned int base;
> +} dcr_host_t;
>
> #define DCR_MAP_OK(host) ((host).token != NULL)
>
> diff --git a/include/asm-powerpc/dcr-native.h b/include/asm-powerpc/dcr-native.h
> index 05af081..f41058c 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -22,11 +22,13 @@
> #ifdef __KERNEL__
> #ifndef __ASSEMBLY__
>
> -typedef struct {} dcr_host_t;
> +typedef struct {
> + unsigned int base;
> +} dcr_host_t;
>
> #define DCR_MAP_OK(host) (1)
>
> -#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){})
> +#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base = (dcr_n) })
> #define dcr_unmap(host, dcr_n, dcr_c) do {} while (0)
> #define dcr_read(host, dcr_n) mfdcr(dcr_n)
> #define dcr_write(host, dcr_n, value) mtdcr(dcr_n, value)
^ permalink raw reply
* Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
From: Mark A. Greer @ 2007-07-11 23:47 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707112233.51899.arnd@arndb.de>
On Wed, Jul 11, 2007 at 10:33:51PM +0200, Arnd Bergmann wrote:
> On Wednesday 11 July 2007, Mark A. Greer wrote:
>
> > > +config CLASSIC32
> > > + def_bool y
> > > + depends on 6xx && PPC_MULTIPLATFORM
> > ^^^^^^^^^^^^^^^^^^^^
> > Arnd, is this really what you wanted? With it, none of the embedded
> > classics have CLASSIC32 defined which means they don't get TAU or
> > ALTIVEC defined which isn't good.
>
> Sorry, this was the result of a wrong patch reordering. In my initial
> patch set I ended up with 6xx == CLASSIC32 and PPC_MULTIPLATFORM=y,
> but then I backed out a few patches in the middle.
Ah, okay.
> I guess the best is to do another patch that moves PPC_EMBEDDED6xx into
> PPC_MULTIPLATFORM again and leaves this one as it is.
> Alternatively, we could kill CONFIG_CLASSIC32 entirely as it is used
> only in a few places. Especially after I resubmit my CPU type selection
> patch again, which allows you do it in a more fine grained way.
Yes, it seems like getting rid of CLASSIC32 would be okay since it is
hardly used.
> Which systems in particular should allow CONFIG_TAU? Is there a more
> specific dependency than (6xx && !(82xx || 83xx || 86xx || 52xx))?
I think Segher pretty much answered this. We definitely need to get
ALTIVEC back soon for 74xx--currently SIGILL's my init when booting.
Since it sounds like you're still tweaking things in Kconfig files,
I'll leave it to you to take care of it. If not, just let me know.
Mark
^ permalink raw reply
* Re: [PATCH] do firmware feature fixups after features are initialised
From: Michael Neuling @ 2007-07-11 23:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: paulus, linuxppc-dev
In-Reply-To: <200707111329.51580.arnd@arndb.de>
In message <200707111329.51580.arnd@arndb.de> you wrote:
> On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
> > There are two possibly solutions I see in the long run:
> > =
>
> > =A0- We could set the FW features earlier on pseries, though that is a bit
> > annoying because that means doing it before the device-tree is
> > unflattened.
> > =
>
> > =A0- We could constraint lmb_alloc to the first segment until the FW fixup
> > occurs, either within lmb_alloc itself, or fixup the callers such as
> > unflatten_device_tree, to pass an explicit limit.
> > =
>
> > What do you think ?
>
> If I'm understanding this right, the first solution should be something
> along the lines of the patch below (not tested), which even removes
> more lines than it adds. It doesn't seem that annoying to me, and it
> makes sense to assume that the fw_features are set up after returning
> from the ppc_md probe.
I'm not sure this patch is going to work as the do_feature_fixups isn't
called any earlier?
Mikey
>
> Arnd <><
>
> Index: linux-2.6/arch/powerpc/platforms/pseries/setup.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/setup.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/setup.c
> @@ -327,8 +327,6 @@ static void __init pSeries_init_early(vo
> {
> DBG(" -> pSeries_init_early()\n");
> =
>
> - fw_feature_init();
> -
> if (firmware_has_feature(FW_FEATURE_LPAR))
> find_udbg_vterm();
> =
>
> @@ -350,14 +348,21 @@ static int __init pSeries_probe_hypertas
> const char *uname, int depth,
> void *data)
> {
> + const char *hypertas;
> + unsigned long len;
> +
> if (depth !=3D 1 ||
> (strcmp(uname, "rtas") !=3D 0 && strcmp(uname, "rtas@0") !=3D 0))
> - return 0;
> + return 0;
> +
> + hypertas =3D of_get_flat_dt_prop(node, "ibm,hypertas-functions", &len);
> + if (!hypertas)
> + return 1;
> =
>
> - if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL) !=3D NULL
)
> - powerpc_firmware_features |=3D FW_FEATURE_LPAR;
> + powerpc_firmware_features |=3D FW_FEATURE_LPAR;
> + fw_feature_init(hypertas, len);
> =
>
> - return 1;
> + return 1;
> }
> =
>
> static int __init pSeries_probe(void)
> Index: linux-2.6/arch/powerpc/platforms/pseries/pseries.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/pseries.h
> +++ linux-2.6/arch/powerpc/platforms/pseries/pseries.h
> @@ -10,7 +10,7 @@
> #ifndef _PSERIES_PSERIES_H
> #define _PSERIES_PSERIES_H
> =
>
> -extern void __init fw_feature_init(void);
> +extern void __init fw_feature_init(const char *, unsigned long);
> =
>
> struct pt_regs;
> =
>
> diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platf=
> orms/pseries/firmware.c
> index 29bf83b..b0c8dbd 100644
> --- a/arch/powerpc/platforms/pseries/firmware.c
> +++ b/arch/powerpc/platforms/pseries/firmware.c
> @@ -66,24 +66,14 @@ firmware_features_table[FIRMWARE_MAX_FEATURES] =3D {
> * device-tree/ibm,hypertas-functions. Ultimately this functionality may
> * be moved into prom.c prom_init().
> */
> -void __init fw_feature_init(void)
> +void __init fw_feature_init(const char *hypertas, unsigned long len)
> {
> struct device_node *dn;
> const char *hypertas, *s;
> - int len, i;
> + int i;
> =
>
> DBG(" -> fw_feature_init()\n");
> =
>
> - dn =3D of_find_node_by_path("/rtas");
> - if (dn =3D=3D NULL) {
> - printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n");
> - goto out;
> - }
> -
> - hypertas =3D of_get_property(dn, "ibm,hypertas-functions", &len);
> - if (hypertas =3D=3D NULL)
> - goto out;
> -
> for (s =3D hypertas; s < hypertas + len; s +=3D strlen(s) + 1) {
> for (i =3D 0; i < FIRMWARE_MAX_FEATURES; i++) {
> /* check value against table of strings */
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Tickless Hz/hrtimers/etc. on PowerPC
From: Matt Sealey @ 2007-07-11 22:15 UTC (permalink / raw)
To: Michael Neuling; +Cc: ppc-dev
In-Reply-To: <8302.1184178785@neuling.org>
Okay.
What I didn't want to do is spend a day sifting some other development
tree picking out what I think might be possibly sort of the right patches
for it.
I'd get it wrong because having not worked on it, I don't know what I am
even looking for.
And I don't want to run -rt or wireless-dev for the benefit of a single
feature. What I am after is something like Ingo Molnar throws out..
single patches done the old way, not git trees. It's so much easier to
handle and integrate for example into a Gentoo ebuild or to make a
tarball of accumulated patches from a certain release kernel.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Michael Neuling wrote:
>> Does anyone have the definitive patchset to enable the tickless hz,
>> some kind of hrtimer and the other related improvements in the PowerPC
>> tree?
>
> Tony Breeds has been looking at this. I think he wanted to clean his
> patch set up before he posted it.
>
> Mikey
^ permalink raw reply
* [PATCH 2/2] DTC: Inherit all of the Device Tree Compiler technical descriptions
From: Jon Loeliger @ 2007-07-11 21:46 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: Jon Loeliger
From: Jon Loeliger <jdl@freescale.com>
out of the kernel's Documentation/powerpc/booting-without-of.txt.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/manual.txt | 493 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 493 insertions(+), 0 deletions(-)
create mode 100644 Documentation/manual.txt
diff --git a/Documentation/manual.txt b/Documentation/manual.txt
new file mode 100644
index 0000000..6f57f16
--- /dev/null
+++ b/Documentation/manual.txt
@@ -0,0 +1,493 @@
+Device Tree Compiler Manual
+===========================
+
+ I - "dtc", the device tree compiler
+
+
+ II - The DT block format
+ 1) Header
+ 2) Device tree generalities
+ 3) Device tree "structure" block
+ 4) Device tree "strings" block
+
+
+
+I - "dtc", the device tree compiler
+===================================
+
+dtc source code can be found at
+<http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
+
+WARNING: This version is still in early development stage; the
+resulting device-tree "blobs" have not yet been validated with the
+kernel. The current generated bloc lacks a useful reserve map (it will
+be fixed to generate an empty one, it's up to the bootloader to fill
+it up) among others. The error handling needs work, bugs are lurking,
+etc...
+
+dtc basically takes a device-tree in a given format and outputs a
+device-tree in another format. The currently supported formats are:
+
+ Input formats:
+ -------------
+
+ - "dtb": "blob" format, that is a flattened device-tree block
+ with
+ header all in a binary blob.
+ - "dts": "source" format. This is a text file containing a
+ "source" for a device-tree. The format is defined later in this
+ chapter.
+ - "fs" format. This is a representation equivalent to the
+ output of /proc/device-tree, that is nodes are directories and
+ properties are files
+
+ Output formats:
+ ---------------
+
+ - "dtb": "blob" format
+ - "dts": "source" format
+ - "asm": assembly language file. This is a file that can be
+ sourced by gas to generate a device-tree "blob". That file can
+ then simply be added to your Makefile. Additionally, the
+ assembly file exports some symbols that can be used.
+
+
+The syntax of the dtc tool is
+
+ dtc [-I <input-format>] [-O <output-format>]
+ [-o output-filename] [-V output_version] input_filename
+
+
+The "output_version" defines what version of the "blob" format will be
+generated. Supported versions are 1,2,3 and 16. The default is
+currently version 3 but that may change in the future to version 16.
+
+Additionally, dtc performs various sanity checks on the tree, like the
+uniqueness of linux, phandle properties, validity of strings, etc...
+
+The format of the .dts "source" file is "C" like, supports C and C++
+style comments.
+
+/ {
+}
+
+The above is the "device-tree" definition. It's the only statement
+supported currently at the toplevel.
+
+/ {
+ property1 = "string_value"; /* define a property containing a 0
+ * terminated string
+ */
+
+ property2 = <1234abcd>; /* define a property containing a
+ * numerical 32-bit value (hexadecimal)
+ */
+
+ property3 = <12345678 12345678 deadbeef>;
+ /* define a property containing 3
+ * numerical 32-bit values (cells) in
+ * hexadecimal
+ */
+ property4 = [0a 0b 0c 0d de ea ad be ef];
+ /* define a property whose content is
+ * an arbitrary array of bytes
+ */
+
+ childnode@addresss { /* define a child node named "childnode"
+ * whose unit name is "childnode at
+ * address"
+ */
+
+ childprop = "hello\n"; /* define a property "childprop" of
+ * childnode (in this case, a string)
+ */
+ };
+};
+
+Nodes can contain other nodes etc... thus defining the hierarchical
+structure of the tree.
+
+Strings support common escape sequences from C: "\n", "\t", "\r",
+"\(octal value)", "\x(hex value)".
+
+It is also suggested that you pipe your source file through cpp (gcc
+preprocessor) so you can use #include's, #define for constants, etc...
+
+Finally, various options are planned but not yet implemented, like
+automatic generation of phandles, labels (exported to the asm file so
+you can point to a property content and change it easily from whatever
+you link the device-tree with), label or path instead of numeric value
+in some cells to "point" to a node (replaced by a phandle at compile
+time), export of reserve map address to the asm file, ability to
+specify reserve map content at compile time, etc...
+
+We may provide a .h include file with common definitions of that
+proves useful for some properties (like building PCI properties or
+interrupt maps) though it may be better to add a notion of struct
+definitions to the compiler...
+
+
+
+II - The DT block format
+========================
+
+This chapter defines the actual format of the flattened device-tree
+passed to the kernel. The actual content of it and kernel requirements
+are described later. You can find example of code manipulating that
+format in various places, including arch/powerpc/kernel/prom_init.c
+which will generate a flattened device-tree from the Open Firmware
+representation, or the fs2dt utility which is part of the kexec tools
+which will generate one from a filesystem representation. It is
+expected that a bootloader like uboot provides a bit more support,
+that will be discussed later as well.
+
+Note: The block has to be in main memory. It has to be accessible in
+both real mode and virtual mode with no mapping other than main
+memory. If you are writing a simple flash bootloader, it should copy
+the block to RAM before passing it to the kernel.
+
+
+1) Header
+---------
+
+ The kernel is entered with r3 pointing to an area of memory that is
+ roughly described in include/asm-powerpc/prom.h by the structure
+ boot_param_header:
+
+struct boot_param_header {
+ u32 magic; /* magic word OF_DT_HEADER */
+ u32 totalsize; /* total size of DT block */
+ u32 off_dt_struct; /* offset to structure */
+ u32 off_dt_strings; /* offset to strings */
+ u32 off_mem_rsvmap; /* offset to memory reserve map
+ */
+ u32 version; /* format version */
+ u32 last_comp_version; /* last compatible version */
+
+ /* version 2 fields below */
+ u32 boot_cpuid_phys; /* Which physical CPU id we're
+ booting on */
+ /* version 3 fields below */
+ u32 size_dt_strings; /* size of the strings block */
+
+ /* version 17 fields below */
+ u32 size_dt_struct; /* size of the DT structure block */
+};
+
+ Along with the constants:
+
+/* Definitions used by the flattened device tree */
+#define OF_DT_HEADER 0xd00dfeed /* 4: version,
+ 4: total size */
+#define OF_DT_BEGIN_NODE 0x1 /* Start node: full name
+ */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off,
+ size, content */
+#define OF_DT_END 0x9
+
+ All values in this header are in big endian format, the various
+ fields in this header are defined more precisely below. All
+ "offset" values are in bytes from the start of the header; that is
+ from the value of r3.
+
+ - magic
+
+ This is a magic value that "marks" the beginning of the
+ device-tree block header. It contains the value 0xd00dfeed and is
+ defined by the constant OF_DT_HEADER
+
+ - totalsize
+
+ This is the total size of the DT block including the header. The
+ "DT" block should enclose all data structures defined in this
+ chapter (who are pointed to by offsets in this header). That is,
+ the device-tree structure, strings, and the memory reserve map.
+
+ - off_dt_struct
+
+ This is an offset from the beginning of the header to the start
+ of the "structure" part the device tree. (see 2) device tree)
+
+ - off_dt_strings
+
+ This is an offset from the beginning of the header to the start
+ of the "strings" part of the device-tree
+
+ - off_mem_rsvmap
+
+ This is an offset from the beginning of the header to the start
+ of the reserved memory map. This map is a list of pairs of 64-
+ bit integers. Each pair is a physical address and a size. The
+ list is terminated by an entry of size 0. This map provides the
+ kernel with a list of physical memory areas that are "reserved"
+ and thus not to be used for memory allocations, especially during
+ early initialization. The kernel needs to allocate memory during
+ boot for things like un-flattening the device-tree, allocating an
+ MMU hash table, etc... Those allocations must be done in such a
+ way to avoid overriding critical things like, on Open Firmware
+ capable machines, the RTAS instance, or on some pSeries, the TCE
+ tables used for the iommu. Typically, the reserve map should
+ contain _at least_ this DT block itself (header,total_size). If
+ you are passing an initrd to the kernel, you should reserve it as
+ well. You do not need to reserve the kernel image itself. The map
+ should be 64-bit aligned.
+
+ - version
+
+ This is the version of this structure. Version 1 stops
+ here. Version 2 adds an additional field boot_cpuid_phys.
+ Version 3 adds the size of the strings block, allowing the kernel
+ to reallocate it easily at boot and free up the unused flattened
+ structure after expansion. Version 16 introduces a new more
+ "compact" format for the tree itself that is however not backward
+ compatible. Version 17 adds an additional field, size_dt_struct,
+ allowing it to be reallocated or moved more easily (this is
+ particularly useful for bootloaders which need to make
+ adjustments to a device tree based on probed information). You
+ should always generate a structure of the highest version defined
+ at the time of your implementation. Currently that is version 17,
+ unless you explicitly aim at being backward compatible.
+
+ - last_comp_version
+
+ Last compatible version. This indicates down to what version of
+ the DT block you are backward compatible. For example, version 2
+ is backward compatible with version 1 (that is, a kernel build
+ for version 1 will be able to boot with a version 2 format). You
+ should put a 1 in this field if you generate a device tree of
+ version 1 to 3, or 16 if you generate a tree of version 16 or 17
+ using the new unit name format.
+
+ - boot_cpuid_phys
+
+ This field only exist on version 2 headers. It indicate which
+ physical CPU ID is calling the kernel entry point. This is used,
+ among others, by kexec. If you are on an SMP system, this value
+ should match the content of the "reg" property of the CPU node in
+ the device-tree corresponding to the CPU calling the kernel entry
+ point (see further chapters for more informations on the required
+ device-tree contents)
+
+ - size_dt_strings
+
+ This field only exists on version 3 and later headers. It
+ gives the size of the "strings" section of the device tree (which
+ starts at the offset given by off_dt_strings).
+
+ - size_dt_struct
+
+ This field only exists on version 17 and later headers. It gives
+ the size of the "structure" section of the device tree (which
+ starts at the offset given by off_dt_struct).
+
+ So the typical layout of a DT block (though the various parts don't
+ need to be in that order) looks like this (addresses go from top to
+ bottom):
+
+
+ ------------------------------
+ r3 -> | struct boot_param_header |
+ ------------------------------
+ | (alignment gap) (*) |
+ ------------------------------
+ | memory reserve map |
+ ------------------------------
+ | (alignment gap) |
+ ------------------------------
+ | |
+ | device-tree structure |
+ | |
+ ------------------------------
+ | (alignment gap) |
+ ------------------------------
+ | |
+ | device-tree strings |
+ | |
+ -----> ------------------------------
+ |
+ |
+ --- (r3 + totalsize)
+
+ (*) The alignment gaps are not necessarily present; their presence
+ and size are dependent on the various alignment requirements of
+ the individual data blocks.
+
+
+2) Device tree generalities
+---------------------------
+
+This device-tree itself is separated in two different blocks, a
+structure block and a strings block. Both need to be aligned to a 4
+byte boundary.
+
+First, let's quickly describe the device-tree concept before detailing
+the storage format. This chapter does _not_ describe the detail of the
+required types of nodes & properties for the kernel, this is done
+later in chapter III.
+
+The device-tree layout is strongly inherited from the definition of
+the Open Firmware IEEE 1275 device-tree. It's basically a tree of
+nodes, each node having two or more named properties. A property can
+have a value or not.
+
+It is a tree, so each node has one and only one parent except for the
+root node who has no parent.
+
+A node has 2 names. The actual node name is generally contained in a
+property of type "name" in the node property list whose value is a
+zero terminated string and is mandatory for version 1 to 3 of the
+format definition (as it is in Open Firmware). Version 16 makes it
+optional as it can generate it from the unit name defined below.
+
+There is also a "unit name" that is used to differentiate nodes with
+the same name at the same level, it is usually made of the node
+names, the "@" sign, and a "unit address", which definition is
+specific to the bus type the node sits on.
+
+The unit name doesn't exist as a property per-se but is included in
+the device-tree structure. It is typically used to represent "path" in
+the device-tree. More details about the actual format of these will be
+below.
+
+The kernel powerpc generic code does not make any formal use of the
+unit address (though some board support code may do) so the only real
+requirement here for the unit address is to ensure uniqueness of
+the node unit name at a given level of the tree. Nodes with no notion
+of address and no possible sibling of the same name (like /memory or
+/cpus) may omit the unit address in the context of this specification,
+or use the "@0" default unit address. The unit name is used to define
+a node "full path", which is the concatenation of all parent node
+unit names separated with "/".
+
+The root node doesn't have a defined name, and isn't required to have
+a name property either if you are using version 3 or earlier of the
+format. It also has no unit address (no @ symbol followed by a unit
+address). The root node unit name is thus an empty string. The full
+path to the root node is "/".
+
+Every node which actually represents an actual device (that is, a node
+which isn't only a virtual "container" for more nodes, like "/cpus"
+is) is also required to have a "device_type" property indicating the
+type of node .
+
+Finally, every node that can be referenced from a property in another
+node is required to have a "linux,phandle" property. Real open
+firmware implementations provide a unique "phandle" value for every
+node that the "prom_init()" trampoline code turns into
+"linux,phandle" properties. However, this is made optional if the
+flattened device tree is used directly. An example of a node
+referencing another node via "phandle" is when laying out the
+interrupt tree which will be described in a further version of this
+document.
+
+This "linux, phandle" property is a 32-bit value that uniquely
+identifies a node. You are free to use whatever values or system of
+values, internal pointers, or whatever to generate these, the only
+requirement is that every node for which you provide that property has
+a unique value for it.
+
+Here is an example of a simple device-tree. In this example, an "o"
+designates a node followed by the node unit name. Properties are
+presented with their name followed by their content. "content"
+represents an ASCII string (zero terminated) value, while <content>
+represents a 32-bit hexadecimal value. The various nodes in this
+example will be discussed in a later chapter. At this point, it is
+only meant to give you a idea of what a device-tree looks like. I have
+purposefully kept the "name" and "linux,phandle" properties which
+aren't necessary in order to give you a better idea of what the tree
+looks like in practice.
+
+ / o device-tree
+ |- name = "device-tree"
+ |- model = "MyBoardName"
+ |- compatible = "MyBoardFamilyName"
+ |- #address-cells = <2>
+ |- #size-cells = <2>
+ |- linux,phandle = <0>
+ |
+ o cpus
+ | | - name = "cpus"
+ | | - linux,phandle = <1>
+ | | - #address-cells = <1>
+ | | - #size-cells = <0>
+ | |
+ | o PowerPC,970@0
+ | |- name = "PowerPC,970"
+ | |- device_type = "cpu"
+ | |- reg = <0>
+ | |- clock-frequency = <5f5e1000>
+ | |- 64-bit
+ | |- linux,phandle = <2>
+ |
+ o memory@0
+ | |- name = "memory"
+ | |- device_type = "memory"
+ | |- reg = <00000000 00000000 00000000 20000000>
+ | |- linux,phandle = <3>
+ |
+ o chosen
+ |- name = "chosen"
+ |- bootargs = "root=/dev/sda2"
+ |- linux,phandle = <4>
+
+This tree is almost a minimal tree. It pretty much contains the
+minimal set of required nodes and properties to boot a linux kernel;
+that is, some basic model informations at the root, the CPUs, and the
+physical memory layout. It also includes misc information passed
+through /chosen, like in this example, the platform type (mandatory)
+and the kernel command line arguments (optional).
+
+The /cpus/PowerPC,970@0/64-bit property is an example of a
+property without a value. All other properties have a value. The
+significance of the #address-cells and #size-cells properties will be
+explained in chapter IV which defines precisely the required nodes and
+properties and their content.
+
+
+3) Device tree "structure" block
+
+The structure of the device tree is a linearized tree structure. The
+"OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
+ends that node definition. Child nodes are simply defined before
+"OF_DT_END_NODE" (that is nodes within the node). A 'token' is a 32
+bit value. The tree has to be "finished" with a OF_DT_END token
+
+Here's the basic structure of a single node:
+
+ * token OF_DT_BEGIN_NODE (that is 0x00000001)
+ * for version 1 to 3, this is the node full path as a zero
+ terminated string, starting with "/". For version 16 and later,
+ this is the node unit name only (or an empty string for the
+ root node)
+ * [align gap to next 4 bytes boundary]
+ * for each property:
+ * token OF_DT_PROP (that is 0x00000003)
+ * 32-bit value of property value size in bytes (or 0 if no
+ value)
+ * 32-bit value of offset in string block of property name
+ * property value data if any
+ * [align gap to next 4 bytes boundary]
+ * [child nodes if any]
+ * token OF_DT_END_NODE (that is 0x00000002)
+
+So the node content can be summarized as a start token, a full path,
+a list of properties, a list of child nodes, and an end token. Every
+child node is a full node structure itself as defined above.
+
+NOTE: The above definition requires that all property definitions for
+a particular node MUST precede any subnode definitions for that node.
+Although the structure would not be ambiguous if properties and
+subnodes were intermingled, the kernel parser requires that the
+properties come first (up until at least 2.6.22). Any tools
+manipulating a flattened tree must take care to preserve this
+constraint.
+
+4) Device tree "strings" block
+
+In order to save space, property names, which are generally redundant,
+are stored separately in the "strings" block. This block is simply the
+whole bunch of zero terminated strings for all property names
+concatenated together. The device-tree property definitions in the
+structure block will contain offset values from the beginning of the
+strings block.
--
1.5.0.3
^ permalink raw reply related
* [PATCH 1/2] Kernel: Move all technical descriptons of the Device Tree Complier
From: Jon Loeliger @ 2007-07-11 21:45 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: Jon Loeliger
From: Jon Loeliger <jdl@freescale.com>
and its formats, command lines, descriptions, etc,
over to the Device Tree Compiler repositories now.
A corresponding patch adding these sections to the DTC
repository has been submitted to that repository as well.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 519 +-------------------------
1 files changed, 18 insertions(+), 501 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 0c24348..73ba544 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -15,13 +15,7 @@ Table of Contents
1) Entry point for arch/powerpc
2) Board support
- II - The DT block format
- 1) Header
- 2) Device tree generalities
- 3) Device tree "structure" block
- 4) Device tree "strings" block
-
- III - Required content of the device tree
+ II - Required content of the device tree
1) Note about cells and address representation
2) Note about "compatible" properties
3) Note about "name" properties
@@ -34,11 +28,9 @@ Table of Contents
e) The /chosen node
f) the /soc<SOCname> node
- IV - "dtc", the device tree compiler
-
- V - Recommendations for a bootloader
+ III - Recommendations for a bootloader
- VI - System-on-a-chip devices and nodes
+ IV - System-on-a-chip devices and nodes
1) Defining child nodes of an SOC
2) Representing devices without a current OF specification
a) MDIO IO device
@@ -53,7 +45,7 @@ Table of Contents
j) Flash chip nodes
k) Global Utilities Block
- VII - Specifying interrupt information for devices
+ V - Specifying interrupt information for devices
1) interrupts property
2) interrupt-parent property
3) OpenPIC Interrupt Controllers
@@ -109,6 +101,13 @@ Revision Information
- Added chapter VI
+ July 11, 2007: Rev 0.6
+ - Removed Device Tree Compiler specifications
+ from this document and relocated them to the
+ Device Tree Repository instead.
+
+
+
ToDo:
- Add some definitions of interrupt tree (simple/complex)
- Add some definitions for PCI host bridges
@@ -279,374 +278,8 @@ point to setup_32.c
your platform should implement.
-II - The DT block format
-========================
-
-
-This chapter defines the actual format of the flattened device-tree
-passed to the kernel. The actual content of it and kernel requirements
-are described later. You can find example of code manipulating that
-format in various places, including arch/powerpc/kernel/prom_init.c
-which will generate a flattened device-tree from the Open Firmware
-representation, or the fs2dt utility which is part of the kexec tools
-which will generate one from a filesystem representation. It is
-expected that a bootloader like uboot provides a bit more support,
-that will be discussed later as well.
-
-Note: The block has to be in main memory. It has to be accessible in
-both real mode and virtual mode with no mapping other than main
-memory. If you are writing a simple flash bootloader, it should copy
-the block to RAM before passing it to the kernel.
-
-
-1) Header
----------
-
- The kernel is entered with r3 pointing to an area of memory that is
- roughly described in include/asm-powerpc/prom.h by the structure
- boot_param_header:
-
-struct boot_param_header {
- u32 magic; /* magic word OF_DT_HEADER */
- u32 totalsize; /* total size of DT block */
- u32 off_dt_struct; /* offset to structure */
- u32 off_dt_strings; /* offset to strings */
- u32 off_mem_rsvmap; /* offset to memory reserve map
- */
- u32 version; /* format version */
- u32 last_comp_version; /* last compatible version */
-
- /* version 2 fields below */
- u32 boot_cpuid_phys; /* Which physical CPU id we're
- booting on */
- /* version 3 fields below */
- u32 size_dt_strings; /* size of the strings block */
-
- /* version 17 fields below */
- u32 size_dt_struct; /* size of the DT structure block */
-};
-
- Along with the constants:
-
-/* Definitions used by the flattened device tree */
-#define OF_DT_HEADER 0xd00dfeed /* 4: version,
- 4: total size */
-#define OF_DT_BEGIN_NODE 0x1 /* Start node: full name
- */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off,
- size, content */
-#define OF_DT_END 0x9
-
- All values in this header are in big endian format, the various
- fields in this header are defined more precisely below. All
- "offset" values are in bytes from the start of the header; that is
- from the value of r3.
-
- - magic
-
- This is a magic value that "marks" the beginning of the
- device-tree block header. It contains the value 0xd00dfeed and is
- defined by the constant OF_DT_HEADER
-
- - totalsize
-
- This is the total size of the DT block including the header. The
- "DT" block should enclose all data structures defined in this
- chapter (who are pointed to by offsets in this header). That is,
- the device-tree structure, strings, and the memory reserve map.
-
- - off_dt_struct
-
- This is an offset from the beginning of the header to the start
- of the "structure" part the device tree. (see 2) device tree)
-
- - off_dt_strings
-
- This is an offset from the beginning of the header to the start
- of the "strings" part of the device-tree
-
- - off_mem_rsvmap
-
- This is an offset from the beginning of the header to the start
- of the reserved memory map. This map is a list of pairs of 64-
- bit integers. Each pair is a physical address and a size. The
- list is terminated by an entry of size 0. This map provides the
- kernel with a list of physical memory areas that are "reserved"
- and thus not to be used for memory allocations, especially during
- early initialization. The kernel needs to allocate memory during
- boot for things like un-flattening the device-tree, allocating an
- MMU hash table, etc... Those allocations must be done in such a
- way to avoid overriding critical things like, on Open Firmware
- capable machines, the RTAS instance, or on some pSeries, the TCE
- tables used for the iommu. Typically, the reserve map should
- contain _at least_ this DT block itself (header,total_size). If
- you are passing an initrd to the kernel, you should reserve it as
- well. You do not need to reserve the kernel image itself. The map
- should be 64-bit aligned.
-
- - version
-
- This is the version of this structure. Version 1 stops
- here. Version 2 adds an additional field boot_cpuid_phys.
- Version 3 adds the size of the strings block, allowing the kernel
- to reallocate it easily at boot and free up the unused flattened
- structure after expansion. Version 16 introduces a new more
- "compact" format for the tree itself that is however not backward
- compatible. Version 17 adds an additional field, size_dt_struct,
- allowing it to be reallocated or moved more easily (this is
- particularly useful for bootloaders which need to make
- adjustments to a device tree based on probed information). You
- should always generate a structure of the highest version defined
- at the time of your implementation. Currently that is version 17,
- unless you explicitly aim at being backward compatible.
-
- - last_comp_version
-
- Last compatible version. This indicates down to what version of
- the DT block you are backward compatible. For example, version 2
- is backward compatible with version 1 (that is, a kernel build
- for version 1 will be able to boot with a version 2 format). You
- should put a 1 in this field if you generate a device tree of
- version 1 to 3, or 16 if you generate a tree of version 16 or 17
- using the new unit name format.
-
- - boot_cpuid_phys
-
- This field only exist on version 2 headers. It indicate which
- physical CPU ID is calling the kernel entry point. This is used,
- among others, by kexec. If you are on an SMP system, this value
- should match the content of the "reg" property of the CPU node in
- the device-tree corresponding to the CPU calling the kernel entry
- point (see further chapters for more informations on the required
- device-tree contents)
-
- - size_dt_strings
-
- This field only exists on version 3 and later headers. It
- gives the size of the "strings" section of the device tree (which
- starts at the offset given by off_dt_strings).
-
- - size_dt_struct
-
- This field only exists on version 17 and later headers. It gives
- the size of the "structure" section of the device tree (which
- starts at the offset given by off_dt_struct).
-
- So the typical layout of a DT block (though the various parts don't
- need to be in that order) looks like this (addresses go from top to
- bottom):
-
-
- ------------------------------
- r3 -> | struct boot_param_header |
- ------------------------------
- | (alignment gap) (*) |
- ------------------------------
- | memory reserve map |
- ------------------------------
- | (alignment gap) |
- ------------------------------
- | |
- | device-tree structure |
- | |
- ------------------------------
- | (alignment gap) |
- ------------------------------
- | |
- | device-tree strings |
- | |
- -----> ------------------------------
- |
- |
- --- (r3 + totalsize)
-
- (*) The alignment gaps are not necessarily present; their presence
- and size are dependent on the various alignment requirements of
- the individual data blocks.
-
-
-2) Device tree generalities
----------------------------
-
-This device-tree itself is separated in two different blocks, a
-structure block and a strings block. Both need to be aligned to a 4
-byte boundary.
-
-First, let's quickly describe the device-tree concept before detailing
-the storage format. This chapter does _not_ describe the detail of the
-required types of nodes & properties for the kernel, this is done
-later in chapter III.
-
-The device-tree layout is strongly inherited from the definition of
-the Open Firmware IEEE 1275 device-tree. It's basically a tree of
-nodes, each node having two or more named properties. A property can
-have a value or not.
-
-It is a tree, so each node has one and only one parent except for the
-root node who has no parent.
-
-A node has 2 names. The actual node name is generally contained in a
-property of type "name" in the node property list whose value is a
-zero terminated string and is mandatory for version 1 to 3 of the
-format definition (as it is in Open Firmware). Version 16 makes it
-optional as it can generate it from the unit name defined below.
-
-There is also a "unit name" that is used to differentiate nodes with
-the same name at the same level, it is usually made of the node
-names, the "@" sign, and a "unit address", which definition is
-specific to the bus type the node sits on.
-
-The unit name doesn't exist as a property per-se but is included in
-the device-tree structure. It is typically used to represent "path" in
-the device-tree. More details about the actual format of these will be
-below.
-
-The kernel powerpc generic code does not make any formal use of the
-unit address (though some board support code may do) so the only real
-requirement here for the unit address is to ensure uniqueness of
-the node unit name at a given level of the tree. Nodes with no notion
-of address and no possible sibling of the same name (like /memory or
-/cpus) may omit the unit address in the context of this specification,
-or use the "@0" default unit address. The unit name is used to define
-a node "full path", which is the concatenation of all parent node
-unit names separated with "/".
-
-The root node doesn't have a defined name, and isn't required to have
-a name property either if you are using version 3 or earlier of the
-format. It also has no unit address (no @ symbol followed by a unit
-address). The root node unit name is thus an empty string. The full
-path to the root node is "/".
-
-Every node which actually represents an actual device (that is, a node
-which isn't only a virtual "container" for more nodes, like "/cpus"
-is) is also required to have a "device_type" property indicating the
-type of node .
-
-Finally, every node that can be referenced from a property in another
-node is required to have a "linux,phandle" property. Real open
-firmware implementations provide a unique "phandle" value for every
-node that the "prom_init()" trampoline code turns into
-"linux,phandle" properties. However, this is made optional if the
-flattened device tree is used directly. An example of a node
-referencing another node via "phandle" is when laying out the
-interrupt tree which will be described in a further version of this
-document.
-
-This "linux, phandle" property is a 32-bit value that uniquely
-identifies a node. You are free to use whatever values or system of
-values, internal pointers, or whatever to generate these, the only
-requirement is that every node for which you provide that property has
-a unique value for it.
-
-Here is an example of a simple device-tree. In this example, an "o"
-designates a node followed by the node unit name. Properties are
-presented with their name followed by their content. "content"
-represents an ASCII string (zero terminated) value, while <content>
-represents a 32-bit hexadecimal value. The various nodes in this
-example will be discussed in a later chapter. At this point, it is
-only meant to give you a idea of what a device-tree looks like. I have
-purposefully kept the "name" and "linux,phandle" properties which
-aren't necessary in order to give you a better idea of what the tree
-looks like in practice.
-
- / o device-tree
- |- name = "device-tree"
- |- model = "MyBoardName"
- |- compatible = "MyBoardFamilyName"
- |- #address-cells = <2>
- |- #size-cells = <2>
- |- linux,phandle = <0>
- |
- o cpus
- | | - name = "cpus"
- | | - linux,phandle = <1>
- | | - #address-cells = <1>
- | | - #size-cells = <0>
- | |
- | o PowerPC,970@0
- | |- name = "PowerPC,970"
- | |- device_type = "cpu"
- | |- reg = <0>
- | |- clock-frequency = <5f5e1000>
- | |- 64-bit
- | |- linux,phandle = <2>
- |
- o memory@0
- | |- name = "memory"
- | |- device_type = "memory"
- | |- reg = <00000000 00000000 00000000 20000000>
- | |- linux,phandle = <3>
- |
- o chosen
- |- name = "chosen"
- |- bootargs = "root=/dev/sda2"
- |- linux,phandle = <4>
-
-This tree is almost a minimal tree. It pretty much contains the
-minimal set of required nodes and properties to boot a linux kernel;
-that is, some basic model informations at the root, the CPUs, and the
-physical memory layout. It also includes misc information passed
-through /chosen, like in this example, the platform type (mandatory)
-and the kernel command line arguments (optional).
-
-The /cpus/PowerPC,970@0/64-bit property is an example of a
-property without a value. All other properties have a value. The
-significance of the #address-cells and #size-cells properties will be
-explained in chapter IV which defines precisely the required nodes and
-properties and their content.
-
-
-3) Device tree "structure" block
-
-The structure of the device tree is a linearized tree structure. The
-"OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
-ends that node definition. Child nodes are simply defined before
-"OF_DT_END_NODE" (that is nodes within the node). A 'token' is a 32
-bit value. The tree has to be "finished" with a OF_DT_END token
-
-Here's the basic structure of a single node:
-
- * token OF_DT_BEGIN_NODE (that is 0x00000001)
- * for version 1 to 3, this is the node full path as a zero
- terminated string, starting with "/". For version 16 and later,
- this is the node unit name only (or an empty string for the
- root node)
- * [align gap to next 4 bytes boundary]
- * for each property:
- * token OF_DT_PROP (that is 0x00000003)
- * 32-bit value of property value size in bytes (or 0 if no
- value)
- * 32-bit value of offset in string block of property name
- * property value data if any
- * [align gap to next 4 bytes boundary]
- * [child nodes if any]
- * token OF_DT_END_NODE (that is 0x00000002)
-
-So the node content can be summarized as a start token, a full path,
-a list of properties, a list of child nodes, and an end token. Every
-child node is a full node structure itself as defined above.
-
-NOTE: The above definition requires that all property definitions for
-a particular node MUST precede any subnode definitions for that node.
-Although the structure would not be ambiguous if properties and
-subnodes were intermingled, the kernel parser requires that the
-properties come first (up until at least 2.6.22). Any tools
-manipulating a flattened tree must take care to preserve this
-constraint.
-
-4) Device tree "strings" block
-
-In order to save space, property names, which are generally redundant,
-are stored separately in the "strings" block. This block is simply the
-whole bunch of zero terminated strings for all property names
-concatenated together. The device-tree property definitions in the
-structure block will contain offset values from the beginning of the
-strings block.
-
-
-III - Required content of the device tree
-=========================================
+II - Required content of the device tree
+========================================
WARNING: All "linux,*" properties defined in this document apply only
to a flattened device-tree. If your platform uses a real
@@ -1003,124 +636,8 @@ address which can extend beyond that limit.
-IV - "dtc", the device tree compiler
-====================================
-
-
-dtc source code can be found at
-<http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
-
-WARNING: This version is still in early development stage; the
-resulting device-tree "blobs" have not yet been validated with the
-kernel. The current generated bloc lacks a useful reserve map (it will
-be fixed to generate an empty one, it's up to the bootloader to fill
-it up) among others. The error handling needs work, bugs are lurking,
-etc...
-
-dtc basically takes a device-tree in a given format and outputs a
-device-tree in another format. The currently supported formats are:
-
- Input formats:
- -------------
-
- - "dtb": "blob" format, that is a flattened device-tree block
- with
- header all in a binary blob.
- - "dts": "source" format. This is a text file containing a
- "source" for a device-tree. The format is defined later in this
- chapter.
- - "fs" format. This is a representation equivalent to the
- output of /proc/device-tree, that is nodes are directories and
- properties are files
-
- Output formats:
- ---------------
-
- - "dtb": "blob" format
- - "dts": "source" format
- - "asm": assembly language file. This is a file that can be
- sourced by gas to generate a device-tree "blob". That file can
- then simply be added to your Makefile. Additionally, the
- assembly file exports some symbols that can be used.
-
-
-The syntax of the dtc tool is
-
- dtc [-I <input-format>] [-O <output-format>]
- [-o output-filename] [-V output_version] input_filename
-
-
-The "output_version" defines what version of the "blob" format will be
-generated. Supported versions are 1,2,3 and 16. The default is
-currently version 3 but that may change in the future to version 16.
-
-Additionally, dtc performs various sanity checks on the tree, like the
-uniqueness of linux, phandle properties, validity of strings, etc...
-
-The format of the .dts "source" file is "C" like, supports C and C++
-style comments.
-
-/ {
-}
-
-The above is the "device-tree" definition. It's the only statement
-supported currently at the toplevel.
-
-/ {
- property1 = "string_value"; /* define a property containing a 0
- * terminated string
- */
-
- property2 = <1234abcd>; /* define a property containing a
- * numerical 32-bit value (hexadecimal)
- */
-
- property3 = <12345678 12345678 deadbeef>;
- /* define a property containing 3
- * numerical 32-bit values (cells) in
- * hexadecimal
- */
- property4 = [0a 0b 0c 0d de ea ad be ef];
- /* define a property whose content is
- * an arbitrary array of bytes
- */
-
- childnode@addresss { /* define a child node named "childnode"
- * whose unit name is "childnode at
- * address"
- */
-
- childprop = "hello\n"; /* define a property "childprop" of
- * childnode (in this case, a string)
- */
- };
-};
-
-Nodes can contain other nodes etc... thus defining the hierarchical
-structure of the tree.
-
-Strings support common escape sequences from C: "\n", "\t", "\r",
-"\(octal value)", "\x(hex value)".
-
-It is also suggested that you pipe your source file through cpp (gcc
-preprocessor) so you can use #include's, #define for constants, etc...
-
-Finally, various options are planned but not yet implemented, like
-automatic generation of phandles, labels (exported to the asm file so
-you can point to a property content and change it easily from whatever
-you link the device-tree with), label or path instead of numeric value
-in some cells to "point" to a node (replaced by a phandle at compile
-time), export of reserve map address to the asm file, ability to
-specify reserve map content at compile time, etc...
-
-We may provide a .h include file with common definitions of that
-proves useful for some properties (like building PCI properties or
-interrupt maps) though it may be better to add a notion of struct
-definitions to the compiler...
-
-
-V - Recommendations for a bootloader
-====================================
+III - Recommendations for a bootloader
+======================================
Here are some various ideas/recommendations that have been proposed
@@ -1151,7 +668,7 @@ while all this has been defined and implemented.
-VI - System-on-a-chip devices and nodes
+IV - System-on-a-chip devices and nodes
=======================================
Many companies are now starting to develop system-on-a-chip
@@ -1820,8 +1337,8 @@ platforms are moved over to use the flattened-device-tree model.
More devices will be defined as this spec matures.
-VII - Specifying interrupt information for devices
-===================================================
+V - Specifying interrupt information for devices
+=================================================
The device tree represents the busses and devices of a hardware
system in a form similar to the physical bus topology of the
--
1.5.0.3
^ permalink raw reply related
* [PATCH 0/2] Move DTC Technical specs out of b-w-o.txt into DTC Repo
From: Jon Loeliger @ 2007-07-11 21:45 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: Jon Loeliger
Folks,
Here are two patches, one to the kernel, the other to
the DTC repo, that moves the technical description
portions of the booting-without-of.txt documentation
out of the kernel and into the DTC repository.
Thanks,
jdl
^ permalink raw reply
* [PATCH] Setup default eth addr in embed_config for Xilinx Virtex platforms
From: Grant Likely @ 2007-07-11 20:38 UTC (permalink / raw)
To: khollan, Kevin Holland, linuxppc-embedded, paulus, galak
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/ppc/boot/simple/embed_config.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index 46676d2..07f1bb5 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -752,7 +752,9 @@ embed_config(bd_t ** bdp)
static const unsigned long congruence_classes = 256;
unsigned long addr;
unsigned long dccr;
+ uint8_t* cp;
bd_t *bd;
+ int i;
/*
* Invalidate the data cache if the data cache is turned off.
@@ -778,6 +780,12 @@ embed_config(bd_t ** bdp)
bd->bi_intfreq = XPAR_CORE_CLOCK_FREQ_HZ;
bd->bi_busfreq = XPAR_PLB_CLOCK_FREQ_HZ;
bd->bi_pci_busfreq = XPAR_PCI_0_CLOCK_FREQ_HZ;
+
+ /* Copy the default ethernet address */
+ cp = (u_char *)def_enet_addr;
+ for (i=0; i<6; i++)
+ bd->bi_enetaddr[i] = *cp++;
+
timebase_period_ns = 1000000000 / bd->bi_tbfreq;
}
#endif /* CONFIG_XILINX_VIRTEX */
^ permalink raw reply related
* Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
From: Segher Boessenkool @ 2007-07-11 21:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707112233.51899.arnd@arndb.de>
> Which systems in particular should allow CONFIG_TAU? Is there a more
> specific dependency than (6xx && !(82xx || 83xx || 86xx || 52xx))?
7xx and 7xxx CPUs (G3 and G4). Nothing earlier (according to
the IEEE article introducing the TAU), maybe some later units
have it though (but I think they have incompatible things with
a similar function).
TAU is broken on many CPU models btw (it works, just gives
back nonsense results).
Segher
^ permalink raw reply
* Re: [RFC][PATCH 3/8] 4xx MMU
From: Josh Boyer @ 2007-07-11 21:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200707112256.38312.arnd@arndb.de>
On Wed, 2007-07-11 at 22:56 +0200, Arnd Bergmann wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > +#elif defined(CONFIG_40x)
> > +/* 40x-style software loaded TLB */
> > +# include <asm/mmu-4xx.h>
> > #elif defined(CONFIG_44x)
> > /* 44x-style software loaded TLB */
> > # include <asm/mmu-44x.h>
>
> If you call it mmu-4xx, shouldn't it be used
> for 44x as well? I would think this either
> should be
No. I was following the established convention that's been there for
years. Which sucks I suppose for people not familiar with 40x/44x.
That would be a lot of stuff to change though... e.g.:
arch/powerpc/platforms/4xx -> arch/powerpc/platforms/40x
arch/powerpc/kernel/head_4xx.S -> arch/powerpc/platforms/head_40x.S
etc. I'd need a git tree to do that cleanly. I've been toying with
creating one for powerpc4xx anyway so I might do that.
>
> > +#elif defined(CONFIG_4xx)
> > +/* 40x-style software loaded TLB */
> > +# include <asm/mmu-4xx.h>
> > -#elif defined(CONFIG_44x)
> > -/* 44x-style software loaded TLB */
> > -# include <asm/mmu-44x.h>
>
> or
>
> > +#elif defined(CONFIG_40x)
> > +/* 40x-style software loaded TLB */
> > +# include <asm/mmu-40x.h>
> > #elif defined(CONFIG_44x)
> > /* 44x-style software loaded TLB */
> > # include <asm/mmu-44x.h>
I'll probably change it to this. Will look a bit odd, given that C file
is arch/powerpc/mm/4xx_mmu.c.
> Is it actually feasible to get to a point where
> you can build a kernel that boots on both
> 40x and 44x, or is it just too different?
The MMUs are entirely different. 40x has real-mode and is 32-bit. 44x
is always virtual and is 36-bit.
josh
^ permalink raw reply
* Re: [RFC][PATCH 5/8] Fix 4xx build
From: Arnd Bergmann @ 2007-07-11 21:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184162326.32199.63.camel@weaponx.rchland.ibm.com>
On Wednesday 11 July 2007, Josh Boyer wrote:
> -#if defined(CONFIG_8xx) || defined(CONFIG_40x)
> +#if defined(CONFIG_8xx)
> =A0EXPORT_SYMBOL(__res);
> =A0#endif
Actually, __res also isn't defined on 8xx, so the export
should probably go away entirely.=20
Arnd <><
^ permalink raw reply
* Re: [RFC][PATCH 3/8] 4xx MMU
From: Arnd Bergmann @ 2007-07-11 20:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184162179.32199.58.camel@weaponx.rchland.ibm.com>
On Wednesday 11 July 2007, Josh Boyer wrote:
> +#elif defined(CONFIG_40x)
> +/* 40x-style software loaded TLB */
> +# =A0include <asm/mmu-4xx.h>
> =A0#elif defined(CONFIG_44x)
> =A0/* 44x-style software loaded TLB */
> =A0# =A0include <asm/mmu-44x.h>
If you call it mmu-4xx, shouldn't it be used
for 44x as well? I would think this either
should be
> +#elif defined(CONFIG_4xx)
> +/* 40x-style software loaded TLB */
> +# include <asm/mmu-4xx.h>
> -#elif defined(CONFIG_44x)
> -/* 44x-style software loaded TLB */
> -# include <asm/mmu-44x.h>
or=20
> +#elif defined(CONFIG_40x)
> +/* 40x-style software loaded TLB */
> +# include <asm/mmu-40x.h>
> #elif defined(CONFIG_44x)
> /* 44x-style software loaded TLB */
> # include <asm/mmu-44x.h>
Is it actually feasible to get to a point where
you can build a kernel that boots on both
40x and 44x, or is it just too different?
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: David Brownell @ 2007-07-11 20:52 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev, linux-mips, Christoph Hellwig, Domen Puncer
In-Reply-To: <20070711203454.GC2301@flint.arm.linux.org.uk>
On Wednesday 11 July 2007, Russell King wrote:
>
> IOW, talk to me and I'll talk back. Ignore me and I'll ignore them.
Exactly why I cc'd you ... if folk want any more sharable
cross-platform code than just the clk.h interface, I expect
you'll have useful comments.
- Dave
^ permalink raw reply
* Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
From: Arnd Bergmann @ 2007-07-11 20:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070711153542.GB11516@mag.az.mvista.com>
On Wednesday 11 July 2007, Mark A. Greer wrote:
> > +config CLASSIC32
> > + def_bool y
> > + depends on 6xx && PPC_MULTIPLATFORM
> ^^^^^^^^^^^^^^^^^^^^
> Arnd, is this really what you wanted? With it, none of the embedded
> classics have CLASSIC32 defined which means they don't get TAU or
> ALTIVEC defined which isn't good.
Sorry, this was the result of a wrong patch reordering. In my initial
patch set I ended up with 6xx == CLASSIC32 and PPC_MULTIPLATFORM=y,
but then I backed out a few patches in the middle.
I guess the best is to do another patch that moves PPC_EMBEDDED6xx into
PPC_MULTIPLATFORM again and leaves this one as it is.
Alternatively, we could kill CONFIG_CLASSIC32 entirely as it is used
only in a few places. Especially after I resubmit my CPU type selection
patch again, which allows you do it in a more fine grained way.
Which systems in particular should allow CONFIG_TAU? Is there a more
specific dependency than (6xx && !(82xx || 83xx || 86xx || 52xx))?
Arnd <><
^ permalink raw reply
* Re: Resend: [PATCH] oprofile support for Power 5++
From: Olof Johansson @ 2007-07-11 20:51 UTC (permalink / raw)
To: Maynard Johnson; +Cc: willschm, linuxppc-dev, Michael Neuling, mjw
In-Reply-To: <4693FB3C.4060305@us.ibm.com>
On Tue, Jul 10, 2007 at 04:33:48PM -0500, Maynard Johnson wrote:
> Will Schmidt wrote:
>
> > On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
> >
> >>>>Does it make more sense to call this "ppc64/power5+rev3"?
> >>>>
> >>>
> >>>This is a change to support new counter setup for oprofile. It may be the
> >>>same if there is a revision 4 or 5 etc. So since the internal name was ++
> I have no idea if there will be a revision 4, etc, but I'm assuming the
> behavior would be the same as rev 3. So I'm not in favor of changing
The way the cputable patch is now, the rev 4 would match the base revision
anyway. Maybe it makes more sense to make PVR xxxx01xx and xxxx02xx
explicitly match the old power5+, and make everything else match power5++?
I guess it all depends on the chance of IBM doing another major rev of
power5. Given it's current phase of product maturity I suppose it's not
all that likely. Doing it this way saves yet another cputable entry as
well, since it would otherwise mean two added entries instead of one.
-Olof
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: Russell King @ 2007-07-11 20:34 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-mips, Christoph Hellwig, Domen Puncer
In-Reply-To: <200707111002.55119.david-b@pacbell.net>
On Wed, Jul 11, 2007 at 10:02:54AM -0700, David Brownell wrote:
> On Wednesday 11 July 2007, Christoph Hellwig wrote:
> > On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > > Umm, this is about the fifth almost identical implementation of
> > > > the clk_ functions. Please, please put it into common code.
> > > >
> > > > And talk to the mips folks which just got a similar comment from me.
> > >
> > > You mean like a lib/clock.c core, rather than an opsvector?
> >
> > I mean an ops vector and surrounding wrappers. Every architecture
> > is reimplementing their own dispatch table which is rather annoying.
>
> ARM doesn't. :)
>
> But then, nobody expects one kernel to support more than one
> vendor's ARM chips; or usually, more than one generation of
> that vendor's chips. So any dispatch table is specific to
> a given platform, and tuned to its quirks. Not much to share
> between OMAP and AT91, for example, except in some cases maybe
> an arm926ejs block.
And also the information stored within a 'struct clk' is very platform
dependent. In the most basic situation, 'struct clk' may not actually
be a structure, but the clock rate. All functions with the exception of
clk_get() and clk_get_rate() could well be no-ops, clk_get() just returns
the 'struct clk' representing the rate and 'clk_get_rate' returns that
as an integer.
More complex setups might want 'struct clk' to contain the address of a
clock enable register, the bit position to enable that clock source, the
clock rate, a refcount, and so on, all of which would be utterly useless
for a platform which had fixed rate clocks.
> I've not seen a solid proposal for such a thing, and it's not
> clear to me how that would play with with older code (e.g. any
> of the ARM implementations).
If people are implementing their own incompatible changes without reference
to the API they're invalid implementations as far as I'm concerned. If
they can't bothered to lift a finger to even _talk_ to me about their
requirements they just don't have any say concerning any future
developments IMO.
IOW, talk to me and I'll talk back. Ignore me and I'll ignore them.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: DEFINE_IDR() and the layer cache
From: Nathan Lynch @ 2007-07-11 20:29 UTC (permalink / raw)
To: Joachim Fenkes
Cc: linuxppc-dev, Christoph Raisch, Stefan Roscher, linux-kernel,
jim.houston
In-Reply-To: <200707112027.30490.fenkes@de.ibm.com>
Hi Joachim-
Joachim Fenkes wrote:
>
> idr_init(), when called for the first time, sets up the layer
> cache. idr_get_new() and friends expect the cache to exist. Now, what happens
> if the first call to idr_get_new() targets an idr initialized using
> DEFINE_IDR() before idr_init() has been called at least once? Could this
> happen?
unnamed_dev_init() is the first caller of idr_init() and it happens to
be called before the first use of idr_get_new():
[ 0.831907] [<c010615a>] dump_stack+0x16/0x18
[ 0.831945] [<c01c2714>] idr_init+0x3c/0x9c
[ 0.831985] [<c038cab8>] unnamed_dev_init+0xd/0xf
[ 0.832027] [<c037b987>] start_kernel+0x307/0x341
[ 0.832068] [<00000000>] 0x0
[ 0.832149] =======================
[ 0.832881] Mount-cache hash table entries: 512
[ 0.833432] [<c010615a>] dump_stack+0x16/0x18
[ 0.833470] [<c01c298f>] idr_get_new_above_int+0x43/0x222
[ 0.833541] [<c01c2b7b>] idr_get_new+0xd/0x28
[ 0.833605] [<c0169243>] set_anon_super+0x36/0xa0
[ 0.833667] [<c01696be>] sget+0x234/0x2c9
[ 0.833722] [<c016a01e>] get_sb_single+0x24/0x8e
[ 0.833781] [<c01a2468>] sysfs_get_sb+0x1c/0x1e
[ 0.833867] [<c0169b63>] vfs_kern_mount+0x41/0x70
[ 0.833927] [<c0169ba8>] kern_mount+0x16/0x18
[ 0.833984] [<c038e494>] sysfs_init+0x57/0xa5
[ 0.834026] [<c038cfe3>] mnt_init+0xc5/0x1cb
[ 0.834064] [<c038cce8>] vfs_caches_init+0x141/0x152
[ 0.834104] [<c037b996>] start_kernel+0x316/0x341
[ 0.834144] [<00000000>] 0x0
[ 0.834174] =======================
It does seem fragile, though. AFAICT there's no guarantee that a
DEFINE_IDR user couldn't call idr_get_new() before unnamed_dev_init()
runs.
Also, init_id_cache() in idr.c is racy wrt itself. If the first two
uses of idr_init() occur concurrently, the code could attempt to
create idr_layer_cache twice.
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 20:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <46952F11.30005@freescale.com>
>>> What if the mem-to-mem channels were explicitly labelled
>>> fsl,mpc8548-dma-mem-to-mem?
>> Why would you? Why would you put _any_ compatible property in
>> the individual channels, even; they aren't separate devices
>> after all.
>
> They should be. :-)
But they're not, no amount of wishing or trying to discount the
shared ("master") register block will change that.
Segher
^ permalink raw reply
* Re: TEMAC MAC address
From: Grant Likely @ 2007-07-11 20:11 UTC (permalink / raw)
To: Kevin Holland, Linux PPC Linux PPC
In-Reply-To: <3D99384DA1D6124CBE9EE993BAA0E5B70195FDFD@exbe-dak-01.daktronics.lan>
On 7/11/07, Kevin Holland <KHollan@daktronics.com> wrote:
> Grant,
> How do I set the MAC address?
Badly, with an ugly hack. :-)
> When my ML410 board boots its Hardware
> address is set to 0. I looked through the message boards and can't seem
> to find what Im looking for. Thanks for your help.
I set the mac addr with some Virtex specific code in
arch/ppc/boot/simple/embed_config.c.
BTW, Please at least CC: the mailing list when asking questions.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] fix idr_get_new_above id alias bugs
From: Hoang-Nam Nguyen @ 2007-07-11 19:27 UTC (permalink / raw)
To: jim.houston
Cc: linux-kernel, openib-general, Stefan Roscher, linuxppc-dev,
Christoph Raisch, linuxppc-dev-bounces+hnguyen=de.ibm.com,
Andrew Morton, Hoang-Nam Nguyen
In-Reply-To: <1184097931.3020.73.camel@localhost.localdomain>
> With this patch, idr.c should work as advertised allocating id
> values in the range 0...0x7fffffff. Andrew had speculated that
> it should allow the full range 0...0xffffffff to be used. I was
> tempted to make changes to allow this, but it would require changes
> to API, e.g. making the starting id value and the return value
> unsigned.
Hi Jim, thanks much for this patch. It should work fine as far
as I can read. Will give it a try in next couple of days.
Nam
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-07-11 19:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <5790B879-A6F0-4FE7-91FC-9FA812BF8231@kernel.crashing.org>
Segher Boessenkool wrote:
>> What if the mem-to-mem channels were explicitly labelled
>> fsl,mpc8548-dma-mem-to-mem?
>
>
> Why would you? Why would you put _any_ compatible property in
> the individual channels, even; they aren't separate devices
> after all.
They should be. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 19:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <4695298A.6090604@freescale.com>
>>> that if we really wanted to we could describe as a
>>> second reg resource in each channel, combined with a channel-ID
>>> property.
>> You cannot describe one register in two different nodes.
>
> Why not? It's read-only.
Because a register belongs to one, and only one, device
node. There is no such concept as "read-only registers"
in Open Firmware btw. How a device (or a driver for a
device) uses the registers is its own business; OF merely
describes what devices uses what address range.
>>> I'm not inclined to bother, though -- not because we don't
>>> currently use
>>> it, but because I have a hard time seeing anyone needing to use it.
>> Unless you're sure no one ever wants to use it, it should be in
>> the device tree.
>
> There are lots of registers that are used that aren't in the device
> tree. This one's pretty low on the priority list to get added, IMHO.
It is in the original proposed tree already. I see no reason
to take it out.
>>> There is no information in that register that is not the individual
>>> channels' registers.
>> People use it to get the status of all registers at once. I/O reads
>> aren't cheap...
>
> On-chip I/O reads shouldn't be all that slow...
There's a full sync after every I/O read. Anyway, it doesn't
matter; the register is there, why not describe it.
>>> It's by far the simplest way to tell the generic DMA driver "do not
>>> touch". "fsl,mpc8548-dma" says "this is a generic, mem-to-mem
>>> DMA channel".
>> I would expect it to mean "this is the 8548 DMA controller".
>
> What if the mem-to-mem channels were explicitly labelled
> fsl,mpc8548-dma-mem-to-mem?
Why would you? Why would you put _any_ compatible property in
the individual channels, even; they aren't separate devices
after all.
>>> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,
>>> hooked up to an audio codec".
>> So this DMA channel cannot be used for general purpose stuff
>> at all?
>
> I don't know if it *can* or not, though it'd be a pretty unusual
> way of using it. In any case, the device tree should be able to
> handle the case where it can't.
Yes, but also the case where it _can_.
>> Sure, we agree on this. It is prudent to describe in the sound
>> node which DMA channel is associated with the sound thing though,
>> even if this is a SoC and all that. It is just describing the
>> hardware; if your sound driver wants to hardcode the DMA stuff,
>> that's fine with me, but that's no reason to not describe the
>> relation in the device tree.
>
> Sure, I was never saying that there shouldn't be phandle linkage
> from the sound node to the dma channel node. I just don't want the
> mem-to-mem driver to have to go to great lengths to figure out
> whether it owns the channel.
>
> Phandle linkage the other way could work, though; if the channel
> has a phandle set in an attached-device property,
I'm not sure that would cleanly work in all cases, I'll have to
think about it.
> then the mem-to-mem driver leaves it alone.
Yeah that would work. There are much simpler solutions though.
>> I see no reason to pretend the non-mem-to-mem channels are somehow
>> different from the mem-to-mem channels.
>
> But they are different, just like an SCC UART is different from an
> SCC ethernet, even though they both go through the SCC.
The SCC is the same; if there was a node describing just the SCC
part, like we have nodes describing _just_ the DMA channel part
here, it would be the same situation.
Segher
^ permalink raw reply
* ML410 PCI support
From: khollan @ 2007-07-11 19:15 UTC (permalink / raw)
To: linuxppc-embedded
I have two questions:
1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development boards.
I want to get the PCI slots working on my board.
2)How do I set the HwAddr for the TEMAC driver? Im using Grants latest git
tree. My board boots and the HwAddr is set to 00:00:00:00:00:00
Thanks for your help
Kevin
--
View this message in context: http://www.nabble.com/ML410-PCI-support-tf4064052.html#a11547023
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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