[AArch64] libgloss nosys.specs

[AArch64] libgloss nosys.specs

[Alexander Fedotov]

Hello

Could anyone describe main idea how to use newlib for AArch64
baremetal with nosys.specs ?

I'm observing following problems:
1. crt0.s always build with ARM_RDI_MONITOR, while ARM port has
different way with rdimon-crt0.s. ARM rdimon.specs utilize
rdimon-crt0.s, while AArch64 is not.
2. how to run it with disabled semihosting and nosys.specs ? Core just
stuck on HLT instruction on third line of _start ( AngelSVCAsm
AngelSVC) and that's all.

Best regards,
Alex

Re: [AArch64] libgloss nosys.specs

[Yao Qi]

On 17-08-08 12:46:02, Alexander Fedotov wrote:
> Hello
> 
> Could anyone describe main idea how to use newlib for AArch64
> baremetal with nosys.specs ?

It doesn't work, unfortunately.  I had some local patches to get it
working.

> 
> I'm observing following problems:
> 1. crt0.s always build with ARM_RDI_MONITOR, while ARM port has
> different way with rdimon-crt0.s. ARM rdimon.specs utilize
> rdimon-crt0.s, while AArch64 is not.

Revert this commit cd26662dc590235e27e17eec773c5a308e6d863f

> 2. how to run it with disabled semihosting and nosys.specs ? Core just
> stuck on HLT instruction on third line of _start ( AngelSVCAsm
> AngelSVC) and that's all.

Wrap them with #ifdef ARM_RDI_MONITOR.  libgloss/aarch64/crt0.S still
pulls in semi-hosting stuff unconditionally,

 1. Get memory layout (stack, heap) via semi-hosting.  You can wrap it
 by ARM_RDI_MONITOR, but give the stack a fixed value, like this,

           exposed here in the HeapInfo Angel call.  */
        ldr     x0, .LC0                /* point at returned values */
        ldr     x1, [x0, #8]            /* get heap_limit */
+#else
+       /* Set up the stack pointer to a fixed value.  */
+       ldr     x1, .Lstack
+#endif

@@ -243,6 +249,10 @@ FUNCTION (_cpu_init_hook):
        GEN_DWORD __bss_start__
 .LC2:
        GEN_DWORD __bss_end__
+
+.Lstack:
+       GEN_DWORD 0x800000

 It is a hack, but good enough to get my work done.  You need to give
 a reasonable stack address for your configuration.

 2. Get command line options via semi-hosting.  You can wrap it by
 ARM_RDI_MONITOR, and set argc 0 and argv = NULL, like this,

@@ -219,6 +220,11 @@
        and     x4, x1, ~15
        mov     sp, x4
 
+#else
+       mov     x0, #0  /* argc = 0 */
+       mov     x1, #0  /* argv = NULL */
+#endif
+
        bl      FUNCTION (main)
 
        b       FUNCTION (exit)         /* Cannot return.  */

 this change above is reasonable, IMO, and I plan to upstream it.

With these stuff put together, I managed to get executable running
compiled with --spec=nosys.specs.  I am not sure your target env, device
or simulator etc.  With nosys.specs, in my side, there is no instruction
to initialize FPU, and _start in crt0.S calls memset.  The first
instruction in memset is a FPU instruction, which triggers exception
because FPU is not initialized.  I have to explicitly initialize FPU in
crt0.S.

Hope it helps, and good luck!

-- 
Yao (齐尧)

Re: [AArch64] libgloss nosys.specs

[Alexander Fedotov]

For archeologists related messages are here:
https://sourceware.org/ml/newlib/2017/msg00741.html
https://sourceware.org/ml/newlib/2017/msg00745.html

On Tue, Aug 8, 2017 at 1:34 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On 17-08-08 12:46:02, Alexander Fedotov wrote:
>> Hello
>>
>> Could anyone describe main idea how to use newlib for AArch64
>> baremetal with nosys.specs ?
>
> It doesn't work, unfortunately.  I had some local patches to get it
> working.
>
>>
>> I'm observing following problems:
>> 1. crt0.s always build with ARM_RDI_MONITOR, while ARM port has
>> different way with rdimon-crt0.s. ARM rdimon.specs utilize
>> rdimon-crt0.s, while AArch64 is not.
>
> Revert this commit cd26662dc590235e27e17eec773c5a308e6d863f
>
>> 2. how to run it with disabled semihosting and nosys.specs ? Core just
>> stuck on HLT instruction on third line of _start ( AngelSVCAsm
>> AngelSVC) and that's all.
>
> Wrap them with #ifdef ARM_RDI_MONITOR.  libgloss/aarch64/crt0.S still
> pulls in semi-hosting stuff unconditionally,
>
>  1. Get memory layout (stack, heap) via semi-hosting.  You can wrap it
>  by ARM_RDI_MONITOR, but give the stack a fixed value, like this,
>
>            exposed here in the HeapInfo Angel call.  */
>         ldr     x0, .LC0                /* point at returned values */
>         ldr     x1, [x0, #8]            /* get heap_limit */
> +#else
> +       /* Set up the stack pointer to a fixed value.  */
> +       ldr     x1, .Lstack
> +#endif
>
> @@ -243,6 +249,10 @@ FUNCTION (_cpu_init_hook):
>         GEN_DWORD __bss_start__
>  .LC2:
>         GEN_DWORD __bss_end__
> +
> +.Lstack:
> +       GEN_DWORD 0x800000
>
>  It is a hack, but good enough to get my work done.  You need to give
>  a reasonable stack address for your configuration.
>
>  2. Get command line options via semi-hosting.  You can wrap it by
>  ARM_RDI_MONITOR, and set argc 0 and argv = NULL, like this,
>
> @@ -219,6 +220,11 @@
>         and     x4, x1, ~15
>         mov     sp, x4
>
> +#else
> +       mov     x0, #0  /* argc = 0 */
> +       mov     x1, #0  /* argv = NULL */
> +#endif
> +
>         bl      FUNCTION (main)
>
>         b       FUNCTION (exit)         /* Cannot return.  */
>
>  this change above is reasonable, IMO, and I plan to upstream it.
>
> With these stuff put together, I managed to get executable running
> compiled with --spec=nosys.specs.  I am not sure your target env, device
> or simulator etc.  With nosys.specs, in my side, there is no instruction
> to initialize FPU, and _start in crt0.S calls memset.  The first
> instruction in memset is a FPU instruction, which triggers exception
> because FPU is not initialized.  I have to explicitly initialize FPU in
> crt0.S.
>
> Hope it helps, and good luck!
>
> --
> Yao (齐尧)



-- 
Best regards,
AF