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

Fcb erase value support #28839

Merged

Conversation

de-nordic
Copy link
Collaborator

@de-nordic de-nordic commented Oct 1, 2020

Adds support to non-0xff erasable flash devices to FCB.

Resolves #28693

@github-actions github-actions bot added area: API Changes to public APIs area: File System area: native port Host native arch port (native_posix) area: Tests Issues related to a particular existing or missing test labels Oct 1, 2020
@nashif
Copy link
Member

nashif commented Oct 21, 2020

@nvlsianpu please review

@nvlsianpu
Copy link
Collaborator

sure

@nvlsianpu
Copy link
Collaborator

@erwango This might be used now on some STM32L1 SoCs which has 0x00 as flash erased state.

@utzig
Copy link
Member

utzig commented Oct 23, 2020

@erwango This might be used now on some STM32L1 SoCs which has 0x00 as flash erased state.

I was gonna try it a few weeks ago but seems like the stm32 flash driver does not support L1 as of yet.

@de-nordic
Copy link
Collaborator Author

I was gonna try it a few weeks ago but seems like the stm32 flash driver does not support L1 as of yet.

Thanks @utzig !

@nvlsianpu
Copy link
Collaborator

@erwango @utzig ping

@erwango
Copy link
Member

erwango commented Nov 5, 2020

Thanks for pinging me. Though, I don't have ways to test this right now and I'm not sure my review has much added value.
What I would suggest though, is to move erase-value prop value definition from zephyr,sim-flash.yaml to flash-controller.yaml so that it could be used widely. Not sure this is the topic of this PR though.

@nvlsianpu
Copy link
Collaborator

@erwango ^^ PR is no related to where erase-value property is defined.

Copy link
Member

@utzig utzig left a comment

Choose a reason for hiding this comment

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

LGTM, left some nitpicks.

#include <drivers/flash.h>

#define MK32(val) ((((uint32_t)val) << 24) | ((val) << 16) | \
((val) << 8) | (val))
Copy link
Member

Choose a reason for hiding this comment

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

This would not work correctly if a uint8_t is passed in because you need to also cast << 16 and << 8. Also it would be better to cast the the MSB with (((uint32_t)(val)) << 24) (one extra set of parenthesis around val. But in the end this would be better being just an inline function so no casts are required.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed.

{
const uint8_t ev = fcb->f_erase_value;

return (fcb->f_magic ^ ~((ev << 24) | (ev << 16) | (ev << 8) | ev));
Copy link
Member

Choose a reason for hiding this comment

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

If MK32 was declared in this file you could use it with ev here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed.

return 1;
} else if (len < FCB_MAX_LEN) {
buf[0] = (len & 0x7f) | 0x80;
buf[1] = len >> 7;
buf[0] = ((len & 0x7f) | 0x80) ^ ~fcb->f_erase_value;
Copy link
Member

Choose a reason for hiding this comment

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

This is a nitpick, but can ((len & 0x7f) | 0x80) ever result in something that is not equal to just (len | 0x80) when you're storing it in a uint8_t?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I doubt.

@nvlsianpu
Copy link
Collaborator

cc @carlescufi This is ready.

@carlescufi
Copy link
Member

@de-nordic can you rebase this? seems like the doc build error was solved in master

Overlays that enable FCB tests on qemu_x86 plaftorm have been added.

Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The FCB has been strongly tied to 0xff erased flash devices and this
commit adds support for other erase values.

Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Fcb tests have been modified to be able to work on non-0xff erase
value flash devices.

Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
@carlescufi carlescufi merged commit 635230c into zephyrproject-rtos:master Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: File System area: native port Host native arch port (native_posix) area: Tests Issues related to a particular existing or missing test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FCB support for non-0xFF flash erase values
6 participants