* Re: Getting Perl on Embedded Linux PowerPC
From: Wolfgang Denk @ 2005-09-15 23:42 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050915191243.GA52539@mail19d.g19.rapidsite.net>
In message <20050915191243.GA52539@mail19d.g19.rapidsite.net> you wrote:
>
> I was attempting to get some ATM Tools compiled into the embedded PowerPC,
> and found I needed Perl installed on the target before I continue.
You probably want to avoid his in an embedded system...
> Has anyone had any luck getting any version of Perl 5 or higher installed
> onto the file system. I am still running this over the NFS dev environment,
> and plan to remove it before final production, so space is of no concern at
> the moment.
Sure. This is trivial. Perl configures and builds just fine, assuming
you have enough time, memory and swap space.
> Or perhaps a pre-compiled RPM that installs, that is built for PowerPC.
No RPM, sorry.
> I am using DENX Linux 2.4.25 at the moment, with pretty much the default
> root file system that is provided.
Just follow the standard instructions for configuring and building
Perl (in native mode, of course). I did this several times before,
without any problems. You have to be patient, though, It's a huge
amount of code, and definitely takes a lot of time to compile.
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
Never underestimate the bandwidth of a station wagon full of tapes.
-- Dr. Warren Jackson, Director, UTCS
^ permalink raw reply
* Getting Perl on Embedded Linux PowerPC
From: Russell McGuire @ 2005-09-15 23:12 UTC (permalink / raw)
To: linuxppc-embedded
Anyone,
I was attempting to get some ATM Tools compiled into the embedded PowerPC,
and found I needed Perl installed on the target before I continue.
So my question...
Has anyone had any luck getting any version of Perl 5 or higher installed
onto the file system. I am still running this over the NFS dev environment,
and plan to remove it before final production, so space is of no concern at
the moment.
Or perhaps a pre-compiled RPM that installs, that is built for PowerPC.
I am using DENX Linux 2.4.25 at the moment, with pretty much the default
root file system that is provided.
-Russ
^ permalink raw reply
* Re: [PATCH] powerpc: merge include/asm/cputable.h
From: Arnd Bergmann @ 2005-09-15 22:56 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, pantelis.antoniou, linuxppc64-dev,
linuxppc-embedded
In-Reply-To: <CEA72228-613A-4106-8ACB-97B81D018B03@freescale.com>
On Dunnersdag 15 September 2005 19:44, Kumar Gala wrote:
> I get the idea now, how about we make CPU_FTR_ALWAYS &
> CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to
> define CPU_FTR_POSSIBLE if they want to.
>
So you mean like:
#ifdef CONFIG_PPC_PSERIES
#define CPU_FTR_PSERIES_POSSIBLE (CPU_FTR_FOO | CPU_FTR_BAR)
#define CPU_FTR_PSERIES_ALWAYS (CPU_FTR_FOO)
#else
#define CPU_FTR_PSERIES_POSSIBLE (0)
#define CPU_FTR_PSERIES_ALWAYS (-1)
#endif
#ifdef CONFIG_PPC_PMAC
#define CPU_FTR_PMAC_POSSIBLE (CPU_FTR_BAR | CPU_FTR_BAZ)
#define CPU_FTR_PMAL_ALWAYS (CPU_FTR_BAZ)
#else
#define CPU_FTR_PMAC_POSSIBLE (0)
#define CPU_FTR_PMAC_ALWAYS (-1)
#endif
...
#define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE | CPU_FTR_PMAC_POSSIBLE \
| CPU_FTR_...
#define CPU_FTR_ALWAYS CPU_FTR_POSSIBLE & CPU_FTR_PSERIES_ALWAYS \
& CPU_FTR_PMAC_ALWAYS & CPU_FTR_ ...
That would of course avoid having to define the features per CPU type,
but at the same time make the system more error prone, because every
time you add a feature to some of the CPUs, you'd have to know exactly
which platform defines to change as well, and they might get out of sync.
I also don't think that using the #defines here makes it any more
readable than the enums, because you cannot have compile-time conditionals
inside of #define.
> I see the classes of for FTR_POSSIBLE: CLASSIC_PPC, 8xx, 4xx, FSL-
> BOOKE, PPC64 (maybe more subclasses here).
>
> The hugh enum while useful, is just really ugly and I can't believe
> it's worth it for the ~60 cases we are using cpu_has_feature() in.
One point to consider is that we traditionally use #ifdef in the
source for many places that could simply use cpu_has_feature(). E.g.
most instances of #ifdef CONFIG_ALTIVEC could be replaced by
cpu_has_feature(CPU_FTR_ALTIVEC) without additional run-time overhead.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: don't execute a temporary comment
From: Paul Mackerras @ 2005-09-15 22:55 UTC (permalink / raw)
To: John W. Linville; +Cc: ppc64-dev, Stephen Rothwell, ppc-dev
In-Reply-To: <20050915140659.GA17670@tuxdriver.com>
John W. Linville writes:
> Why is this helpful? Better in general to keep the commment near the code, no?
Where it was, it was a command, not a comment, so it got printed out
on the screen when you did a make clean, which seemed a bit silly.
Paul.
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Gabriel Paubert @ 2005-09-15 22:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev@ozlabs.org
In-Reply-To: <17193.61187.613745.15444@cargo.ozlabs.ibm.com>
On Fri, Sep 16, 2005 at 08:00:35AM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > So yes, I object strongly object if I don't have a way
> > of removing useless PMAC code. The kernel is already very
> > bloated compared with the 2.2 we started with, which was
> > well below 1MB with the minimal setup: serial console, root
> > on NFS, no swap, some locally modules to control the PCI<->VME
> > bridge and what is behind on the VME bus.
>
> I assume you compile custom kernels for these machines, so you're
> happy with using config options to remove the code you don't want?
Yes, and I have no problems with it.
Actually I even wrote my own bootloader, which reorganizes the
host bridge memory map to make the MVME 2400/2600 have a more
CHRP-like map, like the MVME5100. The reason is that people
with VME systems like sparsely populated huge memory space
and the 1GB IO space of Prep came in the way.
Actually I announced this bootloader on these lists a long
time ago; Cort Dougan (the maintainer at the time) liked it
very much but I failed at pushing it. It had a few interesting
features: among them it could initialize a video board by
executing the BIOS since it included an x86 emulator (24kB
code + data). It had a relatively clean memory management,
etc...
But I have no time to work on it in the next few months.
> Having the .pmac.text, .prep.text etc. sections lets us remove
> unneeded code at runtime, but it sounds like that isn't actually the
> issue for you (i.e. you don't have a need to run the same kernel on
> both a pmac and a prep).
Not at all. For example my pmac kernels need usb to boot
(literally), the MVME machines have CONFIG_USB off (this
saves a lot).
Now there are other architectures that could be merged,
an example is PreP/PowerPlus/MVME5100.
Gabriel
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Paul Mackerras @ 2005-09-15 22:00 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev@ozlabs.org
In-Reply-To: <20050915205709.GA31156@iram.es>
Gabriel Paubert writes:
> So yes, I object strongly object if I don't have a way
> of removing useless PMAC code. The kernel is already very
> bloated compared with the 2.2 we started with, which was
> well below 1MB with the minimal setup: serial console, root
> on NFS, no swap, some locally modules to control the PCI<->VME
> bridge and what is behind on the VME bus.
I assume you compile custom kernels for these machines, so you're
happy with using config options to remove the code you don't want?
Having the .pmac.text, .prep.text etc. sections lets us remove
unneeded code at runtime, but it sounds like that isn't actually the
issue for you (i.e. you don't have a need to run the same kernel on
both a pmac and a prep).
Paul.
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Dan Malek @ 2005-09-15 21:21 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev@ozlabs.org
In-Reply-To: <20050915205709.GA31156@iram.es>
On Sep 15, 2005, at 4:57 PM, Gabriel Paubert wrote:
> So yes, I object strongly object if I don't have a way
> of removing useless PMAC code.
Or, any other code that isn't appropriate. People have
always laughed at me for trying to save bytes here and
there, but I have to say there are many, many more PowerPCs
running Linux in 32M of memory than 2G of memory.
Using the smallest amount of memory to solve the
problem is still the norm, and when you are competing
against other architectures that can run in less memory,
you can't win. Of course, as Gabriel said, I also see
legacy systems that want to change from another OS
to Linux, but they have 16M soldered on the board (which
was _way_ more than necessary to run that other OS),
and that isn't going to change.
Please, we have to be sensitive to configuring systems
to minimize the resource requirements for Linux.
Thanks.
-- Dan
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Gabriel Paubert @ 2005-09-15 20:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev@ozlabs.org
In-Reply-To: <17193.22140.962651.122114@cargo.ozlabs.ibm.com>
On Thu, Sep 15, 2005 at 09:09:48PM +1000, Paul Mackerras wrote:
> Jon Loeliger writes:
>
> > In the Grand Scheme of Things, removing things and making them
> > simpler seems a lofty goal. :-) Anyone know of any pitfalls that
> > await me if I try to remove these sections, a la pmac and friends?
>
> You'll probably get most objection from the PReP users, for whom
> getting back a few hundred kB is a big deal. (Maybe we should just
> buy both of them a G5 or something. 8-)
Well, we have something like 20 or 25 VME machines controlling
experiments here, some with only 16Mb of RAM. The lifetime
of these systems is often of the order of 20 years (we shall
finally get rid of our TMS9900 processors with 32kB in November,
they were bought in 1982 I believe).
So yes, I object strongly object if I don't have a way
of removing useless PMAC code. The kernel is already very
bloated compared with the 2.2 we started with, which was
well below 1MB with the minimal setup: serial console, root
on NFS, no swap, some locally modules to control the PCI<->VME
bridge and what is behind on the VME bus.
Gabriel
^ permalink raw reply
* Re: PPC4xx cleanup
From: Dan Malek @ 2005-09-15 19:03 UTC (permalink / raw)
To: Matt Porter; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <20050915092555.A27452@cox.net>
On Sep 15, 2005, at 12:25 PM, Matt Porter wrote:
> Sounds great to me. This will have to wait to go in mainline until
> after 2.6.14 is out though.
If you are considering this, I think you should be looking at the
recent U-Boot discussion and patches for the "flat OF tree" and
follow that path.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: merge include/asm/cputable.h
From: Kumar Gala @ 2005-09-15 17:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, pantelis.antoniou, linuxppc64-dev,
linuxppc-embedded
In-Reply-To: <200509150158.10511.arnd@arndb.de>
I get the idea now, how about we make CPU_FTR_ALWAYS &
CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to
define CPU_FTR_POSSIBLE if they want to.
I see the classes of for FTR_POSSIBLE: CLASSIC_PPC, 8xx, 4xx, FSL-
BOOKE, PPC64 (maybe more subclasses here).
The hugh enum while useful, is just really ugly and I can't believe
it's worth it for the ~60 cases we are using cpu_has_feature() in.
- kumar
On Sep 14, 2005, at 6:58 PM, Arnd Bergmann wrote:
> On Middeweken 14 September 2005 21:11, Kumar Gala wrote:
>
>> I not sure I understand what the introduction of the enum's gets us.
>>
>>
> It doesn't have to be an enum, it could just as well be a #define,
> if we find that to be better in some way (maybe compile-time).
>
> The general idea is to convert run-time checks into compile-time
> checks in order to improve the running kernel. If you have
>
> // start code
> enum {
> FEATURE_1 = 1,
> FEATURE_2 = 2,
> PLATFORM_1 = FEATURE_1,
> PLATFORM_2 = FEATURE_2,
> PLATFORM_3 = FEATURE_1 | FEATURE_2,
> FEATURE_POSSIBLE =
> #ifdef CONFIG_PLATFORM_1
> PLATFORM_1 |
> #endif
> #ifdef CONFIG_FEATURE_2
> PLATFORM_2 |
> #endif
> #ifdef CONFIG_FEATURE_3
> PLATFORM_3 |
> #endif
> 0,
> FEATURE_ALWAYS =
> #ifdef CONFIG_PLATFORM_1
> PLATFORM_1 &
> #endif
> #ifdef CONFIG_PLATFORM_2
> PLATFORM_2 &
> #endif
> #ifdef CONFIG_PLATFORM_3
> PLATFORM_3 &
> #endif
> FEATURE_POSSIBLE,
> };
>
> static inline int have_feature(unsigned long feature)
> {
> return (FEATURE_ALWAYS & feature) ||
> (FEATURE_POSSIBLE & runtime_feature & feature);
> }
>
> int foo();
> int bar();
> int main(void)
> {
> if (have_feature(FEATURE_1))
> return foo();
> if (have_feature(FEATURE_2))
> return bar();
> return 0;
> }
> // end code
>
> Then gcc will produce optimal object code for any combination
> of CONFIG_PLATFORM_{1,2,3}. Of course I have to admit that the
> header file is not exactly elegant ;-).
>
> Arnd <><
>
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Kumar Gala @ 2005-09-15 17:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev
In-Reply-To: <17193.22140.962651.122114@cargo.ozlabs.ibm.com>
On Sep 15, 2005, at 6:09 AM, Paul Mackerras wrote:
> Jon Loeliger writes:
>
>
>> In the Grand Scheme of Things, removing things and making them
>> simpler seems a lofty goal. :-) Anyone know of any pitfalls that
>> await me if I try to remove these sections, a la pmac and friends?
>>
>
> You'll probably get most objection from the PReP users, for whom
> getting back a few hundred kB is a big deal. (Maybe we should just
> buy both of them a G5 or something. 8-)
If they care that much they should submit a patch to build a PReP
specific kernel that doesn't include this stuff. And while you are
buying G5's for people send one my way :)
I vote that we just get ride of this sections stuff for prep, pmac,
of, chrp and if we want to reduce the code size make it a compile
choice to build specific kernel's that dont include the crap that the
others need. (especially based on the numbers that Jon has posted
for size).
- kumar
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Jon Loeliger @ 2005-09-15 17:07 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev@ozlabs.org
In-Reply-To: <17193.22140.962651.122114@cargo.ozlabs.ibm.com>
On Thu, 2005-09-15 at 06:09, Paul Mackerras wrote:
> Jon Loeliger writes:
>
> > In the Grand Scheme of Things, removing things and making them
> > simpler seems a lofty goal. :-) Anyone know of any pitfalls that
> > await me if I try to remove these sections, a la pmac and friends?
>
> You'll probably get most objection from the PReP users, for whom
> getting back a few hundred kB is a big deal. (Maybe we should just
> buy both of them a G5 or something. 8-)
OK. I dug up some data.
Compiled ppc32 *_defconfig across the page.
Section down the left. All numbers are 4K pages.
OF is the so-called "__openfirmware" section.
pmac ibmchrp stx_gp3 mpc8555_cds
--------------------------------------
pmac 10 7 0 0
prep 2 2 0 0
chrp 1 1 0 0
OF 2 1 0 0
init 47 46 23 32
Over in arch/ppc/mm/init.c this gets done:
printk ("Freeing unused kernel memory:");
FREESEC(init);
if (_machine != _MACH_Pmac)
FREESEC(pmac);
if (_machine != _MACH_chrp)
FREESEC(chrp);
if (_machine != _MACH_prep)
FREESEC(prep);
if (!have_of)
FREESEC(openfirmware);
Toss sections that don't match your _machine.
Everyone tosses init section.
Embedded boards will take no hit.
Ppc64 currently does not have these special sections
and hence will see no impact here.
That is the cost of removing these section identifiers.
So, is everyone prepared to live with these few pages
of occasional increased image size and remove the
special sections?
Thanks,
jdl
^ permalink raw reply
* Re: PPC4xx cleanup
From: Matt Porter @ 2005-09-15 16:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200509151803.15301.sr@denx.de>
On Thu, Sep 15, 2005 at 06:03:14PM +0200, Stefan Roese wrote:
> Hi,
>
> I am right now testing and cleaning up some of the AMCC 4xx eval board ports
> to better support U-Boot as firmware. One question before I begin to send a
> few patches:
>
> All of the 44x boards I looked at (e.g. Ocotea) have to be extended in the
> platform file (e.g. platforms/4xx/ocotea.c) to not only copy the bd_info
> struct from r3, but also check r4 and r6 for initrd and kernel command line
> passing from the bootloader. Instead of adding this code to all different
> platform files, I would like to move this code to the common function
> "ibm44x_platform_init" (syslib/ibm44x_common.c) like it is done in the 40x
> ports "ppc4xx_init" (syslib/ppc4xx_setup.c).
>
> Any objections/remarks?
Sounds great to me. This will have to wait to go in mainline until
after 2.6.14 is out though.
-Matt
^ permalink raw reply
* PPC4xx cleanup
From: Stefan Roese @ 2005-09-15 16:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050830083859.B5925@cox.net>
Hi,
I am right now testing and cleaning up some of the AMCC 4xx eval board ports
to better support U-Boot as firmware. One question before I begin to send a
few patches:
All of the 44x boards I looked at (e.g. Ocotea) have to be extended in the
platform file (e.g. platforms/4xx/ocotea.c) to not only copy the bd_info
struct from r3, but also check r4 and r6 for initrd and kernel command line
passing from the bootloader. Instead of adding this code to all different
platform files, I would like to move this code to the common function
"ibm44x_platform_init" (syslib/ibm44x_common.c) like it is done in the 40x
ports "ppc4xx_init" (syslib/ppc4xx_setup.c).
Any objections/remarks?
Best regards,
Stefan
^ permalink raw reply
* non-inlined versions of local_irq*
From: Kumar Gala @ 2005-09-15 15:12 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: linuxppc64-dev
Anyone know why on ppc32 we have non-inlined versions of:
extern void local_irq_enable(void);
extern void local_irq_disable(void);
extern void local_irq_restore(unsigned long);
extern void local_save_flags_ptr(unsigned long *);
From looking at the code they are never used. Just wondering if
this was for debug or some other reason.
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: don't execute a temporary comment
From: John W. Linville @ 2005-09-15 14:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, ppc64-dev
In-Reply-To: <20050915160430.550d02ed.sfr@canb.auug.org.au>
On Thu, Sep 15, 2005 at 04:04:30PM +1000, Stephen Rothwell wrote:
> --- a/arch/ppc/Makefile
> +++ b/arch/ppc/Makefile
> @@ -102,9 +102,9 @@ define archhelp
> @echo ' *_defconfig - Select default config from arch/$(ARCH)/ppc/configs'
> endef
>
> +# arch/$(ARCH)/include is a temporary hack until we have migrated to asm-powerpc
> archclean:
> $(Q)$(MAKE) $(clean)=arch/ppc/boot
> - # Temporary hack until we have migrated to asm-powerpc
> $(Q)rm -rf arch/$(ARCH)/include
>
> archprepare: checkbin
Why is this helpful? Better in general to keep the commment near the code, no?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Paul Mackerras @ 2005-09-15 11:18 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, linux-ppc-embedded
In-Reply-To: <20050913175028.GB14889@dmt.cnet>
Marcelo Tosatti writes:
> This test&branch looks AltiVec specific, any reason for not #ifdef'ing it
> out?
No, your patch looks fine. (/me wishes patchwork had a "Queued"
state.)
Paul.
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Paul Mackerras @ 2005-09-15 11:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc64-dev, Arnd Bergmann, linuxppc-dev@ozlabs.org
In-Reply-To: <1126705588.14036.10.camel@cashmere.sps.mot.com>
Jon Loeliger writes:
> In the Grand Scheme of Things, removing things and making them
> simpler seems a lofty goal. :-) Anyone know of any pitfalls that
> await me if I try to remove these sections, a la pmac and friends?
You'll probably get most objection from the PReP users, for whom
getting back a few hundred kB is a big deal. (Maybe we should just
buy both of them a G5 or something. 8-)
> And I assume that the obvious mappings can take place (ie, that
> "pmac.text" can just be placed in regular .text, etc), right?
Yes.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Merged ppc_asm.h
From: Paul Mackerras @ 2005-09-15 10:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <F0F2A9CC-F204-407C-A9FA-A60818D09DAB@freescale.com>
Kumar Gala writes:
> What's the status of applying this to your tree?
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=2330
I'm going to start up a ppc-merge.git tree on kernel.org soon. I
don't intend to send any more 32/64 merge patches to Linus until after
2.6.14 is out.
Regards,
Paul.
^ permalink raw reply
* Re: A question about the /dev/ide
From: Clemens Koller @ 2005-09-15 10:41 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E86506C@ydmail.sbell.com.cn>
Hello, Wang Baohua!
FCG WANG Baohua wrote:
> Dear all:
> I had use the UPM of MPC8270 to create the device driver of my pcmcia CF card.
Just an idea: There are IDE-to-CF adapters and PCI-IDE adapters with working drivers.
(for evaluation)
> How to create the "/dev/hda" device nodes? I had only "/dev/ide" device nodes,
> I want to use command like "mkswap /dev/hda4".
> When I use "mkswap /dev/ide/host0/bus0/target0/lun0/part1p4",
> it shows the "No such file or directory" message. How can I create
> the right device nodes? thanks!
man mknod?
But maybe you want to read some more things about devfs, udev, ... /etc/devfsd.conf
before you know what you are doing there?
Well... all that depends on your kernel/system config a bit...
Best greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Segher Boessenkool @ 2005-09-15 8:21 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, cort, linux-ppc-embedded
In-Reply-To: <20050913203555.GB18639@dmt.cnet>
>> This probably has to due with what happens on a G4 system with a
>> kernel not build with Altivec.. However, I dont remember exactly what
>> behavior is desired.
A kernel not build with AltiVec support will just
SIGILL any user process that tries to use it (and
MSR[VEC] = 0).
The code here can safely be #ifdef'ed out (but note
I only looked at the code, I didn't test it ;-) )
Segher
^ permalink raw reply
* Re: Help on 8260 board
From: Tore Martin Hagen @ 2005-09-15 8:24 UTC (permalink / raw)
To: prabha.j; +Cc: linuxppc-embedded
In-Reply-To: <OF29F8842B.21C92BA3-ON6525707B.0016F392-6525707B.0017A365@tcs.com>
Hi,
To change u-boot for your needs you will need to do approximately the
following:
copy include/configs/MPC8260ADS.h to include/configs/YOURBOARD8260.h
Print out the the file and sit down with the 8260 ref. manual. Adjust
the YOURBOARD8260.h to fit your needs. (If you are not a HW designer
this will definitely take you some time)
Added a new directory
board/yourboard8260
copied the following files from board/mpc8266ads to board/fox8275:
config.mk
flash.c
Makefile
mpc8260ads.c -> yourboard8260.c
u-boot.lds
Changed the files to fit the your board.
Changed the main Makefile to support a new target
> YOURBOARD8260_config: unconfig
> @./mkconfig $(@:_config=) ppc mpc8260 yourboard8260
good luck
^ permalink raw reply
* Re: How to use kerberos in ELDK
From: Wolfgang Denk @ 2005-09-15 7:08 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linux-ppc-embedded
In-Reply-To: <20050915062857.B598968263@ozlabs.org>
In message <20050915062857.B598968263@ozlabs.org> you wrote:
>
> I have loadload ELDK-3.1.1 (ppc-2005-03-07 & ppc-2005-03-07-src), but
> whatever I try it, it doesn't work.
Can you please provide a specific example command you tried (and make
sure that it's working in a standard Linux environment), and post it
with a complete list of all output and error messages it produces?
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
Calm down, it's *__only* ones and zeroes.
^ permalink raw reply
* MPC5200 BestComm
From: zhonglei @ 2005-09-15 7:10 UTC (permalink / raw)
To: linuxppc-dev
hi:
My BestComm driver encounter the TEA.Please give
me a help!
The register values are as follows:
/**********************************************/
Setting BestComm Interface to the Local Plus
Bus......Set GR=001
starts DMA when 0x000001f3 bytes!
[ OK ]
MPC5xxx_MBAR+0x3C04 is 0x00000140
MPC5xxx_MBAR+0x3C08 is 0x03010002
MPC5xxx_MBAR+0x3C0C is 0x00000101
MPC5xxx_MBAR+0x3C48 is 0x01000000
MPC5xxx_MBAR+0x3C4C is 0x000001F3
MPC5xxx_MBAR+0x3C00 is 0x00000010
Starting BestComm setting......
TaskSetup......[ OK ]
LPRDTaskId=0x00000004
BestComm request_irq
succeed!MPC5xxx_SDMA_IRQ_BASE+LPRDTaskId=0x00000019
TaskStart running ......[ OK ]
htm_open: LPRDTaskId task 4 started
Kick off FIFO!
irq is entered!
TaskIntStatus=0xFFFFFFFF
End of irq!
MPC5xxx_MBAR+0x1F64 is 0x00000007
MPC5xxx_MBAR+0x1F68 is 0x00007121 // this is
the priority setting
MPC5xxx_MBAR+0x0500 is 0x0AFFFD00
MPC5xxx_MBAR+0x0504 is 0x00000000
MPC5xxx_MBAR+0x0508 is 0x00000000
MPC5xxx_MBAR+0x050C is 0x00000000
MPC5xxx_MBAR+0x0510 is 0x00D01001
MPC5xxx_MBAR+0x0514 is 0x00010FFF
MPC5xxx_MBAR+0x0518 is 0x00000000
MPC5xxx_MBAR+0x051C is 0x00000000
MPC5xxx_MBAR+0x0524 is 0x00000001
MPC5xxx_MBAR+0x0528 is 0x00000000
MPC5xxx_MBAR+0x052C is 0x00002000
MPC5xxx_MBAR+0x0530 is 0x00800000
MPC5xxx_MBAR+0x0538 is 0x00000000
MPC5xxx_MBAR+0x3C44 is 0x00020000
MPC5xxx_MBAR+0x3C48 is 0x01000000
MPC5xxx_MBAR+0x3C4C is 0x000001F3
MPC5xxx_MBAR+0x3C50 is 0x00000008 // readptr is
correct (I set bestcomm transfer 8 bytes from fifo
LPTaskParam.Size.NumBytes = 8;)
MPC5xxx_MBAR+0x3C54 is 0x00000010 // writeptr is
correct
MPC5xxx_MBAR+0x3C14 is 0x01000010 // bytedone is
correct
MPC5xxx_MBAR+0x1218 is 0xFFFFFFE3
MPC5xxx_MBAR+0x1214 is 0x14000000 // a TEA on
task 4 happens!!!
MPC5xxx_MBAR+0x1210 is 0x0F0F0001
MPC5xxx_MBAR+0x121C is 0x03002000
MPC5xxx_MBAR+0x1220 is 0x20C2C3C3
MPC5xxx_MBAR+0x1224 is 0x204400C5
MPC5xxx_MBAR+0x1228 is 0x00000000
MPC5xxx_MBAR+0x122C is 0x00000000
MPC5xxx_MBAR+0x1230 is 0x00000000
MPC5xxx_MBAR+0x1234 is 0x00000000
MPC5xxx_MBAR+0x1238 is 0x00000000
MPC5xxx_MBAR+0x123C is 0x07000006
MPC5xxx_MBAR+0x1240 is 0x05000000
MPC5xxx_MBAR+0x1244 is 0x00000000
MPC5xxx_MBAR+0x1248 is 0x00000000
MPC5xxx_MBAR+0x124C is 0x07000000
MPC5xxx_MBAR+0x1250 is 0x00000000
MPC5xxx_MBAR+0x1254 is 0x00000000
MPC5xxx_MBAR+0x1258 is 0x00000000
MPC5xxx_MBAR+0x1F48 is 0x00000103 // data tenure
time-out and address tenure time-out
MPC5xxx_MBAR+0x1F58 is 0x0FFFFFFF
MPC5xxx_MBAR+0x1F5C is 0x0FFFFFFF
MPC5xxx_MBAR+0x1F50 is 0xC1C24CC0 // captured
address
MPC5xxx_MBAR+0x1F54 is 0x00000062 // captured
signal
/**********************************************/
Please give me a help!!!!
Thanks a lot!
BestRegards
zhonglei
^ permalink raw reply
* How to use kerberos in ELDK
From: JohnsonCheng @ 2005-09-15 6:28 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Dear All,
I have loadload ELDK-3.1.1 (ppc-2005-03-07 & ppc-2005-03-07-src), but
whatever I try it, it doesn't work.
Do anybody know how to use it?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 3109 bytes --]
^ 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