Re: [PATCH] rtems/rtems-kernel-nexus.c: LibBSD init now uses all pass levels.

[Nils Hölscher]

Hi,

BUS_PASS_BUS + BUS_PASS_ORDER_FIRST equals BUS_PASS_BUS, cause
BUS_PASS_ORDER_FIRST is defined 0.

So this is just cosmetical but you are right I should add this.

Best,
Nils

On Fri, 9 Aug 2019 at 20:33, Christian Mauderer  wrote:

> Hello Nils,
>
> thanks for the patch. It sounds like we will get a behaviour that is
> more similar to FreeBSD one with it. But it has the potential to have a
> big influence on existing BSPs so it would be good to have some more
> feedback for it before merging it.
>
> On 09/08/2019 15:53, Nils Hölscher wrote:
> > I observed all Modules loading in the last fdt pass.
> > The reason was, nexus bus loading with BUS_PASS_DEFAULT.
> > ---
> >  rtemsbsd/rtems/rtems-kernel-nexus.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c
> b/rtemsbsd/rtems/rtems-kernel-nexus.c
> > index 15b0f84d..197f23f6 100644
> > --- a/rtemsbsd/rtems/rtems-kernel-nexus.c
> > +++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
> > @@ -394,4 +394,4 @@ static driver_t nexus_driver = {
> >
> >  static devclass_t nexus_devclass;
> >
> > -DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);
> > +EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass,
> 0, 0, SI_ORDER_FIRST, BUS_PASS_BUS);
> >
>
> In freeBSD some of the nexus devices have a "BUS_PASS_BUS +
> BUS_PASS_ORDER_xxx". Did you have a reason to not add a BUS_PASS_ORDER?
>
> For example:
>
> freebsd-org/sys/riscv/riscv/nexus.c:
> EARLY_DRIVER_MODULE(nexus_fdt, root, nexus_fdt_driver,
> nexus_fdt_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
>
> freebsd-org/sys/arm64/arm64/nexus.c:
> EARLY_DRIVER_MODULE(nexus_fdt, root, nexus_fdt_driver,
> nexus_fdt_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
>
> freebsd-org/sys/mips/mips/nexus.c:
> EARLY_DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0,
> BUS_PASS_BUS + BUS_PASS_ORDER_EARLY);
>
> Best regards
>
> Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 2/2] rtems/rtems-kernel-nexus.c: LibBSD init now uses all pass levels.

[Nils Hölscher]

I observed all Modules loading in the last fdt pass.
The reason was, nexus bus loading with BUS_PASS_DEFAULT.
---
 rtemsbsd/rtems/rtems-kernel-nexus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c 
b/rtemsbsd/rtems/rtems-kernel-nexus.c
index 197f23f6..23b72a55 100644
--- a/rtemsbsd/rtems/rtems-kernel-nexus.c
+++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
@@ -394,4 +394,5 @@ static driver_t nexus_driver = {
 
 static devclass_t nexus_devclass;
 
-EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass, 0, 0, 
SI_ORDER_FIRST, BUS_PASS_BUS);
+EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass, 0, 0,
+   SI_ORDER_FIRST, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
-- 
2.22.0

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

[PATCH v2] rtems/rtems-kernel-nexus.c: LibBSD init now uses all pass levels.

[Nils Hölscher]

I observed all Modules loading in the last fdt pass.
The reason was, nexus bus loading with BUS_PASS_DEFAULT.
---
 rtemsbsd/rtems/rtems-kernel-nexus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c 
b/rtemsbsd/rtems/rtems-kernel-nexus.c
index 15b0f84d..23b72a55 100644
--- a/rtemsbsd/rtems/rtems-kernel-nexus.c
+++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
@@ -394,4 +394,5 @@ static driver_t nexus_driver = {
 
 static devclass_t nexus_devclass;
 
-DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);
+EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass, 0, 0,
+   SI_ORDER_FIRST, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
-- 
2.22.0

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

Re: [PATCH v2] rtems/rtems-kernel-nexus.c: LibBSD init now uses all pass levels.

[Nils Hölscher]

Hi,

Sorry can some one help me?
I create the v2 Patch with:
$git format-patch -v2 origin/master

And send the mail with:
$git send-email
v2-0001-rtems-rtems-kernel-nexus.c-LibBSD-init-now-uses-a.patch --to
devel@rtems.org

Why is the patch send to the v1 mail?

Best,
Nils

