public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] dynamic HAL_PLATFORM_* values
@ 2004-04-27  2:30 Andy Dyer
  2004-04-27 16:10 ` Nick Garnett
  0 siblings, 1 reply; 8+ messages in thread
From: Andy Dyer @ 2004-04-27  2:30 UTC (permalink / raw)
  To: ecos-discuss



> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, April 12, 2004 6:20 AM
> To: Andy Dyer
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] dynamic HAL_PLATFORM_* values
> 
> 
> Things like this normally go into plf_io.h. Just add a prototype for
> something like char *cyg_hal_fgpa_version(void), and edit the
> define_proc in the hal cdl to something like
> 
> puts $::cdl_header "#define HAL_PLATFORM_EXTRA  
> cyg_hal_fpga_version()"
> 
> Im note sure is redboot/src/main.c pulls in plf_io.h. If not you will
> also need
> 
> puts $::cdl_header "#include <cyg/hal/plf_io.h>"
> 

I finally got around to messing with this again.  Putting the #include
of plf_io.h into the platform specific .h file seems to break a bunch
of things in building on MIPS.

It causes a bunch of files to be pulled in before the 
#define CYGARC_HAL_COMMON_EXPORT_CPU_MACROS which breaks
hal/mips/arch/current/src/hal_misc.c (and others) and it
causes a bunch of C specific stuff to get pulled into
compiling hal/mips/arch/current/src/context.S (and I assume
other assembly files, too).

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] dynamic HAL_PLATFORM_* values
  2004-04-27  2:30 [ECOS] dynamic HAL_PLATFORM_* values Andy Dyer
@ 2004-04-27 16:10 ` Nick Garnett
  0 siblings, 0 replies; 8+ messages in thread
From: Nick Garnett @ 2004-04-27 16:10 UTC (permalink / raw)
  To: Andy Dyer; +Cc: ecos-discuss

"Andy Dyer" <adyer@righthandtech.com> writes:

> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Monday, April 12, 2004 6:20 AM
> > To: Andy Dyer
> > Cc: ecos-discuss@ecos.sourceware.org
> > Subject: Re: [ECOS] dynamic HAL_PLATFORM_* values
> > 
> > 
> > Things like this normally go into plf_io.h. Just add a prototype for
> > something like char *cyg_hal_fgpa_version(void), and edit the
> > define_proc in the hal cdl to something like
> > 
> > puts $::cdl_header "#define HAL_PLATFORM_EXTRA  
> > cyg_hal_fpga_version()"
> > 
> > Im note sure is redboot/src/main.c pulls in plf_io.h. If not you will
> > also need
> > 
> > puts $::cdl_header "#include <cyg/hal/plf_io.h>"
> > 
> 
> I finally got around to messing with this again.  Putting the #include
> of plf_io.h into the platform specific .h file seems to break a bunch
> of things in building on MIPS.

That is not going to work in general. plf_io.h is designed to be
included only from hal_io.h and may depend on things defined there, or
vice versa.

The simplest thing you could do to make this work is something like
this in the define_proc:

puts $::cdl_header "#ifndef __ASSEMBLER__"
puts $::cdl_header "extern void cyg_hal_fpga_version(void);"
puts $::cdl_header "#define HAL_PLATFORM_EXTRA cyg_hal_fpga_version()"
puts $::cdl_header "#endif"

Since this is just for your platform, this would be OK. It would be a
bit yukky if we were to do this in the architecture or variant HALs.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [ECOS] dynamic HAL_PLATFORM_* values
@ 2004-05-17  4:03 Andy Dyer
  0 siblings, 0 replies; 8+ messages in thread
From: Andy Dyer @ 2004-05-17  4:03 UTC (permalink / raw)
  To: Nick Garnett; +Cc: ecos-discuss


> That is not going to work in general. plf_io.h is designed to be
> included only from hal_io.h and may depend on things defined there, or
> vice versa.
> 
> The simplest thing you could do to make this work is something like
> this in the define_proc:
> 
> puts $::cdl_header "#ifndef __ASSEMBLER__"
> puts $::cdl_header "extern void cyg_hal_fpga_version(void);"
> puts $::cdl_header "#define HAL_PLATFORM_EXTRA cyg_hal_fpga_version()"
> puts $::cdl_header "#endif"
> 

As a refresher I was trying to define a function to return a string
with some version information from the fpga on our board to be
printed at boot time by redboot.  I was trying to figure out the right
way to get a prototype for this included when compiling redboot's main.c

Nick suggested the above solution, but it doesn't work as the function
prototype ends up being included in the target.ld linker file via an
include of <cyg/infra/cyg_type.inc>.  I tried using an #ifdef  
__LANGUAGE_C instead of the #ifndef __ASSEMBLER__, but that didn't work
either.

For now, I'll live with the compilation warning :-)

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] dynamic HAL_PLATFORM_* values
  2004-04-12 11:18 Andy Dyer
  2004-04-12 15:44 ` sandeep kumar
@ 2004-04-12 16:26 ` Andrew Lunn
  1 sibling, 0 replies; 8+ messages in thread
From: Andrew Lunn @ 2004-04-12 16:26 UTC (permalink / raw)
  To: Andy Dyer; +Cc: ecos-discuss

On Sun, Apr 11, 2004 at 10:44:02PM -0500, Andy Dyer wrote:
> We have boards with varying versions of FPGA code in them for
> various reasons (debug builds, not updated, programming mistake,
> etc).
> 
> In the FPGA are registers I can read to get the version
> numbers.  During hal_platform_init() (or maybe earlier) 
> I want to read those registers, format the data into a
> fixed length string in .data and somewhere #define 
> HAL_PLATFORM_EXTRAS to be a pointer to that string, so
> that redboot will print my string out on boot and the string
> will reflect the values in the FPGA registers at runtime.
> Everything I saw from grepping my tree statically defines
> HAL_PLATFORM_* in a cdl file.
> 
> where I was running into trouble was in figuring out what the 
> "right" way to do this is.  The #define doesn't seem to "belong"
> in any of my exisiting platform hal include files (hal_diag, plf_cache,
> plf_intr, plf_io, and plf_stub), so I wanted to make a new header
> file, figure out how to get it into the install/include heirarchy,
> and get it #included into the build headers so when redboot links it
> can find my pointer.

Things like this normally go into plf_io.h. Just add a prototype for
something like char *cyg_hal_fgpa_version(void), and edit the
define_proc in the hal cdl to something like

puts $::cdl_header "#define HAL_PLATFORM_EXTRA  cyg_hal_fpga_version()"

Im note sure is redboot/src/main.c pulls in plf_io.h. If not you will
also need

puts $::cdl_header "#include <cyg/hal/plf_io.h>"

     Andrew

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] dynamic HAL_PLATFORM_* values
  2004-04-12 11:18 Andy Dyer
@ 2004-04-12 15:44 ` sandeep kumar
  2004-04-12 16:26 ` Andrew Lunn
  1 sibling, 0 replies; 8+ messages in thread
From: sandeep kumar @ 2004-04-12 15:44 UTC (permalink / raw)
  To: Andy Dyer, ecos-discuss

Hi,
> In the FPGA are registers I can read to get the version
> numbers.  During hal_platform_init() (or maybe earlier) 
> I want to read those registers, format the data into a
> fixed length string in .data and somewhere #define 
> HAL_PLATFORM_EXTRAS to be a pointer to that string, so
> that redboot will print my string out on boot and the string
> will reflect the values in the FPGA registers at runtime.
> Everything I saw from grepping my tree statically defines
> HAL_PLATFORM_* in a cdl file.
Why not just define an appropriate size array, that you populate
with desired information, and later print it.
regards
sandeep



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [ECOS] dynamic HAL_PLATFORM_* values
@ 2004-04-12 11:18 Andy Dyer
  2004-04-12 15:44 ` sandeep kumar
  2004-04-12 16:26 ` Andrew Lunn
  0 siblings, 2 replies; 8+ messages in thread
From: Andy Dyer @ 2004-04-12 11:18 UTC (permalink / raw)
  To: ecos-discuss

We have boards with varying versions of FPGA code in them for
various reasons (debug builds, not updated, programming mistake,
etc).

In the FPGA are registers I can read to get the version
numbers.  During hal_platform_init() (or maybe earlier) 
I want to read those registers, format the data into a
fixed length string in .data and somewhere #define 
HAL_PLATFORM_EXTRAS to be a pointer to that string, so
that redboot will print my string out on boot and the string
will reflect the values in the FPGA registers at runtime.
Everything I saw from grepping my tree statically defines
HAL_PLATFORM_* in a cdl file.

where I was running into trouble was in figuring out what the 
"right" way to do this is.  The #define doesn't seem to "belong"
in any of my exisiting platform hal include files (hal_diag, plf_cache,
plf_intr, plf_io, and plf_stub), so I wanted to make a new header
file, figure out how to get it into the install/include heirarchy,
and get it #included into the build headers so when redboot links it
can find my pointer.


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] dynamic HAL_PLATFORM_* values
  2004-04-12  5:45 Andy Dyer
@ 2004-04-12  8:00 ` Andrew Lunn
  0 siblings, 0 replies; 8+ messages in thread
From: Andrew Lunn @ 2004-04-12  8:00 UTC (permalink / raw)
  To: Andy Dyer; +Cc: ecos-discuss

On Sun, Apr 11, 2004 at 01:31:03PM -0500, Andy Dyer wrote:
> Is there an example somewhere of how to dynamically define a value for
> HAL_PLATFORM_EXTRAS and make sure the definitions get put in the right
> header files so redboot can link?  I'm trying to print out some fpga
> and chipset revision stuff at startup. 

Im don't understand what you are trying to do. You say dynamically
define but you want to put it into a static header file?

hal_arm_arm9_aaed2000.cdl might give you some ideas.

       Andrew

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ECOS] dynamic HAL_PLATFORM_* values
@ 2004-04-12  5:45 Andy Dyer
  2004-04-12  8:00 ` Andrew Lunn
  0 siblings, 1 reply; 8+ messages in thread
From: Andy Dyer @ 2004-04-12  5:45 UTC (permalink / raw)
  To: ecos-discuss

Is there an example somewhere of how to dynamically define a value for
HAL_PLATFORM_EXTRAS and make sure the definitions get put in the right
header files so redboot can link?  I'm trying to print out some fpga
and chipset revision stuff at startup. 

--
Andrew Dyer               |  adyer@righthandtech.com
Sr. Engineer              |  (630) 238-0789
RightHand Technologies    |  (630) 238-0469 (fax)
735 N. Edgewood Ave.      |
Suite D                   |
Wood Dale, IL 60191-1261  |
USA                       |

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-05-16 17:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-27  2:30 [ECOS] dynamic HAL_PLATFORM_* values Andy Dyer
2004-04-27 16:10 ` Nick Garnett
  -- strict thread matches above, loose matches on Subject: below --
2004-05-17  4:03 Andy Dyer
2004-04-12 11:18 Andy Dyer
2004-04-12 15:44 ` sandeep kumar
2004-04-12 16:26 ` Andrew Lunn
2004-04-12  5:45 Andy Dyer
2004-04-12  8:00 ` Andrew Lunn

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).