from:"oss"

Re: [PATCH] gdb: prefere python3 if it is installed

2021-08-20 Thread oss


On 20/08/2021 18:24, Gedare Bloom wrote:

On Fri, Aug 20, 2021 at 2:02 AM Chris Johns  wrote:


On 20/8/21 5:42 pm, Christian MAUDERER wrote:

Am 20.08.21 um 09:02 schrieb Chris Johns:

On 20/8/21 4:48 pm, Christian MAUDERER wrote:

Hello,

Am 20.08.21 um 03:49 schrieb Chris Johns:

On 20/8/21 3:16 am, Joel Sherrill wrote:

On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom  wrote:


I have no problem with this. I think it is sensible to look for
python3 before python2. At some point we'll have to stop looking for
python2 :)


That is further in the future than I would have thought based on the
CentOS project changes. I still see user organizations with no plans
to move off CentOS 7. It will receive maintenance updates through
2024-06-30.

But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't
that bad. I had to test something on a true 32-bit distribution this week
and even CentOS 7 (i386) wasn't as painful as I expected to setup.


There will come a time when a change made cannot be easily tested by us on
python2 and that will in effect end our support. We are not there yet.


STOP.


Please do not do this again.

That discussion took a wrong direction. We discussed deprecating python2 a

few times and I know that we will not do it before the big long living
distributions drop it. I can live with that and I don't want to re-start this
discussion with this patch.


If Joel feels the need to make this statement he can and he has more than earned
the right to do so. His work and those he supports is important.


Sorry, I didn't want to offend you, Joel or Gedare.

I had that with discussions before that the original idea (here: giving priority
to python3 over python2 when building gdb) started to be buried by a similar but
slightly different one which has been already discussed multiple times (here:
deprecating python2). I wanted to avoid that.

I should have worded that different. I'm sorry if I have offended you, Joel or
Gedare or anyone else.


Thanks and none taken. I am clear on the focus of your posts so it is ok. :)


It would be fine without the STOP. Totally acceptable to express your
opinion and request that we not bikeshed your patch, we just want to
keep the tone of the list in the right direction which we all know can
be challenging in virtual, international communications. We understand
the intent here, but we just want to make sure to keep the list
friendly to all (who may lack some of our context). Thanks!


Yes, again: sorry. "Let's deprecate python2" is a dangerous topic that 
has the tendency to start really long discussions. I pannicked a bit 
there that it would hide the topic that I had in mind. I used the wrong 
tone to express that. I'll try to be more careful in the future.













On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
 wrote:


PS: I had the problem on the 5 branch of RTEMS source builder. I think
we should apply a patch to both: master and the 5 branch.

Am 19.08.21 um 10:34 schrieb Christian Mauderer:

More and more systems stop shipping python2. So we should start to
prefer python3 over python2. For building gdb it is not only necessary
to have a python binary installed, but also the matching python-devel
packet. On a lot of hosts that will now be more often python3-devel
and not python2-devel.
---

Note: Please see that patch more as an suggestion / base for
discussion. I'm open to better solutions.

My problem that triggered this patch was a build of a toolchain on a
github CI/CD system that has been originally set up by one of our
users (see [1] for the log). It seems that on the "macos-latest"
machines a python2 is installed but no python2 headers are found.


I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur):

config: tools/rtems-gdb-10.cfg
package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB
(installed:
19.586MB)
cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
reporting: tools/rtems-gdb-10.cfg ->
arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt
reporting: tools/rtems-gdb-10.cfg ->
arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml

I support the latest MacOS with Xcode and have a dedicated Mac machine that
tracks the current RSB. It had wedged itself and I have cleared that so it is
now building the latest.


So do I understand that correct: This is a "clean" Mac with no additional python
installs or similar and it worked? What python versions are available on this
this machine?


It is working for me and I have not looked into it any more.


If I did understand you correctly, it seems that github has made some odd
choices about their default config for the macos-latest machines. They seem to
have python2 but no devel headers.


You will need to raise that with them.


Yes, of course. I didn't want to raise it as a problem here. It was more a
statement than

Re: Outdated list of BSPs in rtems-tools/config

2023-09-17 Thread oss

Hello Peter, Thomas, Karel,

Am 14.09.23 um 22:15 schrieb Karel Gardas:

Hello Thomas,

On 9/14/23 21:35, Thomas DOERFLER wrote:

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the
PowerPC architecture and favor ARM for automotive applications.

But the MPC5xxx controllers were developed in some sort of cooperation
with ST microelectronics. And ST is still actively playing with this
family. E.g. the SPC564 is still equipped with the eTPU. So the legend
lives on ;-)

indeed, but even ST Micro probably plans to migrate their customers
slowly to their brand new ARM-based chips for automotive: Stellar 32-bit
Automotive MCUs [1]. Although I must add that "Longetivity" is extended
to 20 years for your mentioned SPC56x, whatever that means exactly...

Anyway, I'm afraid, sun is setting on PPC even in automotive business...

I don't really know a lot about the eTPU. But after reading a bit about
it, I stumbled across a presentation from ST and a company called Hycon
(Hybrid Controls) that describes a eTPU to GTM migration (see [1]). The
presentation seems to be part of a Bosch event focused on that GTM (see
[2]). There has been a second event a few years later (see [3]). That
GTM seems to be an IP core that is licensed by multiple chip vendors.

I found it in a number of the PowerPC based chips from ST. But beneath
that, I also found it in some ARM chips from ST that have a "proposal"
status (for example [4]). One of the presentations from Bosch from 2022
mentions that it is implemented by Infineon, ST, Renesas and NXP.

Like I said: I don't really know the eTPU. But if there is a migration
guide, there is a good chance, that it at least works for some cases to
replace the eTPU.

Best regards

Christian

[1]
http://www.bosch-semiconductors.com/media/events/techday_presentations/12_stmicroelectronics.pdf
[2]
https://www.bosch-semiconductors.com/ip-modules/gtm-platform/gtm-techday-2017/
[3]
https://www.bosch-semiconductors.com/ip-modules/gtm-platform/gtm-techday-2022/

[4] https://www.st.com/en/automotive-microcontrollers/sr6g7c6.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread oss

Hello Peter,

Am 13.09.23 um 19:22 schrieb Peter Dufault:

On Jul 25, 2023, at 10:14 , Joel Sherrill wrote:

Most of those are recent and from a lot of different people. GSoC, Kinsey,
you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I
think it has been around a LONG time.

I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in
July.

I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx
embedded board BSPs developed by "eb".

It *is* time to retire the Phytec board as that board is no longer available.

But, I hope we can keep it around for a while as I now need to work on a
follow-up to that BSP.

That thread was not about retiring or deprecating BSPs. It was about
some missing BSPs in the rtems-tools/config files. So if it is still
necessary, I don't think the BSP should be removed.

One of my clients uses the Phycore-MPC5554. They missed the end-of life
announcement for that board. They need to quickly update to something very
compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has
all the functionality they require without software changes.

I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop
equivalent MPC5674F support.

OK for me.

A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of
their products. "eb", are you planning another "gwlcfm", or are you done with that, and what
platform would you move to? I'd like to learn about an architecture that works as well as the old Motorola
architecture does without custom FPGA programming.

I think it's possible that a new batch of the gwlcfm hardware will be
manufactured in the next few years. But it's quite unlikely that the
software will get an upgrade.

The question about a good architecture is quite difficult because it's
always quite application specific.

For RTEMS work that I do, usually a customer already selected a chip
(most of the time some ARM). Therefore, I can't pick a platform that
often. For eb-projects, we usually use NXP or ST chips. On the NXP it
would be i.MX or now also i.MXRT and for ST it's one of the many STM32
chips.

Personally I would like to play a bit with Risc-V chips. But I haven't
found any time yet. Additionally, it seems that there are still not that
many manufacturers that produce Risc-V chips.

If I leave the old Motorola PowerPC's architecture targeted at engine control,
I will miss how the ADC DMA chain works together with the eTPU and also
schedules the output so cleanly do background motor control, and other timing
intensive applications, so that the main CPU is free to e.g. run RTEMS (and in
my case position servo control).

Difficult. Best bet is some NXP chip because they have quite some
peripherals that are still based on the Motorola chips. But I think you
know these chips already and it seems that they are not a good enough
replacement. Otherwise, you wouldn't ask.

At the moment a lot of chips start to provide two different ARM cores.
One bigger (often Cortex-A; sometimes multicore) and one smaller one
(most of the time Cortex-M). I haven't used both CPUs of these dual CPU
systems yet. But in theory they should allow some quite nice division of
tasks: The small CPU can handle the timing intensive application (maybe
with some bare metal code). The second CPU can handle higher level
control and communication. It would be interesting to implement
something like that.

Best regards

Christian

Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-24 Thread oss


Hello Duc,

Am 24.06.22 um 16:28 schrieb Duc Doan:

Hello Christian,

On Thu, 2022-06-23 at 18:30 +0200, o...@c-mauderer.de wrote:

Another tricky part can be how to handle pins or pin groups. At the
moment I just used an "unsigned" for a single pin. That wouldn't be
able
to handle a pin group. Maybe a pin group needs it's own type or some
kind of extensible type. For the usual controller with <= 32 bit a
mask
in a uint32_t would be great. For other controllers maybe a longer
mask
is necessary. That's a bit tricky.


Thank you for the pseudocode, I think your method is better than mine.
I am currently rewriting the code. However, I am not clear about pin
groups: Is a "pin group" same as a "port"? Or does a group mean pins
from that group can come from different ports/GPIO controllers?


It's not unlikely that you want to change multiple pins on one 
controller at the same time. That's what I meant with "pin groups". On a 
controller level it would be (for most controllers):


- Read current value from output register into a temporary variable.
- Change the pins in the group to the new value in that temporary variable.
- Write back the new value to the output register.



Also, I am thinking that maybe I can create an opaque type for pin mask
that BSPs will implement, instead of a specific type like
uint32_t. That type could be used as a long mask or just a pin number,
depending on the BSP.


Be careful with everything that depends on the BSP. Again: Please think 
about an i2c GPIO expander. That chip can be used on different BSPs. It 
can be even an independent driver that can be used by a user on demand 
on any BSP that supports i2c.


Best regards

Christian



Best,

Duc Doan


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-23 Thread oss


Hello Duc,

Am 23.06.22 um 13:36 schrieb Duc Doan:

On Tue, 2022-06-21 at 17:23 +0200, o...@c-mauderer.de wrote:

OK. So every BSP that want's to use that API will have a different
rtems_gpio_config_t (or every other structure) that is defined in
(for
example) bsp.h? The application has to know the details of the
current
BSP and initialize the structure accordingly.

That means that if I write an application that can run on an STM32 or
alternatively on some RISC-V based CPU the API will be different. Not
really portable.



Yes, you are right: rtems_gpio_config_t was defined by each BSP. I have
fixed by making rtems_gpio_t and rtems_gpio_config_t concrete structs
that hold common information among architectures. They also have a
pointer to a bsp-specific structure if required, like in the current
API.
/**
   * @brief Structure for a GPIO object. It holds information
   *like port number and pin number/pin mask.
   *
   */
 typedef struct {
 void *port; /* Pointer to the GPIO port */
 uint32_t pin_mask;  /* The pin number or pin mask */
 bool is_expander;   /* If the GPIO is an expander, set to
true.
Else false. */
 uint32_t expander_id;   /* This field specifies which GPIO
expander is
in use. In case of using multiple
expanders,
this field is necessary to handle
each. */
 void *bsp;  /* Pointer to BSP-specific data */
 } rtems_gpio_t;

/**

   * @brief Structure for configuration of a GPIO object.
   */
 typedef struct {
 rtems_gpio_pin_mode mode;   /* Pin mode */
 rtems_gpio_pull pull;   /* Pull resistor configuration */
 void *bsp;  /* Pointer to BSP-specific config */
 } rtems_gpio_config_t;

Hopefully this makes the application code more portable. I have also
updated the blink code:
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c
This time, for simple tasks like basic I/O, users won't need to care
about the details of a BSP.

One thing I am not sure about is that do all architectures have ports
and pins for GPIO? I am worried that my structure is still skewed
towards STM32 because I don't have much knowledge about different types
of microcontrollers.


Most controllers I've worked with use that organization but I'm not sure 
whether it's true for all controllers. Isn't the controller on the 
raspberry an example where there is only one big group of GPIO0 to 
GPIO<$BigNumber>?


But I think you can always organize pins in that way. Only make sure 
that you don't assume that every controller has a maximum of 32 pins. If 
there is only one GPIO controller on a system that has 400 pins, that 
shouldn't be a problem. The same is true if you have 400 controllers 
with one pin each. The logical structure works in both cases.


Note that not all controllers have to be the same type. See my notes 
below regarding the I2C GPIO chip.





If you ask me: We have SYSINIT functions for this kind of
initializations. If something should be done at about bsp_start, the
user can register a function at RTEMS_SYSINIT_BSP_START.


Thank you for the suggestion. This is what I have and it seems to be
working:

RTEMS_SYSINIT_ITEM(
rtems_gpio_initialize,
RTEMS_SYSINIT_BSP_START,
RTEMS_SYSINIT_ORDER_LAST
);




I think I haven't written clearly what I meant: Let's assume a I2C
chip
like the TCA9537 from TI (can be any other GPIO expander from any
other
vendor): You connect it to a I2C bus and control 4 GPIOs with it.
It's a
GPIO so a good GPIO API should be able to handle it.

In that case the GPIO API would do some I2C transfers under the hood
if
you switch or read a GPIO. So what happens if some error happens
during
one of these transfers. If the only error option is UNSATISFIED, the
application can't distinguish the errors. It only knows something
didn't
work. It can't (for example) retry only on certain error cases like
if
the bus is busy.

Please also note that the I2C GPIO expander is one example where a
BSP
would have two completely different GPIO controllers: A number of
integrated ones and a number of I2C ones. A generic API should be
able
to handle that case too.


I understand what you mean now. I have added that capability to by
creating the field is_expander to select between integrated GPIO and
expander. I also have a field called expander_id to select among
multiple expanders. You can see those in the rtems_gpio_t struct above.
The API function prototypes stay the same, but the BSP now need to
implement 2 functions in private: one is the "*_default" function which
controls the built-in GPIO and the other is the "*_ex" function which
controls the expander. Here are the example read and write functions,
which

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-26 Thread oss


Hello Duc,

Am 25.06.22 um 13:43 schrieb Duc Doan:

Hello Christian,

On Fri, 2022-06-24 at 17:32 +0200, o...@c-mauderer.de wrote:

Be careful with everything that depends on the BSP. Again: Please
think
about an i2c GPIO expander. That chip can be used on different BSPs.
It
can be even an independent driver that can be used by a user on
demand
on any BSP that supports i2c.


I ended up using a void* so that users can pass anything into it and
the driver/BSP will cast and parse it. Is that a good solution?

Also, here is my updated API:

File: gpio2.h  /* API header **/

typedef struct rtems_gpio_handlers rtems_gpio_handlers_t;
typedef struct rtems_gpio_ctrl rtems_gpio_ctrl_t;
typedef struct rtems_gpio_config rtems_gpio_config_t;
typedef struct rtems_gpio_interrupt_config
rtems_gpio_interrupt_config_t;

struct rtems_gpio_handlers {
 rtems_status_code (*initialize)(rtems_gpio_ctrl_t *);

 rtems_status_code (*deinitialize)(rtems_gpio_ctrl_t *);

 rtems_status_code (*configure)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_config_t *);

 rtems_status_code (*configure_interrupt)(rtems_gpio_ctrl_t *, void
*, rtems_gpio_interrupt_config_t *);

 rtems_status_code (*enable_interrupt)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_interrupt_config_t *);

 rtems_status_code (*disable_interrupt)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_interrupt_config_t *);

 rtems_status_code (*set_pin_mode)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_pin_mode);

 rtems_status_code (*set_pull)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_pull);

 rtems_status_code (*read)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_pin_state *);

 rtems_status_code (*write)(rtems_gpio_ctrl_t *, void *,
rtems_gpio_pin_state);

 rtems_status_code (*toggle)(rtems_gpio_ctrl_t *, void *);

};

struct rtems_gpio_ctrl {
 const rtems_gpio_handlers_t *handlers;
};

struct rtems_gpio_config {
 rtems_gpio_pin_mode mode;   /* Pin mode */
 rtems_gpio_pull pull;   /* Pull resistor configuration */
};

struct rtems_gpio_interrupt_config {
 rtems_gpio_interrupt interrupt_mode;/* Interrupt trigger
mode */
 uint32_t interrupt_number;  /* Interrupt number */
 uint32_t priority;  /* Interrupt priority
*/
 void *bsp;  /* Pointer to BSP-
specific config */
 void (*handler) (void *arg);/* Pointer to the IRQ
handler */
 void *arg;  /* Pointer to the
arguments of IRQ handler */
};

extern void rtems_gpio_register(
 rtems_gpio_ctrl_t *base,
 const rtems_gpio_handlers_t *handlers
);

extern rtems_status_code rtems_gpio_initialize(
 rtems_gpio_ctrl_t *base
);

extern rtems_status_code rtems_gpio_deinitialize(
 rtems_gpio_ctrl_t *base
);

extern rtems_status_code rtems_gpio_configure(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_config_t *config
);

extern rtems_status_code rtems_gpio_set_pin_mode(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_pin_mode mode
);

extern rtems_status_code rtems_gpio_set_pull(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_pull pull
);


Is setting the pull really independent of the mode? Most controller that 
I know have a pull-Up only on Inputs. Sometimes on an Open-Drain output. 
Sometimes in another controller (but you might ignore that option). 
Somethimes you can also set a different strength like 10k pull-up or 
100k pull-up.


Best regards

Christian



extern rtems_status_code rtems_gpio_configure_interrupt(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_interrupt_config_t *int_conf
);

extern rtems_status_code rtems_gpio_enable_interrupt(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_interrupt_config_t *int_conf
);

extern rtems_status_code rtems_gpio_disable_interrupt(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_interrupt_config_t *int_conf
);

extern rtems_status_code rtems_gpio_write(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_pin_state value
);

extern rtems_status_code rtems_gpio_read(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_pin_state *value
);

extern rtems_status_code rtems_gpio_ctrl_toggle(
 rtems_gpio_ctrl_t *base,
 void *pin
);
//

File: gpio.c (API source)

#include 

void rtems_gpio_register(
 rtems_gpio_ctrl_t *base,
 const rtems_gpio_handlers_t *handlers
)
{
 base->handlers = handlers;
}

rtems_status_code rtems_gpio_initialize(
 rtems_gpio_ctrl_t *base
)
{
 return base->handlers->initialize(base);
}

rtems_status_code rtems_gpio_deinitialize(
 rtems_gpio_ctrl_t *base
)
{
 return base->handlers->deinitialize(base);
}

rtems_status_code rtems_gpio_configure(
 rtems_gpio_ctrl_t *base,
 void *pin,
 rtems_gpio_config_t *config
)
{
 return base->handlers->configure(base, pin,

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-26 Thread oss


Hello Karel and Duc,

Am 26.06.22 um 09:24 schrieb Duc Doan:

Hello Karel,

I came up with this solution: making a macro that returns a function
depending on driver/BSP name.

/**
   * @brief Get an GPIO control object.
   *
   * This macro requires BSPs/drivers to correctly implement
   * function _gpio_get_ctrl(void *arg,
   * rtems_gpio_ctrl_t **out).
   *
   * @param _driver is the name of the BSP/GPIO driver
   * @param[in] _arg is the void pointer to an argument type
   *defined by BSP/driver
   * @param[out] _out is the pointer to the pointer to where
   * the output object will be stored
   */
#define rtems_gpio_get_ctrl(_driver, _arg, _out) \
 _driver##_gpio_get_ctrl( _arg , _out )

In the application code:

rtems_gpio_get_ctrl(stm32f4, GPIOD, _ctrl);
rtems_gpio_get_ctrl(stm32f4, GPIOA, _ctrl);


It's only a different method of writing the same. It won't solve Karels 
problem because it still wouldn't compile on another BSP.




What do you think about this?

Best,

Duc Doan

On Sat, 2022-06-25 at 21:46 +0200, Karel Gardas wrote:


Hello Duc,

one reminder, your API should be more or less portable. That means
the
example which you produce as a testing example should be API-wise
portable between various BSPs. Is that clear?

I know, I know, sometimes user led 1 on F4 is on different port/pin
on
F7 and then on H7 you get it on even different port/pin, but!

  > stm32f4_gpio_get_ctrl(GPIOD, );

do you expect this to be called from app running on RPi4 for example?
Or
on beagle bone white? Or on stm32h757i-eval board?

Please generalize and make that bit portable too.


I think that approach is due to my suggestion to have a low overhead and 
use the pointers more or less directly. A really portable method would 
be to use for example device files. But for GPIO that would add a lot of 
overhead which isn't good for a fast interface like that.


Another problem that I added for Duc is that I told that I might want to 
register I2C GPIO expanders during the application startup.


A possibility could be to have some general bsp_gpio_get_ctrl(...) 
function that returns the controllers for the integrated GPIOs of a chip 
regardless of the chip. If you have an extra I2C expander, that will be 
a separate function.


Best regards

Christian



Thanks,
Karel

On 6/25/22 15:00, Duc Doan wrote:

Hello Christian,

I forgot to send the sample code. Here it a code to turn on an LED:

/*/

// Obtain the pointer to the instance (port D)
rtems_gpio_ctrl_t *ctrl;
stm32f4_gpio_get_ctrl(GPIOD, );

// enable clocks for port D
rtems_gpio_initialize(ctrl);

// configure the pin
rtems_gpio_set_pin_mode(ctrl, _PIN,
RTEMS_GPIO_PINMODE_OUTPUT_PP);
rtems_gpio_set_pull(ctrl, _PIN, RTEMS_GPIO_PULLUP);

// output to LED
rtems_gpio_write(ctrl, _PIN, RTEMS_GPIO_PIN_SET);

/*/

Best,

Duc Doan
___
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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-29 Thread oss


Hello Duc,

Am 29.06.22 um 13:46 schrieb Duc Doan:

Hello Christian,

I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.

On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:

Regarding pin groups: I think it's worth to think a bit about how the
structure could be extended. You don't have to implement it right now
but you should have a plan what could be possible.

  From my point of view, there are two directions how that could be
implemented: Masks or lists.

If you have a mask (like 0x00108 for pin 3 and pin 8) it has the
advantage that it works fast for most controllers. Difficult is that
it
adds a limit to the maximum pin number depending on the size of the
mask. With that it works only for a few hardware models.

The other option is to add a list of pins instead of a mask. That
makes
it inefficient because most controllers will have to collect pins
into
masks and work with that.

Hm. Difficult. Maybe someone else has a good idea for that in the
next
few days.


I am thinking of later adding separate functions that handle pin
groups. I think it's quite hard to integrate into current functions
because of using virtual pin.

I have an assumption that needs confirmation: all microcontrollers (or
most of them) have register size equal to word size, and pin masks
should be at word size. Is that assumption correct? If so, maybe we can
just use unsigned int (or uintptr_t) for pin masks?


Not sure whether some 64bit controllers don't use 32bit registers. So 
it's not generally true that registers have the word size. It should 
work for most controllers (at least the ones I worked with) but I 
wouldn't guarantee it.


Beneath that: You most likely know my argument already: What about I2C 
or SPI chips. They can use register sizes that are not the same as the 
controllers register size (even if they are most likely only 8 bit most 
of the time at least for I2C).


Best regards

Christian



Best,

Duc Doan



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-21 Thread oss


Am 21.06.22 um 16:31 schrieb Duc Doan:

Using examples of working APIs is a good idea. But be careful not to
copy any code from that framework because the license (GPL) wouldn't be
compatible.


Sure, I don't copy their code but only see what functions should be in a 
GPIO API (like read, write, toggle, pinmode).


Is set and reset the only state a pin can have? Or is that field
thought
to be extended with (for example) open drain or similar states if a
device supports that?


I think it can be extended but I have only put in the most basic states 
for now.



Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better
because than you can use it as a boolean without conversion.


You are right, that was my mistake. I have fixed it.

Does that mean it is (for example) a GPIO controller? In that case
maybe
call it "rtems_gpio_ctrl_t". My first guess from the name would have
been that it is already a pin.

I have made changes in my newest patch, and rtems_gpio_t is now 
essentially a pin.


Same is true for the structures below: How would I initialize one of
these objects in the application?


The example initialization of those structures can be found in my sample 
blink code: 
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c 
 


OK. So every BSP that want's to use that API will have a different 
rtems_gpio_config_t (or every other structure) that is defined in (for 
example) bsp.h? The application has to know the details of the current 
BSP and initialize the structure accordingly.


That means that if I write an application that can run on an STM32 or 
alternatively on some RISC-V based CPU the API will be different. Not 
really portable.


I know that it is difficult in this case. On the one hand an API should 
be portable. On the other hand it should be able to handle very 
different hardware. And all that with the lowest possible overhead. In 
the end it will be some compromise.


Your goal is to either offer a better compromise than the API that is 
currently used for beagle and RPi. Or as an alternative: Don't try to go 
for an universal one and focus on your current device like a lot of the 
BSPs do. I would prefer a good universal API (better than the Beagle / 
RPi one (*)) but I know the problems so I could live with a device 
specific too. But note that this is my personal opinion. Others might 
have a different one.


(*) In case someone didn't see that (I think it was on discord): The 
Beagle / RPi API has two weaknesses in my point of view:


1. It mixes GPIO with Pinmuxing which is not true for all chips. For 
example the whole Freescale / NXP devices tend to have separate 
controllers for that. Having two APIs for that would be better in my 
point of view.


2. It is written with a quite fixed structure in mind. Controllers that 
don't have that structure need bigger workarounds which makes the API slow.


. The definition of the structures are defined by BSP. Here are 
STM32F4's definitions:

/* CODE BEGINS ***/
struct rtems_gpio_t {
     GPIO_TypeDef *port;
     uint16_t pin;
};

/**
   * This structure should be initialized to 0
   *
   * This structure holds configuration options for STM32F4-specific
   * GPIO. The 2 specific modes are Event and Alternate modes. Select
   * a mode by setting the correct field (is_event_mode or 
is_alternate_mode)

   * to 1.
   */
struct rtems_gpio_config_t {
     uint32_t speed;             /* Speed of the pin. Must be specified */

     uint32_t interrupt_mode;    /* The type of interrupt trigger of the 
pin

                                    Use if the pin is in Interrupt mode */

     uint32_t is_event_mode;     /* Sets to 1 if the pin is in event mode,
                                    0 other wise.
                                    Use if the pin is in Event mode */
     uint32_t event_mode;        /* The type of event trigger of the pin
                                    Use if the pin is in Event mode */

     uint32_t is_alternate_mode; /* Sets to 1 if the pin is in Alternate 
mode,

                                    0 other wise.
                                    Use if the pin is in Alternate mode */
     uint32_t alternate_mode;    /* Open drain or Push-pull mode
                                    Use if the pin is in Alternate mode */
     uint32_t alternate_fn;      /* The alternate function of the pin
                                    Use if the pin is in Alternate mode */
};
/* CODE ENDS ***/

What would be done in that function?

Why does the application has to implement it?

Where would it be called?


The initialize function is meant to perform setup code for the GPIO. For 
example, for the

Re: Request for feedback for CAN message structure

2022-06-21 Thread oss


Hello Pavel and Prashanth,

Am 20.06.22 um 22:57 schrieb Pavel Pisa:

Hello Prashanth S and others,

excuse me for lower activity last weeks. We have exams period
and I have lot of other duties and was even ill. I am at Embedded
World in Nuremberg now, so may it be there is some chance to meet
somebody other from RTEMS community.

As for the e-mail it is better to add one of my personal e-mails
(p...@cmp.felk.cvut.cz or pp...@pikron.com)
to notice me for something important, I do not check every
message comming through my list subscription. I go through
RTEMS, NuttX, CAN, etc. forums only when I have spare time.

On Monday 20 of June 2022 18:37:38 Prashanth S wrote:

This is a request for suggestions and feedback for the CAN message
structure.

*CAN message structure that represents the can messages from application to
driver:*

struct can_message {
uint32_t timestamp;
uint32_t id; // 32 bits to support extended id (29 bits)
uint16_t flags;// RTR | BRS | EXT ...
uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
uint8_t res; // reserved for alignment.
uint8_t data[64]; // For supporting data transfer up to 64 bytes.
};

This is the CAN messages structure created based on the suggestions in the
mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).


Yes I like solution with explicit and aligned fields.
I confirm that I think that length representing real data length is better
and it has been chosen for CAN FD by SocketCAN.

I confirm that flags implemented with explicit sized field seem to be more
safe to me. Bitfields are tricky due to endianing and have problem with
initialization and copying when new field is added.

I am not sure if the field name "dlc" (data length code) is right
when the field represents real length, may be "len" is a better
match.

I think that fields order makes sense as well (alignment, purpose etc..).
Only think to consider is possibility to swap

   uint32_t timestamp;
   uint32_t id;

because id is the first and the most important and accessed field,
so when the pointer to structure is give it can be small win
on some targets that it can be accessed without offset addition.
But that is probably neglectable and there can be arguments against.

Another think to consider is a size of "dlc" and or "len" code.
There is ongoing standardization process for CAN XL and it
would allow CAN frames up to 2kB and the length will be with
byte granularity. But CAN XL adds datatype filed and much more
options so it is probably out of the actual RTEMS scope
and would require variable length read and write systemcalls
because 2kB overhead for some 1 or 2 byte message is too high.

So even 8 bit length field is OK for now and may be res field
can solve CAN XL compatibility one day.


Not sure where the field will be used but wouldn't it be better if 
length is 16 bit already if there is an upcoming standard that will 
support lengths that need it. Otherwise some drivers might use the "res" 
for something else or make some assumptions about the length of the 
field that make it harder to change it later.


Best regards

Christian



So generally I agree with the message structure, I declare
minor weight vote to switch from "dlc" to "len".
I think that switch to common message structure based API
on RTEMS would be big win and that (at least for
now) keeping character device like API with IOCTLs
is simpler and matches better actual RTEMS CAN implementations.

Best wishes,

Pavel
___
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: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-19 Thread oss


Hello Duc,

Am 14.06.22 um 16:46 schrieb Duc Doan:

Dear all,

I am proposing a new GPIO API for RTEMS. The current API is kind of tailored to 
some specific hardware and therefore may require some overhead to make it fit 
for others. The one I am proposing is not finished but it is aimed to be simple 
and generic. It has some opaque type structures that need to be implemented by 
BSP. The functions include initialization, configuration, reading, writing, and 
toggle. I took inspiration from the Wiring framework. I also have an example 
implementation for the STM32F4 BSP.


Using examples of working APIs is a good idea. But be careful not to 
copy any code from that framework because the license (GPL) wouldn't be 
compatible.




I would love to get feedback from all of you.

Thank you,

Duc Doan

---
  bsps/arm/stm32f4/gpio/gpio.c |  39 +++
  bsps/include/bsp/gpio2.h | 129 +++
  2 files changed, 168 insertions(+)
  create mode 100644 bsps/arm/stm32f4/gpio/gpio.c
  create mode 100644 bsps/include/bsp/gpio2.h

diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
new file mode 100644
index 00..40aea3febd
--- /dev/null
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -0,0 +1,39 @@
+#include 
+#include 
+#include 
+#include 
+
+struct rtems_gpio_t {
+GPIO_TypeDef *port;
+};
+
+struct rtems_gpio_pin_t {
+uint16_t pin_mask;
+};
+
+struct rtems_gpio_config_t {
+GPIO_InitTypeDef *config;
+}
+
+__weak rtems_status_code rtems_gpio_initialize(void) {
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_status_code rtems_gpio_configure(rtems_gpio_t *gpiox, 
rtems_gpio_config_t *config) {
+HAL_GPIO_Init(gpiox->port, config->config);
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_status_code rtems_gpio_write_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t 
*pin, rtems_gpio_pin_state value) {
+HAL_GPIO_WritePin(gpiox->port, pin->pin_mask, value);
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_gpio_pin_state rtems_gpio_read_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t 
*pin) {
+return HAL_GPIO_ReadPin(gpiox->port, pin->pin_mask);
+}
+
+rtems_status_code rtems_gpio_toggle_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t 
*pin) {
+HAL_GPIO_TogglePin(gpiox->port, pin->pin_mask);
+return RTEMS_SUCCESSFUL;
+}
diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h
new file mode 100644
index 00..ef10d1729a
--- /dev/null
+++ b/bsps/include/bsp/gpio2.h
@@ -0,0 +1,129 @@
+/**
+  * @file
+  *
+  * @ingroup rtems_gpio2
+  *
+  * @brief RTEMS GPIO new API definition.
+  */
+
+ /*
+  *  Copyright (c) 2022 Duc Doan 
+  *
+  *  The license and distribution terms for this file may be
+  *  found in the file LICENSE in this distribution or at
+  *  http://www.rtems.org/license/LICENSE.
+  */
+
+#ifndef LIBBSP_SHARED_GPIO2_H
+#define LIBBSP_SHARED_GPIO2_H
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @name GPIO data structures
+ *
+ * @{
+ */
+
+/**
+  * @brief GPIO bit set and reset enumeration.
+  */
+typedef enum {
+RTEMS_GPIO_PIN_SET = 0,
+RTEMS_GPIO_PIN_RESET
+} rtems_gpio_pin_state;


Is set and reset the only state a pin can have? Or is that field thought 
to be extended with (for example) open drain or similar states if a 
device supports that?


Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better 
because than you can use it as a boolean without conversion.



+
+/**
+  * @brief Opaque type for a GPIO object.
+  *To be implemented by BSP.
+  *
+  * @details This could represent the unit that owns GPIO pins.
+  *  For example, it would be a port for ARM Cortex-M.
+  */
+typedef struct rtems_gpio_t rtems_gpio_t;


Does that mean it is (for example) a GPIO controller? In that case maybe 
call it "rtems_gpio_ctrl_t". My first guess from the name would have 
been that it is already a pin.


I assume that you don't plan to publish the definition of the struct 
rtems_gpio_t, right? With that the application can only use pointers. 
Where does the application get the pointer from?


Same is true for the structures below: How would I initialize one of 
these objects in the application?



+
+/**
+  * @brief Opaque type for a GPIO pin object.
+  *To be implemented by BSP.
+  */
+typedef struct rtems_gpio_pin_t rtems_gpio_pin_t;
+
+/**
+  * @brief Opaque type for configuration of a GPIO object.
+  *To be implemented by BSP.
+  */
+typedef struct rtems_gpio_config_t;
+
+/** @} */
+
+/**
+  * @name GPIO Functions
+  *
+  * @{
+  */
+
+/**
+  * @brief Initialization for GPIO. To be implemented by User Application.
+  *
+  * @retval RTEMS_SUCCESSFUL GPIO successfully initialized.
+  * @retval RTEMS_UNSATISFIED Could not initialize GPIO object.
+  */
+extern rtems_status_code rtems_gpio_initialize(void);
+


What would be done in that function?

Why does the application has to implement it?

Where would it be called?


+/**
+  * @brief Configures a GPIO object.
+

Re: [PATCH] cpukit/dev/can: Added CAN support

2022-07-19 Thread oss


Hello Prashanth,

first question: You also worked on a driver for beagle DCAN. Did you 
already adapt that driver to this API? If yes, it would be usefull to 
post that as a patch too so that the direction and the method how it 
will be used is more clear.


Note that some of my comments might are a bit critical because you add a 
general API. I would have a lot less problems if it would be only a 
driver specific API. If you add a general API, it has to fit the needs 
of not only your current driver but most future drivers too. Changing an 
API later is allways tricky.


Am 15.07.22 um 20:11 schrieb Prashanth S:

---
  cpukit/dev/can/can-queue.c| 112 +++
  cpukit/dev/can/can.c  | 480 ++
  cpukit/include/dev/can/can.h  | 115 +++
  spec/build/cpukit/librtemscpu.yml |   5 +
  4 files changed, 712 insertions(+)
  create mode 100644 cpukit/dev/can/can-queue.c
  create mode 100644 cpukit/dev/can/can.c
  create mode 100644 cpukit/include/dev/can/can.h

diff --git a/cpukit/dev/can/can-queue.c b/cpukit/dev/can/can-queue.c
new file mode 100644
index 00..1cebed2ca4
--- /dev/null
+++ b/cpukit/dev/can/can-queue.c
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+rtems_status_code can_create_rx_buffers(struct can_bus *bus)
+{
+  static int init = 0;
+
+  return rtems_message_queue_create(rtems_build_name('c', 'a', 'n', '0' + 
init++), CAN_RX_BUF_COUNT, sizeof(struct can_msg),
+RTEMS_FIFO | RTEMS_LOCAL, 
>rx_queue_id);


Please make sure to stic to the RTEMS style and use a 80 character line 
length.


You create a name with a "'0' + init++": Are you sure that a maximum of 
10 buffers are created? Otherwise you will get names like "can:", "can;" 
and - sooner or later: "can\xFF", "can\x00", ...


In the header you somewhere had a "destroy" function. Do you need some 
way to de-initialize buffers only used by that bus?



+}
+
+rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+  if ((bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT * 
sizeof(struct can_msg))) == NULL) {


You seem to like writing a lot of code in one line. From my point of 
view that makes code harder to read. If you write it into multiple lines 
instead, someone else doesn't have to think that much about which 
bracket closes where. For example in this case the following would be 
simpler to read:



bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT * 
sizeof(struct can_msg));

if (bus->tx_fifo.pbuf == NULL) {
   
}



+printf("malloc failed\n");


Prints are nice for debugging but can be really annoying in 
applications. Think about some kind of "debug_print" or similar that you 
can enable / disable with a macro at the start of the file. You can also 
use that to add a prefix or function name to all prints. If you search a 
problem, a line like "mallof failed" is meaningless if you are not 
currently working on specially this code. A line like 
"can_create_tx_buffers: malloc failed" is a lot more usefull. There are 
preprocessor macros like __FUNCTION__ that you can use for something 
like that.



+return RTEMS_NO_MEMORY;
+  }
+
+  bus->tx_fifo.head = bus->tx_fifo.tail = 0;


Same here: This is hard to read. I would suggest to split that into two 
lines. Alternatively you might want to think about just using a memset 
to have a clean start for a structure that you

Re: [PATCH v4 1/7] bsps/stm32f4 Include STM32F4 HAL

2022-07-23 Thread oss


Hello Duc,

Am 23.07.22 um 09:37 schrieb Duc Doan:

Hello Karel,

On Sat, 2022-07-23 at 09:09 +0200, Karel Gardas wrote:


Duc,

where have you taken F4 HAL exactly? I'm asking since your import is
full of CRLF line endings which we try hard to eliminate in RTEMS
while
original is not. Proof:

$ git clone https://github.com/STMicroelectronics/STM32CubeF4.git
Cloning into 'STM32CubeF4'...
remote: Enumerating objects: 75365, done.
remote: Counting objects: 100% (1271/1271), done.
remote: Compressing objects: 100% (48/48), done.
remote: Total 75365 (delta 1231), reused 1229 (delta 1221), pack-
reused
74094
Receiving objects: 100% (75365/75365), 157.59 MiB | 6.87 MiB/s, done.
Resolving deltas: 100% (46903/46903), done.
Updating files: 100% (39125/39125), done.
rtems@silence:~/vcs$ cd STM32CubeF4/
rtems@silence:~/vcs/STM32CubeF4$
rtems@silence:~/vcs/STM32CubeF4$
rtems@silence:~/vcs/STM32CubeF4$ git ls-files --eol|grep crlf
rtems@silence:~/vcs/STM32CubeF4$


Please use the command above to review your CRLF files.

Thanks,
Karel



I took the HAL from ST's website by downloading the zip. And yes, when
I tried the command, all HAL files have CRLF. I will remove them in the
next patch set.


Have you thought about using the STM32CubeF4 repo that Karel linked 
instead of the ZIP file as a source?


Can you please add the source for your files to the commit description? 
If you used a zip, provide the link, date, version (if available) and 
maybe a checksum of the file. If you used a git repository (which I 
would prefer), provide a link and the commit ID. That makes it simpler 
to some when find the sources that you used.


Best regards

Christian



Thanks for the reminder,

Duc Doan
___
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: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-08-01 Thread oss

Hello Duc,

Am 01.08.22 um 04:13 schrieb Duc Doan:

Hello Christian,

On Sun, 2022-07-31 at 20:01 +0200, o...@c-mauderer.de wrote:

Hello Duc,

Am 31.07.22 um 17:07 schrieb Duc Doan:

Hello Christian,

On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote:

Hello Duc,

general note for the patch: Please write in the commit message
where
you
got the sources from. That can be a link to a github repo
including a
commit ID or a link to the zip file from ST (including a date,
version
or similar information). If you moved some stuff around compared
to
the
original structure: Please describe about what you did. For
example
in
the imxrt I just added the cp commands that I used:

https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285

Not the best solution but at least someone else can find out
roughly
what I did.

Ah yes, I will do that. I thought I only needed to put the
description
in the email before.

Am 24.07.22 um 14:01 schrieb Duc Doan:

This patch is too large so I cannot send via email. Please find
it
here:
https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16

---
.gitignore | 1 +

You added a "patches" directory to the gitignore. That looks like
a
change that is specific to your method of working. These kind of
changes
should normall not be pushed.

If you want to ignore stuff specific to your work environment, I
recommend to use a global .gitignore file. Git has a
"core.excludesfile"
config for that.

Thanks for the suggestion, I will fix that.

Are the cmsis files from the same source or directly from ARM?

They are from the same source (STM HAL v1.27.1).

The cmsis_gcc.h has a lot of changes compared to the earlier
version
that has been present in RTEMS. A lot of the changes seem to be
whitespace changes. Can these be avoided somehow (for example by
using
dos2unix before overwriting the file)?

From what I've just read about dos2unix, it converts line breaks
from
CRLF to LF (please correct me if I'm wrong). How will this command
resolve the whitespace changes?

I haven't looked at the exact type of whitespace changes. I had the
impression that the difference is most likely only the line ending.
It
didn't look like tab / space issue. Is it a tab / space issue?

I've looked at the some files and noticed that the difference is mostly
additional code/code change (e.g. adding support for ARMv8), but not
whitespace changes.

Hm. Odd. In that case: Why does the diff show a complete removal and
complete adding of (for example) cmsis_gcc.h:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185

In the discord chat there was one suggestion from Ho Kaido to
move
the
files one level down and make them BSP specific. I'm not sure
whether
I'm for or against that idea. Advantage is that it makes BSPs
independant from each other. Disadvantage is that it duplicates
code.

I think I would try to avoid moving them down due to the code
duplication but it raises the question: Which BSPs use the files
too
and
did you try whether they still compile after the upgrade?

Until now I only know of STM32H7 BSP that is using the CMSIS files.
I
tried compiling it before and Karel also confirmed that the BSP
compiles.

Just as an example: core_cm4/7.h is included at least in stm32f4,
stm32h7, atsam and imxrt. So we have to make sure that these three
are
compile-clean. Please use grep to find out where the headers are
included and check whether I maybe missed a BSP.

I have checked using grep (grep -rl ~/gsoc2022/src/rtems/bsps/arm -e
"cmsis\|core_cm" and found that stm32f4, imxrt, stm32h7, and atsam are
using CMSIS files (you remembered all correctly!). I've checked and all
4 of them compile without error.

Great. Thanks for checking.

Best regards

Christian

Best,

Duc

.../stm32f4/hal/Legacy/stm32f4xx_hal_can.c | 1679 ++
.../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c | 2307 ++
bsps/arm/stm32f4/hal/stm32f4xx_hal.c | 615 +
bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c | 2110 ++
bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c | 1112 +
bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c | 2462 ++
bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c | 996 +
bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c | 502 +
bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c | 328 +
bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c | 7132 ++

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-07-30 Thread oss





Am 30.07.22 um 21:41 schrieb Karel Gardas:

On 7/30/22 16:32, o...@c-mauderer.de wrote:

  bsps/arm/include/cmsis_compiler.h |   266 +
  bsps/arm/include/cmsis_gcc.h  |  3460 +--
  bsps/arm/include/cmsis_version.h  |    39 +
  bsps/arm/include/core_cm4.h   |   524 +-
  bsps/arm/include/core_cm7.h   |  5186 ++--
  bsps/arm/include/mpu_armv7.h  |   270 +


Are the cmsis files from the same source or directly from ARM?

The cmsis_gcc.h has a lot of changes compared to the earlier version 
that has been present in RTEMS. A lot of the changes seem to be 
whitespace changes. Can these be avoided somehow (for example by using 
dos2unix before overwriting the file)?


In the discord chat there was one suggestion from Ho Kaido to move the 
files one level down and make them BSP specific. I'm not sure whether 
I'm for or against that idea. Advantage is that it makes BSPs 
independant from each other. Disadvantage is that it duplicates code.


I think I would try to avoid moving them down due to the code 
duplication but it raises the question: Which BSPs use the files too 
and did you try whether they still compile after the upgrade?


We have had this dicussion with Duc on discord IIRC when he started. He 
needed new CMSIS (v5) version due to new HAL which Duc claims depends on 
them. I have not verified that claim personally.


New CMSIS v5 brings obviously:

- by ARM maintained code (v4 is unmaintained IIRC)

but also:

- license change from BSD to Apache-2

At that time I've told Duc to continue with the code and not to worry 
about license changes -- as this would be longer discussion anyway. Not 
sure, but IIRC he also wrote to Sebastian asking for clarification -- 
well, not sure about that. Certainly IIRC I suggested that.


Anyway, I took Duc code and try H7 BSPs and to my surprise they compiles 
more or less all without any compilation related issue. Well, I've not 
tried M4 variants. So far I've not run full tester on this. I'll, but 
first I'd like to test his API if it's possible to also use with H7.


BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then it's 
perhaps possible to go in F4 HAL history back and grab just the three 
with the v4 dependency. On the other hand, for ARM Apache-2 seems to be 
the way forward and for some ST.com depended code too -- so I guess 
RTEMS project will need to live with that fact somehow.


Thanks,
Karel



Hello Karel,

thanks for the clarification. I have to be honest: I missed the license 
change. That is a bit of a difficult one and will cause a discussion. 
@Duc: We need a new LICENSE file in the top level that represents 
that. Maybe split the CMSIS update into a separate patch so that it is 
clear why there is a new license file (if the license is only for the 
CMSIS and not for the STM HAL too).


But my main concern was another one: Which BSPs use the CMSIS files? 
Beneath the stm32 variants, that's at least the atsam and imxrt. Maybe I 
missed some more. We should at least make sure that these BSPs are 
compile-clean with the updated cmsis headers.


Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework

2022-07-30 Thread oss


Hello Duc,

Am 24.07.22 um 14:01 schrieb Duc Doan:

---
  bsps/include/bsp/gpio2.h| 528 
  bsps/include/bsp/periph_api.h   | 142 +++
  bsps/shared/dev/gpio/gpio.c | 212 ++
  bsps/shared/dev/periph_api/periph_api.c | 101 +
  spec/build/bsps/obj.yml |   4 +-
  5 files changed, 986 insertions(+), 1 deletion(-)
  create mode 100644 bsps/include/bsp/gpio2.h
  create mode 100644 bsps/include/bsp/periph_api.h
  create mode 100644 bsps/shared/dev/gpio/gpio.c
  create mode 100644 bsps/shared/dev/periph_api/periph_api.c

diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h


I'm not really happy with the "2" in the name. But at the moment I don't 
have a much better idea either. But if you call it "gpio2", you should 
call the C files "gpio2" too. Maybe "dev/gpio/gpio.h" similar to the 
"dev/i2c/i2c.h"?



new file mode 100644
index 00..9cb1c720ab
--- /dev/null
+++ b/bsps/include/bsp/gpio2.h
@@ -0,0 +1,528 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+


Your file is missing some general doxygen group information. Take a look 
at for example bsps/include/ofw/ofw.h.



+/*
+ * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef LIBBSP_BSP_GPIO2_H
+#define LIBBSP_BSP_GPIO2_H
+
+#include 
+#include 
+
+/**
+  * Configure the maximum number of GPIO controllers used in
+  * a application.
+  *
+  * The macro CONFIGURE_GPIO_MAXIMUM_CONTROLLERS can be
+  * defined in application code. If it is not defined,
+  * it will default to BSP_GPIO_NUM_CONTROLLERS. If BSP's
+  * number of controllers is not defined, it will default
+  * to 1.
+  */
+#ifndef CONFIGURE_GPIO_MAXIMUM_CONTROLLERS


How do you manage that the CONFIGURE_GPIO_MAXIMUM_CONTROLLERS from the 
application is visible here?



+
+#ifndef BSP_GPIO_NUM_CONTROLLERS
+#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS 1
+#else
+#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS BSP_GPIO_NUM_CONTROLLERS
+#endif /* BSP_GPIO_NUM_CONTROLLERS */
+
+#endif /* CONFIGURE_GPIO_MAXIMUM_CONTROLLERS */
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+  * @brief Macro to initialize rtems_gpio.
+  *
+  * @param gpioh pointer to GPIO handlers
+  */
+#define RTEMS_GPIO_BUILD_BASE(_gpio_handlers)   \
+(rtems_gpio) { .virtual_pin = 0,\
+   .gpio_handlers = ( _gpio_handlers ), \
+   .api = NULL  \
+};
+
+/**
+  * @name GPIO data structures
+  *
+  * @{
+  */
+
+/**
+  * @brief GPIO bit set and reset enumeration.
+  */
+typedef enum {
+RTEMS_GPIO_PIN_RESET = 0,
+RTEMS_GPIO_PIN_SET = 1
+} rtems_gpio_pin_state;
+
+/**
+  * @brief GPIO pin modes.
+  */
+typedef enum {
+RTEMS_GPIO_PINMODE_OUTPUT = 0,
+RTEMS_GPIO_PINMODE_OUTPUT_PP = 0,
+RTEMS_GPIO_PINMODE_OUTPUT_OD = 1,
+RTEMS_GPIO_PINMODE_INPUT = 2,
+RTEMS_GPIO_PINMODE_ANALOG = 3,
+RTEMS_GPIO_PINMODE_BSP_SPECIFIC = 4


Maybe the BSP_SPECIFIC should start at a high, fixed offest so that 
adding new general values is simpler. Something like


  RTEMS_GPIO_PINMODE_BSP_SPECIFIC = 100,

A BSP can than use 100, 101, 102, ... for it's specific functions. If 
someone later adds a generic RTEMS_GPIO_PINMODE_FOO = 4, it won't result 
in any conflicts.



+} rtems_gpio_pin_mode;
+
+/**
+  * @brief GPIO pull resistor configuration. Defines pull-up or
+  *pull-down activation.
+  */
+typedef enum {
+RTEMS_GPIO_NOPULL,
+RTEMS_GPIO_PULLUP,
+RTEMS_GPIO_PULLDOWN


Maybe add a "BSP_SPECIFIC" here too. I know of controllers that can 
activate different

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-07-30 Thread oss


Hello Duc,

general note for the patch: Please write in the commit message where you 
got the sources from. That can be a link to a github repo including a 
commit ID or a link to the zip file from ST (including a date, version 
or similar information). If you moved some stuff around compared to the 
original structure: Please describe about what you did. For example in 
the imxrt I just added the cp commands that I used:



https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285

Not the best solution but at least someone else can find out roughly 
what I did.


Am 24.07.22 um 14:01 schrieb Duc Doan:

This patch is too large so I cannot send via email. Please find it here:
https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16

---
  .gitignore| 1 +


You added a "patches" directory to the gitignore. That looks like a 
change that is specific to your method of working. These kind of changes 
should normall not be pushed.


If you want to ignore stuff specific to your work environment, I 
recommend to use a global .gitignore file. Git has a "core.excludesfile" 
config for that.



  bsps/arm/include/cmsis_compiler.h |   266 +
  bsps/arm/include/cmsis_gcc.h  |  3460 +--
  bsps/arm/include/cmsis_version.h  |39 +
  bsps/arm/include/core_cm4.h   |   524 +-
  bsps/arm/include/core_cm7.h   |  5186 ++--
  bsps/arm/include/mpu_armv7.h  |   270 +


Are the cmsis files from the same source or directly from ARM?

The cmsis_gcc.h has a lot of changes compared to the earlier version 
that has been present in RTEMS. A lot of the changes seem to be 
whitespace changes. Can these be avoided somehow (for example by using 
dos2unix before overwriting the file)?


In the discord chat there was one suggestion from Ho Kaido to move the 
files one level down and make them BSP specific. I'm not sure whether 
I'm for or against that idea. Advantage is that it makes BSPs 
independant from each other. Disadvantage is that it duplicates code.


I think I would try to avoid moving them down due to the code 
duplication but it raises the question: Which BSPs use the files too and 
did you try whether they still compile after the upgrade?




  .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c|  1679 ++
  .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c|  2307 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |   615 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  |  2110 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   |  1112 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  |  2462 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |   996 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |   502 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |   328 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c |  7132 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |   680 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  |  1341 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |   495 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c |  1161 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |   182 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c|  4423 
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  |  1305 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c|  2126 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |   313 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  |  2760 +++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  |  3220 +++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |   547 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c|   775 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c |  1347 +
  .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |   172 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c   |  6864 ++
  .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c |   258 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpsmbus.c |  2749 +++
  .../stm32f4/hal/stm32f4xx_hal_fmpsmbus_ex.c   |   145 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_gpio.c |   533 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_hash.c |  3514 +++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_hash_ex.c  |  1040 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_hcd.c  |  1728 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c.c  |  7524 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c_ex.c   |   182 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s.c  |  2094 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s_ex.c   |  1135 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_irda.c |  2687 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_iwdg.c |   262 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_lptim.c|  2484 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc.c |  2215 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc_ex.c  |   151 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_mmc.c  |  3201 +++
  .../stm32f4/hal/stm32f4xx_hal_msp_template.c  |   100 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_nand.c |

Re: devel Digest, Vol 129, Issue 37

2022-08-21 Thread oss

Hello Prashanth,

I added a number of comments for the first (API) commit using the gitlab 
comment function:

https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/2283ab18bd2fbfa363233c6dabcfa5123225f27c

PS: Please don't answer to Devel Digests. That adds totally unrelated 
content to your mails. Beneath that it has a compleatly meaningless 
toppic. That's why the original devel digest mail had this note:

> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."

Normally I strongly suggest to disable digest and let the list send 
individual messages instead. Use a mail filter (ideally server side) to 
move them into one folder so that they don't spam your inbox.

Best regards

Christian

Am 21.08.22 um 08:02 schrieb Prashanth S:

Hi All,

This is a review request for DCAN and CAN support. The review comments
would be very helpful for stabilizing the source files.

https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-review-latest-squash-02-squash/

Regards
Prashanth S

On Mon, 15 Aug 2022 at 11:57, Prashanth S  wrote:

Hi All,

This is a review request for DCAN (Work in Progress) support.

As the patch size exceeds the mail limit, I am attaching the patch in
compressed format.

Regards
Prashanth S

Prashanth S

On Sun, 14 Aug 2022 at 13:56,  wrote:

Send devel mailing list submissions to
 devel@rtems.org

To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.rtems.org/mailman/listinfo/devel
or, via email, send a message with subject or body 'help' to
 devel-requ...@rtems.org

You can reach the person managing the list at
 devel-ow...@rtems.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of devel digest..."

[...]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Review Request for DCAN patches

2022-10-26 Thread oss


Hello Prashanth,

from my point of view the patches look good and I think you processed 
Gedares feedback too. So if no one objects I'll pus the patches on the 
weekend.


Last version is this one:

https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/

Like discussed in Discord, it would be good to squash the canqueueimpl.h 
into the CAN support. Either you can do that or I'll do it right before 
pushing.


Best regards

Christian

Am 16.10.22 um 19:12 schrieb Prashanth S:

Hi All,

This is a review request for the DCAN patch, I have updated the files 
based on review comments.

Attaching the patch as a zip file.

Regards
Prashanth S

___
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: Adding third-party source with Apache-2.0 license

2022-08-07 Thread oss


Hello Duc,

Am 07.08.22 um 13:06 schrieb Duc Doan:

Dear all,

I am working on a project that needs to include ST's STM32F4 HAL into
RTEMS, specifically release v1.27.1 at:
https://github.com/STMicroelectronics/STM32CubeF4. However, the CMSIS
files in this repository have Apache-2.0 license. What do you think
about this? Should I add them to RTEMS, or is there anything I need to
do to include these sources?


Thanks for bringing up this issue. I think one important point is that 
all newer ARM CMSIS files are Apache 2.0:


  https://github.com/ARM-software/CMSIS_5

So that affects all ARM cores and not only STM32. From my point of view, 
we sooner or later have to accept this license if we don't want to 
maintain our own fork of ARM CMSIS.


Best regards

Christian



Thank you,

Duc Doan
___
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: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-07-31 Thread oss


Hello Duc,

Am 31.07.22 um 17:07 schrieb Duc Doan:

Hello Christian,

On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote:

Hello Duc,

general note for the patch: Please write in the commit message where
you
got the sources from. That can be a link to a github repo including a
commit ID or a link to the zip file from ST (including a date,
version
or similar information). If you moved some stuff around compared to
the
original structure: Please describe about what you did. For example
in
the imxrt I just added the cp commands that I used:

  
https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285


Not the best solution but at least someone else can find out roughly
what I did.



Ah yes, I will do that. I thought I only needed to put the description
in the email before.


Am 24.07.22 um 14:01 schrieb Duc Doan:

This patch is too large so I cannot send via email. Please find it
here:
https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16

---
   .gitignore    | 1 +


You added a "patches" directory to the gitignore. That looks like a
change that is specific to your method of working. These kind of
changes
should normall not be pushed.

If you want to ignore stuff specific to your work environment, I
recommend to use a global .gitignore file. Git has a
"core.excludesfile"
config for that.



Thanks for the suggestion, I will fix that.


   bsps/arm/include/cmsis_compiler.h |   266 +
   bsps/arm/include/cmsis_gcc.h  |  3460 +--
   bsps/arm/include/cmsis_version.h  |    39 +
   bsps/arm/include/core_cm4.h   |   524 +-
   bsps/arm/include/core_cm7.h   |  5186 ++--
   bsps/arm/include/mpu_armv7.h  |   270 +


Are the cmsis files from the same source or directly from ARM?



They are from the same source (STM HAL v1.27.1).


The cmsis_gcc.h has a lot of changes compared to the earlier version
that has been present in RTEMS. A lot of the changes seem to be
whitespace changes. Can these be avoided somehow (for example by
using
dos2unix before overwriting the file)?



From what I've just read about dos2unix, it converts line breaks from
CRLF to LF (please correct me if I'm wrong). How will this command
resolve the whitespace changes?


I haven't looked at the exact type of whitespace changes. I had the 
impression that the difference is most likely only the line ending. It 
didn't look like tab / space issue. Is it a tab / space issue?





In the discord chat there was one suggestion from Ho Kaido to move
the
files one level down and make them BSP specific. I'm not sure whether
I'm for or against that idea. Advantage is that it makes BSPs
independant from each other. Disadvantage is that it duplicates code.

I think I would try to avoid moving them down due to the code
duplication but it raises the question: Which BSPs use the files too
and
did you try whether they still compile after the upgrade?



Until now I only know of STM32H7 BSP that is using the CMSIS files. I
tried compiling it before and Karel also confirmed that the BSP
compiles.


Just as an example: core_cm4/7.h is included at least in stm32f4, 
stm32h7, atsam and imxrt. So we have to make sure that these three are 
compile-clean. Please use grep to find out where the headers are 
included and check whether I maybe missed a BSP.







   .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c    |  1679 ++
   .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c    |  2307 ++
   bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |   615 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  |  2110 ++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   |  1112 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  |  2462 ++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |   996 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |   502 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |   328 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c |  7132 ++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |   680 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  |  1341 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |   495 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c |  1161 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |   182 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c    |  4423 
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  |  1305 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c    |  2126 ++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |   313 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  |  2760 +++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  |  3220 +++
   bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |   547 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c    |   775 +
   bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c |  1347 +
   .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |   172 +

Re: [PATCH] cpukit/dev/can: Added CAN support

2022-08-02 Thread oss


Hello Duc,

general note: You add an API to cpukit. Most APIs there should have a 
test case in the testsuite. In this case the test case would have to 
create some dummy CAN driver and check whether everything works like 
expected. As an example take a look at the SPI test:


  https://git.rtems.org/rtems/tree/testsuites/libtests/spi01/init.c

It creates a dummy device and checks whether the SPI layer does 
everything as expected. Would be great if you could add something like 
this. Target of such a test should be more or less that every branch in 
your code is triggered at least once (code coverage). It doesn't has to 
be every combination but it shows that the code is at least reachable 
and works as expected.


Am 31.07.22 um 13:53 schrieb Prashanth S:

---
  cpukit/dev/can/can.c   | 514 +
  cpukit/include/dev/can/can-msg.h   |  55 +++
  cpukit/include/dev/can/can-queue.h | 127 +++
  cpukit/include/dev/can/can.h   | 102 ++
  spec/build/cpukit/librtemscpu.yml  |   6 +
  5 files changed, 804 insertions(+)
  create mode 100644 cpukit/dev/can/can.c
  create mode 100644 cpukit/include/dev/can/can-msg.h
  create mode 100644 cpukit/include/dev/can/can-queue.h
  create mode 100644 cpukit/include/dev/can/can.h

diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..8feec8800b
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,514 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+static ssize_t
+can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
+static ssize_t
+can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
+static ssize_t
+can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
+static ssize_t
+can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
+
+static int can_xmit(struct can_bus *bus);
+
+static int can_create_sem(struct can_bus *);
+static int try_sem(struct can_bus *);
+static int take_sem(struct can_bus *);
+static int give_sem(struct can_bus *);
+
+/* sem_count this is for debug purpose, for debugging
+the take_sem and give_sem
+*/
+static int sem_count = 0;
+
+static void can_bus_obtain(can_bus *bus)
+{
+  rtems_recursive_mutex_lock(>mutex);
+}
+
+static void can_bus_release(can_bus *bus)
+{
+  rtems_recursive_mutex_unlock(>mutex);
+}
+
+int can_create_sem(struct can_bus *bus)
+{
+  int ret = 0;
+
+  ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index),
+  CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL,
+  0, >tx_fifo_sem_id);
+
+  if (ret != 0) {
+printf("can_create_sem: rtems_semaphore_create failed %d\n", ret);
+  }
+
+  return ret;
+}
+
+static void can_interrupt_lock_acquire(struct can_bus *bus)
+{
+  can_bus_obtain(bus);
+  bus->can_dev_ops->dev_int(bus->priv, false);
+}
+
+static void can_interrupt_lock_release(struct can_bus *bus)
+{
+  bus->can_dev_ops->dev_int(bus->priv, true);
+  can_bus_release(bus);
+}
+
+static int take_sem(struct can_bus *bus)
+{
+  int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT,
+RTEMS_NO_TIMEOUT);
+  if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count);



Do you really mean "LOCK" or should it be a "LOG"? Both is reasonable 
here so I'm not entirely sure. But you use the LOCK macro

Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework

2022-08-02 Thread oss


Hello Duc,

Am 02.08.22 um 09:17 schrieb Duc Doan:
[...]

diff --git a/bsps/include/bsp/periph_api.h
b/bsps/include/bsp/periph_api.h
new file mode 100644
index 00..fb02b701dc
--- /dev/null
+++ b/bsps/include/bsp/periph_api.h


Isn't it an API just because you add it here. Is it really
necessary
to
add the "API" in the name?



I was thinking that this periph_api is the base for other APIs, so
I
added "api" in the name.


I'm not entirely sure yet whether this API is really something
separate
from your GPIO API. The "gpio_start" calls the "periph_api_start"
and
the periph_api functions use gpio internal structures. I think I
would
just add these few functions to the GPIO API.



That is also an option. The reason I separated them is that I
thought
these additional functions should be somehow separated from the
basic
GPIO to avoid making GPIO API too complicated. Also, this API is
mostly
for adding new peripheral APIs and not targetting user application.
Users only need to use one function, set_api().


Please note that in our case a user can and often will add his own
drivers to an application too. Not all drivers are in the BSP. Some
applications need specialy tuned drivers and therefor will bring
their
own ones.




I'm still not convinced that this is necessary at all. A
peripheral
has
to know it's pins. But the pin doesn't have to know anything
about
the
connected peripheral. So why do we need that? At the moment it
seems
to
add mainly some complexity and uses some memory.



Logically, a pin doesn't have to know about the connected
peripheral.
However, this newly added API is just a way to make things easier
for
users.

Without this API, for each peripheral, users need to create new
objects
that hold information about both the GPIO pins and the handlers of
that
peripheral. They would have to maintain those objects all the time
during the use of that peripheral. If users want to change the
functionality, they have to create new objects of that peripheral
type.


If the functionallity does not change, the peripheral can just know
it's
pin and the user just has to know and handle the peripheral. Only
during
the initialization he has to init the pin first and the peripheral
afterwards. But that's the case with your API too, isn't it?

If the functionality of a pin changes (which is a really rare use
case)
the user will need two APIs. So if I understand your code correctly,
he
would have to:

- Init GPIO pin.
- Add API for example for ADC.
- Use that pin.
- Remove API for ADC.
- Add API for example for DAC.
- Use the pin.
- Remove API for DAC.
...

So he has to switch in or out the API. For this switching he
eitherhas
to provide memory for the ADC / DAC API or the memory is dynamically
allocated on every switch. I think I would rather keep multiple
pointers
in my application instead of allocating something every time.



This API avoids that by reusing the already-existing GPIO pin
objects.
Users only need a single GPIO object for a pin for all operations,
be
it basic GPIO or additional peripherals. This creates simplicity
for
user application at the cost of added memory (one additional
pointer
member, which is not much in my opinion).



For a single use pin that doesn't have to switch function, the user
needs only one pointer. The one to the object of the driver with the
function he uses. The pin can be a part of that object.


By the way, this newly added API is mostly targeting peripherals
that
require a single pin like ADC or DAC.


That doesn't make it better. Now you added complexity for very
special
cases ;-)



