[U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #869 - 14 msgs
vijay
g.vijaychakravarthy at gdatech.co.in
Thu Jul 15 17:26:40 CEST 2004
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 at lists.sourceforge.net
wrote:
> 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: CFG_FLASH_BASE and CFG_MONITOR_BASE question (Frank Young)
> 2. RE: memory allocation (Friedrich, Lars)
> 3. Re: Question about GNU linker usage (Leon KUKOVEC)
> 4. Writing Makefiles.. (Sudhakar Velusamy)
> 5. RE: Q about automatic dram size detection in sdram_init() (Stefan Roese)
> 6. Re: =?ks_c_5601-1987?B?USBhYm91dCBhdXRvbWF0aWMgZHJhbSBzaXplIGRldGVjdGlvbiBpbiBzZHJhbV9pbml0KCk=?= (Wolfgang Denk)
> 7. Re: question about sdram size autodetection in sdram_init() (Wolfgang Denk)
> 8. U-boot with uclinux on Coldfire (Sonia Martinez Baro)
> 9. Re: Unable to send keys inputs from keyboard to u-boot (Wolfgang Denk)
> 10. Re: AT91RM9200 -> UBoot and arm/thumb interworking (Wolfgang Denk)
> 11. Re: Unable to send keys inputs from keyboard to u-boot (Anders Larsen)
> 12. Re: memory allocation (Wolfgang Denk)
> 13. Re: Writing Makefiles.. (Wolfgang Denk)
> 14. Re: Q about automatic dram size detection in sdram_init() (Wolfgang Denk)
>
> --__--__--
>
> Message: 1
> From: "Frank Young" <young726 at hotmail.com>
> To: u-boot-users at 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 at denx.de>
> >To: "Frank Young" <young726 at hotmail.com>
> >CC: u-boot-users at 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 at 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 at denx.de
> >What about WRITING it first and rationalizing it afterwords? :-)
> > - Larry Wall in <8162 at 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 at wago.com>
> To: "U-Boot-Users (E-Mail)" <u-boot-users at 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 at ultra.si>
> Organization: Ultra d.o.o.
> To: SYLee <dobest03 at empal.com>
> Cc: u-boot-users at 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.
More information about the U-Boot
mailing list