For the record ... I think the key open issue here is
the need to refactor target code so that we have more
general support for reset-without-SRST, using event
handlers that know how to do that via JTAG (such as
by forcing a watchdog reset). Maybe in 0.4.x ...
Once that happens, the other open bi
On Monday 29 June 2009, Øyvind Harboe wrote:
> I'm not a believer in a generic scheme to "discover" how
> to set up a target configuration script.
>
> Really each bitstream would be a different board+target
> configuration under the current OpenOCD thinking.
Different board.cfg or user.cfg is wha
On Mon, Jun 29, 2009 at 9:32 PM, David Brownell wrote:
> On Monday 29 June 2009, Ųyvind Harboe wrote:
>> Really what is required is a target .cfg file for *each* FPGA bit
>> file, just like a .cfg file is required for each target.
>
> You mean, to handle cases like the config bitstream
> linking in
On Monday 29 June 2009, Øyvind Harboe wrote:
> Really what is required is a target .cfg file for *each* FPGA bit
> file, just like a .cfg file is required for each target.
You mean, to handle cases like the config bitstream
linking in more TAPs to the one provided by the FPGA
vendor?
Maybe. We h
On Monday 29 June 2009, Øyvind Harboe wrote:
> The "reset" tcl proc really is *very* CPU oriented. It doesn't make
> much sense to talk about resetting an FPGA into the halted
> state
Right, and that's a problem. As I noted earlier, there
need to be reset hooks that kick in at just the TAP la
> ... that's *IF* one task of that FPGA is implementing a CPU.
> (And if it's not one of the FPGAs with on-chip storage for
> that particular config bitstream.)
Really what is required is a target .cfg file for *each* FPGA bit
file, just like a .cfg file is required for each target.
An FPGA screw
On Monday 29 June 2009, Øyvind Harboe wrote:
> On Mon, Jun 29, 2009 at 7:21 PM, David Brownell wrote:
> > On Monday 29 June 2009, Ųyvind Harboe wrote:
> >> The point is that the target configuration script would define
> >> a tcl proc that would use e.g. play svf file.
> >
> > There's a missing hoo
On Mon, Jun 29, 2009 at 7:21 PM, David Brownell wrote:
> On Monday 29 June 2009, Ųyvind Harboe wrote:
>> The point is that the target configuration script would define
>> a tcl proc that would use e.g. play svf file.
>
> There's a missing hook too. No way for a non-target to
> invoke "svf file.nam
On Monday 29 June 2009, Øyvind Harboe wrote:
> The point is that the target configuration script would define
> a tcl proc that would use e.g. play svf file.
There's a missing hook too. No way for a non-target to
invoke "svf file.name" or "xsvf tap.name file.name" during
the reset process.
_
On Mon, Jun 29, 2009 at 12:42 PM, Duane Ellis wrote:
> Ųyvind Harboe wrote:
>>
>> On pondering the configure FPGA vs. reset script
>> problem.
>>
>> How about if the target added new commands, such as
>> "configure FPGA". This would then be distinct from resetting
>> the CPU, but it could still be
Øyvind Harboe wrote:
> On pondering the configure FPGA vs. reset script
> problem.
>
> How about if the target added new commands, such as
> "configure FPGA". This would then be distinct from resetting
> the CPU, but it could still be placed into the .gdbinit sequence.
>
>
Why is this not "pay
On Mon, Jun 29, 2009 at 8:24 AM, David Brownell wrote:
> On Sunday 28 June 2009, Ųyvind Harboe wrote:
>> How about if the target added new commands, such as
>> "configure FPGA". This would then be distinct from resetting
>> the CPU, but it could still be placed into the .gdbinit sequence.
>
> Targ
On Sunday 28 June 2009, Øyvind Harboe wrote:
> How about if the target added new commands, such as
> "configure FPGA". This would then be distinct from resetting
> the CPU, but it could still be placed into the .gdbinit sequence.
Target? What target?
We shouldn't require *debug* support ("targe
On pondering the configure FPGA vs. reset script
problem.
How about if the target added new commands, such as
"configure FPGA". This would then be distinct from resetting
the CPU, but it could still be placed into the .gdbinit sequence.
--
Øyvind Harboe
Embedded software and hardware consulting
So - if we are to turn reset "inside-out" - what commands do we need?
1) ablity to control SRST & TRST externally.
jtag interface assert SIGNALNAME
jtag interface deassert SIGNALNAME
2) Ablity to know SRST & TRST configuration.
set foo [jtag interface cget -trst-srst-con
(I saw Duane is following up on this one and he's
pretty much the expert on it...)
> If I've got an FPGA *not* programmed with a Nios core,
> that model doesn't work. :)
>
> That issue isn't entirely "reset". It's "initialization",
> which is a separable chunk of reset processing. For a
> Nios
On Saturday 27 June 2009, Duane Ellis wrote:
> Today - the C code *controls* and *drives* the reset sequence.
>
> I'm suggesting we turn that inside out - and make the TCL code - drive
> the reset sequence - via commands above.
That's a good direction, I think. Details TBD, but
certainly gettin
>> This avoids switching
>> programming paradigm from procedural to
>> event based, i.e. we could add events until
>> the cows go home and still miss that crucial
>> event for the next target.
>>
>
> I'd call the current reset "events" procedural
> hooks, myself. Heck, they don't even accep
> > Does it seem to you like the reset process is flexible
> > enough yet?
>
> The idea is that those targets where the tcl reset
> proc doesn't cut it would implement their own
> tcl reset proc from scratch.
That seems undesirable when some key improvements can
be more generically available.
Li
On Thu, Jun 25, 2009 at 12:06 AM, David Brownell wrote:
> On Wednesday 24 June 2009, Duane Ellis wrote:
>> > So maybe you can answer this ... What does the "arp_" prefix in
>> > various commands represent?
>> >
>> > "Address Resolution Protocol" was my first reaction ... but
>> > that doesn't seem
On Wednesday 24 June 2009, Duane Ellis wrote:
> > So maybe you can answer this ... What does the "arp_" prefix in
> > various commands represent?
> >
> > "Address Resolution Protocol" was my first reaction ... but
> > that doesn't seem relevant to JTAG. ;)
>
> That name "arp_" was coined by my se
21 matches
Mail list logo
