[U-Boot-Users] CLI over Ethernet

[U-Boot-Users] CLI over Ethernet

[Srivatsan]

Hi all,

    Greetings. There is a requirement to provide CLI over Ethernet in
uboot.

    1) The CLI works over LAN (not using TCP/IP) using Logical link
control Layer. (Is this possible?)

    2) Anyone who has done a similar stuff has any advice for us? (Not
in negative :-))
    3) Is there any documentation or RFC available which talks of
(Ethernet) connectivity at LLC layer? 

Thanks and Best Regards,
C.R.Srivatsan 
    

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of
u-boot-users-request at lists.sourceforge.net
Sent: Wednesday, November 24, 2004 8:43 PM
To: u-boot-users at lists.sourceforge.net
Subject: U-Boot-Users digest, Vol 1 #1106 - 13 msgs

Send U-Boot-Users mailing list submissions to
	u-boot-users at lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/u-boot-users
or, via email, send a message with subject or body 'help' to
	u-boot-users-request at lists.sourceforge.net

You can reach the person managing the list at
	u-boot-users-admin at lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of U-Boot-Users digest..."


Today's Topics:

   1. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Friedrich, Lars)
   2. question on drive (zhonglei)
   3. boot problem (Alessio Raccis)
   4. Re: question on drive (Marc Leeman)
   5. boot problem (Alessio Raccis)
   6. R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 (Paolo
Broggini)
   7. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)
   8. Re: boot problem (Wolfgang Denk)
   9. Re: question on drive (Wolfgang Denk)
  10. Re: question on drive (Marc Leeman)
  11. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Paugam Luc)
  12. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Steven Scholz)
  13. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)

--__--__--

Message: 1
Subject: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
Date: Wed, 24 Nov 2004 08:46:45 +0100
From: "Friedrich, Lars" <lars.friedrich@wago.com>
To: <u-boot-users@lists.sourceforge.net>

> > Why is that so bad? It makes it possible to debug U-Boot
> > with just loading the image into RAM using BDI2000.
> Which is an unsupported mode of operation which works for a handfull
> of experts and causes confusion with many, many newbees.

How do these lines of code confuse a newbie more than any other code
in the file?

> > But how would you debug U-Boot?
> As I always do. Attach the BDI, burn to flash, start in GDB.

There are 53982 other hardware debuggers out there and only the
minority (is there actually one besides the BDI?) support the
burn to flash feature you rely on. So if you need to start U-Boot
to flash U-Boot, you either do those few lines of code to skip
the relocation or get/use another piece of actually redundant
software to get the image on the flash. I don't know why the
latter should save me time.

> You can do this if you know exactly what you're doing,

Isn't this what is assumed here anyway?

Best regards,
Lars Friedrich

--=20


--__--__--

Message: 2
Date: Wed, 24 Nov 2004 15:25:07 +0800
From: "zhonglei" <zhonglei@RCS-9000.COM>
Reply-To: <zhonglei@RCS-9000.COM>
To: <u-boot-users@lists.sourceforge.net>
Subject: [U-Boot-Users] question on drive

hi
   Sorry for bothering you! But would you please give me a hand.When I
insert a Intel Pro/100s server Adapter into the PCI slot on
Lite5200(motorola MPC5200 development kit) and start the kernel,the
kernel run into a dead lock. The reports are as follows:

.
.
.
IP-Config: Retrying forever (NFS root)...
eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
eth1: Waiting for the link to be up...
eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation complete.
e100: eth0 NIC Link is Up 100 Mbps Full duplex
Sending DHCP requests ...... timed out!
    Please tell me how can I handle it! Thanks in advance!
Best Regards
zhonglei


--__--__--

Message: 3
From: "Alessio Raccis" <lolloz@tiscali.it>
To: <u-boot-users@lists.sourceforge.net>
Date: Wed, 24 Nov 2004 10:10:39 +0100
Subject: [U-Boot-Users] boot problem

Hi all,

I have a problem and now, it's weird to say, I pray to a kernel panic !

I'm working on smdk2410 and I have a u-boot version modified to boot
from
smartmedia. I want, or better I hope to boot 2.6.7 linux kernel. So, I
create a zImage by compiling kernel and then I make:

gzip -9 zImage
./mkimage -A arm  -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000
-n
"Linux Kernel Image" -d zImage.gz uimage

At this point, I download uimage at 33000000 address from a tftp server.

SMDK2410 # tftpboot 33000000 uimage

