On Thursday 03 September 2009, David Claffey wrote: > David Brownell wrote: > >> Committed less "init + reset init" which does not belong > >> in target configuration script. > > > > I think the reset-init handler likely belongs in a board > > init script too ... :) > > > > Specifics of DDR and clock setup vary between boards. > > Also, having the "reset init" script recurse into the > > "reset halt" logic can't be correct... > > > > The reset-halt was added because the pll configuration requires a processor > reset for the PLL register settings to latch. The write to 0xb8050008 resets > the > processor.
Reset to latch PLL settings? Odd. One would expect a reset to re-initialize the PLL configuration too! That's how it's done on every other core I've had occasion to look at. Such odd requirements rate a comment. :) Is that software-triggered reset different from SRST? If so, how? What do boot loaders normally do with PLL setup then? Sounds like they look at the settings, and if they're not appropriate they'll "fix" them and reset. Wouldn't OpenOCD do the same? > If reset_halt is not there the processor is not halted after this new > reset. Perhaps there is another way to do this, but it's working for me. The reset sequence is a bit quirky IMO, and not yet up to some things that it needs to handle. There are a lot of flavors of reset, many ways to trigger them, and special cases everywhere. There are event hooks for "reset-assert-pre" and "reset-deassert-post" logic ... the "reset-init" is *way* late. Are you sure "reset-init" is the right hook to use for PLL setup on this core? (src/helper/startup.tcl has an ocd_process_reset script which you might not have come across ... showing the current set of reset events and their invocation sequence.) > The PLL settings are intentionally set to a lowest common value for all > boards. > If PLL and DDR settings are board-specific I think you just said there that they wouldn't normally be the same ... but that there could be a least-common-denominator applied in some cases. Does this core do the usual, and (a) require PLL to get clocks fast enough to run DDR, (b) include some SRAM for boot code to use before DDR is available? If so, it seems reset-assert-pre might benefit from knowing it's prepping for reset-init (and thus should setup the PLL if it's not already done, before one of the resets) vs not (leaving that for the boot loader). > then it is my understanding that > entire reset-init script should be removed from the target script. That's my general assumption, yes. There could be reusable code that provides hooks for board-specific behavior ... but the reset-init script is doing a lot of what first stage of a boot loader does, and that's *extremely* board-specific. These chips have pin/ball configuration, yes? And have clock trees to set up? And other stuff that varies based on how the chip is wired into a particular board? - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
