* DTC: unaligned memory offset in FIT image
@ 2017-07-20 8:28 DHANAPAL, GNANACHANDRAN (G.)
[not found] ` <VI1PR06MB1599BC212592810ABBE36E2D82A70-8LfwjTntTp1Wb/rYCsWsVK71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: DHANAPAL, GNANACHANDRAN (G.) @ 2017-07-20 8:28 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org,
jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.),
Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.),
CN, Aananth (A.A.),
'gnanachandran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org'
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
Resending this mail presuming previous mail was lost
Hi There,
In our R-car H3 based customized automotive product, we are using U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file system provided by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with following boot log.
reading fitImage_monarch
6627756 bytes read in 299 ms (21.1 MiB/s) ## Loading kernel from FIT Image at 4c000000 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x4c000114
Data Size: 6557502 Bytes = 6.3 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x48080000
Entry Point: 0x48080000
Hash algo: sha1
Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75
Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image at 4c000000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x4c64114c
Data Size: 68887 Bytes = 67.3 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x4c64114c
Uncompressing Kernel Image ... OK
"Synchronous Abort" handler, esr 0x96000021
ELR: 50029550
LR: 5001117c
x0 : 0000000000000000 x1 : 000000004c64117c
x2 : 0000000000000011 x3 : 0000000000000009
x4 : 0000000000000000 x5 : 0000000050038eed
x6 : 0000000000000002 x7 : 000000005005aa98
x8 : 0000000000000000 x9 : 00000000ffffffff
x10: 0000000048e2ba00 x11: 0000000000000001
x12: 0000000000000060 x13: 00000000000001ff
x14: 000000000000003f x15: 000000007fe61670
x16: 000000007fe61e70 x17: 0000000100000000
x18: 000000007fe5ae20 x19: 0000000000000000
x20: 000000004c64114c x21: 000000005003e3db
x22: 000000005005a898 x23: 000000005005a9d8
x24: 0000000000000000 x25: 000000005004e5f0
x26: 000000004c000114 x27: 00000000500018b0
x28: 0000000048080000 x29: 000000007fe5a580
Resetting CPU ...
From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned.
DTC that generates the FIT image doesn't align FIT description text (shown below) hence offset of kernel and DTC are moved to Non 64 bit align address
description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2";
#address-cells = <1>;
String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly.
Please find the attached .its file used for FIT image creation
In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17.
if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8))
emit->align(etarget, 8);
May I know reason why FTF_VARALIGN is skipped for version 17 or Is there other way this can be handle in latest DTC.
Cheers
Gnana
[-- Attachment #2: fit-image.its --]
[-- Type: application/octet-stream, Size: 1458 bytes --]
/dts-v1/;
/ {
description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux kernel";
data = /incbin/("./linux.bin");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x48080000>;
entry = <0x48080000>;
hash@1 {
algo = "sha1";
};
};
fdt@1 {
description = "Flattened Device Tree blob";
data = /incbin/("./r8a7795-smartcore2.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
hash@1 {
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1 {
description = "Boot Linux kernel with FDT blob";
kernel = "kernel@1";
fdt = "fdt@1";
hash@1 {
algo = "sha1";
};
};
};
};
^ permalink raw reply [flat|nested] 6+ messages in thread[parent not found: <VI1PR06MB1599BC212592810ABBE36E2D82A70-8LfwjTntTp1Wb/rYCsWsVK71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* Re: DTC: unaligned memory offset in FIT image [not found] ` <VI1PR06MB1599BC212592810ABBE36E2D82A70-8LfwjTntTp1Wb/rYCsWsVK71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> @ 2017-07-20 13:34 ` david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+ [not found] ` <20170720133443.GB3140-K0bRW+63XPQe6aEkudXLsA@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+ @ 2017-07-20 13:34 UTC (permalink / raw) To: DHANAPAL, GNANACHANDRAN (G.) Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.), Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.), CN, Aananth (A.A.), 'gnanachandran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org' [-- Attachment #1: Type: text/plain, Size: 4790 bytes --] On Thu, Jul 20, 2017 at 08:28:28AM +0000, DHANAPAL, GNANACHANDRAN (G.) wrote: > Resending this mail presuming previous mail was lost I'm not sure why you're presuming that. I got it fine, just hadn't had a chance to reply yet. > Hi There, > > In our R-car H3 based customized automotive product, we are using U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file system provided by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with following boot log. > > reading fitImage_monarch > 6627756 bytes read in 299 ms (21.1 MiB/s) ## Loading kernel from FIT Image at 4c000000 ... > Using 'conf@1' configuration > Trying 'kernel@1' kernel subimage > Description: Linux kernel > Type: Kernel Image > Compression: gzip compressed > Data Start: 0x4c000114 > Data Size: 6557502 Bytes = 6.3 MiB > Architecture: AArch64 > OS: Linux > Load Address: 0x48080000 > Entry Point: 0x48080000 > Hash algo: sha1 > Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75 > Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image at 4c000000 ... > Using 'conf@1' configuration > Trying 'fdt@1' fdt subimage > Description: Flattened Device Tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x4c64114c > Data Size: 68887 Bytes = 67.3 KiB > Architecture: AArch64 > Hash algo: sha1 > Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2 > Verifying Hash Integrity ... sha1+ OK > Booting using the fdt blob at 0x4c64114c > Uncompressing Kernel Image ... OK > "Synchronous Abort" handler, esr 0x96000021 > ELR: 50029550 > LR: 5001117c > x0 : 0000000000000000 x1 : 000000004c64117c > x2 : 0000000000000011 x3 : 0000000000000009 > x4 : 0000000000000000 x5 : 0000000050038eed > x6 : 0000000000000002 x7 : 000000005005aa98 > x8 : 0000000000000000 x9 : 00000000ffffffff > x10: 0000000048e2ba00 x11: 0000000000000001 > x12: 0000000000000060 x13: 00000000000001ff > x14: 000000000000003f x15: 000000007fe61670 > x16: 000000007fe61e70 x17: 0000000100000000 > x18: 000000007fe5ae20 x19: 0000000000000000 > x20: 000000004c64114c x21: 000000005003e3db > x22: 000000005005a898 x23: 000000005005a9d8 > x24: 0000000000000000 x25: 000000005004e5f0 > x26: 000000004c000114 x27: 00000000500018b0 > x28: 0000000048080000 x29: 000000007fe5a580 > > Resetting CPU ... > > > >From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned. > DTC that generates the FIT image doesn't align FIT description text (shown below) hence offset of kernel and DTC are moved to Non 64 bit align address > > description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2"; > #address-cells = <1>; > > String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly. > Please find the attached .its file used for FIT image creation > > In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17. > > if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8)) > emit->align(etarget, 8); > May I know reason why FTF_VARALIGN is skipped for version 17 or Is there other way this can be handle in latest DTC. Because that's how v16 and later are defined. Attempting to use FTF_VARALIGN on current versions would mean dtb clients wouldn't parse it correctly. The variable alignment generally wasn't worth the hassle. Properties are bytestrings and their internal encodings don't generally include alignment gaps. So, even if the start of the property is aligned, there's no guarantee that values within the property are aligned. It might be useful in the case of FIT (I hadn't realised until now that FITs were basically just dtbs with an embedded other dtb). And I guess it would be possible to align the relevent property through the use of FDT_NOP tags, though how to decide when to do that is a pretty vague question. Even then, of course, there's no guarantee that values within the inner dtb will be aligned. As a general rule it's best to write code working with dtbs so that's it's safe with any alignment. I realise that can be pretty awkward for ARM, though. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20170720133443.GB3140-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>]
* Re: DTC: unaligned memory offset in FIT image [not found] ` <20170720133443.GB3140-K0bRW+63XPQe6aEkudXLsA@public.gmane.org> @ 2017-07-20 14:55 ` Rob Herring 0 siblings, 0 replies; 6+ messages in thread From: Rob Herring @ 2017-07-20 14:55 UTC (permalink / raw) To: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org Cc: DHANAPAL, GNANACHANDRAN (G.), devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.), Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.), CN, Aananth (A.A.), gnanachandran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On Thu, Jul 20, 2017 at 8:34 AM, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote: > On Thu, Jul 20, 2017 at 08:28:28AM +0000, DHANAPAL, GNANACHANDRAN (G.) wrote: >> Resending this mail presuming previous mail was lost > > I'm not sure why you're presuming that. I got it fine, just hadn't > had a chance to reply yet. > >> Hi There, >> >> In our R-car H3 based customized automotive product, we are using U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file system provided by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with following boot log. >> >> reading fitImage_monarch >> 6627756 bytes read in 299 ms (21.1 MiB/s) ## Loading kernel from FIT Image at 4c000000 ... >> Using 'conf@1' configuration >> Trying 'kernel@1' kernel subimage >> Description: Linux kernel >> Type: Kernel Image >> Compression: gzip compressed >> Data Start: 0x4c000114 >> Data Size: 6557502 Bytes = 6.3 MiB >> Architecture: AArch64 >> OS: Linux >> Load Address: 0x48080000 >> Entry Point: 0x48080000 >> Hash algo: sha1 >> Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75 >> Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image at 4c000000 ... >> Using 'conf@1' configuration >> Trying 'fdt@1' fdt subimage >> Description: Flattened Device Tree blob >> Type: Flat Device Tree >> Compression: uncompressed >> Data Start: 0x4c64114c >> Data Size: 68887 Bytes = 67.3 KiB >> Architecture: AArch64 >> Hash algo: sha1 >> Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2 >> Verifying Hash Integrity ... sha1+ OK >> Booting using the fdt blob at 0x4c64114c >> Uncompressing Kernel Image ... OK >> "Synchronous Abort" handler, esr 0x96000021 >> ELR: 50029550 >> LR: 5001117c >> x0 : 0000000000000000 x1 : 000000004c64117c >> x2 : 0000000000000011 x3 : 0000000000000009 >> x4 : 0000000000000000 x5 : 0000000050038eed >> x6 : 0000000000000002 x7 : 000000005005aa98 >> x8 : 0000000000000000 x9 : 00000000ffffffff >> x10: 0000000048e2ba00 x11: 0000000000000001 >> x12: 0000000000000060 x13: 00000000000001ff >> x14: 000000000000003f x15: 000000007fe61670 >> x16: 000000007fe61e70 x17: 0000000100000000 >> x18: 000000007fe5ae20 x19: 0000000000000000 >> x20: 000000004c64114c x21: 000000005003e3db >> x22: 000000005005a898 x23: 000000005005a9d8 >> x24: 0000000000000000 x25: 000000005004e5f0 >> x26: 000000004c000114 x27: 00000000500018b0 >> x28: 0000000048080000 x29: 000000007fe5a580 >> >> Resetting CPU ... >> >> >> >From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned. >> DTC that generates the FIT image doesn't align FIT description text (shown below) hence offset of kernel and DTC are moved to Non 64 bit align address >> >> description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2"; >> #address-cells = <1>; >> >> String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly. >> Please find the attached .its file used for FIT image creation >> >> In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17. >> >> if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8)) >> emit->align(etarget, 8); > >> May I know reason why FTF_VARALIGN is skipped for version 17 or Is there other way this can be handle in latest DTC. > > Because that's how v16 and later are defined. Attempting to use > FTF_VARALIGN on current versions would mean dtb clients wouldn't parse > it correctly. The variable alignment generally wasn't worth the > hassle. Properties are bytestrings and their internal encodings don't > generally include alignment gaps. So, even if the start of the > property is aligned, there's no guarantee that values within the > property are aligned. > > It might be useful in the case of FIT (I hadn't realised until now > that FITs were basically just dtbs with an embedded other dtb). And I > guess it would be possible to align the relevent property through the > use of FDT_NOP tags, though how to decide when to do that is a pretty > vague question. Even then, of course, there's no guarantee that > values within the inner dtb will be aligned. > > As a general rule it's best to write code working with dtbs so that's > it's safe with any alignment. I realise that can be pretty awkward > for ARM, though. Modern ARM (v6+) supports unaligned accesses just fine. IIRC, u-boot does not and there was some debate about it, but that was a few years ago. Rob ^ permalink raw reply [flat|nested] 6+ messages in thread
* DTC: unaligned memory offset in FIT image
@ 2017-07-19 13:56 DHANAPAL, GNANACHANDRAN (G.)
[not found] ` <AM4PR06MB1588B92E62622B6F86973F8F82A60-6R4pi30f7lNSYviRaxpvLa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: DHANAPAL, GNANACHANDRAN (G.) @ 2017-07-19 13:56 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org,
jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.),
Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.),
CN, Aananth (A.A.)
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
Hi There,
In our R-car H3 based customized automotive product, we are using U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file system provided
by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with
following boot log.
reading fitImage_monarch
6627756 bytes read in 299 ms (21.1 MiB/s)
## Loading kernel from FIT Image at 4c000000 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x4c000114
Data Size: 6557502 Bytes = 6.3 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x48080000
Entry Point: 0x48080000
Hash algo: sha1
Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 4c000000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x4c64114c
Data Size: 68887 Bytes = 67.3 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x4c64114c
Uncompressing Kernel Image ... OK
"Synchronous Abort" handler, esr 0x96000021
ELR: 50029550
LR: 5001117c
x0 : 0000000000000000 x1 : 000000004c64117c
x2 : 0000000000000011 x3 : 0000000000000009
x4 : 0000000000000000 x5 : 0000000050038eed
x6 : 0000000000000002 x7 : 000000005005aa98
x8 : 0000000000000000 x9 : 00000000ffffffff
x10: 0000000048e2ba00 x11: 0000000000000001
x12: 0000000000000060 x13: 00000000000001ff
x14: 000000000000003f x15: 000000007fe61670
x16: 000000007fe61e70 x17: 0000000100000000
x18: 000000007fe5ae20 x19: 0000000000000000
x20: 000000004c64114c x21: 000000005003e3db
x22: 000000005005a898 x23: 000000005005a9d8
x24: 0000000000000000 x25: 000000005004e5f0
x26: 000000004c000114 x27: 00000000500018b0
x28: 0000000048080000 x29: 000000007fe5a580
Resetting CPU ...
From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned.
DTC that generates the FIT image doesn't align FIT description text (shown below) hence offset of kernel and DTC are moved to
Non 64 bit align address
description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2";
#address-cells = <1>;
String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly.
Please find the attached .its file used for FIT image creation
In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17.
if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8))
emit->align(etarget, 8);
May I know reason why FTF_VARALIGN is skipped for version 17 or
Is there other way this can be handle in latest DTC.
Cheers
Gnana
[-- Attachment #2: fit-image.its --]
[-- Type: application/octet-stream, Size: 1458 bytes --]
/dts-v1/;
/ {
description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux kernel";
data = /incbin/("./linux.bin");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x48080000>;
entry = <0x48080000>;
hash@1 {
algo = "sha1";
};
};
fdt@1 {
description = "Flattened Device Tree blob";
data = /incbin/("./r8a7795-smartcore2.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
hash@1 {
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1 {
description = "Boot Linux kernel with FDT blob";
kernel = "kernel@1";
fdt = "fdt@1";
hash@1 {
algo = "sha1";
};
};
};
};
^ permalink raw reply [flat|nested] 6+ messages in thread[parent not found: <AM4PR06MB1588B92E62622B6F86973F8F82A60-6R4pi30f7lNSYviRaxpvLa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* Re: DTC: unaligned memory offset in FIT image [not found] ` <AM4PR06MB1588B92E62622B6F86973F8F82A60-6R4pi30f7lNSYviRaxpvLa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> @ 2017-07-21 10:48 ` Simon Glass [not found] ` <CAPnjgZ3Bgyhg=dMVVtsqkC+14hM3rO9xS7Y4=pShBcL1iEurDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2017-07-21 10:48 UTC (permalink / raw) To: DHANAPAL, GNANACHANDRAN (G.) Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org, jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.), Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.), CN, Aananth (A.A.) Hi, On 19 July 2017 at 06:56, DHANAPAL, GNANACHANDRAN (G.) <gnanachandran.dhanapal-Vi+0cqmPEYlBDgjK7y7TUQ@public.gmane.org> wrote: > > Hi There, > > In our R-car H3 based customized automotive product, we are using U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file system provided > by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with > following boot log. > > reading fitImage_monarch > 6627756 bytes read in 299 ms (21.1 MiB/s) > ## Loading kernel from FIT Image at 4c000000 ... > Using 'conf@1' configuration > Trying 'kernel@1' kernel subimage > Description: Linux kernel > Type: Kernel Image > Compression: gzip compressed > Data Start: 0x4c000114 > Data Size: 6557502 Bytes = 6.3 MiB > Architecture: AArch64 > OS: Linux > Load Address: 0x48080000 > Entry Point: 0x48080000 > Hash algo: sha1 > Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75 > Verifying Hash Integrity ... sha1+ OK > ## Loading fdt from FIT Image at 4c000000 ... > Using 'conf@1' configuration > Trying 'fdt@1' fdt subimage > Description: Flattened Device Tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x4c64114c > Data Size: 68887 Bytes = 67.3 KiB > Architecture: AArch64 > Hash algo: sha1 > Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2 > Verifying Hash Integrity ... sha1+ OK > Booting using the fdt blob at 0x4c64114c > Uncompressing Kernel Image ... OK > "Synchronous Abort" handler, esr 0x96000021 > ELR: 50029550 > LR: 5001117c > x0 : 0000000000000000 x1 : 000000004c64117c > x2 : 0000000000000011 x3 : 0000000000000009 > x4 : 0000000000000000 x5 : 0000000050038eed > x6 : 0000000000000002 x7 : 000000005005aa98 > x8 : 0000000000000000 x9 : 00000000ffffffff > x10: 0000000048e2ba00 x11: 0000000000000001 > x12: 0000000000000060 x13: 00000000000001ff > x14: 000000000000003f x15: 000000007fe61670 > x16: 000000007fe61e70 x17: 0000000100000000 > x18: 000000007fe5ae20 x19: 0000000000000000 > x20: 000000004c64114c x21: 000000005003e3db > x22: 000000005005a898 x23: 000000005005a9d8 > x24: 0000000000000000 x25: 000000005004e5f0 > x26: 000000004c000114 x27: 00000000500018b0 > x28: 0000000048080000 x29: 000000007fe5a580 > > Resetting CPU ... > > > From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned. > DTC that generates the FIT image doesn't align FIT description text (shown below) hence offset of kernel and DTC are moved to > Non 64 bit align address > > description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2"; > #address-cells = <1>; > > String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly. > Please find the attached .its file used for FIT image creation > > In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17. > > if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8)) > emit->align(etarget, 8); > > > May I know reason why FTF_VARALIGN is skipped for version 17 or > Is there other way this can be handle in latest DTC. I suggest sending this to the U-Boot list since I don't think this is a dtc issue. The kernel should be loaded to the load address in your .its file, so I'm not sure why it is booting it directly from the FIT. > > > Cheers > Gnana Regards, Simon ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAPnjgZ3Bgyhg=dMVVtsqkC+14hM3rO9xS7Y4=pShBcL1iEurDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* RE: DTC: unaligned memory offset in FIT image [not found] ` <CAPnjgZ3Bgyhg=dMVVtsqkC+14hM3rO9xS7Y4=pShBcL1iEurDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2017-07-21 14:02 ` DHANAPAL, GNANACHANDRAN (G.) 0 siblings, 0 replies; 6+ messages in thread From: DHANAPAL, GNANACHANDRAN (G.) @ 2017-07-21 14:02 UTC (permalink / raw) To: Simon Glass Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org, jdl-CYoMK+44s/E@public.gmane.org, Babu, Viswanathan (V.), Ravindran, Madhusudhanan (M.), Gujulan Elango, Hari Prasath (H.), CN, Aananth (A.A.) Hello Simon, -----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: 21 July 2017 16:19 To: DHANAPAL, GNANACHANDRAN (G.) Cc: devicetree-compiler@vger.kernel.org; david@gibson.dropbear.id.au; jdl@jdl.com; Babu, Viswanathan (V.); Ravindran, Madhusudhanan (M.); Gujulan Elango, Hari Prasath (H.); CN, Aananth (A.A.) Subject: Re: DTC: unaligned memory offset in FIT image Hi, On 19 July 2017 at 06:56, DHANAPAL, GNANACHANDRAN (G.) <gnanachandran.dhanapal@visteon.com> wrote: > > Hi There, > > In our R-car H3 based customized automotive product, we are using > U-boot ( bootloader), FIT image (Linux kernel + DTB) and root file > system provided by Renesas provide BSP 2.16.0. FIT image has compressed Linux kernel and uncompressed DTB. While loading the FIT image, system reboot happens with following boot log. > > reading fitImage_monarch > 6627756 bytes read in 299 ms (21.1 MiB/s) ## Loading kernel from FIT > Image at 4c000000 ... > Using 'conf@1' configuration > Trying 'kernel@1' kernel subimage > Description: Linux kernel > Type: Kernel Image > Compression: gzip compressed > Data Start: 0x4c000114 > Data Size: 6557502 Bytes = 6.3 MiB > Architecture: AArch64 > OS: Linux > Load Address: 0x48080000 > Entry Point: 0x48080000 > Hash algo: sha1 > Hash value: 2638b7ad761ed7c70d9053908f274e5617e7ae75 > Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image > at 4c000000 ... > Using 'conf@1' configuration > Trying 'fdt@1' fdt subimage > Description: Flattened Device Tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x4c64114c > Data Size: 68887 Bytes = 67.3 KiB > Architecture: AArch64 > Hash algo: sha1 > Hash value: c29c2b38626b8af9cfd5c1b513a179fc6dcd1db2 > Verifying Hash Integrity ... sha1+ OK > Booting using the fdt blob at 0x4c64114c > Uncompressing Kernel Image ... OK > "Synchronous Abort" handler, esr 0x96000021 > ELR: 50029550 > LR: 5001117c > x0 : 0000000000000000 x1 : 000000004c64117c > x2 : 0000000000000011 x3 : 0000000000000009 > x4 : 0000000000000000 x5 : 0000000050038eed > x6 : 0000000000000002 x7 : 000000005005aa98 > x8 : 0000000000000000 x9 : 00000000ffffffff > x10: 0000000048e2ba00 x11: 0000000000000001 > x12: 0000000000000060 x13: 00000000000001ff > x14: 000000000000003f x15: 000000007fe61670 > x16: 000000007fe61e70 x17: 0000000100000000 > x18: 000000007fe5ae20 x19: 0000000000000000 > x20: 000000004c64114c x21: 000000005003e3db > x22: 000000005005a898 x23: 000000005005a9d8 > x24: 0000000000000000 x25: 000000005004e5f0 > x26: 000000004c000114 x27: 00000000500018b0 > x28: 0000000048080000 x29: 000000007fe5a580 > > Resetting CPU ... > > > From log, we observed that Data start address for both kernel (0x4C000114) and DTB (0x4c64114c) are not 64bit aligned. > DTC that generates the FIT image doesn't align FIT description text > (shown below) hence offset of kernel and DTC are moved to Non 64 bit > align address > > description = "U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9.0+gitAUTOINC+13e7680774/smartcore2"; > #address-cells = <1>; > > String len of description is 97 bytes. By changing this description length to multiple of 8, FIT image works properly. > Please find the attached .its file used for FIT image creation > > In DTC source code, function flatten_tree in file flattree.c, 8 bytes alignment is skipped for DTC version 17. > > if ((vi->flags & FTF_VARALIGN) && (prop->val.len >= 8)) > emit->align(etarget, 8); > > > May I know reason why FTF_VARALIGN is skipped for version 17 or Is > there other way this can be handle in latest DTC. I suggest sending this to the U-Boot list since I don't think this is a dtc issue. The kernel should be loaded to the load address in your .its file, so I'm not sure why it is booting it directly from the FIT. Gnana: As per the log, Before linux kernel relocated to the load address, Synchronous abort exception was triggered in U-boot while retrieving reserve memory entries in DTB. > > > Cheers > Gnana Regards, Simon Cheers Gnana ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-07-21 14:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-20 8:28 DTC: unaligned memory offset in FIT image DHANAPAL, GNANACHANDRAN (G.)
[not found] ` <VI1PR06MB1599BC212592810ABBE36E2D82A70-8LfwjTntTp1Wb/rYCsWsVK71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-07-20 13:34 ` david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
[not found] ` <20170720133443.GB3140-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-07-20 14:55 ` Rob Herring
-- strict thread matches above, loose matches on Subject: below --
2017-07-19 13:56 DHANAPAL, GNANACHANDRAN (G.)
[not found] ` <AM4PR06MB1588B92E62622B6F86973F8F82A60-6R4pi30f7lNSYviRaxpvLa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-07-21 10:48 ` Simon Glass
[not found] ` <CAPnjgZ3Bgyhg=dMVVtsqkC+14hM3rO9xS7Y4=pShBcL1iEurDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-21 14:02 ` DHANAPAL, GNANACHANDRAN (G.)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).