RE: [ECOS] Flash - the saga continues

["Matt Sartori" <msartori at hanoverdisplays dot com>]

Thanks again, Andrew, for prodding me in the right direction. This was
indeed the problem; an old dependency mixed with a bit of false
assumption (that clicking the clean button in the configtool would
actually remove any such stale objects). What, aside from starting
afresh in a new directory, might one do to avoid such scenarios in the
future? 

P.S. The objdump "trick" was a good help I hadn't used before.

m@

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Matt
Sartori
Sent: 30 August 2005 15:58
To: Andrew Lunn
Cc: eCos Discussion
Subject: RE: [ECOS] Flash - the saga continues

Hmm. The symbol appears in two object files:

devs_flash_arm_str710fz2_flash.o whose first entry is

	00000000 l	df	*ABS*	00000000 flash.c
and further down that object file's table is
	00000000 l    d  .text.flash_hwr_init	00000000
and further still
	00000000 g     F .text.flash_hwr_init	00000050 flash_hwr_init

the other object file that lists it is 
	io_flash_flash.o:     file format elf32-littlearm
which again starts off with
	00000000 l    df *ABS*	00000000 flash.c
and lists it as 
	00000000         *UND*	00000000 flash_hwr_init

Looking in the relevant flash.c there is no sign of the flash_hwr_init
function but...My driver files used to be called just flash.c and .h
before I renamed them to MYBOARD_flash.c and .h and I now have a
sneaking suspicion that the project somehow is still looking (and
finding?) those. 
I have occasionally clicked clean in the configtool's build menu but
perhaps that's not enough?
I'll try and make a brand new directory and see what happens.

m@

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: 30 August 2005 15:29
To: Matt Sartori
Cc: eCos Discussion
Subject: Re: [ECOS] Flash - the saga continues

On Tue, Aug 30, 2005 at 02:19:47PM +0100, Matt Sartori wrote:
> Hi Andrew.
> I'm using my own flash drivers which I've placed in
> /packages/devs/flash/arm/myboard/current/src and, in the configtool
> packages window the packages used for my particular configuration are
> both the "generic FLASH memory support" and the "FLASH memory support
> for the ARM STR710FZ2" (which I've been referring to as my board in my
> postings). All the stuff I've not written myself came from a cvs
> snapshot from a month or so back.
> 
> The CYGPKG_REDBOOT_FLASH is set to true.
> I know that Redboot is using (or at least calling the expected
> functions) because on reset it now displays the message;
> "FLASH: 0x00000000 - 0x0, 0 blocks of 0x00000000 bytes each."
> I have put a hang (while(1);) in the function that calls the
> flash_hwr_init (called flash_init in
> /packages/io/flash/current/src/flash.c) and it does hang, but putting
> the same in my flash_hwr_init doesn't hang it, ergo it must be calling
> some other flash_hwr_init. My suspicions were then confirmed when I
> renamed my flash_hwr_init and Redboot didn't bat an eyelid.

Try

XXX-elf-objdump --syms install/lib/libtarget.a | less

Then search for flash_hwr_init. You can then see which object file the
symbol is in. That should give you some clues.

        Andrew


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


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster
(postmaster@hanoverdisplays.com) and delete the material from any
computer.

Although we routinely screen for viruses, addressees should check this
e-mail and any attachment for viruses. We make no warranty as to absence
of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this
email is of a personal nature, it must not be relied upon as expressing
the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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


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