I use DM6446 and i implemented my own codec and i success to compile(the CGT
is version 6.1.12) and run it.
but when i edit the "usr.bld" file by adding this options "-z -l forder.cmd" to
the compiler options, it fail with the below error.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
# generating interfaces for package codecs.decode_slice_h264 (because
package/package.xdc.xml is older than package.xdc) ...
/opt/xdc_3_05/xs
-Dxdc.path="/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../.."
-Dxdc.root=/opt/xdc_3_05 -Dxdc.hostOS=Linux
-Dconfig.importPath=".;/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../..;/opt/xdc_3_05;/opt/xdc_3_05/etc"
-Dxdc.bld.targets="" -DTOOLS= -f xdc/services/intern/cmd/build.xs -m
package/package.xdc.dep -i package/package.xdc.inc package.xdc
translating DECODE_SLICE_H264
.interfaces files complete: Tue Apr 27 14:04:08 EET 2010.
======== .libraries
[/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264]
========
rm -f
package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P
#
# cl64P package/package_codecs.decode_slice_h264.c ...
/opt/TI/C6000CGT6.1.13/bin/cl6x -c -mt -mo --opt_for_speed=5 -O3
--program_level_compile --silicon_version=6446 --keep_asm --opt_for_speed=5 -z
-l forder.cmd -mv64p -eo.o64P -ea.s64P -D__xdc_bld_pkg_c__=package.bld.c
-Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h
-Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_1_13 -o2 -I.
-I/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..
-I/opt/codec_engine_2_10/cetools/packages -I/opt/codec_engine_2_10/packages
-I/opt/bios_5_32_02/packages -I/opt/xdc_3_05/packages -I../..
-I/opt/TI/C6000CGT6.1.13/include
-fs=./package/lib/lib/decode_slice_h264/package
-fr=./package/lib/lib/decode_slice_h264/package -fc
package/package_codecs.decode_slice_h264.c
>> WARNING: invalid linker option -D__xdc_bld_pkg_c__=package.bld.c (ignored)
>> WARNING: invalid linker option -Dxdc_target_name__=C64P (ignored)
>> WARNING: invalid linker option -Dxdc_target_types__=ti/targets/std.h
>> (ignored)
>> WARNING: invalid linker option -Dxdc_bld__profile_release (ignored)
>> WARNING: invalid linker option -Dxdc_bld__vers_1_0_6_1_13 (ignored)
ERROR: argument to option -f ("value") is out of range
gmake[1]: ***
[package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P]
Error 1
gmake: ***
[/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264,.libraries]
Error 2
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs'
make: *** [all] Error 2
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Any help is highly appreciated
Mohamed AbdElwahed Ibrahim
> From: [email protected]
> Subject: Davinci-linux-open-source Digest, Vol 52, Issue 65
> To: [email protected]
> Date: Wed, 21 Apr 2010 07:11:32 -0500
>
> Send Davinci-linux-open-source mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Davinci-linux-open-source digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH 4/4] DM365: Add platform resource management
> (Kevin Hilman)
> 2. Re: [PATCH 2/4] DM365: Allow use of GPIO64_57 (Kevin Hilman)
> 3. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
> 4. RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available (Koeller, T.)
> 5. RE: [PATCH 4/4] DM365: Add platform resource management
> (Nori, Sekhar)
> 6. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Apr 2010 15:20:37 -0700
> From: Kevin Hilman <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [PATCH 4/4] DM365: Add platform resource management
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> [email protected] writes:
>
> > From: Thomas Koeller <[email protected]>
> >
> > Keeping track of resource assignments greatly simplifies
> > the task of writing board support code. Many drivers for
> > DaVinci peripherals were using resources that had never
> > been allocated, with the notable exception of memory
> > resources.
> >
> > Non-conflicting resource assignment is a responsibility
> > of the bus the devices are on, in this case, the platform bus.
> >
> > The resource management scheme implemented by this patch is not
> > perfect. The SoC code really has no business managing resources,
> > it should only provide them to the platform (board support) code.
> > The board support is the only place where information about the
> > intended use of the various hardware resources is available.
>
> Actually, the driver is the place where the resources are used and
> therefore where they should be reserved and released. This patch
> removes this from the drivers and puts it in SoC code which I don't
> like.
>
> There are really two main things going on here that I see:
>
> 1. add parent resources (cfg, irq, dma, etc.)
> 2. move resource reservation from drivers to SoC code
>
> It's primarily 2 that I object to.
>
> While I think (1) may be helpful, if we're going to do it, we should
> do it throughout all of mach-davinci/*.
>
> Kevin
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 20 Apr 2010 15:21:05 -0700
> From: Kevin Hilman <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [PATCH 2/4] DM365: Allow use of GPIO64_57
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> [email protected] writes:
>
> > From: Thomas Koeller <[email protected]>
> >
> > Extended the MUX configuration to allow use of GPIO
> > terminals 64..57.
> >
> > Signed-off-by: Thomas Koeller <[email protected]>
>
> Thanks, applying and queuing for 2.6.35 in davinci-next branch.
>
> Kevin
>
> > ---
> > arch/arm/mach-davinci/dm365.c | 1 +
> > arch/arm/mach-davinci/include/mach/mux.h | 1 +
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> > index 023d708..0813dce 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -580,6 +580,7 @@ MUX_CFG(DM365, SPI4_SDENA1, 4, 16, 3, 2, false)
> > MUX_CFG(DM365, GPIO20, 3, 21, 3, 0, false)
> > MUX_CFG(DM365, GPIO33, 4, 12, 3, 0, false)
> > MUX_CFG(DM365, GPIO40, 4, 26, 3, 0, false)
> > +MUX_CFG(DM365, GPIO64_57, 2, 6, 1, 0, false)
> >
> > MUX_CFG(DM365, VOUT_FIELD, 1, 18, 3, 1, false)
> > MUX_CFG(DM365, VOUT_FIELD_G81, 1, 18, 3, 0, false)
> > diff --git a/arch/arm/mach-davinci/include/mach/mux.h
> > b/arch/arm/mach-davinci/include/mach/mux.h
> > index 05e35fa..d6c6921 100644
> > --- a/arch/arm/mach-davinci/include/mach/mux.h
> > +++ b/arch/arm/mach-davinci/include/mach/mux.h
> > @@ -295,6 +295,7 @@ enum davinci_dm365_index {
> > DM365_GPIO20,
> > DM365_GPIO33,
> > DM365_GPIO40,
> > + DM365_GPIO64_57,
> >
> > /* Video */
> > DM365_VOUT_FIELD,
> > --
> > 1.7.0.3
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > [email protected]
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Apr 2010 10:13:55 +0200
> From: "Koeller, T." <[email protected]>
> To: "Kevin Hilman" <[email protected]>
> Cc: [email protected]
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Kevin,
>
> >
> > Actually, the driver is the place where the resources are used and
> > therefore where they should be reserved and released. This patch
> > removes this from the drivers and puts it in SoC code which I don't
> > like.
> >
> > There are really two main things going on here that I see:
> >
> > 1. add parent resources (cfg, irq, dma, etc.)
> > 2. move resource reservation from drivers to SoC code
> >
> > It's primarily 2 that I object to.
> >
> > While I think (1) may be helpful, if we're going to do it, we should
> > do it throughout all of mach-davinci/*.
>
> Here I do not quite agree with your view. In general, resource managment
> is about avoiding conflicts. This means that it must be done in a
> place where the resource requirements of all devices are known, and this
> is the bus, not the individual drivers. This is more obvious when
> dealing with buses that enumerate their devices and collect their
> resource requirements in order to make intelligent decisions. The
> platform bus has been invented to extend this concept to devices that
> are not really on such a bus.
>
> For platform devices, resources are set up by the platform and passed to
> the drivers via platform devices. At this point, the decision about which
> resource is going to be used by a particular driver has already been made,
> and nothing is gained by defering the actual allocation. Resource
> allocation in the driver is only possible for resources for which
> global root nodes exist (IO and MEMORY addresses). All other kinds of
> resources cannot be allocated by drivers because these do not (and should
> not) know about the root resource nodes in the platform. Consequently,
> you see lots of drivers that do allocate memory resources, but ignore
> all the others.
>
> Therefore, if a platform wanted to do proper resource management covering
> all kinds of resources, it would have to treat memory and io resources
> specially, relying on the driver to do the actual allocation and implement
> resource management only for the remaining resource types, which is
> certainly ugly.
>
> Thanks for your comments!
>
> Thomas
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Apr 2010 10:21:37 +0200
> From: "Koeller, T." <[email protected]>
> To: "Kevin Hilman" <[email protected]>
> Cc: [email protected]
> Subject: RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Kevin,
>
> > > --- /dev/null
> > > +++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> > > @@ -0,0 +1,17 @@
> > > +#ifndef _DAVINCI_EVM_RESOURCES_H
> > > +#define _DAVINCI_EVM_RESOURCES_H
> > > +
> > > +#include <mach/irqs.h>
> > > +#include <mach/edma.h>
> > > +
> > > +/* IRQs */
> > > +#define IRQ_SPI0 IRQ_DM365_SPIINT0_0
> >
> > This can be dropped, and IRQ_DM365_SPIINT0_0 used directly.
> >
> > > +/* DMA channels */
> > > +#define DMA_CHAN_SPI0_TX 16
> > > +#define DMA_CHAN_SPI0_RX 17
> >
> > These are SoC common, should be in <soc>.h
> >
> > > +/* DMA event queues */
> > > +#define DMA_EVQ_SPI0 EVENTQ_3
> >
> > This can be dropped, and EVNETQ_3 used directly.
> >
> > > +#endif /* _DAVINCI_EVM_RESOURCES_H */
> >
> > I think it's best to just drop this file and these #defines altogether
> > and just use the values directly in the board files. It will make the
> > board files a bit more readable and avoid a level of indirection.
>
> I thought it a good idea to have central point where all those
> resources (I am using this term in an informal way here) are defined
> in terms of their intended use, making it easier to spot
> possible conflicts.
>
> > > diff --git a/arch/arm/mach-davinci/dm365.c
> > b/arch/arm/mach-davinci/dm365.c
> > > index ed6c9c7..023d708 100644
> > > --- a/arch/arm/mach-davinci/dm365.c
> > > +++ b/arch/arm/mach-davinci/dm365.c
> > > @@ -616,72 +616,256 @@ EVT_CFG(DM365, EVT3_ASP_RX,
> > 1, 1, 0, false)
> > > #endif
> > > };
> > >
> > > -static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> > > +static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
> > >
> > > -static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > > - .version = SPI_VERSION_1,
> > > - .num_chipselect = 2,
> > > - .clk_internal = 1,
> > > - .cs_hold = 1,
> > > - .intr_level = 0,
> > > - .poll_mode = 1, /* 0 -> interrupt mode 1->
> > polling mode */
> > > - .use_dma = 1, /* when 1, value in poll_mode
> > is ignored */
> > > - .c2tdelay = 0,
> > > - .t2cdelay = 0,
> > > +enum dm365_spi_resource_index {
> > > + spirsrc_iomem,
> > > + spirsrc_irq,
> > > + spirsrc_rxdma,
> > > + spirsrc_txdma,
> > > + spirsrc_evqdma
> > > };
> > >
> > > -static struct resource dm365_spi0_resources[] = {
> > > +
> > > +static struct resource dm365_spi_resources[spirsrc_evqdma
> > + 1][5] = {
> > > {
> > > - .start = 0x01c66000,
> > > - .end = 0x01c667ff,
> > > - .flags = IORESOURCE_MEM,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c66000,
> > > + .end = 0x01c667ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = IRQ_DM365_SPIINT0_0,
> > > - .flags = IORESOURCE_IRQ,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c66800,
> > > + .end = 0x01c66fff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 17,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c67800,
> > > + .end = 0x01c67fff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 16,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c68000,
> > > + .end = 0x01c687ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = EVENTQ_3,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c23000,
> > > + .end = 0x01c237ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > + }
> > > +};
> >
> > Since most boards will not be using all of the above, Rather than
> > statically allocate the IRQ and DMA resources, why not allocate them
> > on demand during _init_spi()?
>
> Don't think this is worthwile. You save a couple of bytes, but have
> to add code that does memory allocation and associated error handling.
>
> thanks,
> Thomas
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 21 Apr 2010 15:09:08 +0530
> From: "Nori, Sekhar" <[email protected]>
> To: "Koeller, T." <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Thomas,
>
> On Wed, Apr 21, 2010 at 13:43:55, Koeller, T. wrote:
> > Hi Kevin,
> >
> > >
> > > Actually, the driver is the place where the resources are used and
> > > therefore where they should be reserved and released. This patch
> > > removes this from the drivers and puts it in SoC code which I don't
> > > like.
> > >
> > > There are really two main things going on here that I see:
> > >
> > > 1. add parent resources (cfg, irq, dma, etc.)
> > > 2. move resource reservation from drivers to SoC code
> > >
> > > It's primarily 2 that I object to.
> > >
> > > While I think (1) may be helpful, if we're going to do it, we should
> > > do it throughout all of mach-davinci/*.
> >
> > Here I do not quite agree with your view. In general, resource managment
> > is about avoiding conflicts. This means that it must be done in a
> > place where the resource requirements of all devices are known, and this
> > is the bus, not the individual drivers. This is more obvious when
> > dealing with buses that enumerate their devices and collect their
> > resource requirements in order to make intelligent decisions. The
> > platform bus has been invented to extend this concept to devices that
> > are not really on such a bus.
> >
> > For platform devices, resources are set up by the platform and passed to
> > the drivers via platform devices. At this point, the decision about which
> > resource is going to be used by a particular driver has already been made,
> > and nothing is gained by defering the actual allocation. Resource
>
> I can think of one (admittedly esoteric) example where this not true.
> On the DM6446 EVM, the NAND and NOR flash reside on the same chip-select
> and it is possible to runtime switch between the flashes used by
> flipping a jumper and insmoding the appropriate driver.
>
> Currently, both nand and nor drivers do not make a memory region request,
> but that should probably be fixed.
>
> > allocation in the driver is only possible for resources for which
> > global root nodes exist (IO and MEMORY addresses). All other kinds of
> > resources cannot be allocated by drivers because these do not (and should
> > not) know about the root resource nodes in the platform. Consequently,
> > you see lots of drivers that do allocate memory resources, but ignore
> > all the others.
>
> IRQ resources are managed by request_irq(). EDMA does its own resource
> management, but ideally should be using drivers/dma/ resource manager.
>
> So, I tend to think of it as driver requesting and releasing all
> shared resources.
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 21 Apr 2010 14:10:29 +0200
> From: "Koeller, T." <[email protected]>
> To: "Nori, Sekhar" <[email protected]>
> Cc: [email protected]
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> From: Nori, Sekhar [mailto:[email protected]]
>
> > IRQ resources are managed by request_irq(). EDMA does its own resource
> > management, but ideally should be using drivers/dma/ resource manager.
>
> This is not the kind of resource management I am talking about. You could
> call request_irq() with any bogus irq number (similar for DMA) and not notice
> that you are doing something wrong. You could attempt to set up an interrupt
> as shared that is not sharable. Look at linux/ioport.h for a lot of stuff
> designed to aid in avoiding such conflicts by proper use of resources.
>
> Finally, a platform may define resources that are totally platform-specific,
> and that can only be managed within the platform itself.
>
> thanks,
> Thomas
>
>
> ------------------------------
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> End of Davinci-linux-open-source Digest, Vol 52, Issue 65
> *********************************************************
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
