QEMU IRL not modeled

[Sam Price]

Debugging some qemu interrupts with the uarts on the microblaze platform.

I noticed i was getting some transactions failed on the qemu side.

interrupt at pc=802dec88 msr=1a2 0 iflags=100
Transaction failed: vaddr 0x41200024 physaddr 0x41200024 size
4 access type DATA_LOAD
Transaction failed: vaddr 0x41200024 physaddr 0x41200024 size
4 access type DATA_STORE
Transaction failed: vaddr 0x41200024 physaddr 0x41200024 size
4 access type DATA_STORE

This is the interrupt controller.

24 offset is the ILR register
24h ILR Interrupt Level Register (ILR)
```
The Interrupt Level Register (ILR) is a read-write register that
contains the ordinal value of the highest priority interrupt prevented
from generating a processor IRQ. The ILR provides a method to block
lower priority interrupts in order to support nested interrupt
handling. When the ILR is 0, no interrupt is allowed to generate IRQ,
when the ILR is 1 only INT(0) is allowed to generate IRQ, etc. If all
interrupts are allowed to generate IRQ, the ILR should contain all
ones. The ILR is shown in Figure 2-10 and described in Table 2-14.

Rtems microblaze is most likely writing to this register here.
https://github.com/RTEMS/rtems/blob/master/bsps/microblaze/microblaze_fpga/irq/irq.c#L140

Its not totally apparent to me why interrupts are disabled and then
re-enable in an interrupt context.

Is this needed?  I started looking through qemu code, but haven't
quite figured out how to patch it to support the irl.

>From what i can tell
https://github.com/Xilinx/qemu/blob/master/target/microblaze/cpu.c#L153

Interrupt registers actually firing.
https://github.com/Xilinx/qemu/blob/master/target/microblaze/helper.c#L180
-- 
Sincerely,

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

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Sam Price]

I was trying to debug while only some of the uart interrupt vectors
seem to work on the microblaze.
I thought it would be nice to compile qemu with debug flags.

Also eventually I would like to develop my own firmware driver
emulation for qemu.  Which would probably require me to have my own
qemu fork anyways.

I think just integrating all the rtems patches into a fork and
changing the remote would work, but maybe im am missing something.

Thanks for the reply.
If I get some free time to hack on this and figure anything out i will
let you know.

Sam.
On Wed, Feb 14, 2024 at 2:37 PM Kinsey Moore  wrote:
>
> On Wed, Feb 14, 2024 at 9:14 AM Sam Price  wrote:
>>
>> I was wondering if you had any notes on your process of working with
>> qemu in the rtems builder.
>> I imagine you have your own xilinx qemu forked to work on, and then
>> take the patches and integrate them into the rsb builder?
>
>
> Nothing so fancy. Here's my current setup for this:
> * have a checkout of the qemu-xilinx repo to generate patches
> * copy generated patches into the rsb/rtems/patches directory
> * set up the RSB recipe to pull in the patch with appropriate SHA512
> * attempt build
>
> This lets me pull in a custom patch for testing without actually hosting it 
> somewhere. I've been wanting an easier way to do this since it's a pain to 
> push patches elsewhere for test hosting before actually pushing it to the 
> ticket, but this is the compromise I've settled on that smooths out the 
> workflow just enough. Ideally, I'd be able to specify a local file path for a 
> patch for test purposes, but that would necessitate some very verbose flag to 
> sb-set-builder like --really-allow-local-patches-just-for-test-purposes 
> because we really don't want to host these patches within RSB.
>
> Kinsey



-- 
Sincerely,

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

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Sam Price]

I was wondering if you had any notes on your process of working with
qemu in the rtems builder.
I imagine you have your own xilinx qemu forked to work on, and then
take the patches and integrate them into the rsb builder?

Thanks,
Sam

On Sun, Feb 11, 2024 at 9:51 PM Kinsey Moore  wrote:
>
> GCC 13.2.0 adds new warnings/errors when mixing ints and enums. This
> changes the pminsn helper type to correctly use enums.
> ---
>  bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg 
> b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> index ca70ebd..6352268 100644
> --- a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> +++ b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> @@ -24,6 +24,13 @@
>  %hash sha512 xlnx_cgem_zynqmp_versal.patch \
>
> tGjJn7o8/fQwdC0sgsYmPW6bqDzMkwhKRqBwuuy8sdEKivDj7uGISMj7p8Iwy9fkHiO3Dd3feno+iz5fHYGBkA==
>
> +#
> +# Patch to fix PPC64 build under GCC 13.2.0
> +#
> +%patch add qemu --rsb-file=xlnx_ppc64_enum.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4988/0001-target-ppc-Resolve-int-enum-mismatch-on-ppc64.patch
> +%hash sha512 xlnx_ppc64_enum.patch \
> +  
> afYfClJ5IO9eV23dOAqxurzAnwS1YmiOEPCts/ftXS/ddXp9Rx2oQYuKeZriawKw7MVlqWNv9eTc5ERoFhRKOg==
> +
>  #
>  # The Qemu build instructions. We use 5.x.x Release 1.
>  #
> --
> 2.39.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

Re: [PATCH] build: Add RTEMS_QUALIFIED

[Sam Price]

set of files brought in by those subsets. I'm not
> interested in maintenance burden of two versions of basically the same
> code. This will eventually lead to inconsistencies. I understand the
> intent may be to have a code base closer to what can be ultimately
> qualified, but I see this as problematic from a long-term maintenance
> perspective.
>
> What I see here is that certain APIs are being circumvented presumably
> because they are not part of someone's qualified package. As far as I
> know, the goal of pre-qual was never to create qualified packages, but
> to make it easier for downstream users to make qualified packages of
> their choosing. Pushing constraints back into rtems.git because of an
> inability to qualify some parts of the code is opposite of the goal.
> It is like a somewhat kinder form of stripping down RTEMS to what is
> qualified and shipping that, which is what I understood to be the
> previous methodology that should be avoided.
>
> I would also not like to see variations of the same files for
> different "profiles" or qualified targets.
>
> Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

device tree loading from uboot.

[Sam Price]

i want to test the device tree loading stuff in qemu.
I don't see a way to set the r5 register on startup via command line in qemu.


void bsp_fdt_copy(const void *src)
{
  const volatile uint32_t *s = (const uint32_t *) src;

im tempted to either hard code the src location rather than passing it in via r5
or add a check if the passed in value is null then use a hard coded address.
if(src == 0x0)
{
  s = BSP_START_COPY_FDT_ADDRESS;
}

qemu can then take a address for the device tree file and place it in
the proper memory address

-device loader,file=$DTB_FILE,addr=$BSP_START_COPY_FDT_ADDRESS,force-raw=true \

Does this seem reasonable or is there a way people are testing device
tree support in qemu by setting the r5 register on startup?

-- 
Sincerely,

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

[PATCH] int64 operation test.

[Sam Price]

on microblaze there is an operation that destroys the msr on interrupt
task switches.
(addi needs switched to addik).
I was trying to add a single processor 78 test to detect this, could
someone review?


*** BEGIN OF TEST SP 78 ***
*** TEST VERSION: 6.0.0.227fd7cbb84a286983ec2b4cea3a24b9836692cb
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.5.0 20230707 (RTEMS 6, RSB
2c95b275714ff8d90bc16ef30ab861ecb54ef0a8-modified, Newlib a021448)
Mod64 failed pos 1831 16 != -4294967280

mod64_failed FAILED -- expected (RTEMS_SUCCESSFUL) got (?)

[ RTEMS shutdown ]
RTEMS version: 6.0.0.227fd7cbb84a286983ec2b4cea3a24b9836692cb
RTEMS tools: 10.5.0 20230707 (RTEMS 6, RSB
2c95b275714ff8d90bc16ef30ab861ecb54ef0a8-modified, Newlib a021448)
executing thread ID: 0x0a010001
executing thread name: UI1

if i patch addi with addik


*** BEGIN OF TEST SP 78 ***
*** TEST VERSION: 6.0.0.227fd7cbb84a286983ec2b4cea3a24b9836692cb
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.5.0 20230707 (RTEMS 6, RSB
2c95b275714ff8d90bc16ef30ab861ecb54ef0a8-modified, Newlib a021448)

*** END OF TEST SP 78 ***


[ RTEMS shutdown ]
RTEMS version: 6.0.0.227fd7cbb84a286983ec2b4cea3a24b9836692cb
RTEMS tools: 10.5.0 20230707 (RTEMS 6, RSB
2c95b275714ff8d90bc16ef30ab861ecb54ef0a8-modified, Newlib a021448)
executing thread ID: 0x0a010001
executing thread name: UI1




---
 spec/build/testsuites/sptests/grp.yml |   2 +
 testsuites/sptests/sp78/init.c| 106 ++
 testsuites/sptests/sp78/sp78.doc  |  37 +
 testsuites/sptests/sp78/sp78.scn  |   2 +
 4 files changed, 147 insertions(+)
 create mode 100644 testsuites/sptests/sp78/init.c
 create mode 100644 testsuites/sptests/sp78/sp78.doc
 create mode 100644 testsuites/sptests/sp78/sp78.scn

diff --git a/spec/build/testsuites/sptests/grp.yml
b/spec/build/testsuites/sptests/grp.yml
index 7676f2cb36..bc5b0fddf1 100644
--- a/spec/build/testsuites/sptests/grp.yml
+++ b/spec/build/testsuites/sptests/grp.yml
@@ -164,6 +164,8 @@ links:
   uid: sp76
 - role: build-dependency
   uid: sp77
+- role: build-dependency
+  uid: sp78
 - role: build-dependency
   uid: spassoc01
 - role: build-dependency
diff --git a/testsuites/sptests/sp78/init.c b/testsuites/sptests/sp78/init.c
new file mode 100644
index 00..03254ae175
--- /dev/null
+++ b/testsuites/sptests/sp78/init.c
@@ -0,0 +1,106 @@
+/*
+ *  COPYRIGHT (c) 2012.
+ *  Krzysztof Miesowicz 
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include "test_support.h"
+
+#define STRESS_COUNT 10
+#define TEST_OFFSET 0x1b3d70   // Some arbitrary offset
+
+typedef struct test_data_container{
+  int64_t divide[STRESS_COUNT];
+  int64_t mod[STRESS_COUNT];
+  int64_t mul[STRESS_COUNT];
+}test_data_container;
+
+test_data_container truth_data;
+test_data_container test_data;
+
+const char rtems_test_name[] = "SP 78";
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument argument);
+void build_test_data(test_data_container * data);
+void check_test_data(test_data_container * truth, test_data_container * data);
+rtems_task Init(
+  rtems_task_argument argument
+)
+{
+  TEST_BEGIN();
+
+  int lcv; /* Loop control variable */
+  rtems_interrupt_lock_context lock_contex;
+  // rtems_interrupt_lock interrupt_lock;
+
+  /* Lock interrupts to create truth data */
+  rtems_interrupt_lock_acquire(interrupt_lock, _contex);
+  build_test_data(_data);
+  rtems_interrupt_lock_release(interrupt_lock, _contex);
+  for(lcv=0;lcv<10;lcv++){
+  build_test_data(_data);
+  check_test_data(_data, _data);
+  }
+
+  TEST_END();
+
+  rtems_test_exit(0);
+}
+
+void build_test_data(test_data_container * data){
+volatile int64_t size;
+volatile int64_t div_check;
+volatile int64_t mod_check;
+volatile int64_t mul_check;
+for (int i = 0; i < STRESS_COUNT; i++) {
+size = TEST_OFFSET*i;
+
+div_check =  size / 128;
+mod_check = size % 128;
+mul_check = size * 128;
+
+data->divide[i] = div_check;
+data->mod[i] = mod_check;
+data->mul[i] = mul_check;
+}
+}
+void check_test_data(test_data_container * truth, test_data_container * data){
+for (int i = 0; i < STRESS_COUNT; i++) {
+  if( truth->divide[i] != data->divide[i]){
+  printf( "Divide64 failed pos %i %lld != %lld\n", i,
truth->divide[i], data->divide[i] );
+  directive_failed( -1, "divide64_failed" );
+  }
+  if( truth->mod[i] != data->mod[i]){
+  printf( "Mod64 failed pos %i %lld != %lld\n", i,
truth->mod[i], data->mod[i] );
+  directive_failed( -1, "mod64_failed" );
+  }
+  if( truth->mul[i] != data->mul[i]){
+  printf( "Mul64 failed pos %i %lld != %lld\n", i,
truth->mul[i], data->mul[i] );
+  directive_failed( -1, 

[PATCH 1/1] rtems-tools: stty rename / spelling bug.

[Sam Price]

This patch fixes a spelling/rename mistake in rtems-tools.

---
 tester/rt/stty.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/rt/stty.py b/tester/rt/stty.py
index 130318d..fca026a 100644
--- a/tester/rt/stty.py
+++ b/tester/rt/stty.py
@@ -558,7 +558,7 @@ class tty(object):
 self._update()

 def read(self):
-return self.fs.read()
+return self.fd.read()

 if __name__ == "__main__":
 if len(sys.argv) == 2:
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/5] testsuites/libtests: Remove floats from libdl tests

[Sam Price]

Nevermind that would be done at the linker and not at compile time.

On Mon, Aug 28, 2023 at 11:04 AM Sam Price  wrote:
>
> Just curious instead of doing #ifdef __microblaze__
> could you do
> #ifndef __extendsfdf2
>
> Or something similar to determine if the floating point symbols are known?
>
> This would make it more portable.
>
> On Mon, Aug 28, 2023 at 10:11 AM Alex White  wrote:
> >
> > On Sun, Aug 27, 2023 at 11:48 PM Chris Johns  wrote:
> > >
> > > On 28/8/2023 2:12 pm, Alex White wrote:
> > > > On Sun, Aug 27, 2023 at 8:38 PM Chris Johns  wrote:
> > > >> The floats need to stay to make sure there are no issues with this 
> > > >> type. I see
> > > >> the tests with floats as valid.
> > > >>
> > > >> Is the only missing function `__extendsfdf2`?
> > > >
> > > > Yes, that is the only missing function. If I change the floats to 
> > > > doubles, the
> > > > need for `__extendsfdf2` goes away and the tests pass. Is that an 
> > > > acceptable
> > > > solution?
> > >
> > > I would happy with doubles being added so they are tested as well but 
> > > that is
> > > also outside the scope of your effort :)
> > >
> > > Is it easier to add a Microblaze conditional for the use of a double to 
> > > the base
> > > image and to forced the symbol to be linked in?
> >
> > I don't think it's too hard to add a conditional to the base image. For
> > instance, this modification to dl07 is enough to make it pass on MicroBlaze:
> >
> > diff --git a/testsuites/libtests/dl07/init.c 
> > b/testsuites/libtests/dl07/init.c
> > index 8db106ba29..7fb1500660 100644
> > --- a/testsuites/libtests/dl07/init.c
> > +++ b/testsuites/libtests/dl07/init.c
> > @@ -67,6 +67,14 @@ static void Init(rtems_task_argument arg)
> >
> >TEST_BEGIN();
> >
> > +#ifdef __microblaze__
> > +  /* This is just here to link `__extendsfdf2` into the base image. */
> > +  {
> > +float f = 0.;
> > +printf("f: %f\n", f);
> > +  }
> > +#endif /* __microblaze__ */
> > +
> >te = rtems_tarfs_load("/", (void *)TARFILE_START, (size_t)TARFILE_SIZE);
> >if (te != 0)
> >{
> >
> > Is that what you were thinking?
> >
> > Alex
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
> Sincerely,
>
> Sam Price



-- 
Sincerely,

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

Re: [PATCH 2/5] testsuites/libtests: Remove floats from libdl tests

[Sam Price]

Just curious instead of doing #ifdef __microblaze__
could you do
#ifndef __extendsfdf2

Or something similar to determine if the floating point symbols are known?

This would make it more portable.

On Mon, Aug 28, 2023 at 10:11 AM Alex White  wrote:
>
> On Sun, Aug 27, 2023 at 11:48 PM Chris Johns  wrote:
> >
> > On 28/8/2023 2:12 pm, Alex White wrote:
> > > On Sun, Aug 27, 2023 at 8:38 PM Chris Johns  wrote:
> > >> The floats need to stay to make sure there are no issues with this type. 
> > >> I see
> > >> the tests with floats as valid.
> > >>
> > >> Is the only missing function `__extendsfdf2`?
> > >
> > > Yes, that is the only missing function. If I change the floats to 
> > > doubles, the
> > > need for `__extendsfdf2` goes away and the tests pass. Is that an 
> > > acceptable
> > > solution?
> >
> > I would happy with doubles being added so they are tested as well but that 
> > is
> > also outside the scope of your effort :)
> >
> > Is it easier to add a Microblaze conditional for the use of a double to the 
> > base
> > image and to forced the symbol to be linked in?
>
> I don't think it's too hard to add a conditional to the base image. For
> instance, this modification to dl07 is enough to make it pass on MicroBlaze:
>
> diff --git a/testsuites/libtests/dl07/init.c b/testsuites/libtests/dl07/init.c
> index 8db106ba29..7fb1500660 100644
> --- a/testsuites/libtests/dl07/init.c
> +++ b/testsuites/libtests/dl07/init.c
> @@ -67,6 +67,14 @@ static void Init(rtems_task_argument arg)
>
>TEST_BEGIN();
>
> +#ifdef __microblaze__
> +  /* This is just here to link `__extendsfdf2` into the base image. */
> +  {
> +float f = 0.;
> +printf("f: %f\n", f);
> +  }
> +#endif /* __microblaze__ */
> +
>te = rtems_tarfs_load("/", (void *)TARFILE_START, (size_t)TARFILE_SIZE);
>if (te != 0)
>{
>
> Is that what you were thinking?
>
> Alex
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

Re: Tool versions for RTEMS 6.1 release?

[Sam Price]

How hard are the microblaze patches going to be to apply?

On Fri, Jun 30, 2023 at 1:19 PM Kinsey Moore 
wrote:

> On Fri, Jun 30, 2023 at 11:58 AM Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Jun 30, 2023 at 1:26 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello,
>>>
>>> it seems the RTEMS 6.1 release is getting closer. We should think about
>>> the tool versions for the release.
>>>
>>> For GCC, my preferred choice would be GCC 13.2:
>>>
>>> https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html
>>>
>>> In GCC 12 a big change was enabling the vectorization support with -O2.
>>> This should have stabilized in GCC 13. GCC 13 contains some
>>> RTEMS-specific improvements for Ada.
>>>
>>
>> I think I am generally ok with moving to 13.2 since we want to be
>> reasonably
>> current when the branch happens.
>>
>> Do you know of any Ada users with Adacore support for GNAT/RTEMS?
>> I am aware of one case and they are using GCC 11 as a base so we already
>> have a mismatch. The user builds RSB tools with TLS disabled for
>> compatibility.
>>  I know this isn't a community concern but if we have more Ada users, we
>> want to do
>> right by them.
>>
>> I also was asked about using FORTRAN recently.
>>
>> I'd like to say the same thing about Rust users. :)
>>
>>>
>>> For Binutils and GDB I would just use the latest release available at
>>> the RTEMS 6 branch point.
>>>
>>
> Be aware that I have recently rolled 6.1 binutils back from 2.40 to 2.39
> due to a regression in the AArch64 toolchain. The latest release is still
> 2.40, so please don't roll that forward until the 2.41 release is out and
> is verified to have the fix.
>
> Kinsey
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Sincerely,

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

Re: doctest rtems example

[Sam Price]

I was testing the out of box version of gtest.
It does not support parsing arguments more than once.
I think you have to load / unload the library between runs.

I would really prefer to use google test.  Its what most of our tests
are already in, and has support for utbot.org

Sam

On Sun, Jun 18, 2023 at 7:25 PM Chris Johns  wrote:
>
> Hi Sam,
>
> Thanks for the post. The website for the code is:
>
> https://github.com/doctest/doctest
>
> I have been using this and I can port tests between Linux and RTEMS. I like it
> because it works and it is a single header. There is no need to build and link
> libraries.
>
> Chris
>
> On 16/6/2023 11:07 pm, Sam Price wrote:
> > /* Tell doctest to not use its own main */
> > #define DOCTEST_CONFIG_IMPLEMENT
> > /* tell doctest to not use sigint that rtems does not have */
> > #define DOCTEST_CONFIG_NO_POSIX_SIGNALS
> > #include "doctest.h"
> >
> > /* Setup command line part */
> > const char rtems_test_name[] = "DOCTEST UNIT TESTS";
> >
> > static int run_doctest_tests(int argc, char **argv) {
> >
> > // Initialize doctest context
> > doctest::Context context(argc, argv);
> >
> > int test_result = context.run(); // run queries, or run tests unless 
> > --no-run
> >
> > if(context.shouldExit()) // honor query flags and --exit
> > return test_result;
> > return 0;
> > }
> >
> > rtems_shell_cmd_t Shell_DOCTEST_Command = {
> > "doctest", /* name */
> > "doctest [doctest options]", /* usage */
> > "tests", /* topic */
> > run_doctest_tests, /* command */
> > NULL, /* alias */
> > NULL /* next */
> > };
> >
> > /* Inside of your Init add the following prior to starting shell */
> > rtems_task Init(rtems_task_argument ignored)
> > {
> > 
> >
> > rtems_shell_add_cmd_struct(_DOCTEST_Command);
> > /* Note i made this high priority, some of my tests require priority 
> > access. */
> > /* It may be better to use 100, and use the following in your test
> > rtems_task_priority old_priority;
> > rtems_task_set_priority(RTEMS_SELF, 0, _priority);
> > ...
> > rtems_task_set_priority(RTEMS_SELF, old_priority, 0x0);
> > */
> >
> > rtems_shell_init("shell0", 20 * 1024, 2, "/dev/console", 0, 1, NULL);
> > ...
> > }
> >
> > TEST_CASE("testing the addition function") {
> > CHECK((2 + 2) == 4);
> > CHECK((2 + 2) == 4.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



-- 
Sincerely,

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

doctest rtems example

[Sam Price]

/* Tell doctest to not use its own main */
#define DOCTEST_CONFIG_IMPLEMENT
/* tell doctest to not use sigint that rtems does not have */
#define DOCTEST_CONFIG_NO_POSIX_SIGNALS
#include "doctest.h"

/* Setup command line part */
const char rtems_test_name[] = "DOCTEST UNIT TESTS";

static int run_doctest_tests(int argc, char **argv) {

// Initialize doctest context
doctest::Context context(argc, argv);

int test_result = context.run(); // run queries, or run tests unless --no-run

if(context.shouldExit()) // honor query flags and --exit
return test_result;
return 0;
}

rtems_shell_cmd_t Shell_DOCTEST_Command = {
"doctest", /* name */
"doctest [doctest options]", /* usage */
"tests", /* topic */
run_doctest_tests, /* command */
NULL, /* alias */
NULL /* next */
};

/* Inside of your Init add the following prior to starting shell */
rtems_task Init(rtems_task_argument ignored)
{


rtems_shell_add_cmd_struct(_DOCTEST_Command);
/* Note i made this high priority, some of my tests require priority access. */
/* It may be better to use 100, and use the following in your test
rtems_task_priority old_priority;
rtems_task_set_priority(RTEMS_SELF, 0, _priority);
...
rtems_task_set_priority(RTEMS_SELF, old_priority, 0x0);
*/

rtems_shell_init("shell0", 20 * 1024, 2, "/dev/console", 0, 1, NULL);
...
}

TEST_CASE("testing the addition function") {
CHECK((2 + 2) == 4);
CHECK((2 + 2) == 4.0);
}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

unit test framework

[Sam Price]

was reading through
https://docs.rtems.org/branches/master/eng/test-framework.html#test-framework-requirements-for-rtems

t.h
I think needs changed to test.h or rtems/test.h

Was trying to stand up a test framework for my board.
Wanted command line arg support though so switched to trying doctest/gtest.
The code in rtems didnt seem to use cli / shell support to launch the
test suite.

-- 
Sincerely,

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

Re: Static analysis

[Sam Price]

Thanks Alex,
I was able to write a variable analyzer using the compile_database.

https://gist.github.com/thesamprice/d4a19102aa4fe11fb96a75df57b9fcfe

On Mon, May 15, 2023 at 9:31 PM Sam Price  wrote:
>
> Thanks Alex,
> I was able to run cppcheck.
> I had to install the newest cppcheck from source to get access to the
> --project flag.
> i ran
> bear ./waf
> and then
> cppcheck --project=compile_commands.json
>
> It returned a few static analysis errors if interested.
> I'll attach the results when it finishes running.
> It is possible I don't have this configured properly, and its using
> its own #defines
>
>
> On Mon, May 15, 2023 at 11:03 AM Alex White  wrote:
> >
> > You should be able to use `bear` (https://github.com/rizsotto/Bear). I have 
> > it installed via my package manager.
> >
> > After a `./waf clean`, run `bear -- ./waf` to generate 
> > compile_commands.json. Then you should be able to run `cppcheck 
> > --project=compile_commands.json`.
> >
> > Alex
>
>
>
> --
> Sincerely,
>
> Sam Price



-- 
Sincerely,

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

Re: Static analysis

[Sam Price]

c:452:24: note: Integer overflow
  if ( (gigs & ( 1 << b) ) != 0 )
   ^
cpukit/libfs/src/dosfs/msdos_format.c:590:24: error: Signed integer
overflow for expression '1< 0; b--)
   ^
cpukit/libfs/src/dosfs/msdos_format.c:590:24: note: Integer overflow
if ((gigs & (1 << b)) != 0)
   ^
cpukit/libblock/src/media.c:637:16: warning: Uninitialized variables:
partitions.begin, partitions.end, partitions.flags [uninitvar]
  .begin = partitions [i].begin,
   ^
cpukit/libblock/src/media.c:708:45: note: Calling function
'attach_and_mount_partitions', 2nd argument 'partitions' value is

  sc = attach_and_mount_partitions(src, partitions, count);
^
cpukit/libblock/src/media.c:637:16: note: Uninitialized variables:
partitions.begin, partitions.end, partitions.flags
  .begin = partitions [i].begin,
   ^
cpukit/libblock/src/bdbuf.c:396:3: warning: Uninitialized variable: q
[uninitvar]
  q->avl.left = q->avl.right = NULL;
  ^
cpukit/libblock/src/bdbuf.c:361:12: note: Assuming condition is false
  while (p != NULL)
   ^
cpukit/libblock/src/bdbuf.c:396:3: note: Uninitialized variable: q
  q->avl.left = q->avl.right = NULL;
  ^

On Mon, May 15, 2023 at 9:31 PM Sam Price  wrote:
>
> Thanks Alex,
> I was able to run cppcheck.
> I had to install the newest cppcheck from source to get access to the
> --project flag.
> i ran
> bear ./waf
> and then
> cppcheck --project=compile_commands.json
>
> It returned a few static analysis errors if interested.
> I'll attach the results when it finishes running.
> It is possible I don't have this configured properly, and its using
> its own #defines
>
>
> On Mon, May 15, 2023 at 11:03 AM Alex White  wrote:
> >
> > You should be able to use `bear` (https://github.com/rizsotto/Bear). I have 
> > it installed via my package manager.
> >
> > After a `./waf clean`, run `bear -- ./waf` to generate 
> > compile_commands.json. Then you should be able to run `cppcheck 
> > --project=compile_commands.json`.
> >
> > Alex
>
>
>
> --
> Sincerely,
>
> Sam Price



-- 
Sincerely,

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

Re: Static analysis

[Sam Price]

Thanks Alex,
I was able to run cppcheck.
I had to install the newest cppcheck from source to get access to the
--project flag.
i ran
bear ./waf
and then
cppcheck --project=compile_commands.json

It returned a few static analysis errors if interested.
I'll attach the results when it finishes running.
It is possible I don't have this configured properly, and its using
its own #defines


On Mon, May 15, 2023 at 11:03 AM Alex White  wrote:
>
> You should be able to use `bear` (https://github.com/rizsotto/Bear). I have 
> it installed via my package manager.
>
> After a `./waf clean`, run `bear -- ./waf` to generate compile_commands.json. 
> Then you should be able to run `cppcheck --project=compile_commands.json`.
>
> Alex



-- 
Sincerely,

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

Static analysis

[Sam Price]

I was trying to run scan-build on a microblaze build.
However scan-build wasn't seeing any files get built.
I then tried to revert down to the intercept-build command, and it
generated an empty compilation database.
/usr/share/clang/scan-build-py-10/bin/intercept-build --override-compiler  ./waf
Is supposed to dump out a compilation database that scan-build is using.

Sadly its not intercepting the compile commands from waf.

For scan build I think waf should be able to generate the compile
database. Also unsure where to add the waf magic.
def configure(conf):
conf.load('compiler_cxx')
...
conf.load('clang_compilation_database')

And then pass that compile database into scan-build

scan-build -o /path/to/report/directory -p /path/to/compile_commands.json


Somewhere in waf I should be able to add some magic to use cppcheck
but am unsure where to add that logic.

import waftools

def options(opt):
opt.load('cppcheck', tooldir=waftools.location)

def configure(conf):
conf.load('cppcheck')

And then be able to use cppcheck on the build.
waf build --cppcheck
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Sam Price]

Yaml files can have comments, json files can’t.  So you would lose some
documentation…
-- 
Sincerely,

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

Re: [PATCH 2/3] bsps/microblaze: Add support for multiple UARTs

[Sam Price]

Same IP as the regular KCU105.
The current uart ip is dependent on the fpga.
I don't believe this modifies the kcu105 bsp, but allows other bsps to
support up to 4 uarts.

On Wed, Mar 29, 2023 at 5:21 PM Chris Johns  wrote:
>
> On 30/3/2023 6:22 am, Alex White wrote:
> > From: "Maldonado, Sergio E. (GSFC-580.0)"  >  .../microblaze/microblaze_fpga/optuartirq.yml |  20 ++
> >  .../microblaze/microblaze_fpga/optuseuart.yml |  17 ++
> >  .../microblaze_fpga/optuseuart1.yml   |  17 ++
> >  .../microblaze_fpga/optuseuart2.yml   |  17 ++
> >  .../microblaze_fpga/optuseuart3.yml   |  17 ++
> >  .../microblaze_fpga/optuseuart4.yml   |  17 ++
>
> Are these 4 UARTs dependent on the IP built into the FPGA with the Microblaze 
> core?
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

rtems gtest

[Sam Price]

I was looking at rtems-gtest from 4 years ago.
https://git.rtems.org/sebh/rtems-gtest.git/
Is this currently in use anywhere for the testing side?
If not I plan on forking the main line google test and writing a toolchain file.
The rtems gtest doesn't seem to share the same history as the official
google test repo.
-- 
Thanks,
Sam Price
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Build error microblaze

[Sam Price]

Getting the following build error when building microblaze, and wanted
to see if anyone else has run into this issue.
I think I'm supposed to be using master on lib bsd and not 6-freebsd-12.

[1303/1988] Compiling freebsd/sys/netinet/libalias/alias_skinny.c
../../freebsd/sys/netinet/sctp_output.c:61:10: fatal error:
machine/in_cksum.h: No such file or directory
   61 | #include 

Lib bsd hash
* 7a12651b (HEAD -> master, navigator/master) libbsd: Add TFTP
filesystem to test media01
Rtems hash
| * 5b124432e2 (HEAD -> master, origin/master, origin/HEAD) build: Fix
copyright statement format

-- 
Sincerely,

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

microblaze 2nd timer

[Sam Price]

I wanted to add secondary timer support to the microblaze bsp.
I have an initial working change to the rtems source here

https://github.com/RTEMS/rtems/compare/master...thesamprice:rtems:timer_debug

And an initial test example here
https://github.com/thesamprice/rtems_mb_timer
Unsure how to integrate this test into rtems test framework.

I renamed bsp/timer.h to bsp/microblaze-timer.h at
bsps/microblaze/microblaze_fpga/include/bsp/microblaze-timer.h
Hoping this would avoid polluting the namespace?
timer.h seemed generic to me.
There seems to be a mix of names for this approach

The microblaze shares a single interrupt vector for all interrupts.
Also the timers share the same timer interrupt vector so you have to
check both of their registers.

I would like to do a follow up to this getting the timer tests to use
the microblaze counter.

Does this look ready for a patch?  Should I follow the patch
instructions and submit?

-- 
Sincerely,

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

Doorstop question

[Sam Price]

Im starting to use doorstop for my project.
I heard that RTEMS uses a customized version of it, and wanted to see
what the differences were.

I was trying to find it on https://git.rtems.org/
But can't seem to find the customized version.

-- 
Sincerely,

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

Re: Microblaze 2nd timer interrupt

[Sam Price]

I pushed my changes to rtems source
https://github.com/RTEMS/rtems/compare/master...thesamprice:rtems:timer_debug

and setup a hello world an example project to test with
https://github.com/thesamprice/rtems_mb_timer/blob/main/hello.c

However im getting the following error.
rtems_mb_timer/hello.c:8:10: fatal error: bsp/timer.h: No such file or directory
8 | #include 
  |  ^

Is the correct approach to just put all bsp specific calls in bsp.h?


On Sat, Nov 5, 2022 at 10:04 PM Sam Price  wrote:
>
> The current microblaze design only has a single timer.
>
> I want to use the 2nd timer on the microblaze to run some low level tasks.
>
> Wondering if someone could see if i'm on the right track.
>
>
> Regarding the timer from the Xilinx api api
>
> """The interrupt service routine reads the timer control/status
> registers to determine the source of the interrupt."""
>
> Also there is a interrupt controller on microblaze that has a single
> jump register.
>
>
> So the underlying logic is interrupt occurs, 32bit interrupt register
> is checked for what bits are set determining what interrupts have
> occured.
>
>
> if bit 0 is set then it is a clock interrupt.
>
>
> Then 2 clock register need checked for what timer caused the interrupt.
>
>
> Current RTEMS implementation only uses 1 of the timers.
>
>
>
>
>
> I added static ISR callbacks for the system and user callback at the
> top of the mb clock.c file.
>
> static rtems_interrupt_handler mblaze_clock_isr = 0x0;
>
> static rtems_interrupt_handler mblaze_user_isr = 0x0;
>
>
>
> I added a callback that checks both registers and calls the
> appropriate callback.
>
>
>
> static void microblaze_clock_handler( void * data){
>
>   volatile Microblaze_Timer *timer = _Microblaze_Timer;
>
>   if ( ( timer->tcsr0 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )
>
>   {
>
> if(mblaze_clock_isr != 0x0){
>
>   mblaze_clock_isr(data);
>
> }
>
>   }
>
>   if ( ( timer->tcsr1 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )
>
>   {
>
> if(mblaze_user_isr != 0x0){
>
>   mblaze_user_isr(data);
>
>   /* Clear the interrupt */
>
>   timer->tcsr1 |= MICROBLAZE_TIMER_TCSR0_T0INT;
>
> }
>
>   }
>
> }
>
>
>
>
>
> I updated the ISR register to store the system clock, and replace the
> isr callback with mine.
>
>
>
> static void microblaze_clock_handler_install( rtems_interrupt_handler isr )
>
> {
>
>   rtems_status_code sc = RTEMS_SUCCESSFUL;
>
>   mblaze_clock_isr = isr; <- Store the system ISR
>
>   sc = rtems_interrupt_handler_install(
>
> 0,
>
> "Clock",
>
> RTEMS_INTERRUPT_UNIQUE,
>
> microblaze_clock_handler, <- Changed from ISR to my new handler.
>
> NULL
>
>   );
>
>
>
>   if ( sc != RTEMS_SUCCESSFUL ) {
>
> bsp_fatal( MICROBLAZE_FATAL_CLOCK_IRQ_INSTALL );
>
>   }
>
> }
>
>
>
> To the microblaze bsp.h
>
>
> im adding my callback functions to register the users clock function.
>
> void microblaze_user_clock_handler_install(rtems_interrupt_handler isr);
>
>
> And the appropriate non static function to the mb clock.c file
>
> void microblaze_user_clock_handler_install(rtems_interrupt_handler isr){
> mblaze_user_isr = isr;
> }
>
> Anyhow about to compile and see if it works.



-- 
Sincerely,

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

Microblaze 2nd timer interrupt

[Sam Price]

The current microblaze design only has a single timer.

I want to use the 2nd timer on the microblaze to run some low level tasks.

Wondering if someone could see if i'm on the right track.


Regarding the timer from the Xilinx api api

"""The interrupt service routine reads the timer control/status
registers to determine the source of the interrupt."""

Also there is a interrupt controller on microblaze that has a single
jump register.


So the underlying logic is interrupt occurs, 32bit interrupt register
is checked for what bits are set determining what interrupts have
occured.


if bit 0 is set then it is a clock interrupt.


Then 2 clock register need checked for what timer caused the interrupt.


Current RTEMS implementation only uses 1 of the timers.





I added static ISR callbacks for the system and user callback at the
top of the mb clock.c file.

static rtems_interrupt_handler mblaze_clock_isr = 0x0;

static rtems_interrupt_handler mblaze_user_isr = 0x0;



I added a callback that checks both registers and calls the
appropriate callback.



static void microblaze_clock_handler( void * data){

  volatile Microblaze_Timer *timer = _Microblaze_Timer;

  if ( ( timer->tcsr0 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )

  {

if(mblaze_clock_isr != 0x0){

  mblaze_clock_isr(data);

}

  }

  if ( ( timer->tcsr1 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )

  {

if(mblaze_user_isr != 0x0){

  mblaze_user_isr(data);

  /* Clear the interrupt */

  timer->tcsr1 |= MICROBLAZE_TIMER_TCSR0_T0INT;

}

  }

}





I updated the ISR register to store the system clock, and replace the
isr callback with mine.



static void microblaze_clock_handler_install( rtems_interrupt_handler isr )

{

  rtems_status_code sc = RTEMS_SUCCESSFUL;

  mblaze_clock_isr = isr; <- Store the system ISR

  sc = rtems_interrupt_handler_install(

0,

"Clock",

RTEMS_INTERRUPT_UNIQUE,

microblaze_clock_handler, <- Changed from ISR to my new handler.

NULL

  );



  if ( sc != RTEMS_SUCCESSFUL ) {

bsp_fatal( MICROBLAZE_FATAL_CLOCK_IRQ_INSTALL );

  }

}



To the microblaze bsp.h


im adding my callback functions to register the users clock function.

void microblaze_user_clock_handler_install(rtems_interrupt_handler isr);


And the appropriate non static function to the mb clock.c file

void microblaze_user_clock_handler_install(rtems_interrupt_handler isr){
mblaze_user_isr = isr;
}

Anyhow about to compile and see if it works.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Re: Possible tls bug on arm / microblaze

[Sam Price]

Sebastian,
I think you fixed this for me in this commit.
Do you know if this got run / tested on a qemu emulator?

commit 4c89fbcd316ca99fa16a0acc31f88fb80cb3060f
Author: Sebastian Huber 
Date:   Tue Sep 27 07:43:37 2022 +0200

score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

Update #3835.

On Wed, Aug 24, 2022 at 11:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> I am on holidays until 2022-08-28. For RTEMS related topics please contact
> Christian Mauderer  if it is
> urgent.
>


-- 
Sincerely,

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

Re: docs not building to PDF

[Sam Price]

Also imagine magick has a command line converter

https://imagemagick.org/script/convert.php


On Thu, Oct 13, 2022 at 3:49 AM  wrote:

> There is also Kroki: https://kroki.io/
> It does the rendering of multiple text based diagram languages, including
> PlantUML, Mermaid, Ditaa and a bunch of others.
> Then you only need one tool for it.
>
> Best regards,
>
> Jan
>
> > -Original Message-
> > From: devel  On Behalf Of Chris Johns
> > Sent: Thursday, October 13, 2022 6:22 AM
> > To: Sam Price 
> > Cc: Development 
> > Subject: Re: docs not building to PDF
> >
> > On 13/10/2022 3:15 pm, Sam Price wrote:
> > > Yes
> > > https://github.com/mermaid-js/mermaid-cli
> > > <https://github.com/mermaid-js/mermaid-cli>
> > >
> > > There are command line tools so it can be integrated into pipelines.
> > >
> > >
> > >   Convert Mermaid mmd Diagram File To SVG
> > >
> > > mmdc -i input.mmd -o output.svg
> > >
> > >
> > >
> > > <https://github.com/mermaid-js/mermaid-cli#create-a-png-with-a-dark-
> > th
> > > eme-and-transparent-background>Create A PNG With A Dark Theme And
> > > Transparent Background
> > >
> > > mmdc -i input.mmd -o output.png -t dark -b transparent
> > >
> > > You dont get much control though over how it places boxes. But it does
> > > sequence diagrams.
> > > Im using it for gantt charts.
> > >
> > > Its one of the mainstream alternatives to plantuml
> > >
> >
> > This tool looks really good and it fits the pattern of tools we can use.
> >
> > Thanks for this.
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-- 
Sincerely,

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

Re: docs not building to PDF

[Sam Price]

I forgot the loop backs. from close back to open.

On Thu, Oct 13, 2022 at 1:12 AM Chris Johns  wrote:

> On 13/10/2022 4:06 pm, Sam Price wrote:
> > example
> >
> >
> https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E
> <
> https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E
> >
> >
> > SVG link
> >
> https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow
> <
> https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow
> >
> >
> >
> > I couldn't figure out how to get semi colons to work
> > new lines are kind  of a pain also.
>
> You are a legend (pun intended) :D
>
> It is looking goo but Frank has the final say.
>
> Chris
>
> >
> > stateDiagram-v2
> >
> > initbsd:Initialize libbsd
> > initNetwork:Initialize Network
> > mkDir:const char *mount_point = "/tftp"result = mkdir( mount_point,
> S_IRWXU
> > | S_IRWXG | S_IRWXO)
> >
> > mountDir:result = mount(  "", mount_point,
> > RTEMS_FILESYSTEM_TYPE_TFTPS, RTEMS_FILESYSTEM_READ_WRITE,
> > "blocksize=1024,windowsize=4,verbose" )
> >
> > openro:fd = open( path, O_RDONLY )
> > read:bytes = read( fd, data_buffer, sizeof( data_buffer ) )
> > readclose:result = close( fd )
> > openw:fd = open( path, O_WRONLY )
> > write:bytes = write( fd, data, size )
> > writeclose:result = close( fd )
> > umount:result = unmount( mount_point )
> > rmdir:result = rmdir( mount_point )
> >
> > state fork_state <>
> > [*] --> initbsd
> > initbsd --> initNetwork
> > initNetwork --> mkDir
> > mkDir --> mountDir
> > mountDir

Re: docs not building to PDF

[Sam Price]

example

https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E

SVG link
https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow


I couldn't figure out how to get semi colons to work
new lines are kind  of a pain also.

stateDiagram-v2

initbsd: Initialize libbsd
initNetwork: Initialize Network
mkDir: const char *mount_point = "/tftp"result = mkdir( mount_point,
S_IRWXU | S_IRWXG | S_IRWXO)

mountDir: result = mount(  "", mount_point,
RTEMS_FILESYSTEM_TYPE_TFTPS, RTEMS_FILESYSTEM_READ_WRITE,
"blocksize=1024,windowsize=4,verbose" )

openro: fd = open( path, O_RDONLY )
read: bytes = read( fd, data_buffer, sizeof( data_buffer ) )
readclose: result = close( fd )
openw: fd = open( path, O_WRONLY )
write: bytes = write( fd, data, size )
writeclose: result = close( fd )
umount: result = unmount( mount_point )
rmdir: result = rmdir( mount_point )

state fork_state <>
[*] --> initbsd
initbsd --> initNetwork
initNetwork --> mkDir
mkDir --> mountDir
mountDir --> fork_state
fork_state
fork_state --> openro
openro --> read
read --> read
read --> readclose
readclose --> umount
fork_state --> openw
openw --> write
write --> write
write --> writeclose
writeclose --> umount
state umount <>
umount --> rmdir
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

[Sam Price]

Yes
https://github.com/mermaid-js/mermaid-cli

There are command line tools so it can be integrated into pipelines.
Convert Mermaid mmd Diagram File To SVG

mmdc -i input.mmd -o output.svg

Create
A PNG With A Dark Theme And Transparent Background

mmdc -i input.mmd -o output.png -t dark -b transparent

You dont get much control though over how it places boxes.
But it does sequence diagrams.
Im using it for gantt charts.

Its one of the mainstream alternatives to plantuml
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

[Sam Price]

Have you guys looked at mermaidjs for simplistic diagrams?
https://mermaid-js.github.io/mermaid/#/flowchart

You can embed it in markdown. pandoc will convert it to images for html.
it works on gitlab wiki, and prob others.

On Wed, Oct 12, 2022 at 8:31 PM Chris Johns  wrote:

>
>
> On 12/10/2022 8:56 pm, Frank Kühndel wrote:
> > Hello Chris,
> > On 10/11/22 23:47, Chris Johns wrote:
> >> On 11/10/2022 7:12 pm, Frank Kühndel wrote:
> >>> Hello Chris,
> >>>
> >>> On 10/11/22 03:09, Chris Johns wrote:
> >>>> On 10/10/2022 9:22 pm, Frank Kühndel wrote:
> >>>>> images/filesystem/tftpfs_usage.png:
> >>>>> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
> >>>> I have a greyed out image I cannot clearly see?
> >>> The image has a transparent background. Some image viewers put a gray
> pattern in
> >>> the background in those case. The PDF has naturally a white background
> on top of
> >>> which the image is displayed.
> >>>
> >>>>> images/filesystem/ftpfs_usage.svg:
> >>>>> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
> >>>>>
> >>>>> The SVG file is the source for the PNG. Both files must be placed in
> the
> >>>>> images/filesystem folder.
> >>>> How is the SVG file created and how can it be edited?
> >>> I used Inkscape. It should be possible to edit it with (almost) any
> tool that
> >>> supports SVG.
> >> I tried withhttps://pixelied.com/features/svg-editor  and it was a
> mess.
> >
> > Yes. I tried another Web-based tool and it was the same mess. Yet, all
> converter
> > handle this correctly. For example:
> >
> > $ firefox file:///home/frank/tftpfs_usage.svg
> > $ convert -geometry 1422x1574 tftpfs_usage.svg tftpfs_usage.png
> > $ display tftpfs_usage.svg
> > $ libreoffice tftpfs_usage.svg
> > $ rsvg-convert --width 1422 --height 1574 -o tftpfs_usage_Z.png
> tftpfs_usage.svg
> >
> > So, I guess it is a bug in the web-based tools.
>
> The format is always going to be fragile and locked into the specific tool
> used
> to create it. Being an open format does not help. Word is a form of XML
> and it
> is also not suitable.
>
> >> My concern is the widgets (or whatever they are called) a tool has may
> not be
> >> available in another.
> >
> > Inkscape is open source and available freely on (almost?) all operating
> system.
> > It is *the* standard open source tool for producing high-quality vector
> graphics
> > today.
>
> I do not agree and I question "the" in your last sentence. Making a fact
> of your
> view does not impress me.
>
> We need a solution that can be maintained past your current employment.
>
> >>> Your Web-Browser should be able to display SVG directly when you
> >>> point it to the file like for
> example:file:///home//tftpfs_usage.svg
> >>>
> >>> You can recreate the PNG with Inkscape on the command line with:
> >>>
> >>> $ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png
> tftpfs_usage.svg
> >> We have a number of images in the doco created using PlantUML. Did you
> consider
> >> using that tool? It has the advantage the images can be regenerated
> from the
> >> source as part of the build if PlantUML and Ditaa are installed and we
> get a
> >> consistent looking set of images.
> >
> > I took a look into PlantUML:
> >
> > * My image is not an UML diagram (or similar to another diagram input
> format it
> > supports)
>
> Ditaa is an option and easy to use.
>
> > * It may be realized as an Activity Diagram, yet. But it will not look
> very
> > similar to the current image.
> >
> > * Most of all, I will need to spend significant time to learn PlantUML
> and to
> > get the result in shape I will certainly need to do some trying and
> fumbling
> > around.
>
> Maybe an example would help:
>
>
> https://git.rtems.org/rtems-docs/tree/images/user/exe-debug-libdebugger.ditaa
>
> > Openly, my company will never pay me for converting the image to
> PlantUML. Sorry
> > about this.
>
> Seems you have made this a commercial issue on a public mailing list I have
> included Thomas on the email and he can reach out me directly. I always
> enjoy
> catching up with him.
>
> > Do you see any solution to this problem?
>
> 1. Revert the patch.
>
> 2. Use something like ditaa
>
> 3. Reword the section to not include the image
>
> In the mean time the docs are not building.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

Re: Possible tls bug on arm / microblaze

[Sam Price]

I modified cpukit/score/cpu/microblaze/__tls_get_addr.c
and added a printf
  printf("TLS OFFSET %x %p %p %d",(uintptr_t) _TLS_Alignment,
tls_block,executing->Start.tls_area, ti->offset);
and then ran the splts* tests on my hardware.
The __tls_get_addr in the splts* tests.

*** BEGIN OF TEST SPTLS 1 ***
*** TEST VERSION: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
TLS item = 123
TLS item = 123
TLS item = 5

*** END OF TEST SPTLS 1 ***


[ RTEMS shutdown ]
RTEMS version: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
RTEMS tools: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
executing thread ID: 0x08a010001
executing thread name: UI1


*** BEGIN OF TEST SPTLS 2 ***
*** TEST VERSION: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
A::globalCounter() = 0
../../../testsuites/sptests/sptls02/init.cc: 168 extern_int == 7

[ RTEMS shutdown ]
RTEMS version: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
RTEMS tools: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
executing thread ID: 0x08a010001
executing thread name: UI1

RTEMS version: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
RTEMS tools: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
executing thread ID: 0x08a010001
executing thread name: UI1


*** BEGIN OF TEST SPTLS 3 ***
*** TEST VERSION: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)

*** END OF TEST SPTLS 3 ***


[ RTEMS shutdown ]
RTEMS version: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
RTEMS tools: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
executing thread ID: 0x08a010001
executing thread name: UI1

*** BEGIN OF TEST SPTLS 4 ***
*** TEST VERSION: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)

*** END OF TEST SPTLS 4 ***


[ RTEMS shutdown ]
RTEMS version: 6.0.0.0cb37ce45e81a2b030cbd99678a42884bc864f84
RTEMS tools: 10.3.1 20220622 (RTEMS 6, RSB
5a19dda19ffaaa43305af1f34597fd4d8165029b, Newlib 27fd806)
executing thread ID: 0x08a010001
executing thread name: UI1

On Tue, Jul 19, 2022 at 2:25 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/07/2022 20:10, Sam Price wrote:
> >
> > Where would the ti->offset member be updated / initialized at?
>
> The caller of __tls_get_addr() has to do this. On ARM, this is function
> is normally not used.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>


-- 
Sincerely,

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

Re: Binary CPU / Thread information.

[Sam Price]

Is there a preferred api style, or just mimic the linux kernel task?
https://docs.huihoo.com/doxygen/linux/kernel/3.7/structtask__struct.html

FreeRTOS has
https://www.freertos.org/a00021.html#xTaskGetTickCount

vxworks has a spy interface.
https://www.ecb.torontomu.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/spyLib.html#top

I would probably prefer a function and pass in a const task identifier, and
a pointer to a struct task to populate.
(Similar to the linux kernel example, possibly with the same names that get
populated?)

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

Binary CPU / Thread information.

[Sam Price]

I saw that there was a console command to see cpu usage information.
https://docs.rtems.org/branches/master/c-user/cpu_usage_statistics.html

Is there a binary api to get this, and stack usage?
I want to get this info out and send it in binary packets.

Is this something that I need to just copy whats going on in this file?
cpukit/libmisc/cpuuse/cpuusagereport.c

https://github.com/RTEMS/rtems/blob/fab1a86221e057a93bb9c1423dac81ed2b29ecde/cpukit/libmisc/cpuuse/cpuusagereport.c#L60

or is there a c api out there that i am missing that fills usage
information into c structs?


-- 
Thank you,

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

Re: Possible tls bug on arm / microblaze

[Sam Price]

At one point I believe a company tested the sptls tests, unsure if they did
this on qemu or hardware.

I'll try running those tests on a recent hash, and back when the company
ran those tests.

Where would the ti->offset member be updated / initialized at?
Only the arm, and microblaze bsps have this in them.

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

Possible tls bug on arm / microblaze

[Sam Price]

On microblaze i was getting a

ESR: Unaligned data access exception

I narrowed this down to this "ti->offset;" being uninitialized in the
following two bsps

https://git.rtems.org/rtems/tree/cpukit/score/cpu/microblaze/__tls_get_addr.c
Also this file
cpukit/score/cpu/arm/__tls_get_addr.c

I tried recompiling with this on the microblaze build with offset being
renamed to offseta.
This only caused a compilation error in the __tls_get_addr function.
So I think this variable is being used without being initialized or ever
changed.
Is it safe to just remove the offset variable?

-- 
Thank you,

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

Re: linkcmds.yml problems

[Sam Price]

Thanks i was trying to figure out how to debug this but didnt make much
progress.
Was trying to get waf to generate verbose information of all the calls it
was doing but wasnt sure how to do this.

Also saw these warnings during the compile process.  Have not had a chance
to dig into them to see if the conversion from unsigned int to void * is ok.

../../../bsps/microblaze/include/../../shared/dev/clock/clockimpl.h: In
function '_Clock_Initialize':
../../../bsps/microblaze/include/../../shared/dev/clock/clockimpl.h:235:37:
warning: passing argument 1 of 'microblaze_clock_handler_install' from
incompatible pointer type [-Wincompatible-pointer-types]
  235 |   Clock_driver_support_install_isr( Clock_isr );
  | ^
  | |
  | rtems_isr
(*)(rtems_vector_number) {aka void (*)(unsigned int)}
../../../bsps/microblaze/microblaze_fpga/clock/clock.c:141:37: note: in
definition of macro 'Clock_driver_support_install_isr'
  141 |   microblaze_clock_handler_install( isr )
  | ^~~
../../../bsps/microblaze/microblaze_fpga/clock/clock.c:122:71: note:
expected 'rtems_interrupt_handler' {aka 'void (*)(void *)'} but argument is
of type 'rtems_isr (*)(rtems_vector_number)' {aka 'void (*)(unsigned int)'}
  122 | static void microblaze_clock_handler_install(
rtems_interrupt_handler isr )
  |



On Thu, Jul 7, 2022 at 3:09 PM Alex White  wrote:

> On Thu, Jul 7, 2022 at 10:31 AM Sam Price  wrote:
> > Is it possible i have a bad python instance ?
>
> I was able to reproduce the linker problem using the latest RTEMS upstream
> code.
>
> It looks like it was broken by commit
> a0aaa394b68727d204904b59514cb0f90840ba6f from 6 days ago.
>
> I will submit a fix.
>
> Alex
>
> >
> >
> > --
> > Thank you,
> >
> > Sam Price
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> 
> From: devel  on behalf of Sam Price <
> thesampr...@gmail.com>
> Sent: Thursday, July 7, 2022 10:30 AM
> To: devel@rtems.org
> Subject: linkcmds.yml problems
>
> Was trying to build the latest source builder/rtems/libbsd but ran into a
> linker problem.
>
> You ever see this the source linker has
>
> spec/build/bsps/microblaze/microblaze_fpga/linkcmds.yml: RAM : ORIGIN =
> _TEXT_START_ADDR, LENGTH = ${BSP_MICROBLAZE_FPGA_RAM_LENGTH}
>
>
> But the generated linker file is creating
>
> RAM : ORIGIN = _TEXT_START_ADDR, LENGTH =
>
> when building rtems without populating the BSP_MICROBLAZE_FPGA_RAM_LENGTH.
>
>
>
> My config.ini has this specified as
> configs/config_kcu105_cpu0.ini:BSP_MICROBLAZE_FPGA_RAM_LENGTH=0x1000
>
> Is it possible i have a bad python instance ?
>
>
> --
> Thank you,
>
> Sam Price
>


-- 
Thank you,

Sam Price
(707) 742-3726
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

linkcmds.yml problems

[Sam Price]

Was trying to build the latest source builder/rtems/libbsd but ran into a
linker problem.

You ever see this the source linker has

spec/build/bsps/microblaze/microblaze_fpga/linkcmds.yml: RAM : ORIGIN =
_TEXT_START_ADDR, LENGTH = ${BSP_MICROBLAZE_FPGA_RAM_LENGTH}


But the generated linker file is creating

RAM : ORIGIN = _TEXT_START_ADDR, LENGTH =

when building rtems without populating the BSP_MICROBLAZE_FPGA_RAM_LENGTH.



My config.ini has this specified as
configs/config_kcu105_cpu0.ini:BSP_MICROBLAZE_FPGA_RAM_LENGTH=0x1000

Is it possible i have a bad python instance ?


--
Thank you,

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

Source-builder Qemu compiling / customizing

[Sam Price]

Im on ubuntu 18 and trying to build qemu for microblaze.
I had to modify the
source-builder/defaults.mc
and change several tool paths from /usr/bin to /bin
(This is prob not a standard build process.)

Short question.  What file in rtems-source builder do I need to modify to
add --disable-docs flag to the command that calls qemu configure and
generates the do-build file.

longer contex

When running
cd $RTEMS_BUILDER_DIR/src/rsb/rtems
../source-builder/sb-set-builder --prefix=$RTEMS_DEST_DIR/6
devel/qemu-xilinx
I get the following error
install: cannot stat 'docs/system/qemu.1': No such file or directory
This file appears to be in docs/system/1/qemu.1
(Maybe thats a source file though)

I can modify
`./build/qemu-xilinx-v2020.2-x86_64-linux-gnu-1/do-build`

and add `--disable-docs` to the line

$SB_PREFIX_CLEAN/lib -L$SYSROOT/lib ${VDE_LDFLAGS}"  CFLAGS="${CFLAGS}
${VDE_CFLAGS}"  ../${source_dir_qemu}/configure  --prefix=/opt/rtems/6
 ${CROSS_PREFIX_OPTION}  --make=make${VDE_CONFIG}  --disable-werror
--disable-tools --disable-pie --disable-vnc --disable-sdl --disable-gtk
--disable-opengl --disable-netmap --disable-nettle --disable-docs

and then run do-build with success.

I saw these files
./rsb/bare/config/devel/qemu-xilinx.bset
./rsb/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
But didnt see anything in them related to compiling.

My end goal is to customize qemu with a device driver that mimics our
firmware per
https://sebastienbourdelin.com/2021/06/16/writing-a-custom-device-for-qemu/
So somewhere I need to change the submodule link to a version of qemu that
I control.

Sorry if this should have been posted to users.  Still waiting on the
verify email.

--
Thanks,

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