| Message ID | 1441734192-21326-3-git-send-email-fabio.estevam@freescale.com |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Stefano Babic |
| Headers | show |
Hi Fabio, On Tue, Sep 08, 2015 at 02:43:11PM -0300, Fabio Estevam wrote: >If the SD card does not contain the u-boot.img then we get the >following error: > >U-Boot SPL 2015.10-rc2-23947-g7ad5930 (Sep 08 2015 - 14:10:29) >** Partition 1 not valid on device 0 ** >spl_register_fat_device: fat register err - -1 >spl_load_image_fat: error reading image u-boot.img, err - -1 > >Remove CONFIG_SPL_FAT_SUPPORT and let CONFIG_SPL_MMC_SUPPORT do the >job. > >Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> >--- > include/configs/mx6ul_14x14_evk.h | 1 - > 1 file changed, 1 deletion(-) > >diff --git a/include/configs/mx6ul_14x14_evk.h b/include/configs/mx6ul_14x14_evk.h >index 4a2280b..e785925 100644 >--- a/include/configs/mx6ul_14x14_evk.h >+++ b/include/configs/mx6ul_14x14_evk.h >@@ -17,7 +17,6 @@ > /* SPL options */ > #define CONFIG_SPL_LIBCOMMON_SUPPORT > #define CONFIG_SPL_MMC_SUPPORT >-#define CONFIG_SPL_FAT_SUPPORT Can we keep this? Without this, we need to burn u-boot.img into sdcard, but i prefer to load u-boot.img from the fat partition. Regards, Peng. > #include "imx6_spl.h" > > #define CONFIG_ROM_UNIFIED_SECTIONS >-- >1.9.1 >
Hi Peng, Fabio, On 09/09/2015 05:29, Peng Fan wrote: > Hi Fabio, > > On Tue, Sep 08, 2015 at 02:43:11PM -0300, Fabio Estevam wrote: >> If the SD card does not contain the u-boot.img then we get the >> following error: >> >> U-Boot SPL 2015.10-rc2-23947-g7ad5930 (Sep 08 2015 - 14:10:29) >> ** Partition 1 not valid on device 0 ** >> spl_register_fat_device: fat register err - -1 >> spl_load_image_fat: error reading image u-boot.img, err - -1 >> >> Remove CONFIG_SPL_FAT_SUPPORT and let CONFIG_SPL_MMC_SUPPORT do the >> job. >> >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> >> --- >> include/configs/mx6ul_14x14_evk.h | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/include/configs/mx6ul_14x14_evk.h b/include/configs/mx6ul_14x14_evk.h >> index 4a2280b..e785925 100644 >> --- a/include/configs/mx6ul_14x14_evk.h >> +++ b/include/configs/mx6ul_14x14_evk.h >> @@ -17,7 +17,6 @@ >> /* SPL options */ >> #define CONFIG_SPL_LIBCOMMON_SUPPORT >> #define CONFIG_SPL_MMC_SUPPORT >> -#define CONFIG_SPL_FAT_SUPPORT > > Can we keep this? Without this, we need to burn u-boot.img into sdcard, but > i prefer to load u-boot.img from the fat partition. Well, how U-Boot is stored on the SD-Card is a decision that you take based on the balance safety against comfortably. Both are ok on my side. If we put u-boot.img in raw SD at a fixed address, it is very uncommon that a user destroy accessing it. On the other side, putting it into a FAT partition makes easier to update for everybody - just copying it into a disk. The issue reported by Fabio is like a corrupted SD-Card - the SD-Card does not contain the correct bootloader and it is ok if it does not boot or hangs. Both ways have advantages and disadvantages. Regards, Stefano
Hi Peng and Stefano, On Wed, Sep 9, 2015 at 4:37 AM, Stefano Babic <sbabic@denx.de> wrote: >>> #define CONFIG_SPL_LIBCOMMON_SUPPORT >>> #define CONFIG_SPL_MMC_SUPPORT >>> -#define CONFIG_SPL_FAT_SUPPORT >> >> Can we keep this? Without this, we need to burn u-boot.img into sdcard, but >> i prefer to load u-boot.img from the fat partition. > > Well, how U-Boot is stored on the SD-Card is a decision that you take > based on the balance safety against comfortably. > Both are ok on my side. If we put u-boot.img in raw SD at a fixed > address, it is very uncommon that a user destroy accessing it. On the > other side, putting it into a FAT partition makes easier to update for > everybody - just copying it into a disk. > The issue reported by Fabio is like a corrupted SD-Card - the SD-Card > does not contain the correct bootloader and it is ok if it does not boot > or hangs. Both ways have advantages and disadvantages. I am trying to get this more standard across Freescale boards. Like it was pointed out here: http://lists.denx.de/pipermail/u-boot/2015-August/222061.html I think it can be confusing for the end user if each FSL board has a different way for booting u-boot.img, so that's why I chose the common approach here. Regards, Fabio Estevam
On Wed, Sep 9, 2015 at 9:26 AM, Fabio Estevam <festevam@gmail.com> wrote: > On Wed, Sep 9, 2015 at 4:37 AM, Stefano Babic <sbabic@denx.de> wrote: >>>> #define CONFIG_SPL_LIBCOMMON_SUPPORT >>>> #define CONFIG_SPL_MMC_SUPPORT >>>> -#define CONFIG_SPL_FAT_SUPPORT >>> >>> Can we keep this? Without this, we need to burn u-boot.img into sdcard, but >>> i prefer to load u-boot.img from the fat partition. >> >> Well, how U-Boot is stored on the SD-Card is a decision that you take >> based on the balance safety against comfortably. >> Both are ok on my side. If we put u-boot.img in raw SD at a fixed >> address, it is very uncommon that a user destroy accessing it. On the >> other side, putting it into a FAT partition makes easier to update for >> everybody - just copying it into a disk. >> The issue reported by Fabio is like a corrupted SD-Card - the SD-Card >> does not contain the correct bootloader and it is ok if it does not boot >> or hangs. Both ways have advantages and disadvantages. > > I am trying to get this more standard across Freescale boards. > > Like it was pointed out here: > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html > > I think it can be confusing for the end user if each FSL board has a > different way for booting u-boot.img, so that's why I chose the common > approach here. I support Fabio request here; it is important to have a standard across evaluation boards.
On Wed, Sep 09, 2015 at 03:36:38PM +0200, Stefano Babic wrote: >Hi Fabio, > >On 09/09/2015 14:26, Fabio Estevam wrote: >> Hi Peng and Stefano, >> >> On Wed, Sep 9, 2015 at 4:37 AM, Stefano Babic <sbabic@denx.de> wrote: >> >>>>> #define CONFIG_SPL_LIBCOMMON_SUPPORT >>>>> #define CONFIG_SPL_MMC_SUPPORT >>>>> -#define CONFIG_SPL_FAT_SUPPORT >>>> >>>> Can we keep this? Without this, we need to burn u-boot.img into sdcard, but >>>> i prefer to load u-boot.img from the fat partition. >>> >>> Well, how U-Boot is stored on the SD-Card is a decision that you take >>> based on the balance safety against comfortably. >>> Both are ok on my side. If we put u-boot.img in raw SD at a fixed >>> address, it is very uncommon that a user destroy accessing it. On the >>> other side, putting it into a FAT partition makes easier to update for >>> everybody - just copying it into a disk. >>> The issue reported by Fabio is like a corrupted SD-Card - the SD-Card >>> does not contain the correct bootloader and it is ok if it does not boot >>> or hangs. Both ways have advantages and disadvantages. >> >> I am trying to get this more standard across Freescale boards. Fabio and Stefano, I agree that we have a common way for Freescale boards. But why not choose SPL_FAT? In future we may add QSPI or SPI SPL boot, then we also need to burn u-boot.img as a raw image to sd card? or burn it to spi/qspi chips? I think the easy way is FAT load from mmc. Also see the following, #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 138 /* offset 69KB */ #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) It u-boot.img is bigger than 400KB, we also need to change the macro definitions, why not choose FAT and we do not need to care about that u-boot.img may be bigger than 400KB, right? And 400KB is a fixed size, whether u-boot.img is saying 100KB or 200KB. In future, if our mfgtool need to support SPL, each time we need to modify related macro in uboot, we need to uppdate mfgtool. We suffer for changing both. Regards, Peng. >> >> Like it was pointed out here: >> http://lists.denx.de/pipermail/u-boot/2015-August/222061.html >> >> I think it can be confusing for the end user if each FSL board has a >> different way for booting u-boot.img, so that's why I chose the common >> approach here. > >Absolutely - the user will be confused. I am fine with any decision you >take on that sense. IMHO in Freescale's boards (I mean, since MX51 and >later) has always written u-boot in raw mode. My vote goes for removing >the flag, then. > >Regards, >Stefano Babic > >-- >===================================================================== >DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de >=====================================================================
Hi Fabio, On 09/09/2015 14:26, Fabio Estevam wrote: > Hi Peng and Stefano, > > On Wed, Sep 9, 2015 at 4:37 AM, Stefano Babic <sbabic@denx.de> wrote: > >>>> #define CONFIG_SPL_LIBCOMMON_SUPPORT >>>> #define CONFIG_SPL_MMC_SUPPORT >>>> -#define CONFIG_SPL_FAT_SUPPORT >>> >>> Can we keep this? Without this, we need to burn u-boot.img into sdcard, but >>> i prefer to load u-boot.img from the fat partition. >> >> Well, how U-Boot is stored on the SD-Card is a decision that you take >> based on the balance safety against comfortably. >> Both are ok on my side. If we put u-boot.img in raw SD at a fixed >> address, it is very uncommon that a user destroy accessing it. On the >> other side, putting it into a FAT partition makes easier to update for >> everybody - just copying it into a disk. >> The issue reported by Fabio is like a corrupted SD-Card - the SD-Card >> does not contain the correct bootloader and it is ok if it does not boot >> or hangs. Both ways have advantages and disadvantages. > > I am trying to get this more standard across Freescale boards. > > Like it was pointed out here: > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html > > I think it can be confusing for the end user if each FSL board has a > different way for booting u-boot.img, so that's why I chose the common > approach here. Absolutely - the user will be confused. I am fine with any decision you take on that sense. IMHO in Freescale's boards (I mean, since MX51 and later) has always written u-boot in raw mode. My vote goes for removing the flag, then. Regards, Stefano Babic
Hi Peng, On Wed, Sep 9, 2015 at 10:33 AM, Peng Fan <b51431@freescale.com> wrote: > Fabio and Stefano, > > I agree that we have a common way for Freescale boards. But why > not choose SPL_FAT? In future we may add QSPI or SPI SPL boot, then we We have boards that boot from SPI SPL today and this is well supported. > also need to burn u-boot.img as a raw image to sd card? You had to write SPL as raw image, so you can do the same for u-boot.img for a more standard behaviour across different boards. Also, you prefer FAT for storing u-boot.img, but why not EXT3 or EXT4? We all know this is very flexible and vaild options, but we are trying to keep things consistent. or burn it > to spi/qspi chips? I think the easy way is FAT load from mmc. SPI is another story and it is well supported today in SPL. You just need to write SPL at offset 1k and u-boot.img at offset CONFIG_SYS_SPI_U_BOOT_OFFS (usually 64kB so that it starts in a sector boundary). > Also see the following, > #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 138 /* offset 69KB */ > #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */ > #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 > #define CONFIG_SYS_MONITOR_LEN (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024) > > It u-boot.img is bigger than 400KB, we also need to change the macro definitions, > why not choose FAT and we do not need to care about that u-boot.img may be bigger > than 400KB, right? And 400KB is a fixed size, whether u-boot.img is saying 100KB or 200KB. The size constraint also exists when you boot from a FAT partition as you need to decide on the partition size for the FAT area. The main point here is to be able to use the same solution for many boards as possible. Peter Robinson put a lot of effort into moving the config options into mx6_common.h. If we start to store u-boot.img in a FAT partition only for this mx6ul evk board that would be a step in the opposite direction of consolidation. > In future, if our mfgtool need to support SPL, each time we need to modify related macro in uboot, > we need to uppdate mfgtool. We suffer for changing both. mfgtool is not the only tool out there and I see no reason why it can't flash u-boot.img in a raw partition. Regards, Fabio Estevam
On 09/09/2015 14:26, Fabio Estevam wrote: > Hi Peng and Stefano, > > On Wed, Sep 9, 2015 at 4:37 AM, Stefano Babic <sbabic@denx.de> wrote: > >>>> #define CONFIG_SPL_LIBCOMMON_SUPPORT >>>> #define CONFIG_SPL_MMC_SUPPORT >>>> -#define CONFIG_SPL_FAT_SUPPORT >>> >>> Can we keep this? Without this, we need to burn u-boot.img into sdcard, but >>> i prefer to load u-boot.img from the fat partition. >> >> Well, how U-Boot is stored on the SD-Card is a decision that you take >> based on the balance safety against comfortably. >> Both are ok on my side. If we put u-boot.img in raw SD at a fixed >> address, it is very uncommon that a user destroy accessing it. On the >> other side, putting it into a FAT partition makes easier to update for >> everybody - just copying it into a disk. >> The issue reported by Fabio is like a corrupted SD-Card - the SD-Card >> does not contain the correct bootloader and it is ok if it does not boot >> or hangs. Both ways have advantages and disadvantages. > > I am trying to get this more standard across Freescale boards. > > Like it was pointed out here: > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html > > I think it can be confusing for the end user if each FSL board has a > different way for booting u-boot.img, so that's why I chose the common > approach here. > Most of us agree to unify i.MX boards using storing the bootloader as raw data. Applied to u-boot-imx, thanks ! Best regards, Stefano Babic
diff --git a/include/configs/mx6ul_14x14_evk.h b/include/configs/mx6ul_14x14_evk.h index 4a2280b..e785925 100644 --- a/include/configs/mx6ul_14x14_evk.h +++ b/include/configs/mx6ul_14x14_evk.h @@ -17,7 +17,6 @@ /* SPL options */ #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_MMC_SUPPORT -#define CONFIG_SPL_FAT_SUPPORT #include "imx6_spl.h" #define CONFIG_ROM_UNIFIED_SECTIONS
If the SD card does not contain the u-boot.img then we get the following error: U-Boot SPL 2015.10-rc2-23947-g7ad5930 (Sep 08 2015 - 14:10:29) ** Partition 1 not valid on device 0 ** spl_register_fat_device: fat register err - -1 spl_load_image_fat: error reading image u-boot.img, err - -1 Remove CONFIG_SPL_FAT_SUPPORT and let CONFIG_SPL_MMC_SUPPORT do the job. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> --- include/configs/mx6ul_14x14_evk.h | 1 - 1 file changed, 1 deletion(-)