TFTP from server 10.124.7.161; our IP address is 10.124.7.50

Filename 'uimage'.

Load address: 0x33000000

Loading:
#################################################################

#################################################################

########################################################

done

Bytes transferred = 950519 (e80f7 hex)



Now I boot the kernel and I have:



SMDK2410 # bootm

## Booting image at 33000000 ...

Image Name: Linux Kernel Image

Created: 2004-11-17 13:50:56 UTC

Image Type: ARM Linux Kernel Image (gzip compressed)

Data Size: 950455 Bytes = 928.2 kB

Load Address: 30008000

Entry Point: 30008000

Verifying Checksum ... OK

Uncompressing Kernel Image ... OK



Starting kernel ...



Uncompressing
Linux...................................................................
done, booting the kernel.





Nothing else !! Can anyone help me, please ? Which is my mistake ?



thanks in advance.



Best regards,



Alex



--__--__--

Message: 4
Date: Wed, 24 Nov 2004 10:14:33 +0100
From: Marc Leeman <marc.leeman@gmail.com>
Reply-To: Marc Leeman <marc.leeman@gmail.com>
To: zhonglei at rcs-9000.com
Subject: Re: [U-Boot-Users] question on drive
Cc: u-boot-users at lists.sourceforge.net

I don't think this has to do with u-boot :) I think you should send
this to the correct mailing list.

> IP-Config: Retrying forever (NFS root)...
> eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
> eth1: Waiting for the link to be up...
> eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation
complete.
> e100: eth0 NIC Link is Up 100 Mbps Full duplex

Maybe your board configuration of the kernel is not quite correct
and/or some interrupt lines are wongly addressed.

> Sending DHCP requests ...... timed out!
>     Please tell me how can I handle it! Thanks in advance!

$ find . -name '*.c' | xargs grep Sending\ DHCP
And start debugging/instrumenting from there.

--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul


--__--__--

Message: 5
From: "Alessio Raccis" <lolloz@tiscali.it>
To: <u-boot-users@lists.sourceforge.net>
Subject: [U-Boot-Users] boot problem
Date: Wed, 24 Nov 2004 10:18:22 +0100

Hi all,

I have a problem and now, it's weird to say, I pray to a kernel panic !

I'm working on smdk2410 and I have a u-boot version modified to boot
from
smartmedia. I want, or better I hope to boot 2.6.7 linux kernel. So, I
create a zImage by compiling kernel and then I make:

gzip -9 zImage
./mkimage -A arm  -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000
-n
"Linux Kernel Image" -d zImage.gz uimage

At this point, I download uimage at 33000000 address from a tftp server.

SMDK2410 # tftpboot 33000000 uimage

TFTP from server 10.124.7.161; our IP address is 10.124.7.50

Filename 'uimage'.

Load address: 0x33000000

Loading:
#################################################################

#################################################################

########################################################

done

Bytes transferred = 950519 (e80f7 hex)



Now I boot the kernel and I have:



SMDK2410 # bootm

## Booting image at 33000000 ...

Image Name: Linux Kernel Image

Created: 2004-11-17 13:50:56 UTC

Image Type: ARM Linux Kernel Image (gzip compressed)

Data Size: 950455 Bytes = 928.2 kB

Load Address: 30008000

Entry Point: 30008000

Verifying Checksum ... OK

Uncompressing Kernel Image ... OK



Starting kernel ...



Uncompressing
Linux...................................................................
done, booting the kernel.





Nothing else !! Can anyone help me, please ? Which is my mistake ?



thanks in advance.



Best regards,



Alex



--__--__--

Message: 6
From: "Paolo Broggini" <pbroggini@softool.ch>
To: "Friedrich, Lars" <lars.friedrich@wago.com>,
	<u-boot-users@lists.sourceforge.net>
Subject: R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
Date: Wed, 24 Nov 2004 10:29:52 +0100



> -----Messaggio originale-----
> Da: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]Per conto di
Friedrich,
> Lars
> Inviato: mercoled?, 24. novembre 2004 08:47
> A: u-boot-users at lists.sourceforge.net
> Oggetto: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200
>
>
> > > Why is that so bad? It makes it possible to debug U-Boot
> > > with just loading the image into RAM using BDI2000.
> > Which is an unsupported mode of operation which works for a handfull
> > of experts and causes confusion with many, many newbees.
>
> How do these lines of code confuse a newbie more than any other code
> in the file?
>
>
> > You can do this if you know exactly what you're doing,
>
> Isn't this what is assumed here anyway?
>
I fully agree with you !!!

