On Thursday 03 September 2009, David Claffey wrote: > > 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. :) > > yes, it's odd. The plls are only reset by power-on reset, not SRST. They > come > up with all the multipliers and dividers set to 1. Changes to the PLL > registers > are only latched when the "reset-switch" is set in software, which causes > > > Is that software-triggered reset different from SRST? If so, how? > > a "full CPU reset" says the data sheet.
And not peripherals ... or does it say? Vendors seem not to make it easy to trigger a full SoC reset from software, short of maybe forcing a watchdog to fire. > > 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? > > The boot loader checks to see if the PLL is in the appropriate state. If so, > it > skips the initialization. The appropriate value is either a user-specific > value > or defaults to a value selected by a speed-step register in the core. So a better solution for OpenOCD might have your reset-halt-post script do the same thing: read that register, and update it only if the PLL settings are still at the default. That way you won't be pessimizing the timings each time you boot; the normal boot code can provide the right ones for the board. > > 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.) > > I see your point. The config script was calling into reset recursively > through > the event handler. I tried a few variations on the idea that the sequence is > in > two steps: first program the pll registers is some event before reset-init, > then > complete the rest in reset-init. > > I kept getting "target not halted" errors until I put the pll setup in a > reset-halt-post handler. I'm guessing the target needs to be halted to send > the > commands. Or at least, it's coded that way. :) There are cores that work either way. Of course, if you write to memory or peripheral registers while the CPU is running, and the code running there isn't prepared for that ... there can be SMP-ish bugs. > >> 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). > > There is no SRAM. Boot code sets up the PLL and DDR in assembly before any RAM > is used (no stack access). So I'd guess it supports boot-from-ROM and boot-from-NOR, but not boot-from-NAND or from other peripherals. At least in terms of the very first stage of booting. Maybe OneNand works too. > >> 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? > > For this SoC most of the "board" is in the silicon except for one x16 DDR > chip, > one SPI flash and the PCI bus. It's highly integrated. The DDR may have a > different density/speed. Maybe that can be a hook, along with the PLL setting > possibly. Hmm, interesting. Your attached patch does look like a good improvement. Gets rid of that nasty recursion. :) A next step would probably be splitting out the PB44 ref board assumptions from the core AR71xx support. Also: the variable you should set is $_TARGETNAME, leading underscore. And don't use [format "%s.cpu" $CHIPNAME] to set it; just "set _TARGETNAME $CHIPNAME.cpu" suffices. The users's guide covers the interop guidelines. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
