Dear Francois,
in message you wrote:
>
> I have been playing with the CoralP, Icecube and Debian.
> Works fine, thanks to the tutorial on the Denx site.
> I now would like to see the microwindows stuff working. I
This will not work. Microwindows can only use a plain framebuffer
interface, b
Andrei Konovalov wrote:
> As this code is not board specific at all,
> I would move it to arch/ppc/syslib/xilinx_pic.c:ppc4xx_pic_init().
> Does it sound reasonable (I'll prepare the patch this weekend then)?
This sounds useful, since I am using a custom developed board using the
Virtex-II Pro.
Peter Asemann wrote:
> Some days ago I was told on this mailinglist I needed to create a custom
> configuration in order to get linux running on my custom hardware.
>
> So I did as I was told and created an own _defconfig and entries
> in the menu via editing arch/ppc/config.in and so on.
>
> W
Thanks. Tweaking a little the source code and I now get the
right colours. The funny thing is that byte swapping was:
0x1234567 => 0x34126745. I initially thought I could just
swap the two least significant bytes as I am pretty sure I
am using a 16-bit mode (fbset reports that anyway). Now I'd
like
Some days ago I was told on this mailinglist I needed to create a custom
configuration in order to get linux running on my custom hardware.
So I did as I was told and created an own _defconfig and entries
in the menu via editing arch/ppc/config.in and so on.
Well, every board seems to include i
>
> This will not work. Microwindows can only use a plain framebuffer
> interface, but the Coral-P does not allow for such a driver because
> of the fact that it has a little-endian register interface.
Or is it because 5200 swaps bytes around on PCI. It sure looks to me
like Freescale ha
Hi all,
I have been playing with the CoralP, Icecube and Debian.
Works fine, thanks to the tutorial on the Denx site.
I now would like to see the microwindows stuff working. I
have been trying the demos from the ELDK but I get strange
colors, it seems my palette is all wrong. The same happens
when
I had the same problem with the i2c-algo-8260.c when loading a module.
It's the __pa() translation. Replace _ALL_ __pa with iopa. It worked for
me. I discovered it from this link:
http://ozlabs.org/pipermail/linuxppc-dev/2002-February/013260.html
linuxppc-embedded-request at ozlabs.org wrote:
>
>I have been playing with the CoralP, Icecube and Debian.
>Works fine, thanks to the tutorial on the Denx site.
>I now would like to see the microwindows stuff working. I
>have been trying the demos from the ELDK but I get strange
>colors, it seems my palette is all wrong. The same happens
>when I
this one fixes the OCP device definition for STB04.
Please consider applying.
Signed-off-by: Andre' Draszik
diff -urN linuxppc-2.5.orig/arch/ppc/platforms/4xx/ibmstb4.c
linuxppc-2.5/arch/ppc/platforms/4xx/ibmstb4.c
--- linuxppc-2.5.orig/arch/ppc/platforms/4xx/ibmstb4.c 2005-02-06
00:16:33.000
This one fixes mktree. The image size stored in the header is pretty off without
this patch. (yes, it can make a difference of upto almost 64k)
Signed-off-by: Andre' Draszik
diff -urN linuxppc-2.5.orig/arch/ppc/boot/utils/mktree.c
linuxppc-2.5/arch/ppc/boot/utils/mktree.c
--- linuxppc-2.5.orig/
Hi,
this is a rewrite of the ibm4xx ocp ide driver. In its current state it
doesn't compile with current 2.6 and is completely broken in many other
aspects anyway.
Please consider applying (or tell me how the patch should be changed to
qualify for applying :)
Signed-off-by: Andre' Draszik
diff
12 matches
Mail list logo
