[U-Boot-Users] CLI over Ethernet

25 Nov 2004

      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@lists.sourceforge.net] On Behalf Of
u-boot-users-request@lists.sourceforge.net
Sent: Wednesday, November 24, 2004 8:43 PM
To: u-boot-users@lists.sourceforge.net
Subject: U-Boot-Users digest, Vol 1 #1106 - 13 msgs
Send U-Boot-Users mailing list submissions to
    u-boot-users@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@lists.sourceforge.net
You can reach the person managing the list at
    u-boot-users-admin@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@rcs-9000.com
Subject: Re: [U-Boot-Users] question on drive
Cc: u-boot-users@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@lists.sourceforge.net
[mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di
Friedrich,
...
Lars
Inviato: mercoledì, 24. novembre 2004 08:47
A: u-boot-users@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@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@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@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@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@denx.de
If God had a beard, he'd be a UNIX programmer.

--__--__--

Message: 9
To: Marc Leeman marc.leeman@gmail.com
Cc: zhonglei@rcs-9000.com, u-boot-users@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@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@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@lists.sourceforge.net
> [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang
> Denk
> Sent: mardi 23 novembre 2004 17:43
> To: Steven Scholz
> Cc: u-boot-users@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@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@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@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@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@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@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.

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