Regards
-Paolo Broggini

> Best regards,
> Lars Friedrich
>
> --
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>




--__--__--

Message: 7
To: "Friedrich, Lars" <lars.friedrich@wago.com>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd@denx.de>
Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
Date: Wed, 24 Nov 2004 11:26:56 +0100

Dear Lars,

in message <AB4979EC12A5EB419810807434495A17283C1E@svex01001.wago.local>
you wrote:
>
> > Which is an unsupported mode of operation which works for a handfull
> > of experts and causes confusion with many, many newbees.
> 
> How do these lines of code confuse a newbie more than any other code
> in the file?

It's not the lines of code, but the mode of operation. People tend to
underestimate the complexity of  the  task  and  the  impact  of  the
required modifications.

> > As I always do. Attach the BDI, burn to flash, start in GDB.
> 
> There are 53982 other hardware debuggers out there and only the
> minority (is there actually one besides the BDI?) support the
> burn to flash feature you rely on. So if you need to start U-Boot

C'me on. You must be joking. Please name a few  commercial  debuggers
which do not support flash programming. Maybe we should add a list of
such broken devices to our wiki so people can avoid them?

Let me check:

* Abatron BDI2000: ok (of course)
* Windriver visionICE II: ok	
* Lauterbach Trace32: ok
* Macraigor Wiggler / Raven / usbDemon: ok
* Agilent 3070 Series etc: ok

Even the free BDM4GDB project suports flash programming.

Please be specific: which BDM/JTAG debugger cannot program  flash?  I
really would like to know to be able to warn our customers.

> > You can do this if you know exactly what you're doing,
> 
> Isn't this what is assumed here anyway?

Yes. People should think, machines should work ;-)

There are areas, where small errors have small consequences which are
easy to spot. AQnd there are really nasty problems. If you look  back
at  the archives you will see that this is one of these nasty problem
domains. And it's a FAQ.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only thing necessary for the triumph of evil is for good  men  to
do nothing.                                            - Edmund Burke


--__--__--

Message: 8
To: "Alessio Raccis" <lolloz@tiscali.it>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd@denx.de>
Subject: Re: [U-Boot-Users] boot problem 
Date: Wed, 24 Nov 2004 11:32:35 +0100

In message <001e01c4d205$7e2ca120$cb077c0a@bart> you wrote:
> 
> I have a problem and now, it's weird to say, I pray to a kernel panic
!

Alternatively, try a post-mortem dump of the log_buf area, see
http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis

Or even better: attach your BDI2000 and debug the Linux kernel code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If God had a beard, he'd be a UNIX programmer.


--__--__--

Message: 9
To: Marc Leeman <marc.leeman@gmail.com>
Cc: zhonglei at rcs-9000.com, u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd@denx.de>
Subject: Re: [U-Boot-Users] question on drive 
Date: Wed, 24 Nov 2004 11:30:14 +0100

In message <1f729c4804112401141cd5deb7@mail.gmail.com> you wrote:
> I don't think this has to do with u-boot :) I think you should send
> this to the correct mailing list.

thanks for pointing out.

> > IP-Config: Retrying forever (NFS root)...
> > eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
> > eth1: Waiting for the link to be up...
> > eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation
complete.
> > e100: eth0 NIC Link is Up 100 Mbps Full duplex
> 
> Maybe your board configuration of the kernel is not quite correct
> and/or some interrupt lines are wongly addressed.

No, you are wrong here. It seems the kernel is working perfectly fine.

> > Sending DHCP requests ...... timed out!
> >     Please tell me how can I handle it! Thanks in advance!
> 
> $ find . -name '*.c' | xargs grep Sending\ DHCP
> And start debugging/instrumenting from there.

Always try simple things first! Is there a  DHCP  server  running  to
answer  the  DHCP  requests  from  the  target? Did you run a network
sniffer and actually see the DHCP reply packets on the wire?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No one wants war.
	-- Kirk, "Errand of Mercy", stardate 3201.7


--__--__--

Message: 10
Date: Wed, 24 Nov 2004 11:47:25 +0100
From: Marc Leeman <marc.leeman@gmail.com>
Reply-To: Marc Leeman <marc.leeman@gmail.com>
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] question on drive

> Always try simple things first! Is there a  DHCP  server  running  to
> answer  the  DHCP  requests  from  the  target? Did you run a network
> sniffer and actually see the DHCP reply packets on the wire?

