[U-Boot-Users] CLI over Ethernet
Srivatsan
srivatsan at deccanetworld.com
Thu Nov 25 11:13:27 CET 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 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)
--__--__--
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 at wago.com>
To: <u-boot-users at 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 at RCS-9000.COM>
Reply-To: <zhonglei at RCS-9000.COM>
To: <u-boot-users at 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 at tiscali.it>
To: <u-boot-users at 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 at gmail.com>
Reply-To: Marc Leeman <marc.leeman at 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 at tiscali.it>
To: <u-boot-users at 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 at softool.ch>
To: "Friedrich, Lars" <lars.friedrich at wago.com>,
<u-boot-users at 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 at wago.com>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at 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 at 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 at tiscali.it>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at denx.de>
Subject: Re: [U-Boot-Users] boot problem
Date: Wed, 24 Nov 2004 11:32:35 +0100
In message <001e01c4d205$7e2ca120$cb077c0a at 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 at gmail.com>
Cc: zhonglei at rcs-9000.com, u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at denx.de>
Subject: Re: [U-Boot-Users] question on drive
Date: Wed, 24 Nov 2004 11:30:14 +0100
In message <1f729c4804112401141cd5deb7 at 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 at gmail.com>
Reply-To: Marc Leeman <marc.leeman at 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 at thomson.net>
To: "Wolfgang Denk" <wd at denx.de>,
"Steven Scholz" <steven.scholz at imc-berlin.de>
Cc: <u-boot-users at 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 at 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 at 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 at 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 at imc-berlin.de>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at denx.de>
Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200
Date: Wed, 24 Nov 2004 16:06:46 +0100
In message <41A48489.80203 at 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.
****************************************************************************
More information about the U-Boot
mailing list