[ECOS] Re:

[ECOS] Re:

[Gary Thomas]

Radu Cernea said:
>>> The difference is in the pin allocation for SMC2:
>>>
>>> - Port B21 & B20 for MPC860
>>> - Port A9 & A8 for MPC850
>>>
>>> The current version of quicc_smc1.c initialize the port pins MPC850-like
>>> (function cyg_hal_smcx_init_channel).
>>>
>>> My question is:
>>> How is it better to add the MPC860 initialization version to the eCos sources?
>>> Should I create a new file, use a conditional pre-compilation flag, orÂ…?
>>
>> What version of quicc_smc1.c are you looking at? There is supposed to be
> complete
>> support already in place for SMC1/SMC2 and SCC1/SCC2/SCC4.  If this is not the
>> case, we need to fix it *there*, not add new code somewhere else.
> Unfortunately I do not have CVS access (the IT department rulesÂ…), so I
> download snapshots from ecoscentric. In the last one (031026), IÂ’m looking at
> the file:
> /ecos/packages/hal/powerpc/quicc/current/src/quicc_smc1.c
>
> There is support for SMC2, but the initialization is not the proper one for
> MPC860. Instead of:
> 168:    eppc->pio_papar |= 0xc0;
> 169:    eppc->pio_padir &= ~0xc0;
> 170:    eppc->pio_paodr &= ~0xc0;
>
> It should be something like:
>     eppc->pip_pbpar |=   0x00000C00;
>     eppc->pip_pbdir &= ~0x00000C00;
>     eppc->pip_pbodr &= ~0x00000C00;
>
> See, for the reference, the table 34-6 in MPC860UM.pdf

Fair enough - please send a proper patch for this, along with the
ChangeLog entry.  It would also be nice to see the corresponding
patch for the interrupt driven serial driber.

Note: use something like this:
  #if defined(CYGHWR_HAL_POWERPC_860) || defined(CYGHWR_HAL_POWERPC_860T)
    ... your proposed setup
  #else
    .. current setup
  #endif





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

[ECOS] Re:

[Anthony Tonizzo]

Hello:

Please use the eCos reflector list to everyone can benefit from
the reply.

> The board used is STM3220G-EVAL.I want to download the Matlab_Simulink
> model to the board,and execute the simulink model.

I believe that you are overestimating what the library loader can do.

The object loader was designed as a very simple way to load pieces
of code in memory, relocate them and then execute the code in them.
There is nothing that prevents loading larger pieces of code (and
I know of a couple of companies that are running very sophisticated
libraries with it) but with large code, compiled by agents other than
the eCos toolchain, the chances of stumbling into roadblocks are
increasing very fast. This is your case.

The code that is loaded must be an object file that is compiled but NOT
linked, as detailed in information included in the library.

In your case it is very likely that the Matlab_Simulink library you want to
execute is some sort of executable itself, rather than an object file and
thus not a good choice for the object loader.

> but when i compile the C files under Matlab_Simulink,and link
> the libgcc.a library under the PATH
> \opt\ecos\gnutools\arm-eabi\lib\gcc\arm-eabi\4.3.2\thumb\thumb2 to the
> exectable file, the value of p_rel.r_info will be 10,which will lead
> switch() function execute the default branch and return -1,therefore
> the exectution failed.

Correct. So let's assume for the time being that the file you want to
load is indeed an object file.

The values that appear inside the switch statement have been chosen
among those described in the ARM ELF document:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf

The possible relocation codes are shown in table 4-8. As you can see
a full fledged linker must support all these types but for a simple object
loader like the one in eCos a far smaller subset is needed to cover the
majority of the cases encountered for sinple libraries comoiled with the
eCos toolchain. The codes you see in the switch() statement are
those that appeared while compiling several programs I tested during
development but the list must not be thought as complete by any
means.

In your case the code 10 corresponds to the R_ARM_THM_CALL
addressing mode (again, see table 4-8), which is a THUMB32 code
(consistent with the fact that you are using a Cortex core).

