| Message ID | 1356537020-31114-1-git-send-email-festevam@gmail.com |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Stefano Babic |
| Headers | show |
On 26/12/2012 16:50, Fabio Estevam wrote: > From: Fabio Estevam <fabio.estevam@freescale.com> > > Since commit c733681 (pmic: Extend PMIC framework to support multiple instances > of PMIC devices) mx53loco fails to allocate the memory for PMIC: > > U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01) > > Board: MX53 LOCO > I2C: ready > DRAM: 1 GiB > pmic_alloc: No available memory for allocation! > pmic_init: POWER allocation error! > CPU: Freescale i.MX53 family rev2.0 at 800 MHz > Reset cause: POR > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > Calling the PMIC related functions at a later stage, ie, from board_late_init() > fixes the issue. > > Reported-by: Robert Nelson <robertcnelson@gmail.com> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> > --- Hi Fabio, hi Robert, the new pmic framework calls malloc(), that the reason. It is then safe to call the init from board_late_init(). Tested-by: Stefano Babic <sbabic@denx.de> Applied to u-boot-imx, thanks. gcc 4.6.4, it boots always here. Best regards, Stefano Babic
Hi Stefano, On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote: > Hi Fabio, hi Robert, > > the new pmic framework calls malloc(), that the reason. It is then safe > to call the init from board_late_init(). > > Tested-by: Stefano Babic <sbabic@denx.de> > > Applied to u-boot-imx, thanks. > > gcc 4.6.4, it boots always here. Ok, great. When you enter commands in the U-boot prompt, does it work fine? With the toolchains that myself and Robert used we are seeing resets. I would like to try the same gcc 4.6.4 toolchain you are using. Where do you get it from? Thanks, Fabio Estevam
On 27/12/2012 11:14, Fabio Estevam wrote: > Hi Stefano, > > On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote: > >> Hi Fabio, hi Robert, >> >> the new pmic framework calls malloc(), that the reason. It is then safe >> to call the init from board_late_init(). >> >> Tested-by: Stefano Babic <sbabic@denx.de> >> >> Applied to u-boot-imx, thanks. >> >> gcc 4.6.4, it boots always here. > > Ok, great. > > When you enter commands in the U-boot prompt, does it work fine? Yes, it is. > With > the toolchains that myself and Robert used we are seeing resets. > > I would like to try the same gcc 4.6.4 toolchain you are using. Where > do you get it from? It comes from ELDK-5.2.1 > I am playing a bit, I do not see your problem. I admit I have no idea which dialog version is on my board. The only issue I can see is with MMC - I see with "fatls" any entry twice: MX53LOCO U-Boot > fatls mmc 0:2 1 cmdline 1 cmdline 283472 u-boot.bin 283472 u-boot.bin 284496 u-boot.imx 284496 u-boot.imx 4093544 uimage 4093544 uimage 160291 uinitrd 160291 uinitrd 349 boot.txt 349 boot.txt 421 boot.scr 421 boot.scr But this is surely another issue.... Best regards, Stefano Babic
Hi Stefano, On Thu, 27 Dec 2012 11:24:15 +0100, Stefano Babic <sbabic@denx.de> wrote: > On 27/12/2012 11:14, Fabio Estevam wrote: > > Hi Stefano, > > > > On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote: > > > >> Hi Fabio, hi Robert, > >> > >> the new pmic framework calls malloc(), that the reason. It is then safe > >> to call the init from board_late_init(). > >> > >> Tested-by: Stefano Babic <sbabic@denx.de> > >> > >> Applied to u-boot-imx, thanks. > >> > >> gcc 4.6.4, it boots always here. > > > > Ok, great. > > > > When you enter commands in the U-boot prompt, does it work fine? > > Yes, it is. > > > With > > the toolchains that myself and Robert used we are seeing resets. > > > > I would like to try the same gcc 4.6.4 toolchain you are using. Where > > do you get it from? > > It comes from ELDK-5.2.1 > > > > > I am playing a bit, I do not see your problem. I admit I have no idea > which dialog version is on my board. > > The only issue I can see is with MMC - I see with "fatls" any entry twice: > > MX53LOCO U-Boot > fatls mmc 0:2 > 1 cmdline > 1 cmdline > 283472 u-boot.bin > 283472 u-boot.bin > 284496 u-boot.imx > 284496 u-boot.imx > 4093544 uimage > 4093544 uimage > 160291 uinitrd > 160291 uinitrd > 349 boot.txt > 349 boot.txt > 421 boot.scr > 421 boot.scr > > But this is surely another issue.... Re the double entries, did you check if these could be short / DOS (8.3) names vs long names? IIRC, for compatibility, in a (V)FAT directory any entry with a name longer than 8.3 has a matching short entry; maybe on the device you're ls'ing, *any* entry has a short version? > Best regards, > Stefano Babic Amicalement,
On 27/12/2012 17:27, Albert ARIBAUD wrote: > Hi Stefano, > Hi Albert, >> I am playing a bit, I do not see your problem. I admit I have no idea >> which dialog version is on my board. >> >> The only issue I can see is with MMC - I see with "fatls" any entry twice: >> >> MX53LOCO U-Boot > fatls mmc 0:2 >> 1 cmdline >> 1 cmdline >> 283472 u-boot.bin >> 283472 u-boot.bin >> 284496 u-boot.imx >> 284496 u-boot.imx >> 4093544 uimage >> 4093544 uimage >> 160291 uinitrd >> 160291 uinitrd >> 349 boot.txt >> 349 boot.txt >> 421 boot.scr >> 421 boot.scr >> >> But this is surely another issue.... > > Re the double entries, did you check if these could be short / DOS (8.3) > names vs long names? IIRC, for compatibility, in a (V)FAT directory any > entry with a name longer than 8.3 has a matching short entry; maybe on > the device you're ls'ing, *any* entry has a short version? That is the point. I tested with another SD-Card, putting also long names, and I get: 614 loadbootscr.scr 614 loadbo~1.scr 2606096 swupdate-image-thb.ext3.gz.u-boot 2606096 swupda~1.u-b 3893896 uimage-thb.bin 3893896 uimage~1.bin There is an entry for long name and one for short name. And with the other SD, all entries has a short version. Simply I do not remember I have already seen the double entries in the past.. Best regards, Stefano
Hi Stefano, On Fri, 28 Dec 2012 09:38:47 +0100, Stefano Babic <sbabic@denx.de> wrote: > On 27/12/2012 17:27, Albert ARIBAUD wrote: > > Hi Stefano, > > > > Hi Albert, > > >> I am playing a bit, I do not see your problem. I admit I have no idea > >> which dialog version is on my board. > >> > >> The only issue I can see is with MMC - I see with "fatls" any entry twice: > >> > >> MX53LOCO U-Boot > fatls mmc 0:2 > >> 1 cmdline > >> 1 cmdline > >> 283472 u-boot.bin > >> 283472 u-boot.bin > >> 284496 u-boot.imx > >> 284496 u-boot.imx > >> 4093544 uimage > >> 4093544 uimage > >> 160291 uinitrd > >> 160291 uinitrd > >> 349 boot.txt > >> 349 boot.txt > >> 421 boot.scr > >> 421 boot.scr > >> > >> But this is surely another issue.... > > > > Re the double entries, did you check if these could be short / DOS (8.3) > > names vs long names? IIRC, for compatibility, in a (V)FAT directory any > > entry with a name longer than 8.3 has a matching short entry; maybe on > > the device you're ls'ing, *any* entry has a short version? > > That is the point. I tested with another SD-Card, putting also long > names, and I get: > > 614 loadbootscr.scr > 614 loadbo~1.scr > 2606096 swupdate-image-thb.ext3.gz.u-boot > 2606096 swupda~1.u-b > 3893896 uimage-thb.bin > 3893896 uimage~1.bin > > There is an entry for long name and one for short name. And with the > other SD, all entries has a short version. Simply I do not remember I > have already seen the double entries in the past.. Yes, normally there should be two different entries; my question was, more precisely, whether you checked if the very SD card with which you saw duplicates appear actually held such duplicates -- as opposed to holding single entries duplicated by the U-Boot code. > Best regards, > Stefano Amicalement,
On 28/12/2012 11:34, Albert ARIBAUD wrote: > Hi Stefano, > Hi Albert, >> There is an entry for long name and one for short name. And with the >> other SD, all entries has a short version. Simply I do not remember I >> have already seen the double entries in the past.. > > Yes, normally there should be two different entries; my question was, > more precisely, whether you checked if the very SD card with which you > saw duplicates appear actually held such duplicates -- as opposed to > holding single entries duplicated by the U-Boot code. No, the SD card has only one single entry, checking it on a Linux PC. I have tried also creating a new empty VFAT partition and copying on it a single file (u-boot.img, a 8.3 file) - I see always twice in u-boot, once on Linux. twister => fatls mmc 0:4 474740 u-boot.img 474740 u-boot.img 2 file(s), 0 dir(s) Regards, Stefano
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 2c8cb7a..63a4f8b 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -462,12 +462,18 @@ int board_init(void) mxc_set_sata_internal_clock(); setup_iomux_i2c(); + + lcd_enable(); + + return 0; +} + +int board_late_init(void) +{ if (!power_init()) clock_1GHz(); print_cpuinfo(); - lcd_enable(); - return 0; } diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index e30502b..c4181bd 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -39,6 +39,7 @@ #define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024) #define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_BOARD_LATE_INIT #define CONFIG_MXC_GPIO #define CONFIG_REVISION_TAG