On Fri, Oct 11, 2002 at 12:37:20PM -0700, Andrew May wrote:
Sorry about the late reply but I wanted to check the 2.5 tree and I haven't
been looking at it before.
On Wed, Oct 09, 2002 at 11:58:28AM +1000, David Gibson wrote:
On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
I'm trying to interface a 405GP chip with an EPSON S1D13506 graphic
controller. Because the EPSON chip is a little endian, I need to have my
framebuffer memory acceded in little endian mode.
What is the best way to change endian attribute for a specific memory
region (ioremap little endian)?
Stefan,
why don't you use the MD4 signal of the Epson Chip to configure it as big
endian device? Or am I missing something here?
Best regards,
Stefan.
First of all it is not my implementation problem :))
You are right you can use this signal, but in my implementation for 13704
it was
Hello All,
I am using the SELF package from Denx (Linux version 2.4.4 kernel
combined with a ramdisk). I have modified the bd_info struct to be
the same as ppcboot's. Also, I have the mpcbdm adaptor and am
starting it with an mpc_init file tailored for a TQM board even
though I have an MBX860
On Thu, Oct 10, 2002 at 05:22:28PM +0200, Anders Blomdell wrote:
I'm still unsuccessful with running linux on my prpmc800 card (and my 2600
card as well)
1. The 2600 does its thing up to the
Uncompressing Linux...done.
Now booting the kernel
point, then it changes the console
Hi, everybody. (I'm not trying to start a flamewar here, really.)
I couldn't help but notice the recent discussion/flamewar about the
bitkeeper license changes over on LKML. These changes, as I
understand them, impact anybody who develops or distributes
software deemed to compete with
If you're unclear on the bitkeeper license I'd suggest you ask Larry. I'm
sure he'd be happy to answer any questions on the license and how it
affects your situation.
} the past, and odds are, will again in the future, I thknk
} maybe this means I can't use bitkeeper anymore (well, not for
On Mon, 14 Oct 2002, Cameron, Steve wrote:
So, I was wondering if there are any plans to say, mirror
the development linux powerpc bitkeeper tree as a tar.bz2
on a more regular basis, like the regular linux kernel
development team does? Or perhaps someone is already
doing that, and I just
We are trying to wade our way through the various processor choices and
options available for PPC on Linux.
One of our requirements is to be able to run the same binary image across
a range of systems. The image can not change just because the processor
does.
We are currently looking at the
In message Pine.LNX.4.33.0210141138290.24959-10 at localhost.localdomain
you wrote:
We are trying to wade our way through the various processor choices and
options available for PPC on Linux.
One of our requirements is to be able to run the same binary image across
a range of systems.
Bret Indrelee wrote:
We are trying to wade our way through the various processor choices and
options available for PPC on Linux.
One of our requirements is to be able to run the same binary image across
a range of systems. The image can not change just because the processor
does.
We are
On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
Bret Indrelee wrote:
We are trying to wade our way through the various processor choices and
options available for PPC on Linux.
One of our requirements is to be able to run the same binary image across
a range of systems.
On Mon, 14 Oct 2002, Wolfgang Denk wrote:
In message Pine.LNX.4.33.0210141138290.24959-10 at
localhost.localdomain you wrote:
We are trying to wade our way through the various processor choices and
options available for PPC on Linux.
One of our requirements is to be able to run the
In message Pine.LNX.4.33.0210141315200.24959-10 at localhost.localdomain
you wrote:
One of our requirements is to be able to run the same binary image across
a range of systems. The image can not change just because the processor
does.
We are currently looking at the 405GPX,
On Monday, October 14, 2002, at 01:15 PM, Matt Porter wrote:
On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
Bret Indrelee wrote:
We are trying to wade our way through the various processor choices
and
options available for PPC on Linux.
One of our requirements is to be
I'd have to agree with that. Classic PPC core implementations currently
offer the broadest selection of userspace binary compatible processors.
I agree, but it depends on how important floating point is to ones
userspace. If they do not care about FP then all of the PPC processors
Wolfgang Denk wrote:
In message 3DAB2923.3060607 at mvista.com Mark Hatle wrote:
IMHO it is a bad practice to mix and match userspace between 403/8xx, 405, and
7xx/74xx/82xx series of processors. It is just asking for problems.. but it
definatly can be done given proper resources and
On Mon, 13 Oct 2002, Kumar Gala wrote:
On Monday, October 14, 2002, at 01:15 PM, Matt Porter wrote:
On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
Bret Indrelee wrote:
[ Looking to have compatible System and User binary image ]
We are currently looking at the 405GPX, 8250,
On Mon, Oct 14, 2002 at 04:37:49PM -0500, Bret Indrelee wrote:
Float isn't important to us, we could have all float be emulated for as
little of it we do.
We need the bzImage.gz and RAM disk image have to be the same binary.
The reason is simple, we don't want the customer to have the mess
You have unreasonable expectations. The PowerPC architecture does not
aspire to maintain total code compatibility at all levels. It specifically
disclaims any aspirations of achieving full code compatibility.
Reference: PowerPC Microprocessor Family: The Programming Environments
Section 1.1.2
20 matches
Mail list logo
