omap2420h4 error

Looking at arm-errors.tar.gz -> omap2420h4.ERR

common/libcommon.a(env_flash.o): In function `env_init':
/.automount/castor-vlab/root/home/wd/git/u-boot/work/common/env_flash.c:265:
undefined reference to `flash_probe'
make: *** [/work/wd/tmp/u-boot-arm/u-boot] Error 1

is because in board/omap2420h4 file flash.c isn't used any more. This file contains flash_probe(), but it isn't compiled. If enabled for test, there are tons of link conflicts with cfi_flash.c.

So looks to me that omap2420h4 switch to cfi disabled flash.c (and didn't remove it) but missed to resolve flash_probe() call in env_flash.c.

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=49a7581c6ced35379ec3c450bb60fe736db9d733

Proposal to fix this is to remove unused file board/omap2420h4/flash.c and remove calls of flash_probe()/omap2420h4 #ifdefs in env_flash.c. However, not sure if this is correct.

Opinions?

Cheers

Dirk

Dirk Behme stated on 8/19/2007 12:05 PM:

I think a more details solution is required for all omap2 SDPs.. the newer H4's seem to have larger range of device supports and i am looking to work towards a common code base for all SDP platforms(2430,3430 etc).. something like board/omap-common directory.. i have started a bit on it.. but it will take a bit of time before i can get it out as working patches..
Regards,
NM

Well, I think these are two different things:

Dirk is proposing a fix for the current tree, i. e. for the next release to make the board build.

You are proposing a more general solution, which involves bigger changes than just a bug fix, and thus has to wait for the next merge window.

That means we need both...

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nobody trips over mountains. It is the small pebble that  causes  you
to  stumble.  Pass all the pebbles in your path and you will find you
have crossed the mountain.

Yes, thanks for clarification.

What's about this regarding the first step, make board build for next release?

--

Fix compilation error for omap2420h4_config. omap2420h4 switched to cfi, so remove old (already disabled) flash.c and flash_probe() calls in env_flash.c.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: omap2420h4_error_fix.txt
Url: http://lists.denx.de/pipermail/u-boot/attachments/20070820/d30873f8/attachment.txt

Applied, thanks.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Chairman was as necessary to a Board planet  as  the  zero  was  in
mathematics, but being a zero had big disadvantages...
                         - Terry Pratchett, _The Dark Side of the Sun_

That was fixed a while back but the patch was pulled. I had like many other older ports had done cloned a generic flash file and made it private. This allowed sibley addition and other fixes. At that time WD objected and not much has happened since then. H4 and 2430SDP support many many different memories configurations across their versions. Providing support for them all in the generic areas requires a good amount of clean up.

This leaves a few approaches with functionality and time/effort as variables.

- Provide support for 1 of the 10 configuration very neatly with minimal effort (only allow 10% of users to work).
- Provide all 10 neatly with high effort (works for 98%).
- Provide all 10 functioning not so neatly but confining it to the board port directory (works for 98%).

Our own port structure now makes omap242x and 243x boards common in several spots and has omap34xx in places. None of this is reflected in the public git code.

If Peter is up to a big diff we might sync them all up to a point where they are all including and booting. Doing it in many patches would probably be unproductive.

Further clean up perhaps with what Nishant was saying could also happen.

I'm happy to allocate a couple days and make them work in the quick method but that might not be the path which goes in... Giving days is do-able weeks is not right now. If others have time then perhaps there are some other options.

Regards,
Richard W.