Hello,
Can some one tell me why my board could not boot from Nor Flash or NAND
Flash with UBL and U-boot.
my UBL version is 1.0, and U-boot version is 1.1.3
That is the message from the Serial:
TI UBL Version: 1.00, Flash type: NOR
Booting PSP Boot Loader
PSPBootMode = NOR
Starting NOR Copy...
NOR
Sundar,
my display is 320x240 and the pixel clock is 6.75MHz.
The following original settings work good but they produce 63 Hz vertical
refresh (too high)
HINT = 407
HSTART = 68
HVALID = 320
VINT = 261
VSTART = 18
VVALID = 240
Please, note that these numbers came directly from the display's dat
Gabriele,
I would suggest you to keep the HINT constant and vary the VINT to arive at
the desired frame rate or vice-versa. Changing both at the same time may
distort your image settings on the LCD. Go on effecting one of the variables
by a pre-calculate value as per your equation. And do make sur
When interfacing FPGA to the DM6446 EVM EMIF do I need a bus switch on
CS3 for my device or is this handled already by the CPLD (Altera MaxII)?
Am I right in thinking simply accessing an address in the CS3 space
will automatically assert the CS3 signal?
I plan on only having 8 bits exposed,
David Brownell wrote:
From: David Brownell
Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
be coupled to clock activation.
Why is that? What's special about MMC WRT PinMux enabling?
WBR, Sergei
___
Davinci-linux-open-source m
Instead of trying to adjust the LCD's native FPS down from 60 to some
desired value, why don't you change your usage of the driver?
Currently, if you using the existing display.c sample code, the main
form of frame rate scheduling is through the waitForVsync() call
(function that does a ioctl for
Hi guys,
I'm trying to get PHP5.xx installed onto my montavista davinci. Its
currently running Apache 2.0.x. I have cross compiled many different
programs and have successfully gotten them to compile using the arm tools
arm_v5t_le-gcc, etc. However this PHP is a bit tricky. The configure script
On Tuesday 30 December 2008, Sergei Shtylyov wrote:
> David Brownell wrote:
>
> > From: David Brownell
>
> > Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
> > be coupled to clock activation.
>
> Why is that? What's special about MMC WRT PinMux enabling?
Nothing special ab
Hello.
David Brownell wrote:
From: David Brownell
Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
be coupled to clock activation.
Why is that? What's special about MMC WRT PinMux enabling?
Nothing special about MMC, but decoupling has to start
somewhere. Coupling p
On Tuesday 30 December 2008, Sergei Shtylyov wrote:
> I'm against such decoupling.
Why?
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Hello.
David Brownell wrote:
From: David Brownell
Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
be coupled to clock activation. This is a small cleanup which
doesn't yet support options like not muxing all MMCSD1 pins when
they're not needed (e.g. hard-wired to an SDIO WL
On Tuesday 30 December 2008, Sergei Shtylyov wrote:
> > Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
> > be coupled to clock activation. This is a small cleanup which
> > doesn't yet support options like not muxing all MMCSD1 pins when
> > they're not needed (e.g. hard-wired to
David Brownell wrote:
Move DM355 MMC/SD pinmux to the device setup code; it shouldn't
be coupled to clock activation. This is a small cleanup which
doesn't yet support options like not muxing all MMCSD1 pins when
they're not needed (e.g. hard-wired to an SDIO WLAN adapter).
Such options
On Tuesday 30 December 2008, Sergei Shtylyov wrote:
>
> Not only that: PinMux setup code will also be board specific. It would
> seem good however to have non-specific PinMux setups for all devices in the
> generic files (like devices.c) with the way of overriding them on the board
> level.
What kind of detect times are people seeing when they plug in a usb
flash drive on the dm355? We're seeing that the time it takes from
insertion to creation of the /dev/sdx node is in the realm of ~12
seconds on average. Is there anyway to speed this up?
Thanks,
BJ
I am sorry to truble you but your suggestions are very important to me.
I wrote a fpga_spi.c which is similar with at25xxA_eeprom.c, and i have changed
the spi_board_info.c, when i make a new linux kernel and load it, it does not
register the fpga spi module. what i want to ask is :
if the fpga
16 matches
Mail list logo