Hm, I assumed this was already checked since it the easiest to do :) I
know, 'assuming' is bad...

This would be (on the server)
# tail -f /var/log/syslog
to check the DCHP packages arriving at the server and the replies being
sen=
t.

--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul


--__--__--

Message: 11
Subject: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
Date: Wed, 24 Nov 2004 11:54:09 +0100
From: "Paugam Luc" <luc.paugam@thomson.net>
To: "Wolfgang Denk" <wd@denx.de>,
   "Steven Scholz" <steven.scholz@imc-berlin.de>
Cc: <u-boot-users@lists.sourceforge.net>

Dear Steven & Wolfgang,

There is perhaps a confusion between _relocation_ and _copy_.

Beware to the fact that actually the AT91RM9200 starter code (especially
=

start.S) does not relocate any code from Flash to RAM (as we can see it
into PowerPC starter code, for example) but rather do a simple copy
of=20
u-boot code from Flash to RAM.

_TEXT_BASE is still defined with a RAM address!

This way to do is unfortunately inherited from ATMEL with their 2 stages
=
boot process.

Regards - Luc

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
> Denk
> Sent: mardi 23 novembre 2004 17:43
> To: Steven Scholz
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200=20
>=20
>=20
> In message <41A35A7E.1020605@imc-berlin.de> you wrote:
> >=20
> > is there a standard way in U-Boot to prevent to the startup=20
> code from relocating=20
> > into RAM?
>=20
> No. U-Boot will always relocate itself to RAM. Well, nearly always  -
> in any halfway sane implementation.
>=20
> > I know that arm920t figures out the currebt address.=20
> compares it to _TEXT_BASE=20
> > and decides wether to relocate or not.
> >=20
> > relocate:				/* relocate U-Boot to=20
> RAM	    */
> > 	adr	r0, _start		/* r0 <- current=20
> position of code   */
> > 	ldr	r1, _TEXT_BASE		/* test if we run from=20
> flash or RAM */
> > 	cmp     r0, r1                  /* don't reloc during=20
> debug         */
>=20
> I wish that code was never written.
>=20
> > So there might be no need for a define like=20
> CFG_DONT_RELOCATE. But how about=20
> > other cpus?
>=20
> All CPUs always relocate the code to RAM. This is the  general  case.
> Anything else is not supported.
>=20
> > (I am asking cause you wrapped the relocate code in=20
> cpu/at91rm9200/start.S with=20
> > CONFIG_BOOTBINFUNC instead of using the above technique.
>=20
> Please consider the CONFIG_BOOTBINFUNC as an optimization  of  effort
> and  effect (read: quick & dirty hack). Feel free to clean up as long
> the result is working code, too.
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --=20
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Fools ignore complexity. Pragmatists suffer it. Some  can  avoid  it.
> Geniuses remove it.
>      - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading
now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>=20


--__--__--

Message: 12
Date: Wed, 24 Nov 2004 13:54:33 +0100
From: Steven Scholz <steven.scholz@imc-berlin.de>
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

Wolfgang Denk wrote:

> In message <41A36CFE.9050900@imc-berlin.de> you wrote:
> 
>>Hmm. So I suggest replacing it with CONFIG_INIT_LOWLEVEL or
CONFIG_LOWLEVEL_INIT.
> 
> 
> Hmmm.. CONFIG or CFG? And what exactly is low (vs. high?) level here?
> 
> 
>>But then: these init steps (clocks and memory) are vital for U-Boot to
run. So 
>>why do we need this define anyway if these steps should be done
always... ?
> 
> 
> Good question. The only reason I can think of  is  to  allob  such  a
> two-stage boot loader as used by Atmel on the AT91RM9200DK.

So we check if all other arm920t boards have an implementation of
memsetup(). 
Then kick out CONFIG_INIT_CRITICAL and introduce 
CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-)


-- 
Steven Scholz


--__--__--

Message: 13
To: Steven Scholz <steven.scholz@imc-berlin.de>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd@denx.de>
Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
Date: Wed, 24 Nov 2004 16:06:46 +0100

In message <41A48489.80203@imc-berlin.de> you wrote:
> 
> So we check if all other arm920t boards have an implementation of
memsetup(). 
> Then kick out CONFIG_INIT_CRITICAL and introduce 
> CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-)

Sounds like a plan to me - but let's use a better name, please.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.



--__--__--

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


