On 06/26/2018 04:39 PM, Andre Przywara wrote:
Hi Guillaume,
On 26/06/18 15:18, guillaume.gardet@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.
Alex