Re: [PATCH] eng: Add register block specification types

[Sebastian Huber]

On 16/09/2021 01:47, Chris Johns wrote:

On 15/9/21 3:33 pm, Sebastian Huber wrote:

On 15/09/2021 00:48, Chris Johns wrote:

On 14/9/21 8:08 pm, Sebastian Huber wrote:

On 10/09/2021 16:41, Sebastian Huber wrote:

A register block may be used to specify the memory-mapped interface to
the hardware.  Register blocks consist of register block members.
Register block members are either instances of registers or instances of
other register blocks.  Registers consists of bit fields.

Update #3715.


Any objections to integrate this?


I am sorry but in it's current form I do.


The hardware specification is work in
progress. What I have currently is a proof of concept for the GR740 and the
GR712RC. It should cause no harm to have it documented. If this stuff is
generally useful is an open question.


Who fixes the spec for the other bus models?


The register block specification doesn't need to be fixed.


I think it does. As I stated earlier showing how an indirect device can be
handled would help.


For devices which are specified in an abstract address space, you could 
change the "register-block-type" from "memory" to "whatever". The code 
generator could then for example generate a set of defines with address 
space offset constants instead of a C structure.





It is independent of
bus models, device driver frameworks, and programming languages.


If it can directly generate a struct to access the registers it is not
independent by definition. You have assumed the implicit integration of the CPU
and connecting buses which may be fine for a SOC or devices used only with one
CPU and bus architecture but it is not generic. A device word size is a physical
constraint of the device, the bus word size is another constraint and they may
not directly align. For example an 8bit UART device connected to a 32bit bus may
result in each register being 32bit aligned. Which offset is in the register
definition?


I really don't see what is the problem here with the register block 
specification. The offsets are just numbers relative to a base address.





The register
block specification contains the same information as a hardware manual in terms
of register blocks, registers, and bit fields. The only difference is that the
register block specification is machine readable and a hardware manual not
really in general.


I suggest you review 

https://japan.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf

... Register Space on page 11. You can enter the offsets but you have no idea
how this IP presents to the CPU until you get the extra piece of information
from the FPGA designer who placed it in the PL. The values in table 2-4 are
address space offsets in the register space and nothing more. The choice of
wording is deliberate and worth noting.


You could directly rewrite table 2-4 and the following register 
definitions in the register block specification.





Will those fixes be compatible and
if not who fixes the existing specs or drivers?


In order to support a particular device driver implementation framework you just
have to write a code generator which reads the register block specification and
outputs the code.


I understand this but the use of `bytes` in size and few other things means the
spec language is too specific to the immediate purpose you have. It just needs
to be broadened and it needs to discuss and deal with buses. In your case a 1:1
mapping of device word size and bus word size.


Ok, so your real problem is that I wrote "bytes" in the description of 
the register-block-size and offset attributes? We could change this into 
something like this:


offset

The attribute value shall be an integer number. It shall be the offset 
in units of address space granules from the register
block begin to the register member.  For memory-mapped register blocks 
the address space granule is one byte.


register-block-size

The attribute value shall be an integer number. It shall be the size of 
the register block in units of address space granules.  For 
memory-mapped register blocks the address space granule is one byte.






The existing code generator just outputs a header file with C
structures and defines for the bit fields. You could use this header file with
the FreeBSD bus space API.


Presenting the struct and defines in a single file and using the bus space API
does not make sense to me and that should not be encouraged. I do understand a
header with the address space offsets and bit maps and then a header with the
struct for those bus archs that can support it but current versions of these
types of headers I have used do not do this, ie zynq uart. Considering this now
I think the separation is something we should mandate.


This is a problem related to the code generator and not the the register 
blocks specification. This patch set is about the register block 
specification.





Those questions expose the liability the project is left with. For me to make
ch

Re: [PATCH v4] improve the format of error reporting on i386

[zack leung]

