* [ECOS] Header files in platform port @ 2001-01-15 12:26 Paul Pham 2001-01-15 13:22 ` [ECOS] hal_copy_data and hal_zero_bss Chris Morrow 2001-01-15 18:44 ` [ECOS] Header files in platform port Jonathan Larmour 0 siblings, 2 replies; 10+ messages in thread From: Paul Pham @ 2001-01-15 12:26 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ECOS] hal_copy_data and hal_zero_bss 2001-01-15 12:26 [ECOS] Header files in platform port Paul Pham @ 2001-01-15 13:22 ` Chris Morrow 2001-01-15 18:30 ` Jonathan Larmour 2001-01-15 18:44 ` [ECOS] Header files in platform port Jonathan Larmour 1 sibling, 1 reply; 10+ messages in thread From: Chris Morrow @ 2001-01-15 13:22 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] hal_copy_data and hal_zero_bss 2001-01-15 13:22 ` [ECOS] hal_copy_data and hal_zero_bss Chris Morrow @ 2001-01-15 18:30 ` Jonathan Larmour 2001-02-25 18:05 ` Chris Morrow 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Larmour @ 2001-01-15 18:30 UTC (permalink / raw) To: Chris Morrow; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] hal_copy_data and hal_zero_bss 2001-01-15 18:30 ` Jonathan Larmour @ 2001-02-25 18:05 ` Chris Morrow 2001-02-25 18:15 ` [ECOS] mips mmu setup Chris Morrow 2001-02-26 15:22 ` [ECOS] hal_copy_data and hal_zero_bss Jonathan Larmour 0 siblings, 2 replies; 10+ messages in thread From: Chris Morrow @ 2001-02-25 18:05 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ECOS] mips mmu setup 2001-02-25 18:05 ` Chris Morrow @ 2001-02-25 18:15 ` Chris Morrow 2001-02-26 12:39 ` Jonathan Larmour 2001-02-26 15:22 ` [ECOS] hal_copy_data and hal_zero_bss Jonathan Larmour 1 sibling, 1 reply; 10+ messages in thread From: Chris Morrow @ 2001-02-25 18:15 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] mips mmu setup 2001-02-25 18:15 ` [ECOS] mips mmu setup Chris Morrow @ 2001-02-26 12:39 ` Jonathan Larmour 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2001-02-26 12:39 UTC (permalink / raw) To: Chris Morrow; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] hal_copy_data and hal_zero_bss 2001-02-25 18:05 ` Chris Morrow 2001-02-25 18:15 ` [ECOS] mips mmu setup Chris Morrow @ 2001-02-26 15:22 ` Jonathan Larmour 2001-02-27 1:54 ` Chris Morrow 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Larmour @ 2001-02-26 15:22 UTC (permalink / raw) To: Chris Morrow; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] hal_copy_data and hal_zero_bss 2001-02-26 15:22 ` [ECOS] hal_copy_data and hal_zero_bss Jonathan Larmour @ 2001-02-27 1:54 ` Chris Morrow 2001-02-27 10:25 ` Jonathan Larmour 0 siblings, 1 reply; 10+ messages in thread From: Chris Morrow @ 2001-02-27 1:54 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] hal_copy_data and hal_zero_bss 2001-02-27 1:54 ` Chris Morrow @ 2001-02-27 10:25 ` Jonathan Larmour 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2001-02-27 10:25 UTC (permalink / raw) To: Chris Morrow; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] Header files in platform port 2001-01-15 12:26 [ECOS] Header files in platform port Paul Pham 2001-01-15 13:22 ` [ECOS] hal_copy_data and hal_zero_bss Chris Morrow @ 2001-01-15 18:44 ` Jonathan Larmour 1 sibling, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2001-01-15 18:44 UTC (permalink / raw) To: Paul Pham; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-02-27 10:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-15 12:26 [ECOS] Header files in platform port Paul Pham 2001-01-15 13:22 ` [ECOS] hal_copy_data and hal_zero_bss Chris Morrow 2001-01-15 18:30 ` Jonathan Larmour 2001-02-25 18:05 ` Chris Morrow 2001-02-25 18:15 ` [ECOS] mips mmu setup Chris Morrow 2001-02-26 12:39 ` Jonathan Larmour 2001-02-26 15:22 ` [ECOS] hal_copy_data and hal_zero_bss Jonathan Larmour 2001-02-27 1:54 ` Chris Morrow 2001-02-27 10:25 ` Jonathan Larmour 2001-01-15 18:44 ` [ECOS] Header files in platform port Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).