2011-07-05 10:50:50     Questions on Blackfin specific GCC options - Bare metal

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2011-07-05 10:50:50     Questions on Blackfin specific GCC options - Bare metal

Prasanth Rajagopal (INDIA)

Message: 102132   

 

I have a couple of questions on the GCC options for the Bare metal toolchain (trying to document the options..):

 

1. mcoreb option - it seems to pull in only Core b memory. But core B alone cannot run independently, so what's the best way to use this option.

2. msdram- seems to use just one block of (*default*   0x00000000   0xffffffff?) - but the length of memory block doesn’t seem to be board specific (SDRAM size?). Related question - from where is *default* pulled in and what is the purpose?

 

3. msim usage - when this feature is used, is it that the memory layout config is done run-time (so virtual default mean - all resides in external memory?) - so user should not touch linker script at all?

 

4. msim usage - it says that " This causes the simulator BSP provided by libgloss to be linked in". I only saw that basicrt.S changes as crt0.S. Is that the only difference with respect to CRT and BSP? Does it actually mean that nothing hardware-specific should be done from inside the basiccrt.S - which is why crt0.S is used?

 

5. Is there a fix for anomaly 05000310 - False Hardware Errors Caused by Fetches at the Boundary of Reserved Memory:) in LDF? There is fix for this anomaly in all VDSP LDFs.

 

Thanks

QuoteReplyEditDelete

 

 

2011-07-05 12:35:19     Re: Questions on Blackfin specific GCC options - Bare metal

Mike Frysinger (UNITED STATES)

Message: 102141   

 

the idea with -mcoreb is that you build an image specifically for loading into the 2nd core.  the toolchain does not assist in any way in actually starting up the core.  so you'd build two images ... the first for core a and boot that normally.  then a 2nd for core b which core a would load and start.

 

-msdram is just to place stuff into external memory.  if you want specific limits as to how much external memory there is, you should write your own linker script.  the default memory range comes from the linker itself ... since the linker script didnt specify any, the default is all of memory.

 

the -msim option defauls to using external memory in the virtual environment.  they could choose to use a custom linker script ... there is no requirement here.  -msim just simplifies the default based on the sim assumptions (you always have external memory).

 

-msim also includes a library (libsim.a) which includes the libgloss syscalls.

 

there is no toolchain support for anomaly 310.  users will need to account for it themselves.  the linker script has no idea what the memory limits are from the user and cannot easily be created based on compiler flags.

Attachments

    Outcomes