The objloader code was never tested for Thumb code, although I cannot
think of any reason why it should not work. The 4th column in the table
shows what type of relocation you have to apply for each addressing code.
You will have to add the missing addressing modes to the
cyg_ldr_relocate() function in relocate_arm.c.

Since you are entering uncharted territory here,
one piece of advice I can provide is to start simple: Compile a very
simple library with some test code in Thumb32. Load this library, and
in the process add all missing addressing modes to the cyg_ldr_relocate()
function as they are discovered by the loader (it helps a lot here to
select CYGPKG_SERVICES_OBJLOADER_DEBUG_LEVEL = 2
and let the loader be very verbose in its output so you can see immediately
what goes wrong.) Increase the complexity of the test library until you
are convinced that most required addressing modes have been
taken care of. Then, and only then, you can try the Simulink
library (which might very well require some more addressing modes
to be added.)

Since Cortex processors are very much in use today and many people
could use this, it would be greatly appreciated if you contributed the
resulting work back to the eCos community.

Regards
Anthony Tonizzo

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

[ECOS] Re:.

[Bob]

. http://fishscraps.com/iopjdosineijjfn.html?rCID=62sy

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

[ECOS] Re:

[Jonathan Larmour]

raghavendra pai g wrote:
>  
>       I created a .ecc file by adding packages such as networking , 
> common ethernet support & open bsd stack. the template i used is linux 
> synthetic target.
> 
>       i tried to compile the hello.c file but it showed me the following 
> error . Why is it so... as when i tried to compile without any of these 
> package it was correct.
[snip]
> /root/proj/test/tr3_install/lib//libtarget.a(net_tcpip_sys_generic.o): 
> In function `sys_ioctl':
> /opt/ecos-2.0/packages/net/tcpip/v2_0/src/sys/kern/sys_generic.c:130: 
> multiple definition of `sb_max'
> /root/proj/test/tr3_install/lib//libtarget.a(net_tcpip_support.o)(.bss.sb_max+0x0): 
> first defined here
> collect2: ld returned 1 exit status
> 
> can u tell me why is it so  ......... and the solution for it

Yes, don't use the OpenBSD stack. Use the FreeBSD stack. In other words, 
use the "net" template.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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

RE: [ECOS] Re:

[Doug Fraser]

For the config switch <#if defined(CYGHWR_HAL_POWERPC_860)>
you should also include the 821, as it has the same pio
usage as the 860. The 850 and the 823 both use port A,
the 860 (and its variants) and the 821 use port B as noted
below.

Doug Fraser

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Tuesday, October 28, 2003 10:08 AM
> To: Radu Cernea
> Cc: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Re: 
> 
> 
> 
> Radu Cernea said:
> >>> The difference is in the pin allocation for SMC2:
> >>>
> >>> - Port B21 & B20 for MPC860
> >>> - Port A9 & A8 for MPC850
> >>>
> >>> The current version of quicc_smc1.c initialize the port 
> pins MPC850-like
> >>> (function cyg_hal_smcx_init_channel).
> >>>
> >>> My question is:
> >>> How is it better to add the MPC860 initialization version 
> to the eCos sources?
> >>> Should I create a new file, use a conditional 
> pre-compilation flag, or...?
> >>
> >> What version of quicc_smc1.c are you looking at? There is 
> supposed to be
> > complete
> >> support already in place for SMC1/SMC2 and SCC1/SCC2/SCC4. 
>  If this is not the
> >> case, we need to fix it *there*, not add new code somewhere else.
> > Unfortunately I do not have CVS access (the IT department 
> rules...), so I
> > download snapshots from ecoscentric. In the last one 
> (031026), I'm looking at
> > the file:
> > /ecos/packages/hal/powerpc/quicc/current/src/quicc_smc1.c
> >
> > There is support for SMC2, but the initialization is not 
> the proper one for
> > MPC860. Instead of:
> > 168:    eppc->pio_papar |= 0xc0;
> > 169:    eppc->pio_padir &= ~0xc0;
> > 170:    eppc->pio_paodr &= ~0xc0;
> >
> > It should be something like:
> >     eppc->pip_pbpar |=   0x00000C00;
> >     eppc->pip_pbdir &= ~0x00000C00;
> >     eppc->pip_pbodr &= ~0x00000C00;
> >
> > See, for the reference, the table 34-6 in MPC860UM.pdf
> 
> Fair enough - please send a proper patch for this, along with the
> ChangeLog entry.  It would also be nice to see the corresponding
> patch for the interrupt driven serial driber.
> 
> Note: use something like this:
>   #if defined(CYGHWR_HAL_POWERPC_860) || 
> defined(CYGHWR_HAL_POWERPC_860T)
>     ... your proposed setup
>   #else
>     .. current setup
>   #endif
> 
> 
> 
> 
> 
> -- 
> Before posting, please read the FAQ: 
http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

[ECOS] Re:

[Gary Thomas]

On Sat, 2002-12-21 at 06:54, zhe zhang wrote:
> Sorry to send mail to u directly , my mail server can not send mail to the ecos mail list .
> 

Note: help via the ecos-discuss mailing is free.  Professional
assistance is available from many companies, including my own.
Sorry, but email sent directly to me without a support contract
will be ignored.

> You gave me an helpful response on the mail list , and I worked it out , that is to say , I got a floppy to boot my pc(x86)
> 
> but I found I can not run the executable loaded to the target via serial/xmodem, as below:
> 
> RedBoot> load -v -m xmodem -c 1 -b 0x0007c000
> CAddress offset = 0xfff7c000
> Entry point: 0x0007c00c, address range: 0x0007c000-0x000949a4
> xyzModem - CRC mode, 7535(SOH)/0(STX)/0(CAN) packets, 3 retries
> RedBoot> exec
> ** Error: Illegal command: "exec"
> 
> I read the document and found pc-redboot do not support "exec" . Does it mean that I can not load another RTOS executable to my target by use of redboot ? 
> 

The "exec" command is normally designed for running Linux from RedBoot.
This is not currently implemented for the x86 PC target.

This does not mean that you can't run arbitrary programs from RedBoot.
You can, but some rules will have to be followed.  When you type 'go'
(as below), RedBoot simply hands the CPU over to the program.  That
program must be capable of managing the processor completely.  On the
PC, this may mean switching modes, setting up MMU tables, etc.

> When I tried "go 0x007c000", target reboot .
> 
> Can u give me some advice ? 

Without knowing more about what you are trying to run, I can't
help more than what I've already given.  What sort of program
are you trying to load/run on this device?

If you're interested in contracted help (pay by the hour), this
can certainly be arranged.  If you only want free help, ask on
ecos-discuss.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------


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

[ECOS] Re:

[Jonathan Larmour]

"amassa@cts.com" wrote:
> I all of the tests from the ecos configuration program and found that the
> intr0.exe was the only one that would consistently fail.  Do you know what
> could cause this?
> 
> Occasionally, I would get a message:
> 
> Program received signal SIGILL, Illegal instruction.
> 
> What does this message mean?

It means the CPU tried to run an instruction that isn't a real instruction.
Is it repeatable? It may indicate a hardware memory corruption problem if
it is random.
 
> Then I ran the twothreads example on my MBX target board and it seems like
> it ran through the two threads once and then tried to exit the program.  The
> output is below.  I can't seem to get the example programs to run properly.
> Do you know why the threads may be descheduling and the program exiting?
> 
> Entering twothreads' cyg_user_start() function
> Beginning execution; thread data is 0
> Beginning execution; thread data is 1
> 
> Breakpoint 1, __libc_exit (status=286326805) at
> //D/PROGRA~1/REDHAT~1/eCos/packages/language/c/libc/v1_3_1/src/stdlib/exit.cxx:82
> Current language:  auto; currently c++

You have a breakpoint set on "exit", but since the twothreads program
doesn't have a "main", the default libc-defined main is run instead, and
that just calls exit straight away.

Simply don't set a breakpoint on exit and forget about it :-).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault