FAT file system crashes when creating new file or directory within the UefiShell or EdkShell (microSD Card)

[Steven Kinney]

While integrating the UEFI.org SCT onto the Arndale board, within the EdkShell environment, the FAT file system crashed when the SCT installer attempted to create a new directory; note the microSD Card is hosting the file system.

In troubleshooting to problem, the UefiShell environment has the same symptoms and times out when trying to create the new directory:

2.0 Shell> mkdir fs0:\test
SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x10
CMD24 fails. Status: 80000012
TransferBlockData fails. 80000012
SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
CMD24 fails. Status: 80000012
TransferBlockData fails. 80000012
SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
CMD24 fails. Status: 80000012
TransferBlockData fails. 80000012
Directory 'fs0:\test' unable to create.
2.0 Shell>

In addition, the FAT file system crashes as shown below:

2.0 FS0:\> ls
SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
CMD24 fails. Status: 80000012
TransferBlockData fails. 80000012
Error. No matching files were found.
2.0 FS0:\>

This failure mode has been verified independently and is blocking UEFI SCT integration relative to the Arndale board.

Identified the problem in:
   ~/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/SDHCxe_EVT1/SDHCxe.c.

Specifically in function TransferBlock(). There is a timing issue that causes a problem with block write without a DEBUG delay. Still looking at the timing stack-up, but writes to SDHC within UefiShell are now functional; albeit noisy.

Down to a single "delay", using DEBUG, to correct the problem and will update and fix this bug for long term, but for now the UefiShell SDHC writes are non-blocking.

BTW, this is on the Arndale board and I can supply a patch so that regression testing can verify this short term fix across other platforms.

[Anmar Oueja (anmar)]

This doesn't just happen on the Arndale. It happens in models and VE board

[Anmar Oueja (anmar)]

This happens on A15 SoCs and not A9

[Steven Kinney (steven-kinney)]

Identified the problem in ~/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/SDHCxe_EVT1/SDHCxe.c, specifically in function TransferBlock(). There is a timing issue that causes a problem with block write without a DEBUG delay. Still looking at the timing stack-up, but writes to SDHC within UefiShell are now functional; albeit noisy. Down to a single "delay", using DEBUG, to correct the problem and will update and fix this bug for long term, but for now the UefiShell SDHC writes are non-blocking. BTW, this is on the Arndale board and I can supply a patch so that regression testing can verify this short term fix across other platforms.

[Ryan Harkin (ryanharkin)]

The driver ought to have configurable timeouts for such occasions, if not, perhaps that is the "proper" fix.

To get around the noise problem, you could try using the function "MicroSecondDelay(delay_in_micro_secs);" to cause delays, rather than using a DEBUG.

Of course, the problem you are seeing could be interrupt related or something like that, so switching to a delay would also verify that it is a pure timeout problem.

[Steven Kinney (steven-kinney)]

Hi Ryan,

           Thinking along the same line, just want to make sure any delay I
put in will scale across all platforms. Simply think this delay is needed
for additional time for writes regarding the SD card. Will have more
information on Friday; took today off. Thanks for your advice; always
appreciated.

BR,

Steve
On Apr 11, 2013 4:35 AM, "Ryan Harkin" <email address hidden> wrote:

> The driver ought to have configurable timeouts for such occasions, if
> not, perhaps that is the "proper" fix.
>
> To get around the noise problem, you could try using the function
> "MicroSecondDelay(delay_in_micro_secs);" to cause delays, rather than
> using a DEBUG.
>
> Of course, the problem you are seeing could be interrupt related or
> something like that, so switching to a delay would also verify that it
> is a pure timeout problem.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1157372
>
> Title:
> FAT file system crashes when creating new file or directory within the
> UefiShell or EdkShell (microSD Card)
>
> Status in Arndale Support:
> Confirmed
> Status in UEFI Support in Linaro:
> Confirmed
>
> Bug description:
> While integrating the UEFI.org SCT onto the Arndale board, within the
> EdkShell environment, the FAT file system crashed when the SCT
> installer attempted to create a new directory; note the microSD Card
> is hosting the file system.
>
> In troubleshooting to problem, the UefiShell environment has the same
> symptoms and times out when trying to create the new directory:
>
> 2.0 Shell> mkdir fs0:\test
> SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x10
> CMD24 fails. Status: 80000012
> TransferBlockData fails. 80000012
> SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
> CMD24 fails. Status: 80000012
> TransferBlockData fails. 80000012
> SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
> CMD24 fails. Status: 80000012
> TransferBlockData fails. 80000012
> Directory 'fs0:\test' unable to create.
> 2.0 Shell>
>
> In addition, the FAT file system crashes as shown below:
>
> 2.0 FS0:\> ls
> SDHC::MSHC_SendCmd timeout CMD:24 RINT:0x1010
> CMD24 fails. Status: 80000012
> TransferBlockData fails. 80000012
> Error. No matching files were found.
> 2.0 FS0:\>
>
> This failure mode has been verified independently and is blocking UEFI
> SCT integration relative to the Arndale board.
>
> Identified the problem in:
>
> ~/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/SDHCxe_EVT1/SDHCxe.c.
>
> Specifically in function TransferBlock(). There is a timing issue that
> causes a problem with block write without a DEBUG delay. Still looking
> at the timing stack-up, but writes to SDHC within UefiShell are now
> functional; albeit noisy.
>
> Down to a single "delay", using DEBUG, to correct the problem and will
> update and fix this bug for long term, but for now the UefiShell SDHC
> writes are non-blocking.
>
> BTW, this is on the Arndale board and I can supply a patch so that
> regression testing can verify this short term fix across other
> platforms.
>
> To manage notifications about this b...

[Leif Lindholm (leif-lindholm)]

Arndale is no longer actively maintained.