Hello Øyvind,
The issue is the endianess of the TAP register. If All MIPs targets have a
little-endian TAP register then the patch is a general fix. In the 6/2009
thread, Nico Coesel suggested the Au1100 set to big endian does not have this
problem. For Drasko , myself and others with MIPs bi
Hi Drasko,
I proposed a solution for the MIPS big-endian problem in the past. See
https://lists.berlios.de/pipermail/openocd-development/2009-June/008659.html
The FASTDATA patch was accepted later and included the
mips_m4k_bulk_write_memory() function that corrects for big-endian targets.
http
> 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. T
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" scri
My mistake. Here's the .txt file
Index: tcl/target/ar71xx.cfg
===
--- tcl/target/ar71xx.cfg (revision 0)
+++ tcl/target/ar71xx.cfg (revision 0)
@@ -0,0 +1,58 @@
+# Atheros AR71xx MIPS 24Kc SoC.
+# tested on PB44 refererenc
Hello Øyvind,
I have a sample target config file attached with your suggestions. The config
file was tested with the Atheros reference design "PB44". The testing included
a test with no bootloader. With a running bootloader the PLL and DDR may be
setup at power-up and before the cpu is halted b
Hi Tornado,
I have been using the fastdata patch for months now. I use it to load a RAM
bootloader image onto dead/empty boards. Then I use the bootloader to program
the flash. Without fastdata, RAM loading is too too slow to be useful.
Fastdata requires a working area in RAM to load and execut
The FASTDATA register is part of the EJTAG specification at least back to 3.10
(search for MD00047-2B-EJTAG-SPC-03.10.pdf to see the FASTDATA register).
This patch optimizes any calls to target->type->bulk_write_memory() and I have
only found the call in target.c. I don't know if flash programming
Attached is a proposed bulk write optimization for mips_m4k file transfers. The
motivation was to speed-up image loading on the mips_m4k target to reach similar
transfer times as the xscale target.
Files modified:
M2399 src/target/mips32.h
M2399 src/target/mips_ejtag.c
> In other words: the binary file should be changed for proper endianess
> before loading it. The MIPS implementation in OpenOCD doesn't need to be
> fixed regarding the endianess.
It's true it doesn't need to be fixed to use the memory commands mw and md. But
it helps in two ways:
1. The mips t
chain without modification.
Nico Coesel wrote:
>> -Original Message-
>> From: Zach Welch [mailto:z...@superlucidity.net]
>> Sent: vrijdag 12 juni 2009 10:39
>> To: Nico Coesel
>> Cc: David Claffey; openocd-development
>> Subject: Re: [Openocd-development]
A patch is needed for MIPS big endian (elf32-tradbigmips) targets. Perhaps I'm
the first to test trunk with a MIPS big endian target.
If "-endian big" is not set in target create, the endianess defaults to little.
mw and md commands will still work, but binary file loads will have the
incorrect
The r1962 patch to add a target examined wrapper created a mips bug.
https://lists.berlios.de/pipermail/openocd-svn/2009-May/000746.html
here is the offending hunk:
Modified: trunk/src/target/mips32.c
===
--- trunk/src/target/mips32.
13 matches
Mail list logo
