Dear Benoît Thébaudeau,
> Dear Marek Vasut,> > On Sunday, April 21, 2013 9:12:31 PM, Marek Vasut wrote:> > Dear Benoît Thébaudeau,> > > > > Dear Marek Vasut,> > > > > > On Sunday, April 21, 2013 5:52:27 PM, Marek Vasut wrote:> > > > Add basic support for the DENX M53EVK board. Currently supported is:> > > > MMC (incl. booting)> > > > > > > ^> > > > > > Can you clarify this, please?> > > > Use u-boot.imx for SD booting as usual.> > > > > spl_boot_device() points only to NAND, so> > > you're clearly talking about hardware MMC boot, and not about hardware> > > NAND boot followed by SPL payload fetched from MMC. But MMC boot does> > > not need SPL here, in which case you will have to generate a simple> > > u-boot.imx, or you will rather want to use u-boot-with-spl.imx for SD> > > (NAND header dropped to leave room for MBR). And in the latter case,> > > why have spl_boot_device() point to NAND for MMC boot?> > > > No, regular u-boot.imx will be used for SD boot.> > OK. So this will require to call make with u-boot.imx as the explicit> target. Should this be documented somewhere, perhaps in a README file for> this board?> > Another solution would be, like for woodburn, to have an sd-specific> config: - m53evk_nand_config would define CONFIG_SPL from boards.cfg, so> u-boot-with-nand-spl.imx would be generated.> - mx53evk_sd_config would not define CONFIG_SPL from boards.cfg, so> u-boot.imx would be generated.> And CONFIG_SPL would be removed from m53evk.h.> > Or, change the various config.mk in order to build u-boot.imx even if> CONFIG_SPL is defined, which would be useless for some boards, but useful> here in order to avoid having 2 configs for almost the same build, while> still not having to explicitly give a make target.
I'd love to see generic u-boot.nand , u-boot.sd etc. targets instead of these
CPU specific stuffs.
Best regards,
Marek Vasut

On 21/04/2013 22:29, Marek Vasut wrote:
> Dear Benoît Thébaudeau,> >> Dear Marek Vasut,>>
Hi Marek,
>> On Sunday, April 21, 2013 9:12:31 PM, Marek Vasut wrote:>>> Dear Benoît Thébaudeau,>>>>>>> Dear Marek Vasut,>>>>>>>> On Sunday, April 21, 2013 5:52:27 PM, Marek Vasut wrote:>>>>> Add basic support for the DENX M53EVK board. Currently supported is:>>>>> MMC (incl. booting)>>>>>>>>> ^>>>>>>>> Can you clarify this, please?>>>>>> Use u-boot.imx for SD booting as usual.>>>>>>> spl_boot_device() points only to NAND, so>>>> you're clearly talking about hardware MMC boot, and not about hardware>>>> NAND boot followed by SPL payload fetched from MMC. But MMC boot does>>>> not need SPL here, in which case you will have to generate a simple>>>> u-boot.imx, or you will rather want to use u-boot-with-spl.imx for SD>>>> (NAND header dropped to leave room for MBR). And in the latter case,>>>> why have spl_boot_device() point to NAND for MMC boot?>>>>>> No, regular u-boot.imx will be used for SD boot.>>>> OK. So this will require to call make with u-boot.imx as the explicit>> target. Should this be documented somewhere, perhaps in a README file for>> this board?>>>> Another solution would be, like for woodburn, to have an sd-specific>> config: - m53evk_nand_config would define CONFIG_SPL from boards.cfg, so>> u-boot-with-nand-spl.imx would be generated.>> - mx53evk_sd_config would not define CONFIG_SPL from boards.cfg, so>> u-boot.imx would be generated.>> And CONFIG_SPL would be removed from m53evk.h.>>>> Or, change the various config.mk in order to build u-boot.imx even if>> CONFIG_SPL is defined, which would be useless for some boards, but useful>> here in order to avoid having 2 configs for almost the same build, while>> still not having to explicitly give a make target.> > I'd love to see generic u-boot.nand , u-boot.sd etc. targets instead of these > CPU specific stuffs.>
But you forget that a single image can be saved on multiple storage:
u-boot.imx can be stored on SD or NOR or SPI-NOR, and that is the reason
for having SOC-specific extension.
I agree with Benoit: at the moment, only people working with i.MX know
that u-boot.im runs on SD. The third solution proposed by Benoit has the
drawback that probably not all boards need u-boot.imx (a board without
SD for example). At least we need an update of the README, but I think
it is not bad to have a new entry in boards.cfg.
Apart of that and not related to this patch, if we in future use SPL
also for booting from SD, we can get a single way to boot from different
storage. TI based SOCs already do this: same SPL, it checks from SD and
NAND.
Best regards,
Stefano

Hi Stefano,
On Wednesday, April 24, 2013 9:39:17 AM, Stefano Babic wrote:
> On 21/04/2013 22:29, Marek Vasut wrote:> > Dear Benoît Thébaudeau,> > > >> Dear Marek Vasut,> >>> > Hi Marek,> > >> On Sunday, April 21, 2013 9:12:31 PM, Marek Vasut wrote:> >>> Dear Benoît Thébaudeau,> >>>> >>>> Dear Marek Vasut,> >>>>> >>>> On Sunday, April 21, 2013 5:52:27 PM, Marek Vasut wrote:> >>>>> Add basic support for the DENX M53EVK board. Currently supported is:> >>>>> MMC (incl. booting)> >>>>>> >>>> ^> >>>>> >>>> Can you clarify this, please?> >>>> >>> Use u-boot.imx for SD booting as usual.> >>>> >>>> spl_boot_device() points only to NAND, so> >>>> you're clearly talking about hardware MMC boot, and not about hardware> >>>> NAND boot followed by SPL payload fetched from MMC. But MMC boot does> >>>> not need SPL here, in which case you will have to generate a simple> >>>> u-boot.imx, or you will rather want to use u-boot-with-spl.imx for SD> >>>> (NAND header dropped to leave room for MBR). And in the latter case,> >>>> why have spl_boot_device() point to NAND for MMC boot?> >>>> >>> No, regular u-boot.imx will be used for SD boot.> >>> >> OK. So this will require to call make with u-boot.imx as the explicit> >> target. Should this be documented somewhere, perhaps in a README file for> >> this board?> >>> >> Another solution would be, like for woodburn, to have an sd-specific> >> config: - m53evk_nand_config would define CONFIG_SPL from boards.cfg, so> >> u-boot-with-nand-spl.imx would be generated.> >> - mx53evk_sd_config would not define CONFIG_SPL from boards.cfg, so> >> u-boot.imx would be generated.> >> And CONFIG_SPL would be removed from m53evk.h.> >>> >> Or, change the various config.mk in order to build u-boot.imx even if> >> CONFIG_SPL is defined, which would be useless for some boards, but useful> >> here in order to avoid having 2 configs for almost the same build, while> >> still not having to explicitly give a make target.> > > > I'd love to see generic u-boot.nand , u-boot.sd etc. targets instead of> > these> > CPU specific stuffs.> > > > But you forget that a single image can be saved on multiple storage:> u-boot.imx can be stored on SD or NOR or SPI-NOR, and that is the reason> for having SOC-specific extension.> > I agree with Benoit: at the moment, only people working with i.MX know> that u-boot.im runs on SD. The third solution proposed by Benoit has the> drawback that probably not all boards need u-boot.imx (a board without> SD for example). At least we need an update of the README, but I think> it is not bad to have a new entry in boards.cfg.> > Apart of that and not related to this patch, if we in future use SPL> also for booting from SD, we can get a single way to boot from different> storage. TI based SOCs already do this: same SPL, it checks from SD and> NAND.
With this also comes the issue of BOOT_FROM in board/denx/m53evk/imximage.cfg.
Strictly speaking, in order to be correct, it should be #if-ed depending on some
config option: nand or sd.
Best regards,
Benoît

