[U-Boot] [PATCH 1/4] thermal: imx_thermal: Do not print on error
It is not very useful to have the message below on every boot (especially when we are using early silicon):
U-Boot 2015.10-rc2-23945-g37cf215 (Sep 08 2015 - 14:12:14 -0300)
CPU: Freescale i.MX6UL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C)CPU: Thermal invalid data, fuse: 0x0 - invalid sensor device
, so turn the error message into debug level.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- drivers/thermal/imx_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c index 3c6c967..04c43d7 100644 --- a/drivers/thermal/imx_thermal.c +++ b/drivers/thermal/imx_thermal.c @@ -159,7 +159,7 @@ static int imx_thermal_probe(struct udevice *dev)
/* Check for valid fuse */ if (fuse == 0 || fuse == ~0) { - printf("CPU: Thermal invalid data, fuse: 0x%x\n", fuse); + debug("CPU: Thermal invalid data, fuse: 0x%x\n", fuse); return -EPERM; }
It is not very useful to have the message below on every boot (especially when we are using early silicon):
U-Boot 2015.10-rc2-23945-g37cf215 (Sep 08 2015 - 14:12:14 -0300)
CPU: Freescale i.MX6UL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C)CPU: Thermal invalid data, fuse: 0x0 - invalid sensor device
, so turn the error message into debug level.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- arch/arm/imx-common/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c index e27546c..667b3f7 100644 --- a/arch/arm/imx-common/cpu.c +++ b/arch/arm/imx-common/cpu.c @@ -205,9 +205,9 @@ int print_cpuinfo(void) if (!ret) printf(" at %dC\n", cpu_tmp); else - puts(" - invalid sensor data\n"); + debug(" - invalid sensor data\n"); } else { - puts(" - invalid sensor device\n"); + debug(" - invalid sensor device\n"); } #endif
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 #include "imx6_spl.h"
#define CONFIG_ROM_UNIFIED_SECTIONS
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.
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
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 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
Add a README file to help users getting started with the board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- board/freescale/mx6ul_14x14_evk/README | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 board/freescale/mx6ul_14x14_evk/README
diff --git a/board/freescale/mx6ul_14x14_evk/README b/board/freescale/mx6ul_14x14_evk/README new file mode 100644 index 0000000..a4c2753 --- /dev/null +++ b/board/freescale/mx6ul_14x14_evk/README @@ -0,0 +1,32 @@ +How to use U-boot on Freescale MX6UL 14x14 EVK +----------------------------------------------- + +- Build U-boot for MX6UL 14x14 EVK: + +$ make mrproper +$ make mx6ul_14x14_evk_defconfig +$ make + +This will generate the SPL image called SPL and the u-boot.img. + +- Flash the SPL image into the micro SD card: + +sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync + +- Flash the u-boot.img image into the micro SD card: + +sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync + +- Jumper settings: + +SW601: 0 0 1 0 +Sw602: 1 0 + +where 0 means bottom position and 1 means top position (from the +switch label numbers reference). + +- Connect the USB cable between the EVK and the PC for the console. +(The USB console connector is the one close the push buttons) + +- Insert the micro SD card in the board, power it up and U-boot messages should +come up.
On 08/09/2015 19:43, Fabio Estevam wrote:
It is not very useful to have the message below on every boot (especially when we are using early silicon):
U-Boot 2015.10-rc2-23945-g37cf215 (Sep 08 2015 - 14:12:14 -0300)
CPU: Freescale i.MX6UL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C)CPU: Thermal invalid data, fuse: 0x0
- invalid sensor device
, so turn the error message into debug level.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
drivers/thermal/imx_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c index 3c6c967..04c43d7 100644 --- a/drivers/thermal/imx_thermal.c +++ b/drivers/thermal/imx_thermal.c @@ -159,7 +159,7 @@ static int imx_thermal_probe(struct udevice *dev)
/* Check for valid fuse */ if (fuse == 0 || fuse == ~0) {
printf("CPU: Thermal invalid data, fuse: 0x%x\n", fuse);
debug("CPU: Thermal invalid data, fuse: 0x%x\n", fuse);
Applied to u-boot-imx, thanks !
Best regards, Stefano Babic
participants (5)
-
Fabio Estevam -
Fabio Estevam -
Otavio Salvador -
Peng Fan -
Stefano Babic