Re: Lite5200 PCI not working

Re: Lite5200 PCI not working

[Wolfgang Denk]

In message <1088671264.6226.59.camel@lucy.pep-kaufbeuren.de> Stefan Nickl wrote:
> On Mon, 2004-06-21 at 18:20, Kate Alhola wrote:
> > >Are you really sure? Maybe it was just an issue of finding the  right
> > >jumper  settings (which is non-trivial). We tested both with Rev. 4.0
> > >and Rev. 5.0 cards, and didn't need -12V.
...
> seems I'm also stuck with this non-trivial problem here.
> I have a Rev.5 card, and just discovered the three jumpers
> to override the analog MUX (J250-252).
>
> I get a picture now, but it's *very* dim, and the colors
> seem not quite right when the CRT's brightness is .
>
> Are there any more jumpers to set or could this be an
> issue with the driver (linuxppc_2_4_devel -Dyesterday)?
> Or maybe is the MUXer also a neccessary booster?

I've updated the table to include  the  settings  for  the  Rev.  4.0
board, too, and to list ALL jumpers on the board.

> OK. Please see http://www.denx.de/twiki/bin/view/DULG/CoralPInstallation

Hope this helps.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
America has been discovered before, but it has always been hushed up.
- Oscar Wilde

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Kate Alhola]

>I've updated the table to include  the  settings  for  the  Rev.  4.0
>board, too, and to list ALL jumpers on the board.
>
>
>
>>OK. Please see http://www.denx.de/twiki/bin/view/DULG/CoralPInstallation
>>
>>
>
>Hope this helps.
>
>

I have Rev 3.0 board with analog switch type EL4331. To get it working
even in bypassed mode
it needs PD ( Power down ) input in pin 14 to grounded ( connect example
to pin 10 ).

With this modification my board works.  I am running Embedded QT but it
looks a like that
#define QT_QWS_REVERSE_BYTE_ENDIANNESS in
qt-embedded-free-3.3.2/src/kernel/qgfxraster_qws.cpp was not enough to get
colours right. Needs just more hacking code for fixing endianes problem.



Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Stefan Nickl]

On Thu, 2004-07-01 at 13:36, Kate Alhola wrote:
> >I've updated the table to include  the  settings  for  the  Rev.  4.0
> >board, too, and to list ALL jumpers on the board.
> >
> >
> >
> >>OK. Please see http://www.denx.de/twiki/bin/view/DULG/CoralPInstallation

Great documentation, thanks!

> I have Rev 3.0 board with analog switch type EL4331. To get it working
> even in bypassed mode
> it needs PD ( Power down ) input in pin 14 to grounded ( connect example
> to pin 10 ).

The Rev 5.0 board has J251 "PDN EN" (apparently documented nowhere
except for the DULG) for that purpose. When set, Pin 14 is grounded.

But it didn't help much. I took random shots at the CORALVO[RGB] signals
on the extension connector, and even there, the red and green channels
are only half the amplitude as the blue channel with a typical
grey-on-black linux startup screen. The picture also looks dim-blueish.

I think I'll try the board in a Windows box in the next step ...

> With this modification my board works.  I am running Embedded QT but it
> looks a like that
> #define QT_QWS_REVERSE_BYTE_ENDIANNESS in
> qt-embedded-free-3.3.2/src/kernel/qgfxraster_qws.cpp was not enough to get
> colours right. Needs just more hacking code for fixing endianes problem.

We're running qte 3.1.1 on the Asilient chip (cpu is MPC8245),
and we didn't have to hack Qt for this, hmm ...

--
Stefan Nickl
Project Engineering
Kontron Modular Computers
Sudetenstr. 7
D-87600 Kaufbeuren
Phone ++49/8341/803-294


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Kate Alhola]

Stefan Nickl wrote:

