Add Flash Device API
Hi All, Attached is the updated flashdev API (v2). I've focused on the feedback previously provided. I've added called the missing calls to bring this API inline with that of the zephyr example provided. The formatting is brought inline with RTEMS style. The shell command is extended to include all previous and added API calls. Included is a testsuite which tests the API calls and wraps a virtual flash device. I want to thank you all for your understanding and feedback on my first submission. I'm more than happy to make further changes to this submission based on feedback to provide an acceptable addition. Thanks, Aaron. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Flash Device API
Hi Chris. Yes, Sorry. I'll resend the correct patches with v2. Thanks, Aaron. --- Original Message --- On Thursday, April 6th, 2023 at 4:59 PM, Chris Johns wrote: > > > Hi Aaron, > > Thanks for this. Is this v2 of patches? > > Chris > > On 6/4/2023 4:52 pm, aaron.nyh...@unfoldedeffective.com wrote: > > > Attached is the updated flashdev API. I've focused on the feedback > > previously provided. I've added called the missing calls to bring > > this API inline with that of the zephyr example provided. The > > formatting is brought inline with RTEMS style. The shell command is > > extended to include all previous and added API calls. Included is a > > testsuite which tests the API calls and wraps a virtual flash device. > > > > I want to thank you all for your understanding and feedback on my > > first submission. I'm more than happy to make further changes to > > this submission based on feedback to provide an acceptable addition. > > > > Thanks, > > Aaron. > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Flash Device API
Hi Aaron, Thanks for this. Is this v2 of patches? Chris On 6/4/2023 4:52 pm, aaron.nyh...@unfoldedeffective.com wrote: > Attached is the updated flashdev API. I've focused on the feedback > previously provided. I've added called the missing calls to bring > this API inline with that of the zephyr example provided. The > formatting is brought inline with RTEMS style. The shell command is > extended to include all previous and added API calls. Included is a > testsuite which tests the API calls and wraps a virtual flash device. > > I want to thank you all for your understanding and feedback on my > first submission. I'm more than happy to make further changes to > this submission based on feedback to provide an acceptable addition. > > Thanks, > Aaron. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Add Flash Device API
Attached is the updated flashdev API. I've focused on the feedback previously provided. I've added called the missing calls to bring this API inline with that of the zephyr example provided. The formatting is brought inline with RTEMS style. The shell command is extended to include all previous and added API calls. Included is a testsuite which tests the API calls and wraps a virtual flash device. I want to thank you all for your understanding and feedback on my first submission. I'm more than happy to make further changes to this submission based on feedback to provide an acceptable addition. Thanks, Aaron. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
Hi All. Sorry for the lack of documentation and clarity in my original submission. Thank you all for the feedback, taking it all on board and will come back with a more complete and acceptable submission. I realised the original ticket number that I quoted was incorrect, #4869 is the correct number. Thanks for your understanding and patience, Aaron. --- Original Message --- On Saturday, March 18th, 2023 at 8:26 AM, Will wrote: > On Fri, Mar 17, 2023 at 4:24 PM Gedare Bloom wrote: > > > Thank you Aaron for contributing this. I have a few comments below, > > and I'll also give some comments on your code shortly. > > > > On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber > > wrote: > > > > > > > > > > > > On 16.03.23 23:07, Chris Johns wrote: > > > > On 16/3/2023 6:13 pm, Sebastian Huber wrote: > > > >> Hello Aaron, > > > >> > > > >> this API seems to be RTEMS-specific. Maybe we should simply pick up an > > > >> existing > > > >> solution which is in more wide spread use, for example: > > > >> > > > >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html > > > > > > > > That interface seems Zepher specific and looks to me like a series of > > > > calls that > > > > appear reasonable as a list to cover. > > > > > > The Zephyr API has drivers for a couple of chips: > > > > > > https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash > > > > > That code looks very zephyr-oriented. I think it would be a challenge > > to go first toward porting this API, if it requires substantial > > modifications of the upstream drivers to also use them, then it is > > more of a maintenance burden than the probable benefits of the code > > reuse. As a starting point, I do see a bespoke RTEMS implementation as > > a suitable place to begin. But, it would be good to understand the > > alternative flash driver frameworks that are out there, and what may > > be pros/cons of adopting them. > > > > > > The patch Aaron has posted is a driver. I > > > > prefer a driver like we have for I2C, SPI etc because the of support it > > > > brings. > > > > > > The I2C and SPI APIs are ported from Linux, so not RTEMS-specific. > > > > > > > > > > > The initial set of ioctl commands is small to start with. If you feel > > > > we should > > > > offer more I suggest they get added once this is merged. > > > > > > > > Is the change OK? > > > > > > I am not opposed to commit this API, however, I don't think it is a step > > > forward. It is yet another RTEMS-specific API. It has no related > > > documentation patches. The API has no high level user (for example > > > JAFFS2). The API has no implementation. It has no tests. It has no > > > driver framework (ONFI, JEDEC). It has no example driver. It has no > > > Doxygen documentation. The coding style of the new file has nothing to > > > do with the RTEMS coding style. > > > > > > > I think the provided code appears to be a good starting point. I > > would request that you might add Doxygen something aligned with what > > we have for the i2c or spi would be good. > > https://docs.rtems.org/doxygen/branches/master/group__I2C.html > > > > In addition to the shell command addition, can you create/extend a > > testsuite for exercising the API? > > > > I will address the code directly also, but these high-level additions > > will greatly improve the submission of a new API. Unfortunately, my > > work on code formatting is not quite complete enough to rely on it for > > fixing any style issues. I'll do what I can to guide you through that. > > > Aaron, > Just in case you haven't already found it, the document you should be using > for style and header documentation is here: > https://docs.rtems.org/branches/master/eng/coding-conventions.html > > Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
On Fri, Mar 17, 2023 at 4:24 PM Gedare Bloom wrote: > Thank you Aaron for contributing this. I have a few comments below, > and I'll also give some comments on your code shortly. > > On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber > wrote: > > > > > > > > On 16.03.23 23:07, Chris Johns wrote: > > > On 16/3/2023 6:13 pm, Sebastian Huber wrote: > > >> Hello Aaron, > > >> > > >> this API seems to be RTEMS-specific. Maybe we should simply pick up > an existing > > >> solution which is in more wide spread use, for example: > > >> > > >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html > > > > > > That interface seems Zepher specific and looks to me like a series of > calls that > > > appear reasonable as a list to cover. > > > > The Zephyr API has drivers for a couple of chips: > > > > https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash > > > That code looks very zephyr-oriented. I think it would be a challenge > to go first toward porting this API, if it requires substantial > modifications of the upstream drivers to also use them, then it is > more of a maintenance burden than the probable benefits of the code > reuse. As a starting point, I do see a bespoke RTEMS implementation as > a suitable place to begin. But, it would be good to understand the > alternative flash driver frameworks that are out there, and what may > be pros/cons of adopting them. > > > > The patch Aaron has posted is a driver. I > > > prefer a driver like we have for I2C, SPI etc because the of support > it brings. > > > > The I2C and SPI APIs are ported from Linux, so not RTEMS-specific. > > > > > > > > The initial set of ioctl commands is small to start with. If you feel > we should > > > offer more I suggest they get added once this is merged. > > > > > > Is the change OK? > > > > I am not opposed to commit this API, however, I don't think it is a step > > forward. It is yet another RTEMS-specific API. It has no related > > documentation patches. The API has no high level user (for example > > JAFFS2). The API has no implementation. It has no tests. It has no > > driver framework (ONFI, JEDEC). It has no example driver. It has no > > Doxygen documentation. The coding style of the new file has nothing to > > do with the RTEMS coding style. > > > > I think the provided code appears to be a good starting point. I > would request that you might add Doxygen something aligned with what > we have for the i2c or spi would be good. > https://docs.rtems.org/doxygen/branches/master/group__I2C.html > > In addition to the shell command addition, can you create/extend a > testsuite for exercising the API? > > I will address the code directly also, but these high-level additions > will greatly improve the submission of a new API. Unfortunately, my > work on code formatting is not quite complete enough to rely on it for > fixing any style issues. I'll do what I can to guide you through that. > Aaron, Just in case you haven't already found it, the document you should be using for style and header documentation is here: https://docs.rtems.org/branches/master/eng/coding-conventions.html Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
Thank you Aaron for contributing this. I have a few comments below, and I'll also give some comments on your code shortly. On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber wrote: > > > > On 16.03.23 23:07, Chris Johns wrote: > > On 16/3/2023 6:13 pm, Sebastian Huber wrote: > >> Hello Aaron, > >> > >> this API seems to be RTEMS-specific. Maybe we should simply pick up an > >> existing > >> solution which is in more wide spread use, for example: > >> > >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html > > > > That interface seems Zepher specific and looks to me like a series of calls > > that > > appear reasonable as a list to cover. > > The Zephyr API has drivers for a couple of chips: > > https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash > That code looks very zephyr-oriented. I think it would be a challenge to go first toward porting this API, if it requires substantial modifications of the upstream drivers to also use them, then it is more of a maintenance burden than the probable benefits of the code reuse. As a starting point, I do see a bespoke RTEMS implementation as a suitable place to begin. But, it would be good to understand the alternative flash driver frameworks that are out there, and what may be pros/cons of adopting them. > > The patch Aaron has posted is a driver. I > > prefer a driver like we have for I2C, SPI etc because the of support it > > brings. > > The I2C and SPI APIs are ported from Linux, so not RTEMS-specific. > > > > > The initial set of ioctl commands is small to start with. If you feel we > > should > > offer more I suggest they get added once this is merged. > > > > Is the change OK? > > I am not opposed to commit this API, however, I don't think it is a step > forward. It is yet another RTEMS-specific API. It has no related > documentation patches. The API has no high level user (for example > JAFFS2). The API has no implementation. It has no tests. It has no > driver framework (ONFI, JEDEC). It has no example driver. It has no > Doxygen documentation. The coding style of the new file has nothing to > do with the RTEMS coding style. > I think the provided code appears to be a good starting point. I would request that you might add Doxygen something aligned with what we have for the i2c or spi would be good. https://docs.rtems.org/doxygen/branches/master/group__I2C.html In addition to the shell command addition, can you create/extend a testsuite for exercising the API? I will address the code directly also, but these high-level additions will greatly improve the submission of a new API. Unfortunately, my work on code formatting is not quite complete enough to rely on it for fixing any style issues. I'll do what I can to guide you through that. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
On 16.03.23 23:07, Chris Johns wrote: On 16/3/2023 6:13 pm, Sebastian Huber wrote: Hello Aaron, this API seems to be RTEMS-specific. Maybe we should simply pick up an existing solution which is in more wide spread use, for example: https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html That interface seems Zepher specific and looks to me like a series of calls that appear reasonable as a list to cover. The Zephyr API has drivers for a couple of chips: https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash The patch Aaron has posted is a driver. I prefer a driver like we have for I2C, SPI etc because the of support it brings. The I2C and SPI APIs are ported from Linux, so not RTEMS-specific. The initial set of ioctl commands is small to start with. If you feel we should offer more I suggest they get added once this is merged. Is the change OK? I am not opposed to commit this API, however, I don't think it is a step forward. It is yet another RTEMS-specific API. It has no related documentation patches. The API has no high level user (for example JAFFS2). The API has no implementation. It has no tests. It has no driver framework (ONFI, JEDEC). It has no example driver. It has no Doxygen documentation. The coding style of the new file has nothing to do with the RTEMS coding style. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
On 16/3/2023 6:13 pm, Sebastian Huber wrote: > Hello Aaron, > > this API seems to be RTEMS-specific. Maybe we should simply pick up an > existing > solution which is in more wide spread use, for example: > > https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html That interface seems Zepher specific and looks to me like a series of calls that appear reasonable as a list to cover. The patch Aaron has posted is a driver. I prefer a driver like we have for I2C, SPI etc because the of support it brings. The initial set of ioctl commands is small to start with. If you feel we should offer more I suggest they get added once this is merged. Is the change OK? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Flash Device API
Hello Aaron, this API seems to be RTEMS-specific. Maybe we should simply pick up an existing solution which is in more wide spread use, for example: https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Flash Device API
This generic flash device API creates a device wrapper for flash drivers. It allows for the flash device to opened as a file descriptor with region limiting. IOCTL calls are present to allow for device idenification. Designed with the goal of creating a generic flash driver that allows different BSPs to create flash devices in a unified manner. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