printk("--\n");
printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%"
PRIx32 "\n",
ctx->idtIndex,
ctx->eip,
_Thread_Executing->Object.id);
printk("--\n");
printk("Processor execution context at time of the fault was :\n");
printk("--\n");
printk(" EAX = %" PRIx32 " EBX = 0x%" PRIx32 " ECX = %" PRIx32 " EDX = %"
PRIx32 "\n",
ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
printk(" ESI = 0x%" PRIx32 " EDI = 0x%" PRIx32 " EBP = 0x%" PRIx32 " ESP =
0x%" PRIx32 "\n",
ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);


Before I send my patch here is what i'll change . So i can do this for
example format the hex values with 0x and
have the thread id as a hex value.

On Wed, 15 Sept 2021 at 15:18, Gedare Bloom  wrote:

> On Mon, Sep 13, 2021 at 6:10 PM zack leung 
> wrote:
> >
> > Gedare told me just to change the ID when I submitted the other I sent
> you
> > in discord. Sorry for things bouncing back and forth.
> >
>
> I said not to change the `type` of the register context variables from
> 32 to ptr. You can change their representation to hex that's fine by
> me, with the fixed width and 0x prepended.
>
> > On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
> >
> > > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
> > > wrote:
> > > >
> > > > Thread id is now a Hex value.
> > > > Updates #4203
> > > > ---
> > > > cpukit/score/cpu/i386/cpu.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/cpukit/score/cpu/i386/cpu.c
> b/cpukit/score/cpu/i386/cpu.c
> > > > index 77b7a7161c..06af57418d 100644
> > > > --- a/cpukit/score/cpu/i386/cpu.c
> > > > +++ b/cpukit/score/cpu/i386/cpu.c
> > > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > > > CPU_Exception_frame *ctx)
> > > > {
> > > > unsigned int faultAddr = 0;
> > > >
> printk("--\n");
> > > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > > PRId32 "\n",
> > > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > > PRIx32 "\n",
> > >
> > > PC and ID should use  PC 0x%08" PRIx32.
> > >
> > > Prefixing with 0x to indicate that the number is hexadecimal. Printing
> > > it with leading zero's and 8 digits wide helps since the address and
> > > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> > > 0x0a010004
> > >
> > > Does this patch have all your other changes? I've slept since seeing
> > > this time and thought there were changes..
> > >
> > > --joel
> > >
> > > > ctx->idtIndex,
> > > > ctx->eip,
> > > > _Thread_Executing->Object.id);
> > > > --
> > > > 2.33.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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB

[Chris Johns]

On 16/9/21 1:46 am, Joel Sherrill wrote:
> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  wrote:
>>
>> On 15/9/21 4:49 am, Joel Sherrill wrote:
>>> On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill >> > wrote:
>>> On Mon, Sep 13, 2021 at 6:54 PM Chris Johns >> > wrote:
>>> > On 13/9/21 11:20 pm, Joel Sherrill wrote:
>>> > > Hi
>>> > >
>>> > > If building a bset tar file, does it matter if the installation 
>>> prefix
>>> > > is writable?
>>> > >
>>> > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
>>> > > --prefix=/rtems/tools 5/rtems-i386
>>> > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
>>> > > error: prefix is not writable: /rtems/tools
>>> > >
>>> > > It does if you are planning to immediately install but if building 
>>> for
>>> > > later installation, I don't think it matters.
>>> > >
>>> > > Thoughts?
>>> >
>>> > What happens if you add --no-install?
>>>
>>> It skips the test.
>>>
>>> And doesn't install anything.
>>
>> Excellent.
>>
>>> > If this does help the question moves to if making a bset is packaging
>>> around an
>>> > install or is it the only output option?
>>>
>>> With a bset-tar, I don't think it did an install anyway. But it's been
>>> a long day. I can
>>> check again tomorrow if you want me to.
>>>
>>> Builds and installs tools unless you specify no install.
>>>
>>> Tar files is an additive behavior.
>>
>> OK and thanks
>>
>>> I am off today but will try to review the help and user docs to make sure 
>>> this
>>> is clear.
>>>
>>> Any thoughts on the tools tarballs not having the architecture name in it? 
>>> If
>>> you build multiple architectures or just want to maintain tool tarballs for
>>> multiple architectures, you have to manually rename them.
>>
>> Could you please remind me about the naming and then what you would like?
> 
> After building tools for ARM for RTEMS 5, this is what is in the tar/
> directory.
> 
> + ls -1 tar
> automake-1.12.6-x86_64-linux-gnu-1.tar.bz2
> rtems-tools-0a5d2057749066e7d184836e92c7ce5334fccc90-1.tar.bz2
> 
> I wondered where autoconf was and it is in the automake tarball. Either
> autoconf should be in a separate tarball of the tarfile should be autotools
> like is used in the bsets. Not sure which but just saying automake-1.12.6
> and including autoconf is not right.

It would seem the tar name is not the parent bset.

> The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
> is used for every architecture. Perhaps rtems-tools-@ARCH@-@t...@-1.tar.bz2.
> Then you can script building all architectures without renaming files.

That implies the tools are arch specific and they are not. The tools should be
tagged with the host arch details if we add anything.

> One thing I also noticed which might cause problems with people feeding
> the tools tarball into another packaging system is that there are duplicate
> files across architectures. 

Yeap.

> I don't see the RSB addressing this but someone
> creating RPM, deb, etc packages might have to. 

Correct.

> If post processing
> is needed to break out a rtems-tools-common tarball, that is on someone
> feeding these into something that doesn't like duplicate files in packages.
> 
> So.. (1) automake has autoconf also and (2) same name is used for rtems-tools
> independent of architecture.

Packaging is beyond the RSB. You have highlighted a couple of issues and more
exist. For example in each build of gcc there are common host files and there
are common host independent files. To map multiple builds of tools into a
packaging system you need to identify all common pieces and then group them
based on the packaging system requirements. You then create a package dependency
tree for the generated packages.

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

Re: [PATCH] eng: Add register block specification types

[Chris Johns]

On 15/9/21 3:33 pm, Sebastian Huber wrote:
> On 15/09/2021 00:48, Chris Johns wrote:
>> On 14/9/21 8:08 pm, Sebastian Huber wrote:
>>> On 10/09/2021 16:41, Sebastian Huber wrote:
 A register block may be used to specify the memory-mapped interface to
 the hardware.  Register blocks consist of register block members.
 Register block members are either instances of registers or instances of
 other register blocks.  Registers consists of bit fields.

 Update #3715.
>>>
>>> Any objections to integrate this?
>>
>> I am sorry but in it's current form I do.
>>
>>> The hardware specification is work in
>>> progress. What I have currently is a proof of concept for the GR740 and the
>>> GR712RC. It should cause no harm to have it documented. If this stuff is
>>> generally useful is an open question.
>>
>> Who fixes the spec for the other bus models?
> 
> The register block specification doesn't need to be fixed.

I think it does. As I stated earlier showing how an indirect device can be
handled would help.

> It is independent of
> bus models, device driver frameworks, and programming languages.

If it can directly generate a struct to access the registers it is not
independent by definition. You have assumed the implicit integration of the CPU
and connecting buses which may be fine for a SOC or devices used only with one
CPU and bus architecture but it is not generic. A device word size is a physical
constraint of the device, the bus word size is another constraint and they may
not directly align. For example an 8bit UART device connected to a 32bit bus may
result in each register being 32bit aligned. Which offset is in the register
definition?

> The register
> block specification contains the same information as a hardware manual in 
> terms
> of register blocks, registers, and bit fields. The only difference is that the
> register block specification is machine readable and a hardware manual not
> really in general.

I suggest you review 

https://japan.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf

... Register Space on page 11. You can enter the offsets but you have no idea
how this IP presents to the CPU until you get the extra piece of information
from the FPGA designer who placed it in the PL. The values in table 2-4 are
address space offsets in the register space and nothing more. The choice of
wording is deliberate and worth noting.

>> Will those fixes be compatible and
>> if not who fixes the existing specs or drivers?
> 
> In order to support a particular device driver implementation framework you 
> just
> have to write a code generator which reads the register block specification 
> and
> outputs the code. 

I understand this but the use of `bytes` in size and few other things means the
spec language is too specific to the immediate purpose you have. It just needs
to be broadened and it needs to discuss and deal with buses. In your case a 1:1
mapping of device word size and bus word size.

> The existing code generator just outputs a header file with C
> structures and defines for the bit fields. You could use this header file with
> the FreeBSD bus space API.

Presenting the struct and defines in a single file and using the bus space API
does not make sense to me and that should not be encouraged. I do understand a
header with the address space offsets and bit maps and then a header with the
struct for those bus archs that can support it but current versions of these
types of headers I have used do not do this, ie zynq uart. Considering this now
I think the separation is something we should mandate.

>> Those questions expose the liability the project is left with. For me to make
>> changes and look after the GR740 and GR712RC it would be a lot of work 
>> because I
>> have not worked with those devices and they are important to some users.
> 
> The existing GRLIB header files are incomplete. What we have now is a complete
> set of register block header files for the GR740.

Will you test all these new definitions? If not how do you know which has been
tested and can be trusted?

>> I do not see the value in us hosting a custom or subset solution for a model 
>> to
>> access hardware we should not be encouraging.
> 
> We don't have a general bus space API in RTEMS. Basically every BSP has its 
> own
> solution. No matter which model you have to access the hardware, you need
> something which tells you how the hardware looks like. This could be a manual 
> or
> a machine readable description.

Agreed and this needs to be part of the specification process or the information
being added is custom and useful only for a specific sub-set of parts. And if I
wanted to use this for something that did not fit I may break the specs and then
the generation tool and that is a liability I would prefer we avoid if we can.

>> I see value in a solution that can
>> support all bus solutions.
> 
> I don't know if the register block specification supports 

Re: The compiler settings for Cortex-M4

[groups]

Good day Sebastian,

I was able to step through the boot process and see memset working properly 
this time. Then I was able to reach Init();

Now back to my BSP for the F767 and the ultimate goal of ethernet and mdns.

Thanks for your help,

Andrei

> On 2021-September-13, at 23:56, Sebastian Huber 
>  wrote:
> 
> Hello Andrei,
> 
> I modified the flags, could you please check if this fixed the problem?
> 
> -- 
> 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/

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

Re: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

[Sebastian Huber]

On 15/09/2021 17:30, Gedare Bloom wrote:

No. I'm more worried about boot time. :)


Would a few milliseconds be acceptable?


Is there any way to poll?

I'm not totally clear on the boot vs secondary processor
initialization sequence, and how closely they need to synchronize at
this stage.

What hardware do you have this problem with?


Yes, instead of using a magic number it would be better to make this 
adaptive. I guess on real hardware there are no issues.


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

Re: RSB

[Joel Sherrill]

On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  wrote:
>
> On 15/9/21 4:49 am, Joel Sherrill wrote:
> > On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill  > > wrote:
> > On Mon, Sep 13, 2021 at 6:54 PM Chris Johns  > > wrote:
> > > On 13/9/21 11:20 pm, Joel Sherrill wrote:
> > > > Hi
> > > >
> > > > If building a bset tar file, does it matter if the installation 
> > prefix
> > > > is writable?
> > > >
> > > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> > > > --prefix=/rtems/tools 5/rtems-i386
> > > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
> > > > error: prefix is not writable: /rtems/tools
> > > >
> > > > It does if you are planning to immediately install but if building 
> > for
> > > > later installation, I don't think it matters.
> > > >
> > > > Thoughts?
> > >
> > > What happens if you add --no-install?
> >
> > It skips the test.
> >
> > And doesn't install anything.
>
> Excellent.
>
> > > If this does help the question moves to if making a bset is packaging
> > around an
> > > install or is it the only output option?
> >
> > With a bset-tar, I don't think it did an install anyway. But it's been
> > a long day. I can
> > check again tomorrow if you want me to.
> >
> > Builds and installs tools unless you specify no install.
> >
> > Tar files is an additive behavior.
>
> OK and thanks
>
> > I am off today but will try to review the help and user docs to make sure 
> > this
> > is clear.
> >
> > Any thoughts on the tools tarballs not having the architecture name in it? 
> > If
> > you build multiple architectures or just want to maintain tool tarballs for
> > multiple architectures, you have to manually rename them.
>
> Could you please remind me about the naming and then what you would like?

