[U-Boot] [PATCH] spl_mmc: allow to load raw image
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com ---
common/spl/spl_mmc.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index c27a250..df406e3 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -33,11 +33,6 @@ static int mmc_load_image_raw_sector(struct mmc *mmc, unsigned long sector) if (count == 0) goto end;
- if (image_get_magic(header) != IH_MAGIC) { - puts("bad magic\n"); - return -1; - } - spl_parse_image_header(header);
/* convert size to sectors - round up */
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
Reviewed-by: Tom Rini trini@konsulko.com
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
OK, but now with Simon's series that adds FIT support to SPL this just doesn't work as is, please rework and resend, thanks!
Hi Tom,
2016-03-16 4:23 GMT+09:00 Tom Rini trini@konsulko.com:
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
OK, but now with Simon's series that adds FIT support to SPL this just doesn't work as is, please rework and resend, thanks!
Done.
http://patchwork.ozlabs.org/patch/598113/
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Hi Tom,
2016-03-17 11:04 GMT+09:00 Tom Rini trini@konsulko.com:
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
I guess this is false.
This is v1 that you said does not work as is.
On Fri, Mar 18, 2016 at 01:07:47AM +0900, Masahiro Yamada wrote:
Hi Tom,
2016-03-17 11:04 GMT+09:00 Tom Rini trini@konsulko.com:
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
I guess this is false.
This is v1 that you said does not work as is.
Yup, oops, forgot to delete it from my local bundle.
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC (hang)
Without the patch, I get:
U-Boot SPL 2016.03-00377-g73b5b27 (Apr 29 2016 - 09:26:30) Trying to boot from MMC bad magic bad magic reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
(U-boot loads)
On Thu, Mar 17, 2016 at 11:12 AM, Tom Rini trini@konsulko.com wrote:
On Fri, Mar 18, 2016 at 01:07:47AM +0900, Masahiro Yamada wrote:
Hi Tom,
2016-03-17 11:04 GMT+09:00 Tom Rini trini@konsulko.com:
On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
I guess this is false.
This is v1 that you said does not work as is.
Yup, oops, forgot to delete it from my local bundle.
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
-- Tom
On Fri, Apr 29, 2016 at 01:06:14PM -0500, Adam Ford wrote:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
No what you're doing is a valid use case that should be working, thanks.
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
On Sun, May 01, 2016 at 05:37:42PM +0900, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
Well, I forgot to ask, is MLO being loaded from FAT or from raw?
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
Derald
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1
Isn't part of what's going wrong now.
2016-05-02 10:57 GMT+09:00 Tom Rini trini@konsulko.com:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Also, I think spl_mmc_load_image() is a bit odd.
case MMCSD_MODE_RAW:
/* If RAW mode fails, try FS mode. */ case MMCSD_MODE_FS:
should be
case MMCSD_MODE_FS:
/* If FS mode fails, try RAW mode. */ case MMCSD_MODE_RAW:
File system is generally higher requirement than raw block access.
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
Does anyone with an OMAP3 board have any issues with this patch? I will admit I haven't stayed on top of stuff due to moving, and other issues at home, but I pulled down the master to reviews some on related stuff, and found that master doesn't boot. I used git bisect this morning and it narrowed down a problem with booting to this patch.
With the patch, I get:
U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) Trying to boot from MMC
OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
> Does anyone with an OMAP3 board have any issues with this patch? I > will admit I haven't stayed on top of stuff due to moving, and > other > issues at home, but I pulled down the master to reviews some on > related stuff, and found that master doesn't boot. I used git > bisect > this morning and it narrowed down a problem with booting to this > patch. > > With the patch, I get: > > U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) > Trying to boot from MMC OK. Do you have u-boot.bin or u-boot.img (which?) written to the raw offset in MMC or from filesystem? Based on the log it looks like filesystem.
I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Derald
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote: > On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: > >> Does anyone with an OMAP3 board have any issues with this patch? I >> will admit I haven't stayed on top of stuff due to moving, and >> other >> issues at home, but I pulled down the master to reviews some on >> related stuff, and found that master doesn't boot. I used git >> bisect >> this morning and it narrowed down a problem with booting to this >> patch. >> >> With the patch, I get: >> >> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >> Trying to boot from MMC > OK. Do you have u-boot.bin or u-boot.img (which?) written to the > raw > offset in MMC or from filesystem? Based on the log it looks like > filesystem. I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I've tried to see why things don't work and dug out my beagle xm from the shelf. Unfortunately, I don't even get it to boot at all with current master. Bisecting points me to the commit below which makes sense - we simply change the raw offset on SD for all OMAP systems.
Is that a good idea? It probably breaks pretty much every user that uses raw boot right now.
Alex
ef5ebe951bec72631cdbc7cef9079e6c684e5d0b is the first bad commit commit ef5ebe951bec72631cdbc7cef9079e6c684e5d0b Author: Semen Protsenko semen.protsenko@linaro.org Date: Wed Apr 20 12:05:59 2016 +0300
ti_armv7_common.h: Fix U-Boot location on eMMC
According to common eMMC partition table for Android boot (see PARTS_DEFAULT definition in include/configs/dra7xx_evm.h), "bootloader" partition (where u-boot.img is stored) starts at 256 KiB. Which is equal to 512 sectors (as 1 MMC sector size is 512 bytes).
This patch fixes CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR constant so that it points to correct address of "bootloader" partition and SPL is able to read, parse and run u-boot.img correctly.
This change was originally done as part of patch [1] in omapzoom u-boot. Without this patch, SPL fails to parse U-Boot header with next error:
mkimage signature not found - ih_magic = 4814325a
While at it, also fix U-Boot partition size, which is 384 KiB (as stated in include/configs/dra7xx_evm.h).
[1] http://omapzoom.org/?p=repo/u-boot.git;a=commit;h=742b82d0c0aa0ed8096c2225a0...
Signed-off-by: Sam Protsenko semen.protsenko@linaro.org Reviewed-by: Tom Rini trini@konsulko.com
:040000 040000 654bed461e899940d8c2acab63de79cbb39551fb 713db2df931848d19ce3f41602b79f7197dd9646 M include
On Mon, May 02, 2016 at 09:08:27AM +0200, Alexander Graf wrote:
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com: > On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com > wrote: >> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: >> >>> Does anyone with an OMAP3 board have any issues with this patch? I >>> will admit I haven't stayed on top of stuff due to moving, and >>> other >>> issues at home, but I pulled down the master to reviews some on >>> related stuff, and found that master doesn't boot. I used git >>> bisect >>> this morning and it narrowed down a problem with booting to this >>> patch. >>> >>> With the patch, I get: >>> >>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >>> Trying to boot from MMC >> OK. Do you have u-boot.bin or u-boot.img (which?) written to the >> raw >> offset in MMC or from filesystem? Based on the log it looks like >> filesystem. > I have u-boot.img copied to the fatfs on the card, but I didn't > put it > in a specific location. > > I never used to have to do that. Is this a new behavior and is it > documented somewhere? > > adam You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I've tried to see why things don't work and dug out my beagle xm from the shelf. Unfortunately, I don't even get it to boot at all with current master. Bisecting points me to the commit below which makes sense - we simply change the raw offset on SD for all OMAP systems.
Is that a good idea? It probably breaks pretty much every user that uses raw boot right now.
No, see the other thread about this one (The -rc release email), it's going to be reverted since I thought it was doing something more clever than it was, oops.
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com:
On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com wrote: > On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: > >> Does anyone with an OMAP3 board have any issues with this patch? I >> will admit I haven't stayed on top of stuff due to moving, and >> other >> issues at home, but I pulled down the master to reviews some on >> related stuff, and found that master doesn't boot. I used git >> bisect >> this morning and it narrowed down a problem with booting to this >> patch. >> >> With the patch, I get: >> >> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >> Trying to boot from MMC > OK. Do you have u-boot.bin or u-boot.img (which?) written to the > raw > offset in MMC or from filesystem? Based on the log it looks like > filesystem. I have u-boot.img copied to the fatfs on the card, but I didn't put it in a specific location.
I never used to have to do that. Is this a new behavior and is it documented somewhere?
adam
You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I'm puzzled. The raw boot path can basically never fail, since all it does is to verify whether we could read the sectors - and that usually works:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f...
So how could we ever fall back from raw to fs mode? I can see how we could fall back from fs loading to raw loading, but the other way around?
Guillaume, you posted a patch a while back to handle exactly that case. How did you get there?
The only real "fix" to this I can think of is to reverse the fallback path. Load from fs, fall back to raw. Because with file systems we know whether something failed.
Alex
Le 02/05/2016 09:35, Alexander Graf a écrit :
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
Hi Adam,
2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com: > On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com > wrote: >> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: >> >>> Does anyone with an OMAP3 board have any issues with this patch? I >>> will admit I haven't stayed on top of stuff due to moving, and >>> other >>> issues at home, but I pulled down the master to reviews some on >>> related stuff, and found that master doesn't boot. I used git >>> bisect >>> this morning and it narrowed down a problem with booting to this >>> patch. >>> >>> With the patch, I get: >>> >>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >>> Trying to boot from MMC >> OK. Do you have u-boot.bin or u-boot.img (which?) written to the >> raw >> offset in MMC or from filesystem? Based on the log it looks like >> filesystem. > I have u-boot.img copied to the fatfs on the card, but I didn't > put it > in a specific location. > > I never used to have to do that. Is this a new behavior and is it > documented somewhere? > > adam You are expecting to boot it from FAT, but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
Can you fix the function to return MMCSD_MODE_FS?
This commit changed to allow to load raw U-Boot image, so MMCSD_MODE_RAW never fails.
So, you can no longer rely on the former behavior "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I'm puzzled. The raw boot path can basically never fail, since all it does is to verify whether we could read the sectors - and that usually works:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f...
So how could we ever fall back from raw to fs mode? I can see how we could fall back from fs loading to raw loading, but the other way around?
Guillaume, you posted a patch a while back to handle exactly that case. How did you get there?
I think there is (was?) a signature or a header check or something like this.
I did not check latest git version. Maybe a patch removed a check?
Guillaume
The only real "fix" to this I can think of is to reverse the fallback path. Load from fs, fall back to raw. Because with file systems we know whether something failed.
Alex
On 05/02/2016 10:58 AM, Guillaume Gardet wrote:
Le 02/05/2016 09:35, Alexander Graf a écrit :
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
On 05/01/2016 03:37 AM, Masahiro Yamada wrote: > Hi Adam, > > > 2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com: >> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com >> wrote: >>> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: >>> >>>> Does anyone with an OMAP3 board have any issues with this >>>> patch? I >>>> will admit I haven't stayed on top of stuff due to moving, and >>>> other >>>> issues at home, but I pulled down the master to reviews some on >>>> related stuff, and found that master doesn't boot. I used git >>>> bisect >>>> this morning and it narrowed down a problem with booting to this >>>> patch. >>>> >>>> With the patch, I get: >>>> >>>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >>>> Trying to boot from MMC >>> OK. Do you have u-boot.bin or u-boot.img (which?) written to the >>> raw >>> offset in MMC or from filesystem? Based on the log it looks like >>> filesystem. >> I have u-boot.img copied to the fatfs on the card, but I didn't >> put it >> in a specific location. >> >> I never used to have to do that. Is this a new behavior and is it >> documented somewhere? >> >> adam > You are expecting to boot it from FAT, > but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW. > > Can you fix the function to return MMCSD_MODE_FS? > > > > This commit changed to allow to load raw U-Boot image, > so MMCSD_MODE_RAW never fails. > > So, you can no longer rely on the former behavior > "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS". > So everyone loading MLO from the FAT filesystem is now wrong? I am trying to understand how this came into being the default.
... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I'm puzzled. The raw boot path can basically never fail, since all it does is to verify whether we could read the sectors - and that usually works:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f...
So how could we ever fall back from raw to fs mode? I can see how we could fall back from fs loading to raw loading, but the other way around?
Guillaume, you posted a patch a while back to handle exactly that case. How did you get there?
I think there is (was?) a signature or a header check or something like this.
I did not check latest git version. Maybe a patch removed a check?
I can't find any patch that removes such a check. Hrm.
So Tom, how would you like to roll this? We can either
1) Check raw after fs, default to fs and revert my patch or 2) Leave fs boot broken (regression) or 3) Leave raw boot broken (same as 2016.03)
Given that release is in 1 week, I'm wary on option 1. I also don't like regressions. So how about we revert my patch and fix it up with fs-before-raw boot for 2016.07?
I'm also not quite sure what to do about the other patch I mentioned earlier that moves the u-boot.img offset. Maybe revert for this release and add a fallback sector to read from if we couldn't find the header?
Alex
Le 02/05/2016 11:12, Alexander Graf a écrit :
On 05/02/2016 10:58 AM, Guillaume Gardet wrote:
Le 02/05/2016 09:35, Alexander Graf a écrit :
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote:
On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote: > On 05/01/2016 03:37 AM, Masahiro Yamada wrote: >> Hi Adam, >> >> >> 2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com: >>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com >>> wrote: >>>> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: >>>> >>>>> Does anyone with an OMAP3 board have any issues with this patch? I >>>>> will admit I haven't stayed on top of stuff due to moving, and >>>>> other >>>>> issues at home, but I pulled down the master to reviews some on >>>>> related stuff, and found that master doesn't boot. I used git >>>>> bisect >>>>> this morning and it narrowed down a problem with booting to this >>>>> patch. >>>>> >>>>> With the patch, I get: >>>>> >>>>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >>>>> Trying to boot from MMC >>>> OK. Do you have u-boot.bin or u-boot.img (which?) written to the >>>> raw >>>> offset in MMC or from filesystem? Based on the log it looks like >>>> filesystem. >>> I have u-boot.img copied to the fatfs on the card, but I didn't >>> put it >>> in a specific location. >>> >>> I never used to have to do that. Is this a new behavior and is it >>> documented somewhere? >>> >>> adam >> You are expecting to boot it from FAT, >> but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW. >> >> Can you fix the function to return MMCSD_MODE_FS? >> >> >> >> This commit changed to allow to load raw U-Boot image, >> so MMCSD_MODE_RAW never fails. >> >> So, you can no longer rely on the former behavior >> "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS". >> > So everyone loading MLO from the FAT filesystem is now wrong? I am > trying to understand how this came into being the default. ... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I wonder if: commit 22d90d560a2b01c47f180e196e6c6485eb8e65db Author: Alexander Graf agraf@suse.de Date: Tue Mar 1 09:56:34 2016 +0100
omap3: Use raw SPL by default for mmc1Isn't part of what's going wrong now.
Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I'm puzzled. The raw boot path can basically never fail, since all it does is to verify whether we could read the sectors - and that usually works:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f...
So how could we ever fall back from raw to fs mode? I can see how we could fall back from fs loading to raw loading, but the other way around?
Guillaume, you posted a patch a while back to handle exactly that case. How did you get there?
I think there is (was?) a signature or a header check or something like this.
I did not check latest git version. Maybe a patch removed a check?
I can't find any patch that removes such a check. Hrm.
Beaglebone black does not boot either with u-boot on FS. So, I did a git bisect and it returns the following patch as the problem: ********************************************************************** commit 4976f4827546154bb296dd0fb33b2cdff94be0c1 Author: Masahiro Yamada yamada.masahiro@socionext.com Date: Wed Mar 16 12:10:00 2016 +0900
spl_mmc: allow to load raw image
The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, mmc_load_image_raw_sector() only accepts a U-Boot legacy image or an FIT image, preventing us from loading a raw image.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Tom Rini trini@konsulko.com **********************************************************************
Guillaume
So Tom, how would you like to roll this? We can either
- Check raw after fs, default to fs and revert my patch or
- Leave fs boot broken (regression) or
- Leave raw boot broken (same as 2016.03)
Given that release is in 1 week, I'm wary on option 1. I also don't like regressions. So how about we revert my patch and fix it up with fs-before-raw boot for 2016.07?
I'm also not quite sure what to do about the other patch I mentioned earlier that moves the u-boot.img offset. Maybe revert for this release and add a fallback sector to read from if we couldn't find the header?
Alex
On 05/02/2016 11:45 AM, Guillaume Gardet wrote:
Le 02/05/2016 11:12, Alexander Graf a écrit :
On 05/02/2016 10:58 AM, Guillaume Gardet wrote:
Le 02/05/2016 09:35, Alexander Graf a écrit :
On 02.05.16 04:29, Derald D. Woods wrote:
On 05/01/2016 09:17 PM, Derald D. Woods wrote:
On 05/01/2016 08:57 PM, Tom Rini wrote: > On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote: >> On 05/01/2016 03:37 AM, Masahiro Yamada wrote: >>> Hi Adam, >>> >>> >>> 2016-04-30 3:06 GMT+09:00 Adam Ford aford173@gmail.com: >>>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini trini@konsulko.com >>>> wrote: >>>>> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote: >>>>> >>>>>> Does anyone with an OMAP3 board have any issues with this >>>>>> patch? I >>>>>> will admit I haven't stayed on top of stuff due to moving, and >>>>>> other >>>>>> issues at home, but I pulled down the master to reviews >>>>>> some on >>>>>> related stuff, and found that master doesn't boot. I used git >>>>>> bisect >>>>>> this morning and it narrowed down a problem with booting to >>>>>> this >>>>>> patch. >>>>>> >>>>>> With the patch, I get: >>>>>> >>>>>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27) >>>>>> Trying to boot from MMC >>>>> OK. Do you have u-boot.bin or u-boot.img (which?) written >>>>> to the >>>>> raw >>>>> offset in MMC or from filesystem? Based on the log it looks >>>>> like >>>>> filesystem. >>>> I have u-boot.img copied to the fatfs on the card, but I didn't >>>> put it >>>> in a specific location. >>>> >>>> I never used to have to do that. Is this a new behavior and >>>> is it >>>> documented somewhere? >>>> >>>> adam >>> You are expecting to boot it from FAT, >>> but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW. >>> >>> Can you fix the function to return MMCSD_MODE_FS? >>> >>> >>> >>> This commit changed to allow to load raw U-Boot image, >>> so MMCSD_MODE_RAW never fails. >>> >>> So, you can no longer rely on the former behavior >>> "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS". >>> >> So everyone loading MLO from the FAT filesystem is now wrong? I am >> trying to understand how this came into being the default. > ... yes, we can't break the case of SPL+U-Boot being on FS on > MMC1. I > wonder if: > commit 22d90d560a2b01c47f180e196e6c6485eb8e65db > Author: Alexander Graf agraf@suse.de > Date: Tue Mar 1 09:56:34 2016 +0100 > > omap3: Use raw SPL by default for mmc1 > > Isn't part of what's going wrong now. > Reverting that commit worked for me!
---8<----------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05) Trying to boot from MMC1 reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img
U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz Logic DM37x/OMAP35x reference board + LPDDR/NAND
---8<----------------------------------------------
Derald
I should also mention that I have Tom's patch from this mailing list thread:
"[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I'm puzzled. The raw boot path can basically never fail, since all it does is to verify whether we could read the sectors - and that usually works:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f...
So how could we ever fall back from raw to fs mode? I can see how we could fall back from fs loading to raw loading, but the other way around?
Guillaume, you posted a patch a while back to handle exactly that case. How did you get there?
I think there is (was?) a signature or a header check or something like this.
I did not check latest git version. Maybe a patch removed a check?
I can't find any patch that removes such a check. Hrm.
Beaglebone black does not boot either with u-boot on FS. So, I did a git bisect and it returns the following patch as the problem:
commit 4976f4827546154bb296dd0fb33b2cdff94be0c1 Author: Masahiro Yamada yamada.masahiro@socionext.com Date: Wed Mar 16 12:10:00 2016 +0900
spl_mmc: allow to load raw image The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, mmc_load_image_raw_sector() only accepts a U-Boot legacy image or an FIT image, preventing us from loading a raw image. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Thanks a lot for the bisect! I guess we could also revert that patch and break socio support. Hrm :). Tom?
Alex
On Mon, May 02, 2016 at 11:12:11AM +0200, Alexander Graf wrote:
[snip]
So Tom, how would you like to roll this? We can either
- Check raw after fs, default to fs and revert my patch or
- Leave fs boot broken (regression) or
- Leave raw boot broken (same as 2016.03)
Given that release is in 1 week, I'm wary on option 1. I also don't like regressions. So how about we revert my patch and fix it up with fs-before-raw boot for 2016.07?
So, we need to revert ef5ebe951bec72 which is what changed the raw offset. I think we also need to revert 22d90d560a2b which yes, will go back to breaking raw MLO + FS U-Boot. The problem here is that we have the fallback case of "load hard-coded size from MMC, assume u-boot.bin is raw". So raw will never fail. Marek posted a series late last week that would address this by letting us say that we want to call an invalid signature for U-Boot bad and continue on to other methods. I'm wondering if this doesn't go far enough actually and we should say that unless specifically set (like CONFIG_SPL_NAND_RAW_ONLY does), we don't assume it's good. It's been a long time since we didn't default to making a u-boot.img and SPL has "always" supported both. It was mainly legacy code for letting people mix-and-match SPL + X-Loader (and go back and forth). I'm leaning towards making this an opt-in thing and introduce CONFIG_SPL_MMC_BIN_ONLY (and rename the NAND one) as the logic is getting really really convoluted now.
On 02.05.16 18:14, Tom Rini wrote:
On Mon, May 02, 2016 at 11:12:11AM +0200, Alexander Graf wrote:
[snip]
So Tom, how would you like to roll this? We can either
- Check raw after fs, default to fs and revert my patch or
- Leave fs boot broken (regression) or
- Leave raw boot broken (same as 2016.03)
Given that release is in 1 week, I'm wary on option 1. I also don't like regressions. So how about we revert my patch and fix it up with fs-before-raw boot for 2016.07?
So, we need to revert ef5ebe951bec72 which is what changed the raw offset. I think we also need to revert 22d90d560a2b which yes, will go back to breaking raw MLO + FS U-Boot. The problem here is that we have the fallback case of "load hard-coded size from MMC, assume u-boot.bin is raw". So raw will never fail. Marek posted a series late last week that would address this by letting us say that we want to call an invalid signature for U-Boot bad and continue on to other methods. I'm wondering if this doesn't go far enough actually and we should say that unless specifically set (like CONFIG_SPL_NAND_RAW_ONLY does), we don't assume it's good. It's been a long time since we didn't default to making a u-boot.img and SPL has "always" supported both. It was mainly legacy code for letting people mix-and-match SPL + X-Loader (and go back and forth). I'm leaning towards making this an opt-in thing and introduce CONFIG_SPL_MMC_BIN_ONLY (and rename the NAND one) as the logic is getting really really convoluted now.
I agree with the plan :)
Alex
participants (6)
-
Adam Ford -
Alexander Graf -
Derald D. Woods -
Guillaume Gardet -
Masahiro Yamada -
Tom Rini