This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Evaluator 7T: using Redboot syscalls


>>>>> Pierre Habraken writes:

> Mark Salter wrote:
>> [...]
>> > Does anyone know how to tell newlib not to use Angel services ?
>> 
>> If you're building a newlib based app, you should use the redboot
>> support in libgloss to build your app.
>> 
>> % arm-elf-gcc -specs=redboot.specs -Ttext=0x10000 ....
>> 
>> The "redboot.specs" part will ensure that RedBoot recognizable SWIs
>> are used, not the Angel ones in libc. This will only work if RedBoot
>> was built with CYGSEM_REDBOOT_BSP_SYSCALLS turned on.

> I just installed the latest (stable) release of newlib (1.11.0).
> I am using a ready to use (?) redboot.UU I found somewhere on the eCos
> site.
> When I launch the program gdb sigtraps:
> ===============================================================
> (gdb) cont
> Continuing.

> Program received signal SIGTRAP, Trace/breakpoint trap.
> __syscall (func_no=0)
>     at ../../../../../newlib-1.11.0/libgloss/arm/redboot-syscalls.c:31
> 31          asm ("swi 0x180001\n");
> ===============================================================
> I suppose the reason is that I am using a wrong RedBoot image and thus
> I'll have to re-build RedBoot with the option you mention above
> (something which does not sound straightforward at first glance...).

Add:

  cdl_component CYGSEM_REDBOOT_BSP_SYSCALLS {
      inferred_value 1
  };

to your redboot_{ROM,RAM}.ecm file.


> However, I do not understand why the trap happens at this point:
> the SWI vector contains a LDR instruction:
> 0x8: ldr pc, [pc, #24] ; 0x28
> furthermore, the memory at address 0x28 contains the address (0x182029c)
> of a valid instruction:
> 0x182029c: sub   sp, sp, #92 ; 0x5c
> 0x18202a0: stmia sp, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11}
> 0x18202a4: mrs   r0, SPSR
> 0x18202a8: ...

What is happening is the stub sees a SWI it does not recognize. The stub
reports a SIGTRAP to gdb with the address of the swi insn.

> So, I'd expect that I could step in through the SWI vector, but actually
> a breakpoint installed at redboot-syscalls.c:31 does not allow me to
> step in beyond that point, as if the SWI instruction could not be
> executed...

Yeah, this is a known limitation in the stub. Stepping into a swi doesn't
work. I think the reason for this limitation has been removed, but the
limitiation itself remains. The problem is in arm_stub.c where:

target_ins()
{
   ...
   case 0x3:  // Coprocessor & SWI
     return (pc+1);
   ...
}

That needs to be filled out to differentiate the SWI from copro insns and
to return the address where the SWI will take you. Something similar should
be done in target_thumb_ins().

--Mark

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]