public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Date: Wed, 15 Jul 2015 14:54:55 +0200	[thread overview]
Message-ID: <20150715145455.4d71f33f@lilith> (raw)
In-Reply-To: <23c8142da99dbf70b335a0792c363641@agner.ch>

Hello Stefan,

On Wed, 15 Jul 2015 14:36:16 +0200, Stefan Agner <stefan@agner.ch>
wrote:

> >> As far as I see we have these two patches which fix Vybrid booting:
> >>
> >> - one which changes the boot_data_t /size/ which keeps the offset
> >>   of dcd_v2_t and the image aligned.
> >>
> >> - one which changes the dcd_v2_t /size/ which compensates the unaligned
> >>   size of boot_data_t and keeps the image aligned.
> >>
> >> > Seems to me that the conclusion is that the actual alignment of
> >> > boot_data_t does not matter and that only the alignment of the
> >> > whole imx_header_v2_t size (and, consequently, offset) matters.
> >> >
> >> > How about just adding an attribute((align(8))) to imx_header_v2_t?
> >>
> >> Hm this sounds tempting, but it does not seem to work here. I think
> >> because it only aligns the beginning of imx_header_v2_t in to 8-byte,
> >> however it does not align the size of the whole struct to 8 bytes, I
> >> guess? Hence the header size is still "unaligned".
> > 
> > Correct -- my fault, this aligns the address, not size, and there is
> > no attribute that will control size alignment.
> 
> Actually I just discovered that "aligned" also changes the size (make
> sure using the correct syntax "__attribute__((aligned(8)))").

Does it? Then I too was under the same misconception that it did not.

> However, imximage.c seems to do some calculations using sizeof(struct
> imx_header) and sizeof(imx_header_v2_t) which lead to this error
> message:
> ./tools/mkimage: header error
> 
> Adding __attribute__((aligned(8))) to struct imx_header seems not to
> alleviate the problem... Any idea?
>
> > So we really need to add manual padding.
> > 
> > And if we want to not introduce any artificial constaints, I suggest we
> > define the padding as a separate field in the overall structure, i.e.:
> > 
> > typedef struct {
> >         flash_header_v2_t fhdr;
> >         boot_data_t boot_data;
> >         dcd_v2_t dcd_table;
> > 	uint32_t padding; /* make size an 8-byte multiple */
> > } imx_header_v2_t;
> 
> That change would also sound good to me.
> 
> > 
> > I think this is the 'least inexact' solution: it does not enforce any
> > address or size alignment constraint that is not defined in the RM, and
> > it does show that the constraint is not on the boot data or DCD but on
> > the header as a whole.
> > 
> > Functionally, it is identical to what I did, so I'm pretty sure it
> > works. :)
> 
> Agreed.

Ok, so let me look into the __attribute__((aligned(8))) issue. If that
can be solved, I would give it my preference; if it cannot, then I will
settle for manually padding the end of imx_header_v2_t.

> --
> Stefan

Amicalement,
-- 
Albert.

  reply	other threads:[~2015-07-15 12:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 12:18 [U-Boot] [PATCH 0/5] Add support for Vybrid VF610-based PCM052 Albert ARIBAUD
2015-06-19 12:18 ` [U-Boot] [PATCH 1/5] net: fec_mxc: remove useless struct nbuf Albert ARIBAUD
2015-06-19 12:18   ` [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code Albert ARIBAUD
2015-06-19 12:18     ` [U-Boot] [PATCH 3/5] i2c: fix vf610 support Albert ARIBAUD
2015-06-19 12:18       ` [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size Albert ARIBAUD
2015-06-19 12:18         ` [U-Boot] [PATCH 5/5] vf610: add support for Phytec PCM052 Albert ARIBAUD
2015-07-10  8:14         ` [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size Stefano Babic
2015-07-14 10:29           ` Stefan Agner
2015-07-15  7:19             ` Stefano Babic
2015-07-15  7:54               ` Albert ARIBAUD
2015-07-15 10:41                 ` Stefan Agner
2015-07-15 11:44                   ` Albert ARIBAUD
2015-07-15 12:36                     ` Stefan Agner
2015-07-15 12:54                       ` Albert ARIBAUD [this message]
2015-07-15  7:37             ` Albert ARIBAUD
2015-07-10  8:11       ` [U-Boot] [PATCH 3/5] i2c: fix vf610 support Stefano Babic
2015-06-19 15:13     ` [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code Stefan Agner
2015-06-19 16:50       ` Albert ARIBAUD
2015-06-19 17:33       ` Albert ARIBAUD
2015-07-10  8:09         ` Stefano Babic
2015-07-13 19:01           ` Stefan Agner
2015-07-14  7:16             ` [U-Boot] (rather [LONG], sorry) " Albert ARIBAUD
2015-06-19 15:38   ` [U-Boot] [PATCH 1/5] net: fec_mxc: remove useless struct nbuf Joe Hershberger
2015-07-10  8:03   ` Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150715145455.4d71f33f@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox