Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What to do for bound access for api_id? Should I use exit( EXIT_SUCCESS
> > ) for this?
>
> You ignore this item an continue.
>
Okay
https://github.com/rmeena840/rtems-tools/commit/24c7753238ab20fc8c002936657ee0f4c16a6e61


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] user/exe: Add link reference in device-tree

[Vijay Kumar Banerjee]

---
 user/bsps/arm/beagle.rst | 2 +-
 user/exe/device-tree.rst | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
index 6c8796b..87c6ecf 100644
--- a/user/bsps/arm/beagle.rst
+++ b/user/bsps/arm/beagle.rst
@@ -40,7 +40,7 @@ from the libbsd HEAD of freebsd-org. For example if the HEAD 
is at
 Then the right Device Tree Source (DTS) file is:
 
https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
 
-Please refer to the :ref:`device-tree` to know more about building and applying
+Please refer to the :ref:`DeviceTree` to know more about building and applying
 the Device Trees.
 
 Writing the uEnv.txt file
diff --git a/user/exe/device-tree.rst b/user/exe/device-tree.rst
index bd21552..d6a4378 100644
--- a/user/exe/device-tree.rst
+++ b/user/exe/device-tree.rst
@@ -2,6 +2,8 @@
 
 .. Copyright (C) 2019 Vijay Kumar Banerjee 
 
+.. _DeviceTree:
+
 Device Tree
 ===
 .. index:: Device Tree
-- 
2.20.1

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

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

I was able to run rv32imac using

qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
-kernel hello.exe


On Tue, Aug 6, 2019 at 9:04 PM Vaibhav Gupta 
wrote:

> Awesome, thanks!
>
> On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> Hi Vaibhav,
>>
>> * I recommend you use rv64* because of a potential 32-bit HTIF issue on
>> Spike.
>> * Make sure you install Spike correctly [1] and it's in your path or
>> also qemu-system-riscv* instead.
>> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
>> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
>> build RTEMS.
>> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
>>
>> [1] https://github.com/riscv/riscv-isa-sim
>> [2] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>
>> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta 
>> wrote:
>> >
>> > I am getting following error:
>> > .
>> > .
>> > $ rtems-test --rtems-bsp=rv32imac_spike
>> --rtems-tools=$HOME/development/rtems/5
>> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>> >
>> > RTEMS Testing - Tester, 5.0.not_released
>> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
>> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
>> 15:00:46 UTC 2019 x86_64
>> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
>> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
>> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: capture.exe
>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cdtest.exe
>> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cxx_iostream.exe
>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: base_sp.exe
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > warning: switched to dry run due to errors
>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: base_sp.exe
>> > Result: invalidTime: 0:00:00.032377 base_sp.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe
>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: capture.exe
>> > Result: invalidTime: 0:00:00.037950 capture.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe
>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cdtest.exe
>> > Result: invalidTime: 0:00:00.038061 cdtest.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe
>> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cxx_iostream.exe
>> > Result: invalidTime: 0:00:00.034353 cxx_iostream.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe
>> > [ 7/11] p:0  f:0  u:0  e:

Re: RISC-V Test Results

[Hesham Almatary]

Hi Joel,


On Thu, 8 Aug 2019 at 14:34, 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
I think you mean rv64imafd_medany by this? Which only has 1 test
passing. Anyway, I had a look at your run command which provides
--rtems-bsp=rv64imafd_medany_spike. However, rv64imafd BSP variant is
the ones passed to the tester instead of rv64imafd_medany, which
should definitely fail as the start address of this one is 0x7000
and Spike's default memory base t0 0x8000.

> + 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.
>
> --joel



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

Re: RISC-V Test Results

[Sebastian Huber]

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. Some test may pass on real 
hardware. So, marking them as expected fails is not right.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V Test Results

[Joel Sherrill]

On Fri, Aug 9, 2019, 5:39 AM Hesham Almatary 
wrote:

> Hi Joel,
>
>
> On Thu, 8 Aug 2019 at 14:34, 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
> I think you mean rv64imafd_medany by this? Which only has 1 test
> passing. Anyway, I had a look at your run command which provides
> --rtems-bsp=rv64imafd_medany_spike. However, rv64imafd BSP variant is
> the ones passed to the tester instead of rv64imafd_medany, which
> should definitely fail as the start address of this one is 0x7000
> and Spike's default memory base t0 0x8000.
>

Thanks for catching the typo. I have a script which distinguishes the same
bsp on different simulators.

Is the riscv support in upstream Qemu? I recall Jim Wilson mentioning it
had been. If so, updating our Qemu in the RSB would be good. As it is now,
there is no RSB Qemu with riscv

>
> > + 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.
> >
> > --joel
>
>
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Reminder of uncrustify RTEMS configuration

[Sebastian Huber]

On 08/08/2019 17:53, Joel Sherrill wrote:

Hi

I had forgotten about this but someone reminded me. I don't know how close
to correct it is or what's deficient. The wiki blames Gedare for it.

https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify 


The last time I checked uncrustify some year ago it looked like a dead 
project. The current Github statistics tell a different story. I think 
it would be worth to try it out with the latest version.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc

Switch_event per CPU added:
https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b

Have a look.

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 09/08/2019 15:06, Ravindra Kumar Meena wrote:

rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc

Switch_event per CPU added:
https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b

Have a look.


Ok, good. Please always check if the babeltrace and Trace Compass give 
the right results after the changes.


If you use cctx->switch_event[ item->cpu ] and similar a couple of times 
in a function, then please assign it to a local pointer and use it, e.g.


switch_event *se = &cctx->switch_event[ item->cpu ];

Please check all structure names and make the similar to the names used 
in the metadata, e.g. swich_event -> event_sched_switch;


Please check the style of the if again, it should be:

if ( condition ) {
 ...
} else {
 ...
}

Check the white space and position of the { }.

When you have a function like get_api_of_id() you return the api, so the 
variable should be named "api":


  size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu 
].thread_id );


  size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu 
].thread_id );


Declare all variables at the top of the function, e.g.

size_t api;
...
api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sis/gdb on Cygwin

[Joel Sherrill]

I thought I saw a patch pushed yesterday afternoon but a fresh build today
shows the same
breakage.

Jiri .. feel free to push a fix for this and I will test when I get back.

On Thu, Aug 8, 2019 at 2:37 PM Joel Sherrill  wrote:

