Re: [U-Boot-Users] weird power-on reset problem
Read your 860 manual Chapter 12. Three times. The difference between a power on reset (PORESET*) and a pushbutton (hardware reset or software induced reset) involves reading the configuration off the data bus and starting the clocks (PLL).
When power is applied, the processor reads the configuration, sets up the PLLs, and lets them stabilize. On a pushbutton reset, the processor does NOT read the configuration and the clocks keep running however they were configured when power was applied.
I would be very suspicious that your PLLs are not stabilizing in time. This would most likely be due to an unstable input clock or possibly due to unstable or noisy power supply voltages.
From the 860 maunual, Chapter 12:
"When PORESET signal is negated, the MODCK values are sampled and internally latched. To ensure proper operation, the PORESET signal should be asserted for a minimum of 3 microseconds."
Question: Does your hardware ensure this?
"When a hard reset event occurs, the MPC860 determines its initial mode of operation by sampling the values present on the data bus (D[0Ð31])..."
Question: Does your hardware ensure the data bus lines are driven properly until after the initial mode of operation is established? Note that the manual says the processor leaves the reset state after PORESET is released _AND_ the PLLs are stable. PLL instability could stretch your start up time, causing problems.
Question: Is your RSTCONF* being driven properly?
gvb
At 02:50 PM 1/17/2003 -0500, bren@sjtu.edu.cn wrote:
We have a very very weird problem. When we power-on our MPC860 board, u-boot will stuck before running in RAM. But once we reset the board with the "reset push button", everything will be fine as long as we DO NOT power-off.
Obviously, there are some differences between power-on reset and internal hardware reset and those differences are where we make some mistakes.
Can anyone help us?
Thanks.
Laudney Ren
-- An expert is one who knows more and more about less and less until he knows absolutely everything about nothing.
This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies.
This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. ***********************************************************************
I am trying to load two boot loaders on to the flash at once. We want to put the vxworks bootloader first, then jump to the beginning of the ppcboot loader at a higher address in the flash when we need to. What parameters do I need to change to to allow this? I found the TEXT_BASE in config.mk. Is there anywhere else?
In message 3E2873F9.5050107@jpl.nasa.gov you wrote:
I am trying to load two boot loaders on to the flash at once. We want to put the vxworks bootloader first, then jump to the beginning of the ppcboot loader at a higher address in the flash when we need to. What
This will not work. PPCBoot / U-Boot expect to find a "virgin" system, i. e. to be started from the reset entry point.
I don't say it can't be done, but you have to understand exactly how the initialization sequence works, and what already has been done by your other boot loader.
I recommend to use just U-Boot, and dump the VxWorks bootloader. U-Boot can boot VxWorks fine, too.
Best regards,
Wolfgang Denk
The problem is that PPCBoot doesn't support the rsh method of booting kernels, so we are stuck w/ tftpboot. We can't use that for our vxworks kernels.
Wolfgang Denk wrote:
In message 3E2873F9.5050107@jpl.nasa.gov you wrote:
I am trying to load two boot loaders on to the flash at once. We want to put the vxworks bootloader first, then jump to the beginning of the ppcboot loader at a higher address in the flash when we need to. What
This will not work. PPCBoot / U-Boot expect to find a "virgin" system, i. e. to be started from the reset entry point.
I don't say it can't be done, but you have to understand exactly how the initialization sequence works, and what already has been done by your other boot loader.
I recommend to use just U-Boot, and dump the VxWorks bootloader. U-Boot can boot VxWorks fine, too.
Best regards,
Wolfgang Denk
In message 3E288496.3090600@jpl.nasa.gov you wrote:
The problem is that PPCBoot doesn't support the rsh method of booting kernels, so we are stuck w/ tftpboot. We can't use that for our vxworks kernels.
Well, I don't know what VxWorks "rsh method" is, but if it _is_ rsh then you need a full TCP/IP stack, while U-Boot comes just with a minimal subset of UDP.
Why cannot you use TFTP? As it is the more primitive thing to do it should be easier, too...
Best regards,
Wolfgang Denk
The problem is that PPCBoot doesn't support the rsh method of booting kernels, so we are stuck w/ tftpboot. We can't use that for our vxworks kernels.
You could try to boot your vxWorks kernels with any of the other boot methods u-boot offers, e.g. tftp, bootp or dhcp.
If you _really_ want to run u-boot as second stage to the vxWorks loader, I suggest you search the archives of this mailing list (and the old ppcboot's list, too) for tips on this issues. You already found TEXT_BASE, you should also check CONFIG_MONITOR base and - depending on your platform - you will need to disable the SDRAM initialisations. There are still plenty of things likely to go astray if u-boot and vxWorks disagree on the system setup (memory mapping being the most crucial), so you have to fully understand what each one does. It is only worth the effort as a last resort, as getting everything straight can be time consuming. As usual, you can always hire a more experienced consultant to do it for you.
Regards Marius
participants (4)
-
Jerry Van Baren -
Marius Gröger -
Timothy Canham -
Wolfgang Denk