[U-Boot] Pine64 problems with GPT partitions

[André Przywara]

Hi,

On 06/26/2018 04:09 PM, Peter Robinson wrote:
>> On 26/06/18 15:52, Alexander Graf wrote:
>>> On 06/26/2018 04:39 PM, Andre Przywara wrote:
>>>> Hi Guillaume,
>>>>
>>>> On 26/06/18 15:18, guillaume.gardet at free.fr wrote:
>>>>> Hi Andre,
>>>>>
>>>>> You are the maintainer of Pine64 in U-Boot, so I want to let you know
>>>>> that Pine64 has problems to access GPT partitions, whereas MBR
>>>>> partitions seem to be OK.
>>>> Is that with the latest U-Boot?
>>>>
>>>> In general GPT is problematic on any Allwinner board, since a standard
>>>> GPT (sectors 1-33) collides with the SPL location on the media (sectors
>>>> 16-80). The latter is mandated by the BootROM and cannot be changed
>>>> (apart from wild hacks to make them coexist).
>>>> One workaround (apart from using MBR) is to restrict the number of GPT
>>>> partitions to 56, so that the GPT ends at sector 16. However this
>>>> is a bit fragile, since GPT mandates the first 34 sectors to be
>>>> available, so any valid partition tool could clobber the SPL at any time.
>>>> So can you check whether this is a problem here or did you take this
>>>> already into account?
>>>> Andreas and Alex should know about this.
>>>
>>> Yes, we decrease the size of the GPT in our image creation already.
>>>
>>>>
>>>>> There is a bug report from openSUSE here with additional
>>>>> informations: https://bugzilla.opensuse.org/show_bug.cgi?id=1098550
>>>> But this reads more like a separate problem. I have heard reports in the
>>>> past that *some* MMC reads (from some sectors?) are very slow in U-Boot,
>>>> but that seemed to be a problem with the ext4 U-Boot driver, possibly in
>>>> conjunction with the Allwinner MMC driver. But I couldn't really
>>>> reproduce this yet reliably.
>>>>
>>>> Another thing that triggered error reports in the past were unreliable
>>>> SD cards, which led to seemingly random errors, in some circumstances.
>>>> Has the SD card been changed to rule this out?
>>>
>>> Yes, we used multiple SD cards. This also seems to be a regression - a
>>> few months back Andreas' Pine64 worked just fine.
>>>
>>> It's very easy to reproduce. Grab a random SD card with an FS on it and
>>> just do
>>>
>>>   U-Boot # ls mmc 0:1
>>>
>>> a few times. I wasn't able to run it more than 10 or 20 times without at
>>> least one invocation that errored out.
>>>
>>>> Also a Pine64 classic is an insufficient power supply, which happens to
>>>> work *most of the time*. Though I doubt that this is a problem here...
>>>
>>> I just used a random power plug I had lying around, but given that this
>>> is reported as a regression, I'm much more inclined to believe that it's
>>> a problem in the clock tree. Unfortunately I don't have anything at hand
>>> to properly analyze the SD clock coming in.
>>
>> I find:
>> -----------------
>> commit 4744d81cc0dbe238bd4d8cd88c1c71022bffa621
>> Author: Stefan Mavrodiev <stefan at olimex.com>
>> Date:   Tue Mar 27 16:57:23 2018 +0300
>>
>>     sunxi: mmc: Fix phase delays
>> -----------------
>> and:
>> -----------------
>> commit 5ff8e54888e4d26a352453564f7f599d29696dc9
>> Author: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>> Date:   Wed Mar 21 12:18:58 2018 +0100
>>
>>     sunxi: improve throughput in the sunxi_mmc driver
>> -----------------
>>
>> as possible regression candidates. Any chance someone could revert them
>> and re-test? Since the sun is still up, I can't do any testing yet ;-)
> 
> I believe it's the second one "sunxi: improve throughput in the
> sunxi_mmc driver" from some testing I did with the patch added to
> 2018.03, I tried the patch to see if it sped up booting, which it did
> for some devices, but it caused similar issues for me on the Pine64.
> It was on my todo list to follow up with the latest upstream RCs to
> see if the issue was still around but I've not had the time yet.

It is still around and is indeed the culprit:
This patch improves device performance by reading the arch timer very
often instead of waiting at least for a millisecond or so every time an
MMC operation has not yet finished.
These frequent reads are actually provoking the Allwinner A64 arch timer
erratum, where the counter sometimes makes jumps forwards or backwards [1].
Trying to piggy back on the similar Freescale erratum does not help, so
I ported the Linux erratum workaround over to U-Boot.
This seems to fix the issue for me, while retaining the good MMC
performance.

Will send two patches to the ML shortly, would appreciate if people
could confirm there that the fix works for them.

Cheers,
Andre.

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576886.html