> This is really easy to fix and hopefully Jiri can produce a patch since I
> am about to leave for the weekend.
>
> The git master has this in erc32 configure.ac. It should be in both sis/
> configure.ac and erc32/configure.ac
> in our gdb 8.2.1 with patches.
>
> # Keep in sync with gdb's configure.ac list.
> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses],
>   [TERMCAP=$ac_cv_search_tgetent], [TERMCAP=""])
> if test x$sim_cv_os_cygwin = xyes; then
>   TERMCAP="${TERMCAP} -luser32"
> fi
> AC_SUBST(TERMCAP)
>
> The gdb version we are using has some old hack-ish code specific to Cygwin
> and termcap which is
> now not needed. Unfortunately, that same code is in sis/configure.ac.
>
> Please and thank you. :)
>
> --joel
>
>
> On Wed, Aug 7, 2019 at 8:37 PM Chris Johns  wrote:
>
>> On 8/8/19 5:46 am, Joel Sherrill wrote:
>> > On Wed, Aug 7, 2019 at 2:33 PM Jiri Gaisler > > > wrote:
>> >
>> >
>> > On 8/7/19 8:22 PM, Joel Sherrill wrote:
>> > > Hi
>> > >
>> > > Looks like Cygwin has libncurses but doesn't install the
>> libtermcap.
>> > > compatibility library.
>> > >
>> > > https://cygwin.com/ml/cygwin/2010-10/msg00018.html  says to link
>> > > against ncurses.
>> > >
>> > >  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed s/-rtems.//`
>>   -I.
>> > > -I../../../gdb-8.2.1/sim/sis -I../common
>> > > -I../../../gdb-8.2.1/sim/sis/../common -I../../include
>> > > -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
>> > > -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
>> > > -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o sis \
>> > >   sis.o exec.o erc32.o func.o help.o float.o grlib.o leon3.o
>> leon2.o
>> > >  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
>> > >  ../../libiberty/libiberty.a -L../../zlib -lz
>> > > ../../readline/libreadline.a `if test -r
>> > > ../../libtermcap/libtermcap.a; then echo
>> > > ../../libtermcap/libtermcap.a; else echo -ltermcap; fi` -luser32
>> -lm
>> > >
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> > > cannot find -ltermcap
>> > > collect2: error: ld returned 1 exit status
>> > >
>> > > Is the solution to just add -lncurses to the list of libraries it
>> > > looks for?
>> > >
>> > > Hopefully someone has some insight into this one.
>> >
>> > How about a patch that disables building sis inside gdb and only
>> use the
>> > newer stand-alone sis version?
>>
>> +1
>>
>> > As long as the rtems tester supports it, I am cool with that.
>>
>> It should. Please find the existing `sis` run or gdb INI configuration
>> files and
>> replace with SIS. I suspect you can get down to one INI config rather
>> than the
>> run and gdb versions we currently have.
>>
>> > My goal is to begin to do regular builds and test sweeps on Cygwin
>> > and Mingw and report to build@. So the RSB and tester need to work. :)
>> >
>>
>> Nice.
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Joel Sherrill]

Coming in late but there isn't there a helper method to turn object names
into strings from either 32 bit values or strings? Shouldn't that be used?

On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > rtems-main.c cleanup:
> >
> https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> >
> > Switch_event per CPU added:
> >
> https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> >
> > Have a look.
>
> Ok, good. Please always check if the babeltrace and Trace Compass give
> the right results after the changes.
>
> If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> in a function, then please assign it to a local pointer and use it, e.g.
>
> switch_event *se = &cctx->switch_event[ item->cpu ];
>
> Please check all structure names and make the similar to the names used
> in the metadata, e.g. swich_event -> event_sched_switch;
>
> Please check the style of the if again, it should be:
>
> if ( condition ) {
>   ...
> } else {
>   ...
> }
>
> Check the white space and position of the { }.
>
> When you have a function like get_api_of_id() you return the api, so the
> variable should be named "api":
>
>size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
>size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
> Declare all variables at the top of the function, e.g.
>
> size_t api;
> ...
> api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

Hi,

I was able to resolve the problem.
The reason that all the devices attached in the last pass and not in the
pass they were assigned, was the nexus bus being loaded as a standard
driver Module.
So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices depend
on nexus bus.
Please see my Output attached.
The prints print the linkpass list and the link list and some other parts.

At the bottom you can also see the pruss device in /dev.

I will create a patch right away.

Best,
Nils

On Wed, 7 Aug 2019 at 11:35, Nils Hölscher  wrote:

> Hi,
>
> I was able to confirm that the current libBSD implementation scans the fdt
> only once.
> caller:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100
> callee:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> The function BUS_NEW_PASS initialises a pass over fdt with all drivers of
> the current pass level.
>
> However after trying to add another pass, I realized that all drivers are
> on the DEFAULT_PASS_LEVEL (max_integer).
>
> Best and thanks,
> Nils
>
> On Thu, 1 Aug 2019 at 11:36, Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> Hello Nils,
>>
>> On 31/07/2019 14:54, Nils Hölscher wrote:
>> > Hi,
>> >
>> > I have been reading into the FreeBSD init code the past few days,
>> > especially for Driver_MODULE.
>> > Expect an Blog entry today or tomorrow.
>> >
>> > Because I don't have JTAG, it took me quite some time.
>>
>> I would always suggest a JTAG or some other kind of debugger for
>> embedded work. In a professional work environment you should try to
>> convince your boss that it is a big time saver (which is definitively
>> true) so that even an expensive debugger is a good investment
>>
>> By the way: For understanding the initialization sequence you might can
>> use a simulator too. For the basic sequence you can simulate any BSP and
>> are not bound to BBB.
>>
>> > With BUS_DEBUG enabled I saw that the problem is indeed that the pruss
>> > unit is discovered too early.
>> > Is this device tree related?
>>
>> It's possible that this is a difference in how modules are handled. I'm
>> not sure whether FreeBSD loads EARLY_MODULES dynamically at another time
>> during boot while we link everything in from the start. If that is true,
>> the mechanism might not work the same like in FreeBSD. You might want to
>> have a look at that.
>>
>> >
>> > I am not sure, cause the overlay I am using is from the BSD community.
>> >
>> > I added my output to a gist and link to the interesting parts.
>> > The EARLY_DRIVER_MODULE's are indeed loaded first.
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
>> > Nexus bus attaches and the driver goes over every discovered device and
>> > tries to attach the drivers in order:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
>> > ofwbus gets discovered:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747
>> > Here the ti_pruss device gets discovered too early in the fdt and fails:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904
>> >
>> > I still haven't found the loop running over fdt.
>>
>> Don't have a test environment ready so this is just from a quick glance
>> at the code. I might have missed something:
>>
>> simplebus_attach adds all child nodes from the tree to the bus:
>>
>>
>> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157
>>
>> The bus_generic_attach then loops over all children and calls their
>> probe and attach functions:
>>
>> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768
>>
>> Best regards
>>
>> Christian
>>
>> > And it seems that the device tree only gets one iteration.
>> > But the BSD man page for EARLY_DRIVER_MODULE states that every
>> > PASS_LEVEL has an iteration.
>> > "
>> >
>> >  The *EARLY*_*DRIVER*_*MODULE*() macro allows a driver to be
>> registered for a
>> >  specific pass level.  The boot time probe and attach process
>> makes   *_multi- _ _ple passes over the device tree_*.  Certain
>> criticaldrivers that provide
>> >  basic services needed by other devices are   attach during
>> earlier passes.
>> >  Most drivers are attached in a final general pass.A driver
>> that
>> >  attaches during an   early pass must register for a specific
>> pass level
>> >  (BUS_PASS_*) via the /pass/ argument.  Once a driver is
>> registered it is
>> >  available to attach to devices for   all subsequent passes."
>> >
>> >
>> https://www.freebsd.org/cgi/man.cgi?query=DRIVER_MODULE&sektion=9&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports
>> >
>> > Best,
>> > Nils
>> >
>> >
>> > On Sun, 28 Jul 2019 at 11:34, Chr

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Joel Sherrill  schrieb:
> Coming in late but there isn't there a helper method to turn object names
> into strings from either 32 bit values or strings? Shouldn't that be used?

This program runs on the host.

> 
> On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
> > On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > > rtems-main.c cleanup:
> > >
> > https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> > >
> > > Switch_event per CPU added:
> > >
> > https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> > >
> > > Have a look.
> >
> > Ok, good. Please always check if the babeltrace and Trace Compass give
> > the right results after the changes.
> >
> > If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> > in a function, then please assign it to a local pointer and use it, e.g.
> >
> > switch_event *se = &cctx->switch_event[ item->cpu ];
> >
> > Please check all structure names and make the similar to the names used
> > in the metadata, e.g. swich_event -> event_sched_switch;
> >
> > Please check the style of the if again, it should be:
> >
> > if ( condition ) {
> >   ...
> > } else {
> >   ...
> > }
> >
> > Check the white space and position of the { }.
> >
> > When you have a function like get_api_of_id() you return the api, so the
> > variable should be named "api":
> >
> >size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> > ].thread_id );
> >
> >size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> > ].thread_id );
> >
> > Declare all variables at the top of the function, e.g.
> >
> > size_t api;
> > ...
> > api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] 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 | 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);
-- 
2.22.0

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

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

[Nils Hölscher]

Hi,

Please see attached the files containing my output.

OUT-BEFORE.txt: contains output without patch.
OUT-AFTER.txt: contains output with patch.

Thanks,
Nils

On Fri, 9 Aug 2019 at 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);
> --
> 2.22.0
>
>
Skript gestartet auf 2019-08-09 16:05:49+02:00 [TERM="xterm-256color" 
TTY="/dev/pts/2" COLUMNS="238" LINES="27"]
]0;nils@nils-Laptop:~/Downloads[nils@nils-Laptop Downloads]$ beagleserial 
[sudo] Passwort f??r nils: 
picocom v3.1

port is: /dev/ttyUSB0
flowcontrol: none
baudrate is: 115200
parity is  : none
databits are   : 8
stopbits are   : 1
escape is  : C-a
local echo is  : no
noinit is  : no
noreset is : no
hangup is  : no
nolock is  : no
send_cmd is: sz -vv
receive_cmd is : rz -vv -E
imap is: 
omap is: 
emap is: crcrlf,delbs,
logfile is : none
initstring : none
exit_after is  : not set
exit is: no

Type [C-a] [C-h] to see available commands
Terminal ready

U-Boot SPL 2019.04-2-gc8b5ad3a1f (Apr 16 2019 - 09:21:31 -0500)
Trying to boot from MMC2
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **


U-Boot 2019.04-2-gc8b5ad3a1f (Apr 16 2019 - 09:21:31 -0500), Build: 
jenkins-github_Bootloader-Builder-116

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **
Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00C0] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
51485 bytes read in 6 ms (8.2 MiB/s)
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
560 bytes read in 2 ms (273.4 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from /uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...

RTEMS u-boot-beaglebone (arm-ti-am335x_evm)
 rtems-boot-image v5.0.not_released

Loading pru.exe.img
1876950 bytes read in 122 ms (14.7 MiB/s)
Loading am335x-boneblack.dtb
51485 bytes read in 6 ms (8.2 MiB/s)
Loading AM335X-PRU-UIO-00A0.dtbo
883 bytes read in 3 ms (287.1 KiB/s)
Applying fdt overlay
## Booting kernel from Legacy Image at 8200 ...
   Image Name:   RTEMS
   Created:  2019-08-09  14:04:44 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:1876886 Bytes = 1.8 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 8ff8b000, end 8fff ... OK

Starting kernel ...


RTEMS Beagleboard: am335x-based
  ARM Debug: 0x4b141000

RTEMS BBB PRU Tester

== passlink List ==
Name: simplebus, Pass: 10
Name: ti_scm, Pass: 15
Name: cpswss, Pass: 2147483647
== link List ==
DevClass: root, Maxunit: 4, ParentClass: NULL
DevClass: simplebus, Maxunit: 0, ParentClass: NULL
DevClass: cpswss, Maxunit: 0, ParentClass: NULL
DevClass: uhub, Maxunit: 0, ParentClass: NULL
DevClass: usbus, Maxunit: 0, ParentClass: NULL
DevClass: ti_pruss, Maxunit: 0, ParentClass: NULL
DevClass: ti_scm, Maxunit: 0, ParentClass: NULL
DevClass: sdhci_ti, Maxunit: 0, ParentClass: NULL
DevClass: mmc, Maxunit: 0, ParentClass: NULL
DevClass: ofwbus, Maxunit: 0, ParentClass: simplebus
DevClass: iicbus, Maxunit: 0, ParentClass: NULL
DevClass: iic, Maxunit: 0, ParentClass: NULL
DevClass: usbss, Maxunit: 0,

Re: GSoC Project | Basic Support for Trace Compass

[Joel Sherrill]

On Fri, Aug 9, 2019, 8:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> - Joel Sherrill  schrieb:
> > Coming in late but there isn't there a helper method to turn object names
> > into strings from either 32 bit values or strings? Shouldn't that be
> used?
>
> This program runs on the host.
>

Couldn't the method be copied?

>
> >
> > On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
> > sebastian.hu...@embedded-brains.de> wrote:
> >
> > > On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > > > rtems-main.c cleanup:
> > > >
> > >
> https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> > > >
> > > > Switch_event per CPU added:
> > > >
> > >
> https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> > > >
> > > > Have a look.
> > >
> > > Ok, good. Please always check if the babeltrace and Trace Compass give
> > > the right results after the changes.
> > >
> > > If you use cctx->switch_event[ item->cpu ] and similar a couple of
> times
> > > in a function, then please assign it to a local pointer and use it,
> e.g.
> > >
> > > switch_event *se = &cctx->switch_event[ item->cpu ];
> > >
> > > Please check all structure names and make the similar to the names used
> > > in the metadata, e.g. swich_event -> event_sched_switch;
> > >
> > > Please check the style of the if again, it should be:
> > >
> > > if ( condition ) {
> > >   ...
> > > } else {
> > >   ...
> > > }
> > >
> > > Check the white space and position of the { }.
> > >
> > > When you have a function like get_api_of_id() you return the api, so
> the
> > > variable should be named "api":
> > >
> > >size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> > > ].thread_id );
> > >
> > >size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> > > ].thread_id );
> > >
> > > Declare all variables at the top of the function, e.g.
> > >
> > > size_t api;
> > > ...
> > > api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
> > >
> > > --
> > > Sebastian Huber, embedded brains GmbH
> > >
> > > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > > Phone   : +49 89 189 47 41-16
> > > Fax : +49 89 189 47 41-09
> > > E-Mail  : sebastian.hu...@embedded-brains.de
> > > PGP : Public key available on request.
> > >
> > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RTEMS BSP Buildset

[Jonathan Brandmeyer]

On Wed, Aug 7, 2019 at 7:07 PM Chris Johns  wrote:

> I dislike BSP_OPTS for a few reason; I will not expand on that topic here. I 
> can
> 
>
> 1. Add option support to the RSB. I am not exactly sure how this could be made
> to work but something like ...
>
>  --enable-bspopt-bsp-zynq-ram-length=256

A variation on this, is that you could provide an option prefix that
is used to forward options to a particular configuration stage, using
GCC's `-Wa,` and `-Wl,` (aka -Xassembler and -Xlinker) as a model.
That way you don't have to decide at the RSB level by hand which
options are worth supporting natively and which ones aren't - all of
them are supported uniformly.  Reasonable prefixes might be `-Xbsp`
and `-Xlibbsd`, for example.

> 2. Add support for RTEMS configure options. This can be done in a similar way 
> to
> the languages for gcc as there is only a few valid ones left.

With an option-forwarding prefix, then its easy to decide that the
options which should be supported natively are only the ones that are
common to all of the BSP's.  For example, --enable-cxx and
--enable-fortran should definitely be covered by the top-level driver,
for example.

>
> 3. Add generic support to the BSP or ARM default workspace initialise code to
> call something like `bsp_workspace_begin()` and `bsp_workspace_end()` that are
> weak functions in RTEMS returning the linkcmd values. A user can add these
> functions to their BSP support code to override. This type of support would 
> let
> the RPi use the generic support.
>
> 4. Do all the above and ban any new BSP_OPTS being added to a BSP in 
> preference
> of weak symbol runtime calls. I feel a number of existing BSP_OPTS could be
> removed this way.

I'm also keenly interested in seeing how far the device tree support
gets.  At least for the Zynq family, passing some options to RTEMS
from the bootloader via device tree could be a convenient workflow.

My project is leveraging the existing weak symbol support for
overriding some of the default clock speeds.  It mostly works.
However, the nature of weak symbol support in the linker makes this
fragile.  Its easy to make a subtle change in the link command line
that silently pulls in RTEMS incorrect (for my board) definition of
the symbol instead of the one I intended to provide from my sources.

The situation with the Zynq also begs the question, what exactly
justifies a new BSP?  As near as I can tell,
xilinx_zynq_{zc702,zc706,zedboard} only exist as separate BSP's to
provide different default values for the various BSP_OPTs.

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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 9. Aug 2019 um 16:11 schrieb joel j...@rtems.org:

> On Fri, Aug 9, 2019, 8:45 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>>
>> - Joel Sherrill  schrieb:
>> > Coming in late but there isn't there a helper method to turn object names
>> > into strings from either 32 bit values or strings? Shouldn't that be
>> used?
>>
>> This program runs on the host.
>>
> 
> Couldn't the method be copied?

Yes, you are a bit late ;-)

The integer values with the thread name parts are in the record event data, not 
the object names.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RTEMS BSP Buildset

[Sebastian Huber]

Hello,

just my 2ct with respect to the lacking device tree support in the Xilinx Zynq 
BSP. This is just a historic accident. The BSP was written before we had any 
device tree support in RTEMS. In general, I think we should stick to what Linux 
does on a certain platform. If it boots via a device tree, then the RTEMS BSP 
should do this as well.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
>
> Ok, good. Please always check if the babeltrace and Trace Compass give
> the right results after the changes.
>
Yes. Both are displaying same output.

>
> If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> in a function, then please assign it to a local pointer and use it, e.g.
>
> switch_event *se = &cctx->switch_event[ item->cpu ];
>
> Please check all structure names and make the similar to the names used
> in the metadata, e.g. swich_event -> event_sched_switch;
>
> Please check the style of the if again, it should be:
>
> if ( condition ) {
>   ...
> } else {
>   ...
> }
>
> Check the white space and position of the { }.
>
> When you have a function like get_api_of_id() you return the api, so the
> variable should be named "api":
>
>size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
>size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
> Declare all variables at the top of the function, e.g.
>
> size_t api;
> ...
> api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );

https://github.com/rmeena840/rtems-tools/commit/11cf7626e40a20c9bfaf889a94d51171519d6dc0



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC PRU: AM35xx Clock driver

[Christian Mauderer]

Hello Nils,

great that you found your problem. It sounds like it is a general bug in
libbsd. What did you change and do you have a patch that would fix this?

Best regards

Christian

On 09/08/2019 15:42, Nils Hölscher wrote:
> Hi,
> 
> I was able to resolve the problem.
> The reason that all the devices attached in the last pass and not in the
> pass they were assigned, was the nexus bus being loaded as a standard
> driver Module.
> So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices
> depend on nexus bus.
> Please see my Output attached.
> The prints print the linkpass list and the link list and some other parts.
> 
> At the bottom you can also see the pruss device in /dev.
> 
> I will create a patch right away.
> 
> Best,
> Nils
> 
> On Wed, 7 Aug 2019 at 11:35, Nils Hölscher  > wrote:
> 
> Hi,
> 
> I was able to confirm that the current libBSD implementation scans
> the fdt only once.
> caller: 
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100
> callee: 
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> The function BUS_NEW_PASS initialises a pass over fdt with all
> drivers of the current pass level.
> 
> However after trying to add another pass, I realized that all
> drivers are on the DEFAULT_PASS_LEVEL (max_integer).
> 
> Best and thanks,
> Nils
> 
> On Thu, 1 Aug 2019 at 11:36, Christian Mauderer
>  > wrote:
> 
> Hello Nils,
> 
> On 31/07/2019 14:54, Nils Hölscher wrote:
> > Hi,
> >
> > I have been reading into the FreeBSD init code the past few days,
> > especially for Driver_MODULE.
> > Expect an Blog entry today or tomorrow.
> >
> > Because I don't have JTAG, it took me quite some time.
> 
> I would always suggest a JTAG or some other kind of debugger for
> embedded work. In a professional work environment you should try to
> convince your boss that it is a big time saver (which is
> definitively
> true) so that even an expensive debugger is a good investment
> 
> By the way: For understanding the initialization sequence you
> might can
> use a simulator too. For the basic sequence you can simulate any
> BSP and
> are not bound to BBB.
> 
> > With BUS_DEBUG enabled I saw that the problem is indeed that
> the pruss
> > unit is discovered too early.
> > Is this device tree related?
> 
> It's possible that this is a difference in how modules are
> handled. I'm
> not sure whether FreeBSD loads EARLY_MODULES dynamically at
> another time
> during boot while we link everything in from the start. If that
> is true,
> the mechanism might not work the same like in FreeBSD. You might
> want to
> have a look at that.
> 
> >
> > I am not sure, cause the overlay I am using is from the BSD
> community.
> >
> > I added my output to a gist and link to the interesting parts.
> > The EARLY_DRIVER_MODULE's are indeed loaded first.
> >
> 
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
> > Nexus bus attaches and the driver goes over every discovered
> device and
> > tries to attach the drivers in order:
> >
> 
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
> > ofwbus gets discovered:
> >
> 
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747
> > Here the ti_pruss device gets discovered too early in the fdt
> and fails:
> >
> 
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904
> >
> > I still haven't found the loop running over fdt.
> 
> Don't have a test environment ready so this is just from a quick
> glance
> at the code. I might have missed something:
> 
> simplebus_attach adds all child nodes from the tree to the bus:
> 
> 
> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157
> 
> The bus_generic_attach then loops over all children and calls their
> probe and attach functions:
> 
> 
> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768
> 
> Best regards
> 
> Christian
> 
> > And it seems that the device tree only gets one iteration.
> > But the BSD man page for EARLY_DRIVER_MODULE states that every
> > PASS_LEVEL has an iteration.
> > " 
> >
>  

Re: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

Hi Christian,

I want to thank you again, since you actually helped me a lot with this
problem.
But I already patched this problem, didn't I.

Thanks,
Nils

Christian Mauderer  schrieb am Fr., 9. Aug. 2019, 19:50:

> Hello Nils,
>
> great that you found your problem. It sounds like it is a general bug in
> libbsd. What did you change and do you have a patch that would fix this?
>
> Best regards
>
> Christian
>
> On 09/08/2019 15:42, Nils Hölscher wrote:
> > Hi,
> >
> > I was able to resolve the problem.
> > The reason that all the devices attached in the last pass and not in the
> > pass they were assigned, was the nexus bus being loaded as a standard
> > driver Module.
> > So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices
> > depend on nexus bus.
> > Please see my Output attached.
> > The prints print the linkpass list and the link list and some other
> parts.
> >
> > At the bottom you can also see the pruss device in /dev.
> >
> > I will create a patch right away.
> >
> > Best,
> > Nils
> >
> > On Wed, 7 Aug 2019 at 11:35, Nils Hölscher  > > wrote:
> >
> > Hi,
> >
> > I was able to confirm that the current libBSD implementation scans
> > the fdt only once.
> > caller:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100
> > callee:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> > The function BUS_NEW_PASS initialises a pass over fdt with all
> > drivers of the current pass level.
> >
> > However after trying to add another pass, I realized that all
> > drivers are on the DEFAULT_PASS_LEVEL (max_integer).
> >
> > Best and thanks,
> > Nils
> >
> > On Thu, 1 Aug 2019 at 11:36, Christian Mauderer
> >  > > wrote:
> >
> > Hello Nils,
> >
> > On 31/07/2019 14:54, Nils Hölscher wrote:
> > > Hi,
> > >
> > > I have been reading into the FreeBSD init code the past few
> days,
> > > especially for Driver_MODULE.
> > > Expect an Blog entry today or tomorrow.
> > >
> > > Because I don't have JTAG, it took me quite some time.
> >
> > I would always suggest a JTAG or some other kind of debugger for
> > embedded work. In a professional work environment you should try
> to
> > convince your boss that it is a big time saver (which is
> > definitively
> > true) so that even an expensive debugger is a good investment
> >
> > By the way: For understanding the initialization sequence you
> > might can
> > use a simulator too. For the basic sequence you can simulate any
> > BSP and
> > are not bound to BBB.
> >
> > > With BUS_DEBUG enabled I saw that the problem is indeed that
> > the pruss
> > > unit is discovered too early.
> > > Is this device tree related?
> >
> > It's possible that this is a difference in how modules are
> > handled. I'm
> > not sure whether FreeBSD loads EARLY_MODULES dynamically at
> > another time
> > during boot while we link everything in from the start. If that
> > is true,
> > the mechanism might not work the same like in FreeBSD. You might
> > want to
> > have a look at that.
> >
> > >
> > > I am not sure, cause the overlay I am using is from the BSD
> > community.
> > >
> > > I added my output to a gist and link to the interesting parts.
> > > The EARLY_DRIVER_MODULE's are indeed loaded first.
> > >
> >
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
> > > Nexus bus attaches and the driver goes over every discovered
> > device and
> > > tries to attach the drivers in order:
> > >
> >
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
> > > ofwbus gets discovered:
> > >
> >
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747
> > > Here the ti_pruss device gets discovered too early in the fdt
> > and fails:
> > >
> >
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904
> > >
> > > I still haven't found the loop running over fdt.
> >
> > Don't have a test environment ready so this is just from a quick
> > glance
> > at the code. I might have missed something:
> >
> > simplebus_attach adds all child nodes from the tree to the bus:
> >
> >
> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157
> >
> > The bus_generic_attach then loops over all children and calls
> their
> >   

Re: GSoC PRU: AM35xx Clock driver

[Christian Mauderer]

Hello Nils,

sorry, I missed the patch on the mailing list.

Best regards

Christian

On 09/08/2019 20:07, Nils Hölscher wrote:
> Hi Christian,
> 
> I want to thank you again, since you actually helped me a lot with this
> problem.
> But I already patched this problem, didn't I.
> 
> Thanks,
> Nils
> 
> Christian Mauderer mailto:l...@c-mauderer.de>>
> schrieb am Fr., 9. Aug. 2019, 19:50:
> 
> Hello Nils,
> 
> great that you found your problem. It sounds like it is a general bug in
> libbsd. What did you change and do you have a patch that would fix this?
> 
> Best regards
> 
> Christian
> 
> On 09/08/2019 15:42, Nils Hölscher wrote:
> > Hi,
> >
> > I was able to resolve the problem.
> > The reason that all the devices attached in the last pass and not
> in the
> > pass they were assigned, was the nexus bus being loaded as a standard
> > driver Module.
> > So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices
> > depend on nexus bus.
> > Please see my Output attached.
> > The prints print the linkpass list and the link list and some
> other parts.
> >
> > At the bottom you can also see the pruss device in /dev.
> >
> > I will create a patch right away.
> >
> > Best,
> > Nils
> >
> > On Wed, 7 Aug 2019 at 11:35, Nils Hölscher  
> > >> wrote:
> >
> >     Hi,
> >
> >     I was able to confirm that the current libBSD implementation scans
> >     the fdt only once.
> >   
>  caller: 
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100
> >   
>  callee: 
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> >     The function BUS_NEW_PASS initialises a pass over fdt with all
> >     drivers of the current pass level.
> >
> >     However after trying to add another pass, I realized that all
> >     drivers are on the DEFAULT_PASS_LEVEL (max_integer).
> >
> >     Best and thanks,
> >     Nils
> >
> >     On Thu, 1 Aug 2019 at 11:36, Christian Mauderer
> >      
> >      >> wrote:
> >
> >         Hello Nils,
> >
> >         On 31/07/2019 14:54, Nils Hölscher wrote:
> >         > Hi,
> >         >
> >         > I have been reading into the FreeBSD init code the past
> few days,
> >         > especially for Driver_MODULE.
> >         > Expect an Blog entry today or tomorrow.
> >         >
> >         > Because I don't have JTAG, it took me quite some time.
> >
> >         I would always suggest a JTAG or some other kind of
> debugger for
> >         embedded work. In a professional work environment you
> should try to
> >         convince your boss that it is a big time saver (which is
> >         definitively
> >         true) so that even an expensive debugger is a good investment
> >
> >         By the way: For understanding the initialization sequence you
> >         might can
> >         use a simulator too. For the basic sequence you can
> simulate any
> >         BSP and
> >         are not bound to BBB.
> >
> >         > With BUS_DEBUG enabled I saw that the problem is indeed that
> >         the pruss
> >         > unit is discovered too early.
> >         > Is this device tree related?
> >
> >         It's possible that this is a difference in how modules are
> >         handled. I'm
> >         not sure whether FreeBSD loads EARLY_MODULES dynamically at
> >         another time
> >         during boot while we link everything in from the start. If
> that
> >         is true,
> >         the mechanism might not work the same like in FreeBSD. You
> might
> >         want to
> >         have a look at that.
> >
> >         >
> >         > I am not sure, cause the overlay I am using is from the BSD
> >         community.
> >         >
> >         > I added my output to a gist and link to the interesting
> parts.
> >         > The EARLY_DRIVER_MODULE's are indeed loaded first.
> >         >
> >       
>  
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
> >         > Nexus bus attaches and the driver goes over every discovered
> >         device and
> >         > tries to attach the drivers in order:
> >         >
> >       
>  
> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
> >         > ofwbus gets di

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

[Christian Mauderer]

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

Re: sis/gdb on Cygwin

[Jiri Gaisler]

On 8/9/19 3:24 PM, Joel Sherrill wrote:
> I thought I saw a patch pushed yesterday afternoon but a fresh build
> today shows the same
> breakage. 
>
> Jiri .. feel free to push a fix for this and I will test when I get back.
The problem right now is that RSB has some breakage which causes the
stand-alone version of sis not to be installed. If I push the patch,
then no sis at all will be installed. I will try to find some time to
look at the cygwin build problem, until Chris gets some time to look at
the RSB issue ...
>
> On Thu, Aug 8, 2019 at 2:37 PM Joel Sherrill  > wrote:
>
> This is really easy to fix and hopefully Jiri can produce a patch
> since I am about to leave for the weekend.
>
> The git master has this in erc32 configure.ac
> . It should be in both sis/configure.ac
>  and erc32/configure.ac  
> in our gdb 8.2.1 with patches.
>
> # Keep in sync with gdb's configure.ac  list.
> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses],
>   [TERMCAP=$ac_cv_search_tgetent], [TERMCAP=""])
> if test x$sim_cv_os_cygwin = xyes; then
>   TERMCAP="${TERMCAP} -luser32"
> fi
> AC_SUBST(TERMCAP)
>
> The gdb version we are using has some old hack-ish code specific
> to Cygwin and termcap which is 
> now not needed. Unfortunately, that same code is in
> sis/configure.ac . 
>
> Please and thank you. :)
>
> --joel
>
>
> On Wed, Aug 7, 2019 at 8:37 PM Chris Johns  > wrote:
>
> On 8/8/19 5:46 am, Joel Sherrill wrote:
> > On Wed, Aug 7, 2019 at 2:33 PM Jiri Gaisler  
> > >> wrote:
> >
> >
> >     On 8/7/19 8:22 PM, Joel Sherrill wrote:
> >     > Hi
> >     >
> >     > Looks like Cygwin has libncurses but doesn't install
> the libtermcap.
> >     > compatibility library.
> >     >
> >     > https://cygwin.com/ml/cygwin/2010-10/msg00018.html 
> says to link
> >     > against ncurses.
> >     >
> >     >  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed
> s/-rtems.//`   -I.
> >     > -I../../../gdb-8.2.1/sim/sis -I../common
> >     > -I../../../gdb-8.2.1/sim/sis/../common -I../../include
> >     > -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
> >     > -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
> >     > -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o
> sis \
> >     >   sis.o exec.o erc32.o func.o help.o float.o grlib.o
> leon3.o leon2.o
> >     >  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
> >     >  ../../libiberty/libiberty.a -L../../zlib -lz
> >     > ../../readline/libreadline.a `if test -r
> >     > ../../libtermcap/libtermcap.a; then echo
> >     > ../../libtermcap/libtermcap.a; else echo -ltermcap;
> fi` -luser32 -lm
> >     >
> 
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> >     > cannot find -ltermcap
> >     > collect2: error: ld returned 1 exit status
> >     >
> >     > Is the solution to just add -lncurses to the list of
> libraries it
> >     > looks for?
> >     >
> >     > Hopefully someone has some insight into this one.
> >
> >     How about a patch that disables building sis inside gdb
> and only use the
> >     newer stand-alone sis version?
>
> +1
>
> > As long as the rtems tester supports it, I am cool with that.
>
> It should. Please find the existing `sis` run or gdb INI
> configuration files and
> replace with SIS. I suspect you can get down to one INI config
> rather than the
> run and gdb versions we currently have.
>
> > My goal is to begin to do regular builds and test sweeps on
> Cygwin
> > and Mingw and report to build@. So the RSB and tester need
> to work. :) 
> >
>
> Nice.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sis/gdb on Cygwin

[Jiri Gaisler]

On 8/9/19 8:34 PM, Jiri Gaisler wrote:
>
>
> On 8/9/19 3:24 PM, Joel Sherrill wrote:
>> I thought I saw a patch pushed yesterday afternoon but a fresh build today 
>> shows the same
>> breakage. 
>>
>> Jiri .. feel free to push a fix for this and I will test when I get back.
> The problem right now is that RSB has some breakage which causes the 
> stand-alone version of sis not to be installed. If I push the patch, then no 
> sis at all will be installed. I will try to find some time to look at the 
> cygwin build problem, until Chris gets some time to look at the RSB issue ...

I tried to build gdb on cygwin but failed on configuration issues and python3 
problems. Cygwin has a million packages with various versions and it is hard to 
figure out what needs to be installed. For windows 10 users, my recommendation 
is to use WSL with ubuntu 18.04. I built RSB without issues in WSL at near 
native speed, and no windows specific patches are needed. Even async SIGIO on 
sockets works ...! With windows 7 being unsupported from January 2020, is it 
really necessary to maintaining msys/mingw/cygwin support ...?



>>
>> On Thu, Aug 8, 2019 at 2:37 PM Joel Sherrill > > wrote:
>>
>> This is really easy to fix and hopefully Jiri can produce a patch since 
>> I am about to leave for the weekend.
>>
>> The git master has this in erc32 configure.ac . It 
>> should be in both sis/configure.ac  and 
>> erc32/configure.ac  
>> in our gdb 8.2.1 with patches.
>>
>> # Keep in sync with gdb's configure.ac  list.
>> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses],
>>   [TERMCAP=$ac_cv_search_tgetent], [TERMCAP=""])
>> if test x$sim_cv_os_cygwin = xyes; then
>>   TERMCAP="${TERMCAP} -luser32"
>> fi
>> AC_SUBST(TERMCAP)
>>
>> The gdb version we are using has some old hack-ish code specific to 
>> Cygwin and termcap which is 
>> now not needed. Unfortunately, that same code is in sis/configure.ac 
>> . 
>>
>> Please and thank you. :)
>>
>> --joel
>>
>>
>> On Wed, Aug 7, 2019 at 8:37 PM Chris Johns > > wrote:
>>
>> On 8/8/19 5:46 am, Joel Sherrill wrote:
>> > On Wed, Aug 7, 2019 at 2:33 PM Jiri Gaisler > 
>> > >> wrote:
>> >
>> >
>> >     On 8/7/19 8:22 PM, Joel Sherrill wrote:
>> >     > Hi
>> >     >
>> >     > Looks like Cygwin has libncurses but doesn't install the 
>> libtermcap.
>> >     > compatibility library.
>> >     >
>> >     > https://cygwin.com/ml/cygwin/2010-10/msg00018.html  says to 
>> link
>> >     > against ncurses.
>> >     >
>> >     >  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed 
>> s/-rtems.//`   -I.
>> >     > -I../../../gdb-8.2.1/sim/sis -I../common
>> >     > -I../../../gdb-8.2.1/sim/sis/../common -I../../include
>> >     > -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
>> >     > -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
>> >     > -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o sis \
>> >     >   sis.o exec.o erc32.o func.o help.o float.o grlib.o leon3.o 
>> leon2.o
>> >     >  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
>> >     >  ../../libiberty/libiberty.a -L../../zlib -lz
>> >     > ../../readline/libreadline.a `if test -r
>> >     > ../../libtermcap/libtermcap.a; then echo
>> >     > ../../libtermcap/libtermcap.a; else echo -ltermcap; fi` 
>> -luser32 -lm
>> >     > 
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> >     > cannot find -ltermcap
>> >     > collect2: error: ld returned 1 exit status
>> >     >
>> >     > Is the solution to just add -lncurses to the list of 
>> libraries it
>> >     > looks for?
>> >     >
>> >     > Hopefully someone has some insight into this one.
>> >
>> >     How about a patch that disables building sis inside gdb and 
>> only use the
>> >     newer stand-alone sis version?
>>
>> +1
>>
>> > As long as the rtems tester supports it, I am cool with that.
>>
>> It should. Please find the existing `sis` run or gdb INI 
>> configuration files and
>> replace with SIS. I suspect you can get down to one INI config 
>> rather than the
>> run and gdb versions we currently have.
>>
>> > My goal is to begin to do regular builds and test sweeps on Cygwin
>> > and Mingw and report to build@. So the RSB and tester need to 
>> work. :) 
>> >
>>
>> Nice.
>>
>> Chris
>>
>
> ___
> devel mailing list
> devel@rtems.org
>

Re: [PATCH] RTEMS BSP Buildset

[Chris Johns]

On 10/8/19 1:23 am, Jonathan Brandmeyer wrote:
> On Wed, Aug 7, 2019 at 7:07 PM Chris Johns  wrote:
> 
>> I dislike BSP_OPTS for a few reason; I will not expand on that topic here. I 
>> can
>> 
>>
>> 1. Add option support to the RSB. I am not exactly sure how this could be 
>> made
>> to work but something like ...
>>
>>  --enable-bspopt-bsp-zynq-ram-length=256
> 
> A variation on this, is that you could provide an option prefix that
> is used to forward options to a particular configuration stage, using
> GCC's `-Wa,` and `-Wl,` (aka -Xassembler and -Xlinker) as a model.
> That way you don't have to decide at the RSB level by hand which
> options are worth supporting natively and which ones aren't - all of
> them are supported uniformly.  Reasonable prefixes might be `-Xbsp`
> and `-Xlibbsd`, for example.

Yes this is nice but I am not sure how the RSB config language can do this.
There are no loops in the language and I do not want to hard code in Python
specific support for a package. There is also multiple options needing to be
appended together to make a full set the user needs. The option handling and the
build script are a long way from each other.

I unfortunately have limited time to put into this so keeping to the config
language is the easiest path.

>> 2. Add support for RTEMS configure options. This can be done in a similar 
>> way to
>> the languages for gcc as there is only a few valid ones left.
> 
> With an option-forwarding prefix, then its easy to decide that the
> options which should be supported natively are only the ones that are
> common to all of the BSP's.  For example, --enable-cxx and
> --enable-fortran should definitely be covered by the top-level driver,
> for example.

There is this ..

https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-common.cfg#n94

where `--with-rtems-cxx` is picked up with ..

%if %{defined with_rtems_cxx}
 %define rtems_cxx 1
%endif

If the `--with-*` and `--without-*` support can be used it means less or no
changes to the RSB python code base.

>> 3. Add generic support to the BSP or ARM default workspace initialise code to
>> call something like `bsp_workspace_begin()` and `bsp_workspace_end()` that 
>> are
>> weak functions in RTEMS returning the linkcmd values. A user can add these
>> functions to their BSP support code to override. This type of support would 
>> let
>> the RPi use the generic support.
>>
>> 4. Do all the above and ban any new BSP_OPTS being added to a BSP in 
>> preference
>> of weak symbol runtime calls. I feel a number of existing BSP_OPTS could be
>> removed this way.
> 
> I'm also keenly interested in seeing how far the device tree support
> gets.  At least for the Zynq family, passing some options to RTEMS
> from the bootloader via device tree could be a convenient workflow.
> 
> My project is leveraging the existing weak symbol support for
> overriding some of the default clock speeds.  It mostly works.
> However, the nature of weak symbol support in the linker makes this
> fragile.  Its easy to make a subtle change in the link command line
> that silently pulls in RTEMS incorrect (for my board) definition of
> the symbol instead of the one I intended to provide from my sources.

Yes and if placed in a library and with separate text and data it can be fiddly.
I place the code in same file as `Init()` and then call each from Init someway.
This makes sure I always have the code I want.

> The situation with the Zynq also begs the question, what exactly
> justifies a new BSP?  As near as I can tell,
> xilinx_zynq_{zc702,zc706,zedboard} only exist as separate BSP's to
> provide different default values for the various BSP_OPTs.

If you are using an openly available target like the Microzed then we want to
have the options set for that user. A user of such a board should not need to
dig into the detail to find a suitable set of settings. Removing BSP_OPTS would
mean we would need to figure out how this needs to be handled.

I would like to find a way so a single kernel build that can adjust to target
variations at runtime. FDT is one method or part of the solution but we would
need to make sure the BSP is consistent and across all BSPs.

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

Re: [PATCH] RTEMS BSP Buildset

[Chris Johns]

On 10/8/19 2:54 am, Sebastian Huber wrote:
> just my 2ct with respect to the lacking device tree support in the Xilinx 
> Zynq BSP. This is just a historic accident. The BSP was written before we had 
> any device tree support in RTEMS. 

FDT support for the Zynq would be nice however it would need to be more than the
uboot way of handling it, ie loading from a file in RTEMS itself with out uboot.

>In general, I think we should stick to what Linux does on a certain platform.

I am not sure about this. It works for some targets like the BBB and RPi but can
it be universally applied? I see issues.

Xilinx provides the FSBL and you need to make sure this is aligned to your
hardware as it contains the ps7_init code built from the SystemZ designer
interface. For some of the hard IP devices in the Zynq the FDT can work but I am
not sure about the specialised parts like the AXI bus configurations unless it
is exported from the Xilinx tools and complete. Then there is secure mode and
non-bricking issues which the Xilinx FSBL has some support for but I have not
seen in u-boot. All Zynq Linux systems I have seen do not have these things.

> If it boots via a device tree, then the RTEMS BSP should do this as well.

How would you integrate the Xilinx tools to handle this, ie ps7_init and 
friends?

U-boot provides the FSBL equivalent, MLO or something like that, that is
specific to a build of hardware for example the Microzed. I do not think a
Microzed build will operate on a Picozed as it has 1G of RAM and there is no
support for a Picozed in u-boot master or Xilinx's u-boot fork. I suspect it is
in the Petalinux source tarball. U-boot is GPL and some places ban GPL of all
forms on a target.

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