June 2012 - U-Boot

[U-Boot] [PATCH 01/24] mxc_i2c: fix i2c_imx_stop
by Troy Kisky 26 Jun '12

26 Jun '12

Instead of clearing 2 bits, all the other bits were set because '|=' was used instead of '&='. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- drivers/i2c/mxc_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Note: All patches in the series are based on the i2c/master branch even though only 1-18 will be applied there. diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index fc68062..c0c45fd 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -264,7 +264,7 @@ void i2c_imx_stop(void) /* Stop I2C transaction */ temp = readb(&i2c_regs->i2cr); - temp |= ~(I2CR_MSTA | I2CR_MTX); + temp &= ~(I2CR_MSTA | I2CR_MTX); writeb(temp, &i2c_regs->i2cr); i2c_imx_bus_busy(0); -- 1.7.9.5

7 54

[U-Boot] Powerpc MPC8641D enable debug hush.c
by Thies Peter Thiesen 25 Jun '12

25 Jun '12

Hi at All, I need a little help: My Hardware: Power PC MPC8641D Board freescale MPC8641hpcn I want to turn on the debug in file hush.c I see in source code “hush.c”, as example: debug_printf("parse_stream: ch=%c (%d) m=%d quote=%d - %c\n", ch >= ' ' ? ch : '.', ch, m, dest->quote, ctx->stack == NULL ? '*' : '.'); What I must do to enable the printing? (Options,and so on…Tutorial…. ) Were does the printing appear? Best Regards, Thiesen -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

2 1

Re: [U-Boot] [PATCH] arm: enable unaligned access on ARMv7
by Lucas Stach 25 Jun '12

25 Jun '12

