mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* imx-image & i.MX35
@ 2014-09-22 22:22 Eric Bénard
  2014-09-23  6:25 ` Sascha Hauer
  0 siblings, 1 reply; 2+ messages in thread
From: Eric Bénard @ 2014-09-22 22:22 UTC (permalink / raw)
  To: barebox

Hi,

I didn't manage to get an image to boot on i.MX35 (internal boot on
NAND) with current imx-image and 2014.09.0.

From the i.MX35 user manual :
Since MLC NAND Flash devices do not guarantee error-free boot blocks,
the i.MX35 boot code requires that the first 4 Kbytes of boot code be
duplicated in a subsequent block to serve as a second copy option.

Actually imx-image puts the image at 4k but it seems that the i.MX35
bootrom copies only from 8k as it expects that there is a copy of the
first 0-4k in 4k-8k (and is supposed to use this copy if there is an
ECC error in the first 4k) as we can see in the following lines :

barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x0   
00000000: ea0003fe eafffffe eafffffe eafffffe                ................
00000010: eafffffe eafffffe eafffffe eafffffe                ................
00000020: 65726162 00786f62 00000000 00000000
barebox.........

=-> header is @ 0 in flash

barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x1000
00001000: 56341200 00000000 0001eda1 00000000                ..4V............
00001010: 00000000 00000000 00000000
00000000                ................

=-> so we have data @ 0x1000 in flash

barebox@Eukrea CPUIMX35:/  md 0x87f00000
87f00000: 00000000 00000000 00000000 00000000                ................
87f00010: 00000000 00000000 00000000
00000000                ................

=-> but we don't find this data in RAM

barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x2000
00002000: ea000012 eafffffe eafffffe eafffffe                ................
00002010: eafffffe eafffffe eafffffe eafffffe                ................
00002020: 65726162 00786f62 00000000 00034272
barebox.....rB..

=-> so we have the image @ 0x2000 in flash

barebox@Eukrea CPUIMX35:/  md 0x87f01000          
87f01000: ea000871 eafffffe eafffffe eafffffe                q...............
87f01010: eafffffe eafffffe eafffffe eafffffe                ................
87f01020: 65726162 00786f62 87f02000 0003b520                barebox.. .. ...

=-> and we find it in RAM

This patch fix the problem, how should this be hanled in imx-image ?

diff --git a/scripts/imx/imx-image.c b/scripts/imx/imx-image.c
index 3a25c09..f908069 100644
--- a/scripts/imx/imx-image.c
+++ b/scripts/imx/imx-image.c
@@ -761,7 +761,7 @@ int main(int argc, char *argv[])
                exit(1);
        }
 
-       ret = xwrite(outfd, buf, 4096);
+       ret = xwrite(outfd, buf, 8192);
        if (ret < 0) {
                perror("write");
                exit(1);
@@ -774,7 +774,7 @@ int main(int argc, char *argv[])
        }
 
        while (image_size) {
-               int now = image_size < 4096 ? image_size : 4096;
+               int now = image_size < 8192 ? image_size : 8192;
 
                ret = xread(infd, buf, now);
                if (ret) {

Eric

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: imx-image & i.MX35
  2014-09-22 22:22 imx-image & i.MX35 Eric Bénard
@ 2014-09-23  6:25 ` Sascha Hauer
  0 siblings, 0 replies; 2+ messages in thread
From: Sascha Hauer @ 2014-09-23  6:25 UTC (permalink / raw)
  To: Eric Bénard; +Cc: barebox

On Tue, Sep 23, 2014 at 12:22:15AM +0200, Eric Bénard wrote:
> Hi,
> 
> I didn't manage to get an image to boot on i.MX35 (internal boot on
> NAND) with current imx-image and 2014.09.0.
> 
> From the i.MX35 user manual :
> Since MLC NAND Flash devices do not guarantee error-free boot blocks,
> the i.MX35 boot code requires that the first 4 Kbytes of boot code be
> duplicated in a subsequent block to serve as a second copy option.
> 
> Actually imx-image puts the image at 4k but it seems that the i.MX35
> bootrom copies only from 8k as it expects that there is a copy of the
> first 0-4k in 4k-8k (and is supposed to use this copy if there is an
> ECC error in the first 4k) as we can see in the following lines :
> 
> barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x0   
> 00000000: ea0003fe eafffffe eafffffe eafffffe                ................
> 00000010: eafffffe eafffffe eafffffe eafffffe                ................
> 00000020: 65726162 00786f62 00000000 00000000
> barebox.........
> 
> =-> header is @ 0 in flash
> 
> barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x1000
> 00001000: 56341200 00000000 0001eda1 00000000                ..4V............
> 00001010: 00000000 00000000 00000000
> 00000000                ................
> 
> =-> so we have data @ 0x1000 in flash
> 
> barebox@Eukrea CPUIMX35:/  md 0x87f00000
> 87f00000: 00000000 00000000 00000000 00000000                ................
> 87f00010: 00000000 00000000 00000000
> 00000000                ................
> 
> =-> but we don't find this data in RAM
> 
> barebox@Eukrea CPUIMX35:/  md -s /dev/nand0 0x2000
> 00002000: ea000012 eafffffe eafffffe eafffffe                ................
> 00002010: eafffffe eafffffe eafffffe eafffffe                ................
> 00002020: 65726162 00786f62 00000000 00034272
> barebox.....rB..
> 
> =-> so we have the image @ 0x2000 in flash
> 
> barebox@Eukrea CPUIMX35:/  md 0x87f01000          
> 87f01000: ea000871 eafffffe eafffffe eafffffe                q...............
> 87f01010: eafffffe eafffffe eafffffe eafffffe                ................
> 87f01020: 65726162 00786f62 87f02000 0003b520                barebox.. .. ...
> 
> =-> and we find it in RAM
> 
> This patch fix the problem, how should this be hanled in imx-image ?

We know the SoC type in imx-image, so it should be possible to limit the
changes to i.MX35 only. The question is whether it's possible to create
an image which works on i.MX35 NAND but also for other mediums like
MMC/SD.
What if we duplicate the header in the image, but limit it to i.MX35.
Does the resulting image still work with MMC/SD and USB?

> 
> diff --git a/scripts/imx/imx-image.c b/scripts/imx/imx-image.c
> index 3a25c09..f908069 100644
> --- a/scripts/imx/imx-image.c
> +++ b/scripts/imx/imx-image.c
> @@ -761,7 +761,7 @@ int main(int argc, char *argv[])
>                 exit(1);
>         }
>  
> -       ret = xwrite(outfd, buf, 4096);
> +       ret = xwrite(outfd, buf, 8192);

Shouldn't this be:

	xwrite(outfd, buf, 4096);
	xwrite(outfd, buf, 4096);

>         if (ret < 0) {
>                 perror("write");
>                 exit(1);
> @@ -774,7 +774,7 @@ int main(int argc, char *argv[])
>         }
>  
>         while (image_size) {
> -               int now = image_size < 4096 ? image_size : 4096;
> +               int now = image_size < 8192 ? image_size : 8192;

this can be dropped, right?

Beware 'buf' has only 4096 bytes allocated.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-09-23  6:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-22 22:22 imx-image & i.MX35 Eric Bénard
2014-09-23  6:25 ` Sascha Hauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox