* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <33AC4A3A-876A-4AF9-B851-928EE80A9D80@kernel.crashing.org>
On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
>
> On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
>
> > On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> >> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >>>>>
> >>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >>>>
> >>>> I believe in his latest patches he removed this part. The device
> >>>> trees
> >>>> were not included at all and he left this point open for
> >>>> discussion.
> >>>
> >>> That's correct.
> >>>
> >>> TBH, I think its wrong to keep them in the kernel source at all--
> >>> yes,
> >>> the same argument could be made for arch/powerpc/boot but that's
> >>> been
> >>> settled.
> >>
> >> Sorry, I have to disagree. We're talking about device tree _source_
> >> files here. I believe they should be included in the kernel source.
> >> Where that is, I don't have a particularly strong argument but they
> >> should be included.
> >
> > I have to second that opinion. The device tree is absolutely integral
> > with the rest of the code/drivers needed to support a board. I say
> > there are stronger arguments for keeping the dts files in the kernel
> > source than there are for the boot wrapper.
> >
> > powerpc/boot/dts makes a lot of sense to me.
>
> I like this location and agree that having them in tree makes sense.
> And putting them under boot isolates them from the kernel proper.
>
> The reason I see to having them in tree is to ensure proper version
> compatibility. This way there is no concern about which .dts version
> will work with which kernel. In the future we can always pull them
> out when things are more stable.
Hmm, that is a good reason...
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <528646bc0608012020l11690cf7wbb7d93e6ba6eae90@mail.gmail.com>
On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> >On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >> > >
> >> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >> >
> >> > I believe in his latest patches he removed this part. The device trees
> >> > were not included at all and he left this point open for discussion.
> >>
> >> That's correct.
> >>
> >> TBH, I think its wrong to keep them in the kernel source at all--yes,
> >> the same argument could be made for arch/powerpc/boot but that's been
> >> settled.
> >
> >Sorry, I have to disagree. We're talking about device tree _source_
> >files here. I believe they should be included in the kernel source.
> >Where that is, I don't have a particularly strong argument but they
> >should be included.
>
> I have to second that opinion. The device tree is absolutely integral
> with the rest of the code/drivers needed to support a board. I say
> there are stronger arguments for keeping the dts files in the kernel
> source than there are for the boot wrapper.
Well, the dts is no good to you without dtc so do we put dtc in the
kernel source tree too?
> powerpc/boot/dts makes a lot of sense to me.
If it goes in the kernel src, I think that's the place as well.
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <1154481150.2676.3.camel@vader.jdub.homelinux.org>
On Tue, Aug 01, 2006 at 08:12:29PM -0500, Josh Boyer wrote:
> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> > On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > >
> > > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> > >
> > > I believe in his latest patches he removed this part. The device trees
> > > were not included at all and he left this point open for discussion.
> >
> > That's correct.
> >
> > TBH, I think its wrong to keep them in the kernel source at all--yes,
> > the same argument could be made for arch/powerpc/boot but that's been
> > settled.
>
> Sorry, I have to disagree. We're talking about device tree _source_
> files here. I believe they should be included in the kernel source.
> Where that is, I don't have a particularly strong argument but they
> should be included.
I would agree that its certainly _easier_ to keep them in the src tree.
The only good argument for why its _right_--that I've seen so far--is
by Kumar (i.e., so you have a dts that you know will boot on that kernel).
> > We already have dtc kept externally to the kernel source. Why not
> > keep a single site where all things necessary to powerpc linux are kept?
> > It could house dtc, the dt attach tool, and all the dt source files.
>
> I think hosting the dtc, the dt attach tool, and pre-built dtb files for
> each platform in one spot would be a good idea.
Well, if you're going to keep prebuilt dtb files there, why wouldn't you
want the dts that makes that dtb to be in the same place?
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Vitaly Bordug @ 2006-08-02 18:16 UTC (permalink / raw)
To: Matthew McClintock
Cc: Tom Rini, Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <1154542161.5550.25.camel@localhost>
On Wed, 02 Aug 2006 13:09:21 -0500
Matthew McClintock wrote:
> On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> > I'll throw in the caveat that I'm not 100% sure we're that stable
> > yet, but it certainly seems like it, at least for the overall
> > portion where you might really have incompatible trees. More or
> > less complete (now every device is described!) dts should be
> > interchangable to the kernel for the custom board X is just a
> > little different from ref board Y issues (and now, in theory, the
> > Just Like A Sandpoint board, with a correct dts will boot the
> > 'sandpoint' kernel).
>
> The sandpoint (as far as I know) does not have a stable DTS. So in
> this case including the DTS in the kernel would reduce confusion. The
> same could be said for other boards where the DTS needed to be
> changed for the IRQ rework. The old DTS will no longer boot the new
> kernels. I'm not sure how much longer we will run into this problem
> though.
>
I am right about to submit dts+code working fine w/ recent IRQ stuff for 8540 and 8560,
and will make sure dts coming along.
But, I guess we finally should end up with a place in kernel tree where such a stuff should reside
further.
^ permalink raw reply
* Re: [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Tom Rini @ 2006-08-02 18:15 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060802181422.GG17652@mag.az.mvista.com>
On Wed, Aug 02, 2006 at 11:14:22AM -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 09:19:34AM -0700, Tom Rini wrote:
> > On Wed, Jul 19, 2006 at 04:14:21PM -0700, Mark A. Greer wrote:
> >
> > > This patch adds the firmware operations that support the DINK firmware
> > > from Freescale.
> >
> > This isn't really DINK support (which would mean actually talking
> > back/with DINK,
>
> You seem to be thinking that this is the final, end-all solution to
> everything. It isn't. Its a step in the direction that we are trying
> go (IIUC). dink.c is about the easiest one there will be. of.c has a
> slightly more complicated fw_ops. We still need to figure out what uboot
> needs and what PIBS needs and what...
Right. I'm just saying that unless you're planning on making this talk
with / use DINK (I swear, the DINK manual talks about this a bit, but
I'm too lazy to look just this second), this isn't the DINK one, this is
the (will be needed and used) bare metal one.
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Mark A. Greer @ 2006-08-02 18:14 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060802161934.GI3075@smtp.west.cox.net>
On Wed, Aug 02, 2006 at 09:19:34AM -0700, Tom Rini wrote:
> On Wed, Jul 19, 2006 at 04:14:21PM -0700, Mark A. Greer wrote:
>
> > This patch adds the firmware operations that support the DINK firmware
> > from Freescale.
>
> This isn't really DINK support (which would mean actually talking
> back/with DINK,
You seem to be thinking that this is the final, end-all solution to
everything. It isn't. Its a step in the direction that we are trying
go (IIUC). dink.c is about the easiest one there will be. of.c has a
slightly more complicated fw_ops. We still need to figure out what uboot
needs and what PIBS needs and what...
As things are added, it'll evolve.
> parsing the infos that it does pass along, and it does,
> iirc,
Not that I know of.
> but I don't recall if it's at all ever correct / useful :)) but
> just a, um, I suck at naming things (see arch/ppc/boot/simple) but
> non-nonsense, no help 'firmware' ops. Please think up a name that
> doesn't suck (as a name I would come up with would). Thanks!
Guess I suck too b/c I can't think of anything better. As things
evolve, fw_ops may go away all together. The problem is, I'm not
exactly sure where we're going to end up so this is the best that
I can do with the info that I have.
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Matthew McClintock @ 2006-08-02 18:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802163822.GK3075@smtp.west.cox.net>
On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> I'll throw in the caveat that I'm not 100% sure we're that stable yet,
> but it certainly seems like it, at least for the overall portion where
> you might really have incompatible trees. More or less complete (now
> every device is described!) dts should be interchangable to the kernel
> for the custom board X is just a little different from ref board Y
> issues (and now, in theory, the Just Like A Sandpoint board, with a
> correct dts will boot the 'sandpoint' kernel).
The sandpoint (as far as I know) does not have a stable DTS. So in this
case including the DTS in the kernel would reduce confusion. The same
could be said for other boards where the DTS needed to be changed for
the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
sure how much longer we will run into this problem though.
-Matthew
^ permalink raw reply
* [RFC] asm code for Hypervisor Call Instrumentation
From: Mike Kravetz @ 2006-08-02 17:59 UTC (permalink / raw)
To: linuxppc-dev
In my last submission of hcall instrumentation patches, I took
Paul's suggestion and added code to get the timebase and PURR
snapshots in the hcall asm routines. I'm not confident in my
assembly skills, so I would really like some comments on this
approach/code. The idea(and some code) was taken from hash_low_64.S.
Of course, this all 'appears' to work correctly. :)
This patch is built on top of Anton's hcall cleanup patch. One
remaining issue is 'where should the statistic data structures
be updated?'. For simplicity, I have the asm code call the
following C routine to perform the updates.
void update_hcall_stats(unsigned long opcode, unsigned long tb_delta,
unsigned long purr_delta)
{
unsigned long op_index = opcode >> 2;
struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
hs->tb_total += tb_delta;
hs->purr_total += purr_delta;
hs->num_calls++;
}
I honestly do not know if it would be better to do all of this in the
assembly routine. I believe that 'allocation' of a stack frame is
only necessary because of the callout. Right?
--
Mike
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall.S powerpc.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc/arch/powerpc/platforms/pseries/hvCall.S 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall.S 2006-07-21 07:06:49.000000000 +0000
@@ -11,7 +11,57 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
-#define STK_PARM(i) (48 + ((i)-3)*8)
+#define STK_PARM(i) (STACKFRAMESIZE + 48 + ((i)-3)*8)
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#ifdef CONFIG_HCALL_STATS
+#define STACKFRAMESIZE 256
+#define HCALL_INST_PRECALL \
+ /* use stack frame to save a few non-volital regs */ \
+ stdu r1,-STACKFRAMESIZE(r1); \
+ std r31,STK_REG(r31)(r1); \
+ std r30,STK_REG(r30)(r1); \
+ std r29,STK_REG(r29)(r1); \
+ std r28,STK_REG(r28)(r1); \
+ \
+ /* save lr and hcall opcode */ \
+ /* then get time, purr snapshot before hcall */ \
+ mflr r31; \
+ mr r30,r3; \
+ mftb r29; \
+BEGIN_FTR_SECTION; \
+ mfspr r28,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR);
+
+#define HCALL_INST_POSTCALL \
+ /* get time, purr snapshot after hcall */ \
+ mftb r4; \
+BEGIN_FTR_SECTION; \
+ mfspr r5,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ /* setup regs to call routine that stuffs stats */ \
+ /* into per-cpu/per-call structure. */ \
+ subf r4,r29,r4; \
+ subf r5,r28,r5; \
+ mr r29,r3; /* save hcall rc */ \
+ mr r3,r30; \
+ bl .update_hcall_stats; \
+ \
+ /* restore hcall rc, lr and non-volital regs */ \
+ mr r3,r29; \
+ mtlr r31; \
+ ld r31,STK_REG(r31)(r1); \
+ ld r30,STK_REG(r30)(r1); \
+ ld r29,STK_REG(r29)(r1); \
+ ld r28,STK_REG(r28)(r1); \
+ addi r1,r1,STACKFRAMESIZE
+#else
+
+#define STACKFRAMESIZE 0
+#define HCALL_INST_PRECALL nop
+#define HCALL_INST_POSTCALL nop
+#endif
.text
@@ -21,8 +71,12 @@ _GLOBAL(plpar_hcall_norets)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
HVSC /* invoke the hypervisor */
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
blr /* return r3 = status */
@@ -33,6 +87,8 @@ _GLOBAL(plpar_hcall)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -50,6 +106,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +119,8 @@ _GLOBAL(plpar_hcall9)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -86,6 +146,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
^ permalink raw reply
* Re: [PATCH 4/6] bootwrapper: Add non-OF serial console support
From: Mark A. Greer @ 2006-08-02 17:54 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060802161712.GH3075@smtp.west.cox.net>
On Wed, Aug 02, 2006 at 09:17:12AM -0700, Tom Rini wrote:
> On Wed, Jul 19, 2006 at 04:12:44PM -0700, Mark A. Greer wrote:
>
> > This patch adds support for serial I/O to the bootwrapper.
> >
> > It is broken into 2 layers. The first layer is generic serial
> > operations that calls uart-specific routines to do the actual I/O.
> > The second layer contains support for a 16550 compatible uart.
> >
> > The division allows support for other serial devices to be easily
> > added in the future (e.g., the Marvell MPSC and the Freescale CPM).
>
> Why do we do this with indirection rather than weak defaults and then
> real implementations?
Remember, devtrees can be added years after the zImage built.
So what if you had a board with 4 serial ports, 2 MPSC, 2 16550/8250
and the /chosen/linux,stdout-path could choose any of the four?
The current code doesn't handle that now either :) but it easily
could (and I should make it handle that). The reason for the
indirections and not weak routines is to allow maximum flexibility.
Once things become more concrete, we can look at what can be replaced
by weak routines. Now isn't the time, IMHO.
> The only places I see that are data are:
>
> > + ns16550_scd.base = NULL;
> > + ns16550_scd.reg_shift = 0;
>
> And I imagine that on platforms where these are real, we dig them out of
> the tree and set them, in your scheme, so it'd just be an empty (return
> 0/NULL) weak function, or the dig in the tree function. Heck, it could
> just always be a 'dig in the tree' function.
I'm sorry, but I can't parse this paragraph.
What I probably should do, is rework serial_open() to query the dt
to get the stdout-path, match it up to one of the low-level serial
drivers that's been linked into the zImage, hook it up, and can call
its open routine. Its open routine can then look for the properies
it needs in the devtree. Something like that.
Again, when things have settled down, we can convert indirects to weak
routines where it makes sense. But also remember, that the zImage
doesn't necessarily know a priori what's going to be in its devtree
(unless what's been compiled & linked into the zImage is so minimal
that it allows it no options--maybe that ends up always being the case,
I don't know).
Mark
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Tom Rini @ 2006-08-02 17:23 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060802170514.GE17652@mag.az.mvista.com>
On Wed, Aug 02, 2006 at 10:05:14AM -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 09:10:54AM -0700, Tom Rini wrote:
> > On Wed, Jul 19, 2006 at 04:05:44PM -0700, Mark A. Greer wrote:
> >
> > > This patch adds the device tree operations (dt_ops) for a flattened
> > > device tree (fdt).
> > [snip]
> > > +/* Definitions used by the flattened device tree */
> > [snip]
> > ...
> > > +struct fdt_bus {
> > > + u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
> > > + int (*translate)(u32 *addr, u64 offset, int na);
> > > +};
> >
> > All of that should live in an fdt.h.
>
> Why? Its never used outside of fdt.c and therefore should not be in
> fdt.h.
Meh, I'll drop it then..
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Mark A. Greer @ 2006-08-02 17:05 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060802161054.GG3075@smtp.west.cox.net>
On Wed, Aug 02, 2006 at 09:10:54AM -0700, Tom Rini wrote:
> On Wed, Jul 19, 2006 at 04:05:44PM -0700, Mark A. Greer wrote:
>
> > This patch adds the device tree operations (dt_ops) for a flattened
> > device tree (fdt).
> [snip]
> > +/* Definitions used by the flattened device tree */
> [snip]
> ...
> > +struct fdt_bus {
> > + u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
> > + int (*translate)(u32 *addr, u64 offset, int na);
> > +};
>
> All of that should live in an fdt.h.
Why? Its never used outside of fdt.c and therefore should not be in
fdt.h.
> > +
> > +static inline struct boot_param_header *
> > +fdt_get_bph(void *dt_blob)
> > +{
> > + return (struct boot_param_header *)dt_blob;
> > +}
>
> Er, can't we just do this in the few places directly?
Sure.
> > + if (!(new_dtb_start = malloc(new_total_size))) {
> > + printf("Can't alloc space for new fdt\n\r");
> > + exit();
> > + }
>
> Wasn't there a panic("Message") or so, for bootwrapper stuff? If not,
> maybe there should be..
There isn't now. Easy enough to add unless someone else objects.
Mark
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-02 16:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17616.17129.964122.125259@cargo.ozlabs.ibm.com>
On Wed, Aug 02, 2006 at 04:15:05PM +1000, Paul Mackerras wrote:
> I wrote:
>
> > The ops structure seems like a reasonable concept, but I question
> > whether we need to have platform_ops separate from fw_ops, since the
> > firmware is essentially part of the implementation of the platform.
> > Also I don't see why we need to do a double indirection to get to each
> > ops function.
>
> Thinking about this a bit more, why do we need the indirect function
> calls at all? Do we ever want to be able to choose (e.g.) one of
> several possible console implementations at runtime? Don't we know at
> compile time which one we will be using, and thus can't we use the
> linker to make the necessary linkages?
The hooking up was done at runtime for relocation reasons.
The got relocation code in crt0.S doesn't handle a function address
statically assigned to a structure member. I don't think its safe
to assume that 0x4000 is safe on all platforms, either, so relocation is
probably a fact of life. We could hack crt0.S instead, if you prefer?
Mark
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-02 17:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200608021441.23429.arnd.bergmann@de.ibm.com>
On Wed, Aug 02, 2006 at 02:41:23PM +0200, Arnd Bergmann wrote:
> On Wednesday 02 August 2006 06:53, Paul Mackerras wrote:
> > > +#ifdef __powerpc64__
> > > +typedef unsigned long u64;
> > > +#else
> > > +typedef unsigned long long u64;
> > > +#endif
> >
> > This is potentially confusing, because the __powerpc64__ relates to
> > the boot wrapper not the kernel, and we don't build a 64-bit boot
> > wrapper on any platform (not yet anyway). Maybe this needs a comment.
> >
> Moreover, even if we ever build this on __powerpc64__, the
> typedef unsigned long long u64 would still do the right thing.
> It only ever becomes a problem when mixing with u64 the c99 uint64_t,
> which is defined the other way.
I copied that code from somewhere but I forget where & can't seem to
find it now. I'll get rid of it for now.
Mark
^ permalink raw reply
* RE: Sloooooowwww CFI Flash programming
From: Franca, Jose Filipe (ext) @ 2006-08-02 16:45 UTC (permalink / raw)
To: linuxppc-dev
That is implemented in the 2.6 kernels. Are you sugesting a merge with
2.6 code? Or there is a patch that implements that in 2.4 kernels?
-----Original Message-----
From: Frank [mailto:frannk_m1@yahoo.com]=20
Sent: quarta-feira, 2 de Agosto de 2006 17:41
To: Franca, Jose Filipe (ext); linuxppc-dev@ozlabs.org
Subject: Re: Sloooooowwww CFI Flash programming
--- "Franca, Jose Filipe (ext)" <jose.franca.ext@siemens.com>
wrote:
> Hello all!
>=20
> I'm using a linux-2.4.31 based kernel in our board and we are
> using a AM29LV040B flash device. Our problem is that flash
> programming is a rather slow process. The responsible is the
> file cfi_cmdset_0002.c. Is there any patch that fixes this
> problem and enables fast programming mode?
>=20
>
You probably need buffer writes enabled.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20
^ permalink raw reply
* Re: Sloooooowwww CFI Flash programming
From: Frank @ 2006-08-02 16:41 UTC (permalink / raw)
To: Franca, Jose Filipe (ext), linuxppc-dev
In-Reply-To: <4051B1A83682514BA8529BCADDA45F086EE61D@PTLISI050MSX.PT001.SIEMENS.NET>
--- "Franca, Jose Filipe (ext)" <jose.franca.ext@siemens.com>
wrote:
> Hello all!
>
> I'm using a linux-2.4.31 based kernel in our board and we are
> using a AM29LV040B flash device. Our problem is that flash
> programming is a rather slow process. The responsible is the
> file cfi_cmdset_0002.c. Is there any patch that fixes this
> problem and enables fast programming mode?
>
>
You probably need buffer writes enabled.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-02 16:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17616.12251.339657.215571@cargo.ozlabs.ibm.com>
On Wed, Aug 02, 2006 at 02:53:47PM +1000, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > Abstract the operations used in the bootwrapper. The operations
> > have been divided up into platform ops (platform_ops), firware ops
> > (fw_ops), device tree ops (dt_ops), and console ops (console_ops).
>
> Overall the approach looks good.
>
> The ops structure seems like a reasonable concept, but I question
> whether we need to have platform_ops separate from fw_ops, since the
> firmware is essentially part of the implementation of the platform.
Sometimes the people run different fw's on the same platform. An
example is the sandpoint which comes with DINK but others run uboot on
it.
> Also I don't see why we need to do a double indirection to get to each
> ops function.
Okay.
> Also, we will probably want to create some directory structure under
> arch/powerpc/boot in the longer term.
Agreed.
> > +#ifdef __powerpc64__
> > +typedef unsigned long u64;
> > +#else
> > +typedef unsigned long long u64;
> > +#endif
>
> This is potentially confusing, because the __powerpc64__ relates to
> the boot wrapper not the kernel, and we don't build a 64-bit boot
> wrapper on any platform (not yet anyway). Maybe this needs a comment.
Okay.
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-02 16:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <33AC4A3A-876A-4AF9-B851-928EE80A9D80@kernel.crashing.org>
On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
> I like this location and agree that having them in tree makes sense.
> And putting them under boot isolates them from the kernel proper.
>
> The reason I see to having them in tree is to ensure proper version
> compatibility. This way there is no concern about which .dts version
> will work with which kernel. In the future we can always pull them
> out when things are more stable.
I'd rephrase that as an arguement to keep them out of tree:
The reason I see to having them out of tree is to ensure we follow the
intent trees holding the information about where devices live and the
kernel being good and asking the trees. This way there is no concern
about which (otherwise valid) .dts version will work with which kernel,
as breaking a valid .dts is either a bug (unintentional API change or a
'Oops, I forgot that the tree might not specify X' which potentially
preempts the custom board Y (that's like a sandpoint!) just doesn't have
X bugs) or a change that requires a dts version bump.
I'll throw in the caveat that I'm not 100% sure we're that stable yet,
but it certainly seems like it, at least for the overall portion where
you might really have incompatible trees. More or less complete (now
every device is described!) dts should be interchangable to the kernel
for the custom board X is just a little different from ref board Y
issues (and now, in theory, the Just Like A Sandpoint board, with a
correct dts will boot the 'sandpoint' kernel).
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Tom Rini @ 2006-08-02 16:19 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719231421.GF3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:14:21PM -0700, Mark A. Greer wrote:
> This patch adds the firmware operations that support the DINK firmware
> from Freescale.
This isn't really DINK support (which would mean actually talking
back/with DINK, parsing the infos that it does pass along, and it does,
iirc, but I don't recall if it's at all ever correct / useful :)) but
just a, um, I suck at naming things (see arch/ppc/boot/simple) but
non-nonsense, no help 'firmware' ops. Please think up a name that
doesn't suck (as a name I would come up with would). Thanks!
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 4/6] bootwrapper: Add non-OF serial console support
From: Tom Rini @ 2006-08-02 16:17 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719231244.GE3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:12:44PM -0700, Mark A. Greer wrote:
> This patch adds support for serial I/O to the bootwrapper.
>
> It is broken into 2 layers. The first layer is generic serial
> operations that calls uart-specific routines to do the actual I/O.
> The second layer contains support for a 16550 compatible uart.
>
> The division allows support for other serial devices to be easily
> added in the future (e.g., the Marvell MPSC and the Freescale CPM).
Why do we do this with indirection rather than weak defaults and then
real implementations? The only places I see that are data are:
> + ns16550_scd.base = NULL;
> + ns16550_scd.reg_shift = 0;
And I imagine that on platforms where these are real, we dig them out of
the tree and set them, in your scheme, so it'd just be an empty (return
0/NULL) weak function, or the dig in the tree function. Heck, it could
just always be a 'dig in the tree' function.
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Tom Rini @ 2006-08-02 16:10 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719230544.GD3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:05:44PM -0700, Mark A. Greer wrote:
> This patch adds the device tree operations (dt_ops) for a flattened
> device tree (fdt).
[snip]
> +/* Definitions used by the flattened device tree */
[snip]
...
> +struct fdt_bus {
> + u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
> + int (*translate)(u32 *addr, u64 offset, int na);
> +};
All of that should live in an fdt.h.
> +
> +static inline struct boot_param_header *
> +fdt_get_bph(void *dt_blob)
> +{
> + return (struct boot_param_header *)dt_blob;
> +}
Er, can't we just do this in the few places directly?
> + if (!(new_dtb_start = malloc(new_total_size))) {
> + printf("Can't alloc space for new fdt\n\r");
> + exit();
> + }
Wasn't there a panic("Message") or so, for bootwrapper stuff? If not,
maybe there should be..
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Tom Rini @ 2006-08-02 16:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17616.17129.964122.125259@cargo.ozlabs.ibm.com>
On Wed, Aug 02, 2006 at 04:15:05PM +1000, Paul Mackerras wrote:
> I wrote:
>
> > The ops structure seems like a reasonable concept, but I question
> > whether we need to have platform_ops separate from fw_ops, since the
> > firmware is essentially part of the implementation of the platform.
> > Also I don't see why we need to do a double indirection to get to each
> > ops function.
>
> Thinking about this a bit more, why do we need the indirect function
> calls at all? Do we ever want to be able to choose (e.g.) one of
> several possible console implementations at runtime? Don't we know at
> compile time which one we will be using, and thus can't we use the
> linker to make the necessary linkages?
Right. I was thinking perhaps Mark did it this way so certain things
could be omitted (if ops->foo then ops->foo(bar, baz)) but that'd
better taken care of with weak functions and getting the right one at
compile time.
The only potential case, but I'm not even sure then that it is an issue,
is on platforms where it's either U-Boot or PIBS/DINK/whatever. But
even then, the only thing that should matter is 'Do we have a tree
passed in?'.
--
Tom Rini
^ permalink raw reply
* Sloooooowwww CFI Flash programming
From: Franca, Jose Filipe (ext) @ 2006-08-02 15:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hello all!
I'm using a linux-2.4.31 based kernel in our board and we are using a AM29LV040B flash device. Our problem is that flash programming is a rather slow process. The responsible is the file cfi_cmdset_0002.c. Is there any patch that fixes this problem and enables fast programming mode?
Thanks for reading (and many more if you reply),
Filipe França.
[-- Attachment #2: Type: text/html, Size: 1046 bytes --]
^ permalink raw reply
* SPI spi_spcom[STR] freeze
From: GSM909 @ 2006-08-02 15:30 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I have problem with SPI
When I want to start my SPI transfer by setting 0x80 to my spi_spcom register. 0x80 keeping in this register till I "READ" the SPMODE register. There is also no transfer or any clock on the pins.
Did anyone had an Idea what this can be ???
my system:
mpc8270
pm827 from mircosys
linux 2.6.14 with Xenomai 2.1.2
The kernel module with the spi run under the rtdm.
Thx for helping me.
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Jon Loeliger @ 2006-08-02 14:42 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
So, like, the other day Adrian Cox mumbled:
> Is anybody else having problems with 32-bit SMP support in arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
As a point of reference, the 32-bit 8641 HPCN seems to be working fine
with both CONFIG_SMP and the device tree mechanism in place. It was working
both before and after the IRQ changes.
Can you nail down any more specifics on how it is failing or where
the corruption happens?
jdl
^ permalink raw reply
* Help for USB host driver for MPC8xx
From: wei.li4 @ 2006-08-02 14:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Dose anyone use USB host drivers for MPC875 with Linux 2.4.25? I just
found these notes from http://www.heeltoe.com/software/usb/usb.html,
but I have no idea about how to use it, any advice? Thanks.
Wei
^ 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