End of U-Boot-Users Digest



********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] CLI over Ethernet

[Detlev Zundel]

Hi Srivatsan,

>     Greetings. There is a requirement to provide CLI over Ethernet in
> uboot.

Really?  There is a requirement?  Anyway, check doc/README.NetConsole.

>     1) The CLI works over LAN (not using TCP/IP) using Logical link
> control Layer. (Is this possible?)

It actually works over UDP.

>     2) Anyone who has done a similar stuff has any advice for us? (Not
> in negative :-))

I guess everything is in place - just use it.

>     3) Is there any documentation or RFC available which talks of
> (Ethernet) connectivity at LLC layer? 
>
> Thanks and Best Regards,
> C.R.Srivatsan 
>     
>
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of
> u-boot-users-request at lists.sourceforge.net
> Sent: Wednesday, November 24, 2004 8:43 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: U-Boot-Users digest, Vol 1 #1106 - 13 msgs
>
> Send U-Boot-Users mailing list submissions to
> 	u-boot-users at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/u-boot-users
> or, via email, send a message with subject or body 'help' to
> 	u-boot-users-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> 	u-boot-users-admin at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of U-Boot-Users digest..."
>
>
> Today's Topics:
>
>    1. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Friedrich, Lars)
>    2. question on drive (zhonglei)
>    3. boot problem (Alessio Raccis)
>    4. Re: question on drive (Marc Leeman)
>    5. boot problem (Alessio Raccis)
>    6. R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 (Paolo
> Broggini)
>    7. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)
>    8. Re: boot problem (Wolfgang Denk)
>    9. Re: question on drive (Wolfgang Denk)
>   10. Re: question on drive (Marc Leeman)
>   11. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Paugam Luc)
>   12. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Steven Scholz)
>   13. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)

[...]

> ****************************************************************************

Do you really think it neccessary to include the _whole digest mail_
in a question introducing a new thread?  Please think about that in
the future, even if it takes a few more keystrokes.

Cheers
  Detlev

-- 
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp."

[U-Boot-Users] CLI over Ethernet

[Srivatsan]

Hi all,

    Thanks for the reply Mr.Detlev Zundel.

    There is indeed a requirement to have CLI over Ethernet using LLC. I
wanted to know the best mechanism to provide CLI over Ethernet (Whether
it is through UDP or through LLC). If it uses UDP then uboot already
provides me with one alternatively if it uses LLC then it has to be
rewritten.

    If any one has tried out CLI over Ethernet using LLC or if anyone
has done a study on LLC, then please share your experiences with me. 

    I have one question to the uboot's design team, why was UDP chosen
for CLI on Ethernet?     

With Thanks and Best Regards,
C.R.Srivatsan

    

-----Original Message-----
From: Detlev Zundel [mailto:dzu at denx.de] 
Sent: Thursday, November 25, 2004 10:22 PM
To: Srivatsan
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] CLI over Ethernet

Hi Srivatsan,

>     Greetings. There is a requirement to provide CLI over Ethernet in
> uboot.

Really?  There is a requirement?  Anyway, check doc/README.NetConsole.

>     1) The CLI works over LAN (not using TCP/IP) using Logical link
> control Layer. (Is this possible?)

It actually works over UDP.

>     2) Anyone who has done a similar stuff has any advice for us? (Not
> in negative :-))

I guess everything is in place - just use it.

>     3) Is there any documentation or RFC available which talks of
> (Ethernet) connectivity at LLC layer? 
>
> Thanks and Best Regards,
> C.R.Srivatsan 
>     
>
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of
> u-boot-users-request at lists.sourceforge.net
> Sent: Wednesday, November 24, 2004 8:43 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: U-Boot-Users digest, Vol 1 #1106 - 13 msgs
>
> Send U-Boot-Users mailing list submissions to
> 	u-boot-users at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/u-boot-users
> or, via email, send a message with subject or body 'help' to
> 	u-boot-users-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> 	u-boot-users-admin at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of U-Boot-Users digest..."
>
>
> Today's Topics:
>
>    1. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Friedrich, Lars)
>    2. question on drive (zhonglei)
>    3. boot problem (Alessio Raccis)
>    4. Re: question on drive (Marc Leeman)
>    5. boot problem (Alessio Raccis)
>    6. R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 (Paolo
> Broggini)
>    7. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)
>    8. Re: boot problem (Wolfgang Denk)
>    9. Re: question on drive (Wolfgang Denk)
>   10. Re: question on drive (Marc Leeman)
>   11. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Paugam Luc)
>   12. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Steven Scholz)
>   13. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk)

