MPC8272ADS and frame buffer
Hello Federico,
It turns out you can solve your problem by using the Epson SD13806
evaluation board (s5u13806b00c). It comes with drivers distributed, inanely enough, as a patch for a specific kernel, so prepare for some hand-patching. Other than that, it works.
Love answering myself :) -Federico
Quoted 15 lines
Hello Linux-PPCers,
I have a quick one: I am looking at the Arabella kernel on the
MPC8272ADS, which I am planning to use as a prototyping platform while we get to figure out a BSP for our custom board.Now, I have an Epson card on hand (13806) which I know to be working
on ppc, and which has drivers as a kernel patch for 2.4.21, and I have a radeon card on hand which I used to like because of its vesa 2.0 compliance. The first brings up the problem of porting the patch to the 2.4.26 kernel, which Arabella/Yuli Barcohen customized to the MPC8272ADS. The latter, according to Yuli himself, won't work because of BIOS initialization issues.I do not mind buying another card if necessary (time is at a greater
premium), but I would like to know that there is a 2.4.6 driver for it or that it is supported by Arabella's kernel.Anyone here using the Arabella BSP on the 8272ADS with a frame buffer on it ? What setup are you using?
-Federico
Signature · 5 lines
_________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish Muad'Dib of Caladan (Federico L. Lucifredi)- Harvard University & BU http://metcs.bu.edu/~lucifred
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Bora Þahin
But S1D13806 is showed in the web site as legacy. Instead of it S1D13506 is suggested, which seems it has the same properties with 13806... Do you know anything about it?
hehe - I know, it is an oldie now. I used it because my company had one around, and it was a cheap approach to try what we had on hand first =)
A good thing for you is that the Linux driver is one for most of the Epson chips (download the file, you will see this sd1d1xxxfb.c (or something like it) file, it depends on different includes for different chips, but other than that it is always the same driver.
Quoted 4 lines
Has it got X-Window driver[s] or only frame-buffer support? If only framebuffer, then it means frame buffer X-window server. And this one is a bit slow AFAIK...
The driver is fb only - I agree with you, if you are going to use X, you dont want to go with that. On the other hand, unlsee you want a lot of applications on the desk, ditching X would help you in maximizing CPU usage as you request below. Qt-E by Trolltech (Disclaimer: I am a fanatical Qt user) supports Fb graphics, so if you do not need anything besides a browser (Opera can also use Qt-E, and Konqueror can also link agains it, although I would not recommend that one yet), you can well do without X.
Quoted 6 lines
FL> I believe the card is enough for browser operation, yes. I am not sure
FL> about playing video beacuse I have not performance-checked it , and as FL> you pointed out, it is unaccelerated. It should be able to display FL> whatever you throw at it though, so if you can do the MPEG decoding FL> completely in software on the MPC side, you should be fine.Thanks for these invaluable insights...
My pleasure to be of help =)
Quoted 11 lines
FL> Do you work at Turk Telecom or are you just a customer ?
Yeah, I am just a customer. I dont like using company e-mail. Because it is read by third party products :-)
If possible, we want to decrease microprocessor clock. Normally we
do it in VIA Epia-500MHz and thinking in parallel with, it should be done under 533, or perhaps [..] 466, 400. I dont know. We will test it. Do you know anything about it?
Hmm - testing is the only way you can come up with a figure. But removing X from the equation will certinly gain you some % of CPU availability, which you will need for the soft mpeg decoder. You also want to test that the buffer setup of the whole thing is designed correctly for the kind of response and thruput you will need... I have seen reports on the mailing list of people having trouble b/c of some crippleware used in bus implementations.
-Federico
Signature · 5 lines
_________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish Muad'Dib of Caladan (Federico L. Lucifredi)- Harvard University & BU http://metcs.bu.edu/~lucifred
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Bora Þahin
Hello Federico,
Thanks for the infos...
FL> You also FL> want to test that the buffer setup of the whole thing is designed FL> correctly for the kind of response and thruput you will need... I have FL> seen reports on the mailing list of people having trouble b/c of some FL> crippleware used in bus implementations.
I dont understand it exactly. May you able to explain it a bit clearly?
Thanks for the infos...
I meant that you have to stress-test the bus connection that you are going to use to whatever graphic hardware you
select - you cannot count on embedded hardware being bleeding-edge performance, and you are going to play 25 or 30 frames a second over that bus -- it is a lot of data, and you have bandwidth (hopefully not a problem with pci) and jitter (delay variance) constraints.
-Federico
Signature · 5 lines
_________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish Muad'Dib of Caladan (Federico L. Lucifredi)- Harvard University & BU http://metcs.bu.edu/~lucifred
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Bora Þahin
Hi Federico,
FL> I meant that you have to stress-test the bus connection that you are
FL> going to use to whatever graphic hardware you
FL> select - you cannot count on embedded hardware being bleeding-edge FL> performance, and you are going to play 25 or 30 frames a second over FL> that bus -- it is a lot of data, and you have bandwidth (hopefully not a FL> problem with pci) and jitter (delay variance) constraints.Sory for the late answer...
Quoted 11 lines
I see you. In fact I know it but some blurry situations is matter. We use IBM-PPC. It has CoreConnect bus. I dont know implementation details of it but it has three different buses. One is PLB. This is for speedy ones. PCI bridge is in this bus also. AFAIK, data and addres bus of it is decoupled. Clock speed is also high. I think it also support burst mode. So in the light of these infos it seems enough. So PCI is enough, this one sholud be enough also.
But as you said, we should take into consideration that these cpus and buses are embedded and at some points, may have clipped version of desktop brothers.
Exactly. And even when the cpu is not clipped, the board might be (I am handling right now a fully complete Motorola MPC8272 based design, the chip supports PCI burst, the board design, however, does not).
-Federico
Signature · 5 lines
_________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish Muad'Dib of Caladan (Federico L. Lucifredi)- Harvard University & BU http://metcs.bu.edu/~lucifred