* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 21:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <143f0a1c76539260fd41fe953e6d1bdf@kernel.crashing.org>
On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> >>>BTW, IEEE1275 seems to disagree:
> >>
> >>No it doesn't.
> >
> >"...in conventional usage the string begins with the name of the
> >device's
> >manufacturer".
>
> You cut that sentence short here, it continues: "as with the name
> property."
You ignored the next sentence, which addressed exactly that point.
> >Even if you want to quibble about the manner in which the
> >manufacturer is specified, that's quite different from leaving it out.
>
> The text of the standard says that often people start the model
> property contents with an "XYZ,". It doesn't say that is required
> (though it hints it might be a good idea to do so). It doesn't say
> it is okay to just put some arbitrary text there.
It says exactly that. They used so many words like "generally",
"arbitrary", "no standard interpretation", "conventional usage", "might",
"for instance", "manufacturer-dependent", etc. that it's fairly clear
that they're merely providing hints as to how the property might be used.
> >>That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
> >>not "some random string without a comma Adder MPC875".
> >
> >"the text string is arbitrary" and "conventional usage".
>
> It doesn't say that. It says _the format_ is arbitrary, it is
> quite specific about the contents: model name and number.
"A manufacturer-dependent string that *generally* specifies the model
name and number".
Besides, that's what I did specify, plus the manufacturer.
> >That "random string" is more useful for the intended purpose than the
> >first half of a MAC address.
>
> What, an OUI isn't useful for uniquely identifying a manufacturer?
> That's news to me.
Not for human consumption.
> >>i.e., it is machine readable.
> >
> >No, it *can* be machine usable in certain circumstances. I'm 100% sure
> >that there is no code out there that cares what's in the model field of
> >this board's device tree,
>
> Why would that matter?
It matters because machine consumption is obviously not how this
particular model property is being used.
> >other than to pass it to /proc/cpuinfo (i.e.
> >human consumption).
>
> It's not my fault that /proc/cpuinfo uses strings that are meant for
> machine consumption by directly showing them to the user, without some
> level of massaging by the platform code first. It definitely is no
> argument for doing bad things in your device tree now, instead of
> fixing the kernel code.
I am not going to add some completely useless layer of indirection
because it suits your odd interpretation of the standard. The
/proc/cpuinfo output of the model property is useful. Descriptive model
properties are useful. Deal with it.
> Anyway, I've said enough about this, I think I've made my point --
> and this is very minor stuff after all.
Whatever, you brought it up.
-Scott
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: Wolfgang Denk @ 2007-09-06 23:30 UTC (permalink / raw)
To: David Hawkins; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <46E05FFD.3020605@ovro.caltech.edu>
In message <46E05FFD.3020605@ovro.caltech.edu> you wrote:
>
> Freescale's technical (design) support is great, and they
> (the software developers; Kim, Timur, etc) are actively
> maintaining/contributing to git trees for u-boot and Linux.
> If you can change processors, I'd recommend any Freescale
> part over an AMCC part.
But then, a lot of people with in-depth experience with AMCC
processors hang out on the lists and on IRC, too. AMCC is pretty well
supported at least as far as U-Boot and Linux (and the ELDK) go.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-06 23:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <20070906233021.59D1C247AF@gemini.denx.de>
Hi Wolfgang,
>> Freescale's technical (design) support is great, and they
>> (the software developers; Kim, Timur, etc) are actively
>> maintaining/contributing to git trees for u-boot and Linux.
>> If you can change processors, I'd recommend any Freescale
>> part over an AMCC part.
>
> But then, a lot of people with in-depth experience with AMCC
> processors hang out on the lists and on IRC, too. AMCC is pretty well
> supported at least as far as U-Boot and Linux (and the ELDK) go.
Thats good to know.
I was just trying to relay my experience with the two
company's support and with two comparable processors
(440EP vs MPC8349EA).
The nice thing about this group, and open-source in
general, is the 'open' part, everyone can share their
experiences :)
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Olof Johansson @ 2007-09-06 23:45 UTC (permalink / raw)
To: Scott Wood, Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20070906213023.GA6399@ld0162-tx32.am.freescale.net>
On Thu, Sep 06, 2007 at 04:30:23PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> > >>>BTW, IEEE1275 seems to disagree:
> > >>
> > >>No it doesn't.
> > >
> > >"...in conventional usage the string begins with the name of the
> > >device's
> > >manufacturer".
> >
> > You cut that sentence short here, it continues: "as with the name
> > property."
>
> You ignored the next sentence, which addressed exactly that point.
Give it up guys.
Segher, can you please stop riding everybody for every single little
detail in the device trees. Noone will be hurt by the fact that a company
name is part of a machine model string.
This is just a huge productivity sink. How about spending the time
(and bandwidth) on something useful instead?
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: setup_64 comment cleanup.
From: Michael Ellerman @ 2007-09-06 23:54 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070906174729.GC21800@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
On Thu, 2007-09-06 at 12:47 -0500, Linas Vepstas wrote:
> Gramatical corrections to comments.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
>
> arch/powerpc/kernel/prom.c | 8 +++++---
> arch/powerpc/kernel/setup_64.c | 6 +++---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> Index: linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/kernel/setup_64.c 2007-09-04 17:29:36.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c 2007-09-05 14:12:23.000000000 -0500
> @@ -181,9 +181,9 @@ void __init early_setup(unsigned long dt
> DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
>
> /*
> - * Do early initializations using the flattened device
> - * tree, like retreiving the physical memory map or
> - * calculating/retreiving the hash table size
> + * Do early initialization using the flattened device
> + * tree, such as retrieving the physical memory map or
> + * calculating/retrieving the hash table size.
> */
> early_init_devtree(__va(dt_ptr));
That's a little pedantic ..
> Index: linux-2.6.22-git2/arch/powerpc/kernel/prom.c
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom.c 2007-09-05 14:23:06.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/kernel/prom.c 2007-09-05 14:24:49.000000000 -0500
> @@ -433,9 +433,11 @@ static int __init early_parse_mem(char *
> }
> early_param("mem", early_parse_mem);
>
> -/*
> - * The device tree may be allocated below our memory limit, or inside the
> - * crash kernel region for kdump. If so, move it out now.
> +/**
> + * move_device_tree - move tree to an unused area, if needed.
> + *
> + * The device tree may be allocated beyond our memory limit, or inside the
> + * crash kernel region for kdump. If so, move it out of the way.
> */
> static void move_device_tree(void)
.. but that looks good. Although it's a semantic change, not just
grammatical as your changelog says.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-07 0:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <22dc6fa3382b591fe721c1b9dee88097@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > That looks totally bogus. Unlike Segher, I think there are a few
> > cases where overlapping reg and ranges can make sense
>
> That's not unlike me -- I may have lower tolerance for it though :-)
I see. Can't imagine how I got another impression... :-p
: Date: Thu, 19 Jul 2007 17:51:17 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
...
: "reg" and "ranges" overlap, that can't be right.
: Date: Tue, 7 Aug 2007 18:51:04 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
...
: > To be honest this looks rather to me like another case where having
: > overlapping 'reg' and 'ranges' would actually make sense.
:
: It never makes sense. You should give the "master" device
: the full "reg" range it covers, and have it define its own
...
> > (PCI bridges
> > where config space is accessed indirectly via MMIO registers which lie
> > in the legacy ISA IO space is an example).
>
> That's a good example yes.
>
> > But this doesn't look like
> > such a case - it just looks like whoever did the device tree
> > misunderstood the distinction between reg and ranges.
>
> Indeed.
>
> >>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >>> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >>> property, but the PHB registers used to access it should be shown
> >>> in the "reg" property. It could be a simple linear window (it
> >>> sounds like it is here?), but it could for example also be
> >>> implemented
> >>> via an address/data register pair.
> >
> > Err... huh? The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding. When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
>
> Sure, it can be encoded like that. But does it make sense?
> You cannot use legacy I/O space as normal memory space.
Well, no, but you can't use *any* MMIO space as normal memory space,
and that's handled routinely by 'ranges'.
> On an arch like x86, where "I/O addresses" exist on the system
> bus as well, it would make sense, since you can translate I/O
> addresses to I/O addresses that way (except on x86 even it cannot
> be done either, since I/O addresses cannot be encoded on the root
> bus -- at least not in existing device trees. There is no official
> x86 binding yet though).
What!? This is nuts, Segher. Why should the binding have to define
some bridge-specific way of encoding the legacy I/O information, when
the PCI-binding's address encoding plus 'ranges' provides a perfectly
unambiguous way of doing so. *And* it makes the normal semantics of
ranges do just the right thing for a subordinate PCI<->ISA bridge.
> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.
>
> But yes, you _can_ use "ranges" for this purpose on PHBs where
> legacy I/O is linearly mapped. It just doesn't make much sense.
> The binding for your specific PHB should tell you what to do.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-07 0:21 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3acb0846724373a8f9edcf4650cc5455@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:36:30PM +0200, Segher Boessenkool wrote:
[snip]
> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "reg" property. It could be a simple linear window (it
> >> sounds like it is here?), but it could for example also be implemented
> >> via an address/data register pair.
> > Yes, it is a simple linear address window. I'll remove its address
> > range
> > from the reg property.
>
> No, please remove it from the "ranges" property, instead.
No, don't. Removing it from reg is just fine.
> >> The order of the "reg" entries depends on the exact model of PCI
> >> bridge, so a device binding for it has to be written.
> > Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
> > should
> > be enough to check for the board type, but a compatible property
> > doesn't
> > hurt.
>
> Please always use "compatible" to probe any devices.
Do do that, though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 03/10] bootwrapper: flatdevtree fixes
From: David Gibson @ 2007-09-07 0:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192104.GC32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:04PM -0500, Scott Wood wrote:
> 1. ft_create_node was returning the internal pointer rather than a phandle.
> 2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
> rather than as the root of the tree. The old, absolute ft_find_device
> is removed, and the relative version is renamed to ft_find_device().
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Although I'm getting really close to obsoleting flatdevtree.c
anyway...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 04/10] bootwrapper: Add strtoull().
From: David Gibson @ 2007-09-07 0:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192110.GD32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:10PM -0500, Scott Wood wrote:
> This will be needed by PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 06/10] bootwrapper: Move strncmp() from flatdevtree_env.h to string.S/string.h.
From: David Gibson @ 2007-09-07 0:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192114.GF32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:14PM -0500, Scott Wood wrote:
> It will be needed for PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I still have a patch that already does this, plus strchr() as well,
pending...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 05/10] bootwrapper: Add get_path().
From: David Gibson @ 2007-09-07 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192112.GE32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:12PM -0500, Scott Wood wrote:
> This will be used by the PlanetCore firmware support to construct
> a linux,stdout-path from the serial node that it finds.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Although I'm planning to obsolete it RSN..
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 09/10] bootwrapper: Only print MAC addresses when the node is actually present.
From: David Gibson @ 2007-09-07 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192118.GI32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:18PM -0500, Scott Wood wrote:
> Some firmwares (such as PlanetCore) only provide a base MAC address, and
> expect the kernel to set certain bits to generate the addresses for the
> other ports. As such, MAC addresses are generated that may not correspond
> to actual hardware.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 10/10] bootwrapper: Add fsl_get_immr() and 8xx/pq2 clock functions.
From: David Gibson @ 2007-09-07 0:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192119.GJ32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:19PM -0500, Scott Wood wrote:
> fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
>
> mpc885_get_clock() transforms a crystal frequency into a system frequency
> according to the PLL register settings.
>
> pq2_get_clocks() does the same as the above for the PowerQUICC II,
> except that it produces several different clocks.
>
> The mpc8xx/pq2 set_clocks() functions modify common properties in
> the device tree based on the given clock data.
>
> The mpc885/pq2 fixup_clocks() functions call get_clocks(), and
> pass the results to set_clocks().
Uh... doesn't this need to go in the series *before* the patch that
uses fsl_get_immr() for the pq2 code..?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: David Gibson @ 2007-09-07 0:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192116.GH32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:16PM -0500, Scott Wood wrote:
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> The device tree must have labels on /#address-cells, the timebase
> frequency, and the memory size.
Hrm... the actual contents of this patch are less about producing an
unheadered binary image than they are about introducing the "raw"
platform. I don't mind the idea of a "raw" platform (although I'm not
sure I like that name for it), but the patch comment needs work.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 07/10] bootwrapper: Add PlanetCore firmware support.
From: David Gibson @ 2007-09-07 1:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192115.GG32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:15PM -0500, Scott Wood wrote:
> This is a library that board code can use to extract information from the
> PlanetCore configuration keys. PlanetCore is used on various boards from
> Embedded Planet.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> +void planetcore_set_mac_addrs(const char *table)
> +{
> + char addr[4][6];
> + u64 int_addr;
> + int i, j;
> +
> + if (!planetcore_get_hex(table, PLANETCORE_KEY_MAC_ADDR, &int_addr))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + u64 this_dev_addr = int_addr | mac_table[i];
> +
> + for (j = 5; j >= 0; j--) {
> + addr[i][j] = this_dev_addr & 0xff;
> + this_dev_addr >>= 8;
> + }
> + }
> +
> + dt_fixup_mac_addresses(addr[0], addr[1], addr[2], addr[3]);
> +}
It seems a bit silly to loop generating the MAC addresses, then loop
again assigning them to the device nodes. Better, I think, to extract
the loop innards from dt_fixup_mac_addresses(), taking the
network-index as a parameter, then call that from within your loop
here.
--
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: Document and implement an improved flash device binding
From: David Gibson @ 2007-09-07 1:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a8b4282d0c58f1090c64591d387dae97@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:28:35PM +0200, Segher Boessenkool wrote:
> >>> + - bank-width : Width (in bytes) of the flash bank. Equal to
> >>> the
> >>> + device width times the number of interleaved chips.
> >>> + - device-width : (optional) Width of a single flash chip. If
> >>> + omitted, assumed to be equal to 'bank-width'.
> >>
> >> Let's have bank-width optional instead, it's more natural
> >> that way for the common case of just one chip. Or, you can
> >> say that either is optional.
> >
> > No, I'm disinclined to do that since bank-width is the primary bit of
> > information that the driver needs.
>
> Bzzzzt. That's not what the device tree is about; it should
> describe the hardware, it shouldn't be just a config file for
> the current Linux drivers.
Yes, yes, so you've said many times.
But where there are multiple ways of encoding exactly the same
information, I don't see that we can't use driver convenience as a
deciding factor.
> Besides, like I said, for the common case where your flash
> chips aren't interleaved, it makes way more sense to talk
> about device-width than it does to call it bank-width.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: David Gibson @ 2007-09-07 1:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070905132106.GB24637@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 08:21:06AM -0500, Scott Wood wrote:
> On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> > On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > > The kernel is of course welcome to do so -- and this may be a valid
> > > reason to attach pin information to specific device nodes, if it actually
> > > saves a non-negligible amount of power -- but it's not a reason to force
> > > the kernel to have to care by not setting things up in the firmware.
> >
> > Well, I might agree here. But to me it seems unnatural that I have to
> > upgrade bootloader to use SPI -- I can already boot the kernel.
>
> Sure -- the firmware should have been done right the first time.
>
> Unfortunately, it very often doesn't, and thus fixups in the kernel's
> platform code are warranted, but the firmware is still the preferred
> place to do it.
Appealing though it is, I think the whole "firmware is the preferred
place to do it" approach is a lost cause (for nearly every value of
"it").
Firmwares are, more often than not, crap, and that's unlikely to
change. For a lot of things, having the kernel or bootwrapper cope as
a special case with a handful of crap firmwares which don't set things
up properly isn't actually any easier than having it set them up
itself, always.
Which is why I err strongly in favour of having the kernel set things
up rather than rely on firmware setup, unless there's a very strong
reason why we *have* to respect the firmware's setup.
(Incidentally, this reasoning is why although the approach is very
neat-looking, I'm actually quite uncomfortable with firmwares directly
supplying flattened device trees to the kernel, rather than having the
tree in the bootwrapper.)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-07 1:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188971635.3223.9.camel@localhost.localdomain>
On Wed, Sep 05, 2007 at 12:53:54AM -0500, Josh Boyer wrote:
> On Wed, 2007-09-05 at 15:46 +1000, David Gibson wrote:
> > > > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > > > >
> > > > > Probably. I just need to find out where they are stored.
> > > >
> > > > It's not buried somewhere in the arch/ppc/boot code?
> > >
> > > It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> > > I'd rather avoid. But I did find where it's stored in flash, so I can
> > > read it from there. I just need to do a little more work to get it in a
> > > manner that can be used.
> >
> > Hrm.. is that address actually guaranteed to be stable across PIBS
> > versions? If arch/ppc uses __res, I think we should do that too. It
> > shouldn't be any worse than what we already do fot cuboot.
>
> The address should be stable for all versions of PIBS that come on the
> Bamboo boards, yes. And after looking at it a bit more, the wrapper in
> arch/ppc for PIBS essentially mocks up __res by reading the values out
> of flash. So the way I'm doing it is the way it was already done.
Ah, ok. Fine then.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: David Gibson @ 2007-09-07 1:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905113317.630ee687@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:33:17AM -0500, Josh Boyer wrote:
> Updated DTS below
>
> Device tree source file for the PPC405 Walnut evaluation board.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
* [patch v2] Cell: Wrap master run control bit
From: Geoff Levand @ 2007-09-07 1:26 UTC (permalink / raw)
To: jk; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras,
Arnd Bergmann
In-Reply-To: <200709050042.13926.arnd@arndb.de>
Subject: Cell: Wrap master run control bit
From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Add platform specific SPU run control routines to the spufs. The current
spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
control SPE execution, but the PS3 hypervisor does not support the use of
this feature.
This change adds the run control wrapper routies spu_enable_spu() and
spu_disable_spu(). The bare metal routines use the master run control
bit, and the PS3 specific routines use the priv2 run control register.
An outstanding enhancement for the PS3 would be to add a guard to check
for incorrect access to the spu problem state when the spu context is
disabled. This check could be implemented with a flag added to the spu
context that would inhibit mapping problem state pages, and a routine
to unmap spu problem state pages. When the spu is enabled with
ps3_enable_spu() the flag would be set allowing pages to be mapped,
and when the spu is disabled with ps3_disable_spu() the flag would be
cleared and mapped problem state pages would be unmapped.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2:
o Added comments about unmapping PS pages when disabled.
arch/powerpc/platforms/cell/spu_manage.c | 15 +++++++++++++
arch/powerpc/platforms/cell/spufs/backing_ops.c | 6 +++++
arch/powerpc/platforms/cell/spufs/hw_ops.c | 10 ++++++++
arch/powerpc/platforms/cell/spufs/run.c | 4 +--
arch/powerpc/platforms/cell/spufs/spufs.h | 1
arch/powerpc/platforms/ps3/spu.c | 27 ++++++++++++++++++++++++
include/asm-powerpc/spu_priv1.h | 15 +++++++++++++
7 files changed, 76 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -35,6 +35,7 @@
#include <asm/firmware.h>
#include <asm/prom.h>
+#include "spufs/spufs.h"
#include "interrupt.h"
struct device_node *spu_devnode(struct spu *spu)
@@ -369,6 +370,18 @@ static int of_destroy_spu(struct spu *sp
return 0;
}
+static int enable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx->ops->master_start(ctx);
+ return 0;
+}
+
+static int disable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx->ops->master_stop(ctx);
+ return 0;
+}
+
/* Hardcoded affinity idxs for qs20 */
#define QS20_SPES_PER_BE 8
static int qs20_reg_idxs[QS20_SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
@@ -535,5 +548,7 @@ const struct spu_management_ops spu_mana
.enumerate_spus = of_enumerate_spus,
.create_spu = of_create_spu,
.destroy_spu = of_destroy_spu,
+ .enable_spu = enable_spu_by_master_run,
+ .disable_spu = disable_spu_by_master_run,
.init_affinity = init_affinity,
};
--- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
@@ -285,6 +285,11 @@ static void spu_backing_runcntl_write(st
spin_unlock(&ctx->csa.register_lock);
}
+static void spu_backing_runcntl_stop(struct spu_context *ctx)
+{
+ spu_backing_runcntl_write(ctx, SPU_RUNCNTL_STOP);
+}
+
static void spu_backing_master_start(struct spu_context *ctx)
{
struct spu_state *csa = &ctx->csa;
@@ -381,6 +386,7 @@ struct spu_context_ops spu_backing_ops =
.get_ls = spu_backing_get_ls,
.runcntl_read = spu_backing_runcntl_read,
.runcntl_write = spu_backing_runcntl_write,
+ .runcntl_stop = spu_backing_runcntl_stop,
.master_start = spu_backing_master_start,
.master_stop = spu_backing_master_stop,
.set_mfc_query = spu_backing_set_mfc_query,
--- a/arch/powerpc/platforms/cell/spufs/hw_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/hw_ops.c
@@ -220,6 +220,15 @@ static void spu_hw_runcntl_write(struct
spin_unlock_irq(&ctx->spu->register_lock);
}
+static void spu_hw_runcntl_stop(struct spu_context *ctx)
+{
+ spin_lock_irq(&ctx->spu->register_lock);
+ out_be32(&ctx->spu->problem->spu_runcntl_RW, SPU_RUNCNTL_STOP);
+ while(in_be32(&ctx->spu->problem->spu_status_R) & SPU_STATUS_RUNNING)
+ cpu_relax();
+ spin_unlock_irq(&ctx->spu->register_lock);
+}
+
static void spu_hw_master_start(struct spu_context *ctx)
{
struct spu *spu = ctx->spu;
@@ -321,6 +330,7 @@ struct spu_context_ops spu_hw_ops = {
.get_ls = spu_hw_get_ls,
.runcntl_read = spu_hw_runcntl_read,
.runcntl_write = spu_hw_runcntl_write,
+ .runcntl_stop = spu_hw_runcntl_stop,
.master_start = spu_hw_master_start,
.master_stop = spu_hw_master_stop,
.set_mfc_query = spu_hw_set_mfc_query,
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -302,7 +302,7 @@ long spufs_run_spu(struct spu_context *c
if (mutex_lock_interruptible(&ctx->run_mutex))
return -ERESTARTSYS;
- ctx->ops->master_start(ctx);
+ spu_enable_spu(ctx);
ctx->event_return = 0;
spu_acquire(ctx);
@@ -376,7 +376,7 @@ long spufs_run_spu(struct spu_context *c
ctx->stats.libassist++;
- ctx->ops->master_stop(ctx);
+ spu_disable_spu(ctx);
ret = spu_run_fini(ctx, npc, &status);
spu_yield(ctx);
--- a/arch/powerpc/platforms/cell/spufs/spufs.h
+++ b/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -170,6 +170,7 @@ struct spu_context_ops {
char*(*get_ls) (struct spu_context * ctx);
u32 (*runcntl_read) (struct spu_context * ctx);
void (*runcntl_write) (struct spu_context * ctx, u32 data);
+ void (*runcntl_stop) (struct spu_context * ctx);
void (*master_start) (struct spu_context * ctx);
void (*master_stop) (struct spu_context * ctx);
int (*set_mfc_query)(struct spu_context * ctx, u32 mask, u32 mode);
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -28,6 +28,7 @@
#include <asm/spu_priv1.h>
#include <asm/lv1call.h>
+#include "../cell/spufs/spufs.h"
#include "platform.h"
/* spu_management_ops */
@@ -419,10 +420,36 @@ static int ps3_init_affinity(void)
return 0;
}
+/**
+ * ps3_enable_spu - Type of spe to create.
+ *
+ * An outstanding enhancement for the PS3 would be to add a guard to check
+ * for incorrect access to the spu problem state when the spu context is
+ * disabled. This check could be implemented with a flag added to the spu
+ * context that would inhibit mapping problem state pages, and a routine
+ * to unmap spu problem state pages. When the spu is enabled with
+ * ps3_enable_spu() the flag would be set allowing pages to be mapped,
+ * and when the spu is disabled with ps3_disable_spu() the flag would be
+ * cleared and the mapped problem state pages would be unmapped.
+ */
+
+static int ps3_enable_spu(struct spu_context *ctx)
+{
+ return -ENOSYS;
+}
+
+static int ps3_disable_spu(struct spu_context *ctx)
+{
+ ctx->ops->runcntl_stop(ctx);
+ return -ENOSYS;
+}
+
const struct spu_management_ops spu_management_ps3_ops = {
.enumerate_spus = ps3_enumerate_spus,
.create_spu = ps3_create_spu,
.destroy_spu = ps3_destroy_spu,
+ .enable_spu = ps3_enable_spu,
+ .disable_spu = ps3_disable_spu,
.init_affinity = ps3_init_affinity,
};
--- a/include/asm-powerpc/spu_priv1.h
+++ b/include/asm-powerpc/spu_priv1.h
@@ -24,6 +24,7 @@
#include <linux/types.h>
struct spu;
+struct spu_context;
/* access to priv1 registers */
@@ -178,6 +179,8 @@ struct spu_management_ops {
int (*enumerate_spus)(int (*fn)(void *data));
int (*create_spu)(struct spu *spu, void *data);
int (*destroy_spu)(struct spu *spu);
+ int (*enable_spu)(struct spu_context *ctx);
+ int (*disable_spu)(struct spu_context *ctx);
int (*init_affinity)(void);
};
@@ -207,6 +210,18 @@ spu_init_affinity (void)
return spu_management_ops->init_affinity();
}
+static inline int
+spu_enable_spu (struct spu_context *ctx)
+{
+ return spu_management_ops->enable_spu(ctx);
+}
+
+static inline int
+spu_disable_spu (struct spu_context *ctx)
+{
+ return spu_management_ops->disable_spu(ctx);
+}
+
/*
* The declarations folowing are put here for convenience
* and only intended to be used by the platform setup code.
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Timur Tabi @ 2007-09-07 1:28 UTC (permalink / raw)
To: Scott Wood, Anton Vorontsov, linuxppc-dev, Timur Tabi
In-Reply-To: <20070907011553.GO26079@localhost.localdomain>
David Gibson wrote:
> Firmwares are, more often than not, crap, and that's unlikely to
> change. For a lot of things, having the kernel or bootwrapper cope as
> a special case with a handful of crap firmwares which don't set things
> up properly isn't actually any easier than having it set them up
> itself, always.
Similarly, firmware is very often unlikely to be updated. So we need to
support situations where we use old firmware with new kernels. The cuImage
support is a classic example of this. Moving code from kernel to firmware
just because some people think it belongs in the firmware is usually impractical.
If we added code to U-Boot today to configure the par_io pins, it would
probably still be years before we could safely remove that code from the kernel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: David Gibson @ 2007-09-07 1:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905113604.746ee01c@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:36:04AM -0500, Josh Boyer wrote:
> Updated patch below
>
> Add zImage wrapper for walnut board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Geoff Levand @ 2007-09-07 1:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <200709050042.13926.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 04 September 2007, Geoff Levand wrote:
>>
>> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>>
>> Add platform specific SPU run control routines.
>>
>> The current spufs_run_spu() implementation uses the SPU master
>> run control bit (MFC_SR1[S]) to control SPE execution, but the
>> PS3 hypervisor does not support the use of this feature. This
>> change adds run control wrapper routines. The bare metal
>> routines use the master run control bit, and the PS3 specific
>> routines use the priv2 run control register.
>>
>> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>
> Hmm, ok. Since I don't think we'll get to do the right solution
> (unmapping the ps registers on the ps3) that soon, doing this
> patch is at least better than the current situation where we
> end up with an oops every time we leave spu_run.
>
> It would probably be good to mention the remaining problem
> with the current approach in the changelog and as a comment
> in the ps3 specific functions.
Ok, I did that.
>> @@ -178,6 +179,8 @@ struct spu_management_ops {
>> int (*enumerate_spus)(int (*fn)(void *data));
>> int (*create_spu)(struct spu *spu, void *data);
>> int (*destroy_spu)(struct spu *spu);
>> + int (*enable_spu)(struct spu_context *ctx);
>> + int (*disable_spu)(struct spu_context *ctx);
>> int (*init_affinity)(void);
>> };
>
> Also, I think you should make the return type of the callback
> 'void' since the result is not used anywhere.
Noguchi-san was hesitant to do this. I also thought lets leave it
as is until we consider the unmapping support, as maybe a return
value might make sense. Jeremy, if you think it better to return
void, please make the update.
-Geoff
^ permalink raw reply
* RE: Re: PCI target implementation on AMCC PPC CPUs
From: Leonid @ 2007-09-07 2:13 UTC (permalink / raw)
To: sdeven.lee, David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <46E0B178.00C522.05513@m5-81.163.com>
Hi:
You want to say PPC440GP cannot be PCI slave without this =
non-transparent bridge because as David said its "interrupt pin register =
hardwired to zero" or there other reasons?=20
I'm trying to use PPC440ep(or epx) and from its datasheet I don't see =
anything about this zero hardwiring. Does it mean "vanilla" PPC440ep =
will work?
And what did you use for PCI Host?
Also, is your code available somwhere?
Thanks,
Leonid.
-----Original Message-----
From: sdeven.lee [mailto:sdeven.lee@163.com]=20
Sent: Thursday, September 06, 2007 7:04 PM
To: David Hawkins
Cc: Leonid; linuxppc-embedded
Subject: Re: Re: PCI target implementation on AMCC PPC CPUs
David Hawkins,=C4=FA=BA=C3=A3=A1
I have been finished an application using AMCC PPC440GP as PCI =
target(slave) in the last 2 month.I use a non-transparent bridge(AMCC =
PCI6466) to make the device a target(slave) like david has said.
=3D=3D=3D=3D=3D=3D=3D 2007-09-07 04:26:01 =
=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D
>Hi Leonid,
>
>In case they are not in the document:
>
>There are several fundamental problems with the AMCC 440EP acting as a=20
>PCI target/slave;
>
>1. As a PCI target, there is only one way to generate
> an interrupt to a host; you basically toggle the
> interrupt pin. This makes it tricky to develop a
> host-to-slave communications protocol, eg. its
> hard to use the single interrupt to indicate various
> interrupt states, eg. target-to-host buffer has
> data versus host-to-target buffer has been emptied.
> Ideally AMCC should have implemented mailboxes and/or
> doorbell registers like any other sane PCI target
> device (eg. some the Freescale processors, or any of
> the PLX technologies chips).
>
>2. Look in the data sheet and see if you can figure out
> how the host processor can generate an interrupt to
> the PowerPC core ... oops, you can't. That kind of
> makes it difficult to work with doesn't it.
>
> A work around would be to have the host write to the
> GPIO register and wire a GPIO pin back to an external
> interrupt pin. Then you would not be able to use any
> other GPIO pin in that GPIO register since there is
> no way to arbitrate host access versus PowerPC core
> access.
>
>This was the other reason I ditched the AMCC part in favor of the=20
>Freescale part.
>
>If you are looking at other parts, make sure you look in the PCI=20
>configuration space of the processor reference manual. Many processors=20
>have the interrupt pin register hardwired to zero, i.e., they can not=20
>be used as target devices, only hosts. In that case you'd have to add=20
>an intel 21555 non-transparent bridge to make the device a target.
>
>Cheers,
>Dave
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D
=09
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
=C0=F1=A3=A1
=20
=20
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1sdeven.lee
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1sdeven.lee@163.com
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12007-09-07
^ permalink raw reply
* Re: Re: PCI target implementation on AMCC PPC CPUs
From: sdeven.lee @ 2007-09-07 2:03 UTC (permalink / raw)
To: David Hawkins; +Cc: Leonid, linuxppc-embedded
RGF2aWQgSGF3a2lucyzE+rrDo6ENCg0KCUkgaGF2ZSBiZWVuIGZpbmlzaGVkIGFuIGFwcGxpY2F0
aW9uIHVzaW5nIEFNQ0MgUFBDNDQwR1AgYXMgUENJIHRhcmdldChzbGF2ZSkgaW4gdGhlIGxhc3Qg
MiBtb250aC5JIHVzZSBhIG5vbi10cmFuc3BhcmVudCBicmlkZ2UoQU1DQyBQQ0k2NDY2KSB0byBt
YWtlIHRoZSBkZXZpY2UgYSB0YXJnZXQoc2xhdmUpIGxpa2UgZGF2aWQgaGFzIHNhaWQuDQoNCj09
PT09PT0gMjAwNy0wOS0wNyAwNDoyNjowMSDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+SGkg
TGVvbmlkLA0KPg0KPkluIGNhc2UgdGhleSBhcmUgbm90IGluIHRoZSBkb2N1bWVudDoNCj4NCj5U
aGVyZSBhcmUgc2V2ZXJhbCBmdW5kYW1lbnRhbCBwcm9ibGVtcyB3aXRoIHRoZSBBTUNDIDQ0MEVQ
DQo+YWN0aW5nIGFzIGEgUENJIHRhcmdldC9zbGF2ZTsNCj4NCj4xLiBBcyBhIFBDSSB0YXJnZXQs
IHRoZXJlIGlzIG9ubHkgb25lIHdheSB0byBnZW5lcmF0ZQ0KPiAgICBhbiBpbnRlcnJ1cHQgdG8g
YSBob3N0OyB5b3UgYmFzaWNhbGx5IHRvZ2dsZSB0aGUNCj4gICAgaW50ZXJydXB0IHBpbi4gVGhp
cyBtYWtlcyBpdCB0cmlja3kgdG8gZGV2ZWxvcCBhDQo+ICAgIGhvc3QtdG8tc2xhdmUgY29tbXVu
aWNhdGlvbnMgcHJvdG9jb2wsIGVnLiBpdHMNCj4gICAgaGFyZCB0byB1c2UgdGhlIHNpbmdsZSBp
bnRlcnJ1cHQgdG8gaW5kaWNhdGUgdmFyaW91cw0KPiAgICBpbnRlcnJ1cHQgc3RhdGVzLCBlZy4g
dGFyZ2V0LXRvLWhvc3QgYnVmZmVyIGhhcw0KPiAgICBkYXRhIHZlcnN1cyBob3N0LXRvLXRhcmdl
dCBidWZmZXIgaGFzIGJlZW4gZW1wdGllZC4NCj4gICAgSWRlYWxseSBBTUNDIHNob3VsZCBoYXZl
IGltcGxlbWVudGVkIG1haWxib3hlcyBhbmQvb3INCj4gICAgZG9vcmJlbGwgcmVnaXN0ZXJzIGxp
a2UgYW55IG90aGVyIHNhbmUgUENJIHRhcmdldA0KPiAgICBkZXZpY2UgKGVnLiBzb21lIHRoZSBG
cmVlc2NhbGUgcHJvY2Vzc29ycywgb3IgYW55IG9mDQo+ICAgIHRoZSBQTFggdGVjaG5vbG9naWVz
IGNoaXBzKS4NCj4NCj4yLiBMb29rIGluIHRoZSBkYXRhIHNoZWV0IGFuZCBzZWUgaWYgeW91IGNh
biBmaWd1cmUgb3V0DQo+ICAgIGhvdyB0aGUgaG9zdCBwcm9jZXNzb3IgY2FuIGdlbmVyYXRlIGFu
IGludGVycnVwdCB0bw0KPiAgICB0aGUgUG93ZXJQQyBjb3JlIC4uLiBvb3BzLCB5b3UgY2FuJ3Qu
IFRoYXQga2luZCBvZg0KPiAgICBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gd29yayB3aXRoIGRvZXNu
J3QgaXQuDQo+DQo+ICAgIEEgd29yayBhcm91bmQgd291bGQgYmUgdG8gaGF2ZSB0aGUgaG9zdCB3
cml0ZSB0byB0aGUNCj4gICAgR1BJTyByZWdpc3RlciBhbmQgd2lyZSBhIEdQSU8gcGluIGJhY2sg
dG8gYW4gZXh0ZXJuYWwNCj4gICAgaW50ZXJydXB0IHBpbi4gVGhlbiB5b3Ugd291bGQgbm90IGJl
IGFibGUgdG8gdXNlIGFueQ0KPiAgICBvdGhlciBHUElPIHBpbiBpbiB0aGF0IEdQSU8gcmVnaXN0
ZXIgc2luY2UgdGhlcmUgaXMNCj4gICAgbm8gd2F5IHRvIGFyYml0cmF0ZSBob3N0IGFjY2VzcyB2
ZXJzdXMgUG93ZXJQQyBjb3JlDQo+ICAgIGFjY2Vzcy4NCj4NCj5UaGlzIHdhcyB0aGUgb3RoZXIg
cmVhc29uIEkgZGl0Y2hlZCB0aGUgQU1DQyBwYXJ0IGluDQo+ZmF2b3Igb2YgdGhlIEZyZWVzY2Fs
ZSBwYXJ0Lg0KPg0KPklmIHlvdSBhcmUgbG9va2luZyBhdCBvdGhlciBwYXJ0cywgbWFrZSBzdXJl
IHlvdSBsb29rDQo+aW4gdGhlIFBDSSBjb25maWd1cmF0aW9uIHNwYWNlIG9mIHRoZSBwcm9jZXNz
b3IgcmVmZXJlbmNlDQo+bWFudWFsLiBNYW55IHByb2Nlc3NvcnMgaGF2ZSB0aGUgaW50ZXJydXB0
IHBpbiByZWdpc3Rlcg0KPmhhcmR3aXJlZCB0byB6ZXJvLCBpLmUuLCB0aGV5IGNhbiBub3QgYmUg
dXNlZCBhcyB0YXJnZXQNCj5kZXZpY2VzLCBvbmx5IGhvc3RzLiBJbiB0aGF0IGNhc2UgeW91J2Qg
aGF2ZSB0byBhZGQgYW4NCj5pbnRlbCAyMTU1NSBub24tdHJhbnNwYXJlbnQgYnJpZGdlIHRvIG1h
a2UgdGhlIGRldmljZQ0KPmEgdGFyZ2V0Lg0KPg0KPkNoZWVycywNCj5EYXZlDQo+DQo+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5MaW51eHBwYy1lbWJl
ZGRlZCBtYWlsaW5nIGxpc3QNCj5MaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+aHR0cHM6
Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1iZWRkZWQNCg0KPSA9ID0g
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGhoaGhoaGh
odbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoXNkZXZlbi5sZWUNCqGhoaGhoaGh
oaGhoaGhoaFzZGV2ZW4ubGVlQDE2My5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNy0wOS0w
Nw0KDQo=
^ 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