Hi Javier,
On 12/26/12 05:24, Javier Martinez Canillas wrote:
> Even when the IGEPv2 board and the IGEP Computer-on-Module
> are different from a form factor point of view, they are
> very similar in the fact that share many components and how
> they are wired.
>
> So, it is possible (and better)
Hi Pavel,
> Technically, the patch was quoted whole, but it goes on top of another,
> that added the DM and early heap macros to the board config, so its of
> no use as it is.
Ok, so IIUC this patch is not required for fixing anything in the
current mainline u-boot, and would not break anything i
On 26/12/2012 19:17, Otavio Salvador wrote:
> On Wed, Dec 26, 2012 at 9:02 AM, Stefano Babic wrote:
>> On 21/12/2012 17:59, Otavio Salvador wrote:
>>> For a generic environment, we shouldn't have a fixed rootfs filesystem
>>> so we drop it from env.
>>>
>>> Signed-off-by: Otavio Salvador
>>> ---
Hi Simon,
On Wed, 26 Dec 2012 12:39:32 -0800, Simon Glass
wrote:
> Hi Vikram,
>
> On Sun, Dec 23, 2012 at 3:27 AM, Vikram Narayanan wrote:
> > bootstage_mark_name calls timer_get_boot_us which inturn calls
> > the arch timer. The arch timer uses the gd pointer to save the
> > lastinc count. A c
On 26/12/2012 19:23, Otavio Salvador wrote:
> On Wed, Dec 26, 2012 at 10:14 AM, Fabio Estevam wrote:
>> On Wed, Dec 26, 2012 at 9:31 AM, Stefano Babic wrote:
>>
>>> Only to remark that this is the correct behavior. The kernel with fdt is
>>> booted independently if this is wanted or not, but if t
On 26/12/2012 16:50, Fabio Estevam wrote:
> From: Fabio Estevam
>
> 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
>
Hi Stefano,
On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic 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
>
> Applied to u-boot-imx, thanks.
>
> gcc 4.6.4, it boots
On Thu, 27 Dec 2012 10:41:06 +0100, Albert ARIBAUD
wrote:
> Hi Simon,
>
> On Wed, 26 Dec 2012 12:39:32 -0800, Simon Glass
> wrote:
> > Hi Vikram,
> >
> > On Sun, Dec 23, 2012 at 3:27 AM, Vikram Narayanan
> > wrote:
> > > bootstage_mark_name calls timer_get_boot_us which inturn calls
> > > the
On 27/12/2012 11:14, Fabio Estevam wrote:
> Hi Stefano,
>
> On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic 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
>>
Dear Krishna Mohan Chagaleti,
In message you
wrote:
>
> I have been trying to test and integrate my customized binary on u-boot.
>
> I tried the procedure of executing the example demo application
> (hello_world.bin) by downloading binary using tftp and executing it.
> But, it didn't help thoug
From: Fabio Estevam
commit c73368150 (pmic: Extend PMIC framework to support multiple instances
of PMIC devices) introduced an extra 'retval' variable, but this is not
necessary since we have already the variable 'ret' in place.
So use 'ret' to store the return values from the pmic related cal
Dear Stefano Babic,
In message <50dc15e3.2040...@denx.de> you wrote:
>
> Well, I think you can add extra tabs to make it more readable:
>
> + "mmcargs=setenv bootargs console=${console_mainline},"\
> + " ${baudrate} root=${mmcroot}\0" \
That should be
"${baudra
Dear Fabio Estevam,
In message <1356604017-9699-1-git-send-email-feste...@gmail.com> you wrote:
> From: Fabio Estevam
>
> commit c73368150 (pmic: Extend PMIC framework to support multiple instances
> of PMIC devices) introduced an extra 'retval' variable, but this is not
> necessary since we h
On 27/12/2012 11:35, Wolfgang Denk wrote:
> Dear Fabio Estevam,
>
Hi Wolfgang,
> In message <1356604017-9699-1-git-send-email-feste...@gmail.com> you wrote:
>> From: Fabio Estevam
>>
>> commit c73368150 (pmic: Extend PMIC framework to support multiple instances
>> of PMIC devices) introduced a
On Thu, Dec 27, 2012 at 9:05 AM, Stefano Babic wrote:
> I think it relies on the fact that only one of the two PMICs is mounted
> on the board. There are versions of the board with the Dialog PMIC, and
> other versions with Frescale's. Worse it is, there is no easy way to
> detect which version o
On Tue, 27 Nov 2012 13:43:24 +0100, Albert ARIBAUD
wrote:
> The goal of this series is to scrub the start.S files
> which have proliferated across arch/arm and eliminate
> code redundancy.
>
> This series only factorizes the C runtime framework,
> that is, the assembly code responsible for settin
Even when the IGEPv2 board and the IGEP Computer-on-Module
are different from a form factor point of view, they are
very similar in the fact that share many components and how
they are wired.
So, it is possible (and better) to have a single board file
for both devices and just use the CONFIG_MACH_
On 12/27/2012 3:52 PM, Albert ARIBAUD wrote:
On Thu, 27 Dec 2012 10:41:06 +0100, Albert ARIBAUD
wrote:
Hi Simon,
On Wed, 26 Dec 2012 12:39:32 -0800, Simon Glass
wrote:
Hi Vikram,
On Sun, Dec 23, 2012 at 3:27 AM, Vikram Narayanan wrote:
bootstage_mark_name calls timer_get_boot_us which int
On 12/26/12 05:24, Javier Martinez Canillas wrote:
> This patch adds an GPIO LED boot status for IGEP boards.
>
> The GPIO LED used is the red LED0 while the Linux kernel
> uses the green LED0 as the boot status.
>
> By using different GPIO LEDs, the user can know in which
> step of the boot proc
On 12/27/12 13:35, Javier Martinez Canillas wrote:
> Even when the IGEPv2 board and the IGEP Computer-on-Module
> are different from a form factor point of view, they are
> very similar in the fact that share many components and how
> they are wired.
>
> So, it is possible (and better) to have a s
On 12/27/2012 02:16 PM, Igor Grinberg wrote:> On 12/26/12 05:24,
Javier Martinez Canillas wrote:
>> This patch adds an GPIO LED boot status for IGEP boards.
>>
>> The GPIO LED used is the red LED0 while the Linux kernel
>> uses the green LED0 as the boot status.
>>
>> By using different GPIO LEDs,
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canil
On 12/27/12 15:36, Javier Martinez Canillas wrote:
> This patch adds an GPIO LED boot status for IGEP boards.
>
> The GPIO LED used is the red LED0 while the Linux kernel
> uses the green LED0 as the boot status.
>
> By using different GPIO LEDs, the user can know in which
> step of the boot proc
Hi Simon,
> This code seems to be entirely othogonal, so remove the #ifdef and put
> the condition in the Makefile instead.
I'm fully with you in respect of cleaning/refactoring the ext4 u-boot
code.
I will test this change when I only find some time ...
--
Best regards,
Lukasz Majewski
Sams
Hello all,
I am new to U-Boot and am trying to find my way around it by looking at
examples, U-Boot's help and googling. However I am unable to find an
explanation of what certain options of U-Boot commands mean. For example:
I am currently trying to figure out what env import's options can do. H
On Thu, Dec 27, 2012 at 9:07 AM, Igor Grinberg wrote:
> Hi Javier,
>
Hi Igor,
Thanks a lot for your feedback.
> On 12/26/12 05:24, Javier Martinez Canillas wrote:
>> Even when the IGEPv2 board and the IGEP Computer-on-Module
>> are different from a form factor point of view, they are
>> very si
From: Fabio Estevam
Looks like the original comment came from a copy and paste from mx31ads.h.
It does not have a context on mx51evk anymore, so delete it.
Signed-off-by: Fabio Estevam
---
include/configs/mx51evk.h |4
1 file changed, 4 deletions(-)
diff --git a/include/configs/mx51
Hi Stefano,
On Thu, 27 Dec 2012 11:24:15 +0100, Stefano Babic
wrote:
> On 27/12/2012 11:14, Fabio Estevam wrote:
> > Hi Stefano,
> >
> > On Thu, Dec 27, 2012 at 8:09 AM, Stefano Babic wrote:
> >
> >> Hi Fabio, hi Robert,
> >>
> >> the new pmic framework calls malloc(), that the reason. It is t
Greetings,
I am using U-Boot version 2011.09-00096 and Kernel 3.1.0 on a proprietary
board booting out of NOR flash. The only mods to the sources are my BSP
files.
All is well as long as the kernel image and ram filesystem archive image are
created with the mkfs.jffs2 command and copied into flas
From: Fabio Estevam
A memset() followed by memset() can be simply replaced by calloc().
Signed-off-by: Fabio Estevam
---
drivers/mmc/fsl_esdhc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index e93e38a..5fc1c36 100
From: Fabio Estevam
A malloc() followed by memset() can be simply replaced by calloc().
Signed-off-by: Fabio Estevam
---
Change since v1:
- Fix commit log
drivers/mmc/fsl_esdhc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_
Here is the text of the checksum error:
U-Boot (gridco)# fsload 8020 os-1.1/uImage
### JFFS2 loading 'os-1.1/uImage' to 0x8020
### JFFS2 load complete: 2859696 bytes loaded to 0x8020
U-Boot (gridco)# fsload os/os-1.1/initramfs.cpio.img 8160
### JFFS2 loading '8160' to 0x0
find
Dear Stefano,
In message <50dc2b8f.2030...@denx.de> you wrote:
>
> I think it relies on the fact that only one of the two PMICs is mounted
> on the board. There are versions of the board with the Dialog PMIC, and
> other versions with Frescale's. Worse it is, there is no easy way to
> detect which
Dear Fabio Estevam,
In message
you wrote:
>
> > However, only one of the two branch can run, because i2c_probe() fails
> > if the PMIC is not found.
>
> Yes, correct. We have either Dialog DA9052 or FSL MC34708 on the
> mx53loco boards, so only one of the branches will run.
This is what the c
Dear Casper,
In message <1356603971660-143623.p...@n7.nabble.com> you wrote:
>
> I am currently trying to figure out what env import's options can do. Help
> only gives:
> /env import [-d] [-t | -b | -c] addr [size] - import environment/
> I see it mostly being used with -t option. However I can
On Thu, Dec 27, 2012 at 8:29 AM, Wolfgang Denk wrote:
> Dear Stefano Babic,
>
> In message <50dc15e3.2040...@denx.de> you wrote:
>>
>> Well, I think you can add extra tabs to make it more readable:
>>
>> + "mmcargs=setenv bootargs console=${console_mainline},"\
>> + " ${baudrate}
On Thu, Dec 27, 2012 at 7:44 AM, Stefano Babic wrote:
> On 26/12/2012 19:23, Otavio Salvador wrote:
>> On Wed, Dec 26, 2012 at 10:14 AM, Fabio Estevam wrote:
>>> On Wed, Dec 26, 2012 at 9:31 AM, Stefano Babic wrote:
>>>
Only to remark that this is the correct behavior. The kernel with fdt i
On 12/27/2012 07:51 PM, Fabio Estevam wrote:
From: Fabio Estevam
A malloc() followed by memset() can be simply replaced by calloc().
Signed-off-by: Fabio Estevam
---
Change since v1:
- Fix commit log
drivers/mmc/fsl_esdhc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
I believe I solved my own problem. It looks like a hardware or kernel driver
issue. Software timeouts are seen in the kernel CFI command set driver
during the write. The driver reports the copy succeeded in spite of the
timeout. I was able to do a copy without experiencing timeouts and the
kernel b
On 12/26/2012 03:28 PM, Simon Glass wrote:
> Include file support in dtc is still not available in common distributions
> so we need to keep our preprocessing arrangement around for a little
> longer.
>
> But # is commonly used in FDT files, so use sed instead of cpp for this
> preprocessing.
Thi
Hi
On Thursday 27 of December 2012 09:59:07 Albert ARIBAUD wrote:
> Hi Pavel,
>
> > Technically, the patch was quoted whole, but it goes on top of another,
> > that added the DM and early heap macros to the board config, so its of
> > no use as it is.
>
> Ok, so IIUC this patch is not required f
41 matches
Mail list logo