[...]

>
************************************************************************
****

Do you really think it neccessary to include the _whole digest mail_
in a question introducing a new thread?  Please think about that in
the future, even if it takes a few more keystrokes.

Cheers
  Detlev

-- 
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp."




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] CLI over Ethernet

[Wolfgang Denk]

Dear C.R.Srivatsan,

in message <002901c4d5d0$c1447720$4501a8c0@bgcw301> you wrote:
> 
>     There is indeed a requirement to have CLI over Ethernet using LLC. I

This may be a requirement for you, but please understand that it is a
non-requirement for U-Boot.

> wanted to know the best mechanism to provide CLI over Ethernet (Whether
> it is through UDP or through LLC). If it uses UDP then uboot already
> provides me with one alternatively if it uses LLC then it has to be
> rewritten.

I'm not sure if you actually mean what you say and how you say it, or
maybe it's my limited understanding of  the  English  language  which
makes  me  feel somewhat angry: this is free software, and instead of
being thankful for finding a powerful tool for free yoiu come up with
semi-mandatory staments like "there is a requirement" or "it  has  to
be  rewritten." I would not like this tone if I was your subordinate,
which I definitely am not.

This is a free software poroject, so if you want to see  it  extended
you can either cointribute yourself by submitting patches, or you can
hire  someone  to  implement  what you want, but please do not expect
that everybody on this list starts hacking just because you feel  you
have a requirement.

>     I have one question to the uboot's design team, why was UDP chosen
> for CLI on Ethernet?     

Why not? UDP is a common standard  protocol.  You  can  use  existing
standard tools to receive and send UDP messages (see netcat). Most of
all,  this  way  the  implementation  is compatible to the netconsole
implementation used by Linux, so we have a standard console  protocol
for both U-Boot and Linux.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A great many people think they are thinking when they are merely re-
arranging their prejudices."                          - William James

[U-Boot-Users] CLI over Ethernet

[Srivatsan]

Hi all.

    May be I have been got wrong. Please excuse me for that. I have been
a member for this group for about a month and I have also seen the mail
transactions. I must say I know for sure that It's not for requirements
alone that this group is being used and also no one is subordinate to
anyone in any open source(leave alone uboot) mailing list. 

   Also I haven't asked for particular CLI (requirement with LLC) to be
developed and given to me. What I have asked is the advantage of having
CLI over Ethernet using LLC? 

Had I mentioned requirement for the group or the code has to rewritten
by uboot group which I know is ethically wrong then I would have made a
mistake. But I just required all your help to give me a head start with
the available resources for my problem.

This group is not for showing emotions.


With Best Regards,
C.R.Srivatsan




----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Monday, November 29, 2004 1:57 PM
To: Srivatsan
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] CLI over Ethernet 

Dear C.R.Srivatsan,

in message <002901c4d5d0$c1447720$4501a8c0@bgcw301> you wrote:
> 
>     There is indeed a requirement to have CLI over Ethernet using LLC.
I

This may be a requirement for you, but please understand that it is a
non-requirement for U-Boot.

> wanted to know the best mechanism to provide CLI over Ethernet
(Whether
> it is through UDP or through LLC). If it uses UDP then uboot already
> provides me with one alternatively if it uses LLC then it has to be
> rewritten.

I'm not sure if you actually mean what you say and how you say it, or
maybe it's my limited understanding of  the  English  language  which
makes  me  feel somewhat angry: this is free software, and instead of
being thankful for finding a powerful tool for free yoiu come up with
semi-mandatory staments like "there is a requirement" or "it  has  to
be  rewritten." I would not like this tone if I was your subordinate,
which I definitely am not.

This is a free software poroject, so if you want to see  it  extended
you can either cointribute yourself by submitting patches, or you can
hire  someone  to  implement  what you want, but please do not expect
that everybody on this list starts hacking just because you feel  you
have a requirement.

>     I have one question to the uboot's design team, why was UDP chosen
> for CLI on Ethernet?     

Why not? UDP is a common standard  protocol.  You  can  use  existing
standard tools to receive and send UDP messages (see netcat). Most of
all,  this  way  the  implementation  is compatible to the netconsole
implementation used by Linux, so we have a standard console  protocol
for both U-Boot and Linux.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A great many people think they are thinking when they are merely re-
arranging their prejudices."                          - William James




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] CLI over Ethernet

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
> Of Srivatsan
> Sent: Monday, November 29, 2004 4:15 AM
> To: wd at denx.de
> Cc: u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] CLI over Ethernet
>
> Hi all.

[snip]

>    Also I haven't asked for particular CLI (requirement with
> LLC) to be developed and given to me. What I have asked is
> the advantage of having CLI over Ethernet using LLC?

Nobody has done CLI over LLC for u-boot.  U-boot does support CLI over
UDP/IP/ethernet frames.  The conclusion is that to the current users of
u-boot, there is no advantage of CLI over LLC compared to CLI over
ethernet frames.

LLC isn't used much for 802.3 framing.  It has added complexity with no
obvious practical benefit.  I personally don't see any advantage of
using it and emperical evidence (e.g. not many are using it) would tend
to indicate others agree with my assessment.

For you with a requirement to do CLI over LLC, the equation is different
(unless you can talk your client into using "ethernet" 802.3 frames ;-).
Fortunately you have the source so you can do whatever CLI you wish over
any transport you care to write.  <applause>Open Source is
great.</applause>

gvb

[snip]

> With Best Regards,
> C.R.Srivatsan

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] CLI over Ethernet

[Detlev Zundel]

Hi Srivatsan,

> Had I mentioned requirement for the group or the code has to rewritten
> by uboot group which I know is ethically wrong then I would have made a
> mistake. But I just required all your help to give me a head start with
> the available resources for my problem.

Don't worry - It was simply kind of amusing that you told us "there is
a requirement to support ...." without the "in our project" part that
I expected.  Lets get back to (hopefully) solid facts.

>    Also I haven't asked for particular CLI (requirement with LLC) to be
> developed and given to me. What I have asked is the advantage of having
> CLI over Ethernet using LLC? 

This is an interesting question and probably you have an answer for
us?  Reading up on LLC I am not really sure what a CLI implementation
would give us - despite the need for a completely separate set of
tools to work with this protocol.  Using UDP (belonging to the IP
family) we can simply use the heapload of utilities available -
especially "netcat" comes to mind.

The netconsole support was written with this in mind to support (as
Wolfgang said) a seamless networking console for the U-Boot / Linux
combination.  The Linux netconsole support predates the netconsole in
U-Boot so it was clear that we would go for compatibility with this
implementation.

> This group is not for showing emotions.

[complete quote snipped]

It is also not for posting complete quotes.  Please try to understand
that it is a waste of bandwidth and of our time to include these
completely useless text parts.  I can always look up the old mails if
I want to see these bits - E-Mail can be very efficient so please try
to use it in this spirirt - even if this entails the 15 minutes it
takes to read the netiquette.

Cheers
  Detlev

-- 
Once the  implementation is  up and running,  it is still a trick to keep it
running.  In a normal,  closed implementation,  this is not a problem;  in a
system with metaobject protocols [..] there is the potential for spectacular
failure modes if certain situations are not properly anticipated.
                                       -- The Art of the Metaobject Protocol

[U-Boot-Users] Uboot Netconsole support

[Srivatsan]

Hi all,

Thanks for the active support everyone has provided me with. 

We are trying to use Uboot on MPC8280. In our case Serial port,
eventhough it is available, can't be used for CLI / as a console port
for dumping uboot's log messages.

The next alternative is Ethernet. I had downloaded uboot ver 1.1.1 but I
am not able to find Readme.Netconsole in the doc directory. Does uboot
1.1.1 provide support for Netconsole? Are there any patches available
for uboot to run Netconsole?

Also we have a requirement to put log messages on Ethernet (on uboot
also). These messages must be put very early, even before the IP comes
up. Is our requirement possible by using the current uboot as is or do
we have to modify the uboot code for the changes?

A trivial issue,
1) I went thro uboot.sourceforge.net, there was uboot ver1.0 only
present(activity percentile was 51.2%)
2) I went to the sourceforge site thro denx.de site and got uboot, the
version shown is uboot1.1.1.(activity percentile 98.3%)

Why is this difference? What is the latest version of uboot released and
where can I get it?

Thanks for all your understanding,
C.R.Srivatsan



********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] Uboot Netconsole support

[Wolfgang Denk]

In message <000e01c4e807$fc2ed800$4501a8c0@bgcw301> you wrote:
> 
> The next alternative is Ethernet. I had downloaded uboot ver 1.1.1 but I
> am not able to find Readme.Netconsole in the doc directory. Does uboot
> 1.1.1 provide support for Netconsole? Are there any patches available

As you already found out it does not contain this feature.

> for uboot to run Netconsole?

No, ther eare no patches. There is a current  version  (top  of  CVS)
which includes this so no patches are needed.

> Also we have a requirement to put log messages on Ethernet (on uboot
> also). These messages must be put very early, even before the IP comes

What exactly do you mean "before the IP comes up"?

> up. Is our requirement possible by using the current uboot as is or do
> we have to modify the uboot code for the changes?

You have to explain what you want to do in such a  way  that  we  can
understand it.

> A trivial issue,
> 1) I went thro uboot.sourceforge.net, there was uboot ver1.0 only

The page reads: "Crunched and crypted init procedure to protect linux
server." This is something else  -  a  completely  different  project
unrelated to "Das U-Boot".

> 2) I went to the sourceforge site thro denx.de site and got uboot, the
> version shown is uboot1.1.1.(activity percentile 98.3%)
> 
> Why is this difference? What is the latest version of uboot released and
> where can I get it?

These are two completely different projects. If you actually  READ  a
bit on the web pages you jump to you might learn the difference.

The last officially released version of U-Boot can be  found  on  the
web  page  at  SF:  it's U-Boot-1.1.1; the current development verion
(1.1.2) is available on the CVS server at SF.


And all of this is information is available by reading a bit  on  the
SF web page and in the mailing list archives.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
place to shift.

[U-Boot-Users] Uboot Netconsole support

[Srivatsan]

Thanks for the reply Mr.Wolfgang.

Correct me if I am wrong.

Our requirement is such that uboot should print (debug) messages while
it is coming up. I do think that the present uboot is doing that but our
requirement is that it must do so on Ethernet console instead of Serial
port. Finally the CLI must start on the Ethernet.

With Best Regards,
C.R.Srivatsan  


-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Wednesday, December 22, 2004 4:36 PM
To: Srivatsan
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Uboot Netconsole support 

In message <000e01c4e807$fc2ed800$4501a8c0@bgcw301> you wrote:
> 
> The next alternative is Ethernet. I had downloaded uboot ver 1.1.1 but
I
> am not able to find Readme.Netconsole in the doc directory. Does uboot
> 1.1.1 provide support for Netconsole? Are there any patches available

As you already found out it does not contain this feature.

> for uboot to run Netconsole?

No, ther eare no patches. There is a current  version  (top  of  CVS)
which includes this so no patches are needed.

> Also we have a requirement to put log messages on Ethernet (on uboot
> also). These messages must be put very early, even before the IP comes

What exactly do you mean "before the IP comes up"?

> up. Is our requirement possible by using the current uboot as is or do
> we have to modify the uboot code for the changes?

You have to explain what you want to do in such a  way  that  we  can
understand it.

> A trivial issue,
> 1) I went thro uboot.sourceforge.net, there was uboot ver1.0 only

The page reads: "Crunched and crypted init procedure to protect linux
server." This is something else  -  a  completely  different  project
unrelated to "Das U-Boot".

> 2) I went to the sourceforge site thro denx.de site and got uboot, the
> version shown is uboot1.1.1.(activity percentile 98.3%)
> 
> Why is this difference? What is the latest version of uboot released
and
> where can I get it?

These are two completely different projects. If you actually  READ  a
bit on the web pages you jump to you might learn the difference.

The last officially released version of U-Boot can be  found  on  the
web  page  at  SF:  it's U-Boot-1.1.1; the current development verion
(1.1.2) is available on the CVS server at SF.


And all of this is information is available by reading a bit  on  the
SF web page and in the mailing list archives.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
place to shift.




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] Uboot Netconsole support

[Wolfgang Denk]

In message <000d01c4e823$3fc8cc40$4501a8c0@bgcw301> you wrote:
> 
> Correct me if I am wrong.

I will.

> Our requirement is such that uboot should print (debug) messages while
> it is coming up. I do think that the present uboot is doing that but our
> requirement is that it must do so on Ethernet console instead of Serial
> port. Finally the CLI must start on the Ethernet.

I'm sorry, but I cannot comment on your  requirements.  How  could  I
know  if  your  description  gives  a  correct representation of your
requirements?

I can only answer  questions  about  U-Boot,  and  I  don't  see  any
question  here.  Also,  I  don't see any indication that you read the
documentation, which is a prerequisite _before_ posting.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn