Hi friends,
Could any one tell me what is the boot sequence of the u-boot.
Thanks in advance
Regards vijay
On Thu, 2004-07-15 at 13:26, u-boot-users-request@lists.sourceforge.net wrote:
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:
- Re: CFG_FLASH_BASE and CFG_MONITOR_BASE question (Frank Young)
- RE: memory allocation (Friedrich, Lars)
- Re: Question about GNU linker usage (Leon KUKOVEC)
- Writing Makefiles.. (Sudhakar Velusamy)
- RE: Q about automatic dram size detection in sdram_init() (Stefan Roese)
- Re: =?ks_c_5601-1987?B?USBhYm91dCBhdXRvbWF0aWMgZHJhbSBzaXplIGRldGVjdGlvbiBpbiBzZHJhbV9pbml0KCk=?= (Wolfgang Denk)
- Re: question about sdram size autodetection in sdram_init() (Wolfgang Denk)
- U-boot with uclinux on Coldfire (Sonia Martinez Baro)
- Re: Unable to send keys inputs from keyboard to u-boot (Wolfgang Denk)
- Re: AT91RM9200 -> UBoot and arm/thumb interworking (Wolfgang Denk)
- Re: Unable to send keys inputs from keyboard to u-boot (Anders Larsen)
- Re: memory allocation (Wolfgang Denk)
- Re: Writing Makefiles.. (Wolfgang Denk)
- Re: Q about automatic dram size detection in sdram_init() (Wolfgang Denk)
--__--__--
Message: 1 From: "Frank Young" young726@hotmail.com To: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] CFG_FLASH_BASE and CFG_MONITOR_BASE question Date: Wed, 14 Jul 2004 22:00:00 -0700
Anyone else can share your success story? I just want to get some clues from the similiar cases.
Thanks!
Frank
From: Wolfgang Denk wd@denx.de To: "Frank Young" young726@hotmail.com CC: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] CFG_FLASH_BASE and CFG_MONITOR_BASE question Date: Thu, 15 Jul 2004 00:41:26 +0200
In message BAY2-F42kIFqFtucwpX000d8fad@hotmail.com you wrote:
Yes, I did try it out. Seems the u-boot works fine and the example application runs fine in SDRAM. But when I tried to load the kernel,
kernel
hangs when early_init (in head_4xx.S) is called. So I want to come back
to
u-boot and double check everything in u-boot is correct.
I think we've been there before. How do you know that the kernel "hangs", and what exactly means "hangs" here?
Don't tell me again that you added some debug code to toggle LED's or write to memory or something like that.
Your "it hangs" may be an "it chrashes because of your debug code" with your debug code, and something completely different without it.
Attach a debugger and find out what's really going on.
In a first step, I recommend to re-read the FAQ section.
BTW, does anyone happen to have early_init problem and solved it? I saw
a
Yes. Many people have posted such problems before, and in all cases I can remember the only problem was some debug code that had been added, or the attempt to use tools (or engineers) that have no idea what virtual memory is.
lot of discussions on the internet. But most of them didn't give a final solution. It doesn't matter if we are using same board or CPU. I just
want
to get some idea of what could be wrong. Any input would be appreciated!
We've been there before. Everything has been said before. follow the advice, or ignore it - your choice. I give up here. I will stop reading this thread and replying to it.
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 about WRITING it first and rationalizing it afterwords? :-) - Larry Wall in 8162@jpl-devvax.JPL.NASA.GOV
MSN Life Events gives you the tips and tools to handle the turning points in your life. http://lifeevents.msn.com
--__--__--
Message: 2 Subject: RE: [U-Boot-Users] memory allocation Date: Thu, 15 Jul 2004 08:19:34 +0200 From: "Friedrich, Lars" lars.friedrich@wago.com To: "U-Boot-Users (E-Mail)" u-boot-users@lists.sourceforge.net
Is there a (good) reason why the mem_alloc_init for ARM (and some other) targets zeroes out the malloc pool?
Paranoia?
That incompetent software developers flood your mailbox?
BTW: the same is done on other architectures, too.
But not for all - so one way or the other, it's not correct. Unless there is less paranoia for certain architectures ;-)
This seems very redundant to me. I removed the memset code and didn't run into any trouble so far, but maybe I was just lucky.
We do a lot of redundand things that help to improve styability ;-)
I consider zeroeing out this memory area as a way to obscure bugs, by allowing faulty code to run nevertheless. I guess it's a thin line between improving stability and catering bad code.
Anyway, I've noted this as 'intended by design' and keep the removal local.
Best regards, Lars Friedrich
--=20
--__--__--
Message: 3 Date: Thu, 15 Jul 2004 08:01:55 +0200 From: Leon KUKOVEC leon.kukovec@ultra.si Organization: Ultra d.o.o. To: SYLee dobest03@empal.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Question about GNU linker usage
Hi SYLee,
SYLee wrote:
[-snip-]
u-boot: depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT) UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | sed -n -e 's/.*(__u_boot_cmd_.*)/-u\1/p'|sort|uniq`;\ $(LD) $(LDFLAGS) $$UNDEF_SYM $(OBJS) \ --start-group $(LIBS) $(PLATFORM_LIBS) --end-group \ -Map u-boot.map -o u-boot
The value of $(LDFLAGS) variable ends "-n" and UNDEF_SYM is undefined symbol name list. Can the undefined symbol names be the non-option argument of gnu ld? According to manual page or info, I haven't found any mention of it.
My understanding is that you very likely do not have OBJDUMP in the PATH or set correctly which is causing UNDEF_SYM not to get defined.
UNDEF_SYMBS actualy expands to -u<symbol_name> which is legal for LDFLAGS.
Try to provide a log that shows how commands are being executed for the u-boot target.
L8rZ.