Hi,
The partition table information for the two NAND chips (each of 1GB,
Blocksize 256KB) listed by kernel is as follows:
Kernel Bootlog:
=
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V
8-bit)
2 NAND chips detected
Creating 5 MTD partitions on
Hi Karicheri,
2010/6/16 Karicheri, Muralidharan m-kariche...@ti.com
Hi,
A snapshot of the work can be previewed at
http://git.linuxtv.org/mkaricheri/vpfe-vpbe-video.git?a=shortlog;h=refs/heads/devel_2_6_35rc2
It is based on sub device interface. Currently we have ported the v4l2
Krunal Patil wrote:
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB
3,3V 8-bit) 2 NAND chips detected
Creating 5 MTD partitions on nand_davinci.0:
0x-0x0078 : bootloader
0x0078-0x0080 : params
0x0080-0x00c0 : kernel
0x00c0-0x20c0 :
Hi,
I'm in the process of adapting the davinci kernel for a custom board
based on the OMAP-L138 (da850).
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common initialisation). I think the
PINMUX configuration is definitely a board
On Thursday 17 June 2010 11:43:27 am Christophe Aeschlimann wrote:
Hi,
I'm in the process of adapting the davinci kernel for a custom board
based on the OMAP-L138 (da850).
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common
Le 17.06.2010 10:53, Caglar Akyuz a écrit :
On Thursday 17 June 2010 11:43:27 am Christophe Aeschlimann wrote:
Hi,
I'm in the process of adapting the davinci kernel for a custom board
based on the OMAP-L138 (da850).
I was surprised to see that the PINMUX registers configuration (in
Hello.
Christophe Aeschlimann wrote:
I'm in the process of adapting the davinci kernel for a custom board
based on the OMAP-L138 (da850).
Are you planning to submit your work here?
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of
On Thursday 17 June 2010 11:22:29 Christophe Aeschlimann wrote:
Actually it is not SoC specific. Possible pinmux configurations are
defined in SoC specific files, then they are adjusted in board specific
files using 'davinci_cfg_reg' which is defined in mach/mux.h.
Indeed. Thanks for the
Le 17.06.2010 11:36, Sergei Shtylyov a écrit :
Hello.
Christophe Aeschlimann wrote:
I'm in the process of adapting the davinci kernel for a custom board
based on the OMAP-L138 (da850).
Are you planning to submit your work here?
If I do anything that could be useful for the community I
On Mon, Jun 14, 2010 at 1:15 PM, Brian Niebuhr bnieb...@efjohnson.com wrote:
Can you please post this series to SPI development list
(spi-devel-gene...@lists.sourceforge.net) CCing the maintainers
David Brownell and Grant Likely?
Done
I had to go looking for these patches. I see that you
Hi Siles,
I am working on DM365 with dvsdk 3.10.00.16 and 2.6.32-rc2.
When I trying to run the encode demo, I met the same problem with you:
@25,694,740us: [+0 T:0x4001fce0] CE - Engine_open Enter('encode', 0x0,
0xbec58a6c)
@25,694,995us: [+0 T:0x4001fce0] OM - Memory_alloc Enter(0x2c)
Krunal,
You might try this:
1) Use hexdump to view the first bit of the bootloader and note the data
values.
2) Load a filesystem into filesystem2.
3) Use hexdump to view the first bit of the bootloader and note the changes.
4) hexdump filesystem2 and search for the pattern. ( you might dump
Christophe Aeschlimann wrote:
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common initialisation).
Frankly speaking, I don't see where the pin lists are a part of common
initialization. Unless you mean da850_pins[] -- that is SoC
Le 17.06.2010 16:12, Sergei Shtylyov a écrit :
Christophe Aeschlimann wrote:
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common initialisation).
Frankly speaking, I don't see where the pin lists are a part of common
initialization.
- The description of alternative PINMUX configuration takes place in
da850_pins[] in da850.c
- Group of pins that describe a new feature can be defined in the
board-specific file (so they can be enabled in one call)
New features should be defined in the SoC file, because your board
might
Le 17.06.2010 17:02, jean-philippe francois a écrit :
- The description of alternative PINMUX configuration takes place in
da850_pins[] in da850.c
- Group of pins that describe a new feature can be defined in the
board-specific file (so they can be enabled in one call)
New features should
Hi Sergei,
On Thu, Jun 17, 2010 at 19:42:11, Sergei Shtylyov wrote:
Christophe Aeschlimann wrote:
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common initialisation).
Frankly speaking, I don't see where the pin lists are a part of
Hello,
Is there anyone else that tried to modify platform data (board-da850-evm.c)
to add USB1.1 and USB2.0 support for OMAP-L138?
Thanks
Nicolas
On Wed, Jun 9, 2010 at 8:58 AM, Nori, Sekhar nsek...@ti.com wrote:
Hi Nicolas,
On Tue, Jun 08, 2010 at 21:22:55, Nicolas Luna wrote:
Sergei,
Raffaele,
You got the readme.txt right!
Arago tree has the latest video drivers for DM365. But this is a temporary
staging tree that has all of the video
drivers up ported from the MV kernel. Some of these drivers (vpfe capture on
DM6446, DM355, DM365
and vpif capture and display on DM646x)
Steve Poulsen wrote:
1) Use hexdump to view the first bit of the bootloader and note the
data values. 2) Load a filesystem into filesystem2.
3) Use hexdump to view the first bit of the bootloader and note the
changes. 4) hexdump filesystem2 and search for the pattern. ( you
might dump it to
Caglar Akyuz wrote:
On Thursday 17 June 2010 11:43:27 am Christophe Aeschlimann wrote:
I was surprised to see that the PINMUX registers configuration (in
da850.c) is SOC dependant (part of common initialisation). I think
the PINMUX configuration is definitely a board specific setting.
Nicolas,
You could refer to the OMAPL kernel tree in the Arago git page. That tree
supports both L137 an L138 platforms including usb.
regards
swami
From: davinci-linux-open-source-boun...@linux.davincidsp.com
In answer to the question in $SUBJECT:
the whole pinmux configuration, yes. But
Quite a lot of it can also be derived from
driver configuration. (Which is board-coupled.)
So (a partly made up example) if a given SPI
bus is configured, with two chipselect lines
active ... that rules out PINMUX
Thanks for the valuable suggestions guys. Appreciate all your inputs. I
will be trying this today.
--
Regards,
Krunal
On 06/18/2010 03:20 AM, Jon Povey wrote:
Steve Poulsen wrote:
1) Use hexdump to view the first bit of the bootloader and note the
data values. 2) Load a filesystem into
Hi Muralidharan,
2010/6/17 Karicheri, Muralidharan m-kariche...@ti.com
Raffaele,
You got the readme.txt right!
:)
I'm reading it.
Arago tree has the latest video drivers for DM365. But this is a temporary
staging tree that has all of the video
drivers up ported from the MV kernel.
25 matches
Mail list logo
