Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hello Stefan,
On Tue, 14 Jul 2015 12:29:52 +0200, Stefan Agner ste...@agner.ch
wrote:
Hi Stefano,
On 2015-07-10 10:14, Stefano Babic wrote:
On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
imximage header size is 4-byte, not 8-byte aligned.
This produces .imx images that a Vybrid cannot boot
on.
Fix by adding a padding field in header.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 36fe095..a913329 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -129,6 +129,7 @@ typedef struct {
ivt_header_t header;
write_dcd_command_t write_dcd_command;
dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
+ uint32_t padding[1]; /* end up on an 8-byte boundary */
} dcd_v2_t;
typedef struct {
Applied to u-boot-imx, thanks !
Sorry, just stumbled over this message now.
We discussed exactly this issue already more than a year ago, see:
http://lists.denx.de/pipermail/u-boot/2014-April/177580.html
Back then you asked whether I asked Freescale about it. Earlier this
year I tried to get hold of that issue and asked Freescale on Community,
see:
https://community.freescale.com/thread/355161
However, no official confirmation or explanation so far.
I think my patch back then solves the issue nicer. The struct dcd_v2_t
is not the reason the whole header is not aligned by 8-byte, it is a
problem of the boot_data_t header which is 12 bytes long. So inserting
the padding just after struct boot_data_t (or inside of struct
boot_data_t) seems to be more appropriate.
After reading the U-Boot and Freescale discussions, IIUC you have come
to the conclusion that the missing 4 bytes were in boot_data_t because
it was the only structure in the header which was not 8-bytes-aligned.
However, the available documentation does not specify this constraint,
and from a more experimental vewpoint, my patch adds 4 bytes at the end
of the overall header, thus leaving boot data at 12 bytes (therefore
leaving the dcd_table not 8-byte-aligned) and yet Vybrid can boot.
To me, this proves that the size alignment problem is not with
boot_data_t but with the overall header.
Aside:
My own hypothesis on the reason for the non-written 8-byte-alignment
requirement is that the ROM code initially loads the NAND sector
containing the header at some fixed address then calls some function to
copy the header just below the image destination address, and that
function is 'optimized' to use 8-byte chunks (probably because it
only had two free regs for ldm/stm) and thus assumes an 8 bytes header
size, and nobody cared to document (or possibly even realized the
existence of) that assumption.
--
Stefan
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hello Stefano, On Wed, 15 Jul 2015 09:19:55 +0200, Stefano Babic sba...@denx.de wrote: I think my patch back then solves the issue nicer. The struct dcd_v2_t is not the reason the whole header is not aligned by 8-byte, it is a problem of the boot_data_t header which is 12 bytes long. So inserting the padding just after struct boot_data_t (or inside of struct boot_data_t) seems to be more appropriate. I see. Albert, can you test on your board if Stefan's patch solves your issue, too ? I could then revert this one and apply Stefan's. I can test it, but I'm sure that boot data does not need size alignment since in my case there is no such alignment and Vybrid boots. To me this means aligning boot_data_t size would introduce a constraint that is not really there. If Stefan would test my patch as well, I reckon he would find it to work as well as his. So we have two patches which fix Vybrid booting: - one which aligns the boot_data_t /size/ but keeps its /offset/ unaligned; - one which aligns the the boot_data_t /offset/ but keeps its /size/ unaligned. 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? It remains doubious how the ROMs on Freescale are interpretating the header, but we can only test it. See my other answer. We could prove it by disassembling the ROM code. Any volunteer? :) Best regards, Stefano Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hi Stefan, On 14/07/2015 12:29, Stefan Agner wrote: Applied to u-boot-imx, thanks ! Sorry, just stumbled over this message now. We discussed exactly this issue already more than a year ago, see: http://lists.denx.de/pipermail/u-boot/2014-April/177580.html I admit that I have forgotten itthanks to revive it ! Back then you asked whether I asked Freescale about it. Earlier this year I tried to get hold of that issue and asked Freescale on Community, see: https://community.freescale.com/thread/355161 However, no official confirmation or explanation so far. I think my patch back then solves the issue nicer. The struct dcd_v2_t is not the reason the whole header is not aligned by 8-byte, it is a problem of the boot_data_t header which is 12 bytes long. So inserting the padding just after struct boot_data_t (or inside of struct boot_data_t) seems to be more appropriate. I see. Albert, can you test on your board if Stefan's patch solves your issue, too ? I could then revert this one and apply Stefan's. It remains doubious how the ROMs on Freescale are interpretating the header, but we can only test it. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hi Albert,
On 2015-07-15 09:54, Albert ARIBAUD wrote:
Hello Stefano,
On Wed, 15 Jul 2015 09:19:55 +0200, Stefano Babic sba...@denx.de
wrote:
I think my patch back then solves the issue nicer. The struct dcd_v2_t
is not the reason the whole header is not aligned by 8-byte, it is a
problem of the boot_data_t header which is 12 bytes long. So inserting
the padding just after struct boot_data_t (or inside of struct
boot_data_t) seems to be more appropriate.
I see. Albert, can you test on your board if Stefan's patch solves your
issue, too ? I could then revert this one and apply Stefan's.
I can test it, but I'm sure that boot data does not need size alignment
since in my case there is no such alignment and Vybrid boots. To me
this means aligning boot_data_t size would introduce a constraint that
is not really there.
I quote here from both emails, since its about the same topic.
After reading the U-Boot and Freescale discussions, IIUC you have come
to the conclusion that the missing 4 bytes were in boot_data_t because
it was the only structure in the header which was not 8-bytes-aligned.
However, the available documentation does not specify this constraint,
and from a more experimental vewpoint, my patch adds 4 bytes at the end
of the overall header, thus leaving boot data at 12 bytes (therefore
leaving the dcd_table not 8-byte-aligned) and yet Vybrid can boot.
Yes, I agree on that. Also the boot data seems not to have the 8-byte
alignment requirement (see the graphics I posted on the Freescale
community article).
To me, this proves that the size alignment problem is not with
boot_data_t but with the overall header.
I agree. Still, boot_data_t is the offender, hence I would prefer that
solution over your solution.
If Stefan would test my patch as well, I reckon he would find it to
work as well as his.
So we have two patches which fix Vybrid booting:
- one which aligns the boot_data_t /size/ but keeps its /offset/
unaligned;
- one which aligns the the boot_data_t /offset/ but keeps its /size/
unaligned.
I don't get this classification. The complete header struct shows that
dcd_v2_t is _after_ boot_data_t.
typedef struct {
flash_header_v2_t fhdr;
boot_data_t boot_data;
dcd_v2_t dcd_table;
} imx_header_v2_t;
Your patch changes the size of dcd_v2_t, hence compensating the
unaligned size of boot_data_t.
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.
It remains doubious how the ROMs on Freescale are interpretating the
header, but we can only test it.
See my other answer. We could prove it by disassembling the ROM code.
Any volunteer? :)
Hehe, not me :-)
--
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hello Stefan (and sorry for the duplicate),
On Wed, 15 Jul 2015 12:41:59 +0200, Stefan Agner ste...@agner.ch
wrote:
Hi Albert,
On 2015-07-15 09:54, Albert ARIBAUD wrote:
Hello Stefano,
On Wed, 15 Jul 2015 09:19:55 +0200, Stefano Babic sba...@denx.de
wrote:
I think my patch back then solves the issue nicer. The struct dcd_v2_t
is not the reason the whole header is not aligned by 8-byte, it is a
problem of the boot_data_t header which is 12 bytes long. So inserting
the padding just after struct boot_data_t (or inside of struct
boot_data_t) seems to be more appropriate.
I see. Albert, can you test on your board if Stefan's patch solves your
issue, too ? I could then revert this one and apply Stefan's.
I can test it, but I'm sure that boot data does not need size alignment
since in my case there is no such alignment and Vybrid boots. To me
this means aligning boot_data_t size would introduce a constraint that
is not really there.
I quote here from both emails, since its about the same topic.
After reading the U-Boot and Freescale discussions, IIUC you have come
to the conclusion that the missing 4 bytes were in boot_data_t because
it was the only structure in the header which was not 8-bytes-aligned.
However, the available documentation does not specify this constraint,
and from a more experimental vewpoint, my patch adds 4 bytes at the end
of the overall header, thus leaving boot data at 12 bytes (therefore
leaving the dcd_table not 8-byte-aligned) and yet Vybrid can boot.
Yes, I agree on that. Also the boot data seems not to have the 8-byte
alignment requirement (see the graphics I posted on the Freescale
community article).
To me, this proves that the size alignment problem is not with
boot_data_t but with the overall header.
I agree. Still, boot_data_t is the offender, hence I would prefer that
solution over your solution.
If Stefan would test my patch as well, I reckon he would find it to
work as well as his.
So we have two patches which fix Vybrid booting:
- one which aligns the boot_data_t /size/ but keeps its /offset/
unaligned;
- one which aligns the the boot_data_t /offset/ but keeps its /size/
unaligned.
I don't get this classification. The complete header struct shows that
dcd_v2_t is _after_ boot_data_t.
typedef struct {
flash_header_v2_t fhdr;
boot_data_t boot_data;
dcd_v2_t dcd_table;
} imx_header_v2_t;
Your patch changes the size of dcd_v2_t, hence compensating the
unaligned size of boot_data_t.
Compensating the unaligned size of the overall header for sure, since
I'm adding a last field in the last structure. But precisely since I'm
adding 4 bytes at the very end of the construct, we cannot tell whether
I fixed the 'size' of the flash header, boot data or DCD.
What we can tell, though, is that Vybrid will boot as long as we
increase the size of the overall header to an 8-byte boundary, and also
that it will boot regardless to whether these 4 bytes are added between
boot data and DCD or after DCD.
(note, btw, that in the Vybrid RM, the IVT itself, and the DCD, contain
their own size explicitly in their tag-length-version headers, but the
boot data does not contain its own size, nor is it contained elsewhere.
What we call 'the size of the boot data' is 'the difference between the
boot data and dcd addresses', but that's a definition for convenience.)
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.
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;
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
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
On 2015-07-15 13:44, Albert ARIBAUD wrote:
Hello Stefan (and sorry for the duplicate),
On Wed, 15 Jul 2015 12:41:59 +0200, Stefan Agner ste...@agner.ch
wrote:
Hi Albert,
On 2015-07-15 09:54, Albert ARIBAUD wrote:
Hello Stefano,
On Wed, 15 Jul 2015 09:19:55 +0200, Stefano Babic sba...@denx.de
wrote:
I think my patch back then solves the issue nicer. The struct dcd_v2_t
is not the reason the whole header is not aligned by 8-byte, it is a
problem of the boot_data_t header which is 12 bytes long. So inserting
the padding just after struct boot_data_t (or inside of struct
boot_data_t) seems to be more appropriate.
I see. Albert, can you test on your board if Stefan's patch solves your
issue, too ? I could then revert this one and apply Stefan's.
I can test it, but I'm sure that boot data does not need size alignment
since in my case there is no such alignment and Vybrid boots. To me
this means aligning boot_data_t size would introduce a constraint that
is not really there.
I quote here from both emails, since its about the same topic.
After reading the U-Boot and Freescale discussions, IIUC you have come
to the conclusion that the missing 4 bytes were in boot_data_t because
it was the only structure in the header which was not 8-bytes-aligned.
However, the available documentation does not specify this constraint,
and from a more experimental vewpoint, my patch adds 4 bytes at the end
of the overall header, thus leaving boot data at 12 bytes (therefore
leaving the dcd_table not 8-byte-aligned) and yet Vybrid can boot.
Yes, I agree on that. Also the boot data seems not to have the 8-byte
alignment requirement (see the graphics I posted on the Freescale
community article).
To me, this proves that the size alignment problem is not with
boot_data_t but with the overall header.
I agree. Still, boot_data_t is the offender, hence I would prefer that
solution over your solution.
If Stefan would test my patch as well, I reckon he would find it to
work as well as his.
So we have two patches which fix Vybrid booting:
- one which aligns the boot_data_t /size/ but keeps its /offset/
unaligned;
- one which aligns the the boot_data_t /offset/ but keeps its /size/
unaligned.
I don't get this classification. The complete header struct shows that
dcd_v2_t is _after_ boot_data_t.
typedef struct {
flash_header_v2_t fhdr;
boot_data_t boot_data;
dcd_v2_t dcd_table;
} imx_header_v2_t;
Your patch changes the size of dcd_v2_t, hence compensating the
unaligned size of boot_data_t.
Compensating the unaligned size of the overall header for sure, since
I'm adding a last field in the last structure. But precisely since I'm
adding 4 bytes at the very end of the construct, we cannot tell whether
I fixed the 'size' of the flash header, boot data or DCD.
What we can tell, though, is that Vybrid will boot as long as we
increase the size of the overall header to an 8-byte boundary, and also
that it will boot regardless to whether these 4 bytes are added between
boot data and DCD or after DCD.
(note, btw, that in the Vybrid RM, the IVT itself, and the DCD, contain
their own size explicitly in their tag-length-version headers, but the
boot data does not contain its own size, nor is it contained elsewhere.
What we call 'the size of the boot data' is 'the difference between the
boot data and dcd addresses', but that's a definition for convenience.)
Good point, agreed.
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.
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
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hello Stefan,
On Wed, 15 Jul 2015 14:36:16 +0200, Stefan Agner ste...@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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
Hi Stefano,
On 2015-07-10 10:14, Stefano Babic wrote:
On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
imximage header size is 4-byte, not 8-byte aligned.
This produces .imx images that a Vybrid cannot boot
on.
Fix by adding a padding field in header.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 36fe095..a913329 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -129,6 +129,7 @@ typedef struct {
ivt_header_t header;
write_dcd_command_t write_dcd_command;
dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
+uint32_t padding[1]; /* end up on an 8-byte boundary */
} dcd_v2_t;
typedef struct {
Applied to u-boot-imx, thanks !
Sorry, just stumbled over this message now.
We discussed exactly this issue already more than a year ago, see:
http://lists.denx.de/pipermail/u-boot/2014-April/177580.html
Back then you asked whether I asked Freescale about it. Earlier this
year I tried to get hold of that issue and asked Freescale on Community,
see:
https://community.freescale.com/thread/355161
However, no official confirmation or explanation so far.
I think my patch back then solves the issue nicer. The struct dcd_v2_t
is not the reason the whole header is not aligned by 8-byte, it is a
problem of the boot_data_t header which is 12 bytes long. So inserting
the padding just after struct boot_data_t (or inside of struct
boot_data_t) seems to be more appropriate.
--
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
On 19/06/2015 14:18, Albert ARIBAUD (3ADEV) wrote:
imximage header size is 4-byte, not 8-byte aligned.
This produces .imx images that a Vybrid cannot boot
on.
Fix by adding a padding field in header.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 36fe095..a913329 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -129,6 +129,7 @@ typedef struct {
ivt_header_t header;
write_dcd_command_t write_dcd_command;
dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
+ uint32_t padding[1]; /* end up on an 8-byte boundary */
} dcd_v2_t;
typedef struct {
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
imximage header size is 4-byte, not 8-byte aligned.
This produces .imx images that a Vybrid cannot boot
on.
Fix by adding a padding field in header.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 36fe095..a913329 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -129,6 +129,7 @@ typedef struct {
ivt_header_t header;
write_dcd_command_t write_dcd_command;
dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
+ uint32_t padding[1]; /* end up on an 8-byte boundary */
} dcd_v2_t;
typedef struct {
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
