* Re: regarding kernel for montavista
From: Alex Zeffertt @ 2005-05-20 8:54 UTC (permalink / raw)
To: Gopala Krishnam Raju; +Cc: linuxppc-embedded
In-Reply-To: <83986B58C72FC447AAC98F916BAB6A5735D90A@postman.facetime.com>
You haven't said a lot of things.
1. What board are you using (and how did you create .config)
2. What was the last thing the kernel said (i.e. where did it crash)
3. Did it oops? If so where did the oops say it crashed
(read man ksymoops; generate output; post it to the list)
Alex
On Fri, 20 May 2005 09:55:57 +0530
"Gopala Krishnam Raju" <graju@facetime.com> wrote:
> hello
>
> 1. I have compiled the montavista kernel
>
> 2. I have done made the make dep
>
> 3. I have done make install
>
> 4. I have done makeinitrd-pxe also
>
> Every thing went well but when i boot this on the target it is giving
> the kernel panic error. I tried with enforcing=0 also then also the
> problem is not solved.
>
> please help me out
>
> Thanks in advance
>
> Regards
>
> GGKRAJU
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Benjamin Herrenschmidt @ 2005-05-20 7:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17037.32285.607543.859030@cargo.ozlabs.ibm.com>
On Fri, 2005-05-20 at 16:05 +1000, Paul Mackerras wrote:
> Here is a revised version of my patch to set the cpu type explicitly
> for gcc when compiling the kernel. Setting the cpu type is a good
> idea in any case, and particularly if you have a biarch gcc. This
> sets the type for all of the ppc cpu families we support.
>
> Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
> and 85xx respectively? I used -mcpu=power4 rather than -mcpu=970
> because the former works with gcc-3.6.6 as in debian and the latter
> doesn't. Unfortunately -mcpu=440 doesn't work either in gcc 3.3,
> though it does in gcc 3.4 (as does -mcpu=970).
The problem is the same as ppc64 isn't it ?, -maltivec doesn't work with
-mcpu=power4 on gcc 3.4 does it ? That would mean no RAID6...
Ben.
^ permalink raw reply
* [PATCH] ppc32: remove unused computation
From: Paul Mackerras @ 2005-05-20 7:15 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
We are computing phys in the code below and never using. This patch
takes out the redundant computation.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/syslib/open_pic.c pmac-2.5/arch/ppc/syslib/open_pic.c
--- linux-2.6/arch/ppc/syslib/open_pic.c 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/syslib/open_pic.c 2005-04-26 20:34:39.000000000 +1000
@@ -557,12 +557,10 @@
*/
void openpic_cause_IPI(u_int ipi, cpumask_t cpumask)
{
- cpumask_t phys;
DECL_THIS_CPU;
CHECK_THIS_CPU;
check_arg_ipi(ipi);
- phys = physmask(cpumask);
openpic_write(&OpenPIC->THIS_CPU.IPI_Dispatch(ipi),
cpus_addr(physmask(cpumask))[0]);
}
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Wolfgang Denk @ 2005-05-20 6:59 UTC (permalink / raw)
To: Hollis Blanchard
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
In-Reply-To: <6fcc07be88e5091ac1428e9bbde6d92f@penguinppc.org>
In message <6fcc07be88e5091ac1428e9bbde6d92f@penguinppc.org> you wrote:
>
> > Maybe you want to post the RFC to lkml, or at least to the
> > linux-arm-kernel and linux-mips mailing lists?
>
> As you observe, having multiple incompatible communication mechanisms
> is an issue of u-boot code maintenance. Since you are the most affected
No, it's vice versa. U-Boot has always been just implementing what
the kernel does. There are many other boot loaders around that all
have to adhere to the interface(s) imposed on them by the kernel.
> In the meantime, it sounds like this device tree stuff solves ppc64's
> problem in a way the maintainers are happy with, so it's hard to ask
> them to come up with a solution to a problem they don't have.
Well, actually nobody has problems: the ARM and MIPS folks have
working solutions, too. The next architecture will implement yet
another way of passing information to the kernel, implement it and
state that they will not accept any other solution, and so on.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
^ permalink raw reply
* [PATCH] ppc32: don't call progress functions after boot
From: Paul Mackerras @ 2005-05-20 6:57 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
On ppc32, the platform code can supply a "progress" function that is
used to show progress through the boot. These functions are usually
in an init section and so can't be called after the init pages are
freed. Now that the cpu bringup code can be called after the system
is booted (for hotplug cpu) we can get the situation where the
progress function can be called after boot. The simple fix is to set
the progress function pointer to NULL when the init pages are freed,
and that is what this patch does (note that all callers already check
whether the function pointer is NULL before trying to call it).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/mm/init.c pmac-2.5/arch/ppc/mm/init.c
--- linux-2.6/arch/ppc/mm/init.c 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/mm/init.c 2005-04-26 20:34:00.000000000 +1000
@@ -179,6 +179,7 @@
if (!have_of)
FREESEC(openfirmware);
printk("\n");
+ ppc_md.progress = NULL;
#undef FREESEC
}
^ permalink raw reply
* [PATCH] ppc32: Fix __copy_tofrom_user return value
From: Paul Mackerras @ 2005-05-20 6:50 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
Recently the __copy_tofrom_user routine was modified to avoid doing
prefetches past the end of the source array. However, in doing so we
introduced a bug in that it now returns the wrong value for the number
of bytes not copied when a fault is encountered. This fixes it to
return the correct number.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/lib/string.S pmac-2.5/arch/ppc/lib/string.S
--- linux-2.6/arch/ppc/lib/string.S 2005-04-26 15:37:55.000000000 +1000
+++ pmac-2.5/arch/ppc/lib/string.S 2005-04-26 20:33:39.000000000 +1000
@@ -446,6 +446,7 @@
#ifdef CONFIG_8xx
/* Don't use prefetch on 8xx */
mtctr r0
+ li r0,0
53: COPY_16_BYTES_WITHEX(0)
bdnz 53b
@@ -564,7 +565,9 @@
/* or write fault in cacheline loop */
105: li r9,1
92: li r3,LG_CACHELINE_BYTES
- b 99f
+ mfctr r8
+ add r0,r0,r8
+ b 106f
/* read fault in final word loop */
108: li r9,0
b 93f
@@ -585,7 +588,7 @@
* r5 + (ctr << r3), and r9 is 0 for read or 1 for write.
*/
99: mfctr r0
- slw r3,r0,r3
+106: slw r3,r0,r3
add. r3,r3,r5
beq 120f /* shouldn't happen */
cmpwi 0,r9,0
^ permalink raw reply
* [PATCH] ppx32: Fix uninitialized variable in set_preferred_console
From: Paul Mackerras @ 2005-05-20 6:45 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linuxppc-dev, trini
This patch fixes an uninitialized variable warning in
arch/ppc/kernel/setup.c, and this time gcc is actually right, there is
a path that could result in offset being uninitialized. Zero is a
sane default in this instance.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN linux-2.6/arch/ppc/kernel/setup.c pmac-2.5/arch/ppc/kernel/setup.c
--- linux-2.6/arch/ppc/kernel/setup.c 2005-05-18 10:53:54.000000000 +1000
+++ pmac-2.5/arch/ppc/kernel/setup.c 2005-05-18 14:11:33.000000000 +1000
@@ -499,7 +499,7 @@
{
struct device_node *prom_stdout;
char *name;
- int offset;
+ int offset = 0;
if (of_stdout_device == NULL)
return -ENODEV;
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Stefan Nickl @ 2005-05-20 6:44 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
In-Reply-To: <20050519231446.29487C1512@atlas.denx.de>
On Fri, 2005-05-20 at 01:14 +0200, Wolfgang Denk wrote:
> > ppc64 kernel anyways ? I don't think that is very relevant. On the
>
> I am aware that you think so, and I try to raise your awareness of
> the fact that there is a huge number of small machines out there.
>
> Please keep in mind that the same interface will be forced sooner or
> later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.
I don't seem to be getting the point: As you proved conclusively on your
website, 2.6 (and IMHO very likely anything that will come after it)
does not scale down well to small systems like the 8xx any more anyways.
And I don't think such a major change will be "forced" upon the mostly
frozen 2.4 tree.
So why try to stop the folks that want to unite the current "mess" in a
proven superset datastructure that seems to suit quite fine with all
chips that came into production for (at least) the last five years?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* [PATCH] Set cpu type explicitly, take 2
From: Paul Mackerras @ 2005-05-20 6:05 UTC (permalink / raw)
To: linuxppc-dev
Here is a revised version of my patch to set the cpu type explicitly
for gcc when compiling the kernel. Setting the cpu type is a good
idea in any case, and particularly if you have a biarch gcc. This
sets the type for all of the ppc cpu families we support.
Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
and 85xx respectively? I used -mcpu=power4 rather than -mcpu=970
because the former works with gcc-3.6.6 as in debian and the latter
doesn't. Unfortunately -mcpu=440 doesn't work either in gcc 3.3,
though it does in gcc 3.4 (as does -mcpu=970).
Paul.
diff -urN linux-2.6/arch/ppc/Makefile pmac-2.5/arch/ppc/Makefile
--- linux-2.6/arch/ppc/Makefile 2005-05-02 08:29:36.000000000 +1000
+++ pmac-2.5/arch/ppc/Makefile 2005-05-19 15:26:42.000000000 +1000
@@ -23,15 +23,20 @@
LDFLAGS_vmlinux := -Ttext $(KERNELLOAD) -Bstatic
CPPFLAGS += -Iarch/$(ARCH)
AFLAGS += -Iarch/$(ARCH)
-CFLAGS += -Iarch/$(ARCH) -msoft-float -pipe \
- -ffixed-r2 -mmultiple
+CFLAGS += -Iarch/$(ARCH) -msoft-float -pipe -ffixed-r2 -mmultiple
CPP = $(CC) -E $(CFLAGS)
CHECKFLAGS += -D__powerpc__
-ifndef CONFIG_E500
-CFLAGS += -mstring
-endif
+cpu-opt-$(CONFIG_6xx) += -mcpu=750 -mtune=7450
+cpu-opt-$(CONFIG_40x) += -mcpu=405
+cpu-opt-$(CONFIG_44x) += -mcpu=440
+cpu-opt-$(CONFIG_POWER3) += -mcpu=power3
+cpu-opt-$(CONFIG_POWER4) += -mcpu=power4
+cpu-opt-$(CONFIG_8xx) += -mcpu=860
+cpu-opt-$(CONFIG_E500) += -mcpu=8540
+
+CFLAGS += $(cpu-opt-y)
cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
cpu-as-$(CONFIG_4xx) += -Wa,-m405
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Paul Mackerras @ 2005-05-20 4:28 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc64-dev, linuxppc-embedded, u-boot-users,
linuxppc-dev
In-Reply-To: <17037.26222.23591.13083@cargo.ozlabs.ibm.com>
I wrote:
> Ben's proposal is for ppc64, at least as present. If the ppc32
> embedded developers decide they want to use a device tree, that would
> be good, but it will proceed by
... and got interrupted. I meant to write "proceed by persuasion and
consensus, not fiat".
Paul.
^ permalink raw reply
* regarding kernel for montavista
From: Gopala Krishnam Raju @ 2005-05-20 4:25 UTC (permalink / raw)
To: linuxppc-embedded
hello
1. I have compiled the montavista kernel
2. I have done made the make dep
3. I have done make install
4. I have done makeinitrd-pxe also=20
Every thing went well but when i boot this on the target it is giving =
the kernel panic error. I tried with enforcing=3D0 also then also the =
problem is not solved.
please help me out=20
Thanks in advance
Regards
GGKRAJU
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Paul Mackerras @ 2005-05-20 4:24 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
Wolfgang Denk writes:
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
I am familiar with birecs and I have looked at the ARM atags
structure, which is the same as birecs at an abstract level, i.e. a
list of arbitrary blobs of data, each with a binary tag and a size.
As far as MIPS is concerned, there didn't seem to be any single
consistent way of passing information from the bootloader to the
kernel. They seem to be in a similar mess to ppc32 in this respect.
I want to avoid that mess for ppc64 by stating now, while there is
only one embedded ppc64 board that runs linux (the Maple eval board)
that there is one true way to pass information into the kernel at boot
time, and that is a flattened device tree.
Birecs and atags are both OK at representing a specified, limited set
of items of information, such as the location and size of an initrd
image or the total amount of memory in a system. They fall down when
it comes to giving information about the devices in the system and
their interconnections. For instance, atags has a structure for
representing a frame buffer - but what if you have two video cards in
your system?
Essentially, each element in the birecs/atags list is like a property
in a device tree that has only one node, and the entire birecs/atags
list is like a 1-node device tree. What the device tree gives you is
the ability to organize those pieces of information hierarchically so
that it becomes obvious when you have multiple instances of a device
(e.g. a PCI host bridge), what pieces of information apply to which
device instances, and which devices have to be used to get to certain
other devices.
Thus, my opinion is that the device tree is technically superior to
the birecs/atags approach. The device tree has also proven itself to
be capable of representing the information that the kernel needs about
all sorts of systems from the very small to the very large. Unless
you can come up with something even better, ppc64 won't be changing.
In particular we're not going to go back to anything like birecs or
atags.
Also, given that a minimal flattened device tree fits in well under
1kB, any arguments about "excessive" memory usage will need to be
accompanied by specific code and data sizes of a real-world example.
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
U-Boot currently doesn't support any ppc64 machines, does it? So
how is there a backward compatibility issue?
Ben's proposal is for ppc64, at least as present. If the ppc32
embedded developers decide they want to use a device tree, that would
be good, but it will proceed by
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
Other architectures are welcome to move to using a device tree. The
problem is going to be convincing them to spend the effort to make the
change. None of the other architectures currently have a solution
that is appealing.
Paul.
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Hollis Blanchard @ 2005-05-20 3:51 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
On May 19, 2005, at 8:18 AM, Wolfgang Denk wrote:
>
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
>
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
>
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
>
> Maybe you want to post the RFC to lkml, or at least to the
> linux-arm-kernel and linux-mips mailing lists?
As you observe, having multiple incompatible communication mechanisms
is an issue of u-boot code maintenance. Since you are the most affected
party, perhaps you could propose something for all the architectures?
You're obviously much more in tune with the needs of ARM and MIPS...
In the meantime, it sounds like this device tree stuff solves ppc64's
problem in a way the maintainers are happy with, so it's hard to ask
them to come up with a solution to a problem they don't have.
-Hollis
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Benjamin Herrenschmidt @ 2005-05-19 23:28 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <20050519231446.29487C1512@atlas.denx.de>
> I am aware that you think so, and I try to raise your awareness of
> the fact that there is a huge number of small machines out there.
>
> Please keep in mind that the same interface will be forced sooner or
> later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.
I will not force it, but others may find it a good idea to do so :)
> It is IMHO wrong to have only the boot loader side in mind. We should
> consider the whole system.
I do have the kernel in mind as well. The fact is the ppc64 kernel
relies on an Open Firmware device tree and we do not want at any cost to
get into the mess that is ppc32. We decided to define this flattened
format for that purpose, and to allow kexec functionality. I did my best
to keep the format as compact as possible (maybe a little bit more could
be saved by changing the way the full path are layed out, maybe we could
even do a new version which gzip's the while blob, but overall, it's
fairly small).
On the kernel side, as I wrote as well, the code for dealing with the
device-tree isn't that big, and will get smaller as I remove the
post-processing of nodes in prom.c that we still have here. And as I
wrote, if other platforms want to re-use that mecanism, they may want to
just use the compact/flattened format directly. The function for
scanning nodes in the flattened tree is about 40 lines of C and the
function for accessing a property in a flattened node is about as much.
>
> I think you are aware that there are several people out there working
> on a similar boot interface for the "small" PPC systems, too.
I know, and I was at the origin of the bi_rec proposal, a few years ago.
I've simply never seen anything actually happening.
> > No other solution will be accepted on the kernel side. At least for
> > ppc64
>
> This is not exactly a constructive position. When each architecture
> comes up with it's own solution for the same problem and then claims
> that no other solution will be accepted we will stick with what we
> have now: a mess.
>
> If this is really your position we may as well stop here.
The ppc64 kernel relies on an open firmware style device tree. That will
not change any time soon. This proposal is a way to define a subset of
this device-tree along with a compact & flattened format so that one
don't have to do a full Open Firmware implementation and so that mimal
trees can be used.
> Yes, of course. And using ATAGS is the only supported way to boot an
> ARM kernel, and so on.
>
> If everybody claims that his way of doing things is the only accepted
> solution we can really save all the time we are wasting on such a
> discussion.
Maybe. I'd rather have this proposal completed and have actual comments
about the _content_ of it rather than such a debate at this point. Once
we have that working, we can talk about extending it.
> > talks about backporting support for that to ppc32 as well. Other
> > architectures are welcome to use it too though :) The device-tree in the
>
> Ummm.. Ben, I have really high respect for you, but such a position
> is simply arrogant. With the same right the ARM folks can say that
> ATAGS is the way to go and other architectures are welcome to use it.
> Actually they might have older rights.
May well be. But that out of topic. The decision has been made already.
> > > Why don't we try to come up with a solution that is acceptable to the
> > > other architectures as well?
> >
> > This has been discussed over and over again, that is the best way to
> > never come up with a solution as everybody will want something different
> > and nobody will ever agree.
>
> With such a position I really wonder why you ever asked?
I'm asking for comments about the content of the proposal and posting to
inform people of what's going on. You are the one wanting to extend it
to other architectures :)
> > The present proposal is implemented today on the ppc64 kernel already,
> > and we have decided to not go backward on this requirement.
>
> The why the heck do you call this a RFC or a proposal? To me it seems
> that you don't propose but dictate a solution - a solution which
> pretty much ignores everything but your own requirements. If
> everything has been decided already I can as well shut up.
I'm asking for comments about the actual details of it, if something was
overlooked in the format (though that actually works today), if my
wording is wrong in parts, if we should define in more details some
aspect of it.
> But please never claim that this has been _discusssed_.
No, what I meant earlier is that trying to come up with something like
that, as you stated earlier, has been discussed again and again and
again without any useful result.
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Wolfgang Denk @ 2005-05-19 23:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <1116541230.5153.8.camel@gaston>
Dear Ben,
in message <1116541230.5153.8.camel@gaston> you wrote:
>
> > I have some concerns about the memory foot print and increased boot
> > time that will result from the proposed solution.
>
> Like everybody it seems, which is funny in a way as I expect pretty much
> none (or a few Kb maybe). The kernel side code for managing a
> device-tree may represent more, but heh, have you seen the size of a
I am not so narrow-minded to think only about U-Boot. I try to think
about the whole system, including boot loader, kernel, and any data
that might need to get passed between these two.
And please believe me, there are many, many systems out there where
"a few Kb" really matter.
> ppc64 kernel anyways ? I don't think that is very relevant. On the
I am aware that you think so, and I try to raise your awareness of
the fact that there is a huge number of small machines out there.
Please keep in mind that the same interface will be forced sooner or
later on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
RAM.
And when you sell 100,000 of these units per year then "a few Kb" may
cost a lot of money. Or may cause that other, prorietary OS get used.
> bootloader side, I don't expect any significant impact. The device-tree
> can be very small, and the code required on the bootloader side ranges
> from nothing for a pre-built one, to a little bit if the bootloader has
> to be able to change/add properties/nodes.
It is IMHO wrong to have only the boot loader side in mind. We should
consider the whole system.
> > There are many embedded systems where resources are tight and requirements
> > are aven tighter.
>
> Amen. (Though heh, this is ppc64, you can't be _that_ tight :)
I think you are aware that there are several people out there working
on a similar boot interface for the "small" PPC systems, too.
> >It would be probably a good idea to also ask for feedback
> > from these folks - for example by posting your RFC on the celinux-dev
> > mailing list.
>
> I will do when I have a little bit more mature proposal.
Thanks in advance.
> > But my biggest concern is that we should try to come up with a
> > solution that has a wider acceptance.
>
> No other solution will be accepted on the kernel side. At least for
> ppc64
This is not exactly a constructive position. When each architecture
comes up with it's own solution for the same problem and then claims
that no other solution will be accepted we will stick with what we
have now: a mess.
If this is really your position we may as well stop here.
> > As is, your proposal will add just another incompatible way of doing
> > the same thing (of course we will have to stay backward compatible
> > with U-Boot to allow booting older kernels, too).
>
> My proposal is the only supported way to boot a ppc64 kernel. There are
Yes, of course. And using ATAGS is the only supported way to boot an
ARM kernel, and so on.
If everybody claims that his way of doing things is the only accepted
solution we can really save all the time we are wasting on such a
discussion.
> talks about backporting support for that to ppc32 as well. Other
> architectures are welcome to use it too though :) The device-tree in the
Ummm.. Ben, I have really high respect for you, but such a position
is simply arrogant. With the same right the ARM folks can say that
ATAGS is the way to go and other architectures are welcome to use it.
Actually they might have older rights.
> > Why don't we try to come up with a solution that is acceptable to the
> > other architectures as well?
>
> This has been discussed over and over again, that is the best way to
> never come up with a solution as everybody will want something different
> and nobody will ever agree.
With such a position I really wonder why you ever asked?
> The present proposal is implemented today on the ppc64 kernel already,
> and we have decided to not go backward on this requirement.
The why the heck do you call this a RFC or a proposal? To me it seems
that you don't propose but dictate a solution - a solution which
pretty much ignores everything but your own requirements. If
everything has been decided already I can as well shut up.
But please never claim that this has been _discusssed_.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have made mistakes, but have never made the mistake of claiming I
never made one. - James G. Bennet
^ permalink raw reply
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
From: Benjamin Herrenschmidt @ 2005-05-19 22:20 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
On Thu, 2005-05-19 at 15:18 +0200, Wolfgang Denk wrote:
> Dear Ben,
>
> in message <1116478614.918.75.camel@gaston> you wrote:
> >
> > And here is a second draft with more infos.
> >
> > Booting the Linux/ppc64 kernel without Open Firmware
>
> Thanks a lot for taking the initiative to come to an agreement about
> the kernel boot interface.
>
> I have some concerns about the memory foot print and increased boot
> time that will result from the proposed solution.
Like everybody it seems, which is funny in a way as I expect pretty much
none (or a few Kb maybe). The kernel side code for managing a
device-tree may represent more, but heh, have you seen the size of a
ppc64 kernel anyways ? I don't think that is very relevant. On the
bootloader side, I don't expect any significant impact. The device-tree
can be very small, and the code required on the bootloader side ranges
from nothing for a pre-built one, to a little bit if the bootloader has
to be able to change/add properties/nodes.
> There are many embedded systems where resources are tight and requirements
> are aven tighter.
Amen. (Though heh, this is ppc64, you can't be _that_ tight :)
>It would be probably a good idea to also ask for feedback
> from these folks - for example by posting your RFC on the celinux-dev
> mailing list.
I will do when I have a little bit more mature proposal.
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance.
No other solution will be accepted on the kernel side. At least for
ppc64
> Especially from the U-Boot
> point of view it is not exactly nice that each of PowerPC, ARM and
> MIPS use their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
True.
> As is, your proposal will add just another incompatible way of doing
> the same thing (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
My proposal is the only supported way to boot a ppc64 kernel. There are
talks about backporting support for that to ppc32 as well. Other
architectures are welcome to use it too though :) The device-tree in the
kernel is fully expanded into a tree structure on ppc, since it's
heavily used by various pieces of code all over the place, but for other
architectures that would like to use that, it's possible to limit
themselves to the flattened format. The ppc64 kernel contains some code
to access nodes & properties directly from the flattened format (used
early during boot) which represents very little code.
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
This has been discussed over and over again, that is the best way to
never come up with a solution as everybody will want something different
and nobody will ever agree.
The present proposal is implemented today on the ppc64 kernel already,
and we have decided to not go backward on this requirement.
> Maybe you want to post the RFC to lkml, or at least to the
> linux-arm-kernel and linux-mips mailing lists?
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 20:36 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CF693.5030100@mrv.com>
[-- Attachment #1: Type: text/plain, Size: 2997 bytes --]
One thought though, if the event register is cleared _before_ the event
is processed (clearing the cause), will the cpm set the bit again
(before we have time to clear the cause) ? That would generate 2
interrupts for the same event ? Am I right ?
Guillaume Autran wrote:
> You are right, moving the event clearing statement is much easier and
> cleaner. Let the interrupt be the loop.
> Thanks Dan !
>
>
> Dan Malek wrote:
>
>>
>> On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
>>
>>> Is it better like this ?
>>
>>
>>
>> Yes, but now I see one problem with it. :-)
>>
>> We have to clear all events even though we may not
>> handle all of them. Your while loop filters only the events
>> we process, but there could be others causing the interrupt
>> which will never get cleared. In this case we end up with
>> an infinite interrupt loop where we don't process anything,
>> but we don't make the interrupt go away, either. It may be
>> easier to forget the loop, just read/clear the event register
>> up front, then process based on the events based upon
>> what we found. It's what we tend to do in the other drivers.
>>
>> The functions called to do the rx/tx processing have loops
>> in them to process all of the data they find, so it isn't likely
>> you have left anything behind. If you want to try to save
>> the interrupt overhead, change it to do/while, check again
>> at the end before the exit.
>>
>> Thanks.
>>
>>
>> -- Dan
>>
>
>------------------------------------------------------------------------
>
>diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
>--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
>+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 16:23:13.000000000 -0400
>@@ -336,22 +336,22 @@
>
> if (IS_SMC(pinfo)) {
> events = smcp->smc_smce;
>+ smcp->smc_smce = events;
> if (events & SMCM_BRKE)
> uart_handle_break(port);
> if (events & SMCM_RX)
> cpm_uart_int_rx(port, regs);
> if (events & SMCM_TX)
> cpm_uart_int_tx(port, regs);
>- smcp->smc_smce = events;
> } else {
> events = sccp->scc_scce;
>+ sccp->scc_scce = events;
> if (events & UART_SCCM_BRKE)
> uart_handle_break(port);
> if (events & UART_SCCM_RX)
> cpm_uart_int_rx(port, regs);
> if (events & UART_SCCM_TX)
> cpm_uart_int_tx(port, regs);
>- sccp->scc_scce = events;
> }
> return (events) ? IRQ_HANDLED : IRQ_NONE;
> }
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 3900 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Dan Malek @ 2005-05-19 20:32 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CF693.5030100@mrv.com>
On May 19, 2005, at 4:26 PM, Guillaume Autran wrote:
> You are right, moving the event clearing statement is much easier and
> cleaner. Let the interrupt be the loop.
I also just had the thought we could check the events for non-zero,
clear them, and process only the ones we wanted. That would save
the interrupt overhead if we had high speed ports (which I really
don't like for normal RS-232 anyway :-)).
I'll move this patch ahead.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 20:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <5e493590088edcf959e30390363e798d@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
You are right, moving the event clearing statement is much easier and
cleaner. Let the interrupt be the loop.
Thanks Dan !
Dan Malek wrote:
>
> On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
>
>> Is it better like this ?
>
>
> Yes, but now I see one problem with it. :-)
>
> We have to clear all events even though we may not
> handle all of them. Your while loop filters only the events
> we process, but there could be others causing the interrupt
> which will never get cleared. In this case we end up with
> an infinite interrupt loop where we don't process anything,
> but we don't make the interrupt go away, either. It may be
> easier to forget the loop, just read/clear the event register
> up front, then process based on the events based upon
> what we found. It's what we tend to do in the other drivers.
>
> The functions called to do the rx/tx processing have loops
> in them to process all of the data they find, so it isn't likely
> you have left anything behind. If you want to try to save
> the interrupt overhead, change it to do/while, check again
> at the end before the exit.
>
> Thanks.
>
>
> -- Dan
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: cpm_uart_core.patch --]
[-- Type: text/plain, Size: 970 bytes --]
diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 16:23:13.000000000 -0400
@@ -336,22 +336,22 @@
if (IS_SMC(pinfo)) {
events = smcp->smc_smce;
+ smcp->smc_smce = events;
if (events & SMCM_BRKE)
uart_handle_break(port);
if (events & SMCM_RX)
cpm_uart_int_rx(port, regs);
if (events & SMCM_TX)
cpm_uart_int_tx(port, regs);
- smcp->smc_smce = events;
} else {
events = sccp->scc_scce;
+ sccp->scc_scce = events;
if (events & UART_SCCM_BRKE)
uart_handle_break(port);
if (events & UART_SCCM_RX)
cpm_uart_int_rx(port, regs);
if (events & UART_SCCM_TX)
cpm_uart_int_tx(port, regs);
- sccp->scc_scce = events;
}
return (events) ? IRQ_HANDLED : IRQ_NONE;
}
^ permalink raw reply
* Re: tah reset?
From: Eugene Surovegin @ 2005-05-19 20:13 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA21A7B9E@exchange.tsi-telsys.com>
On Thu, May 19, 2005 at 03:45:50PM -0400, Sanjay Bajaj wrote:
> Eugene,
>
> Yes, TAH0 in SDR0_MFR register is enabled.
>
> EMAC is able to reset correctly, but TAH isn't at the same location
> [in emac_probe()]. PHY is connected to EMAC and TAH is behind EMAC.
> I do not understand how the RX clock from PHY will reach TAH? Any suggestions ?
E.g. TAH RX path is clocked from the same source as EMAC, I think
it's quite obvious, but I digress.
What are you doing? Having problems with EMAC driver? What kernel
version? What board?
You can try my new NAPI EMAC driver (http://kernel.ebshome.net/).
--
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Dan Malek @ 2005-05-19 19:54 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CEA55.1040904@mrv.com>
On May 19, 2005, at 3:34 PM, Guillaume Autran wrote:
> Is it better like this ?
Yes, but now I see one problem with it. :-)
We have to clear all events even though we may not
handle all of them. Your while loop filters only the events
we process, but there could be others causing the interrupt
which will never get cleared. In this case we end up with
an infinite interrupt loop where we don't process anything,
but we don't make the interrupt go away, either. It may be
easier to forget the loop, just read/clear the event register
up front, then process based on the events based upon
what we found. It's what we tend to do in the other drivers.
The functions called to do the rx/tx processing have loops
in them to process all of the data they find, so it isn't likely
you have left anything behind. If you want to try to save
the interrupt overhead, change it to do/while, check again
at the end before the exit.
Thanks.
-- Dan
^ permalink raw reply
* RE: tah reset?
From: Sanjay Bajaj @ 2005-05-19 19:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Eugene,
Yes, TAH0 in SDR0_MFR register is enabled.
EMAC is able to reset correctly, but TAH isn't at the same location [in =
emac_probe()]. PHY is connected to EMAC and TAH is behind EMAC. I do not =
understand how the RX clock from PHY will reach TAH? Any suggestions ?
Thanks,
Sanjay
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Thursday, May 19, 2005 2:23 PM
To: Sanjay Bajaj
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: tah reset?
On Thu, May 19, 2005 at 02:14:20PM -0400, Sanjay Bajaj wrote:
> While trying to reset the TAH on emac2 of PPC440GX, the Soft Reset=20
> (SR) bit never resets itself to 0. Does anybody know the reason for=20
> it?
Did you enable TAH0 in SDR0_MFR register?
Also, I don't remember for sure, but TAH may have the same problem as=20
EMAC, namely, it won't go out of reset if there is no RX clock from=20
PHY.
--=20
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Guillaume Autran @ 2005-05-19 19:34 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <2376d87e3df664106a6cf626f9575d90@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Is it better like this ?
Dan Malek wrote:
>
> On May 19, 2005, at 1:59 PM, Guillaume Autran wrote:
>
>> Any comment ?
>
>
> The idea is fine. Read Documentation/CodingStyle and try again .....
>
> Thanks.
>
>
> -- Dan
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: cpm_uart_core.patch --]
[-- Type: text/plain, Size: 1560 bytes --]
diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c
--- linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-07 01:20:31.000000000 -0400
+++ linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c 2005-05-19 15:31:03.000000000 -0400
@@ -335,23 +335,25 @@
pr_debug("CPM uart[%d]:IRQ\n", port->line);
if (IS_SMC(pinfo)) {
- events = smcp->smc_smce;
- if (events & SMCM_BRKE)
- uart_handle_break(port);
- if (events & SMCM_RX)
- cpm_uart_int_rx(port, regs);
- if (events & SMCM_TX)
- cpm_uart_int_tx(port, regs);
- smcp->smc_smce = events;
+ while ((events = smcp->smc_smce) & (SMCM_BRKE | SMCM_RX | SMCM_TX)) {
+ smcp->smc_smce = events;
+ if (events & SMCM_BRKE)
+ uart_handle_break(port);
+ if (events & SMCM_RX)
+ cpm_uart_int_rx(port, regs);
+ if (events & SMCM_TX)
+ cpm_uart_int_tx(port, regs);
+ }
} else {
- events = sccp->scc_scce;
- if (events & UART_SCCM_BRKE)
- uart_handle_break(port);
- if (events & UART_SCCM_RX)
- cpm_uart_int_rx(port, regs);
- if (events & UART_SCCM_TX)
- cpm_uart_int_tx(port, regs);
- sccp->scc_scce = events;
+ while ((events = sccp->scc_scce) & (UART_SCCM_BRKE | UART_SCCM_RX | UART_SCCM_TX)) {
+ sccp->scc_scce = events;
+ if (events & UART_SCCM_BRKE)
+ uart_handle_break(port);
+ if (events & UART_SCCM_RX)
+ cpm_uart_int_rx(port, regs);
+ if (events & UART_SCCM_TX)
+ cpm_uart_int_tx(port, regs);
+ }
}
return (events) ? IRQ_HANDLED : IRQ_NONE;
}
^ permalink raw reply
* Re: tah reset?
From: Eugene Surovegin @ 2005-05-19 18:23 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA21A7B9D@exchange.tsi-telsys.com>
On Thu, May 19, 2005 at 02:14:20PM -0400, Sanjay Bajaj wrote:
> While trying to reset the TAH on emac2 of PPC440GX, the Soft Reset
> (SR) bit never resets itself to 0. Does anybody know the reason for
> it?
Did you enable TAH0 in SDR0_MFR register?
Also, I don't remember for sure, but TAH may have the same problem as
EMAC, namely, it won't go out of reset if there is no RX clock from
PHY.
--
Eugene
^ permalink raw reply
* tah reset?
From: Sanjay Bajaj @ 2005-05-19 18:14 UTC (permalink / raw)
To: linuxppc-embedded
While trying to reset the TAH on emac2 of PPC440GX, the Soft Reset (SR) =
bit never resets itself to 0. Does anybody know the reason for it?
Sanjay
^ 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