Analog.com Analog Dialogue Wiki English
Analog.com Analog Dialogue Wiki 简体中文
EngineerZone
EngineerZone
  • Site
  • User
  • Site
  • Search
  • User
EngineerZone
EngineerZone
  • Log in
  • Site
  • Search
  • Log in
  • Home
  • Blogs ⌵
    • EngineerZone Spotlight
    • The Engineering Mind
  • Browse ⌵
    • All Groups
    • All Members
  • Support ⌵
    • 3D ToF Depth Sensing
    • Amplifiers
    • Analog Microcontrollers
    • Analysis Control Evaluation (ACE) Software
    • Audio
    • Clock and Timing
    • Data Converters
    • Design Tools and Calculators
    • Direct Digital Synthesis (DDS)
    • Embedded Vision Sensing
    • Energy Monitoring and Metering
    • FPGA Reference Designs
    • Industrial Ethernet
    • Interface and Isolation
    • Low Power RF Transceivers
    • MEMS Inertial Sensors
    • Motor Control Hardware Platforms
    • Optical Sensing
    • Power By Linear
    • Processors and DSP
    • Reference Circuits
    • RF and Microwave
    • Signal Chain Power (SCP)
    • Switches/Multiplexers
    • Temperature Sensors
    • Video
    • Wide Band RF Transceivers
    • Wireless Sensor Networks Reference Library
  • My EZ
  • More
  • Cancel
  • 主页
  • 浏览 ⌵
    • 收件箱
    • 个人设置
    • 会员
    • 专区列表
  • 论坛专区 ⌵
    • 放大器专区
    • 精密转换器专区
    • 音频专区
    • ADE电能计量专区
    • MEMS和传感器专区
    • 接口和隔离专区
    • Power 中文专区
    • ADUC微处理器专区
    • 锁相环专区
    • 开关和多路复用器专区
    • 温度传感器
    • 基准电压源专区
    • 资源库
    • 论坛使用指南
    • 技术支持参考库
    • 在线研讨会
    • 论坛社群活动
    • 论坛激励活动
  • More
  • Cancel
Linux Distribution for Blackfin
  • Processors and DSP
  • Software and Development Tools
  • Linux Distribution for Blackfin
  • More
  • Cancel
Linux Distribution for Blackfin
Documents FAQ: How do I re-use projects built in VDSP in a GCC Bare metal environment?
  • Q&A
  • Discussions
  • Documents
  • File Uploads
  • Video/Images
  • Sub-Groups
  • Members
  • Tags
  • Reports
  • Managers
  • More
  • Cancel
  • New
Linux Distribution for Blackfin requires membership for participation - click to join
  • Documents
  • 2005-06-18 08:54:21     how load and compile the uClinux kernel
  • 2007-04-03 05:21:47     SPI eeprom write read
  • 2007-06-05 06:05:45     How to load Linux from JFFS2/NAND flash
  • 2011-10-18 00:59:25     Attention: help forums are moving to the Analog Devices' EngineerZone Since Oct.24
  • 2013R1 Linux release for Blackfin
  • AD5700/AD5700-1 RXD Activity After HART Carrier Off
  • DAS U-BOOT FOR BLACKFIN BUGS ARCHIVE
  • Development of the Blackfin Linux Projects is moved to sourceforge.net since Jul. 20, 2013.
  • FAQ: Demo the video capability on BF609
  • FAQ: Does ADI u-boot support BF70x processors?
  • FAQ: GDB commands for newbie.
  • FAQ: Getting Started with SDP-B using GCC Toolchain
  • FAQ: How do I re-use projects built in VDSP in a GCC Bare metal environment?
  • FAQ: How to make u-boot to do somthing automatically after booting
  • FAQ: Moving to a newer Blacinfin Linux release version
  • FAQ: Why I get compile errors with the default ADI release
  • GNU TOOLCHAIN FOR BLACKFIN BUGS ARCHIVE
  • GNU TOOLCHAIN FOR BLACKFIN SUPPORT COMMUNITY
  • How can I flash the uImage into Flash and boot from it?
  • How to autorun applications in uClinux
  • I want to use the second core of Blackfin in Linux to boost the performance, is there a quick guide?
  • LINUX DISTRIBUTION FOR BLACKFIN SUPPORT COMMUNITY
  • +Parent Document for U-Boot Bug Archive
  • +Parent Document for U-Boot Bug Forum Archive
  • +Parent for all content moved from GNU Archive
  • Re: bf537 SPI Bus: To use Kernel, Userspace, or Bitbang control
  • TAGS LIST: Interface and Isolation
  • The 2013R1 Linux release for Blackfin
  • The development of the Blackfin Linux Projects is moved to sourceforge.net since Jul. 20, 2013.
  • Use gdbproxy to debug kernel
  • Use the ADI test scripts to auto config and build a target for a set of function
  • what does a successful "loading u-boot over uart" look like?
  • Where can I get Linux Blackfin documents?
  • [#3812] svn head u-boot build fails initcode.c on older parts
  • [#5809] gcc/g++ test on trunk head regression compared with testing on 09r1.1
  • [#5825] gdb: symbols cannot map to correct source file
  • [#5826] gdb.cp/userdef.exp fails to load executable's loadmap in fdpic testing
  • [#5827] gcc.dg/trampoline-1.c test on hardware fdpic fails on bf527 but pass on bf548
  • [#5828] libstdc++-4.3 21_strings/basic_string/capacity/char/18654.cc test on fdpic would fail
  • [#5842] gdb.base/sigall.exp would fail when debug through serial port 1
  • [#5845] gdb.gdbtk/c_variable.exp fails to be tested through /dev/ttyBF1
  • [#5858] gcc.c-torture/execute/memset-2.c regression now
  • [#5880] ldr-utils build fails
  • [#5886] bfin-elf-libstdc++-4.3 has two regression case compared with libstdc++-4.1
  • [#5887] bfin-uclinux-libstdc++-4.3 ext/headers.cc regress
  • [#5888] bfin-uclinux-libmudflap-4.3.sum pass40-frag.c output pattern test regress
  • [#5889] toolchain-regtest -r (test compare) option has multiple issues
  • [#5890] toolchain-regtest does not handle unknown args very well
  • [#5891] trunk head gdbproxy can't find and open urjtag device
  • [#5892] bfin-uclinux-libstdc++-4.3 23_containers/set/modifiers/16728.cc fail sometimes
  • [#5895] prepare_target_solibs in toolchain-regtest fail to check the libs
  • [#5922] gcc/g++ testcase regression in simulator test for Unhandled instruction
  • [#5928] gas has problems with local labels in LOOP instructions
  • [#5935] toolchain-regtest can't find the toolchain to be tested now
  • [#5938] toolchain-regtest aborts when previous results are missing
  • [#5953] test libmudflap fails for mfconfig.exp.in missing
  • [#5962] mcpu doesn't get passed in testing linux-uclibc toolchain
  • [#5965] elf-simulator test cases regress for program stopped with signal 11
  • [#5966] build sim binutils fails now
  • [#5970] Build oprofile failed at bfd library after toolchain upgrade from 3801 to 3852
  • [#5974] CPLB fault or SIGABRT when throwing&catching C++ exception in static FDPIC ELF
  • [#5980] trunk toolchain cannot find -lbffastfp with -mfast-fp
  • [#5981] gas tests have regressions due to SHIFT->LSHIFT change
  • [#5989] build toolchain fails at binutils-2.17/sim/bfin
  • [#6018] gcc-4.3 ICEs with {interrupt,exception,nmi}_handler function attributes in copyprop_hardreg_forward_1, at regrename.c:1787
  • [#6030] test bfin-elf via simulator, it stops in gdb.gdbtk/c_variable.exp with case "stop in subroutine1"
  • [#7702] GDB fails to find prologue
  • [#7806] gdb test regression after using buildroot as target os
  • [DOC] Configuring Qt Creator as SDK for uClinux

FAQ: How do I re-use projects built in VDSP in a GCC Bare metal environment?

Q.

How do I re-use projects built in VDSP in a GCC Bare metal environment?

--------------------------------------------------------------------------------------

A.

The ELF output format that Visual DSP++ toolchain produces is not compatible with the GNU toolchain output format. Therefore one cannot reuse executables or libraries built using one toolchain, with the other, unless the software is re built from scratch.

There are more examples and libraries built using the VDSP toolchain, compared to the GCC bare metal toolchain. This includes several peripheral device drivers and the various system services. Often one has to re-build these libraries or write from scratch, in order to use with GCC.

Quick answer:

Generate opcodes of the application, and use it directly from SDRAM.

Detailed answer:

Loader files or LDR files are specific formats supported by the on-chip BOOTROM in Blackfin, for booting standalone applications, often from a non-volatile boot source such as the parallel flash. The advantage of this format is that both VDSP & GCC toolchain produces the end LDR file in exactly the same format required by BOOTROM. If a user has an LDR file built via VDSP, it can be feasibly used in a GCC environment, by making use of direct code execution method & the BOOTROM callable APIs.

Boot source can either be a parallel flash or SDRAM. In case of parallel flash, user must create an LDR file using the splitter tool and burn it before actually using it in application. However, code execution from flash is considerably slower.  When the boot source is an SDRAM, execution can become much faster. If the boot stream is residing in SDRAM, there is no real LDR programming required, other than including the file in the application. For creating the LDR image for direct execution, one must use the Splitter tool in Visual DSP++. This tool though it generates an LDR file, the file comprises of the opcodes of the particular program.

Now, since we can generate the opcodes, we actually don’t need the BOOTROM or SDRAM boot either. We could just perform a jump to the specific location.

BF527 is used as an example for the below for illustration. User needs to decide on the memory management carefully between the calling application, bootrom (in case used) and the called application. Additionally, the registers must be properly stored and re-loaded by the calling application. The explanations here are only intended for illustrating the concept and need not be the best method in all cases; users are expected to read the Visual DSP++ Loader Manual, as well as the System Reset and Booting chapter in Hardware Reference Manual for in depth information. Throught the discussion we are assuming that the calling application is the one built with GCC toolchain, and the called application is the one pre-built using VDSP.

Preparing the application:

1. If running from SDRAM directly without involving BOOTROM:

Ensure that all code is mapped to SDRAM, Memory segment should be ROM type.

MEM_SDRAM0 {  TYPE(ROM) WIDTH(8) START(0x00000010) END(0x0010FFFF) }

2. If running from SDRAM via BOOTOM, Include a first boot block like this:

.section bootblock;

.global _firstblock;

.byte_firstblock[16]=  0x06,0xD0,0x5B,0xAD,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;

Changes in ldf:

RESOLVE(_firstblock,0x00000010)

RESOLVE(_main,0x00000020)

Ensure that all code is mapped to SDRAM& Memory segment should be in ROM type.

MEM_SDRAM0 { TYPE(ROM) WIDTH(8) START(0x00000010) END(0x0010FFFF) }

.

3. If running from Flash, Include a first boot block like this:

.section bootblock;

.global _firstblock;

.var _firstblock[4] = 0xAD7BD006,0x20000020, 0x00000010, 0x00000010;

Changes in ldf:

RESOLVE(_firstblock,0x20000000)

RESOLVE(_main,0x20000020)

Ensure that all code is mapped to Flash-ROM type (Async space). Burn this LDR using Flash programming tools.

Called Application - exit:

Since we are actually intending a return from the called application, it could just hardcode an address and return like this:

                asm("P0.L = LO(0xFFA04000);");           

                asm("P0.H = HI(0xFFA04000);");                           

                asm("JUMP (P0);");

Note that it is the responsibility of the called application to terminate Interrupts, DMA or anything with consequence to the calling application.

Loader properties:

The Loader exe (elf-loader) can have the following options to generate the splitter output:

‘elfloader.exe" .\Debug\LED_BLink_BF527_EZ-KIT.dxe -romsplitter -f ASCII -Width 16 -maskaddr 29 -si-revision 0.2 -proc ADSP-BF527

Use Project Options – Splitter to define the correct properties. When using Flash boot, the output can be in intel hex and when using the SDRAM, the output can be in ASCII format.

When using ASCII format, the generated file contains a sequence such as this:

00000010

000000DE

00010101

00000000

06

D0

5B

AD

  ...

We only need to take the byte data stream, as the initial data is meant for post processing tools. So one can delete the following:

00000010 /* 32-bit logical address field */

000000DE /* 32-bit logical length field */

00010101 /* 32-bit control word: 2x address multiply 02 bytes logical width, 01 byte physical width */

00000000 /* reserved */

Use -meminit with basiccrt.s file for initializing data memory sections specified in the LDF.

Using the pre-built LDRs with GCC:

Use additional linker settings to map using a new use Loader Script: -T ldscript.ld -Wl,-Map=Linker.map

When the opcode are used directly, define the locations such that the application starts exactly at the location intended when preparing the LDR:

MEM_SDRAM         : ORIGIN = 0x00000010, LENGTH = 1* 1024 * 1024

Since the loaded application is returning to a hardcoded instruction address, make sure that this location has the instructions for returning back to the calling application.

  MEM_L1_CODE_CACHE : ORIGIN = 0xFFA04000, LENGTH = 0xC000

  .textspecial           :

  {

    *(.textspecial .textspecial.*)

  } >MEM_L1_CODE_CACHE

When the LDR is already burnt to Flash, a direct jump to bootrom callable location 0xef000008 will do. When the LDR or application opcodes are residing in SDRAM, one would need to do:

__attribute__((__section__(".sdram.data")))

unsigned char ldr_dat [] =

{

                #include "led_blink.ldr"

};

SDRAM Controller must be programmed before using the SDRAM. Pre-boot inside bootrom can do this when using SDRAM-boot or user can also program like below:

                *pEBIU_SDRRC  = 0x0407;

                *pEBIU_SDBCTL = 0x25;

                *pEBIU_SDGCTL = 0x0091998D;

Below are some implementations for calling the application and returning from called application gracefully:

ret_from_boot() – function for returning from boot-rom to the . It should be hardcoded at 0xFFA04000.

perform_boot_bfrom() - function for jumping in to boot-rom for SDRAM boot.

perform_boot_direct() - function for jumping in to SDRAM location to execute code directly.

Sample house-keeping routines in GCC

unsigned int  sp_val;

__attribute__((__section__(".textspecial")))

void ret_from_boot()

{

asm(" P0.L = _sp_val;  \

            P0.H = _sp_val;  \

            R0 = [P0];      \

            SP = R0;        \

            FP = [SP++];    \

            RETS = [SP++];  \

            (R7:0, P5:0) = [ SP ++ ] \

            RETS = R0;");

}

__attribute__((__section__(".textspecial")))

void perform_boot_bfrom()

{

asm("       UNLINK;\

            LINK 64;\

            [ -- SP] = (R7:0, P5:0) \

            [ -- SP] = RETS; \

            [ -- SP] = FP;    \

            P0.L = (_sp_val);\

            P0.H = (_sp_val);\

            R0 = SP;\

            [P0] = R0;\

            R0.L = (0x6000);\

            R0.H = (0xFF90);\

            SP = R0;\

            FP = R0;\

            R0.H = 0x0000;\

            R0.L = 0x0010;\

            R1 = 0;\

            R2 = 0;\

            P0.H = 0xEF00;\

            P0.L = 0x0008;\

            JUMP (P0);");

}

__attribute__((__section__(".textspecial")))

void perform_boot_direct()

{

asm("       UNLINK;\

            LINK 64;\

            [ -- SP] = (R7:0, P5:0) \

            [ -- SP] = RETS; \

            [ -- SP] = FP;    \

            P0.L = (_sp_val);\

            P0.H = (_sp_val);\

            R0 = SP;\

            [P0] = R0;\

            R0.L = (0x6000);\

            R0.H = (0xFF90);\

            SP = R0;\

            FP = R0;\

            P0.H = 0x0000;\

            P0.L = 0x0020;\

            JUMP (P0);");

}

Using symbols from VDSP generated dxe:

To run code without symbols is tough, so the following might help in that case:

1. Generate symbol table via elfdump -n .symtab test.dxe

2. Reuse the VDSP generated symbols by directly defining values of these symbols in GCC LDSCRIPT.

3. Reuse the symbols (global data or functions) correctly as defined in the VDSP project.

4. Return from VDSP app via RTS.

One could extract just few required user-level symbols from the appropriate file mentioned in symbol table. Even then registers must be properly preserved.

Example code calling function label

perform_store();

load_vdsp_app(); // defined in ldscript - PROVIDE (_test_led_func = 0x20);

 

operations required before calling application
__attribute__((__section__(".textspecial")))
void perform_store()
{
asm("   UNLINK;\
       LINK 64;\
       [ -- SP] = (R7:0, P5:0) \
       [ -- SP] = RETS; \
       [ -- SP] = FP; \
       P0.L = (_sp_val);\
       P0.H = (_sp_val);\
       R0 = SP;\
       [P0] = R0;\
       R0.L = (0x6000);\
       R0.H = (0xFF90);\
       SP = R0;\
       FP = R0;\
       RTS;");\
}
  • Share
  • History
  • More
  • Cancel
Comments
Anonymous
Related
 
社交网络
快速链接
  • 关于ADI
  • Partners
  • 模拟对话
  • 职业
  • 联系我们
  • 投资信息
  • 新闻中心
  • 质量和可靠性
  • 办事处与代理商
  • Analog Garage
语言
  • English
  • 简体中文
  • 日本語
  • Руccкий
电子快讯

欲获得最新ADI产品、设计工具、培训与活动的相关新闻与文章,请从我们的在线快讯中选出您感兴趣的产品类别,每月或每季度都会发送至您的收件箱。

订阅
Switch to mobile view
Analog Logo
© 1995 - 2021 Analog Devices, Inc. All Rights Reserved 沪ICP备09046653号-1
  • ©
  • 1995 - 2021 Analog Devices, Inc. All Rights Reserved
  • 沪ICP备09046653号-1
  • 网站地图
  • 隐私和保密政策
  • 隐私设置
  • 使用条款
 
Social
Quick Links
  • About ADI
  • Partners
  • Analog Dialogue
  • Careers
  • Contact us
  • Investor Relations
  • News Room
  • Quality & Reliability
  • Sales & Distribution
  • Analog Garage
Languages
  • English
  • 简体中文
  • 日本語
  • Руccкий
Newsletters

Interested in the latest news and articles about ADI products, design tools, training and events? Choose from one of our 12 newsletters that match your product area of interest, delivered monthly or quarterly to your inbox.

Sign Up
Switch to mobile view
Analog Logo
© 1995 - 2021 Analog Devices, Inc. All Rights Reserved 沪ICP备09046653号-1
  • ©
  • 1995 - 2021 Analog Devices, Inc. All Rights Reserved
  • 沪ICP备09046653号-1
  • Sitemap
  • Privacy & Security
  • Privacy Settings
  • Terms of use
EngineerZone Uses cookies to ensure you get the best experience in our community. For more information on cookies, please read our Privacy & Security Statement.