Dear Robin,

in message 6.1.1.1.0.20040907142107.01de03e0@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