On 2023/11/23 8:50, Marek Vasut wrote:
> Replace one type of terrible code formatting with a different
> type of terrible code formatting. No functional change.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Bin Meng
> Cc: Hector Martin
> ---
> driver
On 2023/11/20 21:15, Marek Vasut wrote:
> On 11/20/23 11:45, Hector Martin wrote:
>>
>>
>> On 2023/11/20 11:09, Marek Vasut wrote:
>>> On 11/20/23 00:17, Shantur Rathore wrote:
>>>> On Sun, Nov 19, 2023 at 8:08 PM Marek Vasut wrote:
>>
On 2023/11/20 11:09, Marek Vasut wrote:
> On 11/20/23 00:17, Shantur Rathore wrote:
>> On Sun, Nov 19, 2023 at 8:08 PM Marek Vasut wrote:
>>>
>>> On 10/27/23 01:16, Hector Martin wrote:
>>>> This series is the first of a few bundles of USB fixes we ha
On 29/10/2023 21.11, Marek Vasut wrote:
> On 10/29/23 08:23, Hector Martin wrote:
>> This makes things work properly on devices with >= 2 TiB
>> capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
>> the capacity will be clamped at 2^32 - 1 sectors.
>>
&
On 29/10/2023 21.04, Marek Vasut wrote:
> On 10/29/23 08:24, Hector Martin wrote:
>> We currently do not really handle altsettings properly, and no driver
>> uses them. Ignore the respective endpoint descriptors for secondary
>> altsettings, to avoid creating duplicate en
Now that the USB core passes through timeout info to the host
controller, actually hook it up.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 32
drivers/usb/host/xhci.c | 23 +--
include/usb/xhci.h | 14
this is ignored in the
individual drivers.
Signed-off-by: Hector Martin
---
common/usb.c| 21 ++---
drivers/usb/host/ehci-hcd.c | 5 +++--
drivers/usb/host/ohci-hcd.c | 5 +++--
drivers/usb/host/r8a66597-hcd.c | 5 +++--
drivers/usb/host/usb
OHCI to someone else if anyone cares :)
This series needs to be applied after [1], since the xHCI changes depend
on changes made there.
[1]
https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
Signed-off-by: Hector Martin
---
Hector Martin (2):
usb: Pass thr
work properly.
Signed-off-by: Hector Martin
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c557..90f72fda00bc 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -463,6 +463,15 @@ static int usb_parse_config(struct usb_device
This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 132 ---
1 file chan
USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 22 ++
1 file changed, 14 insertions
0x9e isn't Read Capacity, it's a service action and the read capacity
command is a subcommand.
READ16 is not 0x48, it's 0x88. 0x48 is SANITIZE and that sounds like we
might have been destroying data instead of reading data. No bueno.
Signed-off-by: Hector Martin
---
drivers/
Some USB devices (like hard disks) can take a long time to initially
respond to read/write requests. Explicitly specify a much longer timeout
than normal.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/common
s, which depends on [1] being applied first. The
USBMS part is logically stand-alone and can be applied in parallel
before that.
[1]
https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
Signed-off-by: Hector Martin
---
Hector Martin (4):
scsi: Fix a bunch
Some devices like YubiKeys need more time before SET_ADDRESS. The spec
says we need to wait 10ms.
Signed-off-by: Hector Martin
---
common/usb_hub.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a188ca64..858ada0f73be 100644
--- a/common
ces.
This is particularly important to avoid regressing some users, since
YubiKeys often *don't* work due to other bugs in the USB stack, but will
start to work once they are fixed.
Signed-off-by: Hector Martin
---
common/usb_kbd.c | 19 +++
1 file changed, 19 insertions(+
This mini series fixes one bug, but in the process makes YubiKeys work,
which then regresses people who have one *and* a USB keyboard, since we
only support a single keyboard device.
Therefore patch #1 makes U-Boot ignore YubiKeys, so #2 does not
regress things.
Signed-off-by: Hector Martin
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index db
ff-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e02a6e300c4f..db8b8f200250 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -671,6 +671,14 @
elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d21e76e0bdb6..e02a6e300c4f 100644
--- a/drivers/usb/host
ng up with unexpected event errors.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 34 ++
include/usb/xhci.h | 2 ++
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-r
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 15
edhat.com/show_bug.cgi?id=2244305
Signed-off-by: Hector Martin
---
Changes in v2:
- Squashed in a trivial fix for patch #1
- Removed spurious blank line
- Added a longer description to the cover letter
- Link to v1:
https://lore.kernel.org/r/20231027-usb-fixes-1-v1-0-1c879bbcd...@marcan.st
---
Hec
On 27/10/2023 09.36, Marek Vasut wrote:
> On 10/27/23 01:26, Hector Martin wrote:
>> Gah, I should've paid more attention to that rebase. Here's a dumb
>> fixup for this patch. I'll squash it into a v2 if needed alongside
>> any other changes, or if it looks goo
Gah, I should've paid more attention to that rebase. Here's a dumb
fixup for this patch. I'll squash it into a v2 if needed alongside
any other changes, or if it looks good feel free to apply/squash
it in directly.
---
drivers/usb/host/xhci-ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci
ff-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5c2d16b58589..60f2cf72dffa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -669,6 +669,14 @
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60
elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d08bb8e2bfba..5c2d16b58589 100644
--- a/drivers/usb/host
t and ending up with unexpected event errors.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 34 ++
include/usb/xhci.h | 2 ++
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses the immediate explosions in this part
of the code, but not the original cause.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 15 ++-
drivers/usb/host/xhci.c
other xHCI bugs and adding better debug logs.
I believe this should fix this Fedora bug too:
https://bugzilla.redhat.com/show_bug.cgi?id=2244305
Signed-off-by: Hector Martin
---
Hector Martin (8):
usb: xhci: Guard all calls to xhci_wait_for_event
usb: xhci: Better error handling in
e configuring boot
settings (boot chime, next boot OS, etc.) at the Apple/iBoot layer.
In my opinion, the only sane way to get EFI variables to work here is to
use ubootefi.var and teach OSes how to manipulate it directly, in lieu
of runtime services being available (or perhaps with some kind of
callback layer so the OS can provide ESP file R/W services back to the
runtime services). I'm not sure it's worth actually doing this, but I
can't think of any other viable option if we decide we really want it.
- Hector
ations. Can the current deviations be removed in Asahi Linux?
If you can come up with a better idea that actually works on these
platforms and solves all the issues I mentioned above, I'm all ears.
- Hector
nv foo 'echo bar ; exit -2 ; echo fail'; run foo; echo $?
bar
0
=> setenv foo 'echo bar ; 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: Pan
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 t
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' p
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, ev
echo $?
bar
0
=> setenv foo 'echo bar ; exit -1 ; echo should not see this'; run foo;
echo $?
bar
0
=> setenv foo 'echo bar ; exit -2 ; echo should not see this'; run foo;
echo $?
bar
0
=> setenv f
: Hector Martin
---
drivers/nvme/nvme.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index a305305885ec..5fd2fb9ed6a6 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -27,9 +27,8 @@
#define
r variables that contain lists, like kernel
arguments, and such.
Has this been discussed in the past?
Thanks
--
Hector Palacios
it, branch:
imx_v2018.03_4.14.78_1.0.0_ga. But it seems that the original u-boot
source does not differ regarding the CONFIG_SPL_POST_MEM_SUPPORT
configuration.
Appreciate any help!
Best regards,
Hector
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..c0
Hi Fabio,
On Thu, 18 May 2017 17:52, Fabio Estevam wrote:
> I got very slow performance with MX6UL when U-Boot is loaded via
> serial download mode.
That's it, actually!
I was booting the target via USB, booting from the NAND shows normal
performance.
> This gets fixed by setting the SMP bit:
Hi Fabio,
On 05/17/2017 11:08 PM, Fabio Estevam wrote:
> Hi Hector,
>
> On Wed, May 17, 2017 at 5:50 AM, Palacios, Hector
> wrote:
>
>> The code is on Github [1] (well, not the dual-die DDR3 yet) but there isn't
>> much to see for this issue other than:
>
Hi Fabio,
On Wed, 17 May 2017 00:34, Fabio Estevam wrote:
> Hi Hector,
>
> On Tue, May 16, 2017 at 1:15 PM, Palacios, Hector
> wrote:
>> Greetings,
>>
>> I'm adding support to a 1GiB DDR3 chip that internally has two dies. I
> have configured the i.MX6U
Greetings,
I'm adding support to a 1GiB DDR3 chip that internally has two dies. I have
configured the i.MX6UL memory controller for using two chip selects and
assigned 512MiB to each. Although the RAM seems to work fine I'm experiencing
extremely slow performance compared to a similar 1GiB chip
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
d write $loadaddr 7ff
Signed-off-by: Hector Palacios
---
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 689716753ae6..82802
e, although
it 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
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))
>>
>
d write $loadaddr 7ff
Signed-off-by: Hector Palacios
---
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
+++ b/d
, less one 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@lis
ns silent Linux does not work 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
Reviewed-by: Simon Glass
ns silent Linux does not work 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
---
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
Hi,
I'm loading U-Boot to an i.MX6Q platform using ARM DSTREAM debugger and after
running the DDR initialization script it fails to load the u-boot ELF binary
complaining with:
loadfile "/home/hpalacio/git/u-boot-denx/u-boot"
ERROR(CMD16-TAD11-NAL18):
! Failed to load "u-boot"
! Failed to writ
ne 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_STATUS_MASK (~0x0206BF7F)
&
clock divisor value(SDCLKFS
> or DVS in System Control Register) or setting RSTA bit.
>
> Signed-off-by: Eric Nelson
Reviewed-by: 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 SYSCT
> +#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
se/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 Fabio,
On Thu, 12 Nov 2015 21:56, Fabio Estevam wrote:
> Hi Hector and Cliff,
>
> On Mon, Oct 19, 2015 at 9:06 AM, Hector Palacios
> wrote:
>
>> This issue is reproducible on Freescale's SABRESD on both SD card and eMMC
>> with v2015.04. The
>>
le's 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:
htt
on table,
and
then compared these variables with the values returned by 'part uuid' (as
strings).
Now on v2015.04 the strings do not match due to this endianness change on the
representation.
Thanks
--
Hector
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hello Fabio,
On Sun, Jun 7, 2015 at 19:23, Fabio Estevam wrote:
> Hi Hector,
> On Thu, Jun 4, 2015 at 8:23 AM, Palacios, Hector wrote:
>> Hello,
>>
>> I can see the command 'mmc erase blk# cnt' fails with a DAT0 timeout on iMX6
>> boards when run over the
Hello,
I can see the command 'mmc erase blk# cnt' fails with a DAT0 timeout on iMX6
boards when run over the eMMC.
=> mmc dev 2
=> mmc erase 4000 1000
MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for
DAT0 to go high!
mmc erase failed
0 blocks erase: ERROR
I reproduced i
Hello Troy,
Code comments on commit 124a06d7fbbf82f47304d499418460312a725ad6 for forcing
the boot mode say:
+/*
+ * cfg_val will be used for
+ * Boot_cfg4[7:0]:Boot_cfg3[7:0]:Boot_cfg2[7:0]:Boot_cfg1[7:0]
+ * After reset, if GPR10[28] is 1, ROM will copy GPR9[25:0]
+ * to SBMR1, which will deter
espite failing during the attach procedure now
should
return an error).
4. Run the command again several times:
=> 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 all
espite failing during the attach procedure now
should
return an error).
4. Run the command again several times:
=> 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 all
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
> 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 f
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
---
drivers/misc/mxs_ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a
ction may now return 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
---
drivers/misc/mxs_ocotp.c | 5 +
1 file changed, 1
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
---
drivers/misc/mxs_ocotp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/mxs_ocotp.c b/drivers/misc/mxs_ocotp.c
index
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
---
Chan
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
---
common/cmd_
ntries, and calling env_flags_validate() in
'env_op_create' mode, which only checks for ENV_FLAGS_VARACCESS_PREVENT_CREATE permission.
Any ideas on how to properly fix 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
Tested-by: Lukasz Majewski
Acked-by: Lukasz Majewski
What platforms did you test DDR mode on?
I have
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://lists.denx.de/mailman/listinfo/u-boot
FATBUFSIZE);
if (mydata->fatbuf == NULL) {
debug("Error: allocating memory\n");
return -1;
Tested on an i.MX6 custom platform.
Tested-by: Hector Palacios
Thanks,
--
Héctor Palacios
___
U-Boot m
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
wrote:
Cache was invalidated on the read operation, but it should
also be flushed otherwise.
Signed-off-by: Hector Palacios
After
Cache was invalidated on the read operation, but it should
also be flushed otherwise.
Signed-off-by: Hector Palacios
---
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 was not written
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios
Replying to Tom's q
ARM alignment
> policy, but this patch is not ARM per se and is in Tom's hands.
>
> Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This
> would by no means close the discussion I opened, and in the event
> of a policy ch
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
---
Notes
Hi Albert,
On 02/12/2014 05:31 PM, Albert ARIBAUD wrote:
> Hi Hector,
>
> On Wed, 12 Feb 2014 17:24:26 +0100, "Palacios, Hector"
> wrote:
>
>> Unfortunately this is causing unaligned access in my i.MX6.
>> I'm specifically passing the -mno-unaligned-acc
Hi Lukasz,
On 02/12/2014 04:56 PM, Lukasz Majewski wrote:
> Hi Hector,
>
>> The calloc() call was allocating space for the sizeof the struct
>> pointer rather than for the struct contents.
>>
>> Signed-off-by: Hector Palacios
>> ---
>> disk/part_efi
The calloc() call was allocating space for the sizeof the struct
pointer rather than for the struct contents.
Signed-off-by: Hector Palacios
---
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 5dfaf490c89a..7fabec059d7a
Hi Antoniou,
On 02/07/2014 05:26 PM, Pantelis Antoniou wrote:
> Hi Hector,
>
> On Jan 23, 2014, at 2:39 PM, Hector Palacios wrote:
>
>> This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
>> in an eMMC partition" by allowing boards to accom
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
Reviewed-by: Stephen Warren
---
Notes:
Changes since v2
boards may decide 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
R
boards may decide 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
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
---
Notes:
Changes since v1:
- Use default define if
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 by
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 mailto:hector.palac...@digi.com>> wrote:
This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
in an eMMC partition" by al
1 - 100 of 131 matches
Mail list logo
