| Message ID | 1396504871-1454-8-git-send-email-tharvey@gateworks.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Stefano Babic |
| Headers | show |
Hi Tim, On 04/03/2014 09:01 AM, Tim Harvey wrote: > This is an attempt at using a macro to allow mx6dl-ddr.h and > mx6q-ddr.h registers to be used together which is needed for an SPL bootloader > that can run on either CPU's and must configure MMDC iomux dynamically. > > I am trying to come up with a solution similar to Eric's approach with the > similar issue regarding IMX pinmux but this approach is broken in that imximage > will choke on the cfgtmp file due to the fact that the pre-processor won't > use the enum's as it did the #defines. I'm looking for some positive > suggestions here or perhaps someone else can come up with a solution for this > particular issue which I haven't been able to resolve. Why can't you just rename the register name #defines without enclosing them in an anonymous enum? Then they could coexist and will be usable by imximage.
On Wed, Apr 9, 2014 at 7:57 AM, Nikita Kiryanov <nikita@compulab.co.il> wrote: > Hi Tim, > > > On 04/03/2014 09:01 AM, Tim Harvey wrote: >> >> This is an attempt at using a macro to allow mx6dl-ddr.h and >> mx6q-ddr.h registers to be used together which is needed for an SPL >> bootloader >> that can run on either CPU's and must configure MMDC iomux dynamically. >> >> I am trying to come up with a solution similar to Eric's approach with the >> similar issue regarding IMX pinmux but this approach is broken in that >> imximage >> will choke on the cfgtmp file due to the fact that the pre-processor won't >> use the enum's as it did the #defines. I'm looking for some positive >> suggestions here or perhaps someone else can come up with a solution for >> this >> particular issue which I haven't been able to resolve. > > > Why can't you just rename the register name #defines without enclosing > them in an anonymous enum? Then they could coexist and will be usable > by imximage. > > -- > Regards, > Nikita. Nikita, The cfg files are currently all written to use the IOMUX register names as MX6_ (no Q vs DL) so that a single cfg file can be used for a build-time configuration of IMX6Q or IMX6DL. Furthermore, then cfg files use the pre-processor only, which is why the enums I chose don't work for non-SPL. For SPL, I need both sets of #defines (here they could be enums however) so I would have to duplicate all of the #defines in mx6q_pins.h and mx6dl_pins.h to provide both the MX6_ and the MX6Q_/MX6DL_ #defines. I'm ok with submitting that duplication if there is no other way. Am I missing something completely obvious here? Maybe an example of what you are thinking would help me understand. Regards, Tim
On 04/09/2014 06:46 PM, Tim Harvey wrote: > On Wed, Apr 9, 2014 at 7:57 AM, Nikita Kiryanov <nikita@compulab.co.il> wrote: >> Hi Tim, >> >> >> On 04/03/2014 09:01 AM, Tim Harvey wrote: >>> >>> This is an attempt at using a macro to allow mx6dl-ddr.h and >>> mx6q-ddr.h registers to be used together which is needed for an SPL >>> bootloader >>> that can run on either CPU's and must configure MMDC iomux dynamically. >>> >>> I am trying to come up with a solution similar to Eric's approach with the >>> similar issue regarding IMX pinmux but this approach is broken in that >>> imximage >>> will choke on the cfgtmp file due to the fact that the pre-processor won't >>> use the enum's as it did the #defines. I'm looking for some positive >>> suggestions here or perhaps someone else can come up with a solution for >>> this >>> particular issue which I haven't been able to resolve. >> >> >> Why can't you just rename the register name #defines without enclosing >> them in an anonymous enum? Then they could coexist and will be usable >> by imximage. >> >> -- >> Regards, >> Nikita. > > Nikita, > > The cfg files are currently all written to use the IOMUX register > names as MX6_ (no Q vs DL) so that a single cfg file can be used for a > build-time configuration of IMX6Q or IMX6DL. OK now I understand. It seems to me that you only have this problem because you are using these address #defines as values for mx6_mmdc_ioregs structs to define a register mapping. You can also define this mapping by using a struct template that matches the register layout and a base address, both of which change between CPU types. You can find an example of this in the Wandboard SPL implementation. It's not in mainline ATM so you'll have to download their BSP. The template + base addr method also doesn't use up additional memory to define this layout, which is a point in its favor. > > Regards, > > Tim >
On 04/10/2014 05:08 PM, Nikita Kiryanov wrote: > On 04/09/2014 06:46 PM, Tim Harvey wrote: >> On Wed, Apr 9, 2014 at 7:57 AM, Nikita Kiryanov >> <nikita@compulab.co.il> wrote: >>> Hi Tim, >>> >>> >>> On 04/03/2014 09:01 AM, Tim Harvey wrote: >>>> >>>> This is an attempt at using a macro to allow mx6dl-ddr.h and >>>> mx6q-ddr.h registers to be used together which is needed for an SPL >>>> bootloader >>>> that can run on either CPU's and must configure MMDC iomux dynamically. >>>> >>>> I am trying to come up with a solution similar to Eric's approach >>>> with the >>>> similar issue regarding IMX pinmux but this approach is broken in that >>>> imximage >>>> will choke on the cfgtmp file due to the fact that the pre-processor >>>> won't >>>> use the enum's as it did the #defines. I'm looking for some positive >>>> suggestions here or perhaps someone else can come up with a solution >>>> for >>>> this >>>> particular issue which I haven't been able to resolve. >>> >>> >>> Why can't you just rename the register name #defines without enclosing >>> them in an anonymous enum? Then they could coexist and will be usable >>> by imximage. >>> >>> -- >>> Regards, >>> Nikita. >> >> Nikita, >> >> The cfg files are currently all written to use the IOMUX register >> names as MX6_ (no Q vs DL) so that a single cfg file can be used for a >> build-time configuration of IMX6Q or IMX6DL. > > OK now I understand. It seems to me that you only have this problem > because you are using these address #defines as values for > mx6_mmdc_ioregs structs to define a register mapping. You can > also define this mapping by using a struct template that matches the > register layout and a base address, both of which change between CPU > types. > > You can find an example of this in the Wandboard SPL implementation. Here I'm referring to the file arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h (which I'm guessing you may have already seen based on your comment on patch 11...) > It's not in mainline ATM so you'll have to download their BSP. > The template + base addr method also doesn't use up additional memory > to define this layout, which is a point in its favor. > >> >> Regards, >> >> Tim >> > >
On Thu, Apr 10, 2014 at 7:51 AM, Nikita Kiryanov <nikita@compulab.co.il> wrote: > On 04/10/2014 05:08 PM, Nikita Kiryanov wrote: <snip> > > Here I'm referring to the file arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h > (which I'm guessing you may have already seen based on your comment on > patch 11...) > Nikita, Yes, I started with that but I thought from the previous discussion that the structures were disliked. I will revert back to that approach for my v2 patch and see how well its received. Regards, Tim
Hi Tim, On 09/04/2014 17:46, Tim Harvey wrote: > On Wed, Apr 9, 2014 at 7:57 AM, Nikita Kiryanov <nikita@compulab.co.il> wrote: >> Hi Tim, >> >> >> On 04/03/2014 09:01 AM, Tim Harvey wrote: >>> >>> This is an attempt at using a macro to allow mx6dl-ddr.h and >>> mx6q-ddr.h registers to be used together which is needed for an SPL >>> bootloader >>> that can run on either CPU's and must configure MMDC iomux dynamically. >>> >>> I am trying to come up with a solution similar to Eric's approach with the >>> similar issue regarding IMX pinmux but this approach is broken in that >>> imximage >>> will choke on the cfgtmp file due to the fact that the pre-processor won't >>> use the enum's as it did the #defines. I'm looking for some positive >>> suggestions here or perhaps someone else can come up with a solution for >>> this >>> particular issue which I haven't been able to resolve. >> It seems that this patch breaks all other boards. I tried myself and after preprocessing the .cfg file, the resulting file contains structures that mkimage cannot process. For example, building udoo: MKIMAGE u-boot.imx Invalid imximage commands Type - valid names are: BOOT_FROM, BOOT_OFFSET, DATA, CSF, IMAGE_VERSION Error: board/udoo/udoo.cfg.cfgtmp[44] - Invalid command(struct) In fact, board/udoo/udoo.cfg.cfgtmp contains the structures from /mx6-ddr.h (this patch): # 15 "include/config.h" 2 # 23 "board/udoo/udoo.cfg" 2 # 1 "/home/stefano/Projects/imx/u-boot-imx/arch/arm/include/asm/arch/mx6-ddr.h" 1 # 15 "/home/stefano/Projects/imx/u-boot-imx/arch/arm/include/asm/arch/mx6-ddr.h" struct mx6_mmdc_ioregs { u32 mmdc_dram_dqm0; u32 mmdc_dram_dqm1; u32 mmdc_dram_dqm2; u32 mmdc_dram_dqm3; u32 mmdc_dram_dqm4; u32 mmdc_dram_dqm5; u32 mmdc_dram_dqm6; u32 mmdc_dram_dqm7; u32 mmdc_dram_cas; u32 mmdc_dram_ras; and then mkimage stops. Best regards, Stefano Babic
Hi Tim, hi Nikita, On 10/04/2014 16:08, Nikita Kiryanov wrote: >> The cfg files are currently all written to use the IOMUX register >> names as MX6_ (no Q vs DL) so that a single cfg file can be used for a >> build-time configuration of IMX6Q or IMX6DL. > > OK now I understand. It seems to me that you only have this problem > because you are using these address #defines as values for > mx6_mmdc_ioregs structs to define a register mapping. You can > also define this mapping by using a struct template that matches the > register layout and a base address, both of which change between CPU > types. > Reason to do in this way is the thought that the layout among the processsors can be completely different, thing that for other area is also true. This was discussed also in a previous RFC by Eric: http://lists.denx.de/pipermail/u-boot/2013-November/166665.html Tim, what about to repost in your patchset Eric's patch ? It completes your patchset and add documentation that is now missing (added Eric in CC if he will complain about this..) However, if we can recognize the same layout for all three variations (I have only check some registers in 6Q and 6DL layout), using the same structure with a different base address can be even more readable. I admit I have not checked deeply, but it seems at first glance that mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. > You can find an example of this in the Wandboard SPL implementation. > It's not in mainline ATM so you'll have to download their BSP. > The template + base addr method also doesn't use up additional memory > to define this layout, which is a point in its favor. If the layout is exactly the same, you could make the structure available to all imx6 flavors. Best regards, Stefano Babic
Hi Stefano, On 04/23/2014 10:07 AM, Stefano Babic wrote: > Hi Tim, hi Nikita, > > On 10/04/2014 16:08, Nikita Kiryanov wrote: > >>> The cfg files are currently all written to use the IOMUX register >>> names as MX6_ (no Q vs DL) so that a single cfg file can be used for a >>> build-time configuration of IMX6Q or IMX6DL. >> >> OK now I understand. It seems to me that you only have this problem >> because you are using these address #defines as values for >> mx6_mmdc_ioregs structs to define a register mapping. You can >> also define this mapping by using a struct template that matches the >> register layout and a base address, both of which change between CPU >> types. >> > > Reason to do in this way is the thought that the layout among the > processsors can be completely different, thing that for other area is > also true. > > This was discussed also in a previous RFC by Eric: > > http://lists.denx.de/pipermail/u-boot/2013-November/166665.html > > Tim, what about to repost in your patchset Eric's patch ? It completes > your patchset and add documentation that is now missing (added Eric in > CC if he will complain about this..) > I have no problem with this, but when I did some follow-on work to bring up SPL on Nitrogen6x boards, I recall finding some bugs in that patch set. I didn't follow up with updates because I ran into some other snags. In particular, our use of SPI-NOR makes it crucial that we be able to download a secondary U-Boot over USB. > However, if we can recognize the same layout for all three variations (I > have only check some registers in 6Q and 6DL layout), using the same > structure with a different base address can be even more readable. I > admit I have not checked deeply, but it seems at first glance that > mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. > There's a lot of commonality, but a quick diff of arch-mx6/mx6q-ddr.h and arch-mx6/mx6dl-ddr.h will show the problem areas. >> You can find an example of this in the Wandboard SPL implementation. >> It's not in mainline ATM so you'll have to download their BSP. >> The template + base addr method also doesn't use up additional memory >> to define this layout, which is a point in its favor. > > If the layout is exactly the same, you could make the structure > available to all imx6 flavors. > Unfortunately, I don't believe it is. Regards, Eric
On Wed, Apr 23, 2014 at 10:07 AM, Stefano Babic <sbabic@denx.de> wrote: > Hi Tim, hi Nikita, > > On 10/04/2014 16:08, Nikita Kiryanov wrote: > >>> The cfg files are currently all written to use the IOMUX register >>> names as MX6_ (no Q vs DL) so that a single cfg file can be used for a >>> build-time configuration of IMX6Q or IMX6DL. >> >> OK now I understand. It seems to me that you only have this problem >> because you are using these address #defines as values for >> mx6_mmdc_ioregs structs to define a register mapping. You can >> also define this mapping by using a struct template that matches the >> register layout and a base address, both of which change between CPU >> types. >> > > Reason to do in this way is the thought that the layout among the > processsors can be completely different, thing that for other area is > also true. This was discussed also in a previous RFC by Eric: > > http://lists.denx.de/pipermail/u-boot/2013-November/166665.html > > Tim, what about to repost in your patchset Eric's patch ? It completes > your patchset and add documentation that is now missing (added Eric in > CC if he will complain about this..) The documentation portion of Eric's patch I agreed with for the most part, but in my case I need to take a more flexible approach as I support multiple board variants in a single bootloader that vary a bit in pinmux and GPIO's. For this reason, I don't like the idea of declaring all your iomux in a single structure (Eric's README section 4). > > However, if we can recognize the same layout for all three variations (I > have only check some registers in 6Q and 6DL layout), using the same > structure with a different base address can be even more readable. I > admit I have not checked deeply, but it seems at first glance that > mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. > >> You can find an example of this in the Wandboard SPL implementation. >> It's not in mainline ATM so you'll have to download their BSP. >> The template + base addr method also doesn't use up additional memory >> to define this layout, which is a point in its favor. > > If the layout is exactly the same, you could make the structure > available to all imx6 flavors. > > Best regards, > Stefano Babic > They do differ, but that isn't to say one can't just have two memory mapped struct's and pick which one to use based on CPU, which is exactly what Tapani proposed originally and is what is used in the non-mainlined Wandboard. I will be moving to this method in v2. Regards, Tim
On 04/23/14 22:00, Eric Nelson wrote: > Hi Stefano, > > On 04/23/2014 10:07 AM, Stefano Babic wrote: >> Hi Tim, hi Nikita, >> >> On 10/04/2014 16:08, Nikita Kiryanov wrote: >> >>>> The cfg files are currently all written to use the IOMUX register >>>> names as MX6_ (no Q vs DL) so that a single cfg file can be used for a >>>> build-time configuration of IMX6Q or IMX6DL. >>> >>> OK now I understand. It seems to me that you only have this problem >>> because you are using these address #defines as values for >>> mx6_mmdc_ioregs structs to define a register mapping. You can >>> also define this mapping by using a struct template that matches the >>> register layout and a base address, both of which change between CPU >>> types. >>> >> >> Reason to do in this way is the thought that the layout among the >> processsors can be completely different, thing that for other area is >> also true. >> >> This was discussed also in a previous RFC by Eric: >> >> http://lists.denx.de/pipermail/u-boot/2013-November/166665.html >> >> Tim, what about to repost in your patchset Eric's patch ? It completes >> your patchset and add documentation that is now missing (added Eric in >> CC if he will complain about this..) >> > > I have no problem with this, but when I did some follow-on work to > bring up SPL on Nitrogen6x boards, I recall finding some bugs in > that patch set. > > I didn't follow up with updates because I ran into some other > snags. In particular, our use of SPI-NOR makes it crucial that > we be able to download a secondary U-Boot over USB. > >> However, if we can recognize the same layout for all three variations (I >> have only check some registers in 6Q and 6DL layout), using the same >> structure with a different base address can be even more readable. I >> admit I have not checked deeply, but it seems at first glance that >> mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. >> > > There's a lot of commonality, but a quick diff of arch-mx6/mx6q-ddr.h > and arch-mx6/mx6dl-ddr.h will show the problem areas. > >>> You can find an example of this in the Wandboard SPL implementation. >>> It's not in mainline ATM so you'll have to download their BSP. >>> The template + base addr method also doesn't use up additional memory >>> to define this layout, which is a point in its favor. >> >> If the layout is exactly the same, you could make the structure >> available to all imx6 flavors. >> > > Unfortunately, I don't believe it is. I also, remember it is not. What Tim says actually makes sense, if layout is not the same, define two structs and choose the right one in runtime.
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h b/arch/arm/include/asm/arch-mx6/mx6-ddr.h index 43d377a..6ac857e 100644 --- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h +++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h @@ -6,15 +6,34 @@ #ifndef __ASM_ARCH_MX6_DDR_H__ #define __ASM_ARCH_MX6_DDR_H__ -#ifdef CONFIG_MX6Q +#define MX6_ADDR_DECLARE(prefix, name, addr) \ + prefix##name = addr + +#ifdef CONFIG_MX6QDL +enum { +#define MX6_ADDR_DECL(name, addr) \ + MX6_ADDR_DECLARE(MX6Q_, name, addr), #include "mx6q-ddr.h" -#else -#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) +}; +#undef MX6_ADDR_DECL + +enum { +#define MX6_ADDR_DECL(name, addr) \ + MX6_ADDR_DECLARE(MX6DL_, name, addr), +#include "mx6dl-ddr.h" +}; + +#elif defined(CONFIG_MX6Q) +#define MX6_ADDR_DECL(name, addr) \ + MX6_ADDR_DECLARE(MX6_, name, addr), +#include "mx6q-ddr.h" +#elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) +#define MX6_ADDR_DECL(name, addr) \ + MX6_ADDR_DECLARE(MX6_, name, addr), #include "mx6dl-ddr.h" #else #error "Please select cpu" -#endif /* CONFIG_MX6DL or CONFIG_MX6S */ -#endif /* CONFIG_MX6Q */ +#endif #define MX6_MMDC_P0_MDCTL 0x021b0000 #define MX6_MMDC_P0_MDPDC 0x021b0004 diff --git a/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h b/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h index 1eb4b3c..4828974 100644 --- a/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h +++ b/arch/arm/include/asm/arch-mx6/mx6dl-ddr.h @@ -6,54 +6,56 @@ #ifndef __ASM_ARCH_MX6DLS_DDR_H__ #define __ASM_ARCH_MX6DLS_DDR_H__ +#ifndef CONFIG_MX6QDL #ifndef CONFIG_MX6DL #ifndef CONFIG_MX6S #error "wrong CPU" #endif #endif +#endif -#define MX6_IOM_DRAM_DQM0 0x020e0470 -#define MX6_IOM_DRAM_DQM1 0x020e0474 -#define MX6_IOM_DRAM_DQM2 0x020e0478 -#define MX6_IOM_DRAM_DQM3 0x020e047c -#define MX6_IOM_DRAM_DQM4 0x020e0480 -#define MX6_IOM_DRAM_DQM5 0x020e0484 -#define MX6_IOM_DRAM_DQM6 0x020e0488 -#define MX6_IOM_DRAM_DQM7 0x020e048c +MX6_ADDR_DECL(IOM_DRAM_DQM0, 0x020e0470) +MX6_ADDR_DECL(IOM_DRAM_DQM1, 0x020e0474) +MX6_ADDR_DECL(IOM_DRAM_DQM2, 0x020e0478) +MX6_ADDR_DECL(IOM_DRAM_DQM3, 0x020e047c) +MX6_ADDR_DECL(IOM_DRAM_DQM4, 0x020e0480) +MX6_ADDR_DECL(IOM_DRAM_DQM5, 0x020e0484) +MX6_ADDR_DECL(IOM_DRAM_DQM6, 0x020e0488) +MX6_ADDR_DECL(IOM_DRAM_DQM7, 0x020e048c) -#define MX6_IOM_DRAM_CAS 0x020e0464 -#define MX6_IOM_DRAM_RAS 0x020e0490 -#define MX6_IOM_DRAM_RESET 0x020e0494 -#define MX6_IOM_DRAM_SDCLK_0 0x020e04ac -#define MX6_IOM_DRAM_SDCLK_1 0x020e04b0 -#define MX6_IOM_DRAM_SDBA2 0x020e04a0 -#define MX6_IOM_DRAM_SDCKE0 0x020e04a4 -#define MX6_IOM_DRAM_SDCKE1 0x020e04a8 -#define MX6_IOM_DRAM_SDODT0 0x020e04b4 -#define MX6_IOM_DRAM_SDODT1 0x020e04b8 +MX6_ADDR_DECL(IOM_DRAM_CAS, 0x020e0464) +MX6_ADDR_DECL(IOM_DRAM_RAS, 0x020e0490) +MX6_ADDR_DECL(IOM_DRAM_RESET, 0x020e0494) +MX6_ADDR_DECL(IOM_DRAM_SDCLK_0, 0x020e04ac) +MX6_ADDR_DECL(IOM_DRAM_SDCLK_1, 0x020e04b0) +MX6_ADDR_DECL(IOM_DRAM_SDBA2, 0x020e04a0) +MX6_ADDR_DECL(IOM_DRAM_SDCKE0, 0x020e04a4) +MX6_ADDR_DECL(IOM_DRAM_SDCKE1, 0x020e04a8) +MX6_ADDR_DECL(IOM_DRAM_SDODT0, 0x020e04b4) +MX6_ADDR_DECL(IOM_DRAM_SDODT1, 0x020e04b8) -#define MX6_IOM_DRAM_SDQS0 0x020e04bc -#define MX6_IOM_DRAM_SDQS1 0x020e04c0 -#define MX6_IOM_DRAM_SDQS2 0x020e04c4 -#define MX6_IOM_DRAM_SDQS3 0x020e04c8 -#define MX6_IOM_DRAM_SDQS4 0x020e04cc -#define MX6_IOM_DRAM_SDQS5 0x020e04d0 -#define MX6_IOM_DRAM_SDQS6 0x020e04d4 -#define MX6_IOM_DRAM_SDQS7 0x020e04d8 +MX6_ADDR_DECL(IOM_DRAM_SDQS0, 0x020e04bc) +MX6_ADDR_DECL(IOM_DRAM_SDQS1, 0x020e04c0) +MX6_ADDR_DECL(IOM_DRAM_SDQS2, 0x020e04c4) +MX6_ADDR_DECL(IOM_DRAM_SDQS3, 0x020e04c8) +MX6_ADDR_DECL(IOM_DRAM_SDQS4, 0x020e04cc) +MX6_ADDR_DECL(IOM_DRAM_SDQS5, 0x020e04d0) +MX6_ADDR_DECL(IOM_DRAM_SDQS6, 0x020e04d4) +MX6_ADDR_DECL(IOM_DRAM_SDQS7, 0x020e04d8) -#define MX6_IOM_GRP_B0DS 0x020e0764 -#define MX6_IOM_GRP_B1DS 0x020e0770 -#define MX6_IOM_GRP_B2DS 0x020e0778 -#define MX6_IOM_GRP_B3DS 0x020e077c -#define MX6_IOM_GRP_B4DS 0x020e0780 -#define MX6_IOM_GRP_B5DS 0x020e0784 -#define MX6_IOM_GRP_B6DS 0x020e078c -#define MX6_IOM_GRP_B7DS 0x020e0748 -#define MX6_IOM_GRP_ADDDS 0x020e074c -#define MX6_IOM_DDRMODE_CTL 0x020e0750 -#define MX6_IOM_GRP_DDRPKE 0x020e0754 -#define MX6_IOM_GRP_DDRMODE 0x020e0760 -#define MX6_IOM_GRP_CTLDS 0x020e076c -#define MX6_IOM_GRP_DDR_TYPE 0x020e0774 +MX6_ADDR_DECL(IOM_GRP_B0DS, 0x020e0764) +MX6_ADDR_DECL(IOM_GRP_B1DS, 0x020e0770) +MX6_ADDR_DECL(IOM_GRP_B2DS, 0x020e0778) +MX6_ADDR_DECL(IOM_GRP_B3DS, 0x020e077c) +MX6_ADDR_DECL(IOM_GRP_B4DS, 0x020e0780) +MX6_ADDR_DECL(IOM_GRP_B5DS, 0x020e0784) +MX6_ADDR_DECL(IOM_GRP_B6DS, 0x020e078c) +MX6_ADDR_DECL(IOM_GRP_B7DS, 0x020e0748) +MX6_ADDR_DECL(IOM_GRP_ADDDS, 0x020e074c) +MX6_ADDR_DECL(IOM_DDRMODE_CTL, 0x020e0750) +MX6_ADDR_DECL(IOM_GRP_DDRPKE, 0x020e0754) +MX6_ADDR_DECL(IOM_GRP_DDRMODE, 0x020e0760) +MX6_ADDR_DECL(IOM_GRP_CTLDS, 0x020e076c) +MX6_ADDR_DECL(IOM_GRP_DDR_TYPE, 0x020e0774) #endif /*__ASM_ARCH_MX6S_DDR_H__ */ diff --git a/arch/arm/include/asm/arch-mx6/mx6q-ddr.h b/arch/arm/include/asm/arch-mx6/mx6q-ddr.h index 0aa94cf..bd9cf1a 100644 --- a/arch/arm/include/asm/arch-mx6/mx6q-ddr.h +++ b/arch/arm/include/asm/arch-mx6/mx6q-ddr.h @@ -6,52 +6,54 @@ #ifndef __ASM_ARCH_MX6Q_DDR_H__ #define __ASM_ARCH_MX6Q_DDR_H__ +#ifndef CONFIG_MX6QDL #ifndef CONFIG_MX6Q #error "wrong CPU" #endif +#endif -#define MX6_IOM_DRAM_DQM0 0x020e05ac -#define MX6_IOM_DRAM_DQM1 0x020e05b4 -#define MX6_IOM_DRAM_DQM2 0x020e0528 -#define MX6_IOM_DRAM_DQM3 0x020e0520 -#define MX6_IOM_DRAM_DQM4 0x020e0514 -#define MX6_IOM_DRAM_DQM5 0x020e0510 -#define MX6_IOM_DRAM_DQM6 0x020e05bc -#define MX6_IOM_DRAM_DQM7 0x020e05c4 +MX6_ADDR_DECL(IOM_DRAM_DQM0, 0x020e05ac) +MX6_ADDR_DECL(IOM_DRAM_DQM1, 0x020e05b4) +MX6_ADDR_DECL(IOM_DRAM_DQM2, 0x020e0528) +MX6_ADDR_DECL(IOM_DRAM_DQM3, 0x020e0520) +MX6_ADDR_DECL(IOM_DRAM_DQM4, 0x020e0514) +MX6_ADDR_DECL(IOM_DRAM_DQM5, 0x020e0510) +MX6_ADDR_DECL(IOM_DRAM_DQM6, 0x020e05bc) +MX6_ADDR_DECL(IOM_DRAM_DQM7, 0x020e05c4) -#define MX6_IOM_DRAM_CAS 0x020e056c -#define MX6_IOM_DRAM_RAS 0x020e0578 -#define MX6_IOM_DRAM_RESET 0x020e057c -#define MX6_IOM_DRAM_SDCLK_0 0x020e0588 -#define MX6_IOM_DRAM_SDCLK_1 0x020e0594 -#define MX6_IOM_DRAM_SDBA2 0x020e058c -#define MX6_IOM_DRAM_SDCKE0 0x020e0590 -#define MX6_IOM_DRAM_SDCKE1 0x020e0598 -#define MX6_IOM_DRAM_SDODT0 0x020e059c -#define MX6_IOM_DRAM_SDODT1 0x020e05a0 +MX6_ADDR_DECL(IOM_DRAM_CAS, 0x020e056c) +MX6_ADDR_DECL(IOM_DRAM_RAS, 0x020e0578) +MX6_ADDR_DECL(IOM_DRAM_RESET, 0x020e057c) +MX6_ADDR_DECL(IOM_DRAM_SDCLK_0, 0x020e0588) +MX6_ADDR_DECL(IOM_DRAM_SDCLK_1, 0x020e0594) +MX6_ADDR_DECL(IOM_DRAM_SDBA2, 0x020e058c) +MX6_ADDR_DECL(IOM_DRAM_SDCKE0, 0x020e0590) +MX6_ADDR_DECL(IOM_DRAM_SDCKE1, 0x020e0598) +MX6_ADDR_DECL(IOM_DRAM_SDODT0, 0x020e059c) +MX6_ADDR_DECL(IOM_DRAM_SDODT1, 0x020e05a0) -#define MX6_IOM_DRAM_SDQS0 0x020e05a8 -#define MX6_IOM_DRAM_SDQS1 0x020e05b0 -#define MX6_IOM_DRAM_SDQS2 0x020e0524 -#define MX6_IOM_DRAM_SDQS3 0x020e051c -#define MX6_IOM_DRAM_SDQS4 0x020e0518 -#define MX6_IOM_DRAM_SDQS5 0x020e050c -#define MX6_IOM_DRAM_SDQS6 0x020e05b8 -#define MX6_IOM_DRAM_SDQS7 0x020e05c0 +MX6_ADDR_DECL(IOM_DRAM_SDQS0, 0x020e05a8) +MX6_ADDR_DECL(IOM_DRAM_SDQS1, 0x020e05b0) +MX6_ADDR_DECL(IOM_DRAM_SDQS2, 0x020e0524) +MX6_ADDR_DECL(IOM_DRAM_SDQS3, 0x020e051c) +MX6_ADDR_DECL(IOM_DRAM_SDQS4, 0x020e0518) +MX6_ADDR_DECL(IOM_DRAM_SDQS5, 0x020e050c) +MX6_ADDR_DECL(IOM_DRAM_SDQS6, 0x020e05b8) +MX6_ADDR_DECL(IOM_DRAM_SDQS7, 0x020e05c0) -#define MX6_IOM_GRP_B0DS 0x020e0784 -#define MX6_IOM_GRP_B1DS 0x020e0788 -#define MX6_IOM_GRP_B2DS 0x020e0794 -#define MX6_IOM_GRP_B3DS 0x020e079c -#define MX6_IOM_GRP_B4DS 0x020e07a0 -#define MX6_IOM_GRP_B5DS 0x020e07a4 -#define MX6_IOM_GRP_B6DS 0x020e07a8 -#define MX6_IOM_GRP_B7DS 0x020e0748 -#define MX6_IOM_GRP_ADDDS 0x020e074c -#define MX6_IOM_DDRMODE_CTL 0x020e0750 -#define MX6_IOM_GRP_DDRPKE 0x020e0758 -#define MX6_IOM_GRP_DDRMODE 0x020e0774 -#define MX6_IOM_GRP_CTLDS 0x020e078c -#define MX6_IOM_GRP_DDR_TYPE 0x020e0798 +MX6_ADDR_DECL(IOM_GRP_B0DS, 0x020e0784) +MX6_ADDR_DECL(IOM_GRP_B1DS, 0x020e0788) +MX6_ADDR_DECL(IOM_GRP_B2DS, 0x020e0794) +MX6_ADDR_DECL(IOM_GRP_B3DS, 0x020e079c) +MX6_ADDR_DECL(IOM_GRP_B4DS, 0x020e07a0) +MX6_ADDR_DECL(IOM_GRP_B5DS, 0x020e07a4) +MX6_ADDR_DECL(IOM_GRP_B6DS, 0x020e07a8) +MX6_ADDR_DECL(IOM_GRP_B7DS, 0x020e0748) +MX6_ADDR_DECL(IOM_GRP_ADDDS, 0x020e074c) +MX6_ADDR_DECL(IOM_DDRMODE_CTL, 0x020e0750) +MX6_ADDR_DECL(IOM_GRP_DDRPKE, 0x020e0758) +MX6_ADDR_DECL(IOM_GRP_DDRMODE, 0x020e0774) +MX6_ADDR_DECL(IOM_GRP_CTLDS, 0x020e078c) +MX6_ADDR_DECL(IOM_GRP_DDR_TYPE, 0x020e0798) #endif /*__ASM_ARCH_MX6Q_DDR_H__ */
This is an attempt at using a macro to allow mx6dl-ddr.h and mx6q-ddr.h registers to be used together which is needed for an SPL bootloader that can run on either CPU's and must configure MMDC iomux dynamically. I am trying to come up with a solution similar to Eric's approach with the similar issue regarding IMX pinmux but this approach is broken in that imximage will choke on the cfgtmp file due to the fact that the pre-processor won't use the enum's as it did the #defines. I'm looking for some positive suggestions here or perhaps someone else can come up with a solution for this particular issue which I haven't been able to resolve. Signed-off-by: Tim Harvey <tharvey@gateworks.com> --- arch/arm/include/asm/arch-mx6/mx6-ddr.h | 29 +++++++++-- arch/arm/include/asm/arch-mx6/mx6dl-ddr.h | 82 ++++++++++++++++--------------- arch/arm/include/asm/arch-mx6/mx6q-ddr.h | 82 ++++++++++++++++--------------- 3 files changed, 108 insertions(+), 85 deletions(-)