Autoboot in U-boot

Autoboot in U-boot

[Mike G.]

hi there,

Can someone help me on this autoboot? I successfully configured the
u-boot-0.4.0 for mpc857 custom board but somehow the bootcommand and
boot arg would not run, it just skip the autoboot and goes to prompt. so
help!!!

this is part of the configuration

....................................................................
#if 0
#define CONFIG_BOOTDELAY	-1	/* autoboot disabled*/
#else
#define CONFIG_BOOTDELAY	3	/* autoboot after 5 sec	*/
#endif

#define CONFIG_BOOTCOMMAND	"bootm 02800000 02880000"
#define CONFIG_BOOTARGS		"root=/dev/ram rw"


#undef	CONFIG_WATCHDOG			/* watchdog disabled*/

#define	CONFIG_SCC2_ENET	1	/* use SCC2 ethernet */
#undef	CONFIG_FEC_ENET			/* disable FEC ethernet  */

/* this must be included AFTER the definition of CONFIG_COMMANDS (if
any) */
#include <cmd_confdefs.h>

/*
 * Miscellaneous configurable options
 */
#undef	CFG_LONGHELP		/* undef to save memory*/
#define	CFG_PROMPT	":>"	/* Monitor CommandPrompt	*/
..................................................................

and this is the output displayed:-

......................................................................
U-Boot 0.4.0 (Jul 18 2003 - 10:17:35)

CPU:   unknown MPC850 (0x07000003) at 48 MHz: 4 kB I-Cache 4 kB D-Cache
FEC pret
         *** Warning: CPU Core has Silicon Bugs -- Check the Errata ***
SDRAM:  16 MB
Top of RAM usable for U-Boot at: 01000000
Reserving 512k for U-Boot at: 00f80000
Reserving 256k for malloc() at: 00f40000
Reserving 60 Bytes for Board Info at: 00f3ffc4
Reserving 52 Bytes for Global Data at: 00f3ff90
Stack Pointer at: 00f3ff78
New Stack Pointer is: 00f3ff78
Now running in RAM - U-Boot at: 00f80000
FLASH:  8 MB
In:    serial
Out:   serial
Err:   serial
U-Boot relocated to 00f80000
Net:   SCC ETHERNET
:>
:>

...................................................................

So i don't understand... where did the autoboot go??

hmm.... thanks guys


regards,
Mike G.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Autoboot in U-boot

[Wolfgang Denk]

Dear Mike,

in message <1058495583.1183.8.camel@localhost.localdomain> you wrote:
>
> Can someone help me on this autoboot? I successfully configured the
> u-boot-0.4.0 for mpc857 custom board but somehow the bootcommand and

This is not a linux question, and thus off topic  here.  Please  post
such questions to the u-boot-users mailing list instead.

> boot arg would not run, it just skip the autoboot and goes to prompt. so
> help!!!

What do you get when you run the "printenv" command?

> #define CONFIG_BOOTDELAY	3	/* autoboot after 5 sec	*/

I consider it very bad programming style if the code and the comments
disagree.

> Reserving 512k for U-Boot at: 00f80000

Why is this 512 kB? U-Boot is needs much less memory!

> So i don't understand... where did the autoboot go??

Maybe you have a deeper  problem  with  your  environment  variables.
Where  are  they  stored? In flash? Embedded with the U-Boot image or
separate?

[Followup tu u-boot-users, please]

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
What nonsense people talk about happy marriages! A man can  be  happy
with any woman so long as he doesn't love her.         -- Oscar Wilde

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

HDLC driver for MPC8260

[Adam Kaczynski]

How to buid a "net" driver? Please have a look at
http://www.dgt-lab.com.pl/Serwis/mpc860hdlc.tar.gz

This is a per-channel structure:

typedef struct m_port_t {
         hdlc_device hdlc;    /* HDLC device struct - must be first */
<a lot of private variables comes here...>
}

initialization:
static int __init mpc860hdlc_init(void)
calls
result = register_hdlc_device(&m_dev[i].hdlc);
for each channel  - does registration in the HDLC stack.


de-initialization:
static void __exit mpc860hdlc_cleanup(void)
does the opposite thing:
unregister_hdlc_device(&m_dev[i].hdlc);

open method:
static int m_open(hdlc_device *hdlc)
starts the transmitter queue:
netif_start_queue(hdlc_to_dev(hdlc));


the close method does the opposite thing:
static void m_close(hdlc_device *hdlc)
stops the queue
netif_stop_queue(hdlc_to_dev(hdlc));

the ioctl will probably need re-design work together with sethdlc
utility if you want to pass down more parameters:
static int m_ioctl(hdlc_device *hdlc, struct ifreq *ifr, int cmd)

Now the xmit method:
static int m_xmit(hdlc_device *hdlc, struct sk_buff *skb)
should queue the skb and initiate sending it
(I simplified my task by using an intermediate transmitter queue but you
may wish to directly connect the skbuff to a buffer descriptor- you'll
skip one memcpy then)
or stop if the queue is full (netif_stop_queue(hdlc_to_dev(hdlc));
return 1;)
The skb needs to be freed either after copying it or sending it (in this
case in the interrupt)
dev_kfree_skb_any(skb);
In the transmitter interrupt one should unlock the queue if it was
locked due to being full
netif_wake_queue(hdlc_to_dev(&_m_dev->hdlc));

Reception:
in the interrupt (or in a bottom half if you like)
do some sanity checks... if OK
skb = dev_alloc_skb(len);
copy the data from the low-level buffer
and push it upwards the stack
hdlc_netif_rx(&_m_dev->hdlc, skb);
That's it.
If you like you may also pre-allocate some skbuffs and connect them to
buffer descriptors (this way you will avoid copying)

This is almost all you need to know. Don't hesitate to ask if something
is unclear.

The doble-copying appears not to spoil the performance too much. For
8260 it is even less significant (I checked it for ATM driver) but if
you want to make your boss more happy you may design the driver in a
more mature way than I did.

Regards,
Adam


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/