* [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue @ 2012-04-24 8:09 Michael Trimarchi 2012-04-24 8:13 ` Gilles Chanteperdrix 0 siblings, 1 reply; 9+ messages in thread From: Michael Trimarchi @ 2012-04-24 8:09 UTC (permalink / raw) To: Adeos; +Cc: b.morelli This patch includes: * Fix invalid virtual address base of MX1_2_TCM * Fix the minimum delay below which the hardware timer can not be reprogrammed. The value is the same of that one that is used to calculate the min_delta_ns arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns = clockevent_delta2ns(0xff, &clockevent_mxc); Signed-off-by: Michael Trimarchi <michael@domain.hid> Signed-off-by: Bruno Morelli <b.morelli@domain.hid> --- arch/arm/plat-mxc/time.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c index aae2717..30916f8 100644 --- a/arch/arm/plat-mxc/time.c +++ b/arch/arm/plat-mxc/time.c @@ -400,11 +400,11 @@ mxc_timer_init(struct clk *timer_clk, __ipipe_mach_timerint = irq; __ipipe_mach_ticks_per_jiffy = (clk_get_rate(timer_clk) + HZ/2) / HZ; tsc_info.freq = clk_get_rate(timer_clk); - mxc_min_delay = ((__ipipe_cpu_freq + 500000) / 1000000) ?: 1; + mxc_min_delay = 0xff; if (timer_is_v1()) { tsc_info.u.counter_paddr = phys + MX1_2_TCN; - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); } else { tsc_info.u.counter_paddr = phys + V2_TCN; tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); -- 1.7.5.4 -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 8:09 [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue Michael Trimarchi @ 2012-04-24 8:13 ` Gilles Chanteperdrix 2012-04-24 8:32 ` Michael Trimarchi 0 siblings, 1 reply; 9+ messages in thread From: Gilles Chanteperdrix @ 2012-04-24 8:13 UTC (permalink / raw) To: Michael Trimarchi; +Cc: Adeos, b.morelli On 04/24/2012 10:09 AM, Michael Trimarchi wrote: > This patch includes: > > * Fix invalid virtual address base of MX1_2_TCM > * Fix the minimum delay below which the hardware timer can not be reprogrammed. > The value is the same of that one that is used to calculate the min_delta_ns > > arch/arm/plat-mxc/time.c > 414: clockevent_mxc.min_delta_ns = clockevent_delta2ns(0xff, &clockevent_mxc); I do not think we can use this value, it is way to high for xenomai needs. In latest releases we use 2us instead of 1us, and according to what a user posted recently, this should be enough, could you test with 2us? And 2us is already what we have in the 3.2 repository. -- Gilles. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 8:13 ` Gilles Chanteperdrix @ 2012-04-24 8:32 ` Michael Trimarchi 2012-04-24 8:53 ` Gilles Chanteperdrix 0 siblings, 1 reply; 9+ messages in thread From: Michael Trimarchi @ 2012-04-24 8:32 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Adeos, b.morelli On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: > On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >> This patch includes: >> >> * Fix invalid virtual address base of MX1_2_TCM >> * Fix the minimum delay below which the hardware timer can not be reprogrammed. >> The value is the same of that one that is used to calculate the min_delta_ns >> >> arch/arm/plat-mxc/time.c >> 414: clockevent_mxc.min_delta_ns = clockevent_delta2ns(0xff, &clockevent_mxc); > > I do not think we can use this value, it is way to high for xenomai > needs. In latest releases we use 2us instead of 1us, and according to > what a user posted recently, this should be enough, could you test with > 2us? And 2us is already what we have in the 3.2 repository. > As I understood the min delays is in tick and not depend on the clock rate. This is from atmel at91_ipipe_time min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns * clkevt.mult) >> clkevt.shift; this is exaclty the reverse calculation of clockevent_mxc.min_delta_ns I have already the result in the previous calculation: 0xff is the minimun in ticks Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 8:32 ` Michael Trimarchi @ 2012-04-24 8:53 ` Gilles Chanteperdrix 2012-04-24 9:31 ` Michael Trimarchi 0 siblings, 1 reply; 9+ messages in thread From: Gilles Chanteperdrix @ 2012-04-24 8:53 UTC (permalink / raw) To: Michael Trimarchi; +Cc: Adeos, b.morelli On 04/24/2012 10:32 AM, Michael Trimarchi wrote: > On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>> This patch includes: >>> >>> * Fix invalid virtual address base of MX1_2_TCM >>> * Fix the minimum delay below which the hardware timer can not be reprogrammed. >>> The value is the same of that one that is used to calculate the min_delta_ns >>> >>> arch/arm/plat-mxc/time.c >>> 414: clockevent_mxc.min_delta_ns = clockevent_delta2ns(0xff, &clockevent_mxc); >> >> I do not think we can use this value, it is way to high for xenomai >> needs. In latest releases we use 2us instead of 1us, and according to >> what a user posted recently, this should be enough, could you test with >> 2us? And 2us is already what we have in the 3.2 repository. >> > As I understood the min delays is in tick and not depend on the clock rate. > > This is from atmel at91_ipipe_time > > min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns > * clkevt.mult) >> clkevt.shift; > > this is exaclty the reverse calculation of clockevent_mxc.min_delta_ns > > I have already the result in the previous calculation: 0xff is the minimun in ticks 0xff is too large, it corresponds to 30us on some platforms, could you please try with 2us? The delay is given as a count of ticks or as a duration in ns depending on the architecture, it does not really matter. > > Michael > -- Gilles. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 8:53 ` Gilles Chanteperdrix @ 2012-04-24 9:31 ` Michael Trimarchi 2012-04-24 9:41 ` Gilles Chanteperdrix 0 siblings, 1 reply; 9+ messages in thread From: Michael Trimarchi @ 2012-04-24 9:31 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Adeos, b.morelli Hi On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote: > On 04/24/2012 10:32 AM, Michael Trimarchi wrote: >> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>>> This patch includes: >>>> >>>> * Fix invalid virtual address base of MX1_2_TCM >>>> * Fix the minimum delay below which the hardware timer can not be reprogrammed. >>>> The value is the same of that one that is used to calculate the min_delta_ns >>>> >>>> arch/arm/plat-mxc/time.c >>>> 414: clockevent_mxc.min_delta_ns = clockevent_delta2ns(0xff, &clockevent_mxc); >>> >>> I do not think we can use this value, it is way to high for xenomai >>> needs. In latest releases we use 2us instead of 1us, and according to >>> what a user posted recently, this should be enough, could you test with >>> 2us? And 2us is already what we have in the 3.2 repository. >>> >> As I understood the min delays is in tick and not depend on the clock rate. >> >> This is from atmel at91_ipipe_time >> >> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns >> * clkevt.mult) >> clkevt.shift; >> >> this is exaclty the reverse calculation of clockevent_mxc.min_delta_ns >> >> I have already the result in the previous calculation: 0xff is the minimun in ticks > > 0xff is too large, it corresponds to 30us on some platforms, could you > please try with 2us? The delay is given as a count of ticks or as a > duration in ns depending on the architecture, it does not really matter. > Ok, with 0x85 is working (2 uS). I don't find in the documentation the min_delta_ns for this architecture. I will rebase the patch on core-3.2 Michael >> >> Michael >> > > -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 9:31 ` Michael Trimarchi @ 2012-04-24 9:41 ` Gilles Chanteperdrix 2012-04-24 20:34 ` Gilles Chanteperdrix 0 siblings, 1 reply; 9+ messages in thread From: Gilles Chanteperdrix @ 2012-04-24 9:41 UTC (permalink / raw) To: Michael Trimarchi; +Cc: Adeos, b.morelli On 04/24/2012 11:31 AM, Michael Trimarchi wrote: > Hi > > On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote: >> On 04/24/2012 10:32 AM, Michael Trimarchi wrote: >>> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >>>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>>>> This patch includes: >>>>> >>>>> * Fix invalid virtual address base of MX1_2_TCM * Fix the >>>>> minimum delay below which the hardware timer can not be >>>>> reprogrammed. The value is the same of that one that is used >>>>> to calculate the min_delta_ns >>>>> >>>>> arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns = >>>>> clockevent_delta2ns(0xff, &clockevent_mxc); >>>> >>>> I do not think we can use this value, it is way to high for >>>> xenomai needs. In latest releases we use 2us instead of 1us, >>>> and according to what a user posted recently, this should be >>>> enough, could you test with 2us? And 2us is already what we >>>> have in the 3.2 repository. >>>> >>> As I understood the min delays is in tick and not depend on the >>> clock rate. >>> >>> This is from atmel at91_ipipe_time >>> >>> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns * >>> clkevt.mult) >> clkevt.shift; >>> >>> this is exaclty the reverse calculation of >>> clockevent_mxc.min_delta_ns >>> >>> I have already the result in the previous calculation: 0xff is >>> the minimun in ticks >> >> 0xff is too large, it corresponds to 30us on some platforms, could >> you please try with 2us? The delay is given as a count of ticks or >> as a duration in ns depending on the architecture, it does not >> really matter. >> > > Ok, with 0x85 is working (2 uS). I don't find in the documentation > the min_delta_ns for this architecture. I will rebase the patch on > core-3.2 This is not really a specified constant, finding this minimum value is more of a hit and miss. Anyway, on core 3.2, the timers have been substantially reworked, and we are able to reuse the clockevent callback which has a safety mechanism in addition to the minimum value to avoid loosing ticks (in short, the timer is re-read after programming it, and if the delay has already passed, the callback returns a negative value, which the timer subsystem uses to trigger the irq). Core-3.2 is not yet supported on ARM for xenomai 2.6. I will do the changes and keep you informed. -- Gilles. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 9:41 ` Gilles Chanteperdrix @ 2012-04-24 20:34 ` Gilles Chanteperdrix 2012-04-25 8:12 ` Michael Trimarchi 0 siblings, 1 reply; 9+ messages in thread From: Gilles Chanteperdrix @ 2012-04-24 20:34 UTC (permalink / raw) To: Michael Trimarchi; +Cc: Adeos, b.morelli On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote: > On 04/24/2012 11:31 AM, Michael Trimarchi wrote: >> Hi >> >> On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote: >>> On 04/24/2012 10:32 AM, Michael Trimarchi wrote: >>>> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >>>>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>>>>> This patch includes: >>>>>> >>>>>> * Fix invalid virtual address base of MX1_2_TCM * Fix the >>>>>> minimum delay below which the hardware timer can not be >>>>>> reprogrammed. The value is the same of that one that is used >>>>>> to calculate the min_delta_ns >>>>>> >>>>>> arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns = >>>>>> clockevent_delta2ns(0xff, &clockevent_mxc); >>>>> >>>>> I do not think we can use this value, it is way to high for >>>>> xenomai needs. In latest releases we use 2us instead of 1us, >>>>> and according to what a user posted recently, this should be >>>>> enough, could you test with 2us? And 2us is already what we >>>>> have in the 3.2 repository. >>>>> >>>> As I understood the min delays is in tick and not depend on the >>>> clock rate. >>>> >>>> This is from atmel at91_ipipe_time >>>> >>>> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns * >>>> clkevt.mult) >> clkevt.shift; >>>> >>>> this is exaclty the reverse calculation of >>>> clockevent_mxc.min_delta_ns >>>> >>>> I have already the result in the previous calculation: 0xff is >>>> the minimun in ticks >>> >>> 0xff is too large, it corresponds to 30us on some platforms, could >>> you please try with 2us? The delay is given as a count of ticks or >>> as a duration in ns depending on the architecture, it does not >>> really matter. >>> >> >> Ok, with 0x85 is working (2 uS). I don't find in the documentation >> the min_delta_ns for this architecture. I will rebase the patch on >> core-3.2 > > This is not really a specified constant, finding this minimum value is > more of a hit and miss. Anyway, on core 3.2, the timers have been > substantially reworked, and we are able to reuse the clockevent callback > which has a safety mechanism in addition to the minimum value to avoid > loosing ticks (in short, the timer is re-read after programming it, and > if the delay has already passed, the callback returns a negative value, > which the timer subsystem uses to trigger the irq). > > Core-3.2 is not yet supported on ARM for xenomai 2.6. I will do the > changes and keep you informed. > Ok, I have just pushed the changes to the 2.6 branch repository to support I-pipe core on ARM. So, the repository for xenomai is: git://git.xenomai.org/xenoami-2.6.git branch master and the repository for the core-3.2 ipipe series is: git://git.denx.de/ipipe.git branch core-3.2 -- Gilles. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-24 20:34 ` Gilles Chanteperdrix @ 2012-04-25 8:12 ` Michael Trimarchi 2012-04-25 8:18 ` Gilles Chanteperdrix 0 siblings, 1 reply; 9+ messages in thread From: Michael Trimarchi @ 2012-04-25 8:12 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Adeos, b.morelli Hi Gilles On 04/24/2012 10:34 PM, Gilles Chanteperdrix wrote: > On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote: >> On 04/24/2012 11:31 AM, Michael Trimarchi wrote: >>> Hi >>> >>> On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote: >>>> On 04/24/2012 10:32 AM, Michael Trimarchi wrote: >>>>> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >>>>>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>>>>>> This patch includes: >>>>>>> >>>>>>> * Fix invalid virtual address base of MX1_2_TCM * Fix the >>>>>>> minimum delay below which the hardware timer can not be >>>>>>> reprogrammed. The value is the same of that one that is used >>>>>>> to calculate the min_delta_ns >>>>>>> >>>>>>> arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns = >>>>>>> clockevent_delta2ns(0xff, &clockevent_mxc); >>>>>> >>>>>> I do not think we can use this value, it is way to high for >>>>>> xenomai needs. In latest releases we use 2us instead of 1us, >>>>>> and according to what a user posted recently, this should be >>>>>> enough, could you test with 2us? And 2us is already what we >>>>>> have in the 3.2 repository. >>>>>> >>>>> As I understood the min delays is in tick and not depend on the >>>>> clock rate. >>>>> >>>>> This is from atmel at91_ipipe_time >>>>> >>>>> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns * >>>>> clkevt.mult) >> clkevt.shift; >>>>> >>>>> this is exaclty the reverse calculation of >>>>> clockevent_mxc.min_delta_ns >>>>> >>>>> I have already the result in the previous calculation: 0xff is >>>>> the minimun in ticks >>>> >>>> 0xff is too large, it corresponds to 30us on some platforms, could >>>> you please try with 2us? The delay is given as a count of ticks or >>>> as a duration in ns depending on the architecture, it does not >>>> really matter. >>>> >>> >>> Ok, with 0x85 is working (2 uS). I don't find in the documentation >>> the min_delta_ns for this architecture. I will rebase the patch on >>> core-3.2 >> >> This is not really a specified constant, finding this minimum value is >> more of a hit and miss. Anyway, on core 3.2, the timers have been >> substantially reworked, and we are able to reuse the clockevent callback >> which has a safety mechanism in addition to the minimum value to avoid >> loosing ticks (in short, the timer is re-read after programming it, and >> if the delay has already passed, the callback returns a negative value, >> which the timer subsystem uses to trigger the irq). >> >> Core-3.2 is not yet supported on ARM for xenomai 2.6. I will do the >> changes and keep you informed. >> > Ok, I have just pushed the changes to the 2.6 branch repository to > support I-pipe core on ARM. > > So, the repository for xenomai is: > git://git.xenomai.org/xenoami-2.6.git branch master > and the repository for the core-3.2 ipipe series is: > git://git.denx.de/ipipe.git branch core-3.2 > Thanks I will rebase the the embedded board on top of the ipipe core-3.2 so I can test again the ipipe layer. Michael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue 2012-04-25 8:12 ` Michael Trimarchi @ 2012-04-25 8:18 ` Gilles Chanteperdrix 0 siblings, 0 replies; 9+ messages in thread From: Gilles Chanteperdrix @ 2012-04-25 8:18 UTC (permalink / raw) To: Michael Trimarchi; +Cc: Adeos, b.morelli On 04/25/2012 10:12 AM, Michael Trimarchi wrote: > Hi Gilles > > On 04/24/2012 10:34 PM, Gilles Chanteperdrix wrote: >> On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote: >>> On 04/24/2012 11:31 AM, Michael Trimarchi wrote: >>>> Hi >>>> >>>> On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote: >>>>> On 04/24/2012 10:32 AM, Michael Trimarchi wrote: >>>>>> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote: >>>>>>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote: >>>>>>>> This patch includes: >>>>>>>> >>>>>>>> * Fix invalid virtual address base of MX1_2_TCM * Fix the >>>>>>>> minimum delay below which the hardware timer can not be >>>>>>>> reprogrammed. The value is the same of that one that is used >>>>>>>> to calculate the min_delta_ns >>>>>>>> >>>>>>>> arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns = >>>>>>>> clockevent_delta2ns(0xff, &clockevent_mxc); >>>>>>> >>>>>>> I do not think we can use this value, it is way to high for >>>>>>> xenomai needs. In latest releases we use 2us instead of 1us, >>>>>>> and according to what a user posted recently, this should be >>>>>>> enough, could you test with 2us? And 2us is already what we >>>>>>> have in the 3.2 repository. >>>>>>> >>>>>> As I understood the min delays is in tick and not depend on the >>>>>> clock rate. >>>>>> >>>>>> This is from atmel at91_ipipe_time >>>>>> >>>>>> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns * >>>>>> clkevt.mult) >> clkevt.shift; >>>>>> >>>>>> this is exaclty the reverse calculation of >>>>>> clockevent_mxc.min_delta_ns >>>>>> >>>>>> I have already the result in the previous calculation: 0xff is >>>>>> the minimun in ticks >>>>> >>>>> 0xff is too large, it corresponds to 30us on some platforms, could >>>>> you please try with 2us? The delay is given as a count of ticks or >>>>> as a duration in ns depending on the architecture, it does not >>>>> really matter. >>>>> >>>> >>>> Ok, with 0x85 is working (2 uS). I don't find in the documentation >>>> the min_delta_ns for this architecture. I will rebase the patch on >>>> core-3.2 >>> >>> This is not really a specified constant, finding this minimum value is >>> more of a hit and miss. Anyway, on core 3.2, the timers have been >>> substantially reworked, and we are able to reuse the clockevent callback >>> which has a safety mechanism in addition to the minimum value to avoid >>> loosing ticks (in short, the timer is re-read after programming it, and >>> if the delay has already passed, the callback returns a negative value, >>> which the timer subsystem uses to trigger the irq). >>> >>> Core-3.2 is not yet supported on ARM for xenomai 2.6. I will do the >>> changes and keep you informed. >>> >> Ok, I have just pushed the changes to the 2.6 branch repository to >> support I-pipe core on ARM. >> >> So, the repository for xenomai is: >> git://git.xenomai.org/xenoami-2.6.git branch master >> and the repository for the core-3.2 ipipe series is: >> git://git.denx.de/ipipe.git branch core-3.2 >> > > Thanks > I will rebase the the embedded board on top of the ipipe core-3.2 so I can > test again the ipipe layer. Ok. In fact, please use the ipipe-core from this branch: git://git.xenomai.org/ipipe-gch.git branch for-ipipe-3.2-arm, it is generally more up to date for arm (in this case, it contains some fixes for imx). > > Michael > -- Gilles. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-04-25 8:18 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-24 8:09 [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue Michael Trimarchi 2012-04-24 8:13 ` Gilles Chanteperdrix 2012-04-24 8:32 ` Michael Trimarchi 2012-04-24 8:53 ` Gilles Chanteperdrix 2012-04-24 9:31 ` Michael Trimarchi 2012-04-24 9:41 ` Gilles Chanteperdrix 2012-04-24 20:34 ` Gilles Chanteperdrix 2012-04-25 8:12 ` Michael Trimarchi 2012-04-25 8:18 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.