After building tools for ARM for RTEMS 5, this is what is in the tar/
directory.

+ ls -1 tar
automake-1.12.6-x86_64-linux-gnu-1.tar.bz2
rtems-tools-0a5d2057749066e7d184836e92c7ce5334fccc90-1.tar.bz2

I wondered where autoconf was and it is in the automake tarball. Either
autoconf should be in a separate tarball of the tarfile should be autotools
like is used in the bsets. Not sure which but just saying automake-1.12.6
and including autoconf is not right.

The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
is used for every architecture. Perhaps rtems-tools-@ARCH@-@t...@-1.tar.bz2.
Then you can script building all architectures without renaming files.

One thing I also noticed which might cause problems with people feeding
the tools tarball into another packaging system is that there are duplicate
files across architectures. I don't see the RSB addressing this but someone
creating RPM, deb, etc packages might have to. If post processing
is needed to break out a rtems-tools-common tarball, that is on someone
feeding these into something that doesn't like duplicate files in packages.

So.. (1) automake has autoconf also and (2) same name is used for rtems-tools
independent of architecture.

--joel

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

Re: [PATCH v2] c-user: Define lower and higher priority

[Sebastian Huber]

On 15/09/2021 17:22, Gedare Bloom wrote:

  priority
  The priority is a mechanism used to represent the relative importance 
of an
-element in a set of items.  RTEMS uses :term:`task priorities ` to determine
-which :term:`task` should execute.
+element in a set of items.
+
+For example, :term:`RTEMS` uses :term:`task priorities ` to determine which
+:term:`task` should execute on a processor.  In RTEMS, priorities are
+represented by non-negative integers.
+
+For the Classic :term:`API`, if a numerical priority value ``A`` is 
greater
+than a numerical priority value ``B``, then ``A`` expresses a
+:term:`higher priority` than ``B``.  If a numerical priority value 
``C`` is
+less than a numerical priority value ``D``, then ``C`` expresses a
+:term:`lower priority` than ``D``.
+
+For the :term:`POSIX` API, if a numerical priority value ``R`` is less 
than
+a numerical priority value ``S``, then ``R`` expresses a lower 
priority than
+``S``.  If a numerical priority value ``T`` is greater than a numerical
+priority value ``U``, then ``T`` expresses a higher priority than 
``U``.


These are backwards. Classic priorities with numerically greater
values indicate lower priorities. POSIX priorities with numerically
higher values express higher priorities.


Thanks for noticing this. I swapped the lower and higher priority items:
https://git.rtems.org/rtems-central/commit/?id=4cd035ab1160394172d2669dd2ac22668b365991

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

Re: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

[Gedare Bloom]

On Thu, Sep 9, 2021 at 2:39 AM  wrote:
>
> Sorry, for digging out this old patch.
>
> > On Mon, Jun 7, 2021 at 1:57 PM  wrote:
> >
> >
> > > -Original Message-
> > > From: Gedare Bloom 
> > > Sent: Monday, June 7, 2021 7:00 PM
> > > To: Sommer, Jan 
> > > Cc: devel@rtems.org
> > > Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> > > initialization
> > >
> > > On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> > > >
> > > > - Clock driver initialization for secondary cores had to take less
> > > > than one tick
> > > > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > > > too long and a fatal error is thrown.
> > > > - Give at least 10 ms time for clock initialization to avoid this
> > > > error
> > >
> > > Is there a reason to pick 10?
> > >
> >
> > In qemu I (coarsely) measured 1.5ms for 8 cores.
> > So I thought this should add enough buffer to prevent a fatal error.
> > I probably could also reduce it to 5 ms.
> >
> > > I assume this blocks/idles the system until the interval elapses, so it 
> > > would be
> > > good to minimize waste (subject to Joel's noted rant about premature
> > > optimization).
> > >
> >
> > No. I'm more worried about boot time. :)
> >
>
> Would a few milliseconds be acceptable?
>

Is there any way to poll?

I'm not totally clear on the boot vs secondary processor
initialization sequence, and how closely they need to synchronize at
this stage.

What hardware do you have this problem with?

> >
> >
> > If you take a look at the clock initialization of the secondary cores 
> > (https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):
> >
> > _SMP_Othercast_action(riscv_clock_secondary_action, &cmpval);
> >
> >   if (cmpval - riscv_clock_read_mtime(&clint->mtime) >= interval) {
> > bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
> >   }
> >
> > It will put the first clock tick 10ms into the future (instead of just one 
> > tick), but it won't block the system initialization.
> > It only prevents entering the if condition by having a large enough value 
> > for interval, but the runtime of the clock initialization is the same.
> >
> > How does this impact the timeline for boot to first application thread?
> >
> > Is there a period where the system is up but only one core?
> >
> > Any other oddities I might be missing?
> >
>
> The main effect this has is that the interrupt of the first tick is delayed 
> by a few milliseconds, so that there is enough time for the timers of all 
> cores to initialize, even for configurations with short tick intervals.
> This should have a similar behavior as if the tick time itself would be long 
> (i.e. multiple milliseconds).
>
> Maybe, an alternative solution would be to do this in the 
> "riscv_clock_secondary_initialization".
> If the condition there (see below) fails, try again with a longer time 
> interval for the clock initialization and only fail if that didn't help 
> either.
> Then, it would not affect the situation where everything works fine right now 
> and just add a small penalty to the setups where it currently fails.
> Would this be acceptable?
>
>   178 static void riscv_clock_secondary_initialization(
>   179   volatile RISCV_CLINT_regs *clint,
>   180   uint64_t cmpval,
>   181   uint32_t interval
>   182 )
>   183 {
>   184 #if defined(RTEMS_SMP) && !defined(CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR)
>   185   _SMP_Othercast_action(riscv_clock_secondary_action, &cmpval);
>   186
>   187   if (cmpval - riscv_clock_read_mtime(&clint->mtime) >= interval) {
>   188 bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
>   189   }
>   190 #endif
>   191 }
>
> Best regards,
>
> Jan
>
> > > > ---
> > > >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > > index 3afe86576f..102137aeab 100644
> > > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> > > >tc->interval = interval;
> > > >
> > > >cmpval = riscv_clock_read_mtime(&clint->mtime);
> > > > -  cmpval += interval;
> > > > +  /*
> > > > +   * For very short intervals the time of 1 tick is not enough to
> > > > +   * set up the timer on all cores in SMP systems.
> > > > +   * Give the CPU at least 10 ms.
> > > > +   */
> > > > +  interval = (1 / us_per_tick) * interval;  cmpval += interval;
> > > >
> > > >riscv_clock_clint_init(clint, cmpval, 0);
> > > >riscv_clock_secondary_initialization(clint, cmpval, interval);
> > > > --
> > > > 2.17.1
> > > >
> > > > ___
> > > > devel mailing list
> > > > devel@rtems.org
> > > > http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/list

Re: [PATCH] rtems: Fix message manager documentation

[Gedare Bloom]

ok

On Wed, Sep 15, 2021 at 3:48 AM Sebastian Huber
 wrote:
>
> Correct the description of the ``count`` parameter of
> rtems_message_queue_flush().
>
> Update #4508.
> ---
>  cpukit/include/rtems/rtems/message.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/message.h 
> b/cpukit/include/rtems/rtems/message.h
> index f288d94445..28014f325e 100644
> --- a/cpukit/include/rtems/rtems/message.h
> +++ b/cpukit/include/rtems/rtems/message.h
> @@ -859,8 +859,8 @@ rtems_status_code rtems_message_queue_get_number_pending(
>   * @param id is the queue identifier.
>   *
>   * @param[out] count is the pointer to an uint32_t object.  When the 
> directive
> - *   call is successful, the number of unblocked tasks will be stored in this
> - *   object.
> + *   call is successful, the number of pending messages removed from the 
> queue
> + *   will be stored in this object.
>   *
>   * This directive removes all pending messages from the queue specified by
>   * ``id``.  The number of messages removed is returned in ``count``.  If no
> --
> 2.31.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] c-user: Define lower and higher priority