Hmm your reasoning makes sense. Should I change so that ADC contains
the pin as a member (and thus remove the peripheral API)?


From my point of view, that would be better. You maybe could think 
about hinting on that point in the meeting tomorrow. Maybe someone else 
will add an oppinion too.


Best regards

Christian



Best,

Duc




[...]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-08-02 Thread oss


Hello Duc,

Am 02.08.22 um 12:37 schrieb Duc Doan:

Hello Christian,

On Sat, 2022-07-30 at 22:19 +0200, o...@c-mauderer.de wrote:




Am 30.07.22 um 21:41 schrieb Karel Gardas:

On 7/30/22 16:32, o...@c-mauderer.de wrote:

   bsps/arm/include/cmsis_compiler.h |   266 +
   bsps/arm/include/cmsis_gcc.h  |  3460 +--
   bsps/arm/include/cmsis_version.h  |    39 +
   bsps/arm/include/core_cm4.h   |   524 +-
   bsps/arm/include/core_cm7.h   |  5186 ++--
   bsps/arm/include/mpu_armv7.h  |   270 +


Are the cmsis files from the same source or directly from ARM?

The cmsis_gcc.h has a lot of changes compared to the earlier
version
that has been present in RTEMS. A lot of the changes seem to be
whitespace changes. Can these be avoided somehow (for example by
using
dos2unix before overwriting the file)?

