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 bug go to:
> https://bugs.launchpad.net/arndale/+bug/1157372/+subscriptions
>
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 ay(delay_ in_micro_ secs);" to cause delays, rather than /bugs.launchpad .net/bugs/ 1157372 rmPkg/ExynosPkg /Exynos5250/ Drivers/ SDHCxe_ EVT1/SDHCxe. c. /bugs.launchpad .net/arndale/ +bug/1157372/ +subscriptions
> not, perhaps that is the "proper" fix.
>
> To get around the noise problem, you could try using the function
> "MicroSecondDel
> 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:/
>
> 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:
>
> ~/SamsungPlatfo
>
> 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 bug go to:
> https:/
>