Re: We are loosing patches

On 10/9/20 1:04 am, Thomas Doerfler wrote: > > just a brief note from holidays: Great to hear. Enjoy yourselves. > Am 09.09.20 um 15:19 schrieb Joel Sherrill: > >> All system administration on rtems.org is volunteer.  >> That by itself is the >> biggest barrier. > > We've t

Re: [PATCH v1 2/6] waf: Add path-mappings feature

On 15/8/20 5:57 am, Jan Sommer wrote: > - path-mappings allow to fix autogenerated include paths for some corner > cases of target platforms without the need to change the build system > - Currently used for i386 based bsps I will need to take in this patch into my development libbsd branchs and m

Re: Determining Linux Distribution

On 10/9/20 8:15 am, Joel Sherrill wrote: > On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas > wrote: > > On 9/9/20 11:03 PM, Karel Gardas wrote: > > so Debian, Kali and OpenSuSE at least are not well handled by this > > script and it's quite fun since simple

Re: Determining Linux Distribution

On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas wrote: > On 9/9/20 11:03 PM, Karel Gardas wrote: > > so Debian, Kali and OpenSuSE at least are not well handled by this > > script and it's quite fun since simple: > > Can't judge author of the script. The post is from 2008! So I guess > /etc/os-release

Re: Determining Linux Distribution

On 9/9/20 11:03 PM, Karel Gardas wrote: > so Debian, Kali and OpenSuSE at least are not well handled by this > script and it's quite fun since simple: Can't judge author of the script. The post is from 2008! So I guess /etc/os-release was not so wide spread among the Linuxes at that time... __

Re: Determining Linux Distribution

On 9/9/20 10:30 PM, Joel Sherrill wrote: > It reports CentOS 7 as "centos" Ubuntu 18.04 -> Ubuntu and now in linux containers (if you are curious, but I would bet you get the same result on local installed system too): Ubuntu 20.04 -> Ubuntu CentOS 8 -> centos Debian 10 -> os OpenSUSE 15.2 -> os

Determining Linux Distribution

Hi Chris mentioned this and then the thread moved on. Based on reading a few pages, each distribution has its own place to state the distribution name. Which makes the problem a bit recursive. But some nice soul put together a shell script which is supposed to identify the distribution. https://

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

