[ECOS] Regarding to eCos on VRC4373

[ECOS] Regarding to eCos on VRC4373

[Ling Su]

Hi, Dear All,

After previous struggle, I can work with eCos on the VRC4373 board in Linux
environment. Since some new members just joined the team, and not all of
them love Linux platform that much, I need to figure out a way for them in
WindowsNT/2000. Currently I have some questions, please refer following,

<1>. After compiling egcs snapshot in Windows environment, during
compilation, it also complains "xxx.h is shorter than expected...". What's
wrong with that? How to eliminate them? It is really anonoying.

<2>. We have some communication application developed on the board,
unfortunately the eCos defaultly in Big Endian mode for VRC4373. Since
communication application usually in Little Endian mode, I don't know the
rational reason behind the Big Endian choice for this platform, and I also
would like to know the possibility to compile eCos GDB stub and lib in
Little Endian mode, can we do it smoothly or need any hacking on the source
code?

Best Regards,
-Ling

Re: [ECOS] Regarding to eCos on VRC4373

[Jonathan Larmour]

Ling Su wrote:
> 
> Hi, Dear All,
> 
> After previous struggle, I can work with eCos on the VRC4373 board in Linux
> environment. Since some new members just joined the team, and not all of
> them love Linux platform that much, I need to figure out a way for them in
> WindowsNT/2000. Currently I have some questions, please refer following,
> 
> <1>. After compiling egcs snapshot in Windows environment, during
> compilation, it also complains "xxx.h is shorter than expected...". What's
> wrong with that? How to eliminate them? It is really anonoying.

We would need more details of the error than that.
 
> <2>. We have some communication application developed on the board,
> unfortunately the eCos defaultly in Big Endian mode for VRC4373. Since
> communication application usually in Little Endian mode, I don't know the
> rational reason behind the Big Endian choice for this platform, and I also
> would like to know the possibility to compile eCos GDB stub and lib in
> Little Endian mode, can we do it smoothly or need any hacking on the source
> code?

You will probably need to make some adjustments in the platform code. But
I believe the architecture and variant HALs should work because we have a
v4300-based internal board that used to be little-endian if I remember
right.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Regarding to eCos on VRC4373

[Ling Su]

> > <2>. We have some communication application developed on the board,
> > unfortunately the eCos defaultly in Big Endian mode for VRC4373. Since
> > communication application usually in Little Endian mode, I don't know
the
> > rational reason behind the Big Endian choice for this platform, and I
also
> > would like to know the possibility to compile eCos GDB stub and lib in
> > Little Endian mode, can we do it smoothly or need any hacking on the
source
> > code?
>
> You will probably need to make some adjustments in the platform code. But
> I believe the architecture and variant HALs should work because we have a
> v4300-based internal board that used to be little-endian if I remember
> right.
>

Can you disclouse which vr4300 based board is running eCos, I am just
curious since I didn't find any supported platform on eCos website except
the vrc4373 evaluation board.

I briefly checked the platform code, I didn't find any specific point to
modify since the Macro define CYG_LSBFIRST or CYG_MSBFIRST looks to me take
care of a lot of endian issues. I am just wondering why the Little Endian
mode is illegal for VR4300 platform. What I can think of doing first is to
try to enable it and make the monitor, is that doable?

Since I found the PMON comes together with NEC board is Little endian, can I
just complile the eCos lib in Little endian mode and debug it using PMON?
Any comments on this way? Thanks a lot!

-Ling

Re: [ECOS] Regarding to eCos on VRC4373

[Nick Garnett]

"Ling Su" <lingsu@palmmicro.com> writes:

> > > <2>. We have some communication application developed on the board,
> > > unfortunately the eCos defaultly in Big Endian mode for VRC4373. Since
> > > communication application usually in Little Endian mode, I don't know
> the
> > > rational reason behind the Big Endian choice for this platform, and I
> also
> > > would like to know the possibility to compile eCos GDB stub and lib in
> > > Little Endian mode, can we do it smoothly or need any hacking on the
> source
> > > code?
> >
> > You will probably need to make some adjustments in the platform code. But
> > I believe the architecture and variant HALs should work because we have a
> > v4300-based internal board that used to be little-endian if I remember
> > right.
> >
> 
> Can you disclouse which vr4300 based board is running eCos, I am just
> curious since I didn't find any supported platform on eCos website except
> the vrc4373 evaluation board.

We originally did the port to the VRC4373 in little-endian mode
because, as you point out below, PMON runs in little-endian
mode. However, the customer we were doing this for wanted to run in
big-endian mode, so we swapped it over.

Other boards, such as the TX39 run in little-endian mode, so the HAL
architecture code should be OK. Only the platform code may need some
work.

> 
> I briefly checked the platform code, I didn't find any specific point to
> modify since the Macro define CYG_LSBFIRST or CYG_MSBFIRST looks to me take
> care of a lot of endian issues. I am just wondering why the Little Endian
> mode is illegal for VR4300 platform. What I can think of doing first is to
> try to enable it and make the monitor, is that doable?
>

The main thing that might cause a problem is access to the
devices. While some of the chips will swap endianness with the CPU,
others may need some changes to the access software to cope. I don't
recall the exact details.


> Since I found the PMON comes together with NEC board is Little endian, can I
> just complile the eCos lib in Little endian mode and debug it using PMON?
> Any comments on this way? Thanks a lot!
> 

That is certainly worth trying. However the PMON code in the HAL has
not been used for some time, so it may be out of step with the rest of
the system.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

[ECOS] assertion checks for stack

[Joerg Rapka]

Hello all

I have some trouble with assertion checks for the stack
in file "packages/kernel/current/include/thread.inl".

The assertion checks uses the type "CYG_WORD" for alignment tests.
This type "CYG_WORD" is defined in file
"packages/infra/current/include/cyg_type.h".
It is of type "cyg_uint32" (that's fixed - so it should have always 32
bits).
So the assertion checks for the stack requires a 32-bit alignment of the
stack address.

I'm using the following:
- Motorola M68331 CPU
- latest CVS sources
- template "elix" (without network support)

On my target the assertion check generates a failure, if it checks the main
stack.
This main stack is defined in file
"packages/compat/posix/current/src/pthread.cxx"
in the following way:
static char main_stack[CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE];

This error happens, since the m68k GNU compiler will align the "main_stack"
to 16-bit alignment.

How should I solve the problem?
I cannot (will not) modify the definition of the "main_stack" in file
"pthread.cxx"
either I cannot modify the type definition of "CYG_WORD" in file
"cyg_type.h" (since
this type must have 32-bit - as I understood the rest of the source code).

Thanks in advance for any help or tips.


Best regards, Joerg

Re: [ECOS] Regarding to eCos on VRC4373

[Jonathan Larmour]

Ling Su wrote:
> Can you disclouse which vr4300 based board is running eCos, I am just
> curious since I didn't find any supported platform on eCos website except
> the vrc4373 evaluation board.

Sorry no, nor is it publically available in any case.

> I briefly checked the platform code, I didn't find any specific point to
> modify since the Macro define CYG_LSBFIRST or CYG_MSBFIRST looks to me take
> care of a lot of endian issues. I am just wondering why the Little Endian
> mode is illegal for VR4300 platform. What I can think of doing first is to
> try to enable it and make the monitor, is that doable?

Well, that's where to start, but you may find that some platform code makes
assumptions about the endianness. The only way is to try and see, but if
you say you can only blow one EPROM, this may limit your options :-/.
 
> Since I found the PMON comes together with NEC board is Little endian, can I
> just complile the eCos lib in Little endian mode and debug it using PMON?
> Any comments on this way? Thanks a lot!

It's worth a go. If you do this, remember to set CYGSEM_HAL_USE_ROM_MONITOR
to PMON.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Regarding to eCos on VRC4373

[Ling Su]

> > After previous struggle, I can work with eCos on the VRC4373 board in
Linux
> > environment. Since some new members just joined the team, and not all of
> > them love Linux platform that much, I need to figure out a way for them
in
> > WindowsNT/2000. Currently I have some questions, please refer following,
> >
> > <1>. After compiling egcs snapshot in Windows environment, during
> > compilation, it also complains "xxx.h is shorter than expected...".
What's
> > wrong with that? How to eliminate them? It is really anonoying.
>
> We would need more details of the error than that.
>

I have prepare a more detailed information for this later.

I tried the newest snapshot of gcc for VR4300 processor, unfortunately the
patch available on VRC4373 developments tools webpage are all obselete. I
tried to apply them, a lot of failures, any newer version gcc has been
tested except the snapshot20000313 version?

Best Regards,
-Ling

Re: [ECOS] Regarding to eCos on VRC4373

[Jonathan Larmour]

Ling Su wrote:
> 
> I tried the newest snapshot of gcc for VR4300 processor, unfortunately the
> patch available on VRC4373 developments tools webpage are all obselete. I
> tried to apply them, a lot of failures, any newer version gcc has been
> tested except the snapshot20000313 version?

Sorry, no :(. I would obviously be very interested in updated patches,
otherwise stick to the snapshot.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Regarding to eCos on VRC4373

[Jonathan Larmour]

Ling Su wrote:
> 
> Another questions is: What's the time unit used in eCos, in kernel API or
> timer/counter object, such as cyg_thread_delay(time), how to set the delay
> time, it is in microsecond unit or more?

It is in clock ticks, which are platform-specific. You can use the kernel
API functions at 
http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.9.html

Specifically, look at the definition of cyg_resolution_t, and notice you
can use cyg_clock_get_resolution( cyg_real_time_clock ) to get a
cyg_resolution_t for your real-time-clock.

A shortcut given that you know the platform is to look at the CDL for the
vrc4373 which includes the fields CYGNUM_HAL_RTC_NUMERATOR and
CYGNUM_HAL_RTC_DENOMINATOR which correspond to the fields in the
cyg_resolution_t. This is 1000000000 and 100 respectively, giving
10,000,000 ns/tick == 10 ms/tick.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Regarding to eCos on VRC4373

[Ling Su]

> It is in clock ticks, which are platform-specific. You can use the kernel
> API functions at
> http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.9.html
>
> Specifically, look at the definition of cyg_resolution_t, and notice you
> can use cyg_clock_get_resolution( cyg_real_time_clock ) to get a
> cyg_resolution_t for your real-time-clock.
>
> A shortcut given that you know the platform is to look at the CDL for the
> vrc4373 which includes the fields CYGNUM_HAL_RTC_NUMERATOR and
> CYGNUM_HAL_RTC_DENOMINATOR which correspond to the fields in the
> cyg_resolution_t. This is 1000000000 and 100 respectively, giving
> 10,000,000 ns/tick == 10 ms/tick.
>
Thanks, Jifl,

If I need a timer faster than 10ms/tick, could I increase denominator or
decrease the numerator? I can it is a caculated value, user can not specify.
How could I change them and what is the consequences?

Regards,
-Ling

Re: [ECOS] Regarding to eCos on VRC4373

[Jonathan Larmour]

Ling Su wrote:
> 
> > It is in clock ticks, which are platform-specific. You can use the kernel
> > API functions at
> > http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.9.html
> >
> > Specifically, look at the definition of cyg_resolution_t, and notice you
> > can use cyg_clock_get_resolution( cyg_real_time_clock ) to get a
> > cyg_resolution_t for your real-time-clock.
> >
> > A shortcut given that you know the platform is to look at the CDL for the
> > vrc4373 which includes the fields CYGNUM_HAL_RTC_NUMERATOR and
> > CYGNUM_HAL_RTC_DENOMINATOR which correspond to the fields in the
> > cyg_resolution_t. This is 1000000000 and 100 respectively, giving
> > 10,000,000 ns/tick == 10 ms/tick.
> >
> Thanks, Jifl,
> 
> If I need a timer faster than 10ms/tick, could I increase denominator or
> decrease the numerator? I can it is a caculated value, user can not specify.
> How could I change them and what is the consequences?

Edit the source.

The numerator and denominator describe what the setting is. They are not
the setting itself. The setting itself if CYGNUM_HAL_RTC_PERIOD - that's
what gets programmed into the timer chip. You would then change the
numerator and denominator to reflect that.

You will need to work out yourself what the values for the period,
numerator and denominator that you want are.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Regarding to eCos on VRC4373

[Grant Edwards]

On Wed, Jan 10, 2001 at 02:07:57PM -0800, Ling Su wrote:

> If I need a timer faster than 10ms/tick, could I increase denominator or
> decrease the numerator? I can it is a caculated value, user can not specify.
> How could I change them and what is the consequences?

The last time I messed with changing the tick value (10 or 11
months back) I discovered that there were several places
(tests, network stuff, IIRC) that assumed a 10ms tick.  It's
not a big problem, but something to be aware of.  I had a
system that seemed to work fine with a 1ms tick. I never
bothered to fix the network timings, since I decied to change
back to a 10ms tick.

-- 
Grant Edwards
grante@visi.com