Reorganisation of the STM32 directories

[raiden00pl]

At this moment the STM32 ports are a mess. We have 5 different directories to support STM32 architectures with a lot of duplicated code.
I want to go back to work on the STM32H7 port, but it discourages me that I'll have to duplicate more and more code from stm32/stm32f7 directories.
So maybe it's a good time to fix it?

Gregory once mentioned about ChibiOS and their way of ports organization (https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32)
It looks pretty nice for me. What do you think about reorganise STM32 directories in a similar way?

There is quite a lot of work to do and ST manuals doesn't help with this approach, so it can take some time to finish.
But after changes it'll be much easier to maintain code and add new functionality to STM32 family.

If you think this is a good idea, I can start working on it.
Or if you have a better solution than suggested please let me know.

[patacongo]

I certainly prefer the duplicated code and duplicate directories far more than the mess that is in the STM32 F1-F4 directories. I never want to go that directorion again.  So my initial response is negative although, I think it could be done right.  However, I don't think it can be maintained.  People who modify STM32 doe respect policies with regard to rules to maintain architecture integrity.

Also, H7 cannot share drivers with any other architecutre (except perhaps F7).  Cortex-M7 drivers are not compatible with Cortex-M3/4 drivers and cannot be shared even if the registers are identical.  See http://www.nuttx.org/doku.php?id=wiki:howtos:port-drivers_stm32f7

I would vote NO.  I can only foresee the situation getting worse if we go that way.  The only way it could work is if someone to ownership and responsibility for all STM32.  If that person is me then I insist on separate directories and duplicated code to make life simpler for me.

Don't touch anything unless you plan to maintain it forever.

Greg

[patacongo]

it would be great if there were a person or a committee that control the STM32 implementation.  That is how Linux works things.

That person/committee would prepare and review changes and maintain issues related to STM32.  I would have a more positive attitude if such a group were in place.

I really can't maintain another mystery subsystem.  It is beyond my ability.  Despite all of its architectural flaws, I can understand and maintain the STM32 code as it is now (at least to a limited degree that takes into the account that I don't know very much about STM32).

Greg

[Xiang Xiao]

If the port come from SoC maker and maintained by them, can the similar chip code put into the same folder? or even put into the related drivers folder?

I am asking this question, because we have more than ten variants need to maintain, the current organization make the duplication too much.

Here is our situation:

1.Three arch(arm/armv7-m, risc-v/rv32im and ceva/tl4) is used

2.More then ten subsystem build around these arch

3.Many IP(uart/i2c/spi/i2s/timer/gpio/dma) is reused in these design

With the current organization, the same code need duplicate to ten folders at least.

If the same arch could share the same folder, the code still need duplicate three times.

If the code could put into drivers folder(e.g. drivers/serial), we just need maintain one code base.

Actually, since many modules come from IP vendor, the driver code could even be reused by other SoC too.

Many other bootloader/OS(e.g. U-boot, Linux, Zephyr...) prefer to put the driver code into drivers folder to capture the modern SoC design trend.

Thanks

Xiang

[patacongo]

No vendor code can come into the repositories unless it has a BSD license and follows the NuttX coding style.  But otherwise there is no particular restriction.  The directories outside of arch/ and configs/ must be completely generable and re-usable by anyone and must also follow the C89 standard.

Many vendors use common IP but the drivers are not still compatible because there are differences in peripheral clock configuration, GPIO configurations, interrupts, DMA, etc.  I could see that you could implement such a thing for Xaiomi parts but it would not be portable to other Silicon so I would have to decline the change.

I recently declined a similar SPresence change that added drivers to the driviers/ directory because the change included Sony-specific hooks in the drivers so that they could not be be used by anyone else.  I actually felt bad about doing that because I understand the need.  But I don't think it is a proper use of the NuttX repositories to carry and vendor specific code outside of the arch/ and configs/ directories.

Perhaps there could be some creative solution like an arch/vendor directory with we could keep Xaiomi or Sony-specific code?  You could put common logic in arch/vendor/xaimoi and we could support the SPresence drivers under arch/vendor/sony. We could set up links as we do now for architecture, board, and chip.  Actually, the more I think about it, the more I like that idea.

But I would prefer not to use the common driver/ directory for things that are not completely general, however.

Greg

[xiang xiao]

Yes, to make the drivers generic enough to reuse by multiple SoC, we need extend the driver model to cover:

1.clock configuration

2.DMA configuration

3.cache operation

For GPIO, we could reuse ioexpender interface.

Once these basic drivers are ready, we can build the other drivers on top them and make them generic enough for all SoC.

Actually, we have finished design, implement and test these basic driver model in recent half year.

If the community is interesting, we can share them and refine the interface as needed.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Carvalho de Assis]

Hi Xiang,

I think it could be another great contribution from Pinecone/Xiaomi.

Is it complete on your code base?

BR,

Alan

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

[xiang xiao]

Yes, the code is completed. And we plan to upstream them before the next official NuttX release.

The patch set will include:

1.littlefs wrapper layer for NuttX VFS:

   https://github.com/ARMmbed/littlefs

2.The common clock framework(like the Linux counterpart but write from scratch to save the code/data size).

3.A common DMA ops definition, and Pinecone DMA implementation as demo.

4.Enhance 16550 to utilize the common clock and DMA framework.

5.The generic drivers(i2c, spi, wdt and timer) implementation for Synopsys IP.

6.The generic drivers(uart and timer) implementation for ARM IP.

7.A new arch implementation for CEVA DSP(tl4 and xm6):

  https://www.ceva-dsp.com/product/ceva-teaklite-4/

  https://www.ceva-dsp.com/product/ceva-xm6/

After all generic code upstream, we will start upstream Pinecone's special drivers and platform code.

Thanks

Xiang

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[patacongo]

1.littlefs wrapper layer for NuttX VFS:

   https://github.com/ARMmbed/littlefs

I hope this would go in apps/.  I won't accept this into the OS for use by appliations.  it is non-POSIX.

[xiang xiao]

LittleFS is just another flash friendly file system much like SmartFS, but the code size is much small and support power-less resilient.

We just add:

1.A new mountpt_operations for LittleFS.

2.Implement LittleFS block callback and forward to NuttX's block_operations

Since LittleFS is still in the active development, the porting just has one file(fs_littlefs.c), other code need download from the official repo.

From the user point view, they still call POSIX API mount/open/read/write/close, not lfs_xxx function.

So is it reasonable to put under fs/littlefs folder?

Thanks

Xiang

[Sebastien Lorquet]

Hello

littlefs is very cool and desirable in NuttX, but it should really be implemented directly in NuttX instead of bringing some mbed code.

I would also have a negative opinion on this raw inclusion.

I would be very happy to test a version of littlefs that is correctly integrated in NuttX without wrappers and external code.

Sebastien

[Xiang Xiao]

Sebastien,

