[U-Boot-Users] Few U-boot architecture/implementation questions

[Wolfgang Denk]

Dear Robin,

in message <6.1.1.1.0.20040907142107.01de03e0 at wheresmymailserver.com> you wrote:
> 
> For serial I/O, the cpu specific function found in /cpu/<processor>serial.c 
> named serial_getc(void); can either be implemented where
>   - serial_getc sits a bangs on UART_rx_buff as fast as it can, until 
> something shows up. (idle loop of wait for keystroke).
> OR
>   - an independent uart_rx_int populates a ring buffer, serial_getc grabs 
> the character from the ring buffer, if there isn't a char in the ring 
> buffer, go to sleep for 1ms (at 115,200 Buad, 8N1; 1 char = ~87us; as long 
> as the ring buffer can cope with 12 chars you should be OK).
> 
> It seems as if most of the implementations that I looked at do the first - 
> which is easier, but it is also why monitors, boot loaders,  etc are 
> usually worse case power consumers. (IMHO - idle loops should be idle - not 

Boot loaders are boot loaders, i. e. tools to load  and  start  some-
thing. In the target system, you want to spend as few milliseconds in
the  boot  loader  as  possible.  Don't worry about power consumption
during this time.

The design principle for U-Boot is to make it as easily  to  port  to
new hardware as possible, which means: use a polling driver.

> wait for keystroke - but it is harder, and adds complexity - you still can 
> get UART interrupts when you have networking activity, and you need to make 
> sure that you can handle both - so I can understand why it is implemented 
> as is).

U-Boot is strictly single  tasking.  Such  added  complexity  is  not
wanted, and not needed.


> Question #2
> ---------------------------
> For Networking functions - I have a SMSC LAN911C11 on the first target 
> board, and every time I access the networking functions, it seems to 
> re-initalize the SMSC 9191C111.

Please define what "access the networking functions" means.

> Is this normal? Or do I have a bug (I would assume - bug, but didn't see 
> anything yet).

Normally the ethernet interface gets initialized only once - when you
use the first U-Boot command that acceses the ethernet. An  exception
is  systems  with  multiple interfaces - here a switch to a different
interface will cause this interface to be (re-) initialized.

But if you mean that you run 5 times  the  "tftp"  command  then  you
should  see  only  a  single  init  call  (before  the first transfer
starts).


> Question #3
> ----------------------
> In /include/configs/<board>.h what should CFG_HZ be set to? Lost of 
> different boards seem to be set to 1000 , (but I don't think that they are 

CFG_HZ is the number of clock tick  (timer  interrupts)  per  second.
Typically the timer is configured to run at 1 kHz, thus the 1000.

Some ports misunderstood the meaning of CFG_HZ  and  use  atronomical
values  which  break  this  meaning. Some of them even cause warnings
because of integer overflows when computing delays  etc.  Such  ports
are broken and should be fixed.

> all running at the same frequency) but then some are not - I could not find 
> it int the docs (but maybe didn't look hard enough)

A patch to update the READEM is welcome ;-)


> Question #4
> --------------------
> In /cpu/<cpu_type>interrupts.c in the function udelay(unsigned long usec) - 
> how exact should this be? (exactly 1.00000us or +/- 5% is OK?)

Ther eis no realtime critical stuff in U-Boot. Make it as pricise  as
possible without breaking a leg.


> Question #5
> ----------------------
> In /lib_<cup_type>/timer.c (for those processors that have it) - I have a 
> processor that supports ticks in terms of instructions clocks (up to 
> 750MHz) or peripheral clock ticks (up to 133MHz). I assume that peripheral 
> clocks ticks are OK. (and that loosing the accuracy is not a big deal).

U-Boot does not assume nor guarantee any accuracy of timers.


> Question #6
> -------------------
> Which is actually more of a feature enhancement that a question - if I 
> implement a autobaud routine in /cpu/<cpu_type>/serial.c in the function 
> serial_tstc - that would be the correct place for it? (If no key presses, 
> return 0, if there is a key press - figure out the speed, set the UART up 
> properly if it is not, and then return a 1 ?)

Autobaud is easy to implement, but difficult to  combine  with  other
existing  features like the autoboot configuration options (password,
etc.) - see doc/README.autoboot; when the port is autobauding it will
be difficult not to break existing code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The number you have dialed is imaginary. Please divide by 0  and  try
again.