-z means that every following option is for the linker, and since many compiler options follow the expansion of usr.bld, you can't use -z in that file. Is there not a link.cmd or linker.cmd file that can be used instead (and is consumed by the XDC tooling)?
Regards, - Rob ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Mohamed AbdElwahed Sent: Tuesday, April 27, 2010 5:38 AM To: Davinci Mailing list Subject: Compile Error 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 [http://graphics.hotmail.com/i.p.emthup.gif] > 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: <87633lepfu....@deeproots! ystems.com> > Content-Type: text/plain; charset=us-ascii & gt; > [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 av! ailable. > > 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: <87zl0xdaum. [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 > > >! ; > _______________________________________________ > > Da vinci-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 a! nd 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 > > > +#d! efine _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 o! f 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_interna l = 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] = { > &g! t; > + .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, > > > + }, > > &g! t; + [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 pla! tform resource management > Message-ID: > <B85A65D85D7E [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 thro! ughout 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 reques t_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. Get it now.<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
