> -----Original Message----- > From: Albecki, Mateusz > Sent: Thursday, February 20, 2020 12:05 AM > To: devel@edk2.groups.io > Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming > Subject: [PATCHv2 0/4] MdeModulePkg/SdMmcPciHcDxe: Refactor > command processing > > This patch series aims to refactor command processing to achieve following > > - Trace the failing TRB packets to see what commands are failing and for > what reasons > - Get the response data even if data transfer timed out to allow easier > debugging > - Fix the PIO mode which is currently completely broken. > > Changes in v2: > - Moved verbose packet prints after the command is finished to capture the > successfull command response > - Fixed the debug prints > - PIO data will be moved with width matching the alignment of the block size. > For majority of transfers that means UINT32 width. > > Tests performed: > - Each patch in the series has passed boot from eMMC with ADMAv3 data > transfer mode > - SDMA based boot has been tested with the full patch series > - PIO based boot has been tested with the full patch series > - PIO based data transfer has been additionally tested by creating and > modyfing a file in EFI shell > - Tested async PIO transfer - results below > > Async test results: > I've tested a simple async write and then readback from the eMMMC device > using block IO v2. I have observed > that while the requests are processed correctly by the eMMC driver as soon > as they finish platform will sometimes > mibehave. I've tested async without my changes and the strange behavior > reproduces. Right now I am suspecting there > is some problem either in the EDK2 core that performs async or in the > platform specific code. It is also possible that > I coded the Async BlockIo incorrectly although the test code was rather > simple. Additionally I was able > to observe that on many eMMC controllers PIO based data transfer is broken. > I was only able to find one platform > that supported PIO. Detailed observation below > > Platform 1 (PIO working). > - Test code was able to perform async write to eMMC LBA 0 > - As soon as the callback is called CPU exception happens > - After reboot test code was able to perform async read > - As soon as the callback is called CPU exception happens > - After reboot sync read was able to confirm that data matches what was > written by async write > > Platform2 (PIO is returning trash data - all 0xAF) > - Test code was able to perform async write(although it didn't realyl came > through to the device) > - After write finished test code was able to perform async read(again all data > was 0xAF but the logic in the driver works) > > Platform2 (again PIO is returning trash data) > - Test code scheduled 5 async writes. 2 writes finished and after that CPU > exception was signaled. > > Platform3(also trash data from PIO) > - Test code scheduled one async write as soon as it was done platform > rebooted > > I didn't want to spend any more time debugging this issue as I think it would > turn into the platform debug and what I > observed gave me some confidence that PIO in async is generally working.
Hello Mateusz, Could you help to share your async test codes? I can help to double confirm whether the issue you observed is related with them or not. Also, since edk2 repo is under soft freeze period for the next stable tag, I would prefer for the series to get into the code base after the formal announce of the stable tag (2020-02-28). I will still give the 'Reviewed-by' after my review of the series though. Do you have concern for this? Best Regards, Hao Wu > > All tests were performed with eMMC in HS400 @200MHz clock frequency. > > For easier review & integration patch has been pushed here: > Whole series: > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor > Whole series + SDMA force code(test 3): > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor_force_sd > ma > Whole series + PIO force code(test 4): > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor_force_pio > > Cc: Hao A Wu <hao.a...@intel.com> > Cc: Marcin Wojtas <m...@semihalf.com> > Cc: Zhichao Gao <zhichao....@intel.com> > Cc: Liming Gao <liming....@intel.com> > > Mateusz Albecki (4): > MdeModulePkg/SdMmcPciHcDxe: Enhance driver traces > MdeModulePkg/SdMmcPciHcDxe: Read response on command completion > MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion > MdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer mode > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 4 + > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 521 > ++++++++++++++++----- > 2 files changed, 417 insertions(+), 108 deletions(-) > > -- > 2.14.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54656): https://edk2.groups.io/g/devel/message/54656 Mute This Topic: https://groups.io/mt/71399250/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
