Patchwork [U-Boot] cpu/arm926ejs/start.S question

login
register
mail settings
Submitter Andre Renaud
Date July 7, 2011, 9:38 p.m.
Message ID <4E16276C.3080303@bluewatersys.com>
Download mbox | patch
Permalink /patch/103732/
State Not Applicable
Headers show

Comments

Andre Renaud - July 7, 2011, 9:38 p.m.
Hello,
I am working on an i.MX25 board, and would like to know the recommended
mechanism for putting code in before the first instruction in the
executable, but outside the *_spl system.

Basically, the i.MX25 has a smart boot rom in the CPU, which will
extract the first block, and interpret it (as data, rather than
instructions). However, if I just use the linker script to put this
block before start.S, then U-Boot relocation gets messed up, as _start
is now not the beginning of the image, and a lot of the calculated
offsets are wrong.

At the moment I have this working with the following change in start.S:

and I then #define CONFIG_PRE_START_INCLUDE to be the assembler for the
i.MX25 specific boot code.

Is there a nicer way to go about this?

Regards,
Andre
Simon Glass - July 7, 2011, 10:34 p.m.
Hi Andre,

On Thu, Jul 7, 2011 at 2:38 PM, Andre Renaud <andre@bluewatersys.com> wrote:

> Hello,
> I am working on an i.MX25 board, and would like to know the recommended
> mechanism for putting code in before the first instruction in the
> executable, but outside the *_spl system.
>
> Basically, the i.MX25 has a smart boot rom in the CPU, which will
> extract the first block, and interpret it (as data, rather than
> instructions). However, if I just use the linker script to put this
> block before start.S, then U-Boot relocation gets messed up, as _start
> is now not the beginning of the image, and a lot of the calculated
> offsets are wrong.
>
> At the moment I have this working with the following change in start.S:
> --- cpu/arm926ejs/start.S       (revision 36)
> +++ cpu/arm926ejs/start.S       (working copy)
> @@ -53,6 +53,9 @@
>
>  .globl _start
>  _start:
> +#ifdef CONFIG_PRE_START_INCLUDE
> +#include CONFIG_PRE_START_INCLUDE
> +#endif
>        b       reset
>  #ifdef CONFIG_PRELOADER
>  /* No exception handlers in preloader */
>
> and I then #define CONFIG_PRE_START_INCLUDE to be the assembler for the
> i.MX25 specific boot code.
>
> Is there a nicer way to go about this?
>

We have a similar thing with Tegra, and have built something into the USB
download script which prepends the needed data. In this case it needs to be
signed so it isn't possible to just include it in the U-Boot source, anyway.

I suppose

cat preload.bin u-boot.bin >u-boot.out

is no good?

Regards,
Simon


>
> Regards,
> Andre
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Andre Renaud - July 7, 2011, 10:40 p.m.
Hi Simon,
> We have a similar thing with Tegra, and have built something into the
> USB download script which prepends the needed data. In this case it
> needs to be signed so it isn't possible to just include it in the U-Boot
> source, anyway.
> 
> I suppose
> 
> cat preload.bin u-boot.bin >u-boot.out

I can't think of a particularly good reason why that wouldn't work. It
is nice to use the U-Boot build system to take care of it though, and
there is less chance of someone accidentally flashing the original
u-boot.bin, rather than u-boot.out. I also take advantage of some
information available in the linker in my 'preload.bin', (such as image
size, boot address etc...).

I guess its a question of which is less horrible - maintaining a preload
outside of u-boot, and having a build process which combines them, or
the dodgy #include that I suggested. I'm in favour of the #include,
partly because I've already done it & got it working, but also because
it makes the build system less complex, so less chance of someone making
a mistake. I'm sure I'd feel differently if I'd thought of the
preload.bin first however.

Regards,
Andre
Fabio Estevam - July 8, 2011, 12:54 a.m.
Hi Andre,