Can this be pushed upstream in a non-RTEMS specific way? On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer wrote: > > Some bits are in the wrong order. Beneath that, the interrupts can occur > in an unexpected order. The DATA_AVAIL interrupt can occur at the same > time as the DMA interrupt (or s

Re: We are loosing patches

On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer wrote: > > Hello Jan and Joel, > > On 09/09/2020 15:19, Joel Sherrill wrote: > > > > > > On Wed, Sep 9, 2020 at 3:43 AM > > wrote: > > > > I would like this idea. > > We got Gitlab this year and collaboration with

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On Wed, Sep 9, 2020 at 2:16 AM Chris Johns wrote: > > On 9/9/20 4:55 pm, jan.som...@dlr.de wrote: > > Hi Chris, > > > >> -Original Message- > >> From: Chris Johns > >> Sent: Friday, August 14, 2020 11:43 PM > >> To: Sommer, Jan ; devel@rtems.org > >> Subject: Re: [PATCH v1 0/6] [libbsd] F

Re: We are loosing patches

Hi Joe, just a brief note from holidays: Am 09.09.20 um 15:19 schrieb Joel Sherrill: > All system administration on rtems.org is volunteer.  > That by itself is the > biggest barrier. We've talked collecting funds through a foundation. How can we push that to at least partly

Re: Error while running rtems-test

Sorry for the late reply. My university tests are going to come up really soon and I have to make up for stuff I missed early on :p Did you build with --enable-tests? I do not remember. I am going to make the bsp from the beginning again. Are there *.exe files in ~/quick-start/build/b-smp-leon3

Re: We are loosing patches

Hello Jan and Joel, On 09/09/2020 15:19, Joel Sherrill wrote: > > > On Wed, Sep 9, 2020 at 3:43 AM > wrote: > > I would like this idea. > We got Gitlab this year and collaboration with it is pretty convenient. > They also seem to hand out free licenses for

Re: We are loosing patches

On Wed, Sep 9, 2020 at 3:43 AM wrote: > I would like this idea. > We got Gitlab this year and collaboration with it is pretty convenient. > They also seem to hand out free licenses for OSS projects. > I guess installing and maintaining an instance is probably quite some work. > We use Gitlab com

Re: BSP Test Results

On 09/09/2020 02:29, Chris Johns wrote: [...] > >> > Also I am not sure but hopefully the test reports do accurately reflect >> host OS. >> >> There is a "Host" section at the top of the results log? It is just >> `uname -a`. >> >> I think that's sufficient as long as it can distingui

[PATCH rtems-libbsd 2/2] imx: Remove ccm functions alredy defined in RTEMS

The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in libbsd. Otherwise some applications get linker errors. Update #3869 --- freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c b/freebsd/sys/arm/

[PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

Some bits are in the wrong order. Beneath that, the interrupts can occur in an unexpected order. The DATA_AVAIL interrupt can occur at the same time as the DMA interrupt (or slightly before it). With that, the DMA and PIO interrupt handling doesn't work well together. Beneath that the DMA interrupt

Re: BSP Test Results

On 09/09/2020 02:29, Chris Johns wrote: This would be enough to address my "HW or which simulator" question. I had created #4072, please update adding the items you would like. We can add anything you like and they can be mandated. There already exist a number of fields for various transports so

Re: BSP Test Results

On 09/09/2020 02:36, Chris Johns wrote: On 9/9/20 3:13 am, Gedare Bloom wrote: On Sun, Sep 6, 2020 at 8:55 PM Chris Johns wrote: An example using Joel's recent test run (thanks Joel :)). The sparc/leon2 results show no regressions: Summary === Passed:580 Failed: 0 User I

RE: We are loosing patches

I would like this idea. We got Gitlab this year and collaboration with it is pretty convenient. They also seem to hand out free licenses for OSS projects. I guess installing and maintaining an instance is probably quite some work. Best regards, Jan > -Original Message- > From: devel

Re: BSP Test Results

Hello Chris, On 07/09/2020 04:55, Chris Johns wrote: Hello, I would like to discuss BSP Test results early in the release cycle in the hope we avoid the last minute issues we encountered with RTEMS 5 and the "expected" failure state ticket. I would like to update this section ... https://docs

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

On 09/09/2020 00:25, Joel Sherrill wrote:   This has gotten to be a long-ish side discussion. I havecomments on the patch and will reply to the original email for that. On Thu, Sep 3, 2020 at 10:17 PM Chris Johns > wrote: On 3/9/20 10:08 pm, Sebastian Huber wrote

We are loosing patches

Hello, triggered by a comment from Chris here https://lists.rtems.org/pipermail/users/2020-September/067873.html I started to take a look at patches from non maintainers and write after approval maintainers for some months: I think in May and June we lost at least one or two of the following

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

On 09/09/2020 10:07, Chris Johns wrote: On 9/9/20 4:49 pm, Sebastian Huber wrote: On 09/09/2020 07:56, Chris Johns wrote: What about a test for this API that has a 100K char TLS array and all the other task values as defaults? If the space allocated and reported in the link map is not just over

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 9/9/20 4:55 pm, jan.som...@dlr.de wrote: > Hi Chris, > >> -Original Message- >> From: Chris Johns >> Sent: Friday, August 14, 2020 11:43 PM >> To: Sommer, Jan ; devel@rtems.org >> Subject: Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and >> 5 >> >> On 15/8/20 5:57 a

[PATCH v3] rtems: Add rtems_task_create_from_config()

In contrast to rtems_task_create() this function creates a task with a user-provided task storage area. The new create function uses a configuration structure instead of individual parameters. Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of a task storage area. Add RTEMS_

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

On 09/09/2020 00:43, Joel Sherrill wrote: On Wed, Sep 2, 2020 at 11:09 AM Sebastian Huber > wrote: In contrast to rtems_task_create() this function creates a task with a user-provided task storage area.  The new create function uses a co

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

On 9/9/20 4:49 pm, Sebastian Huber wrote: > On 09/09/2020 07:56, Chris Johns wrote: >> What about a test for this API that has a 100K char TLS array and all the >> other >> task values as defaults? If the space allocated and reported in the link map >> is >> not just over 100K there is a problem.

Re: [PATCH] rsb: Fix the documentation URL

OK to push. Thanks Chris On 9/9/20 6:56 pm, Hesham Almatary wrote: > --- > README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/README b/README > index 34350c8..0a9ae72 100644 > --- a/README > +++ b/README > @@ -20,7 +20,7 @@ The project is part of the RTEMS Project.

[PATCH] rsb: Fix the documentation URL

--- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index 34350c8..0a9ae72 100644 --- a/README +++ b/README @@ -20,7 +20,7 @@ The project is part of the RTEMS Project. The project's websites are: https://git.rtems.org/rtems-source-builder.git/ Do