Dear Stefano Babic,
> On 21/04/2013 22:29, Marek Vasut wrote:> > Dear Benoît Thébaudeau,> > > >> Dear Marek Vasut,> > Hi Marek,> > >> On Sunday, April 21, 2013 9:12:31 PM, Marek Vasut wrote:> >>> Dear Benoît Thébaudeau,> >>> > >>>> Dear Marek Vasut,> >>>> > >>>> On Sunday, April 21, 2013 5:52:27 PM, Marek Vasut wrote:> >>>>> Add basic support for the DENX M53EVK board. Currently supported is:> >>>>> MMC (incl. booting)> >>>>> > >>>> ^> >>>> > >>>> Can you clarify this, please?> >>> > >>> Use u-boot.imx for SD booting as usual.> >>> > >>>> spl_boot_device() points only to NAND, so> >>>> you're clearly talking about hardware MMC boot, and not about hardware> >>>> NAND boot followed by SPL payload fetched from MMC. But MMC boot does> >>>> not need SPL here, in which case you will have to generate a simple> >>>> u-boot.imx, or you will rather want to use u-boot-with-spl.imx for SD> >>>> (NAND header dropped to leave room for MBR). And in the latter case,> >>>> why have spl_boot_device() point to NAND for MMC boot?> >>> > >>> No, regular u-boot.imx will be used for SD boot.> >> > >> OK. So this will require to call make with u-boot.imx as the explicit> >> target. Should this be documented somewhere, perhaps in a README file> >> for this board?> >> > >> Another solution would be, like for woodburn, to have an sd-specific> >> config: - m53evk_nand_config would define CONFIG_SPL from boards.cfg, so> >> > >> u-boot-with-nand-spl.imx would be generated.> >> > >> - mx53evk_sd_config would not define CONFIG_SPL from boards.cfg, so> >> > >> u-boot.imx would be generated.> >> And CONFIG_SPL would be removed from m53evk.h.> >> > >> Or, change the various config.mk in order to build u-boot.imx even if> >> CONFIG_SPL is defined, which would be useless for some boards, but> >> useful here in order to avoid having 2 configs for almost the same> >> build, while still not having to explicitly give a make target.> > > > I'd love to see generic u-boot.nand , u-boot.sd etc. targets instead of> > these CPU specific stuffs.> > But you forget that a single image can be saved on multiple storage:> u-boot.imx can be stored on SD or NOR or SPI-NOR, and that is the reason> for having SOC-specific extension.> > I agree with Benoit: at the moment, only people working with i.MX know> that u-boot.im runs on SD. The third solution proposed by Benoit has the> drawback that probably not all boards need u-boot.imx (a board without> SD for example). At least we need an update of the README, but I think> it is not bad to have a new entry in boards.cfg.> > Apart of that and not related to this patch, if we in future use SPL> also for booting from SD, we can get a single way to boot from different> storage. TI based SOCs already do this: same SPL, it checks from SD and> NAND.
Ok, I fail to grasp what is wanted from me. Shall I rework the patch somehow?
How? Do we want m53evk_sd and m53evk_nand targets ?
Best regards,
Marek Vasut

On Wed, Apr 24, 2013 at 6:32 PM, Marek Vasut <marex@denx.de> wrote:
> We don't have that on MX5. Or do you mean I should do the work and submit this> patch afterwards ?
To make things easier, I just sent a patch series that you can use :-)
> Which one? Or do you mean generate two files full of register sets because of> these two bits?
No, my suggestion is just to put these 2 defines into imx-regs.h. This
is also part of my series I just sent.
>>> > +>> > + /* NAND flash is muxed on ATA pins */>> > + setbits_le32(M4IF_BASE_ADDR + 0xc, M4IF_GENP_WEIM_MM);>> > +>> > + /* Wait for Grant/Ack sequence (see EIM_CSnGCR2:MUX16_BYP_GRANT)>> > */ + for (i = 0x4; i < 0x94; i += 0x18)>> > + clrbits_le32(WEIM_BASE_ADDR + i,>> > WEIM_GCR2_MUX16_BYP_GRANT); +>> > + mxc_set_clock(0, 33, MXC_NFC_CLK);>> > + enable_nfc_clk(1);>>>> Shouldn't this function be placed into a common mx5 location? mx53ard>> uses the same.>> The WEIM and M4IF configuration is board-specific.
Right, understood. It seems like a duplication of code from mx53ard,
but anyway, what about:
clrbits_le32(WEIM_BASE_ADDR + i, WEIM_GCR2_MUX16_BYP_GRANT) ?
Accessing registers via offsets is not the best practice in U-boot.
What about the weim struct defined at arch/arm/include/asm/arch-mx5/imx-regs.h
for acessing such registers?

On 24/04/2013 20:52, Marek Vasut wrote:
>> But you forget that a single image can be saved on multiple storage:>> u-boot.imx can be stored on SD or NOR or SPI-NOR, and that is the reason>> for having SOC-specific extension.>>>> I agree with Benoit: at the moment, only people working with i.MX know>> that u-boot.im runs on SD. The third solution proposed by Benoit has the>> drawback that probably not all boards need u-boot.imx (a board without>> SD for example). At least we need an update of the README, but I think>> it is not bad to have a new entry in boards.cfg.>>>> Apart of that and not related to this patch, if we in future use SPL>> also for booting from SD, we can get a single way to boot from different>> storage. TI based SOCs already do this: same SPL, it checks from SD and>> NAND.> > Ok, I fail to grasp what is wanted from me. Shall I rework the patch somehow? > How? Do we want m53evk_sd and m53evk_nand targets ?
At least add documentation in the README. It is only your choice if you
will add two different targets to boards.cfg
Best regards,
Stefano

On 24/04/2013 12:59, Benoît Thébaudeau wrote:
>> Apart of that and not related to this patch, if we in future use SPL>> also for booting from SD, we can get a single way to boot from different>> storage. TI based SOCs already do this: same SPL, it checks from SD and>> NAND.> > With this also comes the issue of BOOT_FROM in board/denx/m53evk/imximage.cfg.> Strictly speaking, in order to be correct, it should be #if-ed depending on some> config option: nand or sd.
Right, this is also correct. Anyway, BOOT_FROM is used to get the offset
inside the storage, and only to be as much flexible as possible, each
storage has defined its own offset. However, Freescale uses the same
offset (0x400) for most storages (NAND, SD..) and another one for NOR or
OneNAND (0x1000). Maybe it is easier to have only this two cases.
Best regards,
Stefano

Hi Stefano,
On 25.04.2013 09:31, Stefano Babic wrote:
> On 24/04/2013 12:59, Benoît Thébaudeau wrote:> >>> Apart of that and not related to this patch, if we in future use SPL>>> also for booting from SD, we can get a single way to boot from different>>> storage. TI based SOCs already do this: same SPL, it checks from SD and>>> NAND.>>>> With this also comes the issue of BOOT_FROM in board/denx/m53evk/imximage.cfg.>> Strictly speaking, in order to be correct, it should be #if-ed depending on some>> config option: nand or sd.> > Right, this is also correct. Anyway, BOOT_FROM is used to get the offset> inside the storage, and only to be as much flexible as possible, each> storage has defined its own offset. However, Freescale uses the same> offset (0x400) for most storages (NAND, SD..) and another one for NOR or> OneNAND (0x1000). Maybe it is easier to have only this two cases.
Yes, I would prefer that.
And being at it, why don't we add the offset to the resulting image as
well? This would make programming the images to the destination (SD,
NAND, MMC etc) easier. We would not have to care for the correct offset
then (which is more error prone). And it is necessary btw, to have this
offset added, when using the FSL kobs-ng tool to program the image to
NAND flash.
Thanks,
Stefan

On 25/04/2013 10:38, Stefan Roese wrote:
> Hi Stefano,> > On 25.04.2013 09:31, Stefano Babic wrote:>> On 24/04/2013 12:59, Benoît Thébaudeau wrote:>>>>>> Apart of that and not related to this patch, if we in future use SPL>>>> also for booting from SD, we can get a single way to boot from different>>>> storage. TI based SOCs already do this: same SPL, it checks from SD and>>>> NAND.>>>>>> With this also comes the issue of BOOT_FROM in board/denx/m53evk/imximage.cfg.>>> Strictly speaking, in order to be correct, it should be #if-ed depending on some>>> config option: nand or sd.>>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the offset>> inside the storage, and only to be as much flexible as possible, each>> storage has defined its own offset. However, Freescale uses the same>> offset (0x400) for most storages (NAND, SD..) and another one for NOR or>> OneNAND (0x1000). Maybe it is easier to have only this two cases.> > Yes, I would prefer that.> > And being at it, why don't we add the offset to the resulting image as> well? This would make programming the images to the destination (SD,> NAND, MMC etc) easier.
Well, than this feature shoulb be added to the mkimage tool. I suggest
to add a directive to the configuration file (imximage.cfg), such as
PADDING or something like this.
> We would not have to care for the correct offset> then (which is more error prone). And it is necessary btw, to have this> offset added, when using the FSL kobs-ng tool
To my knowledge: do you have the sources for this tool to better
understand what it does ? I can find binaries with different version (I
think 1.3 is the last), but no sources at all. I have not found if it is
open source or not.
Best regards,
Stefano

Dear Stefan Roese,
> Hi Stefano,> > On 25.04.2013 09:31, Stefano Babic wrote:> > On 24/04/2013 12:59, Benoît Thébaudeau wrote:> >>> Apart of that and not related to this patch, if we in future use SPL> >>> also for booting from SD, we can get a single way to boot from> >>> different storage. TI based SOCs already do this: same SPL, it checks> >>> from SD and NAND.> >> > >> With this also comes the issue of BOOT_FROM in> >> board/denx/m53evk/imximage.cfg. Strictly speaking, in order to be> >> correct, it should be #if-ed depending on some config option: nand or> >> sd.> > > > Right, this is also correct. Anyway, BOOT_FROM is used to get the offset> > inside the storage, and only to be as much flexible as possible, each> > storage has defined its own offset. However, Freescale uses the same> > offset (0x400) for most storages (NAND, SD..) and another one for NOR or> > OneNAND (0x1000). Maybe it is easier to have only this two cases.> > Yes, I would prefer that.> > And being at it, why don't we add the offset to the resulting image as> well? This would make programming the images to the destination (SD,> NAND, MMC etc) easier. We would not have to care for the correct offset> then (which is more error prone). And it is necessary btw, to have this> offset added, when using the FSL kobs-ng tool to program the image to> NAND flash.
This would interfere with MBR on SD cards, the offset is there for a reason ;-)
Best regards,
Marek Vasut

On 25.04.2013 14:38, Marek Vasut wrote:
>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the offset>>> inside the storage, and only to be as much flexible as possible, each>>> storage has defined its own offset. However, Freescale uses the same>>> offset (0x400) for most storages (NAND, SD..) and another one for NOR or>>> OneNAND (0x1000). Maybe it is easier to have only this two cases.>>>> Yes, I would prefer that.>>>> And being at it, why don't we add the offset to the resulting image as>> well? This would make programming the images to the destination (SD,>> NAND, MMC etc) easier. We would not have to care for the correct offset>> then (which is more error prone). And it is necessary btw, to have this>> offset added, when using the FSL kobs-ng tool to program the image to>> NAND flash.> > This would interfere with MBR on SD cards, the offset is there for a reason ;-)
Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,
NAND) this padded image would be easier (less error prone) to handle.
Thanks,
Stefan

Hi Stefan,
On Thursday, April 25, 2013 2:48:59 PM, Stefan Roese wrote:
> Subject: Re: [U-Boot] [PATCH V2 6/6] arm: mx5: Add support for DENX M53EVK> > On 25.04.2013 14:38, Marek Vasut wrote:> >>> Right, this is also correct. Anyway, BOOT_FROM is used to get the offset> >>> inside the storage, and only to be as much flexible as possible, each> >>> storage has defined its own offset. However, Freescale uses the same> >>> offset (0x400) for most storages (NAND, SD..) and another one for NOR or> >>> OneNAND (0x1000). Maybe it is easier to have only this two cases.> >>> >> Yes, I would prefer that.> >>> >> And being at it, why don't we add the offset to the resulting image as> >> well? This would make programming the images to the destination (SD,> >> NAND, MMC etc) easier. We would not have to care for the correct offset> >> then (which is more error prone). And it is necessary btw, to have this> >> offset added, when using the FSL kobs-ng tool to program the image to> >> NAND flash.> > > > This would interfere with MBR on SD cards, the offset is there for a reason> > ;-)> > Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,> NAND) this padded image would be easier (less error prone) to handle.
For NAND, we already have u-boot-with-nand-spl.imx. For SPI NOR, something
similar could be done, or this could be done by imximage.
Best regards,
Benoît

On 25/04/2013 14:48, Stefan Roese wrote:
> On 25.04.2013 14:38, Marek Vasut wrote:>>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the offset>>>> inside the storage, and only to be as much flexible as possible, each>>>> storage has defined its own offset. However, Freescale uses the same>>>> offset (0x400) for most storages (NAND, SD..) and another one for NOR or>>>> OneNAND (0x1000). Maybe it is easier to have only this two cases.>>>>>> Yes, I would prefer that.>>>>>> And being at it, why don't we add the offset to the resulting image as>>> well? This would make programming the images to the destination (SD,>>> NAND, MMC etc) easier. We would not have to care for the correct offset>>> then (which is more error prone). And it is necessary btw, to have this>>> offset added, when using the FSL kobs-ng tool to program the image to>>> NAND flash.>>>> This would interfere with MBR on SD cards, the offset is there for a reason ;-)> > Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,> NAND) this padded image would be easier (less error prone) to handle.
If a board can boot only from a single storage, yes. Or at least from
storages with have the same offset. For example, if we have a board with
SPI-NOR and NAND, the offsets are different amd we need two images if we
pad at the beginning. If we want to add such a feature, it should be in
any case disabled to not break most of current boards.
Best regards,
Stefano

On 25/04/2013 14:49, Benoît Thébaudeau wrote:
> Hi Stefan,> > On Thursday, April 25, 2013 2:48:59 PM, Stefan Roese wrote:>> Subject: Re: [U-Boot] [PATCH V2 6/6] arm: mx5: Add support for DENX M53EVK>>>> On 25.04.2013 14:38, Marek Vasut wrote:>>>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the offset>>>>> inside the storage, and only to be as much flexible as possible, each>>>>> storage has defined its own offset. However, Freescale uses the same>>>>> offset (0x400) for most storages (NAND, SD..) and another one for NOR or>>>>> OneNAND (0x1000). Maybe it is easier to have only this two cases.>>>>>>>> Yes, I would prefer that.>>>>>>>> And being at it, why don't we add the offset to the resulting image as>>>> well? This would make programming the images to the destination (SD,>>>> NAND, MMC etc) easier. We would not have to care for the correct offset>>>> then (which is more error prone). And it is necessary btw, to have this>>>> offset added, when using the FSL kobs-ng tool to program the image to>>>> NAND flash.>>>>>> This would interfere with MBR on SD cards, the offset is there for a reason>>> ;-)>>>> Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,>> NAND) this padded image would be easier (less error prone) to handle.> > For NAND, we already have u-boot-with-nand-spl.imx.
Is it padded at the beginnig ? I have thought the pad is between SPL and
u-boot based on CONFIG_SPL_PAD_TO, but we need to flash always at the
right offset.
Regards,
Stefano

Hi Stefano,
On Thursday, April 25, 2013 3:02:25 PM, Stefano Babic wrote:
> On 25/04/2013 14:49, Benoît Thébaudeau wrote:> > Hi Stefan,> > > > On Thursday, April 25, 2013 2:48:59 PM, Stefan Roese wrote:> >> Subject: Re: [U-Boot] [PATCH V2 6/6] arm: mx5: Add support for DENX M53EVK> >>> >> On 25.04.2013 14:38, Marek Vasut wrote:> >>>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the> >>>>> offset> >>>>> inside the storage, and only to be as much flexible as possible, each> >>>>> storage has defined its own offset. However, Freescale uses the same> >>>>> offset (0x400) for most storages (NAND, SD..) and another one for NOR> >>>>> or> >>>>> OneNAND (0x1000). Maybe it is easier to have only this two cases.> >>>>> >>>> Yes, I would prefer that.> >>>>> >>>> And being at it, why don't we add the offset to the resulting image as> >>>> well? This would make programming the images to the destination (SD,> >>>> NAND, MMC etc) easier. We would not have to care for the correct offset> >>>> then (which is more error prone). And it is necessary btw, to have this> >>>> offset added, when using the FSL kobs-ng tool to program the image to> >>>> NAND flash.> >>>> >>> This would interfere with MBR on SD cards, the offset is there for a> >>> reason> >>> ;-)> >>> >> Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,> >> NAND) this padded image would be easier (less error prone) to handle.> > > > For NAND, we already have u-boot-with-nand-spl.imx.> > Is it padded at the beginnig ? I have thought the pad is between SPL and> u-boot based on CONFIG_SPL_PAD_TO, but we need to flash always at the> right offset.
Here are the image types that we currently have:
- u-boot.imx: imx header + u-boot.bin, no padding to compensate for imx offset,
generic usage,
- SPL: imx header + u-boot-spl.bin, no padding to compensate for imx offset,
generic SPL usage,
- u-boot-with-spl.imx: SPL padded to CONFIG_SPL_PAD_TO + uImaged-u-boot.bin, no
padding to compensate for imx offset, any non-NAND SPL + u-boot usage,
- u-boot-with-nand-spl.imx: (FCB (filling normal imx offset) + SPL) padded to
CONFIG_SPL_PAD_TO + uImaged-u-boot.bin, NAND SPL + u-boot usage.
Best regards,
Benoît

Dear Stefano Babic,
> On 24/04/2013 20:52, Marek Vasut wrote:> >> But you forget that a single image can be saved on multiple storage:> >> u-boot.imx can be stored on SD or NOR or SPI-NOR, and that is the reason> >> for having SOC-specific extension.> >> > >> I agree with Benoit: at the moment, only people working with i.MX know> >> that u-boot.im runs on SD. The third solution proposed by Benoit has the> >> drawback that probably not all boards need u-boot.imx (a board without> >> SD for example). At least we need an update of the README, but I think> >> it is not bad to have a new entry in boards.cfg.> >> > >> Apart of that and not related to this patch, if we in future use SPL> >> also for booting from SD, we can get a single way to boot from different> >> storage. TI based SOCs already do this: same SPL, it checks from SD and> >> NAND.> > > > Ok, I fail to grasp what is wanted from me. Shall I rework the patch> > somehow? How? Do we want m53evk_sd and m53evk_nand targets ?> > At least add documentation in the README. It is only your choice if you> will add two different targets to boards.cfg
I'd prefer not to do that. We're currently booting from NAND and SD, so we use
u-boot.imx resp. u-boot-with-nand-spl.imx there. But using the BOOT_FROM "nand"
in the imximage.cfg is indeed wrong. We should focus on fixing that.
We can now pre-process the imximage.cfg with CPP, so why don't we just replace
BOOT_FROM "foobar" with BOOT_OFFSET CONFIG_IMX_BOOT_OFFSET as mentioned by
someone in the thread already and setup the offset either in board config file
or boards.cfg and even have some default value?
Best regards,
Marek Vasut

Hi Benoît,
On 25.04.2013 14:49, Benoît Thébaudeau wrote:
>>>> Yes, I would prefer that.>>>>>>>> And being at it, why don't we add the offset to the resulting image as>>>> well? This would make programming the images to the destination (SD,>>>> NAND, MMC etc) easier. We would not have to care for the correct offset>>>> then (which is more error prone). And it is necessary btw, to have this>>>> offset added, when using the FSL kobs-ng tool to program the image to>>>> NAND flash.>>>>>> This would interfere with MBR on SD cards, the offset is there for a reason>>> ;-)>>>> Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,>> NAND) this padded image would be easier (less error prone) to handle.> > For NAND, we already have u-boot-with-nand-spl.imx.
I'm thinking more about NAND on iMX6. Which doesn't support SPL (until
now). We could add a new build target for imx6 for NAND booting as well.
Not sure if this is better moved to a build target or to the imximage
generation tool?
> For SPI NOR, something> similar could be done, or this could be done by imximage.
Yes. Perhaps its best to add this to imximage.
Thanks,
Stefan

Dear Stefan Roese,
> Hi Benoît,> > On 25.04.2013 14:49, Benoît Thébaudeau wrote:> >>>> Yes, I would prefer that.> >>>> > >>>> And being at it, why don't we add the offset to the resulting image as> >>>> well? This would make programming the images to the destination (SD,> >>>> NAND, MMC etc) easier. We would not have to care for the correct> >>>> offset then (which is more error prone). And it is necessary btw, to> >>>> have this offset added, when using the FSL kobs-ng tool to program> >>>> the image to NAND flash.> >>> > >>> This would interfere with MBR on SD cards, the offset is there for a> >>> reason ;-)> >> > >> Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR,> >> NAND) this padded image would be easier (less error prone) to handle.> > > > For NAND, we already have u-boot-with-nand-spl.imx.> > I'm thinking more about NAND on iMX6. Which doesn't support SPL (until> now). We could add a new build target for imx6 for NAND booting as well.> Not sure if this is better moved to a build target or to the imximage> generation tool?
Maybe we should focus on common u-boot.nand target too, which would produce
correct result depending on the board configuration etc.
> > For SPI NOR, something> > similar could be done, or this could be done by imximage.> > Yes. Perhaps its best to add this to imximage.> > Thanks,> Stefan
Best regards,
Marek Vasut

On 25/04/2013 15:36, Marek Vasut wrote:
> Dear Stefano Babic,>
Hi Marek,
>> At least add documentation in the README. It is only your choice if you>> will add two different targets to boards.cfg> > I'd prefer not to do that. We're currently booting from NAND and SD, so we use > u-boot.imx resp. u-boot-with-nand-spl.imx there. But using the BOOT_FROM "nand" > in the imximage.cfg is indeed wrong. We should focus on fixing that.> > We can now pre-process the imximage.cfg with CPP, so why don't we just replace > BOOT_FROM "foobar" with BOOT_OFFSET CONFIG_IMX_BOOT_OFFSET
+1
> as mentioned by > someone in the thread already and setup the offset either in board config file > or boards.cfg and even have some default value?
Agree
Best regards,
Stefano

Dear Stefano Babic,
> On 25/04/2013 15:36, Marek Vasut wrote:> > Dear Stefano Babic,> > Hi Marek,> > >> At least add documentation in the README. It is only your choice if you> >> will add two different targets to boards.cfg> > > > I'd prefer not to do that. We're currently booting from NAND and SD, so> > we use u-boot.imx resp. u-boot-with-nand-spl.imx there. But using the> > BOOT_FROM "nand" in the imximage.cfg is indeed wrong. We should focus on> > fixing that.> > > > We can now pre-process the imximage.cfg with CPP, so why don't we just> > replace BOOT_FROM "foobar" with BOOT_OFFSET CONFIG_IMX_BOOT_OFFSET> > +1> > > as mentioned by> > someone in the thread already and setup the offset either in board config> > file or boards.cfg and even have some default value?> > Agree
even better, CONFIG_IMX_BOOT_OFFSET can be defined somewhere to either of the
two values -- one for OneNAND and NOR and the other one for the rest. That'd
make it even easier for people to grok down.
I'll wait for general agreement and then possibly look into implementing it.
Best regards,
Marek Vasut

Dear Fabio Estevam,
[..]
> >> Shouldn't this function be placed into a common mx5 location? mx53ard> >> uses the same.> > > > The WEIM and M4IF configuration is board-specific.> > Right, understood. It seems like a duplication of code from mx53ard,> but anyway, what about:> > clrbits_le32(WEIM_BASE_ADDR + i, WEIM_GCR2_MUX16_BYP_GRANT) ?> > Accessing registers via offsets is not the best practice in U-boot.> > What about the weim struct defined at> arch/arm/include/asm/arch-mx5/imx-regs.h> > for acessing such registers?
Yes, I agree, but you won't be able to do that in a loop as above if accessed
via struct-based access so I'm keeping this.
Best regards,
Marek Vasut