[ECOS] Header files in platform port

[ECOS] Header files in platform port

[Paul Pham]

Hi all,

I am trying to do a platform port of eCos to an eval. board with one of
Samsung's ARM-based chips (the S3C3410X). As the porting guide suggested, I
copied the files from another platform (in this case, the PID), and made the
necessary modifications. However, when I try to build the libraries with the
Windows Configuration Tool, it fails to generate the following header files:

<pkg_install_dir>/include/pkgconf/error.h
<pkg_install_dir>/include/pkgconf/hal.h
<pkg_install_dir>/include/pkgconf/hal_arm.h
<pkg_install_dir>/include/pkgconf/hal_arm_<platform>.h
<pkg_install_dir>/include/pkgconf/infra.h
<pkg_install_dir>/include/pkgconf/io.h
<pkg_install_dir>/include/pkgconf/io_serial.h
<pkg_install_dir>/include/pkgconf/kernel.h
<pkg_install_dir>/include/pkgconf/libc.h
<pkg_install_dir>/include/pkgconf/libm.h
<pkg_install_dir>/include/pkgconf/system.h
<pkg_install_dir>/include/pkgconf/wallclock.h

Any idea what I'm doing wrong?

Many thanks,
Paul Pham

[ECOS] hal_copy_data and hal_zero_bss

[Chris Morrow]

The hal_copy_data() and hal_zero_bss() in the mips architecture
currently
do byte reads and writes. Is there any reason they shouldn't use the
memset() and memcpy() functions from infra?

-- 
Chris Morrow	YottaYotta Inc.
email:		cmorrow@yottayotta.com
phone:		(780) 439 9000 ext 227
web:		http://www.yottayotta.com

Re: [ECOS] hal_copy_data and hal_zero_bss

[Jonathan Larmour]

Chris Morrow wrote:
> 
> The hal_copy_data() and hal_zero_bss() in the mips architecture
> currently
> do byte reads and writes. Is there any reason they shouldn't use the
> memset() and memcpy() functions from infra?

There's no guarantee that calling memcpy and memset won't reference
different versions of those functions that rely on the BSS being zeroed or
there being initialized data. e.g. in a debug build.

Better to write those to do word accesses, taking into account that the
symbols may not be word-aligned. They should, but they may not be and we
shouldn't explode if they aren't.

It would probably be even better to just code them in assembler anyway, and
avoid the call from vectors.S. It's easy to write a Duff's device
implementation in asm too. Patches welcome :).

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] Header files in platform port

[Jonathan Larmour]

Paul Pham wrote:
> 
> However, when I try to build the libraries with the
> Windows Configuration Tool, it fails to generate the following header files:
> 
> <pkg_install_dir>/include/pkgconf/error.h
> <pkg_install_dir>/include/pkgconf/hal.h
> <pkg_install_dir>/include/pkgconf/hal_arm.h
> <pkg_install_dir>/include/pkgconf/hal_arm_<platform>.h
> <pkg_install_dir>/include/pkgconf/infra.h
> <pkg_install_dir>/include/pkgconf/io.h
> <pkg_install_dir>/include/pkgconf/io_serial.h
> <pkg_install_dir>/include/pkgconf/kernel.h
> <pkg_install_dir>/include/pkgconf/libc.h
> <pkg_install_dir>/include/pkgconf/libm.h
> <pkg_install_dir>/include/pkgconf/system.h
> <pkg_install_dir>/include/pkgconf/wallclock.h
> 
> Any idea what I'm doing wrong?

These files should get generated when you save your configuration. Is there
some CDL error in your configuration, such as conflicts? Look at (I think)
View->Conflicts. 

I take it that this works fine for the PID.

You could try the command-line tool for comparison purposes. Go to a bash
prompt and type:

export ECOS_REPOSITORY=<your eCos source repository>
ecosconfig new <your platform>
ecosconfig check
ecosconfig tree
make

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] hal_copy_data and hal_zero_bss

[Chris Morrow]

Jonathan Larmour wrote:
> 
> Chris Morrow wrote:
> >
> > The hal_copy_data() and hal_zero_bss() in the mips architecture
> > currently
> > do byte reads and writes. Is there any reason they shouldn't use the
> > memset() and memcpy() functions from infra?
> 
> There's no guarantee that calling memcpy and memset won't reference
> different versions of those functions that rely on the BSS being zeroed or
> there being initialized data. e.g. in a debug build.
> 
> Better to write those to do word accesses, taking into account that the
> symbols may not be word-aligned. They should, but they may not be and we
> shouldn't explode if they aren't.
> 
> It would probably be even better to just code them in assembler anyway, and
> avoid the call from vectors.S. It's easy to write a Duff's device
> implementation in asm too. Patches welcome :).
> 
> 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

An assembler version of hal_zero_bss is included
at the end of this message. I placed mine in
vectors.S. I'm not sure where you would like it.

Currently the start up code calls hal_copy_data before
hal_zero_bss. Since at this point the stack is in bss
when calling hal_zero_bss, I can understand why hal_zero_bss
needs to avoid memset(). If the order of calls to mem_copy_data
and hal_zero_bss were switched, what would prevent the use
of memcpy in hal_copy_data? I can't think of any initialized
data memcpy would depend on.

##-----------------------------------------------------------------------------
## hal_zero_bss
## Zero bss. Done is assembler to avoid problem of zeroing
## bss while using it.
FUNC_START(hal_zero_bss)
#ifdef CYGHWR_HAL_MIPS_64BIT
#define STORE_OP	sd
#define BLOCK_SHIFT	6
#else
#define STORE_OP	sw
#define BLOCK_SHIFT	5
#endif
	la	a0,__bss_start		# start of bss
	la	a1,__bss_end		# end of bss
	andi	a2,a0,mips_regsize-1	# is bss aligned?
	bne	a2,zero,1f		# skip word copy
	nop
	
	# loop with 8 stores per loop
	subu		a3,a1,a0		# get length
	srl		a3,a3,BLOCK_SHIFT	# get number of blocks
	sll		a3,a3,BLOCK_SHIFT	# get length of blocks
	addu		a3,a0,a3		# get end addr of blocks
2:	STORE_OP	zero,(mips_regsize*0)(a0)
	STORE_OP	zero,(mips_regsize*1)(a0)
	STORE_OP	zero,(mips_regsize*2)(a0)
	STORE_OP	zero,(mips_regsize*3)(a0)
	STORE_OP	zero,(mips_regsize*4)(a0)
	STORE_OP	zero,(mips_regsize*5)(a0)
	STORE_OP	zero,(mips_regsize*6)(a0)
	STORE_OP	zero,(mips_regsize*7)(a0)
	addu		a0,a0,mips_regsize*8	# next addr
	bne		a3,a0,2b		# to next store
	nop

	# finish 1 byte at a time
1:	sb	zero,0(a0)		# zero memory
	addiu	a0,a0,1			# next addr
	bne	a0,a1,1b		# to next store
	nop
	jr	ra
FUNC_END(hal_zero_bss)

-- 
Chris Morrow	YottaYotta Inc.
email:		cmorrow@yottayotta.com
phone:		(780) 439 9000 ext 227
web:		http://www.yottayotta.com

[ECOS] mips mmu setup

[Chris Morrow]

For the vrc4373 port, the hal_mips_setup routine
use add instructions for the following sequence.

	li	tmp,PADDR_INC
	add	vaddr,vaddr,tmp
	add	paddr0,paddr0,tmp

Which is okay until you try to map in 2 gig of
address space at which point the vaddr calculate
will result in 0x80000000 during the last interation
of the loop. This will cause an interger overflow
exception.

All the add's in that function should probably be addu's.

-- 
Chris Morrow	YottaYotta Inc.
email:		cmorrow@yottayotta.com
phone:		(780) 439 9000 ext 227
web:		http://www.yottayotta.com

