[U-Boot] Pine64 problems with GPT partitions
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.
There is a bug report from openSUSE here with additional informations: https://bugzilla.opensuse.org/show_bug.cgi?id=1098550
Guillaume
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.
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? 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...
Cheers, Andre.
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
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@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@olimex.com Date: Tue Mar 27 16:57:23 2018 +0300
sunxi: mmc: Fix phase delays ----------------- and: ----------------- commit 5ff8e54888e4d26a352453564f7f599d29696dc9 Author: Philipp Tomsich philipp.tomsich@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.
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@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@olimex.com Date: Tue Mar 27 16:57:23 2018 +0300
sunxi: mmc: Fix phase delays
and:
commit 5ff8e54888e4d26a352453564f7f599d29696dc9 Author: Philipp Tomsich philipp.tomsich@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.
Peter
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@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@olimex.com Date: Tue Mar 27 16:57:23 2018 +0300
sunxi: mmc: Fix phase delays
and:
commit 5ff8e54888e4d26a352453564f7f599d29696dc9 Author: Philipp Tomsich philipp.tomsich@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
participants (5)
-
Alexander Graf -
Andre Przywara -
André Przywara
-
guillaume.gardet＠free.fr -
Peter Robinson