[PATCH] spl: Align device tree blob address at 8-byte boundary
Since libfdt v1.6.1, a new requirement on the device tree address via:
commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()")
must be met that the device tree must be loaded in to memory at an 8-byte aligned address.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
common/spl/spl_fit.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index f41abca0cc..9baf6aca9f 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -374,6 +374,12 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image, */ image_info.load_addr = spl_image->load_addr + spl_image->size;
+ /* + * Since libfdt v1.6.1, the device tree must be loaded in to memory + * at an 8-byte aligned address. + */ + image_info.load_addr = roundup(image_info.load_addr, 8); + /* Figure out which device tree the board wants to use */ node = spl_fit_get_image_node(ctx, FIT_FDT_PROP, index++); if (node < 0) {
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Bin Meng Sent: Monday, 12 July 2021 3:53 pm To: Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org; u- boot@lists.denx.de Cc: Bin Meng bmeng.cn@gmail.com Subject: [PATCH] spl: Align device tree blob address at 8-byte boundary
Since libfdt v1.6.1, a new requirement on the device tree address via:
commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()")
must be met that the device tree must be loaded in to memory at an 8-byte aligned address.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/spl/spl_fit.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index f41abca0cc..9baf6aca9f 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -374,6 +374,12 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image, */ image_info.load_addr = spl_image->load_addr + spl_image->size;
- /*
* Since libfdt v1.6.1, the device tree must be loaded in to memory* at an 8-byte aligned address.*/- image_info.load_addr = roundup(image_info.load_addr, 8);
- /* Figure out which device tree the board wants to use */ node = spl_fit_get_image_node(ctx, FIT_FDT_PROP, index++); if (node < 0) {
-- 2.25.1
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simply hangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
-----Original Message-----
From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Bin Meng Sent: Monday, 12 July 2021 3:53 pm To: Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org; u- boot@lists.denx.de Cc: Bin Meng bmeng.cn@gmail.com Subject: [PATCH] spl: Align device tree blob address at 8-byte boundary
Since libfdt v1.6.1, a new requirement on the device tree address via:
commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()")
must be met that the device tree must be loaded in to memory at an 8-byte aligned address.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/spl/spl_fit.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index f41abca0cc..9baf6aca9f 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -374,6 +374,12 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image, */ image_info.load_addr = spl_image->load_addr + spl_image->size;
+/*
- Since libfdt v1.6.1, the device tree must be loaded in to memory
- at an 8-byte aligned address.
- */
+image_info.load_addr = roundup(image_info.load_addr, 8);
/* Figure out which device tree the board wants to use */ node = spl_fit_get_image_node(ctx, FIT_FDT_PROP, index++); if (node < 0) { --
Regards, Bin
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment. It's just that on 32bit platforms 4-but-not-8 byte alignment tends to not be fatal but on 64bit platforms it is.
On 7/12/21 5:15 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
If I recall this correctly, DT node alignment is 4 byte and that is what DTC emits. If you have fitImage with embedded data, you basically end up with
/ { prop1 = "string1"; prop2 = "string2"; };
where the "string2" is aligned to 4 bytes. And that is what U-Boot expects when it tries to access those data in-place in SPL.
The problem with the reverted patch was that it made U-Boot assume the alignment is 8 bytes, and that actually works only if you use fitImage with external data (mkimage -E), but with embedded data (mkimage default) not so much. That caused off-by-4 error in some cases and that made the SPL hang.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment.
DT alignment was always 4 byte , no ?
It's just that on 32bit platforms 4-but-not-8 byte alignment tends to not be fatal but on 64bit platforms it is.
[...]
On Mon, Jul 12, 2021 at 05:38:33PM +0200, Marek Vasut wrote:
On 7/12/21 5:15 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
If I recall this correctly, DT node alignment is 4 byte and that is what DTC emits. If you have fitImage with embedded data, you basically end up with
/ { prop1 = "string1"; prop2 = "string2"; };
where the "string2" is aligned to 4 bytes. And that is what U-Boot expects when it tries to access those data in-place in SPL.
The problem with the reverted patch was that it made U-Boot assume the alignment is 8 bytes, and that actually works only if you use fitImage with external data (mkimage -E), but with embedded data (mkimage default) not so much. That caused off-by-4 error in some cases and that made the SPL hang.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment.
DT alignment was always 4 byte , no ?
I'm pretty sure, no, 8 byte base alignment is a pretty much always thing. I don't have a reference handy but I also know I couldn't have convinced dgibson to add the check otherwise.
On 7/12/21 5:43 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 05:38:33PM +0200, Marek Vasut wrote:
On 7/12/21 5:15 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
If I recall this correctly, DT node alignment is 4 byte and that is what DTC emits. If you have fitImage with embedded data, you basically end up with
/ { prop1 = "string1"; prop2 = "string2"; };
where the "string2" is aligned to 4 bytes. And that is what U-Boot expects when it tries to access those data in-place in SPL.
The problem with the reverted patch was that it made U-Boot assume the alignment is 8 bytes, and that actually works only if you use fitImage with external data (mkimage -E), but with embedded data (mkimage default) not so much. That caused off-by-4 error in some cases and that made the SPL hang.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment.
DT alignment was always 4 byte , no ?
I'm pretty sure, no, 8 byte base alignment is a pretty much always thing. I don't have a reference handy but I also know I couldn't have convinced dgibson to add the check otherwise.
DTSpec rev 0.3 says the following and I think you got confused by section 5.6 which talks about alignment of the entire tree, not its nodes:
5.4 Structure Block " Each token in the structure block, and thus the structure block itself, shall be located at a 4-byte aligned offset from the beginning of the devicetree blob (see 5.6). "
5.4.2 Tree structure " For each property of the node: ... – FDT_PROP token ... * [zeroed padding bytes to align to a 4-byte boundary] "
5.5 Strings Block " The strings block contains strings representing all the property names used in the tree. These null terminated strings are simply concatenated together in this section, and referred to from the structure block by an offset into the strings block. The strings block has no alignment constraints and may appear at any offset from the beginning of the devicetree blob. "
5.6 Alignment " As described in the previous sections, the structure and strings blocks shall have aligned offsets from the beginning of the devicetree blob. To ensure the in-memory alignment of the blocks, it is sufficient to ensure that the devicetree as a whole is loaded at an address aligned to the largest alignment of any of the subblocks, that is, to an 8-byte boundary. "
On Mon, Jul 12, 2021 at 05:51:29PM +0200, Marek Vasut wrote:
On 7/12/21 5:43 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 05:38:33PM +0200, Marek Vasut wrote:
On 7/12/21 5:15 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
If I recall this correctly, DT node alignment is 4 byte and that is what DTC emits. If you have fitImage with embedded data, you basically end up with
/ { prop1 = "string1"; prop2 = "string2"; };
where the "string2" is aligned to 4 bytes. And that is what U-Boot expects when it tries to access those data in-place in SPL.
The problem with the reverted patch was that it made U-Boot assume the alignment is 8 bytes, and that actually works only if you use fitImage with external data (mkimage -E), but with embedded data (mkimage default) not so much. That caused off-by-4 error in some cases and that made the SPL hang.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment.
DT alignment was always 4 byte , no ?
I'm pretty sure, no, 8 byte base alignment is a pretty much always thing. I don't have a reference handy but I also know I couldn't have convinced dgibson to add the check otherwise.
DTSpec rev 0.3 says the following and I think you got confused by section 5.6 which talks about alignment of the entire tree, not its nodes:
5.4 Structure Block " Each token in the structure block, and thus the structure block itself, shall be located at a 4-byte aligned offset from the beginning of the devicetree blob (see 5.6). "
5.4.2 Tree structure " For each property of the node: ... – FDT_PROP token ...
- [zeroed padding bytes to align to a 4-byte boundary]
"
5.5 Strings Block " The strings block contains strings representing all the property names used in the tree. These null terminated strings are simply concatenated together in this section, and referred to from the structure block by an offset into the strings block. The strings block has no alignment constraints and may appear at any offset from the beginning of the devicetree blob. "
5.6 Alignment " As described in the previous sections, the structure and strings blocks shall have aligned offsets from the beginning of the devicetree blob. To ensure the in-memory alignment of the blocks, it is sufficient to ensure that the devicetree as a whole is loaded at an address aligned to the largest alignment of any of the subblocks, that is, to an 8-byte boundary.
Right. A device tree must start at an 8-byte boundary and U-Boot was violating this both with: - All of the boards that use fdt_high=0xffffffff to disable relocation, and then then place things at arbitrary spots in memory that may or may not violate these requirements. - Perhaps some of the FIT internals where we have a device tree inside a device tree? And we need to fixup whatever we're doing there that's wrong.
On 7/12/21 6:02 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 05:51:29PM +0200, Marek Vasut wrote:
On 7/12/21 5:43 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 05:38:33PM +0200, Marek Vasut wrote:
On 7/12/21 5:15 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
If I recall this correctly, DT node alignment is 4 byte and that is what DTC emits. If you have fitImage with embedded data, you basically end up with
/ { prop1 = "string1"; prop2 = "string2"; };
where the "string2" is aligned to 4 bytes. And that is what U-Boot expects when it tries to access those data in-place in SPL.
The problem with the reverted patch was that it made U-Boot assume the alignment is 8 bytes, and that actually works only if you use fitImage with external data (mkimage -E), but with embedded data (mkimage default) not so much. That caused off-by-4 error in some cases and that made the SPL hang.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment.
DT alignment was always 4 byte , no ?
I'm pretty sure, no, 8 byte base alignment is a pretty much always thing. I don't have a reference handy but I also know I couldn't have convinced dgibson to add the check otherwise.
DTSpec rev 0.3 says the following and I think you got confused by section 5.6 which talks about alignment of the entire tree, not its nodes:
5.4 Structure Block " Each token in the structure block, and thus the structure block itself, shall be located at a 4-byte aligned offset from the beginning of the devicetree blob (see 5.6). "
5.4.2 Tree structure " For each property of the node: ... – FDT_PROP token ...
- [zeroed padding bytes to align to a 4-byte boundary]
"
5.5 Strings Block " The strings block contains strings representing all the property names used in the tree. These null terminated strings are simply concatenated together in this section, and referred to from the structure block by an offset into the strings block. The strings block has no alignment constraints and may appear at any offset from the beginning of the devicetree blob. "
5.6 Alignment " As described in the previous sections, the structure and strings blocks shall have aligned offsets from the beginning of the devicetree blob. To ensure the in-memory alignment of the blocks, it is sufficient to ensure that the devicetree as a whole is loaded at an address aligned to the largest alignment of any of the subblocks, that is, to an 8-byte boundary.
Right. A device tree must start at an 8-byte boundary
Start, yes ; string alignment, no.
and U-Boot was violating this both with:
- All of the boards that use fdt_high=0xffffffff to disable relocation,
Not applicable to SPL case.
and then then place things at arbitrary spots in memory that may or may not violate these requirements.
- Perhaps some of the FIT internals where we have a device tree inside a device tree? And we need to fixup whatever we're doing there that's wrong.
And that too. On arm32 and legacy setups this is fine, on arm64 and all new setups, use mkimage -E to avoid running into this.
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases: 1) u-boot as a FIT (binary and FDT separately loaded) 2) u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
Alex
Hi Alex,
On Mon, 12 Jul 2021 at 10:01, Alex G. mr.nuke.me@gmail.com wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases: 1) u-boot as a FIT (binary and FDT separately loaded) 2) u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
Just on that specific point, we should use the SPL handoff info in a bloblist.
Regards, Simon
On Tue, Jul 13, 2021 at 12:01 AM Alex G. mr.nuke.me@gmail.com wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases: 1) u-boot as a FIT (binary and FDT separately loaded) 2) u-boot with embedded FDT
Is this CONFIG_OF_EMBED?
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size)
I don't see there is even a ALIGN_4 in current SPL logic, but it happens to be 4 in all cases I think.
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
Regards, Bin
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: >> >> I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... >> >> This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. >> >> I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. > > Thanks for your information. > > +Marek who did the revert > > The revert commit message says: > > "The commit breaks booting of fitImage by SPL, the system simply > hangs. This is because on arm32, the fitImage and all of its content > can be aligned to 4 bytes and U-Boot expects just that." > > I don't understand this. If an address is aligned to 8, it is already > aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
Regards, Simon
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote: > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: >> On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: >>> >>> I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... >>> >>> This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. >>> >>> I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. >> >> Thanks for your information. >> >> +Marek who did the revert >> >> The revert commit message says: >> >> "The commit breaks booting of fitImage by SPL, the system simply >> hangs. This is because on arm32, the fitImage and all of its content >> can be aligned to 4 bytes and U-Boot expects just that." >> >> I don't understand this. If an address is aligned to 8, it is already >> aligned to 4, so how did this commit make the system hang on arm32? > > I think this had something to do with embedding contents somewhere in > the image? There is a thread on the ML from then but I don't know how > informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases: 1) u-boot as a FIT (binary and FDT separately loaded) 2) u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: > On 7/12/21 10:15 AM, Tom Rini wrote: > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > > > > > > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > > > > > > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > > > > > > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. > > > > > > Thanks for your information. > > > > > > +Marek who did the revert > > > > > > The revert commit message says: > > > > > > "The commit breaks booting of fitImage by SPL, the system simply > > > hangs. This is because on arm32, the fitImage and all of its content > > > can be aligned to 4 bytes and U-Boot expects just that." > > > > > > I don't understand this. If an address is aligned to 8, it is already > > > aligned to 4, so how did this commit make the system hang on arm32? > > > > I think this had something to do with embedding contents somewhere in > > the image? There is a thread on the ML from then but I don't know how > > informative it will end up being. > > It's true that the flat devicetree spec requires an 8-byte alignment, even > on 32-bit. The issues here are specific to u-boot. > > SPL and u-boot have to agree where u-boot's FDT is located. We'll look at > two cases: > 1) u-boot as a FIT (binary and FDT separately loaded) > 2) u-boot with embedded FDT > > In case (1) SPL must place the FDT at a location where u-boot will find it. > The current logic is > SPL: fdt = ALIGN_4(u_boot + u_boot_size) > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > In case (2), SPL's view of the FDT is not relevant, but instead the build > system must place the FDT correctly: > build: fdt >> u-boot.bin > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > We have 3 places that must agree. A correct and complete patch could change > all three, but one has to consider compatibility issues when crossing u-boot > and SPL versions. > > I had proposed in the revert discussion that SPL use r2 or similar mechanism > to pass the location of the FDT to u-boot.
I'm not sure that we need to worry too much about mix-and-match SPL/U-Boot, but documenting what to go change if you must do it somewhere under doc/ would be good. I think we can just switch to ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
On 7/13/21 8:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote: > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: >> On 7/12/21 10:15 AM, Tom Rini wrote: >>> On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: >>>> On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: >>>>> >>>>> I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... >>>>> >>>>> This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. >>>>> >>>>> I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. >>>> >>>> Thanks for your information. >>>> >>>> +Marek who did the revert >>>> >>>> The revert commit message says: >>>> >>>> "The commit breaks booting of fitImage by SPL, the system simply >>>> hangs. This is because on arm32, the fitImage and all of its content >>>> can be aligned to 4 bytes and U-Boot expects just that." >>>> >>>> I don't understand this. If an address is aligned to 8, it is already >>>> aligned to 4, so how did this commit make the system hang on arm32? >>> >>> I think this had something to do with embedding contents somewhere in >>> the image? There is a thread on the ML from then but I don't know how >>> informative it will end up being. >> >> It's true that the flat devicetree spec requires an 8-byte alignment, even >> on 32-bit. The issues here are specific to u-boot. >> >> SPL and u-boot have to agree where u-boot's FDT is located. We'll look at >> two cases: >> 1) u-boot as a FIT (binary and FDT separately loaded) >> 2) u-boot with embedded FDT >> >> In case (1) SPL must place the FDT at a location where u-boot will find it. >> The current logic is >> SPL: fdt = ALIGN_4(u_boot + u_boot_size) >> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >> >> In case (2), SPL's view of the FDT is not relevant, but instead the build >> system must place the FDT correctly: >> build: fdt >> u-boot.bin >> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >> >> We have 3 places that must agree. A correct and complete patch could change >> all three, but one has to consider compatibility issues when crossing u-boot >> and SPL versions. >> >> I had proposed in the revert discussion that SPL use r2 or similar mechanism >> to pass the location of the FDT to u-boot. > > I'm not sure that we need to worry too much about mix-and-match > SPL/U-Boot, but documenting what to go change if you must do it > somewhere under doc/ would be good. I think we can just switch to > ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
The fail case is this: - you update SPL with this 8 byte alignment change - you have older kernel fitImage with embedded DT for falcon mode - system no longer boots because there is off-by-4 error in the DT address passed to the kernel
I hope this is clear now.
On 7/13/21 3:35 PM, Marek Vasut wrote:
On 7/13/21 8:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote: > On 7/13/21 3:47 PM, Tom Rini wrote: >> On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: >>> On 7/12/21 10:15 AM, Tom Rini wrote: >>>> On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: >>>>> On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle >>>>> reuben.dowle@4rf.com wrote: >>>>>> >>>>>> I submitted an almost identical patch. See >>>>>> https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... >>>>>> >>>>>> >>>>>> This patch eventually had to be reverted >>>>>> (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), >>>>>> because it was causing issues on some platforms that had FIT >>>>>> on 32 bit boundary. However I continue to use it in >>>>>> production code, as without it the boot on my platform aborts. >>>>>> >>>>>> I don't have time to investigate why this was happening, but >>>>>> you need to check this code won't just cause exactly the >>>>>> same faults. >>>>> >>>>> Thanks for your information. >>>>> >>>>> +Marek who did the revert >>>>> >>>>> The revert commit message says: >>>>> >>>>> "The commit breaks booting of fitImage by SPL, the >>>>> system simply >>>>> hangs. This is because on arm32, the fitImage and all of its >>>>> content >>>>> can be aligned to 4 bytes and U-Boot expects just that." >>>>> >>>>> I don't understand this. If an address is aligned to 8, it is >>>>> already >>>>> aligned to 4, so how did this commit make the system hang on >>>>> arm32? >>>> >>>> I think this had something to do with embedding contents >>>> somewhere in >>>> the image? There is a thread on the ML from then but I don't >>>> know how >>>> informative it will end up being. >>> >>> It's true that the flat devicetree spec requires an 8-byte >>> alignment, even >>> on 32-bit. The issues here are specific to u-boot. >>> >>> SPL and u-boot have to agree where u-boot's FDT is located. >>> We'll look at >>> two cases: >>> 1) u-boot as a FIT (binary and FDT separately loaded) >>> 2) u-boot with embedded FDT >>> >>> In case (1) SPL must place the FDT at a location where u-boot >>> will find it. >>> The current logic is >>> SPL: fdt = ALIGN_4(u_boot + u_boot_size) >>> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >>> >>> In case (2), SPL's view of the FDT is not relevant, but instead >>> the build >>> system must place the FDT correctly: >>> build: fdt >> u-boot.bin >>> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >>> >>> We have 3 places that must agree. A correct and complete patch >>> could change >>> all three, but one has to consider compatibility issues when >>> crossing u-boot >>> and SPL versions. >>> >>> I had proposed in the revert discussion that SPL use r2 or >>> similar mechanism >>> to pass the location of the FDT to u-boot. >> >> I'm not sure that we need to worry too much about mix-and-match >> SPL/U-Boot, but documenting what to go change if you must do it >> somewhere under doc/ would be good. I think we can just switch to >> ALIGN(8) not ALIGN(4) and be done with it? > > Remember, there is also falcon boot. And we definitely have to be > able to > have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT
address passed to the kernel
I'm not sure how falcon mode would break the kernel. It passes to the kernel the load address of the fdt. The concern here is loading u-boot.
I hope this is clear now.
On Tue, Jul 13, 2021 at 10:35:03PM +0200, Marek Vasut wrote:
On 7/13/21 8:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote: > On 7/13/21 3:47 PM, Tom Rini wrote: > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: > > > On 7/12/21 10:15 AM, Tom Rini wrote: > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > > > > > > > > > > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > > > > > > > > > > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > > > > > > > > > > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. > > > > > > > > > > Thanks for your information. > > > > > > > > > > +Marek who did the revert > > > > > > > > > > The revert commit message says: > > > > > > > > > > "The commit breaks booting of fitImage by SPL, the system simply > > > > > hangs. This is because on arm32, the fitImage and all of its content > > > > > can be aligned to 4 bytes and U-Boot expects just that." > > > > > > > > > > I don't understand this. If an address is aligned to 8, it is already > > > > > aligned to 4, so how did this commit make the system hang on arm32? > > > > > > > > I think this had something to do with embedding contents somewhere in > > > > the image? There is a thread on the ML from then but I don't know how > > > > informative it will end up being. > > > > > > It's true that the flat devicetree spec requires an 8-byte alignment, even > > > on 32-bit. The issues here are specific to u-boot. > > > > > > SPL and u-boot have to agree where u-boot's FDT is located. We'll look at > > > two cases: > > > 1) u-boot as a FIT (binary and FDT separately loaded) > > > 2) u-boot with embedded FDT > > > > > > In case (1) SPL must place the FDT at a location where u-boot will find it. > > > The current logic is > > > SPL: fdt = ALIGN_4(u_boot + u_boot_size) > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > In case (2), SPL's view of the FDT is not relevant, but instead the build > > > system must place the FDT correctly: > > > build: fdt >> u-boot.bin > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > We have 3 places that must agree. A correct and complete patch could change > > > all three, but one has to consider compatibility issues when crossing u-boot > > > and SPL versions. > > > > > > I had proposed in the revert discussion that SPL use r2 or similar mechanism > > > to pass the location of the FDT to u-boot. > > > > I'm not sure that we need to worry too much about mix-and-match > > SPL/U-Boot, but documenting what to go change if you must do it > > somewhere under doc/ would be good. I think we can just switch to > > ALIGN(8) not ALIGN(4) and be done with it? > > Remember, there is also falcon boot. And we definitely have to be able to > have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT address passed to the kernel
OK. Then I think the answer is what I said recently in another part of this thread, we need to split "find the fdt" from "align the fdt". The fdt can come to us with any alignment it happens to have, but we can't use that fdt in-place unless it's correctly aligned. In the case of falcon mode, it needs to end up at CONFIG_SYS_SPL_ARGS_ADDR. The case of passing it on to U-Boot proper is where we have at best a hack right now (as noted by fdt_hack in common/spl/spl.c). That would be a place to, as has been also suggested in this thread, pass along more correctly where the device tree in memory is.
On Wed, Jul 14, 2021 at 5:11 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 13, 2021 at 10:35:03PM +0200, Marek Vasut wrote:
On 7/13/21 8:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote: > On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote: > > On 7/13/21 3:47 PM, Tom Rini wrote: > > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: > > > > On 7/12/21 10:15 AM, Tom Rini wrote: > > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > > > > > > > > > > > > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > > > > > > > > > > > > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > > > > > > > > > > > > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. > > > > > > > > > > > > Thanks for your information. > > > > > > > > > > > > +Marek who did the revert > > > > > > > > > > > > The revert commit message says: > > > > > > > > > > > > "The commit breaks booting of fitImage by SPL, the system simply > > > > > > hangs. This is because on arm32, the fitImage and all of its content > > > > > > can be aligned to 4 bytes and U-Boot expects just that." > > > > > > > > > > > > I don't understand this. If an address is aligned to 8, it is already > > > > > > aligned to 4, so how did this commit make the system hang on arm32? > > > > > > > > > > I think this had something to do with embedding contents somewhere in > > > > > the image? There is a thread on the ML from then but I don't know how > > > > > informative it will end up being. > > > > > > > > It's true that the flat devicetree spec requires an 8-byte alignment, even > > > > on 32-bit. The issues here are specific to u-boot. > > > > > > > > SPL and u-boot have to agree where u-boot's FDT is located. We'll look at > > > > two cases: > > > > 1) u-boot as a FIT (binary and FDT separately loaded) > > > > 2) u-boot with embedded FDT > > > > > > > > In case (1) SPL must place the FDT at a location where u-boot will find it. > > > > The current logic is > > > > SPL: fdt = ALIGN_4(u_boot + u_boot_size) > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > > > In case (2), SPL's view of the FDT is not relevant, but instead the build > > > > system must place the FDT correctly: > > > > build: fdt >> u-boot.bin > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > > > We have 3 places that must agree. A correct and complete patch could change > > > > all three, but one has to consider compatibility issues when crossing u-boot > > > > and SPL versions. > > > > > > > > I had proposed in the revert discussion that SPL use r2 or similar mechanism > > > > to pass the location of the FDT to u-boot. > > > > > > I'm not sure that we need to worry too much about mix-and-match > > > SPL/U-Boot, but documenting what to go change if you must do it > > > somewhere under doc/ would be good. I think we can just switch to > > > ALIGN(8) not ALIGN(4) and be done with it? > > > > Remember, there is also falcon boot. And we definitely have to be able to > > have old u-boot (SPL) boot new fitImage and vice versa. > > I don't follow you, sorry. But since you seem to have the best > understanding of where all of the cases something could go wrong here, > can you perhaps post an RFC patch? That is likely to be clearer than > another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT address passed to the kernel
OK. Then I think the answer is what I said recently in another part of this thread, we need to split "find the fdt" from "align the fdt". The fdt can come to us with any alignment it happens to have, but we can't use that fdt in-place unless it's correctly aligned. In the case of falcon mode, it needs to end up at CONFIG_SYS_SPL_ARGS_ADDR. The case of passing it on to U-Boot proper is where we have at best a hack right now (as noted by fdt_hack in common/spl/spl.c). That would be a place to, as has been also suggested in this thread, pass along more correctly where the device tree in memory is.
Where are we on this issue?
Regards, Bin
On Mon, Jul 26, 2021 at 09:26:26PM +0800, Bin Meng wrote:
On Wed, Jul 14, 2021 at 5:11 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 13, 2021 at 10:35:03PM +0200, Marek Vasut wrote:
On 7/13/21 8:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote: > > On 7/13/21 4:41 PM, Tom Rini wrote: > > On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote: > > > On 7/13/21 3:47 PM, Tom Rini wrote: > > > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: > > > > > On 7/12/21 10:15 AM, Tom Rini wrote: > > > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > > > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: > > > > > > > > > > > > > > > > I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... > > > > > > > > > > > > > > > > This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. > > > > > > > > > > > > > > > > I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. > > > > > > > > > > > > > > Thanks for your information. > > > > > > > > > > > > > > +Marek who did the revert > > > > > > > > > > > > > > The revert commit message says: > > > > > > > > > > > > > > "The commit breaks booting of fitImage by SPL, the system simply > > > > > > > hangs. This is because on arm32, the fitImage and all of its content > > > > > > > can be aligned to 4 bytes and U-Boot expects just that." > > > > > > > > > > > > > > I don't understand this. If an address is aligned to 8, it is already > > > > > > > aligned to 4, so how did this commit make the system hang on arm32? > > > > > > > > > > > > I think this had something to do with embedding contents somewhere in > > > > > > the image? There is a thread on the ML from then but I don't know how > > > > > > informative it will end up being. > > > > > > > > > > It's true that the flat devicetree spec requires an 8-byte alignment, even > > > > > on 32-bit. The issues here are specific to u-boot. > > > > > > > > > > SPL and u-boot have to agree where u-boot's FDT is located. We'll look at > > > > > two cases: > > > > > 1) u-boot as a FIT (binary and FDT separately loaded) > > > > > 2) u-boot with embedded FDT > > > > > > > > > > In case (1) SPL must place the FDT at a location where u-boot will find it. > > > > > The current logic is > > > > > SPL: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > > > > > In case (2), SPL's view of the FDT is not relevant, but instead the build > > > > > system must place the FDT correctly: > > > > > build: fdt >> u-boot.bin > > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size) > > > > > > > > > > We have 3 places that must agree. A correct and complete patch could change > > > > > all three, but one has to consider compatibility issues when crossing u-boot > > > > > and SPL versions. > > > > > > > > > > I had proposed in the revert discussion that SPL use r2 or similar mechanism > > > > > to pass the location of the FDT to u-boot. > > > > > > > > I'm not sure that we need to worry too much about mix-and-match > > > > SPL/U-Boot, but documenting what to go change if you must do it > > > > somewhere under doc/ would be good. I think we can just switch to > > > > ALIGN(8) not ALIGN(4) and be done with it? > > > > > > Remember, there is also falcon boot. And we definitely have to be able to > > > have old u-boot (SPL) boot new fitImage and vice versa. > > > > I don't follow you, sorry. But since you seem to have the best > > understanding of where all of the cases something could go wrong here, > > can you perhaps post an RFC patch? That is likely to be clearer than > > another long thread here. > > I don't follow you, sorry. I believe the revert did the right thing and > new systems should use mkimage -E when generating fitImages, to avoid > the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT address passed to the kernel
OK. Then I think the answer is what I said recently in another part of this thread, we need to split "find the fdt" from "align the fdt". The fdt can come to us with any alignment it happens to have, but we can't use that fdt in-place unless it's correctly aligned. In the case of falcon mode, it needs to end up at CONFIG_SYS_SPL_ARGS_ADDR. The case of passing it on to U-Boot proper is where we have at best a hack right now (as noted by fdt_hack in common/spl/spl.c). That would be a place to, as has been also suggested in this thread, pass along more correctly where the device tree in memory is.
Where are we on this issue?
Waiting for someone to do what I suggested I think. I've not yet had time to take a look.
On 7/13/21 1:11 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
On 7/13/21 6:47 PM, Simon Glass wrote:
Hi Marek,
On Tue, 13 Jul 2021 at 08:53, Marek Vasut marex@denx.de wrote:
On 7/13/21 4:41 PM, Tom Rini wrote:
On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
On 7/13/21 3:47 PM, Tom Rini wrote: > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: >> On 7/12/21 10:15 AM, Tom Rini wrote: >>> On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: >>>> On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote: >>>>> >>>>> I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3... >>>>> >>>>> This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts. >>>>> >>>>> I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. >>>> >>>> Thanks for your information. >>>> >>>> +Marek who did the revert >>>> >>>> The revert commit message says: >>>> >>>> "The commit breaks booting of fitImage by SPL, the system simply >>>> hangs. This is because on arm32, the fitImage and all of its content >>>> can be aligned to 4 bytes and U-Boot expects just that." >>>> >>>> I don't understand this. If an address is aligned to 8, it is already >>>> aligned to 4, so how did this commit make the system hang on arm32? >>> >>> I think this had something to do with embedding contents somewhere in >>> the image? There is a thread on the ML from then but I don't know how >>> informative it will end up being. >> >> It's true that the flat devicetree spec requires an 8-byte alignment, even >> on 32-bit. The issues here are specific to u-boot. >> >> SPL and u-boot have to agree where u-boot's FDT is located. We'll look at >> two cases: >> 1) u-boot as a FIT (binary and FDT separately loaded) >> 2) u-boot with embedded FDT >> >> In case (1) SPL must place the FDT at a location where u-boot will find it. >> The current logic is >> SPL: fdt = ALIGN_4(u_boot + u_boot_size) >> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >> >> In case (2), SPL's view of the FDT is not relevant, but instead the build >> system must place the FDT correctly: >> build: fdt >> u-boot.bin >> u-boot: fdt = ALIGN_4(u_boot + u_boot_size) >> >> We have 3 places that must agree. A correct and complete patch could change >> all three, but one has to consider compatibility issues when crossing u-boot >> and SPL versions. >> >> I had proposed in the revert discussion that SPL use r2 or similar mechanism >> to pass the location of the FDT to u-boot. > > I'm not sure that we need to worry too much about mix-and-match > SPL/U-Boot, but documenting what to go change if you must do it > somewhere under doc/ would be good. I think we can just switch to > ALIGN(8) not ALIGN(4) and be done with it?
Remember, there is also falcon boot. And we definitely have to be able to have old u-boot (SPL) boot new fitImage and vice versa.
I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here.
I don't follow you, sorry. I believe the revert did the right thing and new systems should use mkimage -E when generating fitImages, to avoid the string alignment problem. That is all.
Using -E should be optional and things really should work without it.
See the DTSpec, I don't think that is possible unless you relocate fitImage components, and if you want fast boot time esp. in SPL, that is not good.
This is why I've asked you to make up some patch to perhaps highlight the problem. Ensuring that the device tree, which is small, is also 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not sure where the problem case is that isn't "user put things they control in a bad spot, fail and tell them why" but I could just be missing a case.
As far as highlighting the problem, here's an excerpt from the previous discussion [1].
## SPL:
image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8);
(gdb) print/x (spl_image->load_addr + spl_image->size) $19 = 0xc01cf85c (gdb) print/x image_info->load_addr $20 = 0xc01cf860
FDT is installed at 0xc01cf860
## u-boot:
__weak void *board_fdt_blob_setup(void) { /* FDT is at end of image */
fdt_blob = (ulong *)&_end;
(gdb) print &_end $22 = (char (*)[]) 0xc01cf85c
FDT is expected at 0xc01cf85c
Alex
[1] https://lists.denx.de/pipermail/u-boot/2020-October/430066.html
On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
On 7/12/21 10:15 AM, Tom Rini wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
It's true that the flat devicetree spec requires an 8-byte alignment, even on 32-bit. The issues here are specific to u-boot.
SPL and u-boot have to agree where u-boot's FDT is located. We'll look at two cases:
- u-boot as a FIT (binary and FDT separately loaded)
- u-boot with embedded FDT
In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
In case (2), SPL's view of the FDT is not relevant, but instead the build system must place the FDT correctly: build: fdt >> u-boot.bin u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
We have 3 places that must agree. A correct and complete patch could change all three, but one has to consider compatibility issues when crossing u-boot and SPL versions.
I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot.
Looking at this again, and trying to figure out what we can do here most easily, I think we need to have spl_fit_append_fdt() perhaps be split in to "find the fdt" and then either a new function, or more logic within the function for "ensure fdt is aligned properly". We had made the assumption that we can use the fdt in place in memory but that's not always true.
On Mon, Jul 12, 2021 at 11:15 PM Tom Rini trini@konsulko.com wrote:
On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle reuben.dowle@4rf.com wrote:
I submitted an almost identical patch. See https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3...
This patch eventually had to be reverted (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16f...), because it was causing issues on some platforms that had FIT on 32 bit boundary. However I continue to use it in production code, as without it the boot on my platform aborts.
I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults.
Thanks for your information.
+Marek who did the revert
The revert commit message says:
"The commit breaks booting of fitImage by SPL, the system simplyhangs. This is because on arm32, the fitImage and all of its content can be aligned to 4 bytes and U-Boot expects just that."
I don't understand this. If an address is aligned to 8, it is already aligned to 4, so how did this commit make the system hang on arm32?
I think this had something to do with embedding contents somewhere in the image? There is a thread on the ML from then but I don't know how informative it will end up being.
Note, as I indicated in this patch, now with libfdt 1.6.1, the alignment to 8 byte is a must-have. So we have to do such alignment anyway.
@Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()") was made to have the 8-byte alignment requirement.
Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment. It's just that on 32bit platforms 4-but-not-8 byte alignment tends to not be fatal but on 64bit platforms it is.
But with libfdt v1.6.1 commit 5e735860c478 ("libfdt: Check for 8-byte address alignment in fdt_ro_probe_()"), now this is fatal error if DT address is not 8-bytes aligned, as that commit adds a check in fdt_ro_probe_().
Regards, Bin
participants (7)
-
Alex G -
Alex G.
-
Bin Meng -
Marek Vasut -
Reuben Dowle -
Simon Glass -
Tom Rini