Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial PR for SDIOBlockdevice implementation #1

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

JojoS62
Copy link

@JojoS62 JojoS62 commented Nov 9, 2018

This is the component that was not merged into mbed-os.

add SDIOBlockdevice
implementation for STM32F4
added some description
almost the same as for STM32F4, but in F7 SDIO device is renamed to SDMMC
SDMMC1 is used for DISCO_F746NG
updated readme.md for new target
@0xc0170
Copy link
Collaborator

0xc0170 commented Nov 12, 2018

@ARMmbed/mbed-os-storage Can you review?

@dannybenor
Copy link

@0xc0170 will do after 5.11 release

@screamerbg
Copy link

@dannybenor We need a review sooner. This is blocking new Pelion DM boards by ST. Could you please help?

@dannybenor
Copy link

blockdevice should be a component and not a feature
This needs review from HAL team

#define SD_DBG 0 /*!< 1 - Enable debugging */
#define SD_CMD_TRACE 0 /*!< 1 - Enable SD command tracing */

#define SD_BLOCK_DEVICE_ERROR_WOULD_BLOCK -5001 /*!< operation would block */
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't those be in H file?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the debug settings are used private in the cpp source, they are not relevant for other modules. I have taken this approach from the SDBlockdevice.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those return errors should be exposed by the h file (possibly for SDBlockDevice as well)
An even better suggestion is to use the errors at mbed_error.h

https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_error.h

UNKNOWN                    256      Unknown error
INVALID_ARGUMENT           257      Invalid Argument
INVALID_DATA               258      Invalid data
INVALID_FORMAT             259      Invalid format
INVALID_INDEX              260      Invalid Index
...

SDIOBlockDevice.cpp Show resolved Hide resolved
SDIOBlockDevice.cpp Outdated Show resolved Hide resolved
SDIOBlockDevice.cpp Outdated Show resolved Hide resolved
SDIOBlockDevice.cpp Show resolved Hide resolved
SDIOBlockDevice.cpp Outdated Show resolved Hide resolved
SDIOBlockDevice.cpp Outdated Show resolved Hide resolved
SDIOBlockDevice.cpp Outdated Show resolved Hide resolved
* @param buffer Buffer to write blocks to
* @param addr Address of block to begin reading from
* @param size Size to read in bytes, must be a multiple of read block size
* @return 0 on success, negative error code on failure
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please try to elaborate possible error values for each API

SDIOBlockDevice.h Outdated Show resolved Hide resolved
@offirko
Copy link

offirko commented Nov 22, 2018

@JojoS62 - thanks for submitting this important BlockDevice implementation. I've left several questions and remarks - thanks!

@JojoS62
Copy link
Author

JojoS62 commented Nov 22, 2018

I have prepared some modifications as requested, but I will run the tests again first. Will push the commits tomorrow.

- removed comments
- renamed short variable names
@screamerbg
Copy link

@JojoS62 @offirko Any update on this? We have 7 ST boards using SDIO, but we're forced to use external SD (SPI) shield.

@dannybenor
Copy link

@screamerbg this requires HAL to go into mbedOS master. Please create a preq and ad HAL team

@deepikabhavnani
Copy link

@dannybenor - This PR was moved to external repo for the same reason. HAL changes might take time as they are not planned, but that should not stop users to use SDIO interface.

HAL changes will be needed to integrate with Mbed OS, but in parallel this driver can be polished and used as external. Also other partners will have reference to add to SDIO changes which will be helpful in finalizing HAL API's.

@dannybenor
Copy link

@deepikabhavnani Yes, you are right. I missed this point. LGTM

while (SD_DMA_ReadPending() != SD_TRANSFER_OK)
{
uint32_t tickstart = HAL_GetTick();
if ((HAL_GetTick() - tickstart) >= MBED_CONF_SD_TIMEOUT)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires a fix in order to measure Timeout correctly.

@offirko
Copy link

offirko commented Dec 16, 2018

@JojoS62 - thanks for making adjustments!
I believe the Timeout issue still requires a fix.

tickstart was inside checking loop
removed wait_ms() calls
added timeout checks for all while loops
@jeromecoutant
Copy link

Hi

Any update ?

Thx

@screamerbg
Copy link

@dannybenor @offirko Any update on this?

@JojoS62
Copy link
Author

JojoS62 commented Feb 7, 2019

sorry for the delay, at the moment I'm very busy with my work.
The component is working, I've applied the most fixes. Only the error codes could be improved, but the mbed errror handling has become also complex and at the moment I have no time to update this. I have used similar codes like in SDBlockDevice, so this component is usable already.
Please review and check if there are major issues that prevent using this PR.

Copy link

@offirko offirko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link

@deepikabhavnani deepikabhavnani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JojoS62 - Thanks for adding this

@deepikabhavnani
Copy link

@ARMmbed/mbed-os-maintainers - Please review and merge

@0xc0170
Copy link
Collaborator

0xc0170 commented Feb 11, 2019

@ARMmbed/mbed-os-maintainers - Please review and merge

we can review but merging is up to @ARMmbed/mbed-os-storage team I believe

/** @file fsfat_test.h
*
* mbed Microcontroller Library
* Copyright (c) 2006-2016 ARM Limited
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be 2019 (new file or at least 2018-2019)

New files should contain SPDX identifier (look at platform header files).

Copy link
Collaborator

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small license fix, rest looks fine

@deepikabhavnani
Copy link

we can review but merging is up to @ARMmbed/mbed-os-storage team I believe

Sounds good, not sure why I thought only maintainers have merge permissions on this repo

@0xc0170
Copy link
Collaborator

0xc0170 commented Feb 19, 2019

@ARMmbed/mbed-os-storage Can we progress? there's new PR that depends also on this one

@jeromecoutant
Copy link

Why this PR is not progressing ?

@adbridge
Copy link

adbridge commented Mar 6, 2019

Why this PR is not progressing ?

@ARMmbed/mbed-os-storage @dannybenor Could you please answer @jeromecoutant ?

@maclobdell
Copy link

maclobdell commented Mar 15, 2019

Just curious - would this better to now have have a generic SDIOBlockDevice in the mbed-os/components/storage/blockdevice/COMPONENT_SDIO and then specific implementations under platform-specific target code at mbed-os/targets/TARGET_/.../TARGET_/

Or alternatively, if there isn't a HAL abstraction to be used by a generic block device driver, perhaps fully target-specific SDIO blockdevice implementations could live in the target code.

Can we move forward with one of these approaches, or perhaps another approach?

mathias-arm added a commit to mathias-arm/sdio-driver that referenced this pull request Aug 9, 2019
- ARMmbed#1 is based on [JojoS62/sdio-driver/master](JojoS62@c03489c).
- ARMmbed#2 is based on [NXPmicro/sdio-driver/Add_SDIO_LPC55S69](nxp-archive@370c51a)
@jeromecoutant
Copy link

@MarceloSalazar @adbridge don't forget this feature :-)

@adbridge
Copy link

@jeromecoutant we don't deal with this repository and it doesn't form part of our mbed-os releases. @MarceloSalazar @0xc0170 do you know anything about how this repo is used/controlled ?

@JojoS62
Copy link
Author

JojoS62 commented Aug 13, 2020

It seems I missed some notifications about updates here. I will try to implement the changes soon.
@adbridge This component was not complying the rules for an integration into Mbed-os, so it was offloaded here. It would be nice if the master branch could be filled.

@irfanafa is this issue still pending? I don't have a NUCLEO_F746ZG, so I can check it only in theorie.

@irfanafa
Copy link

irfanafa commented Aug 13, 2020 via email

Copy link

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't test, but I assume @JojoS62 did !
Thx

@JojoS62
Copy link
Author

JojoS62 commented Jun 9, 2021

in the past month, I reworked this component for the F7. I added also support for the DISCO_F769NI, which uses the 2nd SDMMC interface. I still need to clean up experimental stuff and run the filesystem tests again.
I experienced some problems with the data caching and added some cache flush functions. The difficult thing is, that it depends on the memory what is used. Mbed uses a 'one linker script fits all', but this is difficult to keep when F7 with D-cache and DMA is used. Same problem when I used DMA2D for graphics. I can open an issue for that subject, I want to mention it only here because it can drive you nuts...

@0xc0170 0xc0170 self-requested a review June 28, 2021 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.