In the discord chat there was one suggestion from Ho Kaido to
move the
files one level down and make them BSP specific. I'm not sure
whether
I'm for or against that idea. Advantage is that it makes BSPs
independant from each other. Disadvantage is that it duplicates
code.

I think I would try to avoid moving them down due to the code
duplication but it raises the question: Which BSPs use the files
too
and did you try whether they still compile after the upgrade?


We have had this dicussion with Duc on discord IIRC when he
started. He
needed new CMSIS (v5) version due to new HAL which Duc claims
depends on
them. I have not verified that claim personally.

New CMSIS v5 brings obviously:

- by ARM maintained code (v4 is unmaintained IIRC)

but also:

- license change from BSD to Apache-2

At that time I've told Duc to continue with the code and not to
worry
about license changes -- as this would be longer discussion anyway.
Not
sure, but IIRC he also wrote to Sebastian asking for clarification
--
well, not sure about that. Certainly IIRC I suggested that.

Anyway, I took Duc code and try H7 BSPs and to my surprise they
compiles
more or less all without any compilation related issue. Well, I've
not
tried M4 variants. So far I've not run full tester on this. I'll,
but
first I'd like to test his API if it's possible to also use with
H7.

BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then
it's
perhaps possible to go in F4 HAL history back and grab just the
three
with the v4 dependency. On the other hand, for ARM Apache-2 seems
to be
the way forward and for some ST.com depended code too -- so I guess
RTEMS project will need to live with that fact somehow.

Thanks,
Karel



Hello Karel,

thanks for the clarification. I have to be honest: I missed the
license
change. That is a bit of a difficult one and will cause a discussion.
@Duc: We need a new LICENSE file in the top level that represents
that. Maybe split the CMSIS update into a separate patch so that it
is
clear why there is a new license file (if the license is only for the
CMSIS and not for the STM HAL too).



Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source
root? I found this file being shipped with STM
HAL: 
https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt
Should I copy this file and rename it to LICENSE.Apache-2.0?


