[U-Boot-Users] Question about setting the sys clk freq based on a pull up on io.

[Conn Clark]

Hello all,

	We have just finished designing the cpu to our next generation product 
and I'm just getting into the U-boot code. In my preliminary examination 
of our design and U-Boot I ran into an interesting problem and wanted to 
see if anybody had a solution or suggestion on an approach.

	Our design is based on a 333MHz IBM405EP processor. We wish to detect 
the oscilator speed we are using via a pullup or pulldown resistor on an 
IO line. In order to make our product cheap we were planning to drive 
the system clock with a 25MHz oscilator that also drives our ethernet 
phys. We wanted the flexibility to use a second oscilator to drive the 
system clock at 33.3MHz so we could have the option of driving our 
processor, RAM, and PCI bus at the maximum speed. to do this we added a 
second set of pads for an oscilator inbetween the 25MHz oscilator and 
the mcroprocessor, so we only need to cut the trace between the two 
oscilators when we wish to use the 33.3MHz clock.  What I was planning 
to do was initialy configure a microprocessor IO pin as an input and 
read the value of the pull up or pull down to determine the system clock 
speed then reconfigure it as an output to be used as a control line.

	My problem is how do I go about this without severly modifying U-Boots 
structure. In analyzing how to do this I determined that the 
configuration and reading of the IO pin sould be done in a 
board_pre_init function. This rases the issue of passing values between 
the init functions called by board_init_f. My second issue is how do I 
deal with the two frquencies since only one can be defined as 
CONFIG_SYS_CLK_FREQ(which is used in several places) without sticking 
lots of nasty board specific ifdefs through out the code.

	I didn't see a solution in any of the other boards that I looked at 
(Note I didn't look at them all). We realy don't want to have to specify 
at compile time what frequency we intend on using. This may become an 
option on our products and we don't want to have two different firmware 
images to confuse our costomers (and ourselves). This causes to many 
headaches with determining what the costomer has and problems created by 
loading the wrong firmware.

	Has anybody tackled these two problems yet or do they have any sugestions?

Many thanks in advance,

	Conn

-- 

*****************************************************************
   If you live at home long enough, your parents will move out.
  (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
  This email address may be used to communicate to Conn Clark
  provided it is not being used for advertisement purposes, unless
  prior written consent is given. This email address may not be
  sold under any circumstances. All other rights reserved.