Hi Fabio,
On 12/06/2015 05:21 PM, Fabio Estevam wrote:
> Hi Eric,
>
> On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson wrote:
>
>> I've figured out a way to repeat this on my machine.
>>
>> If I write 0xff's to the eMMC blocks, then issue an erase for the same,
>> I get the problem with each MMC_ERA
Hi Eric,
On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson wrote:
> I've figured out a way to repeat this on my machine.
>
> If I write 0xff's to the eMMC blocks, then issue an erase for the same,
> I get the problem with each MMC_ERASE command.
>
> I've also found something that fixes the issue in my
Hi Eric,
On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson wrote:
> I've figured out a way to repeat this on my machine.
>
> If I write 0xff's to the eMMC blocks, then issue an erase for the same,
> I get the problem with each MMC_ERASE command.
>
> I've also found something that fixes the issue in my
Hi all,
On 12/04/2015 09:35 AM, Eric Nelson wrote:
> Hi Fabio,
>
> On 12/02/2015 12:53 PM, Fabio Estevam wrote:
>> On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson wrote:
>>
> ...
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 53084a7..8f5d9e1 100644
>>> --- a/drivers/mmc/mmc.c
Hi
On Dec 4, 2015 5:50 PM, "Eric Nelson" wrote:
>
> Hi all,
>
> On 12/04/2015 09:08 AM, Eric Nelson wrote:
> ...
> >
> > I think you're onto something.
> >
> > According to the i.MX35 reference manual, which I think was the origin
> > of this patch, the low four bits of the SYSCTL register of the
Hi all,
On 12/04/2015 09:08 AM, Eric Nelson wrote:
...
>
> I think you're onto something.
>
> According to the i.MX35 reference manual, which I think was the origin
> of this patch, the low four bits of the SYSCTL register of the SDHC5
> 3 - SDCLKEN
> 2 - PEREN
> 1
Hi Eric,
On Fri, Dec 4, 2015 at 2:35 PM, Eric Nelson wrote:
> How easy is this for you to reproduce?
Very easy as it happens 100% of the times I run 'mmc erase' on a revC2
or revC4 board.
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lis
Hi Fabio,
On 12/02/2015 12:53 PM, Fabio Estevam wrote:
> On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson wrote:
>
...
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 53084a7..8f5d9e1 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -105,6 +105,9 @@ int mmc_send_cm
Hi Michael,
On 12/02/2015 01:00 PM, Michael Trimarchi wrote:
> Hi
>
> On Wed, Dec 2, 2015 at 8:54 PM, Fabio Estevam wrote:
>> Hi Michael,
>>
>> On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi
>> wrote:
>>
>>> Can you print the sysctl & 0xF? I want to check if this workaround is
>>> really app
Hi
On Wed, Dec 2, 2015 at 8:54 PM, Fabio Estevam wrote:
> Hi Michael,
>
> On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi
> wrote:
>
>> Can you print the sysctl & 0xF? I want to check if this workaround is
>> really applied
>
> In my testing I see the error with or without the ENGcm03648 worka
Hi Michael,
On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi
wrote:
> Can you print the sysctl & 0xF? I want to check if this workaround is
> really applied
In my testing I see the error with or without the ENGcm03648 workaround.
Regards,
Fabio Estevam
___
Hi Eric,
On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson wrote:
> You're hitting the block from a different path than we are and it will
> be tomorrow before I can get an offending board on my desk.
>
> What happens if you "#if 0" around this block?
Then the error changes to:
=> mmc erase 4000 100
Hi
On Wed, Dec 2, 2015 at 7:52 PM, Fabio Estevam wrote:
> Hi Eric,
>
> On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson wrote:
>> Sure. It's a hack, but shows where we're hitting the problem
>> (with the stop command).
>>
>> We haven't been using the "mmc erase" command, but see this when
>> using um
Hi Fabio,
On 12/02/2015 11:52 AM, Fabio Estevam wrote:
> Hi Eric,
>
> On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson wrote:
>> Sure. It's a hack, but shows where we're hitting the problem
>> (with the stop command).
>>
>> We haven't been using the "mmc erase" command, but see this when
>> using ums
Hi Eric,
On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson wrote:
> Sure. It's a hack, but shows where we're hitting the problem
> (with the stop command).
>
> We haven't been using the "mmc erase" command, but see this when
> using ums to program eMMC.
Ok, applied your patch, but still get:
=> mmc e
Hi Fabio,
On 12/02/2015 10:23 AM, Fabio Estevam wrote:
> Hi Eric,
>
> On Tue, Dec 1, 2015 at 5:05 PM, Eric Nelson wrote:
>
>> I've also recently seen this on two different custom boards. Both are
>> running i.MX6Q TO1.2 and both are using eMMC from Micron.
>
> One colleague of mine tested eMMC
Hi Eric,
On Tue, Dec 1, 2015 at 5:05 PM, Eric Nelson wrote:
> I've also recently seen this on two different custom boards. Both are
> running i.MX6Q TO1.2 and both are using eMMC from Micron.
One colleague of mine tested eMMC erasure on a mx6qsabresd revC5 board
with a eMMC from Micron and it w
Hi all,
On 11/16/2015 08:30 AM, Fabio Estevam wrote:
> On Mon, Nov 16, 2015 at 1:23 PM, Fabio Estevam wrote:
>> Hi Hector,
>>
>> On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam wrote:
>>> On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector
>>> wrote:
>>>
Could it be a silicon revision issue
On Mon, Nov 16, 2015 at 1:23 PM, Fabio Estevam wrote:
> Hi Hector,
>
> On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam wrote:
>> On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector
>> wrote:
>>
>>> Could it be a silicon revision issue?
>>> My CPU is i.MX6Q rev1.2.
>>
>> I will try to test this on
Hi Hector,
On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam wrote:
> On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector
> wrote:
>
>> Could it be a silicon revision issue?
>> My CPU is i.MX6Q rev1.2.
>
> I will try to test this on other sabresd boards next week.
I tested this on other mx6qsabres
On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector
wrote:
> Could it be a silicon revision issue?
> My CPU is i.MX6Q rev1.2.
I will try to test this on other sabresd boards next week.
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.d
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
>> issue has been there always, I believe. Appare
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 issue has been there always, I believe.
> Apparently the command erases the first block, but the operation returns an
Dear Cliff,
On 10/16/2015 01:46 PM, Cliff Brust wrote:
> I have the need to erase our eMMC from U-Boot on our custom board due to a
> hard wired
> boot up configuration. Our design is based on the Freescale i.MX6Q SabreSD
> Board
> reference design. The bottom line is the U-Boot command "mmc era
I have the need to erase our eMMC from U-Boot on our custom board due to
a hard wired boot up configuration. Our design is based on the Freescale
i.MX6Q SabreSD Board reference design. The bottom line is the U-Boot
command "mmc erase" is failing with the error "Timeout waiting for DAT0
to go hi
25 matches
Mail list logo
