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

[zack leung]

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",
ctx->idtIndex,
ctx->eip,
_Thread_Executing->Object.id);
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

On 11/09/2021 19:53, Gedare Bloom wrote:

+  start
+  The attribute value shall be an integer number. It shall be the start bit
+  of the bit field.
+

is it necessary to explain anywhere the convention that bit 0 is the
last, least-significant bit of a register?


I added a notice that bit 0 is the least-significant bit to the start 
attribute description.





+  width
+  The attribute value shall be an integer number. It shall be the width in
+  bits of the bit field.
+
+* There may by be no value (null).

delete 'by'?


Thanks, this typo was in a script.

--
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] eng: Add register block specification types

[Sebastian Huber]

On 11/09/2021 19:59, Joel Sherrill wrote:



On Fri, Sep 10, 2021, 9:41 AM 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.


I hope you don't mean C bit fields. They are quite non-portable.


This register block specification is independent of an interface in a 
particular programming language.  It is similar to a machine readable 
manual. From the register block specification you could generate code 
for C, C++, Rust, Ada, Python, and so on. Currently, there is only a C 
header file generator (which doesn't use C bit fields), for example:


https://git.rtems.org/sebh/rtems.git/tree/bsps/include/grlib/gptimer-regs.h?h=qual-35



And I hope we are avoiding packed in this definition of requirements set.


What do you mean with "packed"?


Unfortunately it seems there are more things you can get wrong here 
which leads to negative requirements and negative requirements are bad


Sorry, what do you mean with "negative requirements" here?

--
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] eng: Add register block specification types

[Sebastian Huber]

On 12/09/2021 03:32, Chris Johns wrote:

On 11/9/21 12:41 am, 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.


I feel this is for generation of headers of devices for drivers. Is this 
correct?


Yes, see for example:

https://git.rtems.org/sebh/rtems.git/tree/bsps/include/grlib/gptimer-regs.h?h=qual-35



What bus interface API you are considering mapping this specification too?


Since we don't have a bus interface API in RTEMS I used something simple:

https://git.rtems.org/sebh/rtems.git/tree/bsps/sparc/include/grlib/io.h?h=qual-35



I do not know the purpose of this addition and the long term effect of this
being formalised like this.


The purpose is a machine readable specification of the hardware 
interfaces in terms of register blocks, registers, and bit fields.


I used a similar approach to generate the header files for the AArch32 
and AArch64 system registers:


https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/aarch32-system-registers.h

https://git.rtems.org/rtems/tree/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h

This approach is not limited to memory mapped register blocks.

A machine readable hardware interface specification gives you a lot of 
flexibility. The labor intensive work is the first step, from a hand 
written manual to the specification items. If you have a better format 
in the future, it would be easy to convert the files with a small Python 
script.





Update #3715.


I could not see this topic in the list for that ticket. I prefer that list stays
as it is.


This register block specification format specification belongs to 
"Definition of data model and format actually used for the project".


--
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