* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 19:04 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <44510E4D.5040504@icarus.com>
On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote:
> Eugene Surovegin wrote:
> > There are bigger problems with 4xx support in 2.4 mainline than just
> > missing some chips support.
> >
> > Some parts which are already in 2.4 (e.g. ethernet driver) are of
> > non-production quality.
> >
> > I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
> > change shouldn't break anything, but this will not make 2.4 support
> > really useful for real world deployments. I think we are stuck with
> > maintaining our own 2.4 trees with backports from 2.6. This is what I
> > do myself of all our products (and yeah, diff between stock 2.4.32 and
> > my internal version has already grown quite big to be acceptable for
> > 2.4 inclusion).
> >
>
> Of course we are going to have to keep our own per-board trees.
> but the blatantly common stuff, like the core 405gpr support and
> certain drivers, might as well go in if the gatekeeper can be
> convinced. You and I both probably have huge drivers for custom
> devices hanging off our PPCs, with various hacks to squeeze extra
> performance out. These make our transition to 2.6 difficult, and
> surely we are not alone.
Well, personally, I don't migrate to 2.6 not because I have many custom
drivers in my tree (if they are properly written, migration is
relatively easy), but because 2.6 in my opinion isn't production
ready, at least for architectures I work with. 2.6 is slower, bigger,
is constantly being broken by huge amount of changes, etc. I spent
enough time making 2.4 work on our hardware given limitations and
requirements put on performance, resources etc. I just don't have time
to go through this cycle again. And I'm not talking about PPC stuff, I
mean mostly generic stuff - filesystems, scheduling, networking, etc.
> So 2.4 is going to be around for a while longer for us, so we might
> as well make an effort to keep the house in some sort of order. It
> serves no one to keep these fixes a secret:-)
They aren't secret, but I can understand the simple fact that 2.4 is
closed for a new stuff, we might not like that (although I do, just
look at the mess "stable" 2.6 is :).
There is a point in every piece of software life-cycle when you have
to stop adding features. 2.4 is already at this point, and we should
accept that.
--
Eugene
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-04-27 18:32 UTC (permalink / raw)
To: Matt Porter, linuxppc-embedded
In-Reply-To: <20060427180743.GB11206@gate.ebshome.net>
Eugene Surovegin wrote:
> There are bigger problems with 4xx support in 2.4 mainline than just
> missing some chips support.
>
> Some parts which are already in 2.4 (e.g. ethernet driver) are of
> non-production quality.
>
> I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
> change shouldn't break anything, but this will not make 2.4 support
> really useful for real world deployments. I think we are stuck with
> maintaining our own 2.4 trees with backports from 2.6. This is what I
> do myself of all our products (and yeah, diff between stock 2.4.32 and
> my internal version has already grown quite big to be acceptable for
> 2.4 inclusion).
>
Of course we are going to have to keep our own per-board trees.
but the blatantly common stuff, like the core 405gpr support and
certain drivers, might as well go in if the gatekeeper can be
convinced. You and I both probably have huge drivers for custom
devices hanging off our PPCs, with various hacks to squeeze extra
performance out. These make our transition to 2.6 difficult, and
surely we are not alone.
So 2.4 is going to be around for a while longer for us, so we might
as well make an effort to keep the house in some sort of order. It
serves no one to keep these fixes a secret:-)
In any case, if the patches I sent are rejected, then that's that.
We'll see.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re-configuring busybox that comes with DENX's ELDK SELF
From: Randy Smith @ 2006-04-27 18:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060427180743.GB11206@gate.ebshome.net>
Hello,
I have a weird situation that I am very confused about and I was
wondering if some kind soul would point me in the right direction?
I have a working powerpc embedded system using the 2.4 kernel built with
DENX' ELDK and root file system from DENX' SELF.
I am trying to enable some additional applets in the busybox (well, tftp
anyway) that came with SELF. I am using the ELDK cross toolchain on an
x86 box to build everything and the powerpc board itself is based on an
Icecube board. I thought I could do the following...
1. Download the source for busybox and compile it using the cross tools
from DENX.
2. Install it in my target root file system
3. Make the jffs2 file system image and flash it into the unit under test.
When I do this, the kernel loads and boots just like before and then
hangs after is says it is freeing unused memory. I am assuming that this
is where it is trying to run the new init that I just installed, so
obviously it isn't working like I planned.
Where did I go wrong?
I am thinking that I have a library mismatch/issue and that the new init
binary can't/won't run with the runtime libraries that come with SELF,
but I don't know how to go about correcting this if this is the case.
Opinions or urls to tutorials welcome.
Thanks,
-Randy Smith
Software Engineer
Imagemap, Inc.
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 18:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060426191957.14C4F353DAC@atlas.denx.de>
On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:
> In message <A8793E99-83C1-4FD9-8735-
> D2E8F98B3003@kernel.crashing.org> you wrote:
>>
>> I think thats part of the idea with arch/powerpc defining a standard
>> mechanism for how a boot loader should pass information to the kernel
>> (via a flat device tree).
>
> Yet another standard.
>
>> How would you propose that we handle booting arch/powerpc kernels
>> from u-boot going forward? (for new board ports and existing board
>> ports).
>
> Ideally, I'd like to see a common kernel interface for all archi-
> tectures, PowerPC and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.
>
> I will accept what is decided by the P.T.B., but I request not to
> break backwards compatibility with existing systems.
I've been thinking about the various issues related to booting an
arch/powerpc kernel via u-boot. I was hoping to get some ideas/
comments on what people thought about the various issues/questions
related to producing a system that can boot an arch/powerpc kernel
for an embedded system. I'm using u-boot as the boot loader since
its a popular choice (I imagine the issues are similar for others):
[NOTE: dts, flat dev tree, etc are used interchangeably]
1. boot with an "old" u-boot (via bd_t):
* Have a boot wrapper that takes bd_t and dts and merges them @ runtime
* Boot wrapper has to be custom based on bd_t definition for the system
* dts owned by kernel??
2. boot with a "new" u-boot (has a .dts in it):
* capable of booting arch/powerpc kernel directly w/o modification
* in a production system don't want to update u-boot
* dts owned by u-boot??
Some questions/issues:
* ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the
build of either depend on the user grabbing a dts from some third
party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
port. Boards ship with an "old" u-boot, thus we need a kernel
wrapper with .dts. However, newer u-boot's can (hopefully will) have
a dts in them
* updating of dts: In case 1, this is trivial since its part of the
kernel blob. Case 2. is more difficult. What do people think of
treating the dts like the environment. You have a version compiled
in, but can alternately have a blob in another location that will be
used if exists. This would allow one to update the dts portion w/o
effecting the actual boot loader.
* one solution to the copies of .dts is that we make the wrapper
portion of the kernel the owner of the official latest and
greatest .dts. Every so often a maintainer can sync their .dts with
u-boot to keep them relatively in sync. However, the main mechanism
would be to load the latest .dts blob into the secondary location.
We can provide scripts/tools to do this via u-boot and linux.
comments, other issues people have thought of?
- kumar
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 18:07 UTC (permalink / raw)
To: Matt Porter; +Cc: Stephen Williams, linuxppc-embedded
In-Reply-To: <20060426163540.H16236@cox.net>
On Wed, Apr 26, 2006 at 04:35:40PM -0700, Matt Porter wrote:
> linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
> to take "new stuff" into linux-2.4 at that time either.
>
> There's still rsync://source.mvista.com/linuxppc-2.4 available with
> the 405gpr/sycamore support.
There are bigger problems with 4xx support in 2.4 mainline than just
missing some chips support.
Some parts which are already in 2.4 (e.g. ethernet driver) are of
non-production quality.
I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
change shouldn't break anything, but this will not make 2.4 support
really useful for real world deployments. I think we are stuck with
maintaining our own 2.4 trees with backports from 2.6. This is what I
do myself of all our products (and yeah, diff between stock 2.4.32 and
my internal version has already grown quite big to be acceptable for
2.4 inclusion).
--
Eugene
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 18:01 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <445008E1.70404@icarus.com>
On Wed, Apr 26, 2006 at 04:57:21PM -0700, Stephen Williams wrote:
> Is there a git tree for main line 2.4 maintenance
> (against which I could maintain patches)
git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/linux-2.4.git
--
Eugene
^ permalink raw reply
* RE: [QUESTION] MPC834x DMA Support
From: KRONSTORFER Horst @ 2006-04-27 17:23 UTC (permalink / raw)
To: wd; +Cc: linuxppc-dev
> -----Original Message-----
> From: wd@denx.de [mailto:wd@denx.de]=20
> Sent: Donnerstag, 27. April 2006 18:28
> To: KRONSTORFER Horst
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [QUESTION] MPC834x DMA Support=20
>=20
> In message=20
> <C5BA91F04186584EB68FD42BB4993E6BC1B5C6@FRQWOLEX01.frequentis.
> frq> you wrote:
> >=20
> > does anyone know if the mpc834x's dma unit supports dma=20
> operation only=20
> > between pci and csb or also between csb and csb, f.e. devices=20
> > connected via the lbc (f.e. ram and a dsp)?
>=20
> This should work. We used this to initialize ECC memory. =20
> But be careful about your performance expectations - ask=20
> Freescale what you can get out of memory to memory DMA.=20
> [Sorry, I'm still waiting for replies from FSL myself.]
>
thanks for the hints!
-h
=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:=20
> wd@denx.de You speak of courage. Obviously you do not know=20
> the difference bet- ween courage and foolhardiness. Always=20
> it is the brave ones who die, the soldiers.
> -- Kor, the Klingon Commander, "Errand of Mercy",
> stardate 3201.7
>=20
^ permalink raw reply
* RE: [QUESTION] MPC834x DMA Support
From: KRONSTORFER Horst @ 2006-04-27 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Donnerstag, 27. April 2006 17:25
> To: KRONSTORFER Horst
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [QUESTION] MPC834x DMA Support
>=20
>=20
> On Apr 27, 2006, at 5:37 AM, KRONSTORFER Horst wrote:
>=20
> > hi!
> >
> > does anyone know if the mpc834x's dma unit supports dma=20
> operation only=20
> > between pci and csb or also between csb and csb, f.e. devices=20
> > connected via the lbc (f.e. ram and a dsp)?
>=20
> You should be able to do csb to csb devices.
thanks for the hint!
-h
>=20
> - kumar
>=20
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Kyle Moffett @ 2006-04-27 17:13 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427123701.GG32127@wohnheim.fh-wedel.de>
On Apr 27, 2006, at 08:37:01, J=F6rn Engel wrote:
> On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
>> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
>> adapter_handle,
>> + struct ehca_pfqp *pfqp,
>> + const u8 servicetype,
>> + const u8 daqp_ctrl,
>> + const u8 signalingtype,
>> + const u8 ud_av_l_key_ctl,
>> + const struct ipz_cq_handle send_cq_handle,
>> + const struct ipz_cq_handle =
receive_cq_handle,
>> + const struct ipz_eq_handle async_eq_handle,
>> + const u32 qp_token,
>> + const struct ipz_pd pd,
>> + const u16 max_nr_send_wqes,
>> + const u16 max_nr_receive_wqes,
>> + const u8 max_nr_send_sges,
>> + const u8 max_nr_receive_sges,
>> + const u32 ud_av_l_key,
>> + struct ipz_qp_handle *qp_handle,
>> + u32 * qp_nr,
>> + u16 * act_nr_send_wqes,
>> + u16 * act_nr_receive_wqes,
>> + u8 * act_nr_send_sges,
>> + u8 * act_nr_receive_sges,
>> + u32 * nr_sq_pages,
>> + u32 * nr_rq_pages,
>> + struct h_galpas *h_galpas);
>
> 25 parameters? If you tell me which drugs were involved in this =20
> code, I know what to stay away from. Might be the current record =20
> for any code ever proposed for inclusion.
>
> The whole patch is full of parameter-happy functions with this one =20
> being the ugly top of the iceberg. I sincerely hope this is not a =20
> defined ABI and can still be changed.
What's worse; look at the stack usage on that sucker alone:
10 pointers, 6 u8, 2 u16, 2 u32, and topped off with 3 unknown-sized =20
"struct ipz_cq_handle", an unknown-sized "struct ipz_pd". The =20
alignment alone probably chews up at least another couple bytes in =20
there somewhere too. That's at _least_ 98 + 3*sizeof(struct =20
ipz_cq_handle) + sizeof(struct ipz_pd) on a 64-bit platform (58 + =20
3*sizeof(struct ipz_cq_handle) + sizeof(struct ipz_pd) on 32-bit). =20
Not to mention the fact that you totally screwed the compiler's =20
chances of ever passing the important stuff in registers. And you =20
haven't even gotten into local variables yet.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-04-27 16:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, LKML
OK, one more time, cause I'm an idiot, and can't type.
--------------------------------
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-04-27 16:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, LKML
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-04-27 16:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e2ov5s$1hn$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!
The attached patch adds the ibm405gpr support files from various
places and adds the core support to Linux 2.4. Although this diff
was done relative Marcelo's git tree, it actually touches no C files,
only a few config and make files (Plus it adds the gpr support c/h
files) so it should apply to any recent 2.4 kernel tree.
I'm almost ready with a patch that does a similar thing with
the SystemACE driver.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
[-- Attachment #2: 0001-Core-ppc405GPr-support.txt --]
[-- Type: text/plain, Size: 12383 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Stephen Williams <steve@wing.icarus.com>
Date: Thu Apr 27 08:45:41 2006 -0700
Subject: [PATCH] Core ppc405GPr support.
Signed-off-by: Stephen Williams <steve@wing.icarus.com>
---
arch/ppc/config.in | 3 -
arch/ppc/platforms/Makefile | 1
arch/ppc/platforms/ibm405gpr.c | 108 ++++++++++++++++++++++
arch/ppc/platforms/ibm405gpr.h | 193 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 304 insertions(+), 1 deletions(-)
create mode 100644 arch/ppc/platforms/ibm405gpr.c
create mode 100644 arch/ppc/platforms/ibm405gpr.h
ac23ca9a2f268eec56eea0edd595502ef6e94abc
diff --git a/arch/ppc/config.in b/arch/ppc/config.in
index ade3865..089d479 100644
--- a/arch/ppc/config.in
+++ b/arch/ppc/config.in
@@ -232,7 +232,8 @@ if [ "$CONFIG_4xx" = "y" ]; then
#
# Set options based on processor implementation
#
- if [ "$CONFIG_405GP" = "y" -o "$CONFIG_STB03xxx" = "y" ]; then
+ if [ "$CONFIG_405GP" = "y" -o "$CONFIG_405GPR" = "y" \
+ -o "$CONFIG_STB03xxx" = "y" ]; then
define_bool CONFIG_IBM_OCP y
define_bool CONFIG_PPC_OCP y
define_bool CONFIG_405 y
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
index ab84e70..3aaebc6 100644
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -29,6 +29,7 @@ O_TARGET := platform.o
export-objs := prep_setup.o ibm440gp.o ibm440gx.o
obj-$(CONFIG_405GP) += ibm405gp.o
+obj-$(CONFIG_405GPR) += ibm405gpr.o
obj-$(CONFIG_440GP) += ibm440gp.o
obj-$(CONFIG_440GX) += ibm440gx.o
diff --git a/arch/ppc/platforms/ibm405gpr.c b/arch/ppc/platforms/ibm405gpr.c
new file mode 100644
index 0000000..1e05b7d
--- /dev/null
+++ b/arch/ppc/platforms/ibm405gpr.c
@@ -0,0 +1,108 @@
+/*
+ *
+ * Copyright 2000-2002 MontaVista Software Inc.
+ * Current maintainer
+ * Armin Kuster akuster@mvista.com
+ *
+ * Module name: ibm405gpr.c
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/threads.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <platforms/ibm405gpr.h>
+#include <asm/ibm4xx.h>
+#include <asm/ocp.h>
+
+static struct ocp_func_emac_data ibm405gpr_emac0_def = {
+ .zmii_idx = -1, /* ZMII device index */
+ .zmii_mux = 0, /* ZMII input of this EMAC */
+ .mal_idx = 0, /* MAL device index */
+ .mal_rx_chan = 0, /* MAL rx channel number */
+ .mal_tx1_chan = 0, /* MAL tx channel 1 number */
+ .mal_tx2_chan = 1, /* MAL tx channel 2 number */
+ .wol_irq = BL_MAC_WOL, /* WOL interrupt number */
+ .mdio_idx = -1, /* No shared MDIO */
+};
+
+static struct ocp_func_mal_data ibm405gpr_mal0_def = {
+ .num_tx_chans = 2*EMAC_NUMS, /* Number of TX channels */
+ .num_rx_chans = EMAC_NUMS, /* Number of RX channels */
+};
+
+struct ocp_def core_ocp[] __initdata = {
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_OPB,
+ .index = 0,
+ .paddr = OPB_BASE_START,
+ .irq = OCP_IRQ_NA,
+ .pm = OCP_CPM_NA,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index = 0,
+ .paddr = UART0_IO_BASE,
+ .irq = UART0_INT,
+ .pm = IBM_CPM_UART0
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_16550,
+ .index = 1,
+ .paddr = UART1_IO_BASE,
+ .irq = UART1_INT,
+ .pm = IBM_CPM_UART1
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_IIC,
+ .paddr = IIC0_BASE,
+ .irq = IIC0_IRQ,
+ .pm = IBM_CPM_IIC0
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_GPIO,
+ .paddr = GPIO0_BASE,
+ .irq = OCP_IRQ_NA,
+ .pm = IBM_CPM_GPIO0
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_MAL,
+ .paddr = OCP_PADDR_NA,
+ .irq = OCP_IRQ_NA,
+ .pm = OCP_CPM_NA,
+ .additions = &ibm405gpr_mal0_def,
+ },
+ { .vendor = OCP_VENDOR_IBM,
+ .function = OCP_FUNC_EMAC,
+ .index = 0,
+ .paddr = EMAC0_BASE,
+ .irq = BL_MAC_ETH0,
+ .pm = IBM_CPM_EMAC0,
+ .additions = &ibm405gpr_emac0_def,
+ },
+ { .vendor = OCP_VENDOR_INVALID
+ }
+};
diff --git a/arch/ppc/platforms/ibm405gpr.h b/arch/ppc/platforms/ibm405gpr.h
new file mode 100644
index 0000000..273274c
--- /dev/null
+++ b/arch/ppc/platforms/ibm405gpr.h
@@ -0,0 +1,193 @@
+/*
+ * ibm405gpr.h
+ *
+ *
+ * Armin Kuster akuster@mvista.com
+ * Aug, 2002
+ *
+ *
+ * Copyright 2002 MontaVista Softare Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Version 1.0 (10/01/02) - A. Kuster
+ * Initial version
+ *
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_IBM405GPR_H__
+#define __ASM_IBM405GPR_H__
+
+#include <linux/config.h>
+#include <platforms/ibm_ocp.h>
+
+/* ibm405.h at bottom of this file */
+
+/* PCI
+ * PCI Bridge config reg definitions
+ * see 17-19 of manual
+ */
+
+#define PPC405_PCI_CONFIG_ADDR 0xeec00000
+#define PPC405_PCI_CONFIG_DATA 0xeec00004
+
+#define PPC405_PCI_PHY_MEM_BASE 0x80000000 /* hose_a->pci_mem_offset */
+ /* setbat */
+#define PPC405_PCI_MEM_BASE PPC405_PCI_PHY_MEM_BASE /* setbat */
+#define PPC405_PCI_PHY_IO_BASE 0xe8000000 /* setbat */
+#define PPC405_PCI_IO_BASE PPC405_PCI_PHY_IO_BASE /* setbat */
+
+#define PPC405_PCI_LOWER_MEM 0x80000000 /* hose_a->mem_space.start */
+#define PPC405_PCI_UPPER_MEM 0xBfffffff /* hose_a->mem_space.end */
+#define PPC405_PCI_LOWER_IO 0x00000000 /* hose_a->io_space.start */
+#define PPC405_PCI_UPPER_IO 0x0000ffff /* hose_a->io_space.end */
+
+#define PPC405_ISA_IO_BASE PPC405_PCI_IO_BASE
+
+#define PPC4xx_PCI_IO_PADDR ((uint)PPC405_PCI_PHY_IO_BASE)
+#define PPC4xx_PCI_IO_VADDR PPC4xx_PCI_IO_PADDR
+#define PPC4xx_PCI_IO_SIZE ((uint)64*1024)
+#define PPC4xx_PCI_CFG_PADDR ((uint)PPC405_PCI_CONFIG_ADDR)
+#define PPC4xx_PCI_CFG_VADDR PPC4xx_PCI_CFG_PADDR
+#define PPC4xx_PCI_CFG_SIZE ((uint)4*1024)
+#define PPC4xx_PCI_LCFG_PADDR ((uint)0xef400000)
+#define PPC4xx_PCI_LCFG_VADDR PPC4xx_PCI_LCFG_PADDR
+#define PPC4xx_PCI_LCFG_SIZE ((uint)4*1024)
+#define PPC4xx_ONB_IO_PADDR ((uint)0xef600000)
+#define PPC4xx_ONB_IO_VADDR PPC4xx_ONB_IO_PADDR
+#define PPC4xx_ONB_IO_SIZE ((uint)4*1024)
+
+/* serial port defines */
+#define RS_TABLE_SIZE 2
+
+#define UART0_INT 0
+#define UART1_INT 1
+
+#define OPB_BASE_START 0x40000000
+#define EBIU_BASE_START 0xF0100000
+#define PCIL0_BASE 0xEF400000
+#define UART0_IO_BASE 0xEF600300
+#define UART1_IO_BASE 0xEF600400
+#define IIC0_BASE 0xEF600500
+#define OPB0_BASE 0xEF600600
+#define GPIO0_BASE 0xEF600700
+#define EMAC0_BASE 0xEF600800
+#define BL_MAC_WOL 9 /* WOL */
+#define BL_MAL_SERR 10 /* MAL SERR */
+#define BL_MAL_TXDE 13 /* MAL TXDE */
+#define BL_MAL_RXDE 14 /* MAL RXDE */
+#define BL_MAL_TXEOB 11 /* MAL TX EOB */
+#define BL_MAL_RXEOB 12 /* MAL RX EOB */
+#define BL_MAC_ETH0 15 /* MAC */
+
+#define EMAC_NUMS 1
+#define IIC0_IRQ 2
+
+#define IIC_OWN 0x55
+#define IIC_CLOCK 50
+#define BD_EMAC_ADDR(e,i) bi_enetaddr[i]
+
+#define STD_UART_OP(num) \
+ { 0, BASE_BAUD, 0, UART##num##_INT, \
+ (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
+ iomem_base: (u8 *)UART##num##_IO_BASE, \
+ io_type: SERIAL_IO_MEM},
+
+#if defined(CONFIG_UART0_TTYS0)
+#define SERIAL_DEBUG_IO_BASE UART0_IO_BASE
+#define SERIAL_PORT_DFNS \
+ STD_UART_OP(0) \
+ STD_UART_OP(1)
+#endif
+
+#if defined(CONFIG_UART0_TTYS1)
+#define SERIAL_DEBUG_IO_BASE UART1_IO_BASE
+#define SERIAL_PORT_DFNS \
+ STD_UART_OP(1) \
+ STD_UART_OP(0)
+#endif
+
+/* DCR defines */
+#define DCRN_CHCR_BASE 0x0B1
+#define DCRN_CHPSR_BASE 0x0B4
+#define DCRN_CPMSR_BASE 0x0B8
+#define DCRN_CPMFR_BASE 0x0BA
+
+#define CHR0_U0EC 0x00000080 /* Select external clock for UART0 */
+#define CHR0_U1EC 0x00000040 /* Select external clock for UART1 */
+#define CHR0_UDIV 0x0000003E /* UART internal clock divisor */
+#define CHR1_CETE 0x00800000 /* CPU external timer enable */
+
+#define DCRN_CHPSR_BASE 0x0B4
+#define PSR_PLL_FWD_MASK 0xC0000000
+#define PSR_PLL_FDBACK_MASK 0x30000000
+#define PSR_PLL_TUNING_MASK 0x0E000000
+#define PSR_PLB_CPU_MASK 0x01800000
+#define PSR_OPB_PLB_MASK 0x00600000
+#define PSR_PCI_PLB_MASK 0x00180000
+#define PSR_EB_PLB_MASK 0x00060000
+#define PSR_ROM_WIDTH_MASK 0x00018000
+#define PSR_ROM_LOC 0x00004000
+#define PSR_PCI_ASYNC_EN 0x00001000
+#define PSR_PCI_ARBIT_EN 0x00000400
+
+#define IBM_CPM_IIC0 0x80000000 /* IIC interface */
+#define IBM_CPM_PCI 0x40000000 /* PCI bridge */
+#define IBM_CPM_CPU 0x20000000 /* processor core */
+#define IBM_CPM_DMA 0x10000000 /* DMA controller */
+#define IBM_CPM_OPB 0x08000000 /* PLB to OPB bridge */
+#define IBM_CPM_DCP 0x04000000 /* CodePack */
+#define IBM_CPM_EBC 0x02000000 /* ROM/SRAM peripheral controller */
+#define IBM_CPM_SDRAM0 0x01000000 /* SDRAM memory controller */
+#define IBM_CPM_PLB 0x00800000 /* PLB bus arbiter */
+#define IBM_CPM_GPIO0 0x00400000 /* General Purpose IO (??) */
+#define IBM_CPM_UART0 0x00200000 /* serial port 0 */
+#define IBM_CPM_UART1 0x00100000 /* serial port 1 */
+#define IBM_CPM_UIC 0x00080000 /* Universal Interrupt Controller */
+#define IBM_CPM_TMRCLK 0x00040000 /* CPU timers */
+#define IBM_CPM_EMAC0 0x00020000 /* on-chip ethernet MM unit */
+#define DFLT_IBM4xx_PM ~(IBM_CPM_PCI | IBM_CPM_CPU | IBM_CPM_DMA \
+ | IBM_CPM_OPB | IBM_CPM_EBC \
+ | IBM_CPM_SDRAM0 | IBM_CPM_PLB \
+ | IBM_CPM_UIC | IBM_CPM_TMRCLK)
+
+#define DCRN_DMA0_BASE 0x100
+#define DCRN_DMA1_BASE 0x108
+#define DCRN_DMA2_BASE 0x110
+#define DCRN_DMA3_BASE 0x118
+#define DCRNCAP_DMA_SG 1 /* have DMA scatter/gather capability */
+#define DCRN_DMASR_BASE 0x120
+#define DCRN_EBC_BASE 0x012
+#define DCRN_DCP0_BASE 0x014
+#define DCRN_MAL_BASE 0x180
+#define DCRN_OCM0_BASE 0x018
+#define DCRN_PLB0_BASE 0x084
+#define DCRN_PLLMR_BASE 0x0B0
+#define DCRN_POB0_BASE 0x0A0
+#define DCRN_SDRAM0_BASE 0x010
+#define DCRN_UIC0_BASE 0x0C0
+#define UIC0 DCRN_UIC0_BASE
+
+#include <platforms/ibm405.h>
+
+#endif /* __ASM_IBM405GPR_H__ */
+#endif /* __KERNEL__ */
--
1.2.6
^ permalink raw reply related
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-04-27 16:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, linux-kernel
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply
* Re: u-boot.bin
From: Wolfgang Denk @ 2006-04-27 16:30 UTC (permalink / raw)
To: Eric Heim; +Cc: linuxppc-embedded
In-Reply-To: <20060427160755.24553.qmail@web37812.mail.mud.yahoo.com>
In message <20060427160755.24553.qmail@web37812.mail.mud.yahoo.com> you wrote:
>
> Sorry if this may seem basic to some but is there anything I need to
> know about the format of the u-boot.bin? I want to write a program to
It's a raw binary image. Just data.
> burn the flash on the MPC8349 via the PCI interface. Just not sure
> where to get info on binary file format and if there is anything
> unique about the binary created from u-boot.
Why not using a JTAG debugger?
> ---------------------------------
> New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
> --0-1608916273-1146154075=:24528
> Content-Type: text/html; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
Can you please mind the netiquette? I. e. no HTML postings, trimming
to line length to some 70 characters or so, etc.
Also, you should have posted on the u-boot-users list; your question
is actually off topic here.
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
There is, however, a strange, musty smell in the air that reminds me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit. - Larry Wall in Configure from the perl distribution
^ permalink raw reply
* Re: [QUESTION] MPC834x DMA Support
From: Wolfgang Denk @ 2006-04-27 16:27 UTC (permalink / raw)
To: KRONSTORFER Horst; +Cc: linuxppc-dev
In-Reply-To: <C5BA91F04186584EB68FD42BB4993E6BC1B5C6@FRQWOLEX01.frequentis.frq>
In message <C5BA91F04186584EB68FD42BB4993E6BC1B5C6@FRQWOLEX01.frequentis.frq> you wrote:
>
> does anyone know if the mpc834x's dma unit supports dma operation
> only between pci and csb or also between csb and csb, f.e. devices
> connected via the lbc (f.e. ram and a dsp)?
This should work. We used this to initialize ECC memory. But be
careful about your performance expectations - ask Freescale what you
can get out of memory to memory DMA. [Sorry, I'm still waiting for
replies from FSL myself.]
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
You speak of courage. Obviously you do not know the difference bet-
ween courage and foolhardiness. Always it is the brave ones who die,
the soldiers.
-- Kor, the Klingon Commander, "Errand of Mercy",
stardate 3201.7
^ permalink raw reply
* Re: u-boot.bin
From: Kumar Gala @ 2006-04-27 16:16 UTC (permalink / raw)
To: Eric Heim; +Cc: linuxppc-embedded
In-Reply-To: <20060427160755.24553.qmail@web37812.mail.mud.yahoo.com>
On Apr 27, 2006, at 11:07 AM, Eric Heim wrote:
> Sorry if this may seem basic to some but is there anything I need
> to know about the format of the u-boot.bin? I want to write a
> program to burn the flash on the MPC8349 via the PCI interface.
> Just not sure where to get info on binary file format and if there
> is anything unique about the binary created from u-boot.
This question is best asked on the u-boot lists. But the u-boot.bin
is a straight binary file. The contents should be placed directly
into the location of flash that you desire.
- kumar
^ permalink raw reply
* Re: [Fastboot] Documentation feedback request.
From: Vivek Goyal @ 2006-04-27 14:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev list, fastboot
In-Reply-To: <1146095071.29876.23.camel@localhost.localdomain>
On Thu, Apr 27, 2006 at 09:44:31AM +1000, Michael Ellerman wrote:
> > Load the Dump-capture Kernel
> > ============================
> >
> > After booting to the system kernel, load the dump-capture kernel using
> > the following command:
> >
> > kexec -p <dump-capture-kernel> \
> > --initrd=<initrd-for-dump-capture-kernel> --args-linux \
> > --append="root=<root-dev> init 1 irqpoll"
>
> I've never tested irqpoll on powerpc, I'm not sure we want to recommend
> it, has someone tested it?
>
We have tested it on x86 & x86_64 and it works fine. Not sure about powerpc.
Dave, Mohan and Mike have been doing some testing on powerpc. Guys any
inputs?
-vivek
^ permalink raw reply
* u-boot.bin
From: Eric Heim @ 2006-04-27 16:07 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
Sorry if this may seem basic to some but is there anything I need to know about the format of the u-boot.bin? I want to write a program to burn the flash on the MPC8349 via the PCI interface. Just not sure where to get info on binary file format and if there is anything unique about the binary created from u-boot.
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
[-- Attachment #2: Type: text/html, Size: 552 bytes --]
^ permalink raw reply
* Re: [PATCH 02/16] ehca: module infrastructure
From: Heikki Orsila @ 2006-04-27 15:29 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A165.4000701@de.ibm.com>
On Thu, Apr 27, 2006 at 12:48:05PM +0200, Heiko J Schick wrote:
> + * This source code is distributed under a dual license of GPL v2.0 and
> OpenIB
> + * BSD.
> + *
> + * OpenIB BSD License
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + *
> + * Redistributions of source code must retain the above copyright notice,
> this
> + * list of conditions and the following disclaimer.
> + *
> + * Redistributions in binary form must reproduce the above copyright
> notice,
> + * this list of conditions and the following disclaimer in the
> documentation
> + * and/or other materials
> + * provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER
> + * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
Would you please keep the full license in only one file? It seems to be
duplicated in all source modules. It's wasty.
> + * $Id: ehca_main.c,v 1.35 2006/04/25 08:59:43 schickhj Exp $
This shouldn't be here. The kernel project has its own versioning.
--
Heikki Orsila Barbie's law:
heikki.orsila@iki.fi "Math is hard, let's go shopping!"
http://www.iki.fi/shd
^ permalink raw reply
* Re: [QUESTION] MPC834x DMA Support
From: Kumar Gala @ 2006-04-27 15:25 UTC (permalink / raw)
To: KRONSTORFER Horst; +Cc: linuxppc-dev
In-Reply-To: <C5BA91F04186584EB68FD42BB4993E6BC1B5C6@FRQWOLEX01.frequentis.frq>
On Apr 27, 2006, at 5:37 AM, KRONSTORFER Horst wrote:
> hi!
>
> does anyone know if the mpc834x's dma unit supports dma operation
> only between pci and csb or also between csb and csb, f.e. devices
> connected via the lbc (f.e. ram and a dsp)?
You should be able to do csb to csb devices.
- kumar
^ permalink raw reply
* Re: [PATCH 05/16] ehca: InfiniBand query and multicast functionality
From: Arnd Bergmann @ 2006-04-27 14:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, J?rn Engel
In-Reply-To: <20060427134525.GA20966@infradead.org>
On Thursday 27 April 2006 15:45, Christoph Hellwig wrote:
> It's linewrapped here, too. And the mailer on this box hasn't changed
> for more than three years. OTOH I got strangely looking mails from
> you recently :)
>
>
Hmm. I don't see line wrap problems on
http://patchwork.ozlabs.org/linuxppc/patch?id=5174 . Maybe I'm just
blind.
However, /something/ went wrong with the way the patch
showed up there. Half of it ended up in the comment section
instead of the patch itself.
Arnd <><
^ permalink raw reply
* do_mmap_pgoff issue...
From: Gerhard Jaeger @ 2006-04-27 13:59 UTC (permalink / raw)
To: linuxppc-dev
Hi list,
while trying to mmap some flash area on my mpc8541 CDS board,
I noticed that the overflow case is probably not correctly handled
within function do_mmap_pgoff in linux/mm/mmap.c
The facts:
- mmap the last page @ 0xFFFFF000, len 4K
- result: mmap says EOVERFLOW...
- the function that failed was do_mmap_pgoff()
Here's the pice of code
/* offset overflow? */
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
return -EOVERFLOW;
It's quite clear why it fails in my case:
pgoff + (len >> PAGE_SHIFT) will be 0
I fixed that by inserting the following, to handle that special case:
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) {
if ((pgoff + (len >> PAGE_SHIFT)) != 0 )
return -EOVERFLOW;
}
My question is - is that behaviour a bug or a feature? In fact it's
an off-by-one issue, but I could not believe, that nobody else ever
had problems with that.
TIA for enlighten me
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* QUICC Engine ATM driver
From: Alex Zeffertt @ 2006-04-27 14:11 UTC (permalink / raw)
To: linuxppc-embedded, linux-atm-general@lists.sourceforge.net
Hi all,
Has anybody ported, or started to port, the mpc8260sar ATM driver for
the "PowerQUICC II" to the "PowerQUICC II Pro" (e.g. the MPC8360). If
so I'd love to hear from you :)
Regards,
Alex
PS: For the record:
PowerQUICC I contains a CPM1 which needs the mpc860sar driver
PowerQUICC II & III contain a CPM2 which needs the mpc8260sar driver
PowerQUICC II Pro contains a "QUICC Engine" ....
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Pekka Enberg @ 2006-04-27 13:42 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427123701.GG32127@wohnheim.fh-wedel.de>
On 4/27/06, J=F6rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> The whole patch is full of parameter-happy functions with this one
> being the ugly top of the iceberg. I sincerely hope this is not a
> defined ABI and can still be changed.
It's not in mainline, so it can be changed.
Pekka
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Jörn Engel @ 2006-04-27 13:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <84144f020604270642j788be2ecp82841ac3b3ebcaad@mail.gmail.com>
On Thu, 27 April 2006 16:42:52 +0300, Pekka Enberg wrote:
> On 4/27/06, Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> > The whole patch is full of parameter-happy functions with this one
> > being the ugly top of the iceberg. I sincerely hope this is not a
> > defined ABI and can still be changed.
>
> It's not in mainline, so it can be changed.
I was thinking more about firmware ABI.
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
^ 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