Short answer: Yes.

A bit longer answer: Please make sure that it's really an unchanged 
Apache license before you copy it. I assume it is but just to be sure, I 
would use a diff with the one from opensource.org:


  https://opensource.org/licenses/Apache-2.0

Best regards

Christian



Best,

Duc


But my main concern was another one: Which BSPs use the CMSIS files?
Beneath the stm32 variants, that's at least the atsam and imxrt.
Maybe I
missed some more. We should at least make sure that these BSPs are
compile-clean with the updated cmsis headers.

Best regards

Christian



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Identify 3rd party source in spec?

2022-11-01 Thread oss

Hello Gedare,

Am 31.10.22 um 20:01 schrieb Gedare Bloom:

Resending without the first patch since it may trigger size filters.

-- Forwarded message -
From: Gedare Bloom 
Date: Mon, Oct 31, 2022 at 12:55 PM
Subject: Identify 3rd party source in spec?
To: devel@rtems.org 

Hello all,

I would like to float the idea of managing 3rd party source tracking
through the build system spec files. I believe this would be the most
efficient way to maintain this information, and we can leverage the
existing build system code for tasks such as automatic format checks,
generating lists of third-party code, etc.

Sounds like a good idea to have it in the build specification items.

This will require refactoring some spec files to pull 3rd party code
out to a separate .yml file that gets linked. Once that is done, then
we could add another attribute for this tracking purpose. I would like
to keep it simple as a boolean, maybe just "third-party: true/false"
Attached is an example patch showing how this might work for the
dtc/libfdt code as a build objects item type 'obj', and for zlib
library as a build library item type 'lib' with some proof-of-concept
code for generating a listing of third party source files.

Is it a good idea to make it a mandatory attribute? It makes the yaml 
files bigger. It will only mean that we have to look for copy and paste 
bugs instead of missing attributes if someone adds a new third party 
library.

Do we need some additional information / scripts / stuff for third party 
code? Like an upstream source or upstream version? For example the JFFS2 
code has a VERSION file with lots of information:

https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/VERSION

For the imxrt I added something similar in the commit description:

https://git.rtems.org/rtems/commit/bsps/arm/imxrt/nxp?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285

Full text is a bit big for an attribute but maybe the location of a 
VERSION file in the source tree? Or a minimal link to an upstream code 
and a version info?

Best regards

Christian

As an initial step before making this refactoring, I have added an
explicit default "third-party: false" attribute to every yml file
preceding the enabled-by: attribute, using the following bit of shell:
rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e
's/\(enabled-by.*\)/third-party: false\n\1/'

This touches 2333 files adding that one line, which is the contents of
the first 1 MiB patch attached in the series. The remaining patches
then layer on the top and are functional, outputting:

rtems.git$ ./waf third_party_list
cpukit/dtc/libfdt/fdt.c
cpukit/dtc/libfdt/fdt_addresses.c
cpukit/dtc/libfdt/fdt_empty_tree.c
cpukit/dtc/libfdt/fdt_ro.c
cpukit/dtc/libfdt/fdt_rw.c
cpukit/dtc/libfdt/fdt_strerror.c
cpukit/dtc/libfdt/fdt_sw.c
cpukit/dtc/libfdt/fdt_wip.c
cpukit/zlib/adler32.c
cpukit/zlib/compress.c
cpukit/zlib/crc32.c
cpukit/zlib/deflate.c
cpukit/zlib/gzclose.c
cpukit/zlib/gzlib.c
cpukit/zlib/gzread.c
cpukit/zlib/gzwrite.c
cpukit/zlib/infback.c
cpukit/zlib/inffast.c
cpukit/zlib/inflate.c
cpukit/zlib/inftrees.c
cpukit/zlib/trees.c
cpukit/zlib/uncompr.c
cpukit/zlib/zutil.c

I'll continue to work on this, feedback is requested though if this is
a good direction or how to improve.

Gedare

___
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: RSB repo commits need approval

2023-04-28 Thread oss


Hello Joel,

Am 28.04.23 um 00:19 schrieb Joel Sherrill:



On Wed, Apr 26, 2023 at 7:06 PM Chris Johns > wrote:


Hi,

All RSB repo commits need to be posted for review and independent
approval given
before being pushed to the top level repo.


I thought this was the policy for all top level repositories. There is a 
degree of trust
on any posted patch that it has been tested by the submitter with the 
understanding
that things do slip through. If someone is regularly submitting 
modifications without

testing them, then we have a larger problem.


Regarding the policy: I think that is documented in the rtems.git in the 
MAINTAINERS-file:


  https://git.rtems.org/rtems/tree/MAINTAINERS

We have a few people who are trusted to distinguish between patches that 
can be pushed without review and patches that should get a review while 
all other should post a patch for review and wait at least for a few 
days before pushing it (for BSP specific stuff) or need an acknowledge 
(for general stuff).



Chris: Is that a temporary rule for the blanket write privilege 
maintainers while trying to reach a stable release version? Is there a 
difference between the tools starting with "6/" (which should be the 
release version) and the ones that start with "7/" (which are more or 
less an unstable test version)?


Best regards

Christian



That said, I think we all have accidentally gotten through a reviewed 
patch which

broke some odd BSP/architecture or introduced warnings.

This isn't about improving testing. It is just formalizing that a patch 
should be

posted for review and an ACK.

--joel


Thanks
Chris
___
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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB repo commits need approval

2023-05-01 Thread oss


Am 30.04.23 um 23:53 schrieb Chris Johns:



On 29/4/2023 3:48 am, o...@c-mauderer.de wrote:

Hello Joel,

Am 28.04.23 um 00:19 schrieb Joel Sherrill:



On Wed, Apr 26, 2023 at 7:06 PM Chris Johns mailto:chr...@rtems.org>> wrote:

     Hi,

     All RSB repo commits need to be posted for review and independent
     approval given
     before being pushed to the top level repo.


I thought this was the policy for all top level repositories. There is a
degree of trust
on any posted patch that it has been tested by the submitter with the
understanding
that things do slip through. If someone is regularly submitting modifications
without
testing them, then we have a larger problem.


Regarding the policy: I think that is documented in the rtems.git in the
MAINTAINERS-file:

   https://git.rtems.org/rtems/tree/MAINTAINERS

We have a few people who are trusted to distinguish between patches that can be
pushed without review and patches that should get a review while all other
should post a patch for review and wait at least for a few days before pushing
it (for BSP specific stuff) or need an acknowledge (for general stuff).


Chris: Is that a temporary rule for the blanket write privilege maintainers
while trying to reach a stable release version? Is there a difference between
the tools starting with "6/" (which should be the release version) and the ones
that start with "7/" (which are more or less an unstable test version)?


I think we should post all because it is simpler but it is a good and valid
question. A reason to post all changes is questions or a wrong interpretation
can be resolved up front. I also understand how much better and simpler a pull
request system would have on this process but it is not up and running at the
moment.

I only addressed the RSB with this post and it was done with the agreement of
Joel and Gedare. I did not just make the decision myself. We would like more
detail in some commit messages and a review may be a way to handle that.

Chris



Thanks for the clarification.

Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd development policy clarification needed?

2023-02-03 Thread oss

Hello Gedare,

Am 03.02.23 um 19:51 schrieb Gedare Bloom:

On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER
wrote:

Hello Karel,

On 2023-02-02 12:43, Karel Gardas wrote:

Guys,

recently I needed to work with RTEMS/NFS. As this is provided by libbsd
I took this and following two sentences below from master branch
description provided in README I took as granted that master does have
all the features which are currently available and provided by the project:

"This branch must be used for libbsd development. Back ports to the
6-freebsd-12 are allowed."

I was surprised to be proven wrong then by Fabrizio here:
https://devel.rtems.org/ticket/4723

and by later investigation which shows that 6-freebsd-12 branch
accumulated NFS work by Chris done in 2021 which is not presented on
master. I've investigated just NFS as this was my focus here.

So if 6-freebsd-12 became development branch of some sort, then it would
be great to have that clarified in the project README file to prevent
users confusion? Or if the policy is still the same, then perhaps some
branch sync is needed here?

That currently is an open issue. Basically there is a pending patch set
that should fix that since several months. But there is a disagreement
about some of the changes in that patch set (and about the patches
checked in to 6-freebsd-12). Therefore, it still hasn't been merged.

If you want to know some more about the problematic points, I recommend
reading this (long) thread:

https://lists.rtems.org/pipermail/devel/2023-January/074164.html

The statement that development has to happen on the master branch is
still true. The master is intended to track the FreeBSD upstream
development. Only changes on that branch are guaranteed to live through
an upgrade to a newer base version of FreeBSD. It's very unfortunate,
that there are some patches on the 6-freebsd-12 branch only. On the long
term, that issue has to be resolved.

I have been investigating this problem in the background, and I have
some findings and some questions. First, I have found that there is a
most-common ancestor between master and 6-freebsd-12 at commit
https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976
This is at least promising that the discrepancy between the branches
can be resolved.

The proposed pending patch set to "fix" the NFS issue does not fix the
underlying problem. Instead, it introduces further divergence between
the branches. I would instead suggest that we should resolve to fix
the underlying problem. I can see two paths forward.

1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal
since what I understand is some users have projects based on
6-freebsd-12 and would like an upgrade path. (I guess there is also
the option to abandon master, which also makes little sense.)

A variant for this would be to introduce a 6-freebsd-13 that is based on
the master branch as soon as we have one. That would allow a longer
maintenance because FreeBSD 12 reaches it's EoL December 2023.

2. Pull commits from 6-freebsd-12 into master to make sure master is
the development head. in the future, reject patches that only go
toward release branches. This has its own problems too. It can
realistically only be done in three ways:

Please note that Sebastian mentioned that the file descriptors broke the
NTP support (at least I think it was NTP; possible that it was another
submodule). So picking the current version of the patches into the
master without adding fixes makes the master unusable for some cases.

2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master
back into master. This rewrites the history of master, and
unfortunately will cause the head of 5-freebsd-12 and the tags for
rtems-5 to no longer exist on the master branch. They will still exist
in the '5' branch. The advantage is in the end there will be a linear
history of development on master that reflects the timeline of actual
development that spanned both branches. Theoretically, this should
make it easier to git-bisect.

2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts.
This puts all the missing commits from 6-freebsd-12 on to the current
head of master. I don't know how messy this would be. It ends up
making the history of master convoluted to understand, with fairly old
commits from 2018 being placed on top of newer commits from 2020s.

2c: Merge 6-freebsd-12 into master and fixup conflicts in the merge
commit. This is pretty similar to 2a but ends up with a non-linear
history and a merge commit. It may be a fairly complex merge commit.

For all of the 2x solutions: The commits from 6-freebsd-12 can't just be
cherry-picked. You have to re-import the NFS files from the FreeBSD
master version that is used as base for the current libbsd master.
Otherwise we mix different FreeBSD source versions. We had that some
time back in libbsd and Sebastian needed a lot of time cleaning

Re: [PATCH rtems 6/6] bsps/imxrt: Add imxrt1166_cm7_saltshaker BSP

2023-07-17 Thread oss


Hello Jacob,

Am 14.07.23 um 09:08 schrieb Christian MAUDERER:

Hello Jacob,

On 2023-07-14 08:36, Christian MAUDERER wrote:

Hello Jacob,

On 2023-07-13 18:59, Jacob Killelea wrote:

Hi Christian,

This looks awesome! Do you have any interest in adding support for 
the i.MXRT1062 based Teensy 4.0 and Teensy 4.1?


- Jacob


the Teensy look like interesting boards. Maybe a bit low on memory. 
That would make it difficult to run libbsd on them. The boards don't 
have network, so it's not a problem for the network part. But on the 
i.MXRT, I also use the MMC/SD stack from libbsd so the SD card would 
be a problem.




Just noted: The Teensy 4.1 has an optional Ethernet. So some network 
library would be good. But like I said: The target has too few memory 
for libbsd. lwIP would be a candidate. But I haven't tried that on the 
i.MXRT yet.


Best regards

Christian


It was mean from you to point me to that board. It seems like an 
interesting challenge ;)


I've thrown together a quick prototype for a BSP. It's not yet tested. 
It doesn't even link the tests yet, because the linker command file 
isn't adapted yet. But the BSP sources at least compile without problems:


  https://gitlab.com/c-mauderer/rtems/-/tree/cm/20230717_teensy41

If I find some more time and maybe some hardware, I maybe continue to 
try to write the linker command file. But I don't promise anything ;-)


Best regards

Christian



On the Teensy 4.1, the two memories (optional Flash and optional 
PSRAM) on the FlexSPI maybe can be a bit tricky.


These boards would be pure hobby time. I don't think that I will find 
enough time to fully support the boards at the moment. But I would 
expect that the basics should work with the i.MXRT1052 BSP already. 
The 1050 and 1060 family is quite similar. If you want, I can give you 
some guidance what would be necessary to support the boards.


Best regards

Christian



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Discussion: How to handle HALs, SDKs and libraries

2023-07-16 Thread oss


Hello Karel,

Am 15.07.23 um 19:22 schrieb Karel Gardas:

On 7/15/23 16:00, o...@c-mauderer.de wrote:
We should avoid rebasing and overwriting the old branch because we 
have to preserve a version that can be used with older RTEMS versions. 
So for rebasing, we would have to use multiple branches. Instead of 
rtems-6-branch, it could be a rtems- or 
something similar.


Thanks for confirmation. Have the same feeling about it.

I think that depends heavily on how the upstream project works. If the 
upstream project uses a typical git workflow and is quite active, 
merging is most likely the better solution because we don't get big 
amounts of branches with that.


But this means we still merge to some rtems specific branch since master 
is used to sync with upstream, right?




Yes. That would be my suggested workflow: Track the upstream master or 
main branch and merge it into an RTEMS specific one.


On the other hand I know that some semiconductor manufacturers tend to 
just dump code into a repo and they don't care whether files move 
around or change heavily. They happily mix changes with reformatting 
the complete code. In that case you have no chance of a useful 
merge-commit. I think in these cases it's most likely better to create 
a new branch on every update and rebase the patches.




Anyway, still this is a branch based workflow. How would you do that 
workflow with just fixed commit IDs?


I'm asking since so far commit IDs on submodules were always obtain 
from master branch which is what we basically fork and does not give 
us ability to patch with RTEMS changes...


So I'm curious how would you do that?


I think I have put that in the wrong words. I assumed you mean that 
you want to use some feature that always uses the latest commit of a 
branch (also I don't know whether git even has that feature).


What I wanted to say is that if I check out a RTEMS version from two 
months back, it should check out the revisions of the submodules that 
have been used in RTEMS two months back too. It must not use the 
latest HEAD of the branch from today. It's just part of having a 
version of the code that can be reproduced later.


Right! Now crucial question: is that even supported in git? I'm asking 
since so far I've seen only:


- use fixed commit ids, but those are obtained only from master branch
or
- use branch and then this is always branch HEAD

I've not seen anything like "use fixed commit ID from branch XXX". So 
question for you as an git expert: are you absolutely sure that this 
workflow is supported by git at all? And by this I mean have you tested 
that actually? :-)


I know only of the method that git uses a fixed commit ID in a 
submodule. It expects that the commit ID is on some branch in the remote 
repository. In my experience, it's not relevant whether the commit is on 
the branch `main`, `master`, `foo-bar`, `my-cool-new-feature` or any 
other branch. And yes: I use that regularly.


Additionally, git support adding an optional "branch" parameter to each 
submodule. But as far as I know, that is only used during


  git submodule update --remote

which basically tells git to pull the latest version of the branch 
instead of a special commit ID. I usually don't use that.


See https://stackoverflow.com/a/18797720 for a better explanation.



Of course the revision from two months back has to be available in the 
repo. It doesn't really matter whether it's on master because the code 
just worked or whether it's a RTEMS specific branch because adaptions 
have been necessary.


You "it doesn't really matter" worries me a little bit. I'm not sure 
this functionality is even supported hence my question above if you have 
tested it yourself.


Yes, I use that regularly. For an (old) example, take a look at a branch 
in the repo that I use to test GSoC work:


  https://gitlab.com/c-mauderer/rtems-bbb/-/tree/6

I have a libs/rtems-libbsd submodule there that uses the revision 
c9474c0b which is on a cm/20200726_fix branch in my clone of 
rtems-libbsd. In the .gitmodules the branch is still set to "master". 
Despite that, git can find thre right commit ID.


Best regards

Christian



Thanks!
Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Westernization of RTEMS/stm32H7 [was: Re: Discussion: How to handle HALs, SDKs and libraries]

2023-07-16 Thread oss


Hello Karel,

Am 16.07.23 um 00:07 schrieb Karel Gardas:


   Hello,

Christian mentioned Zephyr west tool as one of good/possible candidates 
for RTEMS tree modularization especially with regarding to HALs and 
other 3rd party libraries.


I mentioned it as one of three tools that I know that solve similar 
problems (Google `repo` from Android, `west` from Zephyr and the feeds 
from OpenWRT). And clearly I haven't made clear enough what my goal was:


I don't want to suggest that we jump on a random tool and use that. What 
I wanted is that we take a look at the reasons why the tools exist and 
evaluate whether we - as RTEMS project - have similar problems that have 
been solved with the tool. You wanted to avoid the academic debate in an 
earlier mail, so I didn't start to go into more details of every reason. 
But now there is a second prototype with a different tool so most likely 
we have to compare some more.


West has the best documentation why they created that tool:

  https://docs.zephyrproject.org/latest/develop/west/why.html

R1. Keeping code out of the main repo. That has advantages and 
disadvantages. And I'm not sure what's more important. Main advantage is 
that it makes more clear what is RTEMS and what is some external source. 
 Main disadvantage is most likely that it is a bit more difficult to 
integrate it into the release process. If it's only one repo, the 
release will be to check out the submodules and archive everything as 
one big file. With multiple separate repos, we have to create one file 
for every repo. Additionally, a user has to download all archives to 
build the release version. So most likely that adds complexity.


R2. Tool, that users can use. Depends quite heavily on the workflow and 
use case of the user. RTEMS has a tendency to not adopt new tools 
easily, especially if they have to be used by the end user. So that 
could be a disadvantage.


R3. Allow to override repos in custom distributions. Not sure whether 
that is useful for us as a project.


R4. Continuous tracking of a HEAD or commit-based tracking. Git does the 
commit-based tracking and I already said that I wouldn't be happy about 
continuous tracking of a branch. So that wouldn't be a reason for me.


From my point of view, what we can learn from that tool is two things:

A) We should take a look whether putting the code in the repo is a 
disadvantage in some situations. I think size of releases and licenses 
could be two. Licenses can be most likely solved with a clear directory 
structure where external libs are in one subdirectory with a good 
description.


B) Do we need to support use cases, where a user wants to replace one 
submodule version by another version without having to create a private 
fork of RTEMS?


C) Do we need to support use cases where we don't want to track fixed 
commit IDs but the HEAD of a branch instead?



For Google repo, I didn't find the original reasons. What I did find are 
some comparisons with submodules like 
https://www.edureka.co/blog/git-submodules-versus-googles-repo-tool


Sounds like the main intention is to make working with multiple repos 
simpler and integrate well with Gerrit and Jenkins. Beneath that, they 
heavily support tracking HEADs of branches.


Main point to learn:

Again: C)

D) We should be careful how we handle submodules so that the usage is as 
simple as possible. So that's part of how we integrate it in our build 
system.


E) We maybe can get problems on a future CI/CD integration.


The OpenWRT Feeds: https://openwrt.org/docs/guide-developer/feeds

I think the main reason why they use that are:

1. Allow to track a HEAD of a branch instead of a certain commit ID. Not 
something that I would want for HALs.


2. Allow a user to add additional feeds. That's similar to the point 3 
of `west`.


I think the main point to learn is basically the same as B) and C).

Best regards

Christian




For comparison with my previous git submodulization of RTEMS/stm32H7 
I've also westernized the same in a similar way. Yes, it is intended to 
remove CMSIS v4 *just* to proof compilation is working with CMSIS 5 from 
outside module! This is just dirty PoC nothing more. A tree structure 
looks a bit different as (folowing zephyr example) I keep modules 
outside the rtems tree. Hence result for west init command below is tree:


modules/hal/stm32h7/stm32h7xx_hal_driver
modules/hal/stm32h7/cmsis_device_h7
modules/hal/stm32h7/CMSIS_5
rtems/...


So if you like to see thing, then install west:

$ pip3 install --user west
$ export PATH=$PATH:$HOME/.local/bin

go into some testing directory and:

$ west init -m https://github.com/karelfv/rtems --mr 
rtems-west-stm32h7-hal rtems-workspace


$ cd rtems-workspace/
$ west update

Compilation again produces working samples. In comparison with git 
submodule approach I find west a bit more civilized (user friendly). 
Nothing is shooting in my own feet etc.


What may resonate in RTEMS devs is:

- yaml format for

Re: Discussion: How to handle HALs, SDKs and libraries

2023-07-16 Thread oss


Hello Karel,

Am 16.07.23 um 12:37 schrieb Karel Gardas:

On 7/16/23 10:03, o...@c-mauderer.de wrote:
Of course the revision from two months back has to be available in 
the repo. It doesn't really matter whether it's on master because 
the code just worked or whether it's a RTEMS specific branch because 
adaptions have been necessary.


You "it doesn't really matter" worries me a little bit. I'm not sure 
this functionality is even supported hence my question above if you 
have tested it yourself.


Yes, I use that regularly. For an (old) example, take a look at a 
branch in the repo that I use to test GSoC work:


   https://gitlab.com/c-mauderer/rtems-bbb/-/tree/6

I have a libs/rtems-libbsd submodule there that uses the revision 
c9474c0b which is on a cm/20200726_fix branch in my clone of 
rtems-libbsd. In the .gitmodules the branch is still set to "master". 
Despite that, git can find thre right commit ID.


Cool! So it didn't work for me due to (i) my git bug or (ii) my git 
doesn't supporting whatever or simply due to (iii) me making silly 
mistake somewhere.


Will need to recheck this. Thanks for the info!

Karel




Seems that we are not the only ones with a waf based build system that 
want to manipulate submodules:


https://github.com/ArduPilot/ardupilot/pull/3592

The final solution seems to be a bit different. Their wscript in the 
latest version has a "--no-submodule-update" parameter. So they decided 
to just update the submodules every time. Can be interesting for users 
because they don't have to care for outdated submodules if they pull a 
new version.


But I think the problem with adding it as a fixed step is, that we have 
a problem with the releases. A release tar ball is not a git repo 
anymore. So a "git submodule init --update" or similar will not work. We 
would need some mechanism to detect whether it's a git repo or not.


Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Discussion: How to handle HALs, SDKs and libraries

2023-07-15 Thread oss

Hello Karel,

thanks for trying that. I wouldn't object to add it to 6 but I wouldn't
expect it either because it means a lot of adaptions to the release
scripts. Chris most likely can tell you more about whether it's even
thinkable at that point in the release cycle or not.

Am 15.07.23 um 01:48 schrieb Karel Gardas:

Hello,

I've created setup where I've put updated STM32H7 HAL consisting of two
submodules:

- stm32h7xx_hal_driver
- cmsis_device_h7

and ARM's

- CMSIS_5

into hals/arm/stm32h7 to follow related BSP code location.

I think I would prefer "contrib/hals", "external/hals" or some other
more generic top directory name. It would allow to use that for other
parts like for example zlib in "contrib/libs/zlib" in the future (if we
agree on having libs like that there too).

At the moment, you have absolute URLs for your submodules:

url = https://github.com/ARM-software/CMSIS_5.git
url = https://github.com/karelfv/stm32h7xx_hal_driver.git
url = https://github.com/karelfv/cmsis_device_h7.git

If we use submodules, I would go for relative paths and clone the
repositories to our git.rtems.org and to all mirrors. It has the
advantage that even if some upstream URL changes, we won't be affected.

I like submodules because they are well-supported by the usual tools.
Nonetheless, we should take a look at some of the reasons why other
projects decided against them. For example Google has the "repo" tool
used in Android. Zephyr has the "west" tool. OpenWRT uses "feeds" for
something similar. I'm sure there are more.

https://gerrit.googlesource.com/git-repo/
https://docs.zephyrproject.org/latest/develop/west/why.html#
https://openwrt.org/docs/guide-developer/feeds

All solve a similar problem. Part of them even overlap already with
functionality from our waf based build system. We should consider
whether we need any of the functionality of these tools and whether we
want to re-implement it or whether we just want to use one of the tools
and integrate with it.

I've also completely removed HAL code from the BSP directory and also
CMSIS v4 files from bsps/arm/include to verify compilation is really
using submodules.

I think the CMSIS headers are used by some other BSPs too. So that's
fine for a prototype. But for the final solution, we need something
different.

If you like to see how this is looking, just:

$ git clone https://github.com/karelfv/rtems.git rtems
$ cd rtems
$ git checkout rtems-stm32h7-hal-git-submodules
$ git submodule update --init

And see bsps/arm/stm32h7/ and hals/arm/stm32h7/ and bsps/arm/include
subdirectories.

You can also compile if you have arm tools:

$ ./waf bspdefaults --rtems-bsps=arm/stm32h757i-eval > stm32h757i-eval.ini
$ ./waf configure --rtems-bsps=arm/stm32h757i-eval
--rtems-config=./stm32h757i-eval.ini --rtems-tools=
--prefix=

$ ./waf

CAVEAT: only STM32H757i-eval BSP is supported and only compilation.
Installation is not supported yet.

Note: HAL is updated to latest STMicro code and all related changes done
in the past by Sebastian and Christian are merged into submodules
projects except Doxygen tag change done by Sebastian. This is to be
discussed topic if doxygen changes belongs to submodule or are not
needed anymore...

I agree that the doxygen shouldn't be necessary any more. But we should
make sure that our Doxyfile doesn't pick up the submodules. So that
would need some of the EXCLUDE* options set to the path of the submodules.

Best regards

Christian

hello.exe/ticker.exe/paranoia.exe runs fine.

Comments welcome!

Karel

On 7/14/23 13:53, Karel Gardas wrote:

Hello,

are we really that close to RTEMS 6 release that none of this is
acceptable to do now?

Asking since I'd also like to update stm32h7 HAL. I may do that
manually or I may do that submodule way which may perhaps save some of
the manual work involved as some of the patches may not be needed
anymore. It depends on resolution to following questions:

- stm32h7 hal contains Sebastian's modification/additions of Doxygen
tags. Do we need to preserve that in the submodule? I guess not, but
I'm not sure and this question of Doxygen markups was not solved in
this thread yet AFAIK.

- all ARMs HALs probably also depends on particular version of CMSIS
files, so I guess we should use separate submodules of CMSIS per HAL.
At least STM recommends that:
https://htmlpreview.github.io/?https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Release_Notes.html -- this would certainly be improvement in comparison with current state of the art besides update of CMSIS alone we would also support manufacture tested CMSIS version for their HAL...

- where to put submodules? What is preferred location? For stm32h7 case!
(i) hals/arm/stm32h7
or
(ii) deps/arm/stm32h7
or
(iii) contrib/arm/stm32h7
or
(iv) anything else preferred?

I may do stm32h7 hal + its CMSIS dependency now (or next week), but
only if the chance

Re: Discussion: How to handle HALs, SDKs and libraries

2023-07-15 Thread oss


Hello Karel,

Am 15.07.23 um 12:17 schrieb Karel Gardas:

On 7/15/23 09:47, o...@c-mauderer.de wrote:

Am 15.07.23 um 01:48 schrieb Karel Gardas:


  Hello,

I've created setup where I've put updated STM32H7 HAL consisting of 
two submodules:


- stm32h7xx_hal_driver
- cmsis_device_h7

and ARM's

- CMSIS_5

into hals/arm/stm32h7 to follow related BSP code location.


