[U-Boot-Users] Multi-file problem

[U-Boot-Users] Multi-file problem

[Rick Bronson]

Hi,

  I found a problem with Mutli-file use of mkimage (using "-T multi")
and fixed in my old u-boot-0.4.0 but my fix seemed to filter through
too many files when I tried to do it (more correctly) on the cvs tree.

  Here's the problem (using 21-Oct-03 cvs files):

  When this address in cmd_bootm.c:1122 inside print_image_hdr() (is
caculated: 

		ulong *len_ptr = (ulong *)((ulong)hdr + sizeof(image_header_t));

  it points to memory that wasn't copied back on cmd_bootm.c:174:

	memmove (&header, (char *)addr, sizeof(image_header_t));

  because len_ptr points to the address header[1] and the memmove only
moved header[0].  So I changed line 140 to:

image_header_t header[2];  /* enough room for multi-image's size bytes too */

  and all occurances of memmove (&header... from:

	memmove (&header, (char *)addr, sizeof(image_header_t));
  to:
	memmove (&header, (char *)addr, sizeof(header));

  But cmd_autoscript.c,common_util.c, armlinux.c uses &header and I'm
not sure if this is the right fix.  Maybe someone who knows this
stuff can give me some direction.

  Thanks much.

  Rick

[U-Boot-Users] Multi-file problem

[Detlev Zundel]

Hi Rick,

>   I found a problem with Mutli-file use of mkimage (using "-T multi")
> and fixed in my old u-boot-0.4.0 but my fix seemed to filter through
> too many files when I tried to do it (more correctly) on the cvs tree.
>
>   Here's the problem (using 21-Oct-03 cvs files):
>
>   When this address in cmd_bootm.c:1122 inside print_image_hdr() (is
> caculated:
>
> 		ulong *len_ptr = (ulong *)((ulong)hdr + sizeof(image_header_t));
>
>   it points to memory that wasn't copied back on cmd_bootm.c:174:
>
> 	memmove (&header, (char *)addr, sizeof(image_header_t));
>
>   because len_ptr points to the address header[1] and the memmove only
> moved header[0].  So I changed line 140 to:
>
> image_header_t header[2];  /* enough room for multi-image's size bytes too */
>
>   and all occurances of memmove (&header... from:
>
> 	memmove (&header, (char *)addr, sizeof(image_header_t));
>   to:
> 	memmove (&header, (char *)addr, sizeof(header));
>
>   But cmd_autoscript.c,common_util.c, armlinux.c uses &header and I'm
> not sure if this is the right fix.  Maybe someone who knows this
> stuff can give me some direction.

In a standard setup, the copying into ram is only done so we can
recalculate the header checksum and compare it to the original value.
If you simply want to print the header information (as iminfo does -
cf. image_info()) a pointer to the flash location will do just as
well.  I have to admit that I do not fully understand the
HAVE_DATAFLASH code so I cannot comment on this situation but apart
from that you could try replacing the

	/* for multi-file images we need the data part, too */
	print_image_hdr (hdr);

with

	/* for multi-file images we need the data part, too */
	print_image_hdr (addr);

If this works, then it surely is less intrusive than your patch.

Cheers
  Detlev

-- 
I haven't lost my mind, I know exactly where I left it.

[U-Boot-Users] Multi-file problem

[Rick Bronson]

Hi Detlev,

  I actually thought about the fix you recommended but I noticed the
hdr struct was being written to before calling the print_image_hdr()
routine so I was a little hesitant.  But I tried it, and it seems to
work okay.  Did you want a diff file or shouldn't I bother for one
line:

	print_image_hdr ((image_header_t *) addr);  /* don't pass hdr, we look past it */

  Thanks for your help.

 Rick

> Hi Rick,
> 
> >   I found a problem with Mutli-file use of mkimage (using "-T multi")
> > and fixed in my old u-boot-0.4.0 but my fix seemed to filter through
> > too many files when I tried to do it (more correctly) on the cvs tree.
> >
> >   Here's the problem (using 21-Oct-03 cvs files):
> >
> >   When this address in cmd_bootm.c:1122 inside print_image_hdr() (is
> > caculated:
> >
> > 		ulong *len_ptr = (ulong *)((ulong)hdr + sizeof(image_header_t));
> >
> >   it points to memory that wasn't copied back on cmd_bootm.c:174:
> >
> > 	memmove (&header, (char *)addr, sizeof(image_header_t));
> >
> >   because len_ptr points to the address header[1] and the memmove only
> > moved header[0].  So I changed line 140 to:
> >
> > image_header_t header[2];  /* enough room for multi-image's size bytes too */
> >
> >   and all occurances of memmove (&header... from:
> >
> > 	memmove (&header, (char *)addr, sizeof(image_header_t));
> >   to:
> > 	memmove (&header, (char *)addr, sizeof(header));
> >
> >   But cmd_autoscript.c,common_util.c, armlinux.c uses &header and I'm
> > not sure if this is the right fix.  Maybe someone who knows this
> > stuff can give me some direction.
> 
> In a standard setup, the copying into ram is only done so we can
> recalculate the header checksum and compare it to the original value.
> If you simply want to print the header information (as iminfo does -
> cf. image_info()) a pointer to the flash location will do just as
> well.  I have to admit that I do not fully understand the
> HAVE_DATAFLASH code so I cannot comment on this situation but apart
> from that you could try replacing the
> 
> 	/* for multi-file images we need the data part, too */
> 	print_image_hdr (hdr);
> 
> with
> 
> 	/* for multi-file images we need the data part, too */
> 	print_image_hdr (addr);
> 
> If this works, then it surely is less intrusive than your patch.
> 
> Cheers
>   Detlev
> 
> -- 
> I haven't lost my mind, I know exactly where I left it.
> 
> 

[U-Boot-Users] Multi-file problem

[Detlev Zundel]

Hi Nick,

>   I actually thought about the fix you recommended but I noticed the
> hdr struct was being written to before calling the print_image_hdr()
> routine so I was a little hesitant.  

This is only for re-calculating the header checksum and comparing it
to the original - nothing to worry about.

> But I tried it, and it seems to work okay.  Did you want a diff file
> or shouldn't I bother for one line:
>
> 	print_image_hdr ((image_header_t *) addr);  /* don't pass hdr, we look past it */

Thanks for verifying that it works for you too.  In that case I'll add
it to CVS as soon as possible.

Cheers
  Detlev

-- 
five monkeys, two typewriters, ten minutes

[U-Boot-Users] Multi-file problem

[Detlev Zundel]

>Hi Nick,

Sorry, I meant to write Rick but some synapses must have
short-circuited somehow ;)

Cheers
  Detlev

-- 
five monkeys, two typewriters, ten minutes