On 7/28/2018 6:13 AM, Dmitry Osipenko wrote:
On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote:
Kingston KE4CN3K6A.
Though I am pretty sure I've figured out the instability.
Brought it in to work and hooked it to a scope.
Couldn't find clock, but cmd and all eight bits are running at 1.2
On 7/28/2018 6:13 AM, Dmitry Osipenko wrote:
On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote:
Kingston KE4CN3K6A.
Though I am pretty sure I've figured out the instability.
Brought it in to work and hooked it to a scope.
Couldn't find clock, but cmd and all eight bits are running at 1.2
On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote:
> Kingston KE4CN3K6A.
> Though I am pretty sure I've figured out the instability.
> Brought it in to work and hooked it to a scope.
> Couldn't find clock, but cmd and all eight bits are running at 1.2 volts.
> Repeated the results with the
On Friday, 27 July 2018 23:19:53 MSK Peter Geis wrote:
> Kingston KE4CN3K6A.
> Though I am pretty sure I've figured out the instability.
> Brought it in to work and hooked it to a scope.
> Couldn't find clock, but cmd and all eight bits are running at 1.2 volts.
> Repeated the results with the
Kingston KE4CN3K6A.
Though I am pretty sure I've figured out the instability.
Brought it in to work and hooked it to a scope.
Couldn't find clock, but cmd and all eight bits are running at 1.2 volts.
Repeated the results with the bootloader, the original kernel, and my
mainline.
Also noticed that
Kingston KE4CN3K6A.
Though I am pretty sure I've figured out the instability.
Brought it in to work and hooked it to a scope.
Couldn't find clock, but cmd and all eight bits are running at 1.2 volts.
Repeated the results with the bootloader, the original kernel, and my
mainline.
Also noticed that
On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote:
> On 07/26/2018 01:36 PM, Stefan Agner wrote:
> > On 26.07.2018 18:39, Peter Geis wrote:
> >> I finally got around to testing this on the Ouya (Tegra 3).
> >
> > Thanks for testing!
> >
> >> I found that the "Got
On Thursday, 26 July 2018 20:48:55 MSK Peter Geis wrote:
> On 07/26/2018 01:36 PM, Stefan Agner wrote:
> > On 26.07.2018 18:39, Peter Geis wrote:
> >> I finally got around to testing this on the Ouya (Tegra 3).
> >
> > Thanks for testing!
> >
> >> I found that the "Got
On 07/26/2018 01:36 PM, Stefan Agner wrote:
On 26.07.2018 18:39, Peter Geis wrote:
I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
I found that the "Got command interrupt 0x0001 even though no
command operation was in progress." error occurred when
On 07/26/2018 01:36 PM, Stefan Agner wrote:
On 26.07.2018 18:39, Peter Geis wrote:
I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
I found that the "Got command interrupt 0x0001 even though no
command operation was in progress." error occurred when
On 26.07.2018 18:39, Peter Geis wrote:
> I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
>
> I found that the "Got command interrupt 0x0001 even though no
> command operation was in progress." error occurred when the interface
On 26.07.2018 18:39, Peter Geis wrote:
> I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
>
> I found that the "Got command interrupt 0x0001 even though no
> command operation was in progress." error occurred when the interface
I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
I found that the "Got command interrupt 0x0001 even though no
command operation was in progress." error occurred when the interface
is unstable.
I've had a lot of problems with sdmmc4 stability on the Ouya
I finally got around to testing this on the Ouya (Tegra 3).
Thanks for testing!
I found that the "Got command interrupt 0x0001 even though no
command operation was in progress." error occurred when the interface
is unstable.
I've had a lot of problems with sdmmc4 stability on the Ouya
On 26.07.2018 17:12, Peter Geis wrote:
> On 07/26/2018 10:47 AM, Stefan Agner wrote:
>> On 26.07.2018 15:56, Peter Geis wrote:
>>> On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM
On 26.07.2018 17:12, Peter Geis wrote:
> On 07/26/2018 10:47 AM, Stefan Agner wrote:
>> On 26.07.2018 15:56, Peter Geis wrote:
>>> On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM
On 07/26/2018 10:47 AM, Stefan Agner wrote:
On 26.07.2018 15:56, Peter Geis wrote:
On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for
On 07/26/2018 10:47 AM, Stefan Agner wrote:
On 26.07.2018 15:56, Peter Geis wrote:
On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for
On 26.07.2018 15:56, Peter Geis wrote:
> On 07/12/2018 03:39 AM, Stefan Agner wrote:
>> It seems that SD3.0 advertisement needs to be set for higher eMMC
>> speed modes (namely DDR52) as well. The TRM states that the SD3.0
>> advertisement bit should be set for all controller instances, even
>>
On 26.07.2018 15:56, Peter Geis wrote:
> On 07/12/2018 03:39 AM, Stefan Agner wrote:
>> It seems that SD3.0 advertisement needs to be set for higher eMMC
>> speed modes (namely DDR52) as well. The TRM states that the SD3.0
>> advertisement bit should be set for all controller instances, even
>>
On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When
On 07/12/2018 03:39 AM, Stefan Agner wrote:
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When specifying vqmmc-supply as a fixed 1.8V regulator on a
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When specifying vqmmc-supply as a fixed 1.8V regulator on a
24 matches
Mail list logo
