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 boot
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 e
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 command
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 the
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 abo
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 stat
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
>> for
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 specifyin
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
12 matches
Mail list logo