On Thu, Jul 7, 2011 at 6:38 PM, Andre Renaud <andre@bluewatersys.com> wrote:
> Hello,
> I am working on an i.MX25 board, and would like to know the recommended
> mechanism for putting code in before the first instruction in the
> executable, but outside the *_spl system.
>
> Basically, the i.MX25 has a smart boot rom in the CPU, which will
> extract the first block, and interpret it (as data, rather than
...

Just to make sure I understand: you want to boot MX25 from internal
mode (from ROM), correct?

We currently do this on the MX51 and we pass the DDR timings, IOMUX,
etc via the DCD (Device Configuration Data) mechanism.

You can refer to: board/freescale/mx51evk/imximage.cfg

I plan to work on adding support for MX25PDK board and I would like to
get it to boot from internal mode (NAND and SD card), but this will
take some time as I will be out for one month.

Would be interested to know whether you get any progress on this side.

Thanks,

Fabio Estevam
Andre Renaud - July 8, 2011, 1:20 a.m.
Hi Fabio,
On 08/07/11 12:54, Fabio Estevam wrote:
> Just to make sure I understand: you want to boot MX25 from internal
> mode (from ROM), correct?

Yes, I am booting in internal mode, so that I can load U-Boot from NAND
(or SPI flash).

> We currently do this on the MX51 and we pass the DDR timings, IOMUX,
> etc via the DCD (Device Configuration Data) mechanism.
> 
> You can refer to: board/freescale/mx51evk/imximage.cfg
> 
> I plan to work on adding support for MX25PDK board and I would like to
> get it to boot from internal mode (NAND and SD card), but this will
> take some time as I will be out for one month.
> 
> Would be interested to know whether you get any progress on this side.

I essentially have it working on 2011.06 from NAND. However I wouldn't
guarantee that the code is necessarily suitable for the main tree. I
have done it via the #include method previously mentioned.

Just out of interest, how does the imximage.cfg file work? I can't see
any reference to that file in any of the build system, so how do you get
it prepended to the image?

Regards,
Andre
Fabio Estevam - July 8, 2011, 1:38 a.m.
Hi Andre,

On Thu, Jul 7, 2011 at 10:20 PM, Andre Renaud <andre@bluewatersys.com> wrote:
..
> Just out of interest, how does the imximage.cfg file work? I can't see
> any reference to that file in any of the build system, so how do you get
> it prepended to the image?

Please check doc/README.imximage file for details regarding the
generation of the u-boot.imx image.

I think that it would be nice if you include such file for your board
so that the same approach as in MX51/MX53 can be used.

Regards,

Fabio Estevam
Andre Renaud - July 8, 2011, 1:42 a.m.
Hi Fabio,
> Please check doc/README.imximage file for details regarding the
> generation of the u-boot.imx image.
> 
> I think that it would be nice if you include such file for your board
> so that the same approach as in MX51/MX53 can be used.

This is basically exactly what I was after. Thanks for that, once I get
some other things finalised I'll shift over to using this system.

Regards,
Andre
Stefano Babic - July 8, 2011, 6:13 a.m.
On 07/08/2011 03:20 AM, Andre Renaud wrote:
> Hi Fabio,
> On 08/07/11 12:54, Fabio Estevam wrote:
>> Just to make sure I understand: you want to boot MX25 from internal
>> mode (from ROM), correct?
> 

Hi Andre,

> Just out of interest, how does the imximage.cfg file work? I can't see
> any reference to that file in any of the build system, so how do you get
> it prepended to the image?

This is exactly the way we use to prepend an header for the i.MX
processors that it is automatically executed before start.S. The i.MX25
uses V1 version of the imximage, as the MX35 and MX51. However, there is
not yet MX25 boards in u-boot using this mechanism.
Of course, it works if (as it should be) the code you want to add has
the goal to write defined values and you cannot add any type of logic.
The syntax is very simple and accepts the format
	 <data wide> <address you want to write> <value>.
You can check the imximage file for mx51/mx53 boards and as reference
the doc/README.imximage, as already stated by Fabio.

Best regards,
Stefano Babic
Andre Renaud - July 11, 2011, 4:59 a.m.
Hi Fabio,

On 08/07/11 12:54, Fabio Estevam wrote:
> Just to make sure I understand: you want to boot MX25 from internal
> mode (from ROM), correct?
> 
> We currently do this on the MX51 and we pass the DDR timings, IOMUX,
> etc via the DCD (Device Configuration Data) mechanism.
> 
> You can refer to: board/freescale/mx51evk/imximage.cfg
> 
> I plan to work on adding support for MX25PDK board and I would like to
> get it to boot from internal mode (NAND and SD card), but this will
> take some time as I will be out for one month.
> 
> Would be interested to know whether you get any progress on this side.

I have basically got this working, but I have to put the final
u-boot.imx image into the SPI flash at address 0x400, not the base (the
image that I had essentially padded it out to 0x400). Is there any
reason that imximage doesn't do this? As far as I can tell from the
i.MX25 datasheet the image has a fixed offset, and there doesn't seem
much point in not rolling this into the final image.

Am I missing something about this?

Regards,
Andre
Fabio Estevam - July 11, 2011, 3 p.m.
Hi Andre,

On Mon, Jul 11, 2011 at 1:59 AM, Andre Renaud <andre@bluewatersys.com> wrote:
...
> I have basically got this working, but I have to put the final
> u-boot.imx image into the SPI flash at address 0x400, not the base (the
> image that I had essentially padded it out to 0x400). Is there any
> reason that imximage doesn't do this? As far as I can tell from the
> i.MX25 datasheet the image has a fixed offset, and there doesn't seem
> much point in not rolling this into the final image.

Actually the offset is not always 0x400. Please check Table 7-10 of MX25RM.

When booting from NOR and OneNAND the offset is 0x100.

So the current behaviour is fine as it allows the same u-boot.imx
image to be flashed on different boot media types by just adjusting
the proper offset.

Regards,

Fabio Estevam

Patch

--- cpu/arm926ejs/start.S       (revision 36)
+++ cpu/arm926ejs/start.S       (working copy)
@@ -53,6 +53,9 @@ 

 .globl _start
 _start:
+#ifdef CONFIG_PRE_START_INCLUDE
+#include CONFIG_PRE_START_INCLUDE
+#endif
        b       reset
 #ifdef CONFIG_PRELOADER
 /* No exception handlers in preloader */