I think I would prefer "contrib/hals", "external/hals" or some other 
more generic top directory name. It would allow to use that for other 
parts like for example zlib in "contrib/libs/zlib" in the future (if 
we agree on having libs like that there too).


Indeed, name is not the problem here. Both looks fine, somewhat prefer 
external a bit.



At the moment, you have absolute URLs for your submodules:

   url = https://github.com/ARM-software/CMSIS_5.git
   url = https://github.com/karelfv/stm32h7xx_hal_driver.git
   url = https://github.com/karelfv/cmsis_device_h7.git

If we use submodules, I would go for relative paths and clone the 
repositories to our git.rtems.org and to all mirrors. It has the 
advantage that even if some upstream URL changes, we won't be affected.


This is dirty PoC not a final solution. Due to this I've settled on 
absolute urls and not relative. For final solution relative are needed, 
but both url (relative/abolute) and name/location in RTEMS tree is very 
easy to change based on decision.


I like submodules because they are well-supported by the usual tools. 


Honestly. I like submodules idea, but hate its implementation. Some 
reasons:


- submodules were added as a light weight feature and during the 
development of git/submodule feature they accumulated some more.


- submodules started as way to get commit id of the external project to 
the tree. But only master branch was supported. (not suitable for RTEMS)


- later submodules added capability to use tag (still not suitable for 
RTEMS)


- later submodules added capability to use different branch from the 
project, but only a head of it. (finally what RTEMS need).


I don't like using branches instead of fixed commit IDs. Otherwise, it's 
not possible to reliable re-build a fixed version.




- in the field you can see gits supporting different sets of submodule 
features described above.




Yes, it will force us to use a minimum git version that supports the 
necessary features. From my point of view, it's mainly something we 
should document.


- submodules are easy to be broken. Personal experience from Haskell 
compiler (GHC) project which uses submodules a lot. I have git 2.25 and 
I always have an issue to pull from GHC repo since alwyas for me one 
submodule (when changed) will be broken for me. Conclusion: clone with 
submodules may kind of work, but later pull may be tricky.




Agreed: It's easy to miss that a submodule is out of date.

- besides submodules are not supported in 'got' which is 3rd party 
independent implementation of git like SCM with more sane UI




I would say that this is a problem of the third-party client. We should 
make sure to support the official git client. Maybe additionally some 
(python?) git library if it is necessary for our tools.


- due to submodules trickiness development policy for external 
integration with project code modification (aka HAL patches) needs to be 
very well written. I smell horrible increase in cognitive load here...


Nonetheless, we should take a look at some of the reasons why other 
projects decided against them. For example Google has the "repo" tool 
used in Android. Zephyr has the "west" tool. OpenWRT uses "feeds" for 
something similar. I'm sure there are more.


   https://gerrit.googlesource.com/git-repo/
   https://docs.zephyrproject.org/latest/develop/west/why.html#
   https://openwrt.org/docs/guide-developer/feeds

All solve a similar problem. Part of them even overlap already with 
functionality from our waf based build system. We should consider 
whether we need any of the functionality of these tools and whether we 
want to re-implement it or whether we just want to use one of the 
tools and integrate with it.


Oh, do I sense starting academic debate now? The point of my dirty PoC 
was to ground that a bit and show real stuff to get a feel of 
possibilities.




I think the Proof of Concept is great and important. Thanks for doing 
it. I'm fully OK with submodules as a general direction. I just wanted 
to point out that we should take at least a short look at other systems 
that solve similar problems. If they work around serious limitations of 
submodules we can learn from them and avoid that we hit the same 
limitations.


I used submodules myself in a lot of cases. And there are mainly two 
problems that I have:


1. I often miss pushing a submodule when I push the base repo. And I 
only note it way later if I try to update the repo on another PC. That 
happened to me multiple times when working with submodules. But another 
tool will just have other problems so

Re: Discussion: How to handle HALs, SDKs and libraries

2023-07-15 Thread oss


Hello Karel,

Am 15.07.23 um 15:03 schrieb Karel Gardas:

On 7/15/23 14:33, o...@c-mauderer.de wrote:
I like submodules because they are well-supported by the usual tools. 


Honestly. I like submodules idea, but hate its implementation. Some 
reasons:


- submodules were added as a light weight feature and during the 
development of git/submodule feature they accumulated some more.


- submodules started as way to get commit id of the external project 
to the tree. But only master branch was supported. (not suitable for 
RTEMS)


- later submodules added capability to use tag (still not suitable 
for RTEMS)


- later submodules added capability to use different branch from the 
project, but only a head of it. (finally what RTEMS need).


I don't like using branches instead of fixed commit IDs. Otherwise, 
it's not possible to reliable re-build a fixed version.


And this is most important detail, so let's discuss this alone.


OK.



I have a hal library, let's consider this to be 
https://github.com/karelfv/stm32h7xx_hal_driver -- just one project for 
now.


This is a fork of ST Micro project of the same name which is a slow 
development project. Few accumulated commits over one year let say.


This project needs few RTEMS related patches and there is a chance they 
also need to kind of adapt to the new development. So let's branch as:


- master branch -- this is fork of ST Micro
- rtems-6-branch -- this is a branch from master at one point of time 
accumulating RTEMS related changes.


Now, let's assume this was done 6 months ago and now you would like to 
update from ST Micro upstream. How would you do that? I see:


- git fetch upstream inside the master
- git push master

that's update of master in fork and now:

- pull/merge master
or
- rebase master

in the rtems-6-branch? I'm afraid rebase is dangerous in shared setup so 
probably pull/merge?


We should avoid rebasing and overwriting the old branch because we have 
to preserve a version that can be used with older RTEMS versions. So for 
rebasing, we would have to use multiple branches. Instead of 
rtems-6-branch, it could be a rtems- or something 
similar.


I think that depends heavily on how the upstream project works. If the 
upstream project uses a typical git workflow and is quite active, 
merging is most likely the better solution because we don't get big 
amounts of branches with that.


On the other hand I know that some semiconductor manufacturers tend to 
just dump code into a repo and they don't care whether files move around 
or change heavily. They happily mix changes with reformatting the 
complete code. In that case you have no chance of a useful merge-commit. 
I think in these cases it's most likely better to create a new branch on 
every update and rebase the patches.




Anyway, still this is a branch based workflow. How would you do that 
workflow with just fixed commit IDs?


I'm asking since so far commit IDs on submodules were always obtain from 
master branch which is what we basically fork and does not give us 
ability to patch with RTEMS changes...


So I'm curious how would you do that?


I think I have put that in the wrong words. I assumed you mean that you 
want to use some feature that always uses the latest commit of a branch 
(also I don't know whether git even has that feature).


What I wanted to say is that if I check out a RTEMS version from two 
months back, it should check out the revisions of the submodules that 
have been used in RTEMS two months back too. It must not use the latest 
HEAD of the branch from today. It's just part of having a version of the 
code that can be reproduced later.


Of course the revision from two months back has to be available in the 
repo. It doesn't really matter whether it's on master because the code 
just worked or whether it's a RTEMS specific branch because adaptions 
have been necessary.


Best regards

Christian



Thanks!
Karel



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

2023-05-05 Thread oss


Hello Gedare,

thanks for taking a look at the patch set.

Am 05.05.23 um 15:56 schrieb Gedare Bloom:

On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
 wrote:


Hello,

this patch set for the arm/imxrt BSP family updates the SDK files to the
latest version of the mcux-sdk from NXP and prepares the BSP for further
chip variants. I plan to add a BSP that uses the IMXRT1166 soon.

As a base for the mcux-sdk files, I now use the NXP git repository
instead of zip files that can be downloaded from NXP. I kept the exact
file system structure to make future updates simpler.

To import the files, I used a script. It is not a clean script and it
was only tested on a Linux machine. Despite that, I added that script to
the BSP directory in case someone else ever wants to update the
mcux-sdk. Updating the SDK is also possible without the script. It's
just a lot more manual work. So if we don't want a script in that state
in the repository, I can also just keep it on a private branch.


I would recommend that you document the import/update process for the
SDK in this BSP (or family) documentation. You could provide a stable
external link to the script there instead of including it in the
rtems.git tree. I'm not convinced that including scripts etc in the
same tree as the source they manipulate is a great practice. It seems
to violate separation of concerns.


Disadvantage is that the script (and documentation) is a bit less simple 
to find. But that's not a problem for me (I know where to search) so I 
will adapt that.


De we have an official preferred stable location? Otherwise, I think 
either a small repo in my https://git.rtems.org/christianm or a repo on 
github should be a good place (most likely the later one).





The patches that import the new SDK files (patch 0002) and remove the
old ones (patch 0004) are too big for the list. I'll only send the
summary. You can find the full patches here:

   0002: 
https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
   0004: 
https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d

The complete patch set is on this branch:

   https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/

At the moment, I import the support files for all currently available
i.MXRT* variants. The headers for the CPU registers are really big (a
few megabytes per header) which makes the complete source tree of the
mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
only keep the ones that are currently used or will be used soon
(IMXRT1052 and IMXRT1166) to reduce the size.


Thanks, I think this is fine. The increase in the number of HAL/SDK
that we have to import is starting to concern me in general. I wonder
if there is a better way to manage these external sources.



I think I have a language problem here: Is it fine that I push 96MB or 
is it fine that I reduce the size of the patch before pushing?


In this case I only updated the existing HAL with more chips, but I 
agree that having a better solution to manage HALs than the 
clone-and-own approach would be great.


One possible solutions could be to use subrepos. We can clone the lib to 
the git.rtems.org, add necessary patches and add that as a subrepo. If 
an update is necessary, patches can just be rebased on the latest 
version of the upstream lib. Another one could be something like the 
west tool that is used in Zephyr. Maybe can also make it simpler to 
include libs with vendor specific licenses.


But approaches like that will have a big impact on how to handle a lot 
of tasks in RTEMS. For example you would have to init submodules before 
building BSPs. The submodules have to be handled during release. And a 
lot more. So we shouldn't discuss that as a side note to a patch set but 
rather as a new mail thread.


Best regards

Christian


Best regards

Christian


___
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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

2023-05-15 Thread oss


Hello Chris,

Am 15.05.23 um 05:18 schrieb Chris Johns:



On 6/5/2023 2:02 am, Gedare Bloom wrote:

On Fri, May 5, 2023 at 9:02 AM  wrote:


Hello Gedare,

thanks for taking a look at the patch set.

Am 05.05.23 um 15:56 schrieb Gedare Bloom:

On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
 wrote:


Hello,

this patch set for the arm/imxrt BSP family updates the SDK files to the
latest version of the mcux-sdk from NXP and prepares the BSP for further
chip variants. I plan to add a BSP that uses the IMXRT1166 soon.

As a base for the mcux-sdk files, I now use the NXP git repository
instead of zip files that can be downloaded from NXP. I kept the exact
file system structure to make future updates simpler.

To import the files, I used a script. It is not a clean script and it
was only tested on a Linux machine. Despite that, I added that script to
the BSP directory in case someone else ever wants to update the
mcux-sdk. Updating the SDK is also possible without the script. It's
just a lot more manual work. So if we don't want a script in that state
in the repository, I can also just keep it on a private branch.


I would recommend that you document the import/update process for the
SDK in this BSP (or family) documentation. You could provide a stable
external link to the script there instead of including it in the
rtems.git tree. I'm not convinced that including scripts etc in the
same tree as the source they manipulate is a great practice. It seems
to violate separation of concerns.


Disadvantage is that the script (and documentation) is a bit less simple
to find. But that's not a problem for me (I know where to search) so I
will adapt that.

De we have an official preferred stable location? Otherwise, I think
either a small repo in my https://git.rtems.org/christianm or a repo on
github should be a good place (most likely the later one).


This should be fine. ftp.rtems.org should also be usable (in theory)




The patches that import the new SDK files (patch 0002) and remove the
old ones (patch 0004) are too big for the list. I'll only send the
summary. You can find the full patches here:

0002: 
https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
0004: 
https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d

The complete patch set is on this branch:

https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/

At the moment, I import the support files for all currently available
i.MXRT* variants. The headers for the CPU registers are really big (a
few megabytes per header) which makes the complete source tree of the
mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
only keep the ones that are currently used or will be used soon
(IMXRT1052 and IMXRT1166) to reduce the size.


Thanks, I think this is fine. The increase in the number of HAL/SDK
that we have to import is starting to concern me in general. I wonder
if there is a better way to manage these external sources.



I think I have a language problem here: Is it fine that I push 96MB or
is it fine that I reduce the size of the patch before pushing?


My apologies, I missed this also. If it's not that much more work, it
might be best to remove the unused variants. We don't like to carry
around dead code in the repo as another general rule.


In this case I only updated the existing HAL with more chips, but I
agree that having a better solution to manage HALs than the
clone-and-own approach would be great.

One possible solutions could be to use subrepos. We can clone the lib to
the git.rtems.org, add necessary patches and add that as a subrepo. If
an update is necessary, patches can just be rebased on the latest
version of the upstream lib. Another one could be something like the
west tool that is used in Zephyr. Maybe can also make it simpler to
include libs with vendor specific licenses.

But approaches like that will have a big impact on how to handle a lot
of tasks in RTEMS. For example you would have to init submodules before
building BSPs. The submodules have to be handled during release. And a
lot more. So we shouldn't discuss that as a side note to a patch set but
rather as a new mail thread.


Agreed.


Do these HAL systems provide stable API interfaces? If so is all RTEMS needs to
interface to is the API headers?

Chris



I think that depends a lot on the vendor. In my experience, the better 
HALs are mostly stable. For example, I don't think that the ST HAL 
changed the API in the versions that I know. And during the update of 
the NXP SDK I didn't note a breaking API change either. Only addition of 
new functions.


The HAL provides basic drivers. For example in the i.MXRT BSP I use it 
for stuff like setting up clocks or adding drivers like serial, I2C or 
SPI. I expect that at least some drivers are necessary to link every 
program. So without the HAL, the test suite wouldn't build. As far as I 
know that would be something new

37 matches

Mail list logo