[Gedare Bloom]

On Tue, Sep 14, 2021 at 10:21 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst | 37 -
>  1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 16a8b8d..94bf773 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -398,6 +398,10 @@ Glossary
>  heterogeneous
>  A multiprocessor computer system composed of dissimilar processors.
>
> +higher priority
> +A :term:`task` ``H`` has a higher :term:`priority` than a task 
> ``L``, if
> +task ``H`` is more important than task ``L``.
> +
>  home scheduler
>  The home scheduler of a :term:`task` is a :term:`scheduler` which is 
> an
>  :term:`eligible scheduler` and which is assigned to the task during 
> its
> @@ -498,6 +502,10 @@ Glossary
>  A multiprocessor configuration where shared memory is not used for
>  communication.
>
> +lower priority
> +A :term:`task` ``L`` has a lower :term:`priority` than a task ``H``, 
> if
> +task ``L`` is less important than task ``H``.
> +
>  major number
>  The index of a device driver in the Device Driver Table.
>
> @@ -664,8 +672,22 @@ Glossary
>
>  priority
>  The priority is a mechanism used to represent the relative 
> importance of an
> -element in a set of items.  RTEMS uses :term:`task priorities  priority>` to determine
> -which :term:`task` should execute.
> +element in a set of items.
> +
> +For example, :term:`RTEMS` uses :term:`task priorities  priority>` to determine which
> +:term:`task` should execute on a processor.  In RTEMS, priorities are
> +represented by non-negative integers.
> +
> +For the Classic :term:`API`, if a numerical priority value ``A`` is 
> greater
> +than a numerical priority value ``B``, then ``A`` expresses a
> +:term:`higher priority` than ``B``.  If a numerical priority value 
> ``C`` is
> +less than a numerical priority value ``D``, then ``C`` expresses a
> +:term:`lower priority` than ``D``.
> +
> +For the :term:`POSIX` API, if a numerical priority value ``R`` is 
> less than
> +a numerical priority value ``S``, then ``R`` expresses a lower 
> priority than
> +``S``.  If a numerical priority value ``T`` is greater than a 
> numerical
> +priority value ``U``, then ``T`` expresses a higher priority than 
> ``U``.
>

These are backwards. Classic priorities with numerically greater
values indicate lower priorities. POSIX priorities with numerically
higher values express higher priorities.

>  priority boosting
>  A simple approach to extend the priority inheritance protocol for
> @@ -999,13 +1021,18 @@ Glossary
>  and resumes execution on another processor.
>
>  task priority
> -A task priority of a :term:`task` determines its importance relative 
> to
> -other tasks.  The scheduler use task priorities to determine which
> -:term:`ready task` gets a processor allocated, see :term:`scheduled 
> task`.  The
> +A task :term:`priority` of a :term:`task` determines its importance
> +relative to other tasks.
> +
> +The scheduler use task priorities to determine which :term:`ready 
> task` gets
> +a processor allocated, see :term:`scheduled task`.  The
>  :term:`eligible priorities ` of a task define the 
> position of the task in a
>  :term:`wait queue` which uses the priority discipline.  Each task 
> has at
>  least the :term:`real priority`.
>
> +Task priorities are used in :term:`wait queues ` which 
> use the priority
> +discipline to determine the dequeueing order of tasks.
> +
>  task processor affinity
>  The set of processors on which a task is allowed to execute.
>
> --
> 2.31.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] improve the format of error reporting on i386

[Gedare Bloom]

On Mon, Sep 13, 2021 at 6:10 PM zack leung  wrote:
>
> Gedare told me just to change the ID when I submitted the other I sent you
> in discord. Sorry for things bouncing back and forth.
>

I said not to change the `type` of the register context variables from
32 to ptr. You can change their representation to hex that's fine by
me, with the fixed width and 0x prepended.

> On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
>
> > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
> > wrote:
> > >
> > > Thread id is now a Hex value.
> > > Updates #4203
> > > ---
> > > cpukit/score/cpu/i386/cpu.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > > index 77b7a7161c..06af57418d 100644
> > > --- a/cpukit/score/cpu/i386/cpu.c
> > > +++ b/cpukit/score/cpu/i386/cpu.c
> > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > > CPU_Exception_frame *ctx)
> > > {
> > > unsigned int faultAddr = 0;
> > > printk("--\n");
> > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > PRId32 "\n",
> > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > PRIx32 "\n",
> >
> > PC and ID should use  PC 0x%08" PRIx32.
> >
> > Prefixing with 0x to indicate that the number is hexadecimal. Printing
> > it with leading zero's and 8 digits wide helps since the address and
> > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> > 0x0a010004
> >
> > Does this patch have all your other changes? I've slept since seeing
> > this time and thought there were changes..
> >
> > --joel
> >
> > > ctx->idtIndex,
> > > ctx->eip,
> > > _Thread_Executing->Object.id);
> > > --
> > > 2.33.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems: Fix message manager documentation

[Sebastian Huber]

Correct the description of the ``count`` parameter of
rtems_message_queue_flush().

Update #4508.
---
 cpukit/include/rtems/rtems/message.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/rtems/message.h 
b/cpukit/include/rtems/rtems/message.h
index f288d94445..28014f325e 100644
--- a/cpukit/include/rtems/rtems/message.h
+++ b/cpukit/include/rtems/rtems/message.h
@@ -859,8 +859,8 @@ rtems_status_code rtems_message_queue_get_number_pending(
  * @param id is the queue identifier.
  *
  * @param[out] count is the pointer to an uint32_t object.  When the directive
- *   call is successful, the number of unblocked tasks will be stored in this
- *   object.
+ *   call is successful, the number of pending messages removed from the queue
+ *   will be stored in this object.
  *
  * This directive removes all pending messages from the queue specified by
  * ``id``.  The number of messages removed is returned in ``count``.  If no
-- 
2.31.1

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

Re: [PATCH] c-user: Fix message manager documentation

[Frank Kühndel]

On 9/14/21 5:52 PM, Sebastian Huber wrote:
> Remove bogus return status from rtems_message_queue_receive().  Clarify
> rtems_message_queue_flush().
> 
> Close #4508.
> ---
>  c-user/message/directives.rst | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/c-user/message/directives.rst b/c-user/message/directives.rst
> index f320350..7317eb4 100644
> --- a/c-user/message/directives.rst
> +++ b/c-user/message/directives.rst
> @@ -891,10 +891,6 @@ queue.
>  :c:macro:`RTEMS_UNSATISFIED`
>  The queue was empty.
>  
> -:c:macro:`RTEMS_UNSATISFIED`
> -The queue was flushed while the calling task was waiting to receive a
> -message.
> -
>  :c:macro:`RTEMS_TIMEOUT`
>  The timeout happened while the calling task was waiting to receive a
>  message
> @@ -1039,17 +1035,22 @@ present on the queue, count is set to zero.
>  The ``count`` parameter was `NULL
>  `_.
>  
> +.. rubric:: NOTES:
> +
> +The directive does not flush tasks waiting to receive a message from the
> +:term:`wait queue` of the message queue.
> +
>  .. rubric:: CONSTRAINTS:
>  
>  The following constraints apply to this directive:
>  
> -* The directive may be called from within task context.
> -
>  * The directive may be called from within interrupt context.
>  
> -* When the directive operates on a remote object, the directive sends a 
> message
> -  to the remote node and waits for a reply.  This will preempt the calling
> -  task.
> +* The directive may be called from within device driver initialization 
> context.
> +
> +* The directive may be called from within task context.
> +
> +* The directive will not cause the calling task to be preempted.
>  
>  .. Generated from spec:/rtems/message/if/buffer

Hi Sebastian,

the text for the `count` parameter needs to be changed too. Currently it
says:

| count
|
| This parameter is the pointer to an uint32_t object. When the
| directive call is successful, the number of unblocked tasks will be
| stored in this object.

It should instead read:

| count
|
| This parameter is the pointer to an uint32_t object. When the
| directive call is successful, the number of messages removed will be
| stored in this object.

Greetings
fk




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