* Re: ARCH=ppc or ARCH=powerpc
From: Josh Boyer @ 2006-08-24 13:07 UTC (permalink / raw)
To: BDE; +Cc: linuxppc-embedded
In-Reply-To: <1156424295.19482.11.camel@localhost>
On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote:
>
> I'm currently working on a PPC 405 based developement card. Does it mean
> I have to work using the arch/ppc tree ?
For now, yes. Set ARCH=ppc when you compile the kernel.
> What about the includes ? Do I have to use only include/asm-ppc or are
> include/asm-powerpc necessary as well ?
I believe there are some hacks in the makefiles to pull common asm files
from include/asm-powerpc when needed. Basically, you should be able to
just do:
#include <asm/foo.h>
and it should work. If you're adding new .h files, I suppose asm-ppc is
the place to add them for now. That's just my opinion though :)
josh
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Matt Porter @ 2006-08-24 13:23 UTC (permalink / raw)
To: Benjamin Delagoutte; +Cc: linuxppc-embedded
In-Reply-To: <1156424295.19482.11.camel@localhost>
On Thu, Aug 24, 2006 at 02:58:15PM +0200, Benjamin Delagoutte wrote:
> Le jeudi 24 août 2006 à 07:49 -0500, Josh Boyer a écrit :
> > On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote:
> > > ppc = 32bit.
> > > powerpc= 64bit.
> > > Correct me if I am wrong.
> >
> > Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now.
> >
> > >
> > > I am not sure why community didn't adopt the name ppc and ppc64 just
> > > like ia-32 and ia64.
> >
> > They did originally.
> >
> > The new direction is to have everything under arch/powerpc, both 32 and
> > 64 bit. The reason arch/ppc still exists is because some 32 bit
> > platforms have not been fully migrated to the requirements to be merged
> > into arch/powerpc. Namely, the code has to boot from an OpenFirmware
> > like flattened device tree. The PPC 4xx family of processors, as an
> > example, does not do this yet though there is work going on to adapt it.
>
> I'm currently working on a PPC 405 based developement card. Does it mean
> I have to work using the arch/ppc tree ?
PPC405 is only supported in the arch/ppc tree currenty. Unless you
want to contribute to the effort to move to arch/powerpc, you'll
have to work with arch/ppc/
> What about the includes ? Do I have to use only include/asm-ppc or are
> include/asm-powerpc necessary as well ?
When you do an arch/ppc build it automagically includes shared
includes from asm-powerpc as necessary. There's nothing to worry
about there.
The goal is to have the new 4xx arch/powerpc support not break 4xx
arch/ppc support. So as boards are merged and verified working,
we'll remove the equivalent support from arch/ppc...
Some boards/chips may just die if no maintainer step up to port
them over...but all the important stuff should get an interested
party once we get the initial 4xx support in arch/powerpc working.
-Matt
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Matt Porter @ 2006-08-24 13:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: BDE, linuxppc-embedded
In-Reply-To: <1156424840.5640.27.camel@zod.rchland.ibm.com>
On Thu, Aug 24, 2006 at 08:07:20AM -0500, Josh Boyer wrote:
> On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote:
> > What about the includes ? Do I have to use only include/asm-ppc or are
> > include/asm-powerpc necessary as well ?
>
> I believe there are some hacks in the makefiles to pull common asm files
> from include/asm-powerpc when needed. Basically, you should be able to
> just do:
>
> #include <asm/foo.h>
>
> and it should work. If you're adding new .h files, I suppose asm-ppc is
> the place to add them for now. That's just my opinion though :)
That's what I would recommend too. If this is for an out-of-tree custom
port then there's no real concern anyway.
-Matt
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Jon Loeliger @ 2006-08-24 13:22 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060824041027.GA19887@suse.de>
So, like, the other day Greg KH mumbled:
> On Thu, Aug 24, 2006 at 02:02:06PM +1000, Paul Mackerras wrote:
> >
> > No, that's the right branch, but the mirroring was very slow. My
> > update of hours ago has only just propagated out. Try again now.
>
> Ok, that worked. I can pull from master@kernel.org too, which would
> have worked here :)
Paul and Greg,
Thanks for picking up those 86xx and 85xx patches!
So, has there been a change in the general flow of things
for PowerPC these days? Will all the PPC patches be going
through Greg K-H from now on? Or is that a temporary flow?
Just curious,
jdl
^ permalink raw reply
* Re: ioremap() fails for >64 MB
From: Matt Porter @ 2006-08-24 12:25 UTC (permalink / raw)
To: alva; +Cc: linuxppc-embedded
In-Reply-To: <000001c6c728$9aeeac30$8500a8c0@dc.roysiu.servebbs.com>
On Thu, Aug 24, 2006 at 10:54:23AM +0800, alva wrote:
> I think 64MB limitation of ioremap() is due to the kernel's page size.
> When compiling kernel, it has an option to choose the memory page size
> which is default 64MB. To use memory greater than 64MB, there is two
> methods. One is to make the kernel's page size larger as Phil Nitschke
> said. Another is to modify ioremap() a little bit --- just make it use
> another file for "mmap" while larger than 64MB. Since the central
> concept of linux is file-based, I think more files are not harmful that
> only waste a little bit inode structure. And it is much more feasible
> that one can choose to use file in memory or harddisk or mounted device
> harddisk/memory ... ...
This is incorrect. There is no "64MB page size". Unless you are ioremapping
a region overed by a BAT/CAM, the mapping is composed of default 4KB PTEs.
The reason it fails is because of what I explained earlier. Just wanted to
clarify so nobody was confused by these statements. We can map arbitrary
sizes to the limit of what the kernel virtual address space settings
allow. This varies from platform to platform.
-Matt
^ permalink raw reply
* Re: ioremap() fails for >64 MB
From: Matt Porter @ 2006-08-24 12:56 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1156327238.6735.9.camel@lamorak.int.avalon.com.au>
On Wed, Aug 23, 2006 at 07:30:37PM +0930, Phil Nitschke wrote:
> On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote:
> > On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote:
> > > Hi all,
> > >
> > > I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk
> > > of it at boot-time, then ioremap() it into the kernel space inside a
> > > device driver. So far I've succeeded with 64 MB, but can't go any
> > > higher, as mm/vmalloc.c tells me: "allocation failed: out of vmalloc
> > > space - use vmalloc=<size> to increase size."
> > >
> > > So I tried adding a vmalloc line to the kernel command line as follows:
> > > Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=...
> >
> > Yeah, that suggestion is bogus. That option can't help with getting
> > more vmalloc space in this case.
> >
> > > So the vmalloc=<size> argument has made no difference. What do I need
> > > to do to make this work?
> >
> > Go to the "Advanced setup" menu. There's a number of options to provide
> > fine-grained control of the PPC kernel virtual address space.
>
> <SNIP>
>
> Thanks Matt (and others) for your suggestions. Matt has given me the
> answers I was looking for.
>
> Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit
> processor, why do I need high memory at all?
Dan answered this one...
> Are there performance implications on this platform from having a non
> optimal low/high ratio?
It "depends". In PPC, we've always has kernelbase at 0xc0000000, however,
the dirty secret is that we still haven't have a 3:1 user:kernel split
like some other arches. We've always had TASK_SIZE at 0x80000000 which
really results in a 1:1 split. So, as long as you don't modify
TASK_SIZE, there's no chance of starving memory hungry user space
applications. There's already this waste space from 0x80000000-0xbfffffff
that was left due to legacy PReP reasons.
Even if you do modify TASK_SIZE down to something like 0x40000000,
for a 1:3 split, many embedded apps are perfectly happy with this
space, YMMV.
It's important that you understand how the userspace works at the
low level, plus VSIDs (on classic PPC), and the general concepts
of the virtual memory organization between kernel and userspace before
you mess with all these advanced options. They are under advanced
options since they can easily make your system inoperable with the
improper settings.
> > That said, why don't you just use alloc_bootmem() to reserve memory
> > for your driver at boot time?
>
> I avoided this simply because I wanted to load/unload my driver (during
> development), and alloc_bootmem() seemed better suited to drivers
> compiled into the kernel. But I'll look again at this idea if further
> problems arise with the approach above.
I see. It doesn't have any bearing on using a loadable module since
alloc_bootmem() is only called by your board port code. Your loadable
module just uses that reserved area and manages it on its own.
In any case, either approach will work.
-Matt
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Kumar Gala @ 2006-08-24 13:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Greg KH, Paul Mackerras
In-Reply-To: <E1GGFAL-0004qP-3D@jdl.com>
On Aug 24, 2006, at 8:22 AM, Jon Loeliger wrote:
> So, like, the other day Greg KH mumbled:
>> On Thu, Aug 24, 2006 at 02:02:06PM +1000, Paul Mackerras wrote:
>>>
>>> No, that's the right branch, but the mirroring was very slow. My
>>> update of hours ago has only just propagated out. Try again now.
>>
>> Ok, that worked. I can pull from master@kernel.org too, which would
>> have worked here :)
>
> Paul and Greg,
>
> Thanks for picking up those 86xx and 85xx patches!
>
> So, has there been a change in the general flow of things
> for PowerPC these days? Will all the PPC patches be going
> through Greg K-H from now on? Or is that a temporary flow?
Greg's acting in Linus's place til he gets back.
- k
^ permalink raw reply
* MontaVista 2.6 Kernel support for Xilinx ML40x
From: Frank D Lombardo @ 2006-08-24 13:59 UTC (permalink / raw)
To: linuxppc-embedded
I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
available for the Xilinx ML40x series of boards. I would assume that
means driver support for at least most of the hardware on the boards.
Is this code that should be freely available? How would one get a copy
of these drivers? I am interested in drivers for the ML403.
Thanks,
Frank
^ permalink raw reply
* Re: atomic operations in user space
From: Brent Cook @ 2006-08-24 14:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Terry Liang
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC380@zch01exm20.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote:
> Why do you need atomic operations in user land? IPC will be sufficient
> to deal with race conditions between processes.
>
> Best Regards,
> Leo
What about multiple threads within a process updating a counter?
Of course, if you look at these functions in the kernel header, they're just 2 or 3 inline assembly calls - you could easily rewrite them. Google for 'PowerPC atomic increment' and grab one of the unencumbered implementations if you need to use it in a non-GPL program.
On the other hand, I see no license at the top of my /usr/include/asm-i386/atomic.h file at all, same for PowerPC - are Linux header files actually GPL or are they more like the glibc headers, with exceptions made for userspace programs?
The atomic operations on x86 were accidentally exported early on, so they have to hang around apparently for compatibility (there are some mailing list threads out there to this effect.) Currently, you just have to assume in Linux that if you include something from /usr/include/linux or asm that it will not necessarily be cross-version or cross-architecture compatible. Not every arch in Linux even has atomic operations of this nature, which I guess is the main reason why they are not exported in general.
- Brent
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On
>
> Behalf Of
>
> > Terry Liang
> > Sent: Thursday, August 24, 2006 3:04 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: atomic operations in user space
> >
> > Thanks. Arnd. My main concern is whether the operations are really
>
> atomic as they
>
> > are in the kernel space. I have read some discussion in another forum
>
> that on other
>
> > platforms, even if you are able to compile the atomic_add(),
>
> atomic_set(), etc.
>
> > from an user space application, they don't guarantee to be atomic.
>
> Thanks.
>
> > Regards,
> >
> > Terry Liang
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2875 bytes --]
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-24 14:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <AB150E9C-6BB3-46C1-980D-311D3277BFC1@kernel.crashing.org>
Thanks Kumar,
As always, you're several steps ahead of me.
On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote:
> I know I posted a patch for cf-ide.c to lkml some time ago, this was
> to do a CF in true ide mode using the 83xx localbus.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113877891224982&w=2
>
> We did some UPM setup in u-boot to use two CS on Localbus for this.
In our case, we only have one CS available but it's going to a CPLD that
will decode and provide two CSs to the CF. This will work as long as
the UPM setup is identical for the two chip selects. Should be...
Off-topic to this list, but do you have the U-boot code that you can
share? If not, no worries.
thanks,
Ben
^ permalink raw reply
* RE: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Claus Gindhart @ 2006-08-24 15:02 UTC (permalink / raw)
To: Frank D Lombardo, linuxppc-embedded
Frank,
due to my understanding of the GPL (and i have already invested some =
time
in understanding the various flavours of open source licences), you =
should
contact Montavista, and ask them for the sources.
This board adaption is derivative work of the GPL Kernel, so the result =
of
this work also falls under the GPL, and has to be made freely available=20
under the terms of the GPL.
--=20
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
=20
-----Original Message-----
From: linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org=
]
On Behalf Of Frank D Lombardo
Sent: Donnerstag, 24. August 2006 15:59
To: linuxppc-embedded@ozlabs.org
Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)=20
available for the Xilinx ML40x series of boards. I would assume that=20
means driver support for at least most of the hardware on the boards. =20
Is this code that should be freely available? How would one get a copy=20
of these drivers? I am interested in drivers for the ML403.
Thanks,
Frank
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Michael Galassi @ 2006-08-24 15:17 UTC (permalink / raw)
To: Frank D Lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44EDB0A8.4040200@mdivac.com>
I too had high hopes when I heard an LSP for the ML40x was imminent, I
nabbed it and was disappointed to find that their drivers still only
support relatively old versions of the Xilinx IP. It would seem that
they are still creating the design they ported to with EDK/ISE v7.2
rather than the newer 8.1 or 8.2 with updated IP libraries. This is
from the xparameters_ml40x.h file they distribute.
/*******************************************************************
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 7.1.2 EDK_H.12.5.1
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc. All rights reserved.
*
* Description: Driver parameters
*
*******************************************************************/
Sigh.
-michael
>I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
>available for the Xilinx ML40x series of boards. I would assume that
>means driver support for at least most of the hardware on the boards.
>Is this code that should be freely available? How would one get a copy
>of these drivers? I am interested in drivers for the ML403.
>
>Thanks,
>Frank
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 15:36 UTC (permalink / raw)
To: Claus Gindhart; +Cc: linuxppc-embedded
In-Reply-To: <DADA32856852FC458E0F96B664A6F55E011E2423@kom-mailsrv1.kontron-modular.com>
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
I've got the LSP, and have booted it on the ML40X.
In my opinion it is currently unstable, but that is my opinion. I've not
been able to keep it powered up for 24 hours without it locking up on the
RS232 serial terminal. Also, running updatedb over nfs causes it to abort
with a kernel panic, although that might be an interraction with the nfs
server. (Although even if the nfs server dies (which it did not), I don't
expect a kernel panic).
I have had it run over 6 hours without issue, so I expect subtle memory
leaks, not serious problems.
On 8/24/06, Claus Gindhart <claus.gindhart@kontron.com> wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already invested some time
> in understanding the various flavours of open source licences), you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so the result of
> this work also falls under the GPL, and has to be made freely available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> available for the Xilinx ML40x series of boards. I would assume that
> means driver support for at least most of the hardware on the boards.
> Is this code that should be freely available? How would one get a copy
> of these drivers? I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3528 bytes --]
^ permalink raw reply
* RE: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Rick Moleres @ 2006-08-24 15:40 UTC (permalink / raw)
To: Michael Galassi, Frank D Lombardo; +Cc: linuxppc-embedded
Note that Xilinx plans to update the MV drivers to support the latest IP
in EDK 8.2.2 (due out around October), and these drivers would be part
of the BSP generation process of Platform Studio. Sorry, the timing of
the MV ML40x work and our EDK 8.1.x release was such that MV had no
choice but to use older IP and drivers.
-Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of Michael Galassi
Sent: Thursday, August 24, 2006 9:18 AM
To: Frank D Lombardo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MontaVista 2.6 Kernel support for Xilinx ML40x=20
I too had high hopes when I heard an LSP for the ML40x was imminent, I
nabbed it and was disappointed to find that their drivers still only
support relatively old versions of the Xilinx IP. It would seem that
they are still creating the design they ported to with EDK/ISE v7.2
rather than the newer 8.1 or 8.2 with updated IP libraries. This is
from the xparameters_ml40x.h file they distribute.
=20
/*******************************************************************
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 7.1.2 EDK_H.12.5.1
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc. All rights reserved.
*
* Description: Driver parameters
*
*******************************************************************/
Sigh.
-michael
>I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)=20
>available for the Xilinx ML40x series of boards. I would assume that=20
>means driver support for at least most of the hardware on the boards. =20
>Is this code that should be freely available? How would one get a copy
>of these drivers? I am interested in drivers for the ML403.
>
>Thanks,
>Frank
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Segher Boessenkool @ 2006-08-24 15:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, arnd, segher
In-Reply-To: <17645.18647.720814.903612@cargo.ozlabs.ibm.com>
> Also it would be really nice if you could figure out a way to
> avoid doing the unnecessary 64-bit logical operations on 32-bit
> machines
Like I asked before -- should we run this emulation on 32-bit
machines at all? The instruction only exists in the 64-bit
architecture after all.
Segher
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Peter Ryser @ 2006-08-24 16:52 UTC (permalink / raw)
To: Wade Maxfield; +Cc: linuxppc-embedded
In-Reply-To: <45a1b53e0608240836l52ed51b5u309e31dd8486cc5b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
Wade,
are you sure that you did not build your hardware with evaluation cores
of the licenses? If you are using the evaluation licenses the hardware
(FPGA design) will stop working after a certain amount of time and you
will see a lock-up.
- Peter
Wade Maxfield wrote:
>
> I've got the LSP, and have booted it on the ML40X.
>
> In my opinion it is currently unstable, but that is my opinion.
> I've not been able to keep it powered up for 24 hours without it
> locking up on the RS232 serial terminal. Also, running updatedb over
> nfs causes it to abort with a kernel panic, although that might be an
> interraction with the nfs server. (Although even if the nfs server
> dies (which it did not), I don't expect a kernel panic).
>
> I have had it run over 6 hours without issue, so I expect subtle
> memory leaks, not serious problems.
>
>
>
> On 8/24/06, Claus Gindhart < claus.gindhart@kontron.com
> <mailto:claus.gindhart@kontron.com>> wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already invested
> some time
> in understanding the various flavours of open source licences),
> you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so the
> result of
> this work also falls under the GPL, and has to be made freely
> available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> <mailto:claus.gindhart@kontron-modular.com>
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:kontron.com@ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org <mailto:linuxppc-embedded@ozlabs.org>
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> available for the Xilinx ML40x series of boards. I would assume that
> means driver support for at least most of the hardware on the boards.
> Is this code that should be freely available? How would one get a
> copy
> of these drivers? I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 4744 bytes --]
^ permalink raw reply
* Platform device style question
From: Ben Warren @ 2006-08-24 17:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
A 'newbie-to-platform-devices' question:
In a patch that Kumar just sent for a compact flash device, the resource
data (I/O addresses, IRQ # etc.) are retrieved from the platform system.
I guess I can either modify the device tree in U-boot by adding
additional nodes, or instantiate a platform device in Linux __init code
based on static information. The former gives the advantage of having
the bootloader pass the info to the OS. (Somebody please correct me if
I'm off-base here!)
Are device trees meant to only contain information about the CPU and
tightly-coupled peripherals, or is it considered OK-form to also include
board-level hardware info? I guess they can really hold anything, but
I'm trying to figure out the original intent.
regards,
Ben
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 17:57 UTC (permalink / raw)
To: Peter Ryser, ppc
In-Reply-To: <44EDD947.3000105@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
Good question. How long before lockup? The only core that should be
licensed is the ethernet, and I know it was sysgened on a system with a
license. This is the Xilinx reference design for the ml403 board.
On 8/24/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
>
> Wade,
>
> are you sure that you did not build your hardware with evaluation cores of
> the licenses? If you are using the evaluation licenses the hardware (FPGA
> design) will stop working after a certain amount of time and you will see a
> lock-up.
>
> - Peter
>
>
> Wade Maxfield wrote:
>
>
> I've got the LSP, and have booted it on the ML40X.
>
> In my opinion it is currently unstable, but that is my opinion. I've
> not been able to keep it powered up for 24 hours without it locking up on
> the RS232 serial terminal. Also, running updatedb over nfs causes it to
> abort with a kernel panic, although that might be an interraction with the
> nfs server. (Although even if the nfs server dies (which it did not), I
> don't expect a kernel panic).
>
> I have had it run over 6 hours without issue, so I expect subtle memory
> leaks, not serious problems.
>
>
>
> On 8/24/06, Claus Gindhart < claus.gindhart@kontron.com> wrote:
> >
> > Frank,
> >
> > due to my understanding of the GPL (and i have already invested some
> > time
> > in understanding the various flavours of open source licences), you
> > should
> > contact Montavista, and ask them for the sources.
> >
> > This board adaption is derivative work of the GPL Kernel, so the result
> > of
> > this work also falls under the GPL, and has to be made freely available
> > under the terms of the GPL.
> >
> > --
> > Mit freundlichen Gruessen / Best regards
> >
> > Claus Gindhart
> > SW R&D
> > Kontron Modular Computers
> > phone :++49 (0)8341-803-374
> > mailto:claus.gindhart@kontron-modular.com
> > http://www.kontron.com
> >
> > -----BEGIN GEEK CODE BLOCK-----
> > Version: 3.1
> > GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> > K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> > D-- G e++> h--- !r x+++
> > ------END GEEK CODE BLOCK------
> >
> >
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> > [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> > ]
> > On Behalf Of Frank D Lombardo
> > Sent: Donnerstag, 24. August 2006 15:59
> > To: linuxppc-embedded@ozlabs.org
> > Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
> >
> >
> > I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> > available for the Xilinx ML40x series of boards. I would assume that
> > means driver support for at least most of the hardware on the boards.
> > Is this code that should be freely available? How would one get a copy
> > of these drivers? I am interested in drivers for the ML403.
> >
> > Thanks,
> > Frank
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> ------------------------------
>
> _______________________________________________ Linuxppc-embedded mailing
> list Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 6041 bytes --]
^ permalink raw reply
* Re: Platform device style question
From: Vitaly Bordug @ 2006-08-24 18:06 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1156441997.17977.44.camel@saruman.qstreams.net>
On Thu, 24 Aug 2006 13:53:17 -0400
Ben Warren <bwarren@qstreams.com> wrote:
> Hello,
>
> A 'newbie-to-platform-devices' question:
>
> In a patch that Kumar just sent for a compact flash device, the resource
> data (I/O addresses, IRQ # etc.) are retrieved from the platform system.
> I guess I can either modify the device tree in U-boot by adding
> additional nodes, or instantiate a platform device in Linux __init code
> based on static information. The former gives the advantage of having
> the bootloader pass the info to the OS. (Somebody please correct me if
> I'm off-base here!)
>
I'd suggest to make a look at LDD concerning linux device model...
For platform device, there's no need to cope with u-boot at all. You'll prolly need to
register the respective platform device from the board-specific code, with proper name
and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static
PD definitions usage.
> Are device trees meant to only contain information about the CPU and
> tightly-coupled peripherals, or is it considered OK-form to also include
> board-level hardware info? I guess they can really hold anything, but
> I'm trying to figure out the original intent.
>
I'd make sense to figure out the platform device bus before digging into device trees. It's slightly
different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with
your case afaiu.
> regards,
> Ben
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Kumar Gala @ 2006-08-24 18:25 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1156430695.17977.28.camel@saruman.qstreams.net>
On Aug 24, 2006, at 9:44 AM, Ben Warren wrote:
> Thanks Kumar,
>
> As always, you're several steps ahead of me.
>
> On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote:
>
>> I know I posted a patch for cf-ide.c to lkml some time ago, this was
>> to do a CF in true ide mode using the 83xx localbus.
>>
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=113877891224982&w=2
>>
>> We did some UPM setup in u-boot to use two CS on Localbus for this.
> In our case, we only have one CS available but it's going to a CPLD
> that
> will decode and provide two CSs to the CF. This will work as long as
> the UPM setup is identical for the two chip selects. Should be...
> Off-topic to this list, but do you have the U-boot code that you can
> share? If not, no worries.
The only code in u-boot was the UPM setup code, I'm happy to send
that to you.
- kumar
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-24 18:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <9861097B-ACAD-45E6-9FA7-B86F0C1E8FA1@kernel.crashing.org>
Kumar,
On Thu, 2006-08-24 at 13:25 -0500, Kumar Gala wrote:
> The only code in u-boot was the UPM setup code, I'm happy to send
> that to you.
>
If it's no trouble, that would be great. My HW guy is calculating the
settings, but this stuff can be frustrating to debug. BTW - was the
system bus speed for your CPU 33 or 66 MHz? We're targeting for a
400MHz 8349 which has a 33MHz system bus.
^ permalink raw reply
* [2.6.18-rc2] Oops in load_elf_binary...
From: Guennadi Liakhovetski @ 2006-08-24 18:39 UTC (permalink / raw)
To: linuxppc-dev
Hi,
my Kurobox crashes randomly at startup with
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 128k init
Oops: Exception in kernel mode, sig: 4 [#1]
NIP: 00000388 LR: C008D464 CTR: C003D5A0
REGS: c044fc30 TRAP: 0700 Not tainted (2.6.18-rc2-kuroboxHG)
MSR: 00081002 <ME> CR: 24048448 XER: 20000000
TASK = c0449b40[1] 'init' THREAD: c044e000
GPR00: 0000092F C044FCE0 C0449B40 00000000 00000930 00000000 100196CC 10000000
GPR08: 00000930 00009032 00001002 0044FCE0 C000FD9C 1003B600 10019E6C 100196D0
GPR16: C05B38E0 C044FEC0 10000000 00000001 00000007 C05A77C0 00000001 00000000
GPR24: C06A8D00 C0250000 00000000 100193A0 C059C200 00000000 C05B39C0 C06AA980
NIP [00000388] 0x388
LR [C008D464] padzero+0x50/0x9c
Call Trace:
[C044FCE0] [00101877] 0x101877 (unreliable)
[C044FDA0] [00000000] 0x0
[C044FDB0] [C008DD2C] load_elf_binary+0x7c0/0x12d8
[C044FE50] [C0069AC8] search_binary_handler+0x84/0x260
[C044FE70] [C0069DE0] do_execve+0x13c/0x1ec
[C044FE90] [C000BEBC] sys_execve+0x58/0x94
[C044FEB0] [C0004220] ret_from_syscall+0x0/0x38
[C044FF70] [C0070974] sys_dup+0x24/0x3c
[C044FF80] [C00038EC] init+0x1bc/0x2e4
[C044FFF0] [C0006554] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
What can it be? IDE?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Platform device style question
From: Ben Warren @ 2006-08-24 18:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060824220625.515d9b3c@vitb.ru.mvista.com>
Thanks Vitaly,
On Thu, 2006-08-24 at 22:06 +0400, Vitaly Bordug wrote:
> I'd suggest to make a look at LDD concerning linux device model...
Thanks. I'll read it again. My little brain absorbs this stuff very
slowly.
> For platform device, there's no need to cope with u-boot at all. You'll prolly need to
> register the respective platform device from the board-specific code, with proper name
> and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static
> PD definitions usage.
My particular platform (MPC8349) gets its hardware info (CPU, IMMBAR,
PCI, I2C, SPI resources etc.) from an OF device tree that is generated
alongside U-boot and I guess embedded in the uImage file. (I apologize
if I'm getting my jargon mixed up here) The OF device tree idea seemed
like a slick way to abstract away some HW settings from Linux. I was
imagining writing board-side platform device registration that gets its
settings from the device tree, allowing a bit of re-use between similar
but not identical boards.
>
> I'd make sense to figure out the platform device bus before digging into device trees. It's slightly
> different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with
> your case afaiu.
I definitely have much learning to do. Thanks very much for the
pointers!
regards,
Ben
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-24 19:22 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060823002801.GA2709@localhost>
On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
>
> Hi Stefan,
> Hi All
>
> On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:
>
> [ ... ]
>
> > The fact that Linux on the AlBook gets at least as far as "ieee1394:
> > Error parsing configrom for node 0-00:1023" indicates that not all hope
> > is lost. If you have got the time, compile the 1394 drivers for verbose
> > logging and send the log. Don't crosspost the log if it gets too big.
>
> Some tests on the Alubook:
.. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
created:
www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
Because i hate to burden my lousy memory with what I did to produce
the logs above, I scrambled together my admittedly marginal bash
knowledge and ran the tests with 4 scripts to produce the logs.
All the following below is to give you control on how these logs were
created. I'll try to be as verbose as possible. This because, as I
already made clear, I'm anything else but a bash expert. And because I
want to make sure the logs are not spoiled.
And please:
If you think the following is not necessary and instead only burdens
everyone else's mail box with KB that are not needed please let me
know ... :)
###########################################################
*** How
disable-irm.kern.log.when.fw.disk.is.switched.on.txt
was made
###########################################################
First the main script I run to get
disable-irm.kern.log.when.fw.disk.is.switched.on.txt
/home/shorty/scripts/ieee.test.sh:
------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \
sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \
cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
fi
-------------------------------------------------
As you can see above 2 more scripts are (hopefully :) executed inside
the latter script:
#1: /home/shorty/scripts/scsi.stop.sh:
-----------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.stop.sh; \
rmmod raw1394; \
rmmod eth1394;
rmmod ohci1394; \
rmmod sbp2; \
rmmod ieee1394
---------------------------------------
and #2: /home/shorty/scripts/scsi.start.sh:
------------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh; \
modprobe ieee1394 disable_irm=1; \
sleep 2; \
modprobe ohci1394; \
sleep 2; \
modprobe sbp2; \
sleep 2; \
modprobe raw1394; \
sleep 2
chown root.shorty /dev/raw1394
--------------------------------------------
This is what the shell was saying when running ieee.test.sh:
-----------------------------------------------------------
[root@ 20:39:50]# /home/shorty/scripts/ieee.test.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.sh
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \
sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \
cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; t
hen
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switch
ed.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
fi
+ /home/shorty/scripts/scsi.stop.sh
+ /bin/sh -n /home/shorty/scripts/scsi.stop.sh
+ rmmod raw1394
ERROR: Module raw1394 does not exist in /proc/modules
+ rmmod eth1394
+ rmmod ohci1394
+ rmmod sbp2
+ rmmod ieee1394
+ /home/shorty/scripts/scsi.start.sh
+ /bin/sh -n /home/shorty/scripts/scsi.start.sh
+ modprobe ieee1394 disable_irm=1
+ sleep 2
+ modprobe ohci1394
+ sleep 2
+ modprobe sbp2
+ sleep 2
+ modprobe raw1394
+ sleep 2
+ chown root.shorty /dev/raw1394
+ sleep 2
+ /home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux debby1-6 2.6.18-rc4-ieeeverbose-gef7d1b24-dirty #1 Tue Aug 22 22:18:50 CES
T 2006 ppc GNU/Linux
Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
udev 097
Modules Loaded raw1394 sbp2 eth1394 ohci1394 ieee1394 bluetooth radeon d
rm nfs nfsd exportfs lockd nfs_acl sunrpc ipv6 therm_adt746x sr_mod cpufreq_powe
rsave cpufreq_performance scsi_mod apm_emu joydev appletouch snd_aoa_codec_onyx
usbhid snd_aoa_fabric_layout snd_aoa pcmcia firmware_class snd_aoa_i2sbus snd_pc
m_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc sungem sungem_phy pmac_zilo
g serial_core snd ehci_hcd ide_cd evdev uninorth_agp agpgart i2c_powermac ohci_h
cd yenta_socket rsrc_nonstatic pcmcia_core cdrom soundcore snd_aoa_soundbus usbc
ore
+ cat /dev/null
+ echo '===> NOW SWITCH ON THE FW DISK <===='
===> NOW SWITCH ON THE FW DISK <====
+ sleep 70
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switche
d.on.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched
.on.txt
[root@ 20:42:36]#
------------------------------------------------------------
########################################################################
*** How
disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
was made
########################################################################
disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
covers one of at least 2 instances when I started gscanbus a few
minutes after failing to connect the firewire disk to the alubook with
the very first script, i.e. ieee.test.sh.
I turned on a bus reset from within gscanbus.
/home/shorty/scripts/ieee.test.with.gscanbus.sh:
-----------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \
echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
fi
---------------------------
Shell output when running ieee.test.with.gscanbus.sh:
-----------------------------------------
# /home/shorty/scripts/ieee.test.with.gscanbus.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \
echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti
on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connec
tion.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
fi
+ echo '====> NOW RUN gscanbus ... <====='
====> NOW RUN gscanbus ... <=====
+ cat /dev/null
+ sleep 120
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connect
ion.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti
on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.fai
led.fw.connection.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.fail
ed.fw.connection.txt
[root@ 20:52:04]#
------------------------------------------
3 nodes inside the gscanbus window:
#1:
--------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: Yes
CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1
Vendor: Unknown
Textual Leafes:
Linux - ohci1394
AV/C Subunits
-------------
N/A
-------------------------
#2:
---------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: None
Port 0: Connected to parent node
Port 1: Not connected
Port 2: Not connected
Init. reset: No
CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0
Vendor: (null)
Textual Leafes:
AV/C Subunits
-------------
N/A
-------------------------
#3
-----------------------------
SelfID Info
-----------
Physical ID: 2
Link active: No
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to child node
Port 2: Connected to child node
Init. reset: No
CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0
Vendor: (null)
Textual Leafes:
AV/C Subunits
-------------
N/A
--------------------------------
And this was what the xterm was telling from where I ran gscanbus:
------------------------------------------
$ gscanbus
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000494: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000428: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff000042c: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000464: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
--------------------------------------------
HTH
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Frank D Lombardo @ 2006-08-24 19:27 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608241057j4ebe519drd1e431a2275ccdde@mail.gmail.com>
The ml403 reference design has several evaluation cores: opb_uart16550,
opb_iic and opb_ethernet. They seem to time-out after about eight hours.
Frank
Wade Maxfield wrote:
> Good question. How long before lockup? The only core that should be
> licensed is the ethernet, and I know it was sysgened on a system with
> a license. This is the Xilinx reference design for the ml403 board.
>
>
> On 8/24/06, *Peter Ryser* <peter.ryser@xilinx.com
> <mailto:peter.ryser@xilinx.com>> wrote:
>
> Wade,
>
> are you sure that you did not build your hardware with evaluation
> cores of the licenses? If you are using the evaluation licenses
> the hardware (FPGA design) will stop working after a certain
> amount of time and you will see a lock-up.
>
> - Peter
>
>
> Wade Maxfield wrote:
>
> I've got the LSP, and have booted it on the ML40X.
>
> In my opinion it is currently unstable, but that is my opinion.
> I've not been able to keep it powered up for 24 hours without it
> locking up on the RS232 serial terminal. Also, running updatedb
> over nfs causes it to abort with a kernel panic, although that
> might be an interraction with the nfs server. (Although even if
> the nfs server dies (which it did not), I don't expect a kernel
> panic).
>
> I have had it run over 6 hours without issue, so I expect
> subtle memory leaks, not serious problems.
>
>
>
> On 8/24/06, *Claus Gindhart* < claus.gindhart@kontron.com
> <mailto:claus.gindhart@kontron.com>> wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already
> invested some time
> in understanding the various flavours of open source
> licences), you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so
> the result of
> this work also falls under the GPL, and has to be made freely
> available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> <mailto:claus.gindhart@kontron-modular.com>
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:kontron.com@ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org
> <mailto:linuxppc-embedded@ozlabs.org>
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6
> Kernel)
> available for the Xilinx ML40x series of boards. I would
> assume that
> means driver support for at least most of the hardware on the
> boards.
> Is this code that should be freely available? How would one
> get a copy
> of these drivers? I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________ Linuxppc-embedded
> mailing list Linuxppc-embedded@ozlabs.org
> <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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