I'm still learning about DVI signaling in general, so please forgive
if this is a dumb question. 
In reading the Beagle reference
(http://beagleboard.org/static/BBSRM_latest.pdf ), I can see that
there are 24 pins setup as 'pixel data bits', with no designation as
to what those pins should be used for (RGB-wise). I see what appear
to be standard things (h-sync, v-sync, 3.3/5v signaling, etc.)
In looking at the Sharp LQ043T1DG01 datasheet
(http://datasheet.octopart.com/LQ043T1DG01-Sharp-Microelectronics-datasheet-166381.pdf)
I can see the 24 pixel data pins which ARE marked as Red, Green, or
Blue. Also I see the other signaling pins which are also present on
the Beagle.
Based on this it would seem to me that the LCD interface (J4/J5 on
Beagle) is designed to just connect an LCD like the LQ043T1DG01 to
it...
So, my question. Would it be possible for me to build a connector or
solder up the LQ043T1DG01 to the LCD interface (J4/J5) on the Beagle -
and have Linux use that as a display? Is that the way it's intended
to work, or is there some signaling driver needed? Obviously, the
pins on the Beagle side are not designated for Red, Green, or
Blue....so that seems like a problem. I'd be connecting pins without
'really' knowing what signal is expected there.
Cheers,
These signals are 1.8V. Not 3.5/5V signalling. You will need to have them buffered before you drive a LCD panel and thei voltages shifted.
Refer to -xM version of the schematic for a description of the RGB functionality of the signals.
The J4 and J5 are indeed provided to host an adapter board to allow it to drive various LCD panels. It would be impossible for you to create a connector or solder up wires to drive the Sharp display. You will need to as I said, buffer the signals. You also need to provide the required voltages to drive the display, including the the back light. These voltages are not provided on the connector. You will need to create these from the 5V rail that is provided.
Gerald
Gerald Coley <gerald@beagleboard.org> [2010-09-07 19:02:54]:
The J4 and J5 are indeed provided to host an adapter board to allow it to
drive various LCD panels.
Hi,
I would like to use J4/J5 expansion headers as the only connection to BB for
my LCD expansion board. No J3 usage, so it can be used for example with Zippy
board. There's only i2c3 available on J4/J5 and on the wiki page for expansion
boards[1], there's i2c info for EEPROM connection - i2c2, address 0x50. The
question is, would it be possible to change the autodetection code to probe
also i2c3 bus? I asked already on IRC about it, but didn't get any meaningful
answer :-), rather some advices like "emulate EDID properly", but I can't find
any info, that it's necessary to emulate EDID anywhere.
I don't know EDID that much, but I think, that the format is incompatible with
EEPROM content for BB expansion boards, since the first 8 bytes of EEPROM are
reserved for EDID header "00h FFh FFh FFh FFh FFh FFh 00h".
Thanks for your opinion.
1. http://elinux.org/BeagleBoardPinMux#Hardware_2
-- ynezz
I suppose you could change it, but that is not the standard and I would not support such a change. Why not just read the EDID value as is currently done for the monitors? That code is already there. That was the intent of the original design so as not to create additional software.
Gerald
Gerald Coley <gerald@beagleboard.org> [2010-09-08 09:10:43]:
I suppose you could change it, but that is not the standard and I would not
support such a change. Why not just read the EDID value as is currently done
for the monitors? That code is already there. That was the intent of the
original design so as not to create additional software.
Sorry, but I don't get what do you mean, it's maybe just misunderstanding.
My i2c stuff on the board:
BEAGLE EEPROM 0x50 PWM/GPIO 0x51 TS 0x52
__________ __________ ___________
JP4 ---i2c3--| |---| |---| |
>AT24C01B| |BACKLIGHT| |TOUCHSCREEN|
JP5 ---i2c3--|________|---|_________|---|___________|
Content of the EEPROM will be same as would be on the i2c2. The only change I
want, is change of the u-boot expansion detection code to something like this:
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 8c5b88c..7846951 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -49,7 +49,8 @@ static struct {
#define TWL4030_I2C_BUS 0
-#define EXPANSION_EEPROM_I2C_BUS 1
+#define EXPANSION_EEPROM_I2C_BUS2 1
+#define EXPANSION_EEPROM_I2C_BUS3 2
#define EXPANSION_EEPROM_I2C_ADDRESS 0x50
#define TINCANTOOLS_VENDORID 0x0100
@@ -127,11 +128,14 @@ void beagle_identify(void)
*/
unsigned int get_expansion_id(void)
{
- i2c_set_bus_num(EXPANSION_EEPROM_I2C_BUS);
Petr �tetiar <ynezz@true.cz> [2010-09-09 10:00:41]:
Gerald Coley <gerald@beagleboard.org> [2010-09-08 09:10:43]:
> I suppose you could change it, but that is not the standard and I would not
> support such a change. Why not just read the EDID value as is currently done
> for the monitors? That code is already there. That was the intent of the
> original design so as not to create additional software.
Sorry, but I don't get what do you mean, it's maybe just misunderstanding.
My i2c stuff on the board:
BEAGLE EEPROM 0x50 PWM/GPIO 0x51 TS 0x52
__________ __________ ___________
JP4 ---i2c3--| |---| |---| |
>AT24C01B| |BACKLIGHT| |TOUCHSCREEN|
JP5 ---i2c3--|________|---|_________|---|___________|
Isn't the above with the u-boot change better then this:
BEAGLE PWM/GPIO 0x51 TS 0x52
__________ ___________
JP4 ---i2c3--| |---| |
>BACKLIGHT> >TOUCHSCREEN>
JP5 ---i2c3--|_________|---|___________|
BEAGLE EEPROM 0x50
Petr Štetiar wrote:
Petr Štetiar<ynezz@true.cz> [2010-09-09 10:00:41]:
Gerald Coley<gerald@beagleboard.org> [2010-09-08 09:10:43]:
> I suppose you could change it, but that is not the standard and I would not
> support such a change. Why not just read the EDID value as is currently done
> for the monitors? That code is already there. That was the intent of the
> original design so as not to create additional software.
Sorry, but I don't get what do you mean, it's maybe just misunderstanding.
My i2c stuff on the board:
BEAGLE EEPROM 0x50 PWM/GPIO 0x51 TS 0x52
__________ __________ ___________
JP4 ---i2c3--| |---| |---| |
>AT24C01B| |BACKLIGHT| |TOUCHSCREEN|
JP5 ---i2c3--|________|---|_________|---|___________|
Isn't the above with the u-boot change better then this:
what is being proposed is that you make the *content* of the
AT24C01B be a valid EDID block so that your LCD/TS appears
as a standard DVI monitor that brings his own EDID info.
the I2C address for the EDID block is also 0x50 it seems.
Vladimir Pantelic <vladoman@gmail.com> [2010-09-09 10:31:27]:
Petr �tetiar wrote:
Petr �tetiar<ynezz@true.cz> [2010-09-09 10:00:41]:
Gerald Coley<gerald@beagleboard.org> [2010-09-08 09:10:43]:
> I suppose you could change it, but that is not the standard and I would not
> support such a change. Why not just read the EDID value as is currently done
> for the monitors? That code is already there. That was the intent of the
> original design so as not to create additional software.
Sorry, but I don't get what do you mean, it's maybe just misunderstanding.
My i2c stuff on the board:
BEAGLE EEPROM 0x50 PWM/GPIO 0x51 TS 0x52
__________ __________ ___________
JP4 ---i2c3--| |---| |---| |
>AT24C01B| |BACKLIGHT| |TOUCHSCREEN|
JP5 ---i2c3--|________|---|_________|---|___________|
Isn't the above with the u-boot change better then this:
what is being proposed is that you make the *content* of the
AT24C01B be a valid EDID block so that your LCD/TS appears
as a standard DVI monitor that brings his own EDID info.
the I2C address for the EDID block is also 0x50 it seems.
Ok, this is nice idea, but it's impossible. You use EEPROM with same address
for EDID and for expansion detection. In current scenarion you can have either
EDID or expansion board detection, not both. Or am I mistaken?
-- ynezz
Petr �tetiar <ynezz@true.cz> [2010-09-09 10:59:39]:
Vladimir Pantelic <vladoman@gmail.com> [2010-09-09 10:31:27]:
> Petr �tetiar wrote:
>> Petr �tetiar<ynezz@true.cz> [2010-09-09 10:00:41]:
>>
>>> Gerald Coley<gerald@beagleboard.org> [2010-09-08 09:10:43]:
>>>
>>> > I suppose you could change it, but that is not the standard and I would not
>>> > support such a change. Why not just read the EDID value as is currently done
>>> > for the monitors? That code is already there. That was the intent of the
>>> > original design so as not to create additional software.
>>>
>>> Sorry, but I don't get what do you mean, it's maybe just misunderstanding.
>>> My i2c stuff on the board:
>>>
>>> BEAGLE EEPROM 0x50 PWM/GPIO 0x51 TS 0x52
>>> __________ __________ ___________
>>> JP4 ---i2c3--| |---| |---| |
>>> >AT24C01B| |BACKLIGHT| |TOUCHSCREEN|
>>> JP5 ---i2c3--|________|---|_________|---|___________|
>>
>> Isn't the above with the u-boot change better then this:
>
> what is being proposed is that you make the *content* of the
> AT24C01B be a valid EDID block so that your LCD/TS appears
> as a standard DVI monitor that brings his own EDID info.
>
> the I2C address for the EDID block is also 0x50 it seems.
Ok, this is nice idea, but it's impossible. You use EEPROM with same address
for EDID and for expansion detection. In current scenarion you can have either
EDID or expansion board detection, not both. Or am I mistaken?
Or do you mean, that the expansion detection code should be changed so it can detect
EDID header and read the info about the board from the EDID?
-- ynezz
EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
Koen Kooi <koen@beagleboard.org> [2010-09-09 11:49:59]:
EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
What is screen i2c bus, it's bus #3? Than it means, that it will need 2
EEPROMS, one for EDID on i2c bus #3 and second one for expansion board
detection on bus #2 and use all three J3/J4/J5, right?
-- ynezz
Petr �tetiar <ynezz@true.cz> [2010-09-09 12:22:54]:
Koen Kooi <koen@beagleboard.org> [2010-09-09 11:49:59]:
> EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
What is screen i2c bus, it's bus #3? Than it means, that it will need 2
EEPROMS, one for EDID on i2c bus #3 and second one for expansion board
detection on bus #2 and use all three J3/J4/J5, right?
In case I would go on with usage of J4/J5 only, because I don't see the point
of occupying whole BB just with one expansion board and just for the detection
logic use 2 pins on J3/i2c2, would it be fine with it you, to change the detection
logic to something similar in attached patch? Thanks.
-- ynezz
edid.patch (1.94 KB)
Petr �tetiar <ynezz@true.cz> [2010-09-09 14:34:46]:
Petr �tetiar <ynezz@true.cz> [2010-09-09 12:22:54]:
> Koen Kooi <koen@beagleboard.org> [2010-09-09 11:49:59]:
>
> > EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
>
> What is screen i2c bus, it's bus #3? Than it means, that it will need 2
> EEPROMS, one for EDID on i2c bus #3 and second one for expansion board
> detection on bus #2 and use all three J3/J4/J5, right?
In case I would go on with usage of J4/J5 only, because I don't see the point
of occupying whole BB just with one expansion board and just for the detection
logic use 2 pins on J3/i2c2, would it be fine with it you, to change the detection
logic to something similar in attached patch? Thanks.
I've just realized, that abussing version/revision is really stupid, but it
might work with serial number which is reserved for 32-bit number and abussing
it shouldn't affect EDID parsing.
-- ynezz
Petr �tetiar <ynezz@true.cz> [2010-09-09 14:52:18]:
Petr �tetiar <ynezz@true.cz> [2010-09-09 14:34:46]:
> Petr �tetiar <ynezz@true.cz> [2010-09-09 12:22:54]:
>
> > Koen Kooi <koen@beagleboard.org> [2010-09-09 11:49:59]:
> >
> > > EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
> >
> > What is screen i2c bus, it's bus #3? Than it means, that it will need 2
> > EEPROMS, one for EDID on i2c bus #3 and second one for expansion board
> > detection on bus #2 and use all three J3/J4/J5, right?
>
> In case I would go on with usage of J4/J5 only, because I don't see the point
> of occupying whole BB just with one expansion board and just for the detection
> logic use 2 pins on J3/i2c2, would it be fine with it you, to change the detection
> logic to something similar in attached patch? Thanks.
I've just realized, that abussing version/revision is really stupid, but it
might work with serial number which is reserved for 32-bit number and abussing
it shouldn't affect EDID parsing.
Hm, I wonder, if I wrote something wrong, because the discussion has ended.
It's wrong to discuss my ideas using diffs against u-boot source code? Should I
write it rather in english? Thanks.
-- ynezz
I will not support such a change in the UBoot to read the second EEPROM on J4/J5. There is already an industry standard that supports this interface called EDID. That is all that I will support. That needs to be added unto UBoot if the identification of the display is required in Uboot and it needs to be added into the Kernel as well…
Gerald
Petr Štetiar <ynezz@true.cz> [2010-09-09 14:52:18]:
Petr Štetiar <ynezz@true.cz> [2010-09-09 14:34:46]:
> Petr Štetiar <ynezz@true.cz> [2010-09-09 12:22:54]:
>
> > Koen Kooi <koen@beagleboard.org> [2010-09-09 11:49:59]:
> >
> > > EDID and DDC are on the 'screen' i2c bus, which isn't used for expansion board IDs
> >
> > What is screen i2c bus, it's bus #3? Than it means, that it will need 2
> > EEPROMS, one for EDID on i2c bus #3 and second one for expansion board
> > detection on bus #2 and use all three J3/J4/J5, right?
>
> In case I would go on with usage of J4/J5 only, because I don't see the point
> of occupying whole BB just with one expansion board and just for the detection
> logic use 2 pins on J3/i2c2, would it be fine with it you, to change the detection
> logic to something similar in attached patch? Thanks.
I've just realized, that abussing version/revision is really stupid, but it
might work with serial number which is reserved for 32-bit number and abussing
it shouldn't affect EDID parsing.
Hm, I wonder, if I wrote something wrong, because the discussion has ended.
It's wrong to discuss my ideas using diffs against u-boot source code? Should I
write it rather in english? Thanks.
I appreciated getting the patch to aide in the discussion. I really
didn't pay attention until I saw the patch (which I would consider for
the BeagleBoard validation image u-boot that gets shipped with the
boards). Sorry if I came in late.
Unfortunately, patches on this list come as attachments, so I can't
easily reply in-line.
This said, I don't like the patch. The convention of the expansion
EEPROM is for use of the expansion port. I'd support the use of
additional addresses to support the inclusion of multiple boards
occupying the same expansion connector, but the reading of the EDID
EEPROM should be kept separate and should provide information on using
the LCD expansion header or DVI-D output.
I think it still is not clear why you are trying to do this and put it
on top of the expansion board EEPROM handling routines.
I've used the experience of answering the RISC OS question on this
list[1] and the validation instructions[2] to try to improve my
knowledge enough to be able to put EDID-D parsing into u-boot.
Obviously I'm doing that at a bit of a low priority.
[1] http://groups.google.com/group/beagleboard/browse_thread/thread/6a77c62f1b855aaa/35e91a747f0763eb?#35e91a747f0763eb
[2] http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext#i2c
Jason Kridner <jkridner@beagleboard.org> [2010-09-13 12:00:44]:
This said, I don't like the patch. The convention of the expansion
EEPROM is for use of the expansion port. I'd support the use of
additional addresses to support the inclusion of multiple boards
occupying the same expansion connector, but the reading of the EDID
EEPROM should be kept separate and should provide information on using
the LCD expansion header or DVI-D output.
Thanks a lot for your input, and I see your point. Just don't mix it together,
use EEPROM on i2c2 to identify the boards utilizing expansion connector and
use EDID to identify LCD expansion boards which want to use JP4/JP5 connectors
only, with EEPROM on i2c3 only. We can identify the board using EDID without
any hassle, because there's vendor/product ID which we can use for such
purpose, right?
I think it still is not clear why you are trying to do this and put it
on top of the expansion board EEPROM handling routines.
It was just the first mockup, nothing serious, just an idea.
-- ynezz
Jason Kridner <jkridner@beagleboard.org> [2010-09-13 12:00:44]:
This said, I don't like the patch. The convention of the expansion
EEPROM is for use of the expansion port. I'd support the use of
additional addresses to support the inclusion of multiple boards
occupying the same expansion connector, but the reading of the EDID
EEPROM should be kept separate and should provide information on using
the LCD expansion header or DVI-D output.
Thanks a lot for your input, and I see your point. Just don't mix it together,
use EEPROM on i2c2 to identify the boards utilizing expansion connector and
use EDID to identify LCD expansion boards which want to use JP4/JP5 connectors
only, with EEPROM on i2c3 only. We can identify the board using EDID without
any hassle, because there's vendor/product ID which we can use for such
purpose, right?
That's exactly my viewpoint, yes.
Jason Kridner <jkridner@beagleboard.org> [2010-09-13 15:44:00]:
> Thanks a lot for your input, and I see your point. Just don't mix it together,
> use EEPROM on i2c2 to identify the boards utilizing expansion connector and
> use EDID to identify LCD expansion boards which want to use JP4/JP5 connectors
> only, with EEPROM on i2c3 only. We can identify the board using EDID without
> any hassle, because there's vendor/product ID which we can use for such
> purpose, right?
That's exactly my viewpoint, yes.
Ok, cool. I hope, that I can provide some patches for the discussion by the end
of this week.
-- ynezz