[U-Boot] [PATCH 1/4] thermal: imx_thermal: Do not print on error

[U-Boot] [PATCH 1/4] thermal: imx_thermal: Do not print on error

[Fabio Estevam]

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;
 	}
 
-- 
1.9.1

[U-Boot] [PATCH 2/4] imx-common: cpu: Do not print on invalid temperature

[Fabio Estevam]

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
 
-- 
1.9.1

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Fabio Estevam]

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
-- 
1.9.1

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Peng Fan]

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
>

-- 

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Stefano Babic]

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

-- 
=====================================================================
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 at denx.de
=====================================================================

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Fabio Estevam]

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

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Otavio Salvador]

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Stefano Babic]

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

-- 
=====================================================================
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 at denx.de
=====================================================================

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Peng Fan]

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 at denx.de
>=====================================================================

-- 

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Fabio Estevam]

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

[U-Boot] [PATCH 3/4] mx6ul_14x14_evk: Remove CONFIG_SPL_FAT_SUPPORT

[Stefano Babic]

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


-- 
=====================================================================
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 at denx.de
=====================================================================

[U-Boot] [PATCH 4/4] mx6ul_14x14_evk: Add a README file

[Fabio Estevam]

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.
-- 
1.9.1

[U-Boot] [PATCH 1/4] thermal: imx_thermal: Do not print on error

[Stefano Babic]

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);
>  		return -EPERM;
>  	}
>  
> 

Applied to u-boot-imx, thanks !

Best 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 at denx.de
=====================================================================