> 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.
>
> 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.
>
>
> 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.
>
>
>> 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).
>
>
>> 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.
- David
Index: tcl/target/ar71xx.cfg
===================================================================
--- tcl/target/ar71xx.cfg (revision 2663)
+++ tcl/target/ar71xx.cfg (working copy)
@@ -13,16 +13,17 @@
set TARGETNAME [format "%s.cpu" $CHIPNAME]
target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
-$TARGETNAME configure -event reset-init {
+$TARGETNAME configure -event reset-halt-post {
#setup PLL to lowest common denominator 300/300/150 setting
mww 0xb8050000 0x000f40a3 # reset val + CPU:3 DDR:3 AHB:0
mww 0xb8050000 0x800f40a3 # send to PLL
#next command will reset for PLL changes to take effect
mww 0xb8050008 3 # set reset_switch and clock_switch
(resets SoC)
- reset halt # let openocd know that it is in the
reset state
+}
- #initialize_pll
+$TARGETNAME configure -event reset-init {
+ #complete pll initialization
mww 0xb8050000 0x800f0080 # set sw_update bit
mww 0xb8050008 0 # clear reset_switch bit
mww 0xb8050000 0x800f00e8 # clr pwrdwn & bypass
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