Hi Albert, Am Montag, den 25.06.2012, 22:17 +0200 schrieb Albert ARIBAUD: > Hi Lucas, > > On Sun, 24 Jun 2012 08:30:19 +0200, Lucas Stach <dev(a)lynxeye.de> wrote: > > Hi Albert, > > > > Am Samstag, den 23.06.2012, 11:01 +0200 schrieb Albert ARIBAUD: > > [snip] > > > > >> But apart from this, we certainly have situations where we have > > > > >> unaligned accesses that are justified and could not be removed. > > > > >> [...] > > > > >> I cannot see how enabling a hardware feature can be seen as > > > > >> allowing of lax behaviour. As some of the USB structs are used > > > > >> to access hardware registers, we can not align every struct > > > > >> there. > > > > > > If the access is in true RAM, then we can always realign the data; > > > and I don't know of memory-mapped registers which would be > > > unaligned wrt their width. If some USB controller is designed so, > > > then the fix should only and explicitly affect that controller, > > > because we don't know it it will always be used with an ARM > > > implementation that can do unaligned accesses. > > > > My point is: on ARM platforms that can't do unaligned access in > > hardware the toolchain will automaticly emit helper code to work > > around this. On an ARMv7 platform hardware assisted unaligned access > > is mandatory, so toolchains will not emit helper code and rather let > > the hardware do it's job. > > My point is that there should be a reason for doing unaligned access to > boot (pun half-intended) and I don't see any. > I see your point here. > > Now the situation is as follows: hardware platforms without the > > ability to do unaligned access in hardware will just work even though > > the code is suboptimal, but users of an ARMv7 platform will encounter > > unexplained system hangs, which is bad imho. This patch just makes > > behaviour consistent across ARMv5 and ARMv7 platforms. > > Wouldn't aligning data properly make behaviour consistent as well? > Consistent in the way of "it works on all platforms", but not in the way of programming practice. ARMv7 people will have to care about alignment to not encounter runtime errors, while on ARMv5 it just doesn't matter. (Which certainly does not make it the right thing to do on ARMv5, but as the existing USB code shows people just haven't cared about this.) > > If we really want to disallow the use of unaligned memory operations > > in U-Boot we should make all platforms fail at compile time, not make > > one platform fail randomly at runtime. Do you think this is the way > > to go? I'm fine either way, I'm just not okay with the current > > situation where one platform fails while another just works. > > I do not want to disallow unaligned accesses, because this assumes > they were allowed in the first place; I want to keep not allowing them, > just like they were unallowed far, and just like they can keep on > being. If a misaligned access causes one platform to fail while another > just works, then we should avoid the misaligned access by re-aligning > it properly so as to make both platforms work. > The thing I wanted to say is: if we generally consider unaligned access a no-go for ARMv7 (which I'm fine with), we should equally consider it a no-go for ARMv5. So I would rather want to see both platforms fail at compile time if we have unaligned data, to avoid the unintended introduction of such code in the codebase as has happened with the usb code. Sadly I have not found a way to tell gcc to error out if encounters an unaligned access. Currently ARMv5 "allows" unaligned data, as toolchains insert helper code which makes it work. Also it is really unfortunate that coding errors (which the unjustified use of unaligned data certainly is) manifest as a runtime error, rather than a compiletime failure, which make them a lot harder to spot. > IOW, things will not change until I am shown some actual situation where > a misaligned access is necessary and the core prevents it. > I'm okay with you dropping this patch and will try to come up with something that make programming constraints more consistent across both ARM platforms. Thanks, Lucas

1 0

[U-Boot] [PATCH 10/11 v3] armv7: Adding cpu specific cache managmenent
by mathieu.poirier＠linaro.org 25 Jun '12

25 Jun '12

From: "Mathieu J. Poirier" <mathieu.poirier(a)linaro.org> Some CPU (i.e u8500) need more cache management before launching the Linux kernel. Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Signed-off-by: John Rigby <john.rigby(a)linaro.org> --- Changes for v2: - Moved from __attribute__(...) to __weak. changes for v3: - Choosing more explicit name for extra cache management routine. --- arch/arm/cpu/armv7/cpu.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c index c6fa8ef..f01989f 100644 --- a/arch/arm/cpu/armv7/cpu.c +++ b/arch/arm/cpu/armv7/cpu.c @@ -36,6 +36,7 @@ #include <asm/system.h> #include <asm/cache.h> #include <asm/armv7.h> +#include <linux/compiler.h> void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3) { @@ -44,6 +45,8 @@ void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3) void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) __attribute__((weak, alias("save_boot_params_default"))); +void __weak cpu_cache_initialization(void){} + int cleanup_before_linux(void) { /* @@ -81,5 +84,10 @@ int cleanup_before_linux(void) */ invalidate_dcache_all(); + /* + * Some CPU need more cache attention before starting the kernel. + */ + cpu_cache_initialization(); + return 0; } -- 1.7.5.4

1 1

[U-Boot] problems when large nand flash used
by Сергей К. 25 Jun '12

25 Jun '12

Hello all! I have some problem when using NAND flash manufactured by Toshiba. The device ID is 0xD7 , value 4Gbyte, page size 0x1000, erase blocksize 0x80000. The board is at91sam9260 based custom board. At first I was a normal performance of the board with a chip samsung k9k8g08 and u-boot version 1.3.4. But now i can not to get normal functionality of the board using toshiba chip and u-boot version 2012.04-rc3 Then I change NAND chip and u-boot sends to debug port ecc error when access to NAND is flow. For a while I could not think how to solve this problem and changed U-boot settings to no avail. Then I manually set page size and blocksize in file drivers/mtd/nand/nand_ids.c for 0xD7 device and the error disappeared. I have no idea - what did i wrong?Why autodetect is absent? Now ecc error do not take place, but i have not accsess to high 2Gbyte of NAND- write , erase and read operations is fault, blocks skipped to high range of the NAND. not 2Gbyte , the fault area begin from 0x80200000h address (it is more correctly). Write, erase and read operations into space 0x0000h - 0x80200000h flow without any problem. This NAND chip is new. What do you think about this? Best regards, Serg Klimenko

2 1

[U-Boot] [PATCH v4 0/13] split tegra20 arm7 code into separate SPL
by Allen Martin 25 Jun '12

25 Jun '12

This patch series fixes a long standing problem with the tegra20 u-boot build. Tegra20 contains an ARM7TDMI boot processor and a Cortex A9 main processor. Prior to this patch series this was accomplished by #ifdefing out any armv7 code from the early boot sequence and creating a single binary that runs on both both the ARM7TDMI and A9. This was very fragile as changes to compiler options or any additions or rearranging of the early boot code could add additional armv7 specific code causing it to fail on the ARM7TDMI. This patch series pulls all the armv4t code out into a separate SPL that does nothing more than initialize the A9 and transfer control to it. The resultint SPL and armv7 u-boot are concatenated together into a single image. This patch series is also available from: git://github.com/arm000/u-boot.git branch: tegra-spl-v4 Changes: v4: - rebased to u-boot-tegra/next - reordered entire patch series to preserve git bisect, verified build and boot at each patch - merged patches that add SPL config defines and removes duplicate code from u-boot init, these have to go in atomically to preserve building at each patch - fixed compiler warnings introduced - fixed blank line at end of file on cpu.c - renamed u-boot.t2 to u-boot-t2.bin - cleaned up config.mk generation in mkconfig to make it more readable - added some text to clarify using arm720t code for arm7tdmi - rearranged SPL memory map to make resulting SPL + u-boot image much smaller - removed separate PAD_TO define in favor of just using CONFIG_SYS_TEXT_BASE - moved warmboot_save_sdram_params() from dram_init() to board_init() v3: - git bisect still does not work across this series, I'm saving that for the next revision, but I had enough changes that I wanted to get this out for review - expanded the tegra2 -> tegra20 rename to include functions/variables/ defines - rebased to u-boot-tegra/next - removed some extra -march=armv4t flags, kept armv4t flags on warmboot_avp since it's special - removed bashisms from mkconfig - renamed CONFIG_MACH_TEGRA_GENERIC to CONFIG_TEGRA - moved SPL overrides to tegra2-common-post.h - changed SPL base address to 0x108000, u-boot goes to 0x208000 - moved warboot_save_sdram_params fix to separate patch - remove USE_PRIVATE_LIBGCC from non SPL build - expanded SPL support to all tegra20 boards, not just seaboard v2: - renamed tegra2 to tegra20 to match kernel and devicetree naming policy - pulled all SPL related config overrides to a separate file to clean up ifdefs from seabard.h - rebased to TOT u-boot/master and fixed a bug related to init sequence changes between this patch series and new EMC code - made u-boot.t2 target work even if CONFIG_OF is disabled - added back USE_PRIVATE_LIBGCC [PATCH v4 01/13] tegra20: rename tegra2 -> tegra20 [PATCH v4 02/13] tegra20: move tegra20 SoC code to [PATCH v4 03/13] tegra20: rename CONFIG_MACH_TEGRA_GENERIC [PATCH v4 04/13] tegra20: tec: add tegra20-common-post.h [PATCH v4 05/13] tegra20: plutux: change obj directory mkdir commands [PATCH v4 06/13] mkconfig: add support for SPL CPU [PATCH v4 07/13] ARM: Fix arm720t SPL build [PATCH v4 08/13] tegra20: remove timer_init from SPL build [PATCH v4 09/13] ARM: add tegra20 support to arm720t [PATCH v4 10/13] tegra20: add u-boot-t2.bin target [PATCH v4 11/13] tegra20: move SDRAM param save to later in boot [PATCH v4 12/13] tegra20: enable SPL for tegra20 boards [PATCH v4 13/13] tegra20: Remove armv4t build flags MAINTAINERS | 18 +-- Makefile | 16 +++ arch/arm/cpu/arm720t/cpu.c | 2 + arch/arm/cpu/arm720t/interrupts.c | 5 + arch/arm/cpu/arm720t/start.S | 19 ++- .../arm/cpu/arm720t/tegra20}/Makefile | 27 ++-- .../arch-tegra2 => cpu/arm720t/tegra20}/board.h | 11 +- .../{armv7/tegra2/ap20.c => arm720t/tegra20/cpu.c} | 148 ++------------------ .../ap20.h => cpu/arm720t/tegra20/cpu.h} | 15 +- arch/arm/cpu/arm720t/tegra20/spl.c | 132 +++++++++++++++++ arch/arm/cpu/armv7/start.S | 2 - arch/arm/cpu/armv7/{tegra2 => tegra20}/Makefile | 15 +- .../cpu/armv7/{tegra2 => tegra20}/cmd_enterrcm.c | 4 +- arch/arm/cpu/armv7/{tegra2 => tegra20}/config.mk | 12 +- arch/arm/cpu/armv7/{tegra2 => tegra20}/usb.c | 2 +- .../cpu/{armv7/tegra2 => tegra20-common}/Makefile | 29 ++-- arch/arm/cpu/tegra20-common/ap20.c | 131 +++++++++++++++++ .../cpu/{armv7/tegra2 => tegra20-common}/board.c | 39 ++---- .../cpu/{armv7/tegra2 => tegra20-common}/clock.c | 10 +- .../cpu/{armv7/tegra2 => tegra20-common}/crypto.c | 0 .../cpu/{armv7/tegra2 => tegra20-common}/crypto.h | 0 .../arm/cpu/{armv7/tegra2 => tegra20-common}/emc.c | 2 +- .../cpu/{armv7/tegra2 => tegra20-common}/funcmux.c | 2 +- .../tegra2 => tegra20-common}/lowlevel_init.S | 0 .../cpu/{armv7/tegra2 => tegra20-common}/pinmux.c | 4 +- .../arm/cpu/{armv7/tegra2 => tegra20-common}/pmu.c | 2 +- .../{armv7/tegra2 => tegra20-common}/sys_info.c | 2 +- .../cpu/{armv7/tegra2 => tegra20-common}/timer.c | 2 +- .../{armv7/tegra2 => tegra20-common}/warmboot.c | 18 +-- .../tegra2 => tegra20-common}/warmboot_avp.c | 4 +- .../tegra2 => tegra20-common}/warmboot_avp.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/ap20.h | 4 +- .../asm/{arch-tegra2 => arch-tegra20}/apb_misc.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/board.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/clk_rst.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/clock.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/emc.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/flow.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/funcmux.h | 2 +- .../asm/{arch-tegra2 => arch-tegra20}/fuse.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/gp_padctrl.h | 2 +- .../asm/{arch-tegra2 => arch-tegra20}/gpio.h | 2 +- arch/arm/include/asm/arch-tegra20/hardware.h | 29 ++++ .../asm/{arch-tegra2 => arch-tegra20}/mmc.h | 8 +- .../asm/{arch-tegra2 => arch-tegra20}/pinmux.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/pmc.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/pmu.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/scu.h | 0 .../{arch-tegra2 => arch-tegra20}/sdram_param.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/sys_proto.h | 4 +- .../tegra2.h => arch-tegra20/tegra20.h} | 18 +-- .../asm/{arch-tegra2 => arch-tegra20}/tegra_i2c.h | 2 +- .../asm/{arch-tegra2 => arch-tegra20}/tegra_spi.h | 4 +- .../asm/{arch-tegra2 => arch-tegra20}/timer.h | 6 +- .../uart-spi-switch.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/uart.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/usb.h | 0 .../asm/{arch-tegra2 => arch-tegra20}/warmboot.h | 0 board/avionic-design/common/tamonten.c | 4 +- .../dts/{tegra2-medcom.dts => tegra20-medcom.dts} | 0 .../dts/{tegra2-plutux.dts => tegra20-plutux.dts} | 0 .../dts/{tegra2-tec.dts => tegra20-tec.dts} | 0 board/avionic-design/plutux/Makefile | 7 +- .../dts/{tegra2-paz00.dts => tegra20-paz00.dts} | 0 board/compal/paz00/paz00.c | 6 +- ...{tegra2-trimslice.dts => tegra20-trimslice.dts} | 0 board/compulab/trimslice/trimslice.c | 6 +- board/nvidia/common/board.c | 17 ++- board/nvidia/common/emc.c | 2 +- board/nvidia/common/uart-spi-switch.c | 2 +- .../{tegra2-harmony.dts => tegra20-harmony.dts} | 2 +- .../{tegra2-seaboard.dts => tegra20-seaboard.dts} | 0 .../{tegra2-ventana.dts => tegra20-ventana.dts} | 2 +- .../{tegra2-whistler.dts => tegra20-whistler.dts} | 2 +- board/nvidia/harmony/harmony.c | 6 +- board/nvidia/seaboard/seaboard.c | 6 +- board/nvidia/whistler/whistler.c | 6 +- boards.cfg | 23 +-- doc/README.SPL | 12 ++ drivers/gpio/tegra_gpio.c | 12 +- drivers/i2c/tegra_i2c.c | 12 +- drivers/input/Makefile | 2 +- drivers/mmc/tegra_mmc.c | 32 ++--- drivers/mmc/tegra_mmc.h | 12 +- drivers/spi/tegra_spi.c | 10 +- include/configs/harmony.h | 14 +- include/configs/medcom.h | 12 +- include/configs/paz00.h | 12 +- include/configs/plutux.h | 12 +- include/configs/seaboard.h | 20 +-- include/configs/tec.h | 12 +- ...{tegra2-common-post.h => tegra20-common-post.h} | 73 +++++++++- .../configs/{tegra2-common.h => tegra20-common.h} | 44 +++--- include/configs/trimslice.h | 14 +- include/configs/ventana.h | 12 +- include/configs/whistler.h | 14 +- include/fdtdec.h | 12 +- include/serial.h | 2 +- mkconfig | 24 ++-- spl/Makefile | 4 + 100 files changed, 735 insertions(+), 483 deletions(-) ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

2 19

Re: [U-Boot] USB Flash Drive
by Mr.Deng 25 Jun '12

25 Jun '12

Dear buyer, We have a newest design USB Flash drive, can be Silkprint your own logo, Attached pls find the picture for your reference, Thanks for your kindly attention. We're looking forward to hearing from you soon! Item name: USB Flash Drive FOB SZ Price: 256MB: 2.35/pc 512MB: 2.5/pc 1GB: 3.4/pc 2GB: 3.8/pc 4GB: 4.35/pc 8GB: 5.5/pc 16GB: 9.6/pc 32GB: 17.9/pc 64GB: 35.5/pc lead time: 3days, Best Regards! Mr.Deng Mettei Technology Co.,Ltd Tel:0086-755-29237500 Fax:0086-755-27800378 Website:www.mettei.com MSN:szadidas@hotmail.com Skype: Jobdeng

1 0

Re: [U-Boot] [PATCH] config.mk:Update DBGFLAGS with dwarf information
by Prabhakar Kushwaha 25 Jun '12

25 Jun '12

Hi, Sorry for the delayed response. I somehow missed this :( On 06/19/2012 10:29 AM, Prabhakar Kushwaha wrote: > Hi Prabhakar, > > On Thu, May 24, 2012 at 2:43 PM, Prabhakar Kushwaha > <prabhakar(a)freescale.com> wrote: > > Hi Wolfgang, > > > > This patch has been pending for a very long time. No review > comments has > > been provided. > > Mike Frysinger posted a comment on May 14, 2012: > > [quote] > no real information here as to what is going wrong. the -g flag > provides debug > information and many people (myself included) have found this sufficient. > > please describe your actual problem in detail and how this actually fixes > things for you. > -mike > > I agree with Mike's reply i.e. -g flag provides sufficient debug information. But some debugger requires debug information in specific format i.e. -gdwarf-2 For example Freescale CodeWarrior Debugger Regards, Prabhakar > >> >> >> On 04/25/2012 09:41 AM, Prabhakar Kushwaha wrote: >>> Hi, >>> >>> This patch has review-pending from a very long time. >>> >>> I request the "mailing-list" to review this patch. >>> >>> Regards, >>> Prabhakar >>> >>> On Wednesday 15 February 2012 02:25 PM, Prabhakar Kushwaha wrote: >>>> Built u-boot elf file does not contain any dwarf informations by >>>> default. This >>>> information is required for debugging. >>>> >>>> Add dwarf ver 2 flag in DBGFLAGS. >>>> >>>> Signed-off-by: Radu Lazarescu<radu.lazarescu(a)freescale.com> >>>> Signed-off-by: Prabhakar Kushwaha<prabhakar(a)freescale.com> >>>> --- >>>> Applies on http://git.denx.de/u-boot.git branch master >>>> >>>> config.mk | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/config.mk b/config.mk >>>> index ddaa477..11bc20d 100644 >>>> --- a/config.mk >>>> +++ b/config.mk >>>> @@ -178,7 +178,7 @@ endif >>>> # who are porting old code to latest mainline but not updating >>>> $(AR). >>>> ARFLAGS = $(error update your Makefile to use cmd_link_o_target >>>> and not AR) >>>> RELFLAGS= $(PLATFORM_RELFLAGS) >>>> -DBGFLAGS= -g # -DDEBUG >>>> +DBGFLAGS= -g -gdwarf-2 # -DDEBUG >>>> OPTFLAGS= -Os #-fomit-frame-pointer >>>> >>>> OBJCFLAGS += --gap-fill=0xff >>> >>> >>> >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot(a)lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot(a)lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > >

3 4

[U-Boot] [PATCH 1/4] cmd_bootm: fix compilation warning for assigned but never used variable
by Otavio Salvador 25 Jun '12

25 Jun '12

The iflag variable was holding the return of disable_interrupts call but the value was not used in the method so we drop the assignment. Signed-off-by: Otavio Salvador <otavio(a)ossystems.com.br> --- common/cmd_bootm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 5685232..45e726a 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -1587,7 +1587,6 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc, static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { - ulong iflag; bootm_headers_t images; if (bootz_start(cmdtp, flag, argc, argv, &images)) @@ -1598,7 +1597,7 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */ - iflag = disable_interrupts(); + disable_interrupts(); #if defined(CONFIG_CMD_USB) /* -- 1.7.10

4 32

[U-Boot] [PATCH v2 2/3] imx: Use a clear identification of an unidentified CPU type
by Otavio Salvador 25 Jun '12

25 Jun '12

In case an unidentified CPU type is detected it now returns i.MX??, in a const char. Signed-off-by: Otavio Salvador <otavio(a)ossystems.com.br> Cc: Marek Vasut <marex(a)denx.de> Cc: Stefano Babic <sbabic(a)denx.de> Cc: Fabio Estevam <fabio.estevam(a)freescale.com> Changes since v1: * use i.MX?? for unidentified CPU type --- arch/arm/cpu/armv7/imx-common/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c b/arch/arm/cpu/armv7/imx-common/cpu.c index b3195dd..e7bd0bf 100644 --- a/arch/arm/cpu/armv7/imx-common/cpu.c +++ b/arch/arm/cpu/armv7/imx-common/cpu.c @@ -66,7 +66,7 @@ char *get_reset_cause(void) #if defined(CONFIG_DISPLAY_CPUINFO) -static char *get_imx_type(u32 imxtype) +static const char *get_imx_type(u32 imxtype) { switch (imxtype) { case 0x63: @@ -80,7 +80,7 @@ static char *get_imx_type(u32 imxtype) case 0x53: return "53"; default: - return "unknown"; + return "??"; } } -- 1.7.10

3 4