| Message ID | 4E16276C.3080303@bluewatersys.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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 >
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
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
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
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
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
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
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
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
--- 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 */