>On Thu, 2004-07-01 at 13:36, Kate Alhola wrote:
>
>
>>>I've updated the table to include  the  settings  for  the  Rev.  4.0
>>>board, too, and to list ALL jumpers on the board.
>>>
>>>
>>>
>>>
>>>
>>>>OK. Please see http://www.denx.de/twiki/bin/view/DULG/CoralPInstallation
>>>>
>>>>
>
>Great documentation, thanks!
>
>
>
>>I have Rev 3.0 board with analog switch type EL4331. To get it working
>>even in bypassed mode
>>it needs PD ( Power down ) input in pin 14 to grounded ( connect example
>>to pin 10 ).
>>
>>
>
>The Rev 5.0 board has J251 "PDN EN" (apparently documented nowhere
>except for the DULG) for that purpose. When set, Pin 14 is grounded.
>
>But it didn't help much. I took random shots at the CORALVO[RGB] signals
>on the extension connector, and even there, the red and green channels
>are only half the amplitude as the blue channel with a typical
>grey-on-black linux startup screen. The picture also looks dim-blueish.
>
>
It is wery strange, symproms are exactly sama than with this analog
switch problem
with 3.0 board........

>I think I'll try the board in a Windows box in the next step ...
>
>
>
You can try it in normal PC Linux box also. So did i when i tested
driver before denx driver.

>>With this modification my board works.  I am running Embedded QT but it
>>looks a like that
>>#define QT_QWS_REVERSE_BYTE_ENDIANNESS in
>>qt-embedded-free-3.3.2/src/kernel/qgfxraster_qws.cpp was not enough to get
>>colours right. Needs just more hacking code for fixing endianes problem.
>>
>>
>
>We're running qte 3.1.1 on the Asilient chip (cpu is MPC8245),
>and we didn't have to hack Qt for this, hmm ...
>
>
There is generic problem in these Fujitsu Display cobntrollers chips
that their
byte ordering (endianism) does not match with powerPC. So when used
in 32 bit pixels the R, G and B bytes does not match normal way used by
linux Frame buffer devices. Most of  chips allow configuration for little or
big endian based on CPU but CoralP does not and this conversion must be
done by software. For this reason we are offering two display controller
solutions, CoralP and Rage Mobility M1.  There is some good things in
COralP and at the moment it is only chip specified for
extended temperature range.



Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Wolfgang Denk]

In message <40E48E1D.4080404@iti.fi> you wrote:
>
> There is generic problem in these Fujitsu Display cobntrollers chips
> that their
> byte ordering (endianism) does not match with powerPC. So when used
> in 32 bit pixels the R, G and B bytes does not match normal way used by
> linux Frame buffer devices. Most of  chips allow configuration for little or
> big endian based on CPU but CoralP does not and this conversion must be
> done by software. For this reason we are offering two display controller

That's  why  we  implemented  drivers  fopr  the  Coral-P  which  are
independedt of the byte-order (and available under GPL).

> solutions, CoralP and Rage Mobility M1.  There is some good things in
> COralP and at the moment it is only chip specified for
> extended temperature range.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Until you walk a mile in another man's moccasins, you  can't  imagine
the smell.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Kate Alhola]

Wolfgang Denk wrote:

>That's  why  we  implemented  drivers  fopr  the  Coral-P  which  are
>independedt of the byte-order (and available under GPL).
>
>
>
Do you meaean that responsibility of byte order is left to application
level ?
Linux fbdev just maps display memory to user application space and so it
cant do anything for how R,G,B bits are ordered within word. It is
then responsibility to GUI-engine ( X-server, Embedded-QT ) to
handle this ordering.

Kate


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Wolfgang Denk]

In message <40E4E804.5010606@iti.fi> you wrote:
>
> Do you meaean that responsibility of byte order is left to application
> level ?

No. The graphic drivers are responsible for it.

> Linux fbdev just maps display memory to user application space and so it
> cant do anything for how R,G,B bits are ordered within word. It is
> then responsibility to GUI-engine ( X-server, Embedded-QT ) to
> handle this ordering.

This is why it is impossible to use a simple  framebuffer  driver  on
the  Coral-P  in  16  bit mode. You can run a framebuffer with 24 bpp
(and actually our first demo dreiver was doing this), but it ain't no
fun.

Also, with  a  framebuffer  driver  you  miss  all  the  options  for
accelerated graphics provided by the Coral-P engine.

This is why we implemented an accelerated X11 driver for the Coral-P.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Today is the yesterday you worried about tomorrow.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Kate Alhola]

Wolfgang Denk wrote:

>In message <40E4E804.5010606@iti.fi> you wrote:
>
>
>>Do you meaean that responsibility of byte order is left to application
>>level ?
>>
>>
>
>No. The graphic drivers are responsible for it.
>
>
It is how you call it. X server or Embedded QT graphics driver normally
works
in user level..

>>Linux fbdev just maps display memory to user application space and so it
>>cant do anything for how R,G,B bits are ordered within word. It is
>>then responsibility to GUI-engine ( X-server, Embedded-QT ) to
>>handle this ordering.
>>
>>
>
>This is why it is impossible to use a simple  framebuffer  driver  on
>the  Coral-P  in  16  bit mode. You can run a framebuffer with 24 bpp
>(and actually our first demo dreiver was doing this), but it ain't no
>fun.
>
>
Yes, this was that i were using and in this one x-server was just
patched to fix byte order.

>Also, with  a  framebuffer  driver  you  miss  all  the  options  for
>accelerated graphics provided by the Coral-P engine.
>
>This is why we implemented an accelerated X11 driver for the Coral-P.
>
>
I should try this new one. With the older one i have some problems with
get all required
virtual console etc drivers to compiled to kernel to make Xfree 4.4
happy. Ok, now
there looks a like to be icecube_5200_CoralP_defconfig

It is just somehow dificult to find all new files appearing to tree ......

May be it is worth to try use QT with X11 server instead using embedded
qt direct to
fb device. In older driver it was anyhow much better to use embedded qt
direrctly.



Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Wolfgang Denk]

In message <40E514DE.6020300@iti.fi> you wrote:
>
> >This is why we implemented an accelerated X11 driver for the Coral-P.
> >
> I should try this new one. With the older one i have some problems with get all required
> virtual console etc drivers to compiled to kernel to make Xfree 4.4 happy. Ok, now
> there looks a like to be icecube_5200_CoralP_defconfig

Yes, this is what we use for testing. It requires  a  USB  mouse  and
keyboard to make the X11 server happy.

> May be it is worth to try use QT with X11 server instead using embedded qt direct to
> fb device. In older driver it was anyhow much better to use embedded qt direrctly.

We have standard versions of Debian  and  YellowDog  running  on  the
LITE5200, so Qt embedded should be pretty straightforward, too.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Make it right before you make it faster.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Lite5200 CoralP issues

[Kate Alhola]

Wolfgang Denk wrote:

>In message <40E514DE.6020300@iti.fi> you wrote:
>
>
>>>This is why we implemented an accelerated X11 driver for the Coral-P.
>>>
>>>
>>>
>>I should try this new one. With the older one i have some problems with get all required
>>virtual console etc drivers to compiled to kernel to make Xfree 4.4 happy. Ok, now
>>there looks a like to be icecube_5200_CoralP_defconfig
>>
>>
>Yes, this is what we use for testing. It requires  a  USB  mouse  and
>keyboard to make the X11 server happy.
>
>
>
I took as test the yours uImage-LITE5200 kernel etc. It booted up
nicelly with newest
CVS snapshot with console text to CoralP display.

But still starting X it says "can not open free VT". As i earlier wrote
on list, there is even hard coded
in Xfree sources that it tries open /dev/tty0 with following strace results

open("/dev/tty0", O_WRONLY)             = 4
ioctl(4, 0x5600, 0x101b6eb0)            = -1 ENOTTY (Inappropriate ioctl
for device)

The problem is that /dev/tty0 looks a like to be hardcoded to
"xf86OpenConsole(void)" in xfree86 lnx_init.c and
it is called unconditionally from xf86Init.c . I have not found any
switch to switch console off from xfree86
config files. Also linkig /dev/tty to /dev/null or /dev/vcs0 etc does
not help, it just replaces
"can not open" error with "Cannot find a free VT".

How you get avoid this one ?

>>May be it is worth to try use QT with X11 server instead using embedded qt direct to
>>fb device. In older driver it was anyhow much better to use embedded qt direrctly.
>>
>>
>
>We have standard versions of Debian  and  YellowDog  running  on  the
>LITE5200, so Qt embedded should be pretty straightforward, too.
>
>
The largest problem is to make minimun set that fits in a Flash memory
with enough functions.
I think that i am still missing something important why i can't get X
running with CoralP drivers.
It needs something and i should find out what is needed. If there is
full yellowdog, then
you have 99.9% extra for most embedded systems.

OK, there is two ways, take YDL and start strip it down untiull it stops
working
or then find out every dependensy that is needed to get minimun system
running.
I think that is better to find out and understand these dependensies.

The Embedded QT runs easier because there is less dependensies to some
strange things
but now with accellerated coralP driver there is reason use X server.

Finally anyhow in embedded systems there should be GUI that works
without any dependensies
to mouse/keyboard

Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 CoralP issues

[Mark Chambers]

Anybody know how much the Coral-P chip itself cost? (approximately)

Mark Chambers

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 CoralP issues

[Wolfgang Denk]

In message <010001c4603b$07d43060$0301a8c0@chuck2> you wrote:
>
> Anybody know how much the Coral-P chip itself cost? (approximately)

Ummm... this obviously depends on the volume. I think for  the 1...5k
range  you  should  be able to get prices < 30 Euro ($ 35). Also feel
free to ask for the  "LIME"  chip  which  essentially  is  a  Coral-P
without the video-in interface at about half the price; see
http://www.fme.fujitsu.com/products/graphics_controllers/MB862xxLime.html

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"There are three principal ways to lose money: wine, women, and engi-
neers. While the first two are more pleasant, the third is by far the
more certain."                           - Baron Rothschild, ca. 1800

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Stefan Nickl]

On Fri, 2004-07-02 at 09:22, Wolfgang Denk wrote:
> > Linux fbdev just maps display memory to user application space and so it
> > cant do anything for how R,G,B bits are ordered within word. It is
> > then responsibility to GUI-engine ( X-server, Embedded-QT ) to
> > handle this ordering.
>
> This is why it is impossible to use a simple  framebuffer  driver  on
> the  Coral-P  in  16  bit mode. You can run a framebuffer with 24 bpp
> (and actually our first demo dreiver was doing this), but it ain't no
> fun.

I now found out why my picture looked so dim...
My trusty old CRT was finally broken. ARG!

Ok, but the picture from the console (penguin, messages ...)
is still very blue-ish; however X is perfectly ok with
the accelerated driver, so with the above said by you,
it this what I have to expect?

I understand that console messages on the VGA are not
important for an embedded system when the apps (can)
work correctly.

I just want to avoid everyone asking me
"why does that screen look so blue?" :)

Btw: "fbset -depth 24" and bootargs+="video=mb86290:1024x768-24@70"
     apparently have no effect at all...


--
Stefan Nickl
Kontron Modular Computers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Lite5200 PCI not working

[Wolfgang Denk]

Dear Stefan,

in message <1089287836.6000.46.camel@lucy.pep-kaufbeuren.de> you wrote:
>
> I now found out why my picture looked so dim...
> My trusty old CRT was finally broken. ARG!

:-(

> Ok, but the picture from the console (penguin, messages ...)
> is still very blue-ish; however X is perfectly ok with
> the accelerated driver, so with the above said by you,
> it this what I have to expect?

No, colors should be fine on the console, too. Are you sure  you  are
using  the  latest  kernel  drivers?  Note that there are both kernel
modifications plus the X11 driver.

> I understand that console messages on the VGA are not
> important for an embedded system when the apps (can)
> work correctly.

They are important in may cases, and they should be OK. At least this
is working fine here.

There is a Linux kernel image on our FTP server which you could  give
a try:

ftp://adm:PASSWORD@www.denx.de/ftp/pub/fujitsu/Coral-P/uImage-LITE5200

> Btw: "fbset -depth 24" and bootargs+="video=mb86290:1024x768-24@70"
>      apparently have no effect at all...

Ummm.. I will check this...

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If A equals success, then the formula is A = X + Y + Z. X is work.  Y
is play. Z is keep your mouth shut.                 - Albert Einstein

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/