I am currently working on OMAP 3530. I am trying to write a Driver for
Display Sub-System.
This is my requirement:
I have a Codec library which will decode a video file(H.264). Now i
need to display the Video file through the LCD monitor available on
the board.
Do i need to initialize and write driver for all the modules available
in Display Sub-System?
Modules I meant are :
1) Display controller (DISPC) module
2) Remote frame buffer interface (RFBI) module
3) Serial display interface (SDI) complex input/output (I/O) module
with the associated phased-locked
loop (PLL)
4) Display serial interface (DSI) complex I/O module and a DSI
protocol engine
5) DSI PLL controller that drives a DSI PLL and high-speed (HS)
divider
6) NTSC/PAL video encoder .
I am newbie to this Display Subsystem field. Please give your
suggestions for write a minimal driver so that i can display a video
file with the help of LCD available on the board. I am not using
Linux. I am Using a RTOS developed by ourself for the purpose. Hence I
cannot depend on Linux.
Do i need to initialize and write driver for all the modules available
in Display Sub-System?
No, but you should take care, that you know the state of the different
IP-blocks - This might be as easy as resetting the block - Most blocks are
reset/powered down pr default unless you do anything actively to enable them
1) Display controller (DISPC) module
2) Remote frame buffer interface (RFBI) module
3) Serial display interface (SDI) complex input/output (I/O) module
with the associated phased-locked
loop (PLL)
4) Display serial interface (DSI) complex I/O module and a DSI
protocol engine
5) DSI PLL controller that drives a DSI PLL and high-speed (HS)
divider
6) NTSC/PAL video encoder .
Without knowing your requirements for the display driver in details I would
say, that you should mainly focus on 1 (DISP_C). In case you want to connect
it to an intelligent display using the RFBI interface and a Rev C board, you
of cause need support for item 2 as well.
SDI is a serial standard which you don't need to care about for BeagleBoard.
Likewise for DSI (It's a MIPI standard mainly used by cell-phone
manufacturers), which isn't officially supported on OMAP3530 AFAIR, so you
can more or less ignore items 3-5 -...
Item 6 is only relevant in case you want to use the S-video output...
I will however recommend you to spend a day or two going through all of
chapter 15 "Display Interface Subsystem" in the TRM in order to get a
general overview, before heading at writing some code...
Speaking from experience - It's worth the time spend
Søren
"Without knowing your requirements for the display driver in details I
would say, that you should mainly focus on 1 (DISP_C). In case you want to
connect >it to an intelligent display using the RFBI interface and a Rev C
board, you of cause need support for item 2 as well."
This is my requirement.
I need to write a minimal display driver to display a (.bmp or .jpg or .rb
image file) through the lcd panel available on the board. The image will be
in SDRAM. How should I begin?
I will however recommend you to spend a day or two going through all of
chapter 15 "Display Interface Subsystem" in the TRM in order to get a
general >overview, before heading at writing some code...
This is my requirement.
I need to write a minimal display driver to display a (.bmp or .jpg or
.rb image file) through the lcd panel available on the board. The image
will be in SDRAM. How should I begin?
In case it's a "normal" TFT panel configured using I2C or SPI, and only
using the parallel display bus for actual pixel data transfer, you should
mainly consider the DISP_C part of the display sub system.
In case you as well sends commands to the display using the display data
bus, you need support for the RFBI part as well...
I would recommend you to take a look in the u-boot source, which is capable
of putting the splash screen up on Beagle - What you need might be very
similar to this... I unfortunately have never digged into this code myself,
but I think you should easily be able to find it by searching a little for
DISP_C or similar...
It's not a bit deal - From other projects, a couple of 100s-lines I would
assume (depending on error checking, coding style, cleanliness of the code,
etc...)
The RTOS which I use does not support Filesystem. This is how I am planning
to do. Please tell me wheather I am missing anything?
When I switch on the board uboot comes up. Then using the (Load Binary)loadb
of Uboot I load a jpg file to a memory. In the LCD driver along with other
initialization part I will configure this address as the base address of
Graphics Buffer.
Doubt: Is it required to load binary alone. jpg and .bmp formats will have
some header informations right? How is the Display subsystem controller
handling this(different file formats)?
When I switch on the board uboot comes up. Then using the (Load
Binary)loadb
of Uboot I load a jpg file to a memory. In the LCD driver along with
other
initialization part I will configure this address as the base address
of
Graphics Buffer.
Doubt: Is it required to load binary alone. jpg and .bmp formats will
have
some header informations right? How is the Display subsystem controller
handling this(different file formats)?
The short answer to this: DISP_C doesn't know anything with respect to file
formats.
You can only feed a RAW image buffer (with some given pixel formats
specified by the DISP_C) into the DISP_C system.
Not anything like BMP, JPG, etc, which are all more or less encoded formats
with headers, meta data, etc.. You need to do the image processing before
passing it to DISP_C. As such this is a complete other task, than getting
DISP_C up running...
Please go ahead and read chapter 15 and a lot will be much clearer - I hope
Søren
I have succeeded in displaying a bmp image on the lcd panel.
Now I am trying to wite a sound driver to rendere an audio along with
the images. Can you help?
Which is the chapter in trm that I need to go through?
Great news - Keep up the great work.
In order to get Audio working you mainly need to focus on the TRM chapter 21
(McBSP). McBSP2 is connected to TPS65950 (the Power ASIC and Audio Codec).
Information about setting up TPS65950 can be found in:
Here you should mainly focus on chapter 14 (Audio)
The configuration of TPS65950 is done through I2C interface 1 (TRM chapter
18)...
Hi Soren,
Thanks a lot for that.
I shall go through the chapters you mentioned in the manual.
Do we need to configue
TPS65950 module
McBSP2 module
I2S module which helps in the two modules communicate.
My thinking is that i need to configure first two alone. and I2S is already configured?
I am going through the 14.5.3 of TPS65950 trm. Am i looking at the correct location in trm.?
The 14.5.3 says it is for encrypted mp3 files. Mine is already decrypted using a custom codec of TATA elxsi. Will this create any problem?
The address space of these registers seems confusing. It said that physical address is at 0x000000001 to 0x00000050. Is this address offset or correct address? Which is the correct address?
Thanks a lot for that. I shall go through the chapters you mentioned in
the manual.
Do we need to configue
1) TPS65950 module
2) McBSP2 module
3) I2S module which helps in the two modules communicate.
My thinking is that i need to configure first two alone. and I2S is
already configured?
McBSP2 and I2S is the same. You use the McBSP IP-block to create an I2S
compliant data stream - Out of reset neither of the IP blocks are configured
as default...
I am going through the 14.5.3 of TPS65950 trm.
Am i looking at the correct location in trm.?
The 14.5.3 says it is for encrypted mp3 files.
Mine is already decrypted using a custom codec
of TATA elxsi. Will this create any problem?
As for the display DISP_C module, the audio module is dumb as well. It
doesn't know of any file formats (AAC/MP3/Ogg/etc). The module basically
takes raw audio-streams (samples) using I2S and convert it to analog
outputs. I think you need to read the complete chapter 14 in order to get
the overall picture. Just reading the example in chapter 14.5.3 is in my
opinion a bit too optimistic
The address space of these registers seems confusing.
It said that physical address is at 0x000000001 to
0x00000050. Is this address offset or correct address?
Which is the correct address?
The addresses are correct. TPS65950 can be accessed on 4 different I2C
addresses, and the Audio registers are the ones laying in front on I2C
address 0x49. More info on this can be found in chapter 2 of the TPS65950
TRM...
As for the OMAP TRM there is quite a bit of reading in order to get over the
first learning curve - After this everything will work out just fine
Reposting, since I changed the subject line by mistake
Søren
Thanks a lot for that. I shall go through the chapters you mentioned
in the manual.
Do we need to configue
TPS65950 module
McBSP2 module
I2S module which helps in the two modules communicate.
My thinking is that i need to configure first two alone.
and I2S is already configured?
McBSP2 and I2S is the same. You use the McBSP IP-block to create an I2S compliant data stream - Out of reset neither of the IP blocks are configured as default…
I am going through the 14.5.3 of TPS65950 trm.
Am i looking at the correct location in trm.?
The 14.5.3 says it is for encrypted mp3 files.
Mine is already decrypted using a custom codec of TATA elxsi. Will
this create any problem?
As for the display DISP_C module, the audio module is dumb as well. It doesn’t know of any file formats (AAC/MP3/Ogg/etc). The module basically takes raw audio-streams (samples) using I2S and convert it to analog outputs. I think you need to read the complete chapter 14 in order to get the overall picture. Just reading the example in chapter 14.5.3 is in my opinion a bit too optimistic
The address space of these registers seems confusing.
It said that physical address is at 0x000000001 to 0x00000050. Is this
address offset or correct address?
Which is the correct address?
The addresses are correct. TPS65950 can be accessed on 4 different I2C addresses, and the Audio registers are the ones laying in front on I2C address 0x49. More info on this can be found in chapter 2 of the TPS65950 TRM…
As for the OMAP TRM there is quite a bit of reading in order to get over the first learning curve - After this everything will work out just fine
What is the value of Program counter (PC) when powered on?
Where is xloader and uboot lying? In On-Chip ROM or FLASH ?
Can you breif me the execution flow from the point of reset to uboot
Prompt seen in hyper terminal?
Hi Rahanesh,
When the ARM core is released from Reset, the PC is set to address 0, which
is the beginning of the internal ROM-code. The ROM-code will depending on
the SYS_BOOT setting try to do one of several kinds of booting. The
different boot modes are listed in Table 25.3.
In brief, in case of NAND booting it will search the first 4 blocks for the
xloader image and load it into the internal memory. It will then afterward
jump to this loaded image. The xloader will do further initialization of
external memory, clocks, GMPC etc. and then load and jump to u-boot. Then
you are up running
All of this is together with many more details about the chip-booting
procedure itself very well documented in the TRM chapter 25.
Hi Soren,
"the PC is set to address 0, which is the beginning of the internal
ROM-code"
What is the piece of code residing in internal ROM at 0x00000000?. (internal
ROM and ON chip ROM are same, I suppose). Is it just the loading code of
xloader from () to internal memory?
"Assuming it is NAND booting"
From where does it get the xloader image to load it into the internal
memory(Internal SRAM rght?)?
Where is xloader and uboot image in memory (internal ROM or ) ?
What is the piece of code residing in internal ROM at 0x00000000?.
It's the beginning of the ROM code - Stored internally in the chip.
(internal ROM and ON chip ROM are same, I suppose). Is it just the
loading code
of xloader from () to internal memory?
No - The ROM code can do far more than this - It can i.e. do peripheral
booting over UART or USB, booting from MMC, NAND, NOR etc.
"Assuming it is NAND booting"
From where does it get the xloader image to load it into the internal
The ROM-code searches the first 4 NAND blocks to find a valid boot-image
(i.e. the xloader) to load into the internal SRAM memory. After this it
releases control by jumping to the loaded image and makes it run...
Where is xloader and uboot image in memory (internal ROM or ) ?
xloader and uboot are both stored in external NAND flash
Please go ahead and read chapter 25 - It will bring a lot of light on the
topic
Thanks a lot for your advice on configuring audio. As ypu said I went
through the audio codec module and McBSP module.
I have successfully configured all the registers.
After configuration I have rendered the few PCM samples to the McBSP module.
I am now able to hear some music.
In the trm they say that transmit register is connected to audio buffer,
which in turn connected to transmit buffer which finally transmits.
Now what I have tried is that I simply write the pcm samples in the transmit
register(DXR_Reg) on a while loop.
This can cause the buffer to overflow and many samples get overwritten
right? How do I solve this?
Doubt: I have configured the Codec module with a sampling rate of 41000.
My assumption , with the help of sampling rate the codec module reconstruct
an analog signal from the sampling rate and PCM samples.
With what speed is McBSP module transfering data to codec module? This
should be in sync with the codec module rght?
Regards
Rahanesh
The information contained in this electronic message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended
recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy
all copies of this message and any attachments contained in it.
Now what I have tried is that I simply write the pcm samples in the
transmit register(DXR_Reg) on a while loop.
This can cause the buffer to overflow and many samples get overwritten
right? How do I solve this?
With what speed is McBSP module transfering data to codec module? This
should be in sync with the codec module rght?
Long time since I have done any actual code for the McBSP.
I will try to answer your questions best possible
1) Right - I think you can check for overflow by checking:
XOVFLSTAT in register MCBSPLP_IRQSTATUS_REG, but I'm not 100% sure.
2) Right again - AFAIR this is handled automatically by the configuration.
In case you are transferring a 16 bit stereo signal, the McBSP data must be
configuration there might be some extra bits for synchronization - But you
should expect a bit rate in the area of 1.3Mbit/s
Now what I have tried is that I simply write the pcm samples in the
transmit register(DXR_Reg) on a while loop.
This can cause the buffer to overflow and many samples get overwritten
right? How do I solve this?
Between successive writes to Tx register, wait on XRDY bit of
McBSPLP_SPCR2 register .
With what speed is McBSP module transfering data to codec module? This
should be in sync with the codec module rght?
Both T2 codec and McBSP should be configured for same Fs, data formats etc.
