Re: [PATCH] shell: Fixing bug in line editing of the shell with CTRL-U.

[Chris Johns]

On 26/9/20 2:06 am, Joel Sherrill wrote:
> On Fri, Sep 25, 2020, 10:06 AM Gedare Bloom  > wrote:
> 
> On Fri, Sep 25, 2020 at 3:11 AM Frank Kuehndel
>  > wrote:
> >
> > This patch fixes a tiny bug in the command line editing of the RTEMS
> shell. Typing CTRL-U in the shell should remove all characters left of the
> cursor. After pressing CTRL-U, the current implementation does wrongly 
> place
> the cursor at the end of the line instead at its beginning.
> >
> >
> > To reproduce the bug, start the shell and type 'abc123' (no ):
> >
> > > ~/src/rtems $ qemu-system-arm -net none -nographic -M realview-pbx-a9 
> -m
> 256M -kernel build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl10.exe
> > >
> > >
> > > *** BEGIN OF TEST libdl (RTL) 10 ***
> > > *** TEST VERSION: 6.0.0.d9bdf166644f612dd628fe4951c12c6f8e94ba5f
> > > *** TEST STATE: USER_INPUT
> > > *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> > > *** TEST TOOLS: 10.2.1 20200904 (RTEMS 6, RSB
> 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
> > > RTL (libdl) commands: dl, rtl
> > >
> > >
> > > RTEMS Shell on /dev/foobar. Use 'help' to list commands.
> > > SHLL [/] # abc123
> >
> > Then move the cursor onto the '1' by hitting three times the 
> 
> key. Next type -U:
> >
> > > SHLL [/] # 123
> >
> > Note that the cursor is at the end of the line (after '3') instead of
> correctly at the beginning (on the '1'), now.
> >
> > Continuing typing 'echo ' incorrectly results in the output:
> >
> > > SHLL [/] # 123echo 123
> >
> > The patch changes this behavior so that the cursor in the second last 
> step
> will be on the '1' and typing 'echo ' will then correctly reflected as:
> >
> > > SHLL [/] # echo 123
> >
> 
> Please put the above bug details into a ticket
> https://devel.rtems.org/wiki/NewTicket with a milestone of 6
> 
> 
> Why wouldn't this also be appropriate for 5?
> 

It is fine for 5 with a ticket.

> And can anyone confirm this happens on real hardware? Sometimes control
> characters act funny on simulators.

It is broken on hardware so the simulator and hardware match.

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

Re: qoriq_e6500_32 with smp - compiler error

[Sebastian Huber]

On 26/09/2020 22:02, Gedare Bloom wrote:


I reduced this just to:
---
[powerpc/qoriq_e6500_32_smp]
INHERIT = qoriq_e6500_32
RTEMS_SMP = True
---

And it breaks. If I don't use the INHERIT option, this works:
[powerpc/qoriq_e6500_32]
RTEMS_SMP = True

So the inheritance must not be picking something up.

It should work now.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user: Add migration hints from old build system

[Sebastian Huber]

On 26/09/2020 17:50, Joel Sherrill wrote:


Why the __ around RTEMS_ADA and no other option?
There is a one to one correspondence between the BSP option name and the 
define in .


I think the first order of business is to explain how to translate 
existing configure and build steps to the new one. I think adding a 
simple example with a couple of enable/disable and the corresponding 
waf would help. Every user has to face this.


Then explaining multiple bsps but I don't know how common that is in 
actual use.


Let's focus on getting folks across the transition hurdle first.


I think this is all covered by:

https://docs.rtems.org/branches/master/user/bld/index.html

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

Re: [rtems commit] build: Fix enabled-by evaluation

[Chris Johns]

On 27/9/20 5:40 pm, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:b8d84015a4bc30f280b3e39f3f806e1ec0b2ec7a
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=b8d84015a4bc30f280b3e39f3f806e1ec0b2ec7a
> 
> Author:Sebastian Huber 
> Date:  Sun Sep 27 09:35:06 2020 +0200
> 
> build: Fix enabled-by evaluation
> 
> For the enabled-by evaluation we have to use the BSP name defined by the
> build specification and not the user.
> 
> Update #3818.
> 
> ---
> 
>  wscript | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/wscript b/wscript
> index 5a6400e..e5ac53f 100755
> --- a/wscript
> +++ b/wscript
> @@ -1355,12 +1355,13 @@ def configure_variant(conf, cp, bsp_map, path_list, 
> top_group, variant):

I think the below fragment needs a comment along the lines of the commit
message. It is difficult to see this and understand what is happening.

>  conf.setenv(variant)
>  arch, bsp_name = variant.split("/")
>  bsp_base = bsp_map.get(bsp_name, bsp_name)
> +arch_bsp = arch + "/" + bsp_base

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

[PATCH] build: Add comment

[Sebastian Huber]

Update #3818.
---
 wscript | 4 
 1 file changed, 4 insertions(+)

diff --git a/wscript b/wscript
index 6280afa6c9..1670acf936 100755
--- a/wscript
+++ b/wscript
@@ -1362,7 +1362,11 @@ def configure_variant(conf, cp, bsp_map, path_list, 
top_group, variant):
 conf.env["BSP_BASE"] = bsp_base
 conf.env["BSP_NAME"] = bsp_name
 conf.env["DEST_OS"] = "rtems"
+
+# For the enabled-by evaluation we have to use the base BSP defined by the
+# build specification and not the BSP name provided by the user.
 conf.env["ENABLE"] = [get_compiler(conf, cp, variant), arch, arch_bsp]
+
 conf.env["TOP"] = conf.path.abspath()
 conf.env["TOPGROUP"] = top_group
 conf.env["VARIANT"] = variant
-- 
2.26.2

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

Re: [PATCH] build: Add comment

[Chris Johns]

Thanks, this is great. OK to push.

On 28/9/20 2:18 pm, Sebastian Huber wrote:
> Update #3818.
> ---
>  wscript | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/wscript b/wscript
> index 6280afa6c9..1670acf936 100755
> --- a/wscript
> +++ b/wscript
> @@ -1362,7 +1362,11 @@ def configure_variant(conf, cp, bsp_map, path_list, 
> top_group, variant):
>  conf.env["BSP_BASE"] = bsp_base
>  conf.env["BSP_NAME"] = bsp_name
>  conf.env["DEST_OS"] = "rtems"
> +
> +# For the enabled-by evaluation we have to use the base BSP defined by 
> the
> +# build specification and not the BSP name provided by the user.
>  conf.env["ENABLE"] = [get_compiler(conf, cp, variant), arch, arch_bsp]
> +
>  conf.env["TOP"] = conf.path.abspath()
>  conf.env["TOPGROUP"] = top_group
>  conf.env["VARIANT"] = variant
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 6/8] score: Add AArch64 port

[Sebastian Huber]

On 25/09/2020 20:45, Kinsey Moore wrote:

-Original Message-
From: Sebastian Huber 
Sent: Friday, September 25, 2020 11:20
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 6/8] score: Add AArch64 port

On 25/09/2020 17:27, Kinsey Moore wrote:


diff --git a/cpukit/include/rtems/score/tls.h
b/cpukit/include/rtems/score/tls.h
index 65a49d87be..8c15eee569 100644
--- a/cpukit/include/rtems/score/tls.h
+++ b/cpukit/include/rtems/score/tls.h
@@ -85,7 +85,7 @@ typedef struct TLS_Thread_control_block {
 struct TLS_Thread_control_block *tcb;
   #else /* !__i386__ */
 TLS_Dynamic_thread_vector *dtv;
-#if CPU_SIZEOF_POINTER == 4
+#if CPU_SIZEOF_POINTER == 4 || CPU_SIZEOF_POINTER == 8
 uintptr_t reserved;
   #endif
   #endif /* __i386__ */

Are you sure this is correct? TLS_Dynamic_thread_vector *dtv; is 8 bytes in 
this case.
[]
Dropping this change causes sptls01 to fail. This was added pretty early in the 
implementation, so I've just had to go back and refresh my memories of the 
reasoning behind it which still may not be entirely accurate. Sptls01 fails 
without this patch because under AArch64/LP64, gcc and gdb expect a 16 byte 
offset to the TLS data segment. If this patch is not present, the TCB is half 
the size it needs to be and so getting a TLS variable address ends up indexing 
into the TCB+TLS data segment at a compiler-expected offset that does not 
correspond to the actual data layout. I adjusted this to match the compiler's 
offset expectations. There may be a better way to fix this issue, but this is 
the most appropriate location I could find that made the most sense. The 
biggest worry I have here is that this may break other architectures that also 
have 8 byte pointers. When I fix the file headers, I'll see if I can make this 
more specific to AArch64.


Yes, the AArch64 seems to use a TCB size of 16 bytes. It would be good 
to reference all ABI related documents in the CPU supplement.


For PowerPC 64-Bit ELF V2 ABI, the TCB is 8 bytes 
(implementation-dependent extra fields may be added before the DTV pointer):


http://openpowerfoundation.org/wp-content/uploads/resources/leabi-prd/content/dbdoclet.50655241_50444.html

I guess we have to make this definition a bit more architecture-dependent.

--
Sebastian Huber, embedded brains GmbH

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

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