First, even the link(https://github.com/ARMmbed/littlefs) contain ARMmbed word, but it actually don't depend on ARMmbed.

Here is the specific wrapper code for ARMmbed:

https://github.com/ARMmbed/mbed-os/tree/master/features/storage/filesystem/littlefs

Second, since LittleFS is still in the active development process, it will make the furture integration very hard if we duplicate and modify the code to follow NuttX coding style.

Actually, we don't upstream LittleFS NuttX porting code right now just because we are waiting for LittleFS v2.0 release.

[Gregory Nutt]

I will not accept any code the NuttX repositories that does not follow the NuttX coding style 100% under any and condition.  That is absolute and inflexible.

 

Nor do I accept forks for active projects into NuttX ever.

 

If you want to include this file system, the you must take a frozen snapshot and adapt to the NuttX coding style.  Otherwise I will decline the change and that is not at all negotiable.

 

The are NuttX values that I never compromise:

 

1. All code must conform to the portable POSIX interface for applications.
2. All code must follow good architecture rules for modularity and must respect the layer architecture.
3. All code must conform to the NuttX coding style.

 

I am flexible on most everything else, but those are inviolable.

 

Greg

 

Sent from Mail for Windows 10

[Xiang Xiao]

Greg,

If we follow the integration style like apps/graphics/littlevgl:

1.README.txt or script to instruct where to download the external package

2.All other integration code follow NuttX coding sytle

3.The integration layer strictly follow the VFS design and POSIX interface
Is this approach acceptable?

[Gregory Nutt]

No, I won’t have that in the NuttX directory.  I don’t want.  That kind of stuff in in apps/ but never in nuttx/.

 

Please, if you do no not wish to follow the NuttX standards, do not pursue this.  I will no cooperate in any way and will refuse any attempt to include this in the OS because I do not want it there unless it is 100% native and conforming to the NuttX standard.

 

None of the things you suggest will ever happen.  Never!

[Gregory Nutt]

There are certain things I am flexible on and there things that I am not flexible on.  I am not flexible on this and I can promise you that the code will never come into the repository if it does not conform.

 

I will no bend.  I will not compromise.  That is an absolute.

 

Greg

 

 

Sent from Mail for Windows 10

 

From: Gregory Nutt
Sent: Sunday, September 16, 2018 9:20 PM
To: nu...@googlegroups.com
Subject: RE: [nuttx] Reorganisation of the STM32 directories

 

No, I won’t have that in the NuttX directory.  I don’t want.  That kind of stuff in in apps/ but never in nuttx/.

 

Please, if you do no not wish to follow the NuttX standards, do not pursue this.  I will no cooperate in any way and will refuse any attempt to include this in the OS because I do not want it there unless it is 100% native and conforming to the NuttX standard.

 

None of the things you suggest will ever happen.  Never!

 

Greg

 

Sent from Mail for Windows 10

 

From: Xiang Xiao
Sent: Sunday, September 16, 2018 9:10 PM
To: NuttX
Subject: Re: [nuttx] Reorganisation of the STM32 directories

 

Greg,

If we follow the integration style like apps/graphics/littlevgl:

1.README.txt or script to instruct where to download the external package

2.All other integration code follow NuttX coding sytle

3.The integration layer strictly follow the VFS design and POSIX interface
Is this approach acceptable?

On Monday, September 17, 2018 at 10:52:08 AM UTC+8, patacongo wrote:

I will not accept any code the NuttX repositories that does not follow the NuttX coding style 100% under any and condition.  That is absolute and inflexible.

 

Nor do I accept forks for active projects into NuttX ever.

 

If you want to include this file system, the you must take a frozen snapshot and adapt to the NuttX coding style.  Otherwise I will decline the change and that is not at all negotiable.

 

The are NuttX values that I never compromise:

 

1.       All code must conform to the portable POSIX interface for applications.

2.       All code must follow good architecture rules for modularity and must respect the layer architecture.

3.       All code must conform to the NuttX coding style.

[Xiang Xiao]

Ok, we will keep the change in our private git. If anyone is interesting, we could share the patch to him directly.

[spudaneco]

That sounds better. Thank you!

If the code becomes stable in the future and you decide to freeze it and make it follow the Nuttx coding style, then it will be quite welcome.

Greg

Sent from Samsung tablet.

[patacongo]

Ok, we will keep the change in our private git. If anyone is interesting, we could share the patch to him directly.

It doesn't look like there is very much activity on littlefs.  I see a bug fix two weeks ago.  But there was nothing prior to that since August 27.  I think it is safe to make a proper port.

If you want to give me you wrapped version of littlefs, I may be able to make time to do a proper port to NuttX.

I see some things in littlefs that are not acceptable in NuttX.  For example, lsf_format().  That would have to be moved to apps/fsutils.

Greg

[patacongo]

It doesn't look like there is very much activity on littlefs.  I see a big fix two weeks ago.  But there was nothing prior to that since August 27.  I think it is safe to make a proper port.

No... there is a misleading typo.  It was not a "big fix".  A "BUG fix" and it was not big at all.

[Xiang Xiao]

littlefs master branch just contain the stable code, the development branch is on v2-alpha/v2-alpha-b-trees which have more than 100 commit ahead of master:(.

[spudaneco]

Where would i find the repository?

Sent from Samsung tablet.

-------- Original message --------

From: Xiang Xiao <xiaoxia...@gmail.com>

Date: 9/18/18 8:35 PM (GMT-06:00)

To: NuttX <nu...@googlegroups.com>

Subject: Re: [nuttx] Reorganisation of the STM32 directories

[Xiang Xiao]

here:

https://github.com/ARMmbed/littlefs/tree/v2-alpha

https://github.com/ARMmbed/littlefs/tree/v2-alpha-b-trees

Actually, you can select the branch from the top lelt button which has a label Branch: xxx

[spudaneco]

Thanks.  I thiught you were referring to a Xaiomi reoository with your wrapper.  I will need to look at the changes on the branches you mention.  Perhaps it is premature to bring in the changes.

Gref

[Xiang Xiao]

LittleFS's design is very well, NuttX VFS wrapper don't need modify any offical LittleFS code base.

[Sebastien Lorquet]

Hello

There is little chance that official littlefs source follows the nuttx coding standard. We need a port of the stable version that is correctly formatted and integrated in nuttx without a wrapper.

Sebastien

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

[Gregory Nutt]

> here:
> https://github.com/ARMmbed/littlefs/tree/v2-alpha
> https://github.com/ARMmbed/littlefs/tree/v2-alpha-b-trees
> Actually, you can select the branch from the top lelt button which has
> a label Branch: xxx

I started looking at the code on the branches this morning.

The license for the new code on the branches has been changed to
Apache.  I do not accept Apache licensed code into NuttX.  Any code
coming into NuttX must be either BSD or MIT.

So we can all forget about LittleFS.  That is not going to happen by you
or me or by anyone else.  If it is not-BSD compatible, it won't go in
the repositories.

Greg

[Sebastien Lorquet]

I have always said that we need a nuttx tailored implementation made from the
quite complete and accurate specification, that is directly implemented on top
of NuttX MTD framework, like smartfs.

This would ensure licence compliance, and, more importantly, understanding of
how the non trivial internals are working.

I hope someone can take the time to write and contribute that.

Sebastien

[Gregory Nutt]

> I have always said that we need a nuttx tailored implementation made from the
> quite complete and accurate specification, that is directly implemented on top
> of NuttX MTD framework, like smartfs.
>
> This would ensure licence compliance, and, more importantly, understanding of
> how the non trivial internals are working.
>
> I hope someone can take the time to write and contribute that.

I agree with you.  Deriving from a specification is the based way to go.

It is easy to write a file system if you have a good specification of
the file system.  For example, I wrote the ROMFS file system in just a
few days based on this
https://www.kernel.org/doc/Documentation/filesystems/romfs.txt -- just a
short .txt document describing the data structures.

The standard ROMFS is GPL, mine is original and BSD.  It is unrelated to
the GPL code and in no way derives from it other that through that .txt
file.  But the nice thing is that the the clone ROMFS is fully
compatible with the standard GPL ROMFS tool 'genromfs.'

Most of the file systems used in Linux have specifications here:
https://www.kernel.org/doc/Documentation/filesystems/, although not all
are sufficiently detailed to support re-implementation.

All of the BSD file systems are free game too:
http://fxr.watson.org/fxr/source/fs/ but there are no embedded FLASH
file systems there.

This is a mature FLASH file system with MIT license:
https://github.com/pellepl/spiffs


Greg