This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ecos redboot compile problem.


Just so we're on the same page here, what system are you using to compile
your eCos?  Is it, perhaps, a Sparc or other big-endian machine?  That might
explain the byte swapping problem you are observing.

As far as the 12345678 87654321 "trick"...
This is a trick that I implemented solely to minimize the number of times I
have to switch to running Code Composer (on a Windows machine) so I can stay
in my nice, warm, cozy, Linux world.

Basically, RedBoot (and the stupid serial port bootloader I wrote before I
ported RedBoot) checks the first two locations in internal SRAM at startup.
If they are 0x12345678 and 0x87654321 respectively, then RedBoot branches to
the third location in SRAM.  (It also zeros those two locations if they
match -- that way it only works the first time I press reset after loading
code into SRAM).  Since SRAM contents are preserved across hard resets (also
known as "power on" resets, but don't expect SRAM to be preserved across a
power cycle :-)), I can download a new version of RedBoot to internal SRAM,
hold down the reset button for longer than two seconds (so that the FPGA
generates a poweron reset), and see if my new version of RedBoot works
before I commit it to flash.  Without that feature, if I committed a new
version of RedBoot to flash, pressed the reset button, and something didn't
work, I would have to go find my Windows box with Code Composer on it,
attach the JTAG, and use Code Composer to reload a known good RedBoot.

There is nothing special about the 0x12345678 and 0x87654321 constants.
They were not selected because of any resemblance to known opcodes.  They
were just the first two constants that I thought of that I thought had a
reasonable chance of not showing up by chance in SRAM.

Now, having said all of that, it turns out that the SRAM version of RedBoot
is also suitable for loading in via Code Composer.  Sometime in the recent
past, TI added support for ELF files (traditionally, TI tools only support
COFF files).  However, with the version 2.00 tools I was using, I found that
some versions of the RedBoot for SRAM caused CCS to die.  So I fiddled
around, removing the networking packages, etc... until I generated an ELF
file which didn't choke CCS.  I haven't tried with the 2.20 tools that are
available now.

Regardless, you should be able to generate the SRAM version of RedBoot with
something similar to:

prompt$ ecosconfig new innovator redboot
prompt$ ecosconfig import
$ECOS_REPOSITORY/hal/arm/arm9/innovator/current/misc/redboot_SRAM.ecm
prompt$ ecosconfig tree
prompt$ make
prompt$ arm-elf-objdump -D install/bin/redboot.elf | grep "2000000[04]:"

produces the following output:

20000000:	12345678 	eornes	r5, r4, #125829120	; 0x7800000
20000004:	87654321 	strhib	r4, [r5, -r1, lsr #6]!

FWIW...
prompt$ arm-elf-gcc -v
Reading specs from
/usr/local/xtools/arm-elf-3.2.1/lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: ../../src/gcc-3.2.1/configure --target=arm-elf
--prefix=/usr/local/xtools/arm-elf-3.2.1 --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/usr/local/xtools/arm-elf-3.2.1/arm-elf/include -v
Thread model: single
gcc version 3.2.1

HTH
--wpd

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]