Re: [ECOS] mips mmu setup

[Jonathan Larmour]

Chris Morrow wrote:
> 
> For the vrc4373 port, the hal_mips_setup routine
> use add instructions for the following sequence.
> 
>         li      tmp,PADDR_INC
>         add     vaddr,vaddr,tmp
>         add     paddr0,paddr0,tmp
> 
> Which is okay until you try to map in 2 gig of
> address space at which point the vaddr calculate
> will result in 0x80000000 during the last interation
> of the loop. This will cause an interger overflow
> exception.
> 
> All the add's in that function should probably be addu's.

Thanks for the report. Assuming you have hardware that barfs on this, in
the next anonymous CVS update, can you check that I've got all the ones
that need doing? Also if there are any in the arch HAL please pipe up,
preferably with a patch of course :-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] hal_copy_data and hal_zero_bss

[Jonathan Larmour]

Chris Morrow wrote:
> 
> An assembler version of hal_zero_bss is included
> at the end of this message. I placed mine in
> vectors.S. I'm not sure where you would like it.

That's fine. Thanks! It'll be in the next anon CVS update.
 
> Currently the start up code calls hal_copy_data before
> hal_zero_bss. Since at this point the stack is in bss
> when calling hal_zero_bss, I can understand why hal_zero_bss
> needs to avoid memset(). If the order of calls to mem_copy_data
> and hal_zero_bss were switched, what would prevent the use
> of memcpy in hal_copy_data? I can't think of any initialized
> data memcpy would depend on.

We don't support it yet, but in future we may have profiling hooks for
debug builds for example, or very detailed tracing/instrumentation. So for
now I'd rather not introduce such a dependency.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] hal_copy_data and hal_zero_bss

[Chris Morrow]

Jonathan Larmour wrote:
> 
> Chris Morrow wrote:
> >
> > An assembler version of hal_zero_bss is included
> > at the end of this message. I placed mine in
> > vectors.S. I'm not sure where you would like it.
> 
One slight problem. If bss is exactly a multiple
of the block size, the byte loop goes wild. Sorry
about that.

diff -c -r1.23 vectors.S
*** vectors.S	2001/02/27 01:21:47	1.23
--- vectors.S	2001/02/27 09:46:57
***************
*** 803,814 ****
          bne             a3,a0,2b                # to next store
          nop
  
          # finish 1 byte at a time
  1:      sb      zero,0(a0)              # zero memory
          addiu   a0,a0,1                 # next addr
          bne     a0,a1,1b                # to next store
          nop
!         jr      ra
  FUNC_END(hal_zero_bss)
  
          
--- 803,820 ----
          bne             a3,a0,2b                # to next store
          nop
  
+ 	# If length is a multiple of block size then we
+ 	# are done and need to skip the byte loop
+ 	beq		a1,a0,3f
+ 	nop
+ 	
          # finish 1 byte at a time
  1:      sb      zero,0(a0)              # zero memory
          addiu   a0,a0,1                 # next addr
          bne     a0,a1,1b                # to next store
          nop
! 3:	jr      ra
! 	nop
  FUNC_END(hal_zero_bss)


-- 
Chris Morrow	YottaYotta Inc.
email:		cmorrow@yottayotta.com
phone:		(780) 439 9000 ext 227
web:		http://www.yottayotta.com

Re: [ECOS] hal_copy_data and hal_zero_bss

[Jonathan Larmour]

Chris Morrow wrote:
> 
> Jonathan Larmour wrote:
> >
> > Chris Morrow wrote:
> > >
> > > An assembler version of hal_zero_bss is included
> > > at the end of this message. I placed mine in
> > > vectors.S. I'm not sure where you would like it.
> >
> One slight problem. If bss is exactly a multiple
> of the block size, the byte loop goes wild. Sorry
> about that.

Thanks. I've checked that in (and by hand into anon CVS too).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine