Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 14/08/2014 11:21 am, Peng Fan wrote:
Hi,
I have a two days travel, so this reply is late.
2014-08-12 10:56 GMT+08:00 Chris Johns mailto:chr...@rtems.org>>:
On 11/08/2014 12:24 am, Peng Fan wrote:
1. Fix getopt_long usage in rtl host. some shorthand options are not
hanlded correctly, this patch fixes it.
Thanks for cleaning this up.
2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg
of this
option will be passed to xx-rtemsxx-gcc, it will be used the
search lib
dirs. Detailed msg is in the commit log of the patch.
I wonder if we need the explicit -march and -mcpu options and this
or should we remove them and add a more general option that can
include these flags. When I added the -march etc I thought this was
all that was needed and that is proving to be a little naive.
If -march and -mcpu are only passed to gcc to let gcc search the libs, I
think we can add a more generic option.
What do you think ?
I think we can extract the 'machine' related flags from rtems bsp and
build a table in rtl-host like the following:
struct bsp_flag {
char* bsp_name;
char* flags;
} ;
Here machine related flags in gcc is at
https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/ chapter 3.17.
struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];
alloc space
bsp_flags[0].bsp_name = bsp name from rtems source code
bsp_flags[0].flags = machine flags from rtems source code corresponding
to the bsp
bsp_flags[1]
bsp_flags[2]
..
I think the user should manage this in their build environment. The
rtems-tld (trace linker) will need the BSP set up to work so this is a
different case.
Using the machine flags, xxx_rtemsxx_gcc can search the related libs
first, if not found, then search the common libs, because the machine
related lib path is in the first.
Yes it can.
Just my thought, the code above is not good. Hmm. using String, new and
class in c++
I understand.
I think we may pass a madantory bsp name to rtl-host, such as "--bsp
xxx" , xxx means the bsp name
Or we pass --cc-flags and let the user manage the interface to the BSP.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 08/15/2014 04:15 PM, Chris Johns wrote:
On 14/08/2014 11:21 am, Peng Fan wrote:
Hi,
I have a two days travel, so this reply is late.
2014-08-12 10:56 GMT+08:00 Chris Johns mailto:chr...@rtems.org>>:
On 11/08/2014 12:24 am, Peng Fan wrote:
1. Fix getopt_long usage in rtl host. some shorthand options
are not
hanlded correctly, this patch fixes it.
Thanks for cleaning this up.
2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg
of this
option will be passed to xx-rtemsxx-gcc, it will be used the
search lib
dirs. Detailed msg is in the commit log of the patch.
I wonder if we need the explicit -march and -mcpu options and this
or should we remove them and add a more general option that can
include these flags. When I added the -march etc I thought this was
all that was needed and that is proving to be a little naive.
If -march and -mcpu are only passed to gcc to let gcc search the libs, I
think we can add a more generic option.
What do you think ?
I think we can extract the 'machine' related flags from rtems bsp and
build a table in rtl-host like the following:
struct bsp_flag {
char* bsp_name;
char* flags;
} ;
Here machine related flags in gcc is at
https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/ chapter 3.17.
struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];
alloc space
bsp_flags[0].bsp_name = bsp name from rtems source code
bsp_flags[0].flags = machine flags from rtems source code corresponding
to the bsp
bsp_flags[1]
bsp_flags[2]
..
I think the user should manage this in their build environment. The
rtems-tld (trace linker) will need the BSP set up to work so this is a
different case.
I have not read related source code. what is it for?
Using the machine flags, xxx_rtemsxx_gcc can search the related libs
first, if not found, then search the common libs, because the machine
related lib path is in the first.
Yes it can.
Just my thought, the code above is not good. Hmm. using String, new and
class in c++
I understand.
I think we may pass a madantory bsp name to rtl-host, such as "--bsp
xxx" , xxx means the bsp name
Or we pass --cc-flags and let the user manage the interface to the BSP.
If not pass correct machine flags to gcc, rtems-ld may link wrong
libgcc.a and other libxxx.a, and rtems-ld can not give any error msg
about this. At last, when loading rap file, error occurs, but hard to
find what happens.
I am not sure, but I think let user to handle the machine flags is not
user friendly, unless users are clearly about what machine flags should
be passed to xx-rtemsxx-gcc by rtems-ld.
If using --cc-flags, this option may be manatory, but not optional. And
the user should extract the machine flags from rtems source code.
I think passing bsp name to rtems-ld, and rtems-ld search a table which
contains bsps' name and the machine flags corresponding to the bsp. If
the bsp name passed to rtems-ld can not be found in the table, rtems-ld
complains err msg, If found, then all is fine.
Regards,
Peng.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)
Included variants: tms570ls3137_hdk_intram - place code and data into internal SRAM tms570ls3137_hdk_sdram - place code into external SDRAM and data to SRAM tms570ls3137_hdk - variant prepared for stand-alone RTEMS aplication stored and running directly from flash. Not working yet. Chip initialization code not included in BSP. External startup generated by TI's HalCoGen was usedfor testing and debugging. More information about TMS570 BSP can be found at http://www.rtems.org/wiki/index.php/Tms570 Patch version 2 - most of the formatting suggestion applied. - BSP converted to use clock shell - console driver "set attributes" tested. Baudrate change working Todo: refractor header files (name register fields) --- c/src/lib/libbsp/arm/tms570/Makefile.am| 144 + c/src/lib/libbsp/arm/tms570/README | 67 +++ c/src/lib/libbsp/arm/tms570/bsp_specs | 13 + c/src/lib/libbsp/arm/tms570/clock/clock.c | 157 ++ c/src/lib/libbsp/arm/tms570/configure.ac | 52 ++ .../lib/libbsp/arm/tms570/console/printk-support.c | 85 +++ c/src/lib/libbsp/arm/tms570/console/tms570-sci.c | 560 c/src/lib/libbsp/arm/tms570/include/bsp.h | 102 c/src/lib/libbsp/arm/tms570/include/irq.h | 134 + c/src/lib/libbsp/arm/tms570/include/tms570-pom.h | 101 c/src/lib/libbsp/arm/tms570/include/tms570-rti.h | 95 .../libbsp/arm/tms570/include/tms570-sci-driver.h | 40 ++ c/src/lib/libbsp/arm/tms570/include/tms570-sci.h | 76 +++ c/src/lib/libbsp/arm/tms570/include/tms570-vim.h | 75 +++ c/src/lib/libbsp/arm/tms570/include/tms570.h | 28 + c/src/lib/libbsp/arm/tms570/irq/irq.c | 192 +++ .../make/custom/tms570ls3137_hdk-testsuite.tcfg| 19 + .../arm/tms570/make/custom/tms570ls3137_hdk.cfg| 20 + .../tms570/make/custom/tms570ls3137_hdk_intram.cfg | 21 + .../tms570/make/custom/tms570ls3137_hdk_sdram.cfg | 20 + c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c | 100 c/src/lib/libbsp/arm/tms570/preinstall.am | 123 + c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37 ++ c/src/lib/libbsp/arm/tms570/startup/bspstart.c | 42 ++ .../lib/libbsp/arm/tms570/startup/bspstarthooks.c | 41 ++ .../arm/tms570/startup/linkcmds.tms570ls3137_hdk | 27 + .../startup/linkcmds.tms570ls3137_hdk_intram | 28 + .../tms570/startup/linkcmds.tms570ls3137_hdk_sdram | 27 + 28 files changed, 2426 insertions(+) create mode 100644 c/src/lib/libbsp/arm/tms570/Makefile.am create mode 100644 c/src/lib/libbsp/arm/tms570/README create mode 100644 c/src/lib/libbsp/arm/tms570/bsp_specs create mode 100644 c/src/lib/libbsp/arm/tms570/clock/clock.c create mode 100644 c/src/lib/libbsp/arm/tms570/configure.ac create mode 100644 c/src/lib/libbsp/arm/tms570/console/printk-support.c create mode 100644 c/src/lib/libbsp/arm/tms570/console/tms570-sci.c create mode 100644 c/src/lib/libbsp/arm/tms570/include/bsp.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/irq.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-pom.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-rti.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci-driver.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-vim.h create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570.h create mode 100644 c/src/lib/libbsp/arm/tms570/irq/irq.c create mode 100644 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg create mode 100644 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg create mode 100644 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg create mode 100644 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_sdram.cfg create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.c create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.h create mode 100644 c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c create mode 100644 c/src/lib/libbsp/arm/tms570/preinstall.am create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspreset.c create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstart.c create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstarthooks.c create mode 100644 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk create mode 100644 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_intram create mode 100644 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_sdram diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am b/c/src/lib/libbsp/arm/tms570/Makefile.am new file mode 100644 index 000..ce34c6c --- /dev/null +++ b/c/src/lib/libbsp/arm/tms570/Makefile.am @@ -0,0 +1,144 @@ +## +# +# @file makefile.am +# +# @brief Makefile of LibBSP for the TMS5
Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 15/08/2014 7:37 pm, Peng Fan wrote:
On 08/15/2014 04:15 PM, Chris Johns wrote:
On 14/08/2014 11:21 am, Peng Fan wrote:
Hi,
I have a two days travel, so this reply is late.
2014-08-12 10:56 GMT+08:00 Chris Johns mailto:chr...@rtems.org>>:
On 11/08/2014 12:24 am, Peng Fan wrote:
1. Fix getopt_long usage in rtl host. some shorthand options
are not
hanlded correctly, this patch fixes it.
Thanks for cleaning this up.
2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg
of this
option will be passed to xx-rtemsxx-gcc, it will be used the
search lib
dirs. Detailed msg is in the commit log of the patch.
I wonder if we need the explicit -march and -mcpu options and this
or should we remove them and add a more general option that can
include these flags. When I added the -march etc I thought this was
all that was needed and that is proving to be a little naive.
If -march and -mcpu are only passed to gcc to let gcc search the libs, I
think we can add a more generic option.
What do you think ?
I think we can extract the 'machine' related flags from rtems bsp and
build a table in rtl-host like the following:
struct bsp_flag {
char* bsp_name;
char* flags;
} ;
Here machine related flags in gcc is at
https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/ chapter 3.17.
struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];
alloc space
bsp_flags[0].bsp_name = bsp name from rtems source code
bsp_flags[0].flags = machine flags from rtems source code corresponding
to the bsp
bsp_flags[1]
bsp_flags[2]
..
I think the user should manage this in their build environment. The
rtems-tld (trace linker) will need the BSP set up to work so this is a
different case.
I have not read related source code. what is it for?
The rtems-tld is a trace linker. It is still being worked on and not
usable. Trace linking lets a user define a set of functions they want to
trace and rtems-tld will generate the wrapping functions, compile them
and perform a link using the GNU ld's '--wrap=symbol' option. This will
combine with the capture engine to allow real-time tracing on targets.
The first pass of the rtems-tld will provide a proof of concept way to
output to stdout entry to a function with the arguments and the return
value shown as hex dumps. The capture engine integration is happening
slowly with Jennifer and is the end objective.
If things work out with rtems-tld the wrapping generators will be
specified in INI files which lets users provide custom ways to trace
execution. The INI files in the repo show the idea being worked on.
Using the machine flags, xxx_rtemsxx_gcc can search the related libs
first, if not found, then search the common libs, because the machine
related lib path is in the first.
Yes it can.
Just my thought, the code above is not good. Hmm. using String, new and
class in c++
I understand.
I think we may pass a madantory bsp name to rtl-host, such as "--bsp
xxx" , xxx means the bsp name
Or we pass --cc-flags and let the user manage the interface to the BSP.
If not pass correct machine flags to gcc, rtems-ld may link wrong
libgcc.a and other libxxx.a, and rtems-ld can not give any error msg
about this. At last, when loading rap file, error occurs, but hard to
find what happens.
I am not sure, but I think let user to handle the machine flags is not
user friendly, unless users are clearly about what machine flags should
be passed to xx-rtemsxx-gcc by rtems-ld.
If using --cc-flags, this option may be manatory, but not optional. And
the user should extract the machine flags from rtems source code.
I think passing bsp name to rtems-ld, and rtems-ld search a table which
contains bsps' name and the machine flags corresponding to the bsp. If
the bsp name passed to rtems-ld can not be found in the table, rtems-ld
complains err msg, If found, then all is fine.
This sounds reasonable. Maybe we provide both and users can decide. The
bsp option may be suitable and may need some extra options or they can
provide the full list and not specify a bsp.
Which ever way we go the rtems-ld and rtems-tld should be the similar.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