On Sat, 10 Aug 2019 at 10:48, Nils Hölscher  wrote:

> I observed all Modules loading in the last fdt pass.
> The reason was, nexus bus loading with BUS_PASS_DEFAULT.
> ---
>  rtemsbsd/rtems/rtems-kernel-nexus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c
> b/rtemsbsd/rtems/rtems-kernel-nexus.c
> index 15b0f84d..23b72a55 100644
> --- a/rtemsbsd/rtems/rtems-kernel-nexus.c
> +++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
> @@ -394,4 +394,5 @@ static driver_t nexus_driver = {
>
>  static devclass_t nexus_devclass;
>
> -DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);
> +EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass, 0,
> 0,
> +   SI_ORDER_FIRST, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
> --
> 2.22.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] rtems/rtems-kernel-nexus.c: LibBSD init now uses all pass levels.

[Vijay Kumar Banerjee]

On Sat, Aug 10, 2019 at 2:22 PM Nils Hölscher  wrote:

> Hi,
>
> Sorry can some one help me?
> I create the v2 Patch with:
> $git format-patch -v2 origin/master
>
> And send the mail with:
> $git send-email
> v2-0001-rtems-rtems-kernel-nexus.c-LibBSD-init-now-uses-a.patch --to
> devel@rtems.org
>
> Hello Nils,

Your v2 reached the list :
https://lists.rtems.org/pipermail/devel/2019-August/027246.html
Gmail client sometimes include it in the same thread.

Regards,
Vijay

> Why is the patch send to the v1 mail?
>
> Best,
> Nils
>
> On Sat, 10 Aug 2019 at 10:48, Nils Hölscher  wrote:
>
>> I observed all Modules loading in the last fdt pass.
>> The reason was, nexus bus loading with BUS_PASS_DEFAULT.
>> ---
>>  rtemsbsd/rtems/rtems-kernel-nexus.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c
>> b/rtemsbsd/rtems/rtems-kernel-nexus.c
>> index 15b0f84d..23b72a55 100644
>> --- a/rtemsbsd/rtems/rtems-kernel-nexus.c
>> +++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
>> @@ -394,4 +394,5 @@ static driver_t nexus_driver = {
>>
>>  static devclass_t nexus_devclass;
>>
>> -DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);
>> +EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass,
>> 0, 0,
>> +   SI_ORDER_FIRST, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
>> --
>> 2.22.0
>>
>> ___
> 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: RTEMS Source Builder failed for MX Linux

[Himanshu Sekhar Nayak]

Hi Chris,

Here is the patch file you requested for the changes that I have made to
sb/linux.py and defaults.mc

Thanks
Himanshu
From 205fcd98c6f9d1f012b2a97c47b2ba8b6ff1feea Mon Sep 17 00:00:00 2001
From: Himanshu40 
Date: Sat, 10 Aug 2019 16:55:08 +0530
Subject: [PATCH] Changes made to source directories for MX Linux

---
 source-builder/defaults.mc | 10 +-
 source-builder/sb/linux.py |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/source-builder/defaults.mc b/source-builder/defaults.mc
index 3508877..3251a98 100644
--- a/source-builder/defaults.mc
+++ b/source-builder/defaults.mc
@@ -139,12 +139,12 @@ __autoreconf:exe, optional, 'autoreconf'
 __awk:   exe, required, 'awk'
 __bash:  exe, optional, '/bin/bash'
 __bison: exe, required, '/usr/bin/bison'
-__bzip2: exe, required, '/usr/bin/bzip2'
+__bzip2: exe, required, '/bin/bzip2'
 __cat:   exe, required, '/bin/cat'
 __cc:exe, required, 'gcc'
-__chgrp: exe, required, '/usr/bin/chgrp'
+__chgrp: exe, required, '/bin/chgrp'
 __chmod: exe, required, '/bin/chmod'
-__chown: exe, required, '/usr/sbin/chown'
+__chown: exe, required, '/bin/chown'
 __cp:exe, required, '/bin/cp'
 __cpp:   exe, none, '%{__cc} -E'
 __cvs:   exe, optional, '/usr/bin/cvs'
@@ -152,7 +152,7 @@ __cvs_z: none,none, '%{__cvs} -z 9'
 __cxx:   exe, required, 'g++'
 __flex:  exe, required, '/usr/bin/flex'
 __git:   exe, required, '/usr/bin/git'
-__grep:  exe, required, '/usr/bin/grep'
+__grep:  exe, required, '/bin/grep'
 __gzip:  exe, required, '/usr/bin/gzip'
 __id:exe, required, '/usr/bin/id'
 __id_u:  exe, none, '%{__id} -u'
@@ -178,7 +178,7 @@ __ranlib:exe, required, 'ranlib'
 __rm:exe, required, '/bin/rm'
 __rmfile:exe, none, '%{__rm} -f'
 __rmdir: exe, none, '%{__rm} -rf'
-__sed:   exe, required, '/usr/bin/sed'
+__sed:   exe, required, '/bin/sed'
 __setup_post:exe, none, '%{__chmod} -R a+rX,g-w,o-w .'
 __sh:exe, required, '/bin/sh'
 __tar:   exe, required, '/usr/bin/tar'
diff --git a/source-builder/sb/linux.py b/source-builder/sb/linux.py
index 367532a..238fc81 100644
--- a/source-builder/sb/linux.py
+++ b/source-builder/sb/linux.py
@@ -94,7 +94,7 @@ def load():
 distro = 'redhat'
 elif distro in ['centos', 'fedora']:
 distro = 'redhat'
-elif distro in ['Ubuntu', 'ubuntu', 'LinuxMint', 'linuxmint']:
+elif distro in ['Ubuntu', 'ubuntu', 'mxlinux', 'LinuxMint', 'linuxmint']:
 distro = 'debian'
 elif distro in ['Arch']:
 distro = 'arch'
-- 
2.11.0

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

Re: Problem: RSB does no longer install stand-alone sis

[Jiri Gaisler]

The problem comes from a commit to source-builder/config/sis-2-1.cfg,
made on July 23. If I revert that, installation works again. If nobody
objects, I will push a revert in about an hour and we can debug this at
a later stage.

Jiri.

On 8/9/19 2:34 AM, Chris Johns wrote:
> On 9/8/19 7:59 am, Gedare Bloom wrote:
>> On Thu, Aug 8, 2019 at 3:53 PM Gedare Bloom  wrote:
>>> I can confirm something is wrong. The install step does copy something
>>> though, I get a tree like this:
>>> /share/rtems/rsb:
>>> sis-2.17-x86_64-linux-gnu-1.txt  sis-2.17-x86_64-linux-gnu-1.xml
>>>
>>> I gave --log option to sb-set-builder. I can see the build compiled.
>>>
>>> It looks like %clean is running before %copy. That looks suspicious to me.
>>>
>> Nvm, I think that may be normal.  I don't have any more guesses at the 
>> moment!
>>
> Thanks for taking the time to look. I must have broken something. I will take 
> a
> look this weekend. Sorry about this.
>
> Chris
>>> On Thu, Aug 8, 2019 at 3:43 PM Jiri Gaisler  wrote:
 RSB does not longer install the stand-alone version of sis. Even though 
 the RSB log claims is does, the binary is not copied to the install 
 location:

 installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5does nothing 
 

 There has been a few commits that changes the RSB install scripts but I am 
 not able to see where it goes wrong. Maybe someone more enlightened than 
 me could look at this.

 Building sis as bare tool has that same problem. The binary is built but 
 not installed:

 rtems-source-builder/bare$ ../source-builder/sb-set-builder 
 --prefix=/opt/rtems/5 devel/sis
 RTEMS Source Builder - Set Builder, 5 (e5460e9ecb99)
 Build Set: devel/sis
 config: devel/sis-2-1.cfg
 package: sis-2.17-x86_64-linux-gnu-1
 building: sis-2.17-x86_64-linux-gnu-1
 sizes: sis-2.17-x86_64-linux-gnu-1: 3.770MB (installed: 633.499KB)
 cleaning: sis-2.17-x86_64-linux-gnu-1
 reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.txt
 reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.xml
 installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5
 Build Set: Time 0:00:04.271759
  $

 $ ls -l /opt/rtems/5/bin/*sis*
 ls: cannot access '/opt/rtems/5/bin/*sis*': No such file or directory


 ___
 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: RISC-V Test Results

[Jiri Gaisler]

On 8/8/19 3:33 PM, Joel Sherrill wrote:
> Hi
>
> If you are subscribed to the build@ mailing list, then you saw the
> flurry of test
> results from over night. I built every variant and ran the test suite
> with RTEMS 
> debug on and off.  Here are some observations:
>
> + rv64imafd only has one test pass
> + rv64_iamd_medany only has one test pass
> + Generally speaking, 17-19 tests failed or timed out on every variant
> with 
>    551-553 passing. It would be great for someone to mark the tests in
> the 
>    tcfg files as expected fails.
>
> Hopefully this gives someone incentive to look into the failures.
>
> I would also run them on qemu but I don't think we have an RSB recipe
> for a 
> Qemu with RISC-V support.


I don't know about RV64, but most RV32 tests pass on sis using the
griscv bsp:

$ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/griscv/testsuites
--log=all.txt

Passed:    633
Failed:  0
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 2
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 643
User Input:
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 whetstone.exe
 dhrystone.exe
 linpack.exe
Timeouts:
 crypt01.exe
 smpmrsp01.exe
Average test time: 0:00:00.354592
Testing time : 0:03:48.002439

The crypt01 would succeed if the timeout limit would be a bit longer.
smpmrsp01 never terminates, this is most likely a simulator issue.
Remaining tests including SMP pass as expected.

Jiri.

>
> --joel
>
> ___
> 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: Problem: RSB does no longer install stand-alone sis

[Chris Johns]

On 10/8/19 11:17 pm, Jiri Gaisler wrote:
> The problem comes from a commit to source-builder/config/sis-2-1.cfg,
> made on July 23. 

I am aware this is the problem and a revert may work for you but I seem to
remember it did a problem but I cannot remember what. :)

I would prefer we have the configs in the RSB use `%{host_build_flags}` because
in that expanded macro is the logic that handles all hosts and situations we
have found over the years.

> If I revert that, installation works again. If nobody
> objects, I will push a revert in about an hour and we can debug this at
> a later stage.

It hard for me to object or comment when I am not awake. Maybe a day or so would
be a better time frame and on a weekend a bit longer maybe be needed. :)

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

Re: RTEMS Source Builder failed for MX Linux

[Chris Johns]

On 10/8/19 9:41 pm, Himanshu Sekhar Nayak wrote:
> 
> Here is the patch file you requested for the changes that I have made to
> sb/linux.py and defaults.mc 
> 

Thank you.

Can you please move the changes in `defaults.mc` to `linux.py` in a section that
is specific to MX Linux? The `defaults.mc` is global and this sort of change is
specific to a distro of Linux and would other hosts.

Please add a variation to ...

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104

and then support to handle your distro. This may mean not using `debian`.

Thanks
Chris


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

Re: RTEMS Source Builder failed for MX Linux

[Joel Sherrill]

Also does there need to be a new section in the Users Guide on what host
packages need to be installed?

On Sat, Aug 10, 2019, 8:17 PM Chris Johns  wrote:

> On 10/8/19 9:41 pm, Himanshu Sekhar Nayak wrote:
> >
> > Here is the patch file you requested for the changes that I have made to
> > sb/linux.py and defaults.mc 
> >
>
> Thank you.
>
> Can you please move the changes in `defaults.mc` to `linux.py` in a
> section that
> is specific to MX Linux? The `defaults.mc` is global and this sort of
> change is
> specific to a distro of Linux and would other hosts.
>
> Please add a variation to ...
>
>
> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104
>
> and then support to handle your distro. This may mean not using `debian`.
>
> 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

Re: RTEMS Source Builder failed for MX Linux

[Chris Johns]

On 11/8/19 11:54 am, Joel Sherrill wrote:
> Also does there need to be a new section in the Users Guide on what host
> packages need to be installed?

Yes the documentation needs to be updated to add this distro.

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

Re: RISC-V Test Results

[Chris Johns]

On 9/8/19 9:47 pm, Sebastian Huber wrote:
> On 08/08/2019 15:33, Joel Sherrill wrote:
>> Hi
>>
>> If you are subscribed to the build@ mailing list, then you saw the flurry of 
>> test
>> results from over night. I built every variant and ran the test suite with 
>> RTEMS
>> debug on and off.  Here are some observations:
>>
>> + rv64imafd only has one test pass
>> + rv64_iamd_medany only has one test pass
>> + Generally speaking, 17-19 tests failed or timed out on every variant with
>>     551-553 passing. It would be great for someone to mark the tests in the
>>     tcfg files as expected fails.
> 
> The BSP runs on hardware and simulators.

Interesting.

> Some test may pass on real hardware.

Sure.

> So, marking them as expected fails is not right.

Agreed. I expect to see regressions in simulator from time to time so hardware
is a only way we can validate our test results.

If a BSP can run on both hardware and simulation the hardware results should
have precedent over simulation. This means the we tag against the hardware
results in this case.

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