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

Add overloaded get_erase_size API with address parameter to BlockDevice #6408

Merged
merged 1 commit into from
Mar 29, 2018

Conversation

davidsaada
Copy link
Contributor

Description

Add an overloaded get_erase_size API with address parameter to BlockDevice and all derived classes.
This is due to the fact that in some flash components, erase size varies depending on address.

Pull request type

  • Feature

cmonr
cmonr previously approved these changes Mar 20, 2018
Copy link
Contributor

@cmonr cmonr left a comment

Choose a reason for hiding this comment

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

LGTM!

@cmonr
Copy link
Contributor

cmonr commented Mar 20, 2018

@AnotherButler, if you would like to take a quick look. Small doc updates.

@cmonr cmonr requested a review from geky March 20, 2018 22:26
@cmonr
Copy link
Contributor

cmonr commented Mar 20, 2018

@geky if you could take a look at the API addition. Imo, looks straightforward.

Copy link
Contributor

@geky geky left a comment

Choose a reason for hiding this comment

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

I'm for it, though unfortunately the slicing/chaining block devices need some changes.

cc @deepikabhavnani, @c1728p9

*
* @return Size of a eraseable block in bytes
* @return Size of an eraseable block in bytes
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, that's what I get for using search/replace on english...

{
return _erase_size;
}

Copy link
Contributor

@geky geky Mar 20, 2018

Choose a reason for hiding this comment

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

Oh, unfortunately this implementation is going to be much more complicated. We need to lookup the erase size for the block inside the list of block devices.

@@ -102,6 +102,11 @@ bd_size_t SlicingBlockDevice::get_erase_size() const
return _bd->get_erase_size();
}

bd_size_t SlicingBlockDevice::get_erase_size(bd_addr_t addr) const
{
return _bd->get_erase_size(addr);
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs to have the _start offset added to addr before passing addr down

@@ -276,6 +276,11 @@ bd_size_t MBRBlockDevice::get_erase_size() const
return _bd->get_erase_size();
}

bd_size_t MBRBlockDevice::get_erase_size(bd_addr_t addr) const
{
return _bd->get_erase_size(addr);
Copy link
Contributor

Choose a reason for hiding this comment

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

This also needs to add _offset to addr.

@davidsaada
Copy link
Contributor Author

davidsaada commented Mar 21, 2018

@geky Thanks for the comments. Pushed a fix. Please observe the changes (mainly the one in ChainingBlockDevice.cpp).

@cmonr
Copy link
Contributor

cmonr commented Mar 21, 2018

Pinging @geky for a re-review. Also, possibly @deepikabhavnani.

Primarily wondering if ChainingBlockDevice is the only block device that needed non-trivial changes/updates.

@davidsaada
Copy link
Contributor Author

davidsaada commented Mar 22, 2018

@cmonr I believe it is. As:
HeapBlockDevice is the basic one, not relying on anything else.
ExhaustibleBlockDevice, ObservingBlockDevice, ReadOnlyBlockDevice and ProfilingBlockDevice only add features that don't change anything related to addresses comparing to the underlying BD.
MBRBlockDevice and SlicingBlockDevice do change things comparing to the underlying BD, but they are easy to implement (and @geky showed how).
Only non-trivial one is ChainingBlockDevice, as it's the only one dealing with multiple underlying BDs.

MBED_ASSERT(0);
return 0; // satisfy compiler
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, this looks good 👍

Choose a reason for hiding this comment

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

Nothing to block this PR: Just queries for my understanding

  1. I see _bd_count(sizeof(bds) / sizeof(bds[0]) set during constructor, does this mean we erase all chain blocks in erase operation?

Copy link
Contributor

Choose a reason for hiding this comment

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

geky
geky previously approved these changes Mar 22, 2018
@deepikabhavnani
Copy link

This is due to the fact that in some flash components, erase size varies depending on address.

Please explain this comment, how erase size will vary based on the address

* @return Size of an erasable block in bytes
* @note Must be a multiple of the program size
*/
virtual bd_size_t get_erase_size(bd_addr_t addr) const

Choose a reason for hiding this comment

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

Please add param in doxygen - addr

AnotherButler
AnotherButler previously approved these changes Mar 22, 2018
@cmonr
Copy link
Contributor

cmonr commented Mar 22, 2018

@davidsaada Could you squash Amanda's copy edits, and add another commit for Deepika's comments?

After that, we should be good to start CI.

@davidsaada
Copy link
Contributor Author

Please explain this comment, how erase size will vary based on the address

@deepikabhavnani This is relevant in case the block device implements a flash components having different sector sizes (erase size = sector size). In this case, the API cannot return a constant erase size, as it depends on the address.

@deepikabhavnani
Copy link

This is relevant in case the block device implements a flash components having different sector sizes (erase size = sector size)

Single block device supporting different sector sizes? I don;t think we support that.. @geky Please clarify.

@davidsaada
Copy link
Contributor Author

Single block device supporting different sector sizes? I don;t think we support that.

@deepikabhavnani Indeed, we currently don't have any block device that has variant erase sizes. However, unless we add this API, we'll never be able to implement block devices supporting flash components with variant sector sizes.

@cmonr
Copy link
Contributor

cmonr commented Mar 23, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Mar 23, 2018

Build : SUCCESS

Build number : 1545
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6408/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Mar 23, 2018

@cmonr
Copy link
Contributor

cmonr commented Mar 23, 2018

12:38:17 FATAL: command execution failed
12:38:17 java.io.EOFException

ಠ_ಠ

/morph export-build

@mbed-ci
Copy link

mbed-ci commented Mar 23, 2018

@mbed-ci
Copy link

mbed-ci commented Mar 24, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 24, 2018

@AnotherButler Can you review the latest update?

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 24, 2018

@davidsaada Handbook update reference?

@theotherjimmy theotherjimmy merged commit 64df0dd into ARMmbed:master Mar 29, 2018
@davidsaada davidsaada deleted the david_erase_size_addr branch July 9, 2018 13:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants