; exit ; echo fail'; run foo; echo $?
bar
0
"
Fixes: 8c4e3b79bd0 ("cmd: exit: Fix return value")
Signed-off-by: Marek Vasut
---
Cc: Adrian Vovk
Cc: Hector Palacios
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Tom Rini
---
cmd/exit.c| 7 +--
common/cli.c | 7 +
Hi Max,
On 12/13/22 13:24, Max van den Biggelaar wrote:
Hi,
I have a question regarding the U-Boot exit command. We are currently using
mainline U-Boot 2022.04 version to provide our embedded systems with a
bootloader image. To start our firmware via U-Boot environment, we use a
bootscript
On 11/21/22 09:55, Hector Palacios wrote:
Hi Marek,
On 11/19/22 15:12, Marek Vasut wrote:
On 11/18/22 12:19, Hector Palacios wrote:
Commit 8c4e3b79bd0bb76eea16869e9666e19047c0d005 supposedly
passed one-level up the argument passed to 'exit' but it also
broke 'exit' purpose of stopping
Hi Marek,
On 11/19/22 15:12, Marek Vasut wrote:
On 11/18/22 12:19, Hector Palacios wrote:
Commit 8c4e3b79bd0bb76eea16869e9666e19047c0d005 supposedly
passed one-level up the argument passed to 'exit' but it also
broke 'exit' purpose of stopping a script.
In reality, even if 'do_exit
'echo bar ; exit -2 ; echo should not see this'; run foo;
echo $?
bar
0
=> setenv foo 'echo bar ; exit ; echo should not see this'; run foo;
echo $?
bar
0
Reported-by: Adrian Vovk
Signed-off-by: Hector Palacios
---
common/cli_hush.c | 4
1 file
All mii operations require a valid PHY address except the 'device'
command, which expects the PHY name rather than the address.
Signed-off-by: Hector Palacios
---
cmd/mii.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index ce7b393eeaae..c0c42a851f90
ze), does not help. This DDR is still performing
slowly in
U-Boot, but I can't find the reason why.
Thanks for your help, anyway.
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On 07/18/2016 09:18 AM, Hector Palacios wrote:
> nand_do_write_ops() determines if it is writing a partial page with the
> formula:
> if (column || (writelen < mtd->writesize - 1))
>
> When 'writelen' is exactly 1 byte less than the NAND page size the formula
> equa
Signed-off-by: Hector Palacios <hector.palac...@digi.com>
---
Changes in v2
- v1 was wronly generated over U-Boot v2015.04
drivers/mtd/nand/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 68971675
should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0x and iterating until the watchdog timeout triggers.
To reproduce the issue on a NAND with 2K page (0x800):
=> nand erase.part
=> nand write $loadaddr 7ff
Signed-off-by: Hec
On 07/15/2016 08:49 PM, Scott Wood wrote:
> On Fri, 2016-07-15 at 09:45 +0200, Hector Palacios wrote:
>> nand_do_write_ops() determines if it is writing a partial page with the
>> formula:
>> part_pagewr = (column || writelen < (mtd->writesize - 1))
>>
>
Signed-off-by: Hector Palacios <hector.palac...@digi.com>
---
drivers/mtd/nand/nand_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 689716753ae6..c8be74849e56 100644
--- a/drivers/mtd/nand/nand_base.c
byte.
Thanks in advance for your comments.
Hector Palacios (1):
mtd: nand: fix bug writing 1 byte less than page size
drivers/mtd/nand/nand_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
with these commands.
This patch moves the fixup_silent_linux() call out of the
BOOTM_STATE_LOADOS state and into BOOTM_STATE_OS_PREP, to silence Linux
independently of the used command (booti, bootm or bootz).
Signed-off-by: Hector Palacios <hector.palac...@digi.com>
Reviewed-by: Simon Gl
with these commands.
This patch moves the fixup_silent_linux() call out of the
BOOTM_STATE_LOADOS state and into BOOTM_STATE_OS_PREP, to silence Linux
independently of the used command (booti, bootm or bootz).
Signed-off-by: Hector Palacios <hector.palac...@digi.com>
---
common/bootm.c | 12 +++--
i.MX6UL defines speed grading in OCOTP register 0x440[17:16]
as follows:
00 reserved
01 528MHz
10 700MHz
11 reserved
This commit removes the constants (which had the speed hardcoded
in their names) and uses values instead.
Signed-off-by: Hector Palacios
en changing clock divisor value(SDCLKFS
> or DVS in System Control Register) or setting RSTA bit.
>
> Signed-off-by: Eric Nelson <e...@nelint.com>
Reviewed-by: Hector Palacios <hector.palac...@digi.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
#define MMC_ERASE_ARG0x
> +#define MMC_SECURE_ERASE_ARG 0x8000
> +#define MMC_TRIM_ARG 0x0001
> +#define MMC_DISCARD_ARG 0x0003
> +#define MMC_SECURE_TRIM1_ARG 0x8001
> +#define MMC_SECURE_TRIM2_ARG 0x80008000
>
> #define MMC_S
produce the "mmc erase/ENGcm03648"
> issue (with or without a code change) for a couple of hours now.
>
> Can you give this a spin?
>
> It seems unlikely to address the issue unless what we're seeing is a
> side effect of a glitch while switching clocks.
As Fabio, I can reproduce this 100% of the times.
The patch does not fix it, though.
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Eric,
On 12/04/2015 07:33 PM, Eric Nelson wrote:
> Hi Fabio and Hector,
>
> On 12/04/2015 10:43 AM, Eric Nelson wrote:
>> On 12/04/2015 10:38 AM, Eric Nelson wrote:
>>> On 12/04/2015 10:32 AM, Eric Nelson wrote:
The low four bits of the SYSCTL register are reserved on the USDHC
if !defined(CONFIG_MX6)
Per your commit message should this be
#if (!defined(CONFIG_MX6) && !defined(CONFIG_MX7))
> #define SYSCTL_CKEN 0x0008
> #define SYSCTL_PEREN 0x0004
> #define SYSCTL_HCKEN 0x0002
> #define SYSCTL_IPGEN 0x0001
> +#endif
> #define SYSCTL_RSTA 0x0100
> #define SYSCTL_RSTC 0x0200
> #define SYSCTL_RSTD 0x0400
>
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
SABRESD on both SD card and eMMC with
v2015.04. The issue has been there always, I believe.
Apparently the command erases the first block, but the operation returns an
error, so
it aborts and it doesn't continue erasing futher blocks.
I opened a similar thread a while ago:
http://lists.denx.
:
= ubi part MyPart
= ubi part MyPart
In my case, after calling this three times, the target hangs. I think the exit
path in
ubi_init() does not properly free every allocated memory. I was not able to
find the
root cause, though.
Regards
--
Hector Palacios
:
= ubi part MyPart
= ubi part MyPart
In my case, after calling this three times, the target hangs. I think the exit
path in
ubi_init() does not properly free every allocated memory. I was not able to
find the
root cause, though.
Regards
--
Hector Palacios
A previous operation may have set the error flag, which must be cleared
before a new write operation can be issued.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/mxs_ocotp.c b/drivers/misc
The write operation may fail when trying to write to a locked area. In
this case the ERROR bit is set in the CTRL register. Check for that
condition and return an error.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 7 +++
1 file changed, 7 insertions
success even if the final
preparation function fails, but it's probably enough to print a message
because (if successful) the real programming of the fuses has already
completed.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 5 +
1 file changed, 1
Hi Fabio,
On 11/21/2014 06:10 PM, Fabio Estevam wrote:
Hi Hector,
On Fri, Nov 21, 2014 at 2:54 PM, Hector Palacios
hector.palac...@digi.com wrote:
The write operation may fail when trying to write to a locked area. In
this case the ERROR bit is set in the CTRL register. Check
Fuse drivers, like the mxs_ocotp.c, may return negative error codes but
the commands are only allowed to return CMD_RET_* enum values to the
shell, otherwise the following error appears:
exit not allowed from main input shell.
Signed-off-by: Hector Palacios hector.palac...@digi.com
Fuse drivers, like the mxs_ocotp.c, may return negative error codes but
the commands are not allowed to return negative error codes to the shell,
otherwise the following error appears:
exit not allowed from main input shell.
Signed-off-by: Hector Palacios hector.palac...@digi.com
this?
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 05/21/2014 04:20 AM, Jaehoon Chung wrote:
Hi, Hector.
On 05/21/2014 01:37 AM, Hector Palacios wrote:
Hi,
On 05/16/2014 06:59 AM, Jaehoon Chung wrote:
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew
but the driver returned error code
COM_ERR (-18) when trying to switch to any of the DDR modes. I guess the fsl_esdhc.c
driver needs some adaptation for DDR to work.
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http
-fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
if (mydata-fatbuf == NULL) {
debug(Error: allocating memory\n);
return -1;
Tested on an i.MX6 custom platform.
Tested-by: Hector Palacios hector.palac...@digi.com
Thanks,
--
Héctor Palacios
Hi,
On 03/28/2014 03:36 PM, Eric Nelson wrote:
Hi Hector,
On 03/28/2014 06:49 AM, Fabio Estevam wrote:
On Fri, Mar 28, 2014 at 7:15 AM, Hector Palacios
hector.palac...@digi.com wrote:
Cache was invalidated on the read operation, but it should
also be flushed otherwise.
Signed-off-by: Hector
Cache was invalidated on the read operation, but it should
also be flushed otherwise.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
Notes:
After enabling L2 cache on i.MX6 I found out that many times
when running the 'gpt' command to partition a uSD card, the
data
fields is justified.
[1] http://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
The calloc() call was allocating space for the sizeof the struct
pointer rather than for the struct contents.
Besides, since this buffer is passed to mmc for writing and some
platforms may use cache, the legacy_mbr struct should be cache-aligned.
Signed-off-by: Hector Palacios hector.palac
The calloc() call was allocating space for the sizeof the struct
pointer rather than for the struct contents.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
disk/part_efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index
to store the environment in a different partition.
The __weak function also allows to remove some ifdefs from the code.
If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
(default value for U-Boot when a partition is not provided).
Signed-off-by: Hector Palacios hector.palac
Since function mmc_get_env_devno is __weak and can be overridden by
board code, boards do not need to mandatory define
CONFIG_SYS_MMC_ENV_DEV.
If the constant is not defined, define it to 0 by default.
Signed-off-by: Hector Palacios hector.palac...@digi.com
Reviewed-by: Stephen Warren swar
Since function mmc_get_env_devno is __weak and can be overridden by
board code, boards do not need to mandatory define
CONFIG_SYS_MMC_ENV_DEV.
If the constant is not defined, define it to 0 by default.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
Notes:
Changes since v1
to store the environment in a different partition.
The __weak function also allows to remove some ifdefs from the code.
If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
(default value for U-Boot when a partition is not provided).
Signed-off-by: Hector Palacios hector.palac
Hi Stephen,
On 01/15/2014 06:40 PM, Stephen Warren wrote:
On 01/15/2014 03:53 AM, Hector Palacios wrote:
Since function mmc_get_env_devno is __weak and can be overridden by
board code, boards do not necessarily need to define
CONFIG_SYS_MMC_ENV_DEV. If the constant is not defined, return 0
to store the environment in a different partition.
The __weak function also allows to remove some ifdefs from the code.
If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
(default value for U-Boot when a partition is not provided).
Signed-off-by: Hector Palacios hector.palac
Since function mmc_get_env_devno is __weak and can be overridden by
board code, boards do not necessarily need to define
CONFIG_SYS_MMC_ENV_DEV. If the constant is not defined, return 0 by
default.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
common/env_mmc.c | 4
1 file
Fix incorrect name for iomux 0x7 of MX6_PAD_RGMII_TX_CTL which really
has function ENET_REF_CLK and not ANATOP_REF_OUT.
On imx6q also fix select input value to 1.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 2 +-
arch/arm/include/asm
Hello Otavio,
On 01/15/2014 12:09 PM, Otavio Salvador wrote:
Hello Hector,
On Wed, Jan 15, 2014 at 8:53 AM, Hector Palacios hector.palac...@digi.com
mailto:hector.palac...@digi.com wrote:
This complements commit 9404a5fc7cb58 env_mmc: allow environment to be
in an eMMC partition
Dear Otavio,
On 01/03/2014 06:35 PM, Otavio Salvador wrote:
On Thu, Jan 2, 2014 at 9:36 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, January 02, 2014 at 05:53:00 PM, Hector Palacios wrote:
Hi,
I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc
subcommands 'open
boot_partition
is the same as
mmc dev dev part
where part is the boot partition
mmc close dev boot_partition
is the same as
mmc dev dev 0
as a 0 will switch to partition 0 (user data).
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
Dear Jagan,
On 10/14/2013 06:57 PM, Jagan Teki wrote:
On Mon, Oct 14, 2013 at 9:37 PM, Tom Rini tr...@ti.com wrote:
On Mon, Oct 14, 2013 at 06:00:20PM +0200, Hector Palacios wrote:
Dear Marek,
I noticed that 'fatls' displays duplicated filenames (short and
long) for every file in the media
mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+
And the same here.
It works ok, but I can't say if it fixes exactly those seldom initialization problems
because I don't have a reliable way to reproduce them.
Tested-by: Hector Palacios hector.palac...@digi.com
Best regards,
--
Hector Palacios
init to board_early_init_f(),
where all the other upstream clock are initialized and also make
sure there is proper stabilization delay.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Hector Palacios hector.palac...@digi.com
Cc: Oliver Metz oli
;
dentptr++;
continue;
}
#endif
Could you please check?
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
()
d855bd95ad35568b109f1b4587b68f0c950011f5 mtd: omap2: allow bulding as a module
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
yet.
Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please
disregards my previous message.
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 09/16/2013 03:10 AM, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Performing tftp transfers on mx28 results in random timeouts.
Hector Palacios and Robert Hodaszi analyzed the root cause being related to the
alignment of the 'buff' buffer inside fec_recv().
GCC
Hello,
Going back to this old thread I have some news regarding the problem with TFTP
transmissions blocking (timed out) after 10 seconds on the FEC of the MX28.
See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio
regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Huang,
On 09/02/2013 10:50 AM, Huang Shijie wrote:
于 2013年09月02日 16:42, Hector Palacios 写道:
I am writing the JFFS2 partition from my custom U-Boot. Do you mean
that they way it writes it could not be compatible with what the new
driver expects? That sounds really bad.
The mtd code
to
mxs_power_set_auto_restart().
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
-by: Hector Palacios hector.palac...@digi.com
---
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 5ee2d88..285ac79 100644
--- a/arch
Dear Marek,
On 07/24/2013 05:54 PM, Marek Vasut wrote:
Dear Hector Palacios,
The AUTO_RESTART flag of HW_RTC_PERSISTENT0 register will
power up the chip automatically 180ms after power down.
This bit must be enabled by the boot loader to ensure the
target can start upon hardware reset
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr
the tftp command again, and then the file downloads completely.
The PHY is my usual suspect...
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Marek,
On 07/15/2013 02:30 PM, Marek Vasut wrote:
Dear Hector Palacios,
Hi Marek,
On 07/12/2013 06:48 PM, Marek Vasut wrote:
[...]
but I found something:
It is very strange that the timeouts appear always after transferring
between 20 and 24 MiB. So I thought maybe it was not an issue
On 07/15/2013 05:12 PM, Marek Vasut wrote:
Hi Hector,
Hi Marek,
On 07/15/2013 02:30 PM, Marek Vasut wrote:
Dear Hector Palacios,
Hi Marek,
On 07/12/2013 06:48 PM, Marek Vasut wrote:
[...]
but I found something:
It is very strange that the timeouts appear always after transferring
to my board. I'm using a Micrel KSZ8031RNLI at 50MHz. I always suspect from
the PHY.
I'm disconcerted because usually the timeouts occur after having successfully
downloaded 22 or 24 MiB. Other times it just downloads completely.
In any case, good job!
Best regards,
--
Hector Palacios
the issue
happens after 10s.
It's like if, after these 10 seconds, the PHY lost the link or something.
Really odd.
Does it tell you anything?
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo
Dear Marek Vasut,
On 03/13/2013 07:10 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 05:52 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 05:19 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 11
Hello,
When doing large TFTP downloads (files bigger than 10MiB) on my MX28 platform I'm
sometimes experiencing pauses and timeouts. U-Boot will eventually restart the
transmission and sometimes may successfully complete the download, but other times it
won't.
On my platform it was somewhat
Dear Marek Vasut,
On 03/13/2013 11:58 AM, Marek Vasut wrote:
Dear Hector Palacios,
Hello,
When doing large TFTP downloads (files bigger than 10MiB) on my MX28
platform I'm sometimes experiencing pauses and timeouts. U-Boot will
eventually restart the transmission and sometimes may
Dear Marek Vasut,
On 03/13/2013 05:19 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 11:58 AM, Marek Vasut wrote:
Dear Hector Palacios,
Hello,
When doing large TFTP downloads (files bigger than 10MiB) on my MX28
platform I'm sometimes experiencing pauses
Dear Marek Vasut,
On 03/13/2013 05:52 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 05:19 PM, Marek Vasut wrote:
Dear Hector Palacios,
Dear Marek Vasut,
On 03/13/2013 11:58 AM, Marek Vasut wrote:
Dear Hector Palacios,
Hello,
When doing large TFTP
On 02/26/2013 01:19 PM, Hector Palacios wrote:
Greetings,
I'm porting a custom platform based on mx28evk to latest U-Boot.
I modified the iomux.c for my platform (different DUART pins) and made some
changes to
mxs_adjust_memory_params() to accommodate to my DRAM chip.
I built the u-boot.sb
Greetings,
I'm porting a custom platform based on mx28evk to latest U-Boot.
I modified the iomux.c for my platform (different DUART pins) and made some changes to
mxs_adjust_memory_params() to accommodate to my DRAM chip.
I built the u-boot.sb. The platform however does not boot either from
76 matches
Mail list logo
