* 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: 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: 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: 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: 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 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
* 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: 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
* Re: SRAM support for the Pegasos II platform
From: Dale Farnsworth @ 2005-09-15 23:44 UTC (permalink / raw)
To: det.nicolas; +Cc: linuxppc-dev
In-Reply-To: <20050914091229.A27721C007F7@mwinf0309.wanadoo.fr>
In article <20050914091229.A27721C007F7@mwinf0309.wanadoo.fr> you write:
> You can find enclosed or at the URL a patch for the 2.6.14-rc1.
> http://arrakin.homedns.org/~nicolas/mv643xx_eth_chrp_pegasos_eth.c.2.6.14-rc1.diff
>
> It allows (with drivers/net/mv643xx_eth.*) to take advantage of the SRAM of
> the Marvell Discovery II for the network driver.
>
> Reviews and comments welcome.
Hi Nicolas,
+#define PEGASOS2_SRAM_SIZE (0x00008000)
I think the SRAM is 256KB, so shouldn't this be 0x00040000 ?
-Dale
^ permalink raw reply
* How to dump D-cache
From: Shawn Jin @ 2005-09-16 0:00 UTC (permalink / raw)
To: ppcembed
Hi,
The instruction dcread is used to read data cache. The syntax is
dcread RT,RA,RB. The effective address is formed by adding RA to RB.
In order to read a specific cache line or the whole d-cache, how do I
know the effective addresses correponding to the cache line(s)? The
processor is ppc440.
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH] powerpc: merge include/asm/cputable.h
From: Kumar Gala @ 2005-09-16 2:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, pantelis.antoniou, linuxppc64-dev,
linuxppc-embedded
In-Reply-To: <200509160056.32617.arnd@arndb.de>
On Sep 15, 2005, at 5:56 PM, Arnd Bergmann wrote:
> 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_ ...
Yes, something like that. Why do we need the CPU_FTR_ALWAYS. It
seems that CPU_FTR_POSSIBLE is sufficient. I may just not understand
the purpose of CPU_FTR_ALWAYS.
> 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.
Well if you are adding a new FTR you better know what CPUs it belongs
to otherwise how would you update the cputable today? However, I do
agree it could be error prone.
> 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.
These should stay as CONFIG options because to reduce the code size
of the kernel which is important to embedded people.
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: don't execute a temporary comment
From: Kumar Gala @ 2005-09-16 2:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev, ppc64-dev, Stephen Rothwell
In-Reply-To: <17193.64509.576852.408757@cargo.ozlabs.ibm.com>
We are going to send this to Linus for 2.6.14, right?
- k
On Sep 15, 2005, at 5:55 PM, Paul Mackerras wrote:
> 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.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: merge include/asm/cputable.h
From: Arnd Bergmann @ 2005-09-16 3:11 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, pantelis.antoniou, linuxppc64-dev,
linuxppc-embedded
In-Reply-To: <D6BA4E97-B338-4584-8ECD-440FC70AFED0@freescale.com>
On Freedag 16 September 2005 04:22, Kumar Gala wrote:
> > #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_ ...
>
> Yes, something like that. Why do we need the CPU_FTR_ALWAYS. It
> seems that CPU_FTR_POSSIBLE is sufficient. I may just not understand
> the purpose of CPU_FTR_ALWAYS.
>
> > 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.
>
> These should stay as CONFIG options because to reduce the code size
> of the kernel which is important to embedded people.
The whole point of the logic is to reduce code size, because gcc
is smart enough to remove all dead code then.
Consider again the definition of
| static inline int have_feature(unsigned long feature)
| {
| return (FEATURE_ALWAYS & feature) ||
| (FEATURE_POSSIBLE & runtime_feature & feature);
| }
If the feature is part of FEATURE_ALWAYS, this will be optimized to
| return 1 || FEATURE_POSSIBLE & runtime_feature & feature;
and subsequently
| return 1;
If it is not part of FEATURE_POSSIBLE, it it equivalent to
| return 0 || (0 & runtime_feature & feature);
which becomes
| return 0;
Any code inside of
| if (0) { /* ... */ }
is only checked for syntax by gcc but will not end up in the object code.
For the 'if(1)' case, the code gets smaller as well, because the runtime
flag does not have to be dereferenced.
For some places, we might prefer to replace '#ifdef CONFIG_FOO' not with
have_feature(FOO), but rather with feature_possible(FOO), given a definition
of
static inline int have_feature(unsigned int feature)
{
return !!(FEATURE_POSSIBLE & feature);
}
which always get evaluated at compile time.
Arnd <><
^ permalink raw reply
* RE: How to use kerberos in ELDK
From: JohnsonCheng @ 2005-09-16 3:11 UTC (permalink / raw)
To: wd; +Cc: 'linux-ppc-embedded'
In-Reply-To: <20050915070803.A0EB33529BB@atlas.denx.de>
1. For ppc-2005-03-07-src,
[root]# rpm -iv krb5-1.2.7-14_3.src.rpm
Warning: user builder does not exist - using root
Warning: group builder does not exist - using root
..................
2. For ppc-2005-03-07
[root]# rpm -iv krb5-libs-ppc_6xx-1.2.7-14_3.ppc.rpm
Error: Failed dependencies:
grep-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
sh-utils-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
[root]# rpm -iv grep-ppc_6xx-2.5.1-4_1.ppc.rpm
Preparing packages for installation...
Package grep-ppc_6xx-2.5.1-4_1 is intended for a ppc
architecture
File /bin/egrep freom install of grep-ppc_6xx-2.5.1-4_1
conflicts with file from package grep-2.5.1-26
................
Ps: My build machine is x86, therefore, my target ppc board has not
enough space to do this, how can I get krb5 library from ELDK on x86?
Thanks,
Johnson Cheng
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Thursday, September 15, 2005 3:08 PM
To: JohnsonCheng
Cc: linux-ppc-embedded
Subject: Re: How to use kerberos in ELDK
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
* A mtd timeout issue on ppc
From: JohnsonCheng @ 2005-09-16 3:28 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
The size of initrd.boot is about 8.5M, then
dd if=initrd.boot of=/dev/mtd2, cause
MTD do_write_buffer(): software timeout
dd: /dev/mtd2: Input/output error
When I change the size of initrd.boot to about 2M, it's OK.
But this 8.5M file can transit by U-boot.
Why ?? Is kernel issue or MTD utility issue ?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 3744 bytes --]
^ permalink raw reply
* Re: How to use kerberos in ELDK
From: Wolfgang Denk @ 2005-09-16 6:32 UTC (permalink / raw)
To: JohnsonCheng; +Cc: 'linux-ppc-embedded'
In-Reply-To: <20050916031236.E521942DDD@denx.de>
In message <20050916031236.E521942DDD@denx.de> you wrote:
> 1. For ppc-2005-03-07-src,
> [root]# rpm -iv krb5-1.2.7-14_3.src.rpm
There is no need to be root to install the ELDK or ELDK packages.
Also, you should read (and follow) the documentation; the manual
explains in deatil that you have to use the ELLDK's own RPM-tool to
install (or remove) ELDK packets. For details please see
http://www.denx.de/twiki/bin/view/DULG/ELDKIndividualPackages
> 2. For ppc-2005-03-07
> [root]# rpm -iv krb5-libs-ppc_6xx-1.2.7-14_3.ppc.rpm
> Error: Failed dependencies:
> grep-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
> sh-utils-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
> [root]# rpm -iv grep-ppc_6xx-2.5.1-4_1.ppc.rpm
> Preparing packages for installation...
> Package grep-ppc_6xx-2.5.1-4_1 is intended for a ppc
> architecture
> File /bin/egrep freom install of grep-ppc_6xx-2.5.1-4_1
> conflicts with file from package grep-2.5.1-26
All these are consequences of your wrong commands.
You must use "${CROSS_COMPILE}rpm" instead.
> Ps: My build machine is x86, therefore, my target ppc board has not
> enough space to do this, how can I get krb5 library from ELDK on x86?
Actually these get installed by default when you install the ELDK:
-> ppc_8xx-rpm -q krb5-devel krb5-libs
krb5-devel-ppc_8xx-1.2.7-14_3
krb5-libs-ppc_8xx-1.2.7-14_3
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
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
^ permalink raw reply
* RE: How to use kerberos in ELDK
From: JohnsonCheng @ 2005-09-16 7:00 UTC (permalink / raw)
To: wd; +Cc: 'linux-ppc-embedded'
In-Reply-To: <20050916063238.24A5B352B7B@atlas.denx.de>
Dear Wolfgang,
Maybe I meet the big trouble.
I find no powerpc-linux-rpm in my build machine, only have
powerpc-linux-gcc, powerpc-linux-ar .....
What should I do?
Thanks,
Johnson Cheng
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, September 16, 2005 2:33 PM
To: JohnsonCheng
Cc: 'linux-ppc-embedded'
Subject: Re: How to use kerberos in ELDK
In message <20050916031236.E521942DDD@denx.de> you wrote:
> 1. For ppc-2005-03-07-src,
> [root]# rpm -iv krb5-1.2.7-14_3.src.rpm
There is no need to be root to install the ELDK or ELDK packages.
Also, you should read (and follow) the documentation; the manual
explains in deatil that you have to use the ELLDK's own RPM-tool to
install (or remove) ELDK packets. For details please see
http://www.denx.de/twiki/bin/view/DULG/ELDKIndividualPackages
> 2. For ppc-2005-03-07
> [root]# rpm -iv krb5-libs-ppc_6xx-1.2.7-14_3.ppc.rpm
> Error: Failed dependencies:
> grep-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
> sh-utils-ppc_6xx is needed by krb5-libs-ppc_6xx-1.2.7-14_3
> [root]# rpm -iv grep-ppc_6xx-2.5.1-4_1.ppc.rpm
> Preparing packages for installation...
> Package grep-ppc_6xx-2.5.1-4_1 is intended for a ppc
> architecture
> File /bin/egrep freom install of grep-ppc_6xx-2.5.1-4_1
> conflicts with file from package grep-2.5.1-26
All these are consequences of your wrong commands.
You must use "${CROSS_COMPILE}rpm" instead.
> Ps: My build machine is x86, therefore, my target ppc board has not
> enough space to do this, how can I get krb5 library from ELDK on x86?
Actually these get installed by default when you install the ELDK:
-> ppc_8xx-rpm -q krb5-devel krb5-libs
krb5-devel-ppc_8xx-1.2.7-14_3
krb5-libs-ppc_8xx-1.2.7-14_3
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
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
^ permalink raw reply
* Re: Getting Perl on Embedded Linux PowerPC
From: Clemens Koller @ 2005-09-16 8:57 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050915191243.GA52539@mail19d.g19.rapidsite.net>
Hello, Russell!
Russell McGuire 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.
>
> 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.
I was compiling and running Perl on my mpc8540 system (natively)...
I haven't had any problems with that.
$ perl --version
This is perl, v5.8.6 built for ppc-linux
----- my (old) install log says:
perl:
wget ftp://.../perl-5.8.6.tar.gz
tar ...
less INSTALL
rm -f config.sh Policy.sh
sh Configure
or
sh Configure -de (for default installation)
make
make test
and it should end up with something like:
All tests successful.
u=6.52 s=0.89 cu=415.95 cs=22.58 scripts=845 tests=87560
make[2]: Leaving directory `/home/clemens/build/perl-5.8.6'
make[1]: Leaving directory `/home/clemens/build/perl-5.8.6'
and finally:
su -
make install
-----
> Or perhaps a pre-compiled RPM that installs, that is built for PowerPC.
Sorry, no rpm's over here. Which PowerPC?
> I am using DENX Linux 2.4.25 at the moment, with pretty much the default
> root file system that is provided.
Should be no problem, I think. I started with that too, a long time ago.
Give it a try. You just need make sure that you don't run out of coffee! ;-)
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
* Java on PowerPC
From: Rita Carvalho @ 2005-09-16 8:41 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I am trying use IBMJava2-SDK-142.ppc.tgz in a PowerPc 440 GX with
Montavista.
When I try the command ./java - version the error Illegal instruction
(core dumped) occurs.
Can you please help me?
Thank you for your attention.
_________________________________________________________________
MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com
^ permalink raw reply
* Re: Java on PowerPC
From: Marius Groeger @ 2005-09-16 9:51 UTC (permalink / raw)
To: Rita Carvalho; +Cc: linuxppc-embedded
In-Reply-To: <BAY7-F9CCE196E3FF0097799A069E910@phx.gbl>
On Fri, 16 Sep 2005, Rita Carvalho wrote:
> I am trying use IBMJava2-SDK-142.ppc.tgz in a PowerPc 440 GX with
> Montavista. When I try the command ./java - version the error
> Illegal instruction (core dumped) occurs.
Just a guess: have you turned on FPU emulation in the kernel
configuration?
Regards,
Marius
--
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
^ permalink raw reply
* [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
From: Stefan Roese @ 2005-09-16 11:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050915092555.A27452@cox.net>
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
Add U-Boot support to AMCC PPC405 eval boards (bubinga, sycamore and walnut)
and cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea) to better
support U-Boot as bootloader.
Signed-off-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
[-- Attachment #2: ppc4xx_u-boot.patch --]
[-- Type: text/x-diff, Size: 12650 bytes --]
[PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
Add U-Boot support to AMCC PPC405 eval boards (bubinga, sycamore and walnut)
and cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea) to better
support U-Boot as bootloader.
Signed-off-by: Stefan Roese <sr@denx.de>
---
commit ca5c0372ee8b8ea6c6090665743cc5fb90eb667d
tree 9306e22f6c382dc54b2b57d14c321a5baf101da7
parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
author Stefan Roese <sr@denx.de> Fri, 16 Sep 2005 12:52:16 +0200
committer Stefan Roese <sr@denx.de> Fri, 16 Sep 2005 12:52:16 +0200
arch/ppc/platforms/4xx/Kconfig | 14 +++++++++++---
arch/ppc/platforms/4xx/bamboo.c | 14 ++------------
arch/ppc/platforms/4xx/bubinga.c | 20 ++++++++++++++++++++
arch/ppc/platforms/4xx/bubinga.h | 7 +++++++
arch/ppc/platforms/4xx/ebony.c | 13 ++-----------
arch/ppc/platforms/4xx/luan.c | 13 ++-----------
arch/ppc/platforms/4xx/ocotea.c | 31 +++++++++++--------------------
arch/ppc/platforms/4xx/sycamore.c | 2 +-
arch/ppc/platforms/4xx/sycamore.h | 7 +++++++
arch/ppc/platforms/4xx/walnut.h | 7 +++++++
arch/ppc/syslib/ibm44x_common.c | 35 ++++++++++++++++++++++++++++++++++-
arch/ppc/syslib/ibm44x_common.h | 3 ++-
include/asm-ppc/ppcboot.h | 4 ++--
13 files changed, 108 insertions(+), 62 deletions(-)
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -212,10 +212,18 @@ config EMBEDDEDBOOT
depends on EP405 || XILINX_ML300
default y
-config IBM_OPENBIOS
- bool
+choice
+ prompt "Bootloader support"
depends on ASH || BUBINGA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
- default y
+ default IBM_OPENBIOS
+
+config IBM_OPENBIOS
+ bool "IBM OpenBIOS"
+
+config UBOOT
+ bool "U-Boot"
+
+endchoice
config PPC4xx_DMA
bool "PPC4xx DMA controller support"
diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c
--- a/arch/ppc/platforms/4xx/bamboo.c
+++ b/arch/ppc/platforms/4xx/bamboo.c
@@ -52,7 +52,7 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
-bd_t __res;
+extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
@@ -426,17 +426,7 @@ bamboo_setup_arch(void)
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- parse_bootinfo(find_bootinfo());
-
- /*
- * If we were passed in a board information, copy it into the
- * residual data area.
- */
- if (r3)
- __res = *(bd_t *)(r3 + KERNELBASE);
-
-
- ibm44x_platform_init();
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = bamboo_setup_arch;
ppc_md.show_cpuinfo = bamboo_show_cpuinfo;
diff --git a/arch/ppc/platforms/4xx/bubinga.c b/arch/ppc/platforms/4xx/bubinga.c
--- a/arch/ppc/platforms/4xx/bubinga.c
+++ b/arch/ppc/platforms/4xx/bubinga.c
@@ -89,7 +89,11 @@ bubinga_early_serial_map(void)
* by 16.
*/
uart_div = (mfdcr(DCRN_CPC0_UCR_BASE) & DCRN_CPC0_UCR_U0DIV);
+#ifdef CONFIG_UBOOT
+ uart_clock = __res.bi_procfreq / uart_div;
+#else
uart_clock = __res.bi_pllouta_freq / uart_div;
+#endif
/* Setup serial port access */
memset(&port, 0, sizeof(port));
@@ -218,9 +222,25 @@ bios_fixup(struct pci_controller *hose,
void __init
bubinga_setup_arch(void)
{
+#ifdef CONFIG_UBOOT
+ struct ocp_def *def;
+ struct ocp_func_emac_data *emacdata;
+#endif
+
ppc4xx_setup_arch();
+#ifdef CONFIG_UBOOT
+ /* Set mac_addr for each EMAC */
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
+ emacdata = def->additions;
+ memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
+ emacdata = def->additions;
+ memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
+#else
ibm_ocp_set_emac(0, 1);
+#endif
bubinga_early_serial_map();
diff --git a/arch/ppc/platforms/4xx/bubinga.h b/arch/ppc/platforms/4xx/bubinga.h
--- a/arch/ppc/platforms/4xx/bubinga.h
+++ b/arch/ppc/platforms/4xx/bubinga.h
@@ -18,6 +18,8 @@
#include <platforms/4xx/ibm405ep.h>
#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_IBM_OPENBIOS
/*
* Data structure defining board information maintained by the boot
* ROM on IBM's evaluation board. An effort has been made to
@@ -36,6 +38,11 @@ typedef struct board_info {
unsigned int bi_opb_busfreq; /* OPB Bus speed, in Hz */
unsigned int bi_pllouta_freq; /* PLL OUTA speed, in Hz */
} bd_t;
+#elif CONFIG_UBOOT
+#include <asm/ppcboot.h>
+#else
+#error "Please enable either IBM OpenBIOS or U-Boot bootloader support!"
+#endif
/* Some 4xx parts use a different timebase frequency from the internal clock.
*/
diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
--- a/arch/ppc/platforms/4xx/ebony.c
+++ b/arch/ppc/platforms/4xx/ebony.c
@@ -55,7 +55,7 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gp_common.h>
-bd_t __res;
+extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
@@ -318,16 +318,7 @@ ebony_setup_arch(void)
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- parse_bootinfo(find_bootinfo());
-
- /*
- * If we were passed in a board information, copy it into the
- * residual data area.
- */
- if (r3)
- __res = *(bd_t *)(r3 + KERNELBASE);
-
- ibm44x_platform_init();
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = ebony_setup_arch;
ppc_md.show_cpuinfo = ebony_show_cpuinfo;
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -53,7 +53,7 @@
#include <syslib/ibm440gx_common.h>
#include <syslib/ibm440sp_common.h>
-bd_t __res;
+extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
@@ -356,16 +356,7 @@ luan_setup_arch(void)
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- parse_bootinfo(find_bootinfo());
-
- /*
- * If we were passed in a board information, copy it into the
- * residual data area.
- */
- if (r3)
- __res = *(bd_t *)(r3 + KERNELBASE);
-
- ibm44x_platform_init();
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = luan_setup_arch;
ppc_md.show_cpuinfo = luan_show_cpuinfo;
diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
--- a/arch/ppc/platforms/4xx/ocotea.c
+++ b/arch/ppc/platforms/4xx/ocotea.c
@@ -53,7 +53,7 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
-bd_t __res;
+extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
@@ -287,6 +287,15 @@ ocotea_setup_arch(void)
ibm440gx_tah_enable();
+ /*
+ * Determine various clocks.
+ * To be completely correct we should get SysClk
+ * from FPGA, because it can be changed by on-board switches
+ * --ebs
+ */
+ ibm440gx_get_clocks(&clocks, 33333333, 6 * 1843200);
+ ocp_sys_info.opb_bus_freq = clocks.opb;
+
/* Setup TODC access */
TODC_INIT(TODC_TYPE_DS1743,
0,
@@ -325,25 +334,7 @@ static void __init ocotea_init(void)
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- parse_bootinfo(find_bootinfo());
-
- /*
- * If we were passed in a board information, copy it into the
- * residual data area.
- */
- if (r3)
- __res = *(bd_t *)(r3 + KERNELBASE);
-
- /*
- * Determine various clocks.
- * To be completely correct we should get SysClk
- * from FPGA, because it can be changed by on-board switches
- * --ebs
- */
- ibm440gx_get_clocks(&clocks, 33333333, 6 * 1843200);
- ocp_sys_info.opb_bus_freq = clocks.opb;
-
- ibm44x_platform_init();
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = ocotea_setup_arch;
ppc_md.show_cpuinfo = ocotea_show_cpuinfo;
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -100,7 +100,7 @@ sycamore_setup_arch(void)
ppc4xx_setup_arch();
- ibm_ocp_set_emac(0, 1);
+ ibm_ocp_set_emac(0, 0);
kb_data = ioremap(SYCAMORE_PS2_BASE, 8);
if (!kb_data) {
diff --git a/arch/ppc/platforms/4xx/sycamore.h b/arch/ppc/platforms/4xx/sycamore.h
--- a/arch/ppc/platforms/4xx/sycamore.h
+++ b/arch/ppc/platforms/4xx/sycamore.h
@@ -19,6 +19,8 @@
#include <platforms/4xx/ibm405gpr.h>
#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_IBM_OPENBIOS
/*
* Data structure defining board information maintained by the boot
* ROM on IBM's "Sycamore" evaluation board. An effort has been made to
@@ -36,6 +38,11 @@ typedef struct board_info {
unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
} bd_t;
+#elif CONFIG_UBOOT
+#include <asm/ppcboot.h>
+#else
+#error "Please enable either IBM OpenBIOS or U-Boot bootloader support!"
+#endif
/* Some 4xx parts use a different timebase frequency from the internal clock.
*/
diff --git a/arch/ppc/platforms/4xx/walnut.h b/arch/ppc/platforms/4xx/walnut.h
--- a/arch/ppc/platforms/4xx/walnut.h
+++ b/arch/ppc/platforms/4xx/walnut.h
@@ -24,6 +24,8 @@
#include <platforms/4xx/ibm405gp.h>
#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_IBM_OPENBIOS
/*
* Data structure defining board information maintained by the boot
* ROM on IBM's "Walnut" evaluation board. An effort has been made to
@@ -41,6 +43,11 @@ typedef struct board_info {
unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
} bd_t;
+#elif CONFIG_UBOOT
+#include <asm/ppcboot.h>
+#else
+#error "Please enable either IBM OpenBIOS or U-Boot bootloader support!"
+#endif
/* Some 4xx parts use a different timebase frequency from the internal clock.
*/
diff --git a/arch/ppc/syslib/ibm44x_common.c b/arch/ppc/syslib/ibm44x_common.c
--- a/arch/ppc/syslib/ibm44x_common.c
+++ b/arch/ppc/syslib/ibm44x_common.c
@@ -27,9 +27,14 @@
#include <asm/time.h>
#include <asm/ppc4xx_pic.h>
#include <asm/param.h>
+#include <asm/bootinfo.h>
+#include <asm/ppcboot.h>
#include <syslib/gen550.h>
+/* Global Variables */
+bd_t __res;
+
phys_addr_t fixup_bigphys_addr(phys_addr_t addr, phys_addr_t size)
{
phys_addr_t page_4gb = 0;
@@ -150,8 +155,36 @@ static unsigned long __init ibm44x_find_
return mem_size;
}
-void __init ibm44x_platform_init(void)
+void __init ibm44x_platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
{
+ parse_bootinfo(find_bootinfo());
+
+ /*
+ * If we were passed in a board information, copy it into the
+ * residual data area.
+ */
+ if (r3)
+ __res = *(bd_t *)(r3 + KERNELBASE);
+
+#if defined(CONFIG_BLK_DEV_INITRD)
+ /*
+ * If the init RAM disk has been configured in, and there's a valid
+ * starting address for it, set it up.
+ */
+ if (r4) {
+ initrd_start = r4 + KERNELBASE;
+ initrd_end = r5 + KERNELBASE;
+ }
+#endif /* CONFIG_BLK_DEV_INITRD */
+
+ /* Copy the kernel command line arguments to a safe place. */
+
+ if (r6) {
+ *(char *) (r7 + KERNELBASE) = 0;
+ strcpy(cmd_line, (char *) (r6 + KERNELBASE));
+ }
+
ppc_md.init_IRQ = ppc4xx_pic_init;
ppc_md.find_end_of_memory = ibm44x_find_end_of_memory;
ppc_md.restart = ibm44x_restart;
diff --git a/arch/ppc/syslib/ibm44x_common.h b/arch/ppc/syslib/ibm44x_common.h
--- a/arch/ppc/syslib/ibm44x_common.h
+++ b/arch/ppc/syslib/ibm44x_common.h
@@ -36,7 +36,8 @@ struct ibm44x_clocks {
};
/* common 44x platform init */
-void ibm44x_platform_init(void) __init;
+void ibm44x_platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7) __init;
/* initialize decrementer and tick-related variables */
void ibm44x_calibrate_decr(unsigned int freq) __init;
diff --git a/include/asm-ppc/ppcboot.h b/include/asm-ppc/ppcboot.h
--- a/include/asm-ppc/ppcboot.h
+++ b/include/asm-ppc/ppcboot.h
@@ -73,8 +73,8 @@ typedef struct bd_info {
#if defined(CONFIG_HYMOD)
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
-#if defined(CONFIG_EVB64260) || defined(CONFIG_44x) || defined(CONFIG_85xx) ||\
- defined(CONFIG_83xx)
+#if defined(CONFIG_EVB64260) || defined(CONFIG_405EP) || defined(CONFIG_44x) || \
+ defined(CONFIG_85xx) || defined(CONFIG_83xx)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#endif
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: How to use kerberos in ELDK
From: Wolfgang Denk @ 2005-09-16 11:23 UTC (permalink / raw)
To: JohnsonCheng; +Cc: 'linux-ppc-embedded'
In-Reply-To: <20050916070358.781D2422AF@denx.de>
In message <20050916070358.781D2422AF@denx.de> you wrote:
>
> Maybe I meet the big trouble.
> I find no powerpc-linux-rpm in my build machine, only have
> powerpc-linux-gcc, powerpc-linux-ar .....
> What should I do?
You should really READ the documentation. It says, and I explicitely
quoted this in my previous posting:
> You must use "${CROSS_COMPILE}rpm" instead.
So instead of trying powerpc-linux-rpm which indeed does not exist
you should run ppc_8xx-rpm or whichever other architecture you're
using (alternatively ppc-rpm would work, but this is undocumented and
not recommended).
Please RTFM!
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
"...and the fully armed nuclear warheads, are, of course, merely a
courtesy detail."
^ permalink raw reply
* Re: Java on PowerPC
From: Robert Swindells @ 2005-09-16 11:07 UTC (permalink / raw)
To: ritac_c; +Cc: linuxppc-embedded
In-Reply-To: <BAY7-F9CCE196E3FF0097799A069E910@phx.gbl>
Rita Carvalho wrote:
>I am trying use IBMJava2-SDK-142.ppc.tgz in a PowerPc 440 GX with
>Montavista.
>When I try the command ./java - version the error Illegal instruction
>(core dumped) occurs.
<http://www-128.ibm.com/developerworks/linux/library/l-pow-apple.html>
^ permalink raw reply
* RE: How to use kerberos in ELDK
From: JohnsonCheng @ 2005-09-16 12:09 UTC (permalink / raw)
To: wd; +Cc: 'linux-ppc-embedded'
In-Reply-To: <20050916112324.0528D352B7B@atlas.denx.de>
Yes. I have find out how to do it.
./install -d ppc_6xx
Thanks,
Johnson Cheng
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, September 16, 2005 7:23 PM
To: JohnsonCheng
Cc: 'linux-ppc-embedded'
Subject: Re: How to use kerberos in ELDK
In message <20050916070358.781D2422AF@denx.de> you wrote:
>
> Maybe I meet the big trouble.
> I find no powerpc-linux-rpm in my build machine, only have
> powerpc-linux-gcc, powerpc-linux-ar .....
> What should I do?
You should really READ the documentation. It says, and I explicitely
quoted this in my previous posting:
> You must use "${CROSS_COMPILE}rpm" instead.
So instead of trying powerpc-linux-rpm which indeed does not exist
you should run ppc_8xx-rpm or whichever other architecture you're
using (alternatively ppc-rpm would work, but this is undocumented and
not recommended).
Please RTFM!
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
"...and the fully armed nuclear warheads, are, of course, merely a
courtesy detail."
^ permalink raw reply
* HELLO
From: colaristide2 @ 2005-09-16 12:29 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hello,
My name is Col(Rtd) Jon Aristide,brother to the
exiled President of Haiti,(Dr.Jean Bertrand
Aristide)
Due to the evolution against the government
of my brother caused by his political opponents in
Haiti,we managed to enter a red cross airplane that
was evacuating foreigners and we are presently on
political assylum in Central African Repubilc(CAR)
I wish to invest in Real Estate and commercial
Properties and equally start a new life in your
country with your assistance and cooperation.If you
are in a good position to help my family,please send
an e-mail to my personal address below indicating your
desire to help meinvest this funds in your country and
beyond.
I urgently await your e-mail letter.
Reply to my confidential mail box: jonaris05@yahoo.com
Best Regards and hope to meet you soon.
God bless,
Col Jon(Rtd).
^ 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