[U-Boot] Pine64 problems with GPT partitions

[Andre Przywara]

Hi,

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 ;-)

Cheers,
Andre.