hal-porting-platform.html
来自「有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等」· HTML 代码 · 共 1,675 行 · 第 1/3 页
HTML
1,675 行
<!-- Copyright (C) 2003 Red Hat, Inc. --><!-- This material may be distributed only subject to the terms --><!-- and conditions set forth in the Open Publication License, v1.0 --><!-- or later (the latest version is presently available at --><!-- http://www.opencontent.org/openpub/). --><!-- Distribution of the work or derivative of the work in any --><!-- standard (paper) book form is prohibited unless prior --><!-- permission is obtained from the copyright holder. --><HTML><HEAD><TITLE>Platform HAL Porting</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE=" Porting Guide"HREF="hal-porting-guide.html"><LINKREL="PREVIOUS"TITLE="HAL Coding Conventions"HREF="hal-porting-coding-conventions.html"><LINKREL="NEXT"TITLE="Variant HAL Porting"HREF="hal-porting-variant.html"></HEAD><BODYCLASS="SECTION"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="hal-porting-coding-conventions.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 11. Porting Guide</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="hal-porting-variant.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECTION"><H1CLASS="SECTION"><ANAME="HAL-PORTING-PLATFORM">Platform HAL Porting</H1><P>This is the type of port that takes the least effort. It basicallyconsists of describing the platform (board) for the HAL: memorylayout, early platform initialization, interrupt controllers, and asimple serial device driver.</P><P>Doing a platform port requires a preexisting architecture andpossibly a variant HAL port.</P><DIVCLASS="SECTION"><H2CLASS="SECTION"><ANAME="AEN9415">HAL Platform Porting Process</H2><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9417">Brief overview</H3><P>The easiest way to make a new platform HAL is simply to copy anexisting platform HAL of the same architecture/variant and change allthe files to match the new one. In case this is the first platform forthe architecture/variant, a platform HAL from another architectureshould be used as a template.</P><P>The best way to start a platform port is to concentrate on gettingRedBoot to run. RedBoot is a simpler environment than full eCos, itdoes not use interrupts or threads, but covers most of thebasic startup requirements.</P><P>RedBoot normally runs out of FLASH or ROM and provides program loadingand debugging facilities. This allows further HAL development tohappen using RAM startup configurations, which is desirable for thesimple reason that downloading an image which you need to test isoften many times faster than either updating a flash part, or indeed,erasing and reprogramming an EPROM.</P><P>There are two approaches to getting to this first goal:</P><P></P><OLTYPE="1"><LI><P>The board is equipped with a ROM monitor which allows "load and go" ofELF, binary, S-record or some other image type which can be createdusing <SPANCLASS="APPLICATION">objcopy</SPAN>. This allows you to developRedBoot by downloading and running the code (saving time).</P><P>When the stub is running it is a good idea to examine the varioushardware registers to help you write the platform initialization code.</P><P>Then you may have to fiddle a bit going through step two (getting itto run from ROM startup). If at all possible, preserve the originalROM monitor so you can revert to it if necessary.</P></LI><LI><P>The board has no ROM monitor. You need to get the platforminitialization and stub working by repeatedly making changes, updatingflash or EPROM and testing the changes. If you are lucky, you have aJTAG or similar CPU debugger to help you. If not, you will probablylearn to appreciate LEDs. This approach may also be needed during theinitial phase of moving RedBoot from RAM startup to ROM, since it isvery unlikely to work first time.</P></LI></OL></DIV><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9431">Step-by-step</H3><P>Given that no two platforms are exactly the same, you may have todeviate from the below. Also, you should expect a fair amount offiddling - things almost never go right the first time. See the hintssection below for some suggestions that might help debugging.</P><P>The description below is based on the HAL layout used in the MIPS,PC and MN10300 HALs. Eventually all HALs should be converted to look likethese - but in a transition period there will be other HALs which looksubstantially different. Please try to adhere to the following as much ispossible without causing yourself too much grief integrating with aHAL which does not follow this layout.</P><DIVCLASS="SECTION"><H4CLASS="SECTION"><ANAME="AEN9435">Minimal requirements</H4><P>These are the changes you must make before you attempt to buildRedBoot. You are advised to read all the sources though.</P><P></P><OLTYPE="1"><LI><P>Copy an existing platform HAL from the same or another architecture. Rename the files as necessary to follow the standard: CDL and MLT related files should contain the <arch>_<variant>_<platform> triplet.</P></LI><LI><P>Adjust CDL options. Primarily option naming, real-time clock/counter, and CYGHWR_MEMORY_LAYOUT variables, but also other options may need editing. Look through the architecture/variant CDL files to see if there are any requirements/features which where not used on the platform you copied. If so, add appropriate ones. See <AHREF="hal-porting-platform.html#HAL-PORTING-CDL-REQUIREMENTS">the Section called <I>HAL Platform CDL</I></A> for more details.</P></LI><LI><P>Add the necessary packages and target descriptions to the top-level <TTCLASS="FILENAME">ecos.db</TT> file. See <AHREF="hal-porting-platform.html#HAL-PORTING-ECOS-DATABASE">the Section called <I>eCos Database</I></A>. Initially, the target entry should only contain the HAL packages. Other hardware support packages will be added later.</P></LI><LI><P>Adjust the MLT files in <TTCLASS="FILENAME">include/pkgconf</TT> to match the memory layout on the platform. For initial testing it should be enough to just hand edit .h and .ldi files, but eventually you should generate all files using the memory layout editor in the configuration tool. See <AHREF="hal-porting-platform.html#HAL-PORTING-PLATFORM-MEMORY-LAYOUT">the Section called <I>Platform Memory Layout</I></A> for more details.</P></LI><LI><P> Edit the <TTCLASS="FILENAME">misc/redboot_<STARTUP>.ecm</TT> for the startup type you have chosen to begin with. Rename any platform specific options and remove any that do not apply. In the <TTCLASS="LITERAL">cdl_configuration</TT> section, comment out any extra packages that are added, particularly packages such as <TTCLASS="LITERAL">CYGPKG_IO_FLASH</TT> and <TTCLASS="LITERAL">CYGPKG_IO_ETH_DRIVERS</TT>. These are not needed for initial porting and will be added back later. </P></LI><LI><P>If the default IO macros are not correct, override them in plf_io.h. This may be necessary if the platform uses a different endianness from the default for the CPU.</P></LI><LI><P>Leave out/comment out code that enables caches and/or MMU if possible. Execution speed will not be a concern until the port is feature complete.</P></LI><LI><P>Implement a simple serial driver (polled mode only). Make sure the initialization function properly hooks the procedures up in the virtual vector IO channel tables. RedBoot will call the serial driver via these tables.</P><P> By copying an existing platform HAL most of this code will be already done, and will only need the platform specific hardware access code to be written. </P></LI><LI><P>Adjust/implement necessary platform initialization. This can be found in <TTCLASS="FILENAME">platform.inc</TT> and <TTCLASS="FILENAME">platform.S</TT> files (ARM: <TTCLASS="FILENAME">hal_platform_setup.h</TT> and <TTCLASS="FILENAME"><platform>_misc.c</TT>, PowerPC: <TTCLASS="FILENAME"><platform>.S</TT>). This step can be postponed if you are doing a RAM startup RedBoot first and the existing ROM monitor handles board initialization.</P></LI><LI><P>Define <TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET</TT> (optionally empty) and <TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET_ENTRY</TT> so that RedBoot can reset-on-detach - this is very handy, often removing the need for physically resetting the board between downloads.</P></LI></OL><P>You should now be able to build RedBoot. For ROM startup:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="PROGRAMLISTING">% ecosconfig new <target_name> redboot% ecosconfig import $(ECOS_REPOSITORY)/hal/<architecture>/<platform>/<version>/misc/redboot_ROM.ecm% ecosconfig tree% make</PRE></TD></TR></TABLE><P>You may have to make further changes than suggested above to getthe make command to succeed. But when it does, you should find aRedBoot image in install/bin. To program this image into flash orEPROM, you may need to convert to some other file type, and possiblyadjust the start address. When you have the correct<SPANCLASS="APPLICATION">objcopy</SPAN> command to do this, add it to the<TTCLASS="LITERAL">CYGBLD_BUILD_GDB_STUBS</TT> custom build rule in theplatform CDL file.</P><P>Having updated the flash/EPROM on the board, you should see outputon the serial port looking like this when powering on the board:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="PROGRAMLISTING">RedBoot(tm) bootstrap and debug environment [ROMRAM]Non-certified release, version UNKNOWN - built 15:42:24, Mar 14 2002Platform: <PLATFORM> (<ARCHITECTURE> <VARIANT>)Copyright (C) 2000, 2001, 2002, Red Hat, Inc.RAM: 0x00000000-0x01000000, 0x000293e8-0x00ed1000 availableFLASH: 0x24000000 - 0x26000000, 256 blocks of 0x00020000 bytes each.RedBoot> </PRE></TD></TR></TABLE><P>If you do not see this output, you need to go through all yourchanges and figure out what's wrong. If there's a user programmableLED or LCD on the board it may help you figure out how far RedBootgets before it hangs. Unfortunately there's no good way to describewhat to do in this situation - other than that you have to play withthe code and the board.</P></DIV><DIVCLASS="SECTION"><H4CLASS="SECTION"><ANAME="AEN9484">Adding features</H4><P>Now you should have a basic RedBoot running on the board. Thismeans you have a the correct board initialization and a working serialdriver. It's time to flesh out the remaining HAL features.</P><P></P><OLTYPE="1"><LI><P>Reset. As mentioned above it is desirable to get the board toreset when GDB disconnects. When GDB disconnects it sends RedBoota kill-packet, and RedBoot first calls <TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET()</TT>,attempting to perform a software-invoked reset. Most embeddedCPUs/boards have a watchdog which is capable of triggering a reset.If your target does not have a watchdog, leave<TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET()</TT> empty and rely on the fallback approach.</P><P>If <TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET()</TT> did not cause a reset, RedBoot willjump to <TTCLASS="LITERAL">HAL_STUB_PLATFORM_RESET_ENTRY</TT> - this should be the addresswhere the CPU will start execution after a reset. Re-initializing theboard and drivers will <SPANCLASS="emphasis"><ICLASS="EMPHASIS">usually</I></SPAN> be good enough to make ahardware reset unnecessary.</P><P>After the reset caused by the kill-packet, the target will be readyfor GDB to connect again. During a days work, this will save you frompressing the reset button many times.</P><P>Note that it is possible to disconnect from the board withoutcausing it to reset by using the GDB command "detach".</P></LI><LI><P>Single-stepping is necessary for both instruction-level debuggingand for breakpoint support. Single-stepping support should already bein place as part of the architecture/variant HAL, but you want to giveit a quick test since you will come to rely on it.</P></LI><LI><P>Real-time clock interrupts drive the eCos scheduler clock. Manyembedded CPUs have an on-core timer (e.g. SH) or decrementer(e.g. MIPS, PPC) that can be used, and in this case it will already besupported by the architecture/variant HAL. You only have to calculateand enter the proper <TTCLASS="LITERAL">CYGNUM_HAL_RTC_CONSTANTS</TT>definitions in the platform CDL file.</P><P>On some targets it may be necessary to use a platform-specifictimer source for driving the real-time clock. In this case you alsohave to enter the proper CDL definitions, but must also definesuitable versions of the <TTCLASS="LITERAL">HAL_CLOCK_XXXX</TT> macros.</P></LI><LI><P>Interrupt decoding usually differs between platforms because thenumber and type of devices on the board differ. In<TTCLASS="FILENAME">plf_intr.h</TT> (ARM:<TTCLASS="FILENAME">hal_platform_ints.h</TT>) you must either extend orreplace the default vector definitions provided by the architectureor variant interrupt headers. You may also have to define<TTCLASS="LITERAL">HAL_INTERRUPT_XXXX</TT> control macros.</P></LI><LI><P>Caching may also differ from architecture/variant definitions.This maybe just the cache sizes, but there can also be biggerdifferences for example if the platform supports 2nd level caches.</P><P>When cache definitions are in place, enable the caches onstartup. First verify that the system is stable for RAM startups, thenbuild a new RedBoot and install it. This will test if caching, and inparticular the cache sync/flush operations, also work for ROM startup.</P></LI><LI><P>Asynchronous breakpoints allow you to stop application executionand enter the debugger. Asynchronous breakpoint details are describedin .</P></LI></OL><P>You should now have a completed platform HAL port. Verify itsstability and completeness by running all the eCos tests and fix anyproblems that show up (you have a working RedBoot now, remember! Thatmeans you can debug the code to see why it fails).</P><P>Given the many configuration options in eCos, there may be hiddenbugs or missing features that do not show up even if you run all thetests successfully with a default configuration. A comprehensive testof the entire system will take many configuration permutations andmany many thousands of tests executed.</P></DIV></DIV><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9517">Hints</H3><P></P><UL><LI><P>JTAG or similar CPU debugging hardware can greatly reduce the time it takes to write a HAL port since you always have full visibility of what the CPU is doing. </P></LI><LI><P>LEDs can be your friends if you don't have a JTAG device. Especially in the start of the porting effort if you don't already have a working ROM monitor on the target. Then you have to get a basic RedBoot working while basically being blindfolded. The LED can make it little easier, as you'll be able to do limited tracking of program flow and behavior by switching the LED on and off. If the board has multiple LEDs you can show a number (using binary notation with the LEDs) and sprinkle code which sets different numbers throughout the code.</P></LI><LI><P⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?