* [U-Boot] [PATCH] spl_mmc: allow to load raw image
@ 2016-02-29 11:31 Masahiro Yamada
2016-03-01 1:58 ` Tom Rini
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Masahiro Yamada @ 2016-02-29 11:31 UTC (permalink / raw)
To: u-boot
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 */
--
1.9.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [U-Boot] [PATCH] spl_mmc: allow to load raw image 2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada @ 2016-03-01 1:58 ` Tom Rini 2016-03-15 19:23 ` [U-Boot] " Tom Rini 2016-03-17 2:04 ` Tom Rini 2 siblings, 0 replies; 27+ messages in thread From: Tom Rini @ 2016-03-01 1:58 UTC (permalink / raw) To: u-boot 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> -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160229/be043f2c/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada 2016-03-01 1:58 ` Tom Rini @ 2016-03-15 19:23 ` Tom Rini 2016-03-16 3:10 ` Masahiro Yamada 2016-03-17 2:04 ` Tom Rini 2 siblings, 1 reply; 27+ messages in thread From: Tom Rini @ 2016-03-15 19:23 UTC (permalink / raw) To: u-boot 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! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/e3b369ca/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-03-15 19:23 ` [U-Boot] " Tom Rini @ 2016-03-16 3:10 ` Masahiro Yamada 0 siblings, 0 replies; 27+ messages in thread From: Masahiro Yamada @ 2016-03-16 3:10 UTC (permalink / raw) To: u-boot 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/ -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada 2016-03-01 1:58 ` Tom Rini 2016-03-15 19:23 ` [U-Boot] " Tom Rini @ 2016-03-17 2:04 ` Tom Rini 2016-03-17 16:07 ` Masahiro Yamada 2 siblings, 1 reply; 27+ messages in thread From: Tom Rini @ 2016-03-17 2:04 UTC (permalink / raw) To: u-boot 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! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160316/d49eba54/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-03-17 2:04 ` Tom Rini @ 2016-03-17 16:07 ` Masahiro Yamada 2016-03-17 16:12 ` Tom Rini 0 siblings, 1 reply; 27+ messages in thread From: Masahiro Yamada @ 2016-03-17 16:07 UTC (permalink / raw) To: u-boot 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. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-03-17 16:07 ` Masahiro Yamada @ 2016-03-17 16:12 ` Tom Rini 2016-04-29 14:59 ` Adam Ford 0 siblings, 1 reply; 27+ messages in thread From: Tom Rini @ 2016-03-17 16:12 UTC (permalink / raw) To: u-boot 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160317/ae3d3218/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-03-17 16:12 ` Tom Rini @ 2016-04-29 14:59 ` Adam Ford 2016-04-29 17:53 ` Tom Rini 0 siblings, 1 reply; 27+ messages in thread From: Adam Ford @ 2016-04-29 14:59 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-04-29 14:59 ` Adam Ford @ 2016-04-29 17:53 ` Tom Rini 2016-04-29 18:06 ` Adam Ford 0 siblings, 1 reply; 27+ messages in thread From: Tom Rini @ 2016-04-29 17:53 UTC (permalink / raw) To: 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160429/65a627e5/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-04-29 17:53 ` Tom Rini @ 2016-04-29 18:06 ` Adam Ford 2016-04-29 18:06 ` Tom Rini 2016-05-01 8:37 ` Masahiro Yamada 0 siblings, 2 replies; 27+ messages in thread From: Adam Ford @ 2016-04-29 18:06 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-04-29 18:06 ` Adam Ford @ 2016-04-29 18:06 ` Tom Rini 2016-05-01 8:37 ` Masahiro Yamada 1 sibling, 0 replies; 27+ messages in thread From: Tom Rini @ 2016-04-29 18:06 UTC (permalink / raw) To: u-boot 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160429/2c7d51cd/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-04-29 18:06 ` Adam Ford 2016-04-29 18:06 ` Tom Rini @ 2016-05-01 8:37 ` Masahiro Yamada 2016-05-01 13:46 ` Tom Rini 2016-05-02 1:32 ` Derald D. Woods 1 sibling, 2 replies; 27+ messages in thread From: Masahiro Yamada @ 2016-05-01 8:37 UTC (permalink / raw) To: u-boot 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". -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-01 8:37 ` Masahiro Yamada @ 2016-05-01 13:46 ` Tom Rini 2016-05-02 1:32 ` Derald D. Woods 1 sibling, 0 replies; 27+ messages in thread From: Tom Rini @ 2016-05-01 13:46 UTC (permalink / raw) To: u-boot 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160501/b6938763/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-01 8:37 ` Masahiro Yamada 2016-05-01 13:46 ` Tom Rini @ 2016-05-02 1:32 ` Derald D. Woods 2016-05-02 1:57 ` Tom Rini 1 sibling, 1 reply; 27+ messages in thread From: Derald D. Woods @ 2016-05-02 1:32 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 1:32 ` Derald D. Woods @ 2016-05-02 1:57 ` Tom Rini 2016-05-02 2:04 ` Masahiro Yamada 2016-05-02 2:17 ` Derald D. Woods 0 siblings, 2 replies; 27+ messages in thread From: Tom Rini @ 2016-05-02 1:57 UTC (permalink / raw) To: u-boot 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160501/db4ab53d/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 1:57 ` Tom Rini @ 2016-05-02 2:04 ` Masahiro Yamada 2016-05-02 2:17 ` Derald D. Woods 1 sibling, 0 replies; 27+ messages in thread From: Masahiro Yamada @ 2016-05-02 2:04 UTC (permalink / raw) To: u-boot 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 mmc1 > > Isn'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. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 1:57 ` Tom Rini 2016-05-02 2:04 ` Masahiro Yamada @ 2016-05-02 2:17 ` Derald D. Woods 2016-05-02 2:29 ` Derald D. Woods 1 sibling, 1 reply; 27+ messages in thread From: Derald D. Woods @ 2016-05-02 2:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 2:17 ` Derald D. Woods @ 2016-05-02 2:29 ` Derald D. Woods 2016-05-02 7:08 ` Alexander Graf 2016-05-02 7:35 ` Alexander Graf 0 siblings, 2 replies; 27+ messages in thread From: Derald D. Woods @ 2016-05-02 2:29 UTC (permalink / raw) To: u-boot 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. Derald ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 2:29 ` Derald D. Woods @ 2016-05-02 7:08 ` Alexander Graf 2016-05-02 12:44 ` Tom Rini 2016-05-02 7:35 ` Alexander Graf 1 sibling, 1 reply; 27+ messages in thread From: Alexander Graf @ 2016-05-02 7:08 UTC (permalink / raw) To: u-boot 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'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=742b82d0c0aa0ed8096c2225a00e9f350212efa9 Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> :040000 040000 654bed461e899940d8c2acab63de79cbb39551fb 713db2df931848d19ce3f41602b79f7197dd9646 M include ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 7:08 ` Alexander Graf @ 2016-05-02 12:44 ` Tom Rini 0 siblings, 0 replies; 27+ messages in thread From: Tom Rini @ 2016-05-02 12:44 UTC (permalink / raw) To: u-boot 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 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'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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160502/8bd73f77/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 2:29 ` Derald D. Woods 2016-05-02 7:08 ` Alexander Graf @ 2016-05-02 7:35 ` Alexander Graf 2016-05-02 8:58 ` Guillaume Gardet 1 sibling, 1 reply; 27+ messages in thread From: Alexander Graf @ 2016-05-02 7:35 UTC (permalink / raw) To: u-boot 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=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 7:35 ` Alexander Graf @ 2016-05-02 8:58 ` Guillaume Gardet 2016-05-02 9:12 ` Alexander Graf 0 siblings, 1 reply; 27+ messages in thread From: Guillaume Gardet @ 2016-05-02 8:58 UTC (permalink / raw) To: u-boot 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=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115 > > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 8:58 ` Guillaume Gardet @ 2016-05-02 9:12 ` Alexander Graf 2016-05-02 9:45 ` Guillaume Gardet 2016-05-02 16:14 ` Tom Rini 0 siblings, 2 replies; 27+ messages in thread From: Alexander Graf @ 2016-05-02 9:12 UTC (permalink / raw) To: u-boot 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=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115 >> >> >> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 9:12 ` Alexander Graf @ 2016-05-02 9:45 ` Guillaume Gardet 2016-05-02 11:21 ` Alexander Graf 2016-05-02 16:14 ` Tom Rini 1 sibling, 1 reply; 27+ messages in thread From: Guillaume Gardet @ 2016-05-02 9:45 UTC (permalink / raw) To: u-boot 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=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115 >>> >>> 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 > > 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 > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 9:45 ` Guillaume Gardet @ 2016-05-02 11:21 ` Alexander Graf 0 siblings, 0 replies; 27+ messages in thread From: Alexander Graf @ 2016-05-02 11:21 UTC (permalink / raw) To: u-boot 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=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115 >>>> >>>> >>>> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 9:12 ` Alexander Graf 2016-05-02 9:45 ` Guillaume Gardet @ 2016-05-02 16:14 ` Tom Rini 2016-05-02 21:19 ` Alexander Graf 1 sibling, 1 reply; 27+ messages in thread From: Tom Rini @ 2016-05-02 16:14 UTC (permalink / raw) To: u-boot 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 > > 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? 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160502/e0077641/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] spl_mmc: allow to load raw image 2016-05-02 16:14 ` Tom Rini @ 2016-05-02 21:19 ` Alexander Graf 0 siblings, 0 replies; 27+ messages in thread From: Alexander Graf @ 2016-05-02 21:19 UTC (permalink / raw) To: u-boot 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 >> >> 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? > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2016-05-02 21:19 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada 2016-03-01 1:58 ` Tom Rini 2016-03-15 19:23 ` [U-Boot] " Tom Rini 2016-03-16 3:10 ` Masahiro Yamada 2016-03-17 2:04 ` Tom Rini 2016-03-17 16:07 ` Masahiro Yamada 2016-03-17 16:12 ` Tom Rini 2016-04-29 14:59 ` Adam Ford 2016-04-29 17:53 ` Tom Rini 2016-04-29 18:06 ` Adam Ford 2016-04-29 18:06 ` Tom Rini 2016-05-01 8:37 ` Masahiro Yamada 2016-05-01 13:46 ` Tom Rini 2016-05-02 1:32 ` Derald D. Woods 2016-05-02 1:57 ` Tom Rini 2016-05-02 2:04 ` Masahiro Yamada 2016-05-02 2:17 ` Derald D. Woods 2016-05-02 2:29 ` Derald D. Woods 2016-05-02 7:08 ` Alexander Graf 2016-05-02 12:44 ` Tom Rini 2016-05-02 7:35 ` Alexander Graf 2016-05-02 8:58 ` Guillaume Gardet 2016-05-02 9:12 ` Alexander Graf 2016-05-02 9:45 ` Guillaume Gardet 2016-05-02 11:21 ` Alexander Graf 2016-05-02 16:14 ` Tom Rini 2016-05-02 21:19 ` Alexander Graf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox