Re: [Openocd-development] MIPS (Big Endian) Questions
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 big-endian hardware cores, the TAP register is always little-endian and the patch is necessary. - David On 03/18/2011 02:02 AM, Øyvind Harboe wrote: Hi, thanks for working on this! Could you post this patch once it's ready to be committed in a separate thread? It's not entirely clear from what you write whether you consider the change appropriate for the master branch or not. Not everything that makes it work in my case should be committed to master branch Sometimes we(openocd maintainers) let patches slip between the cracks(which is why I post any outstanding patches? posts every once in a while). Thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS (Big Endian) Questions
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.
https://lists.berlios.de/pipermail/openocd-development/2009-September/010308.html
mips_m4k_bulk_write_memory was designed to write large files to RAM. I use it to
load RAM boot loaders. The value of 128 is arbitrarily large compared to the mww
command.
Without the patch below, mww and mdw do not work and my DDR setup also fails.
With the patch it works.
- David
src/target/mips_m4k.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/target/mips_m4k.c b/src/target/mips_m4k.c
index 8afee9c..965f326 100644
--- a/src/target/mips_m4k.c
+++ b/src/target/mips_m4k.c
@@ -864,6 +864,28 @@ static int mips_m4k_read_memory(struct target *target,
uint32_t address,
if (ERROR_OK != retval)
return retval;
+ /* TAP data register is loaded LSB first (little endian) */
+ if (target-endianness == TARGET_BIG_ENDIAN)
+ {
+ uint32_t i, t32;
+ uint16_t t16;
+
+ for (i = 0; i (count * size); i += size)
+ {
+ switch (size)
+ {
+ case 4:
+ t32 = le_to_h_u32(buffer[i]);
+ h_u32_to_be(buffer[i], t32);
+ break;
+ case 2:
+ t16 = le_to_h_u16(buffer[i]);
+ h_u16_to_be(buffer[i], t16);
+ break;
+ }
+ }
+ }
+
return ERROR_OK;
}
@@ -889,6 +911,28 @@ static int mips_m4k_write_memory(struct target *target,
uint32_t address,
if (((size == 4) (address 0x3u)) || ((size == 2) (address
0x1u)))
return ERROR_TARGET_UNALIGNED_ACCESS;
+ /* TAP data register is loaded LSB first (little endian) */
+ if (target-endianness == TARGET_BIG_ENDIAN)
+ {
+ uint32_t i, t32;
+ uint16_t t16;
+
+ for (i = 0; i (count*size); i += size)
+ {
+ switch (size)
+ {
+ case 4:
+ t32 = be_to_h_u32(buffer[i]);
+ h_u32_to_le(buffer[i], t32);
+ break;
+ case 2:
+ t16 = be_to_h_u16(buffer[i]);
+ h_u16_to_le(buffer[i], t16);
+ break;
+ }
+ }
+ }
+
/* if noDMA off, use DMAACC mode for memory write */
if (ejtag_info-impcode EJTAG_IMP_NODMA)
return mips32_pracc_write_mem(ejtag_info, address, size, count,
(void *)buffer);
On 03/17/2011 08:45 AM, Drasko DRASKOVIC wrote:
Hi all,
I have few questions regarding MIPS and endianess :
1) In openocd/src/target/mips_m4k.c we can see that target endianess
is checked and treated only mips_m4k_bulk_write_memory() in and not
mips_m4k_write_memory() and mips_m4k_read_memory(). Why is this so ?
(It leads to wrong SDRAM setup, as mww and mdw commands make no sense
in my case, because mips_m4k_write_memory() is called and my taget is
big endian).
2) When is mips_m4k_bulk_write_memory() actually called ? Obviously
from my tests - not always. I can see it called when I am trying to
load bigger files into SDRAM, but for smaller directly
mips_m4k_write_memory() is called (and thus endianess is never
treated). How does this fast_write actually works in MIPS case ?
3) Can we conclude based on this that big endian targets for MIMPS are
not supported in the current OpenOCD implementation ? Did anyone had
sucess running OpenOCD eith big endian target and how is it done in
this case, having in mind problems I pointed out.
Best regards,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
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 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 PLL settings are intentionally set to a lowest common value for all boards. If PLL and DDR settings are board-specific then it is my understanding that entire reset-init script should be removed from the target script. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
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 0xb805 0x000f40a3 # reset val + CPU:3 DDR:3 AHB:0
mww 0xb805 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 0xb805 0x800f0080 # set sw_update bit
mww 0xb8050008 0# clear reset_switch bit
mww 0xb805 0x800f00e8 # clr pwrdwn bypass
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
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 by the debugger.
I used the floowing commandline for my test:
openocd -f interface/olimex-jtag-tiny.cfg -f ./ar71xx.cfg
And here is the successful image_load command:
telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
load_image /tftpboot/mips/ar7/redboot-ram.bin 0xa050
mips32_pracc_fastdata_xfer using 0xa060 for write handler
254216 byte written at address 0xa050
downloaded 254216 byte in 2.620105s
- David
Øyvind Harboe wrote:
Would you mind contributing this script to the OpenOCD target library?
Your explanations in this email would then be a comment inside
this config script.
Note that you do not need a separate file for the reset init sequence,
you can include it directly in a single config file, search for examples
on this in other config files shipped with OpenOCD
Also, it is good form to split out the interface and target config script
in separate files. You can specify multiple config file son the openocd
command line:
openocd -f interface/xxx.cfg -f board/ar71xx.cfg
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 refererence board
+
+jtag_nsrst_delay 100
+jtag_ntrst_delay 100
+
+reset_config trst_and_srst
+
+set CHIPNAME ar71xx
+
+jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 1
+
+set TARGETNAME [format %s.cpu $CHIPNAME]
+target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
+
+$TARGETNAME configure -event reset-init {
+ #setup PLL to lowest common denominator 300/300/150 setting
+ mww 0xb805 0x000f40a3 # reset val + CPU:3 DDR:3 AHB:0
+ mww 0xb805 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
+ mww 0xb805 0x800f0080 # set sw_update bit
+ mww 0xb8050008 0 # clear reset_switch bit
+ mww 0xb805 0x800f00e8 # clr pwrdwn bypass
+ mww 0xb8050008 1 # set clock_switch bit
+ sleep 1 # wait for lock
+
+ # Setup DDR config and flash mapping
+ mww 0xb800 0xefbc8cd0 # DDR cfg cdl val (rst: 0x5bfc8d0)
+ mww 0xb804 0x8e7156a2 # DDR cfg2 cdl val (rst: 0x80d106a8)
+
+ mww 0xb810 8 # force precharge all banks
+ mww 0xb810 1 # force EMRS update cycle
+ mww 0xb80c 0# clr ext. mode register
+ mww 0xb810 2 # force auto refresh all banks
+ mww 0xb810 8 # force precharge all banks
+ mww 0xb808 0x31 # set DDR mode value CAS=3
+ mww 0xb810 1 # force EMRS update cycle
+ mww 0xb814 0x461b # DDR refresh value
+ mww 0xb818 0x # DDR Read Data This Cycle value (16bit: 0x)
+ mww 0xb81c 0x7 # delay added to the DQS line (normal = 7)
+ mww 0xb820 0
+ mww 0xb824 0
+ mww 0xb828 0
+}
+
+# setup working area somewhere in RAM
+$TARGETNAME configure -work-area-phys 0xa060 -work-area-size 0x2
+
+# serial SPI capable flash
+# flash bank driver base size chip_width bus_width
+
+init
+reset init
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
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 refererence board
+
+jtag_nsrst_delay 100
+jtag_ntrst_delay 100
+
+reset_config trst_and_srst
+
+set CHIPNAME ar71xx
+
+jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 1
+
+set TARGETNAME [format %s.cpu $CHIPNAME]
+target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
+
+$TARGETNAME configure -event reset-init {
+ #setup PLL to lowest common denominator 300/300/150 setting
+ mww 0xb805 0x000f40a3 # reset val + CPU:3 DDR:3 AHB:0
+ mww 0xb805 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
+ mww 0xb805 0x800f0080 # set sw_update bit
+ mww 0xb8050008 0# clear reset_switch bit
+ mww 0xb805 0x800f00e8 # clr pwrdwn bypass
+ mww 0xb8050008 1# set clock_switch bit
+ sleep 1 # wait for lock
+
+ # Setup DDR config and flash mapping
+ mww 0xb800 0xefbc8cd0 # DDR cfg cdl val (rst: 0x5bfc8d0)
+ mww 0xb804 0x8e7156a2 # DDR cfg2 cdl val (rst: 0x80d106a8)
+
+ mww 0xb810 8# force precharge all banks
+ mww 0xb810 1# force EMRS update cycle
+ mww 0xb80c 0# clr ext. mode register
+ mww 0xb810 2# force auto refresh all banks
+ mww 0xb810 8# force precharge all banks
+ mww 0xb808 0x31 # set DDR mode value CAS=3
+ mww 0xb810 1# force EMRS update cycle
+ mww 0xb814 0x461b # DDR refresh value
+ mww 0xb818 0x # DDR Read Data This Cycle value
(16bit: 0x)
+ mww 0xb81c 0x7 # delay added to the DQS line (normal =
7)
+ mww 0xb820 0
+ mww 0xb824 0
+ mww 0xb828 0
+}
+
+# setup working area somewhere in RAM
+$TARGETNAME configure -work-area-phys 0xa060 -work-area-size 0x2
+
+# serial SPI capable flash
+# flash bank driver base size chip_width bus_width
+
+init
+reset init
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] proposed FASTDATA bulk write optimization for mips_m4k file transfers
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
M2399 src/target/mips32_pracc.c
M2399 src/target/mips_ejtag.h
M2399 src/target/mips32_pracc.h
M2399 src/target/mips_m4k.c
Summary:
Bulk transfers are currently done with word accesses using the PrAcc data
register. This optimization uses a working-area, if available, to load a
download routine into ram. The download routine uses EJTAG FASTDATA transfers
to transfer the data. This greatly decreases load times because:
- code fetches are no longer through the PrAcc register, the code is executing
in ram.
- stack is also in the working-area
- Use of only the FASTDATA register minimizes JTAG access.
- the call to jtag_execute_queue() is made only after building the entire
buffer transfer queue.
The idea is taken from the xscale debug_handler loaded into a mini instruction
cache. The mips_m4k does not have a convenient place to load a download routine
like the xscale's mini IC. Instead this patch has been tested with a
working-area in system ram. This requires that the external memory controller be
initialized, most commonly in a board script. The alternative is to lock enough
ways in the instruction cache to make an internal code area. But the system ram
approach is simpler and allows full use of the cache for the program under
debugging.
If a working area is not defined, the code will work as before; bulk writes will
issue a series of word writes that uses the PrAcc data register.
This only affects bulk memory writes; byte, short and word accesses still use
the PrAcc data register.
There is support for FASTDATA bulk reads. However, there is currently no
bulk_read_memory equivalent for bulk_write_memory.
I have probably missed some problems with this approach or it's methods. Still
this code builds and runs and the result is file transfers times decrease
dramatically.
load_image boot-ram.bin 0xa050
mips32_pracc_fastdata_xfer using 0xa0001000 for write handler
253424 byte written at address 0xa050
downloaded 253424 byte in 3.110119s
- David
Index: src/target/mips32.h
===
--- src/target/mips32.h (revision 2399)
+++ src/target/mips32.h (working copy)
@@ -78,6 +78,7 @@
#define MIPS32_OP_ADDI 0x08
#define MIPS32_OP_AND 0x24
#define MIPS32_OP_COP0 0x10
+#define MIPS32_OP_JR 0x08
#define MIPS32_OP_LUI 0x0F
#define MIPS32_OP_LW 0x23
#define MIPS32_OP_LBU 0x24
@@ -104,6 +105,7 @@
#define MIPS32_B(off) MIPS32_BEQ(0, 0, off)
#define MIPS32_BEQ(src,tar,off)MIPS32_I_INST(MIPS32_OP_BEQ,
src, tar, off)
#define MIPS32_BNE(src,tar,off)MIPS32_I_INST(MIPS32_OP_BNE,
src, tar, off)
+#define MIPS32_JR(reg) MIPS32_R_INST(0, reg, 0, 0, 0,
MIPS32_OP_JR)
#define MIPS32_MFC0(gpr, cpr, sel) MIPS32_R_INST(MIPS32_OP_COP0,
MIPS32_COP0_MF, gpr, cpr, 0, sel)
#define MIPS32_MTC0(gpr,cpr, sel) MIPS32_R_INST(MIPS32_OP_COP0,
MIPS32_COP0_MT, gpr, cpr, 0, sel)
#define MIPS32_LBU(reg, off, base) MIPS32_I_INST(MIPS32_OP_LBU, base, reg,
off)
Index: src/target/mips_ejtag.c
===
--- src/target/mips_ejtag.c (revision 2399)
+++ src/target/mips_ejtag.c (working copy)
@@ -4,6 +4,8 @@
* *
* Copyright (C) 2008 by David T.L. Wong *
* *
+ * Copyright (C) 2009 by David N. Claffey dnclaf...@gmail.com *
+ * *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
@@ -146,6 +148,46 @@
return ERROR_OK;
}
+int mips_ejtag_fastdata_scan(mips_ejtag_t *ejtag_info, int write, uint32_t
*data)
+{
+ jtag_tap_t *tap;
+ tap = ejtag_info-tap;
+
+ if (tap==NULL)
+ return ERROR_FAIL;
+
+ scan_field_t fields[2];
+ uint8_t spracc = 0;
+ uint8_t t[4] = { 0,0,0,0 };
+
+ /* fastdata 1-bit register */
+ fields[0].tap = tap;
+ fields[0].num_bits = 1;
+ fields[0].out_value = spracc;
+ fields[0].in_value = NULL;
+
+ /* processor access data register 32 bit */
+ fields[1].tap = tap;
+ fields[1].num_bits = 32;
+ fields[1].out_value = t;
+
+ if (write)
+ {
+ fields[1].in_value = NULL;
+
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
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 will touch this code. - David Nico Coesel wrote: I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. If the PIC32 catches on you should see more MIPS experts. offtopic anti-PIC rant deleted So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips32 big endian fix
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 target will be consistent with other targets in the use of the -endian option. 2. as Zach said why require an external tool manage the conversion? Can OpenOCD reasonably offer such support built-in? For little endian targets, the patch is transparent. For big endian targets it removes the confusion and offers built-in native file support. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips32 big endian fix
Nico, You are correct, target.c modifies for endianness. This is helpful when I set openocd to -endian big; it sets the word order for mw and md commands to the same endianness as the binary files I want to load. The problem is the mips_m4k target does not adjust for endianness like the xscale target does. My board is a Atheros ar71xx with a MIPS 24Kc hardcore. The cpu endianness cannot be changed and there is no other endianness in the SoC. The special registers read and write correctly when I configure openocd in little endian mode. When I saw the discrepancy I thought, I have a big endian target, why should I not set -endian big. So as a fix, I followed the practice in src/target/xscale.c:xscale_send() where word order is swapped depending on target-endianness. I can now read/write the special registers correctly and download a binary from my toolchain 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] mips32 big endian fix On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Claffey Sent: donderdag 11 juni 2009 23:18 To: openocd-development Subject: [Openocd-development] mips32 big endian fix 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 word order loaded into memory. The EJTAG processor access data register (PrAcc) is little endian regardless of the CPU endianness; it is always loaded LSB first. This is confirmed by the fact that mips_ejtag_drscan_32() uses buf_set_u32() to load the scan field; buf_set_u32() is a little-endian formatter. For big endian targets, data buffers have to be modified so the LSB of each u32 or u16 is at the lower (first) memory location. The attached patch for src/target/mips_m4k.c fixes the problem. Included is a patch for src/target/mips_ejtag.c that fixes the case of a big endian host. Again it is related to PrAcc. If the drscan out_value word order is set using buf_set_u32() then it makes sense to also fixup the in_value with buf_get_u32(); a symmetry argument. This has no affect on little endian hosts. David, I strongly doubt your patch is required. AFAIK OpenOCD already modifies the loaded data for correct endianess at a higher level. Secondly I think endianess conversions should not be done inside a target specific file. I'm using OpenOCD with a MIPS target (AU1100) as well which is also big endian. I've configured OpenOCD to use little endian mode and that seems to be the proper setting. A thing to look out for is that the MIPS EJTAG interface may do the endian conversion for you. Is the order of the special function registers correct when OpenOCD is in little endian mode? This the case with 'my' AU1100 target. You might want to check that first. If the special function registers read correctly in little endian mode then you'll need to modify the endianess of the binary file before loading it with OpenOCD. There are tools to do that. If I'm correct the bootloader Yamon comes with a tool called 'smunge' which can be used to modify the endianess of a file. As you probably noticed, I already committed these changes, but they will be trivial to revert. Please let me know if I should remove them. That said, why require an external tool manage the conversion? Can OpenOCD reasonably offer such support built-in? Zach, In case of the AU1100 the answer is no. The AU1100 SOC is a complete endian mess. For starters: the MIPS core starts in big endian but the external memory controller starts in little endian. This would imply endian conversion depending on the address. Way too complicated. Anyway when I use OpenOCD I can load the binary file (bootloader) without need for byte shuffling. If I use the MacGraigor software I need to shuffle the data first. I would like to hear from David first before a final judgement about his patches is made. I'm curious about the target he is working on. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] mips32 bug in target examined wrapper
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.c 2009-05-31 09:38:20 UTC (rev 1961)
+++ trunk/src/target/mips32.c 2009-05-31 09:38:43 UTC (rev 1962)
@@ -346,9 +346,9 @@
{
mips32_common_t *mips32 = target-arch_info;
- if (!target-type-examined)
+ if (target_was_examined(target))
{
- target-type-examined = 1;
+ target_set_examined(target);
/* we will configure later */
mips32-bp_scanned = 0;
and the fix:
Index: src/target/mips32.c
===
--- src/target/mips32.c (revision 2201)
+++ src/target/mips32.c (working copy)
@@ -346,7 +346,7 @@
{
mips32_common_t *mips32 = target-arch_info;
- if (target_was_examined(target))
+ if (!target_was_examined(target))
{
target_set_examined(target);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] mips32 big endian fix
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 word order loaded into memory.
The EJTAG processor access data register (PrAcc) is little endian regardless of
the CPU endianness; it is always loaded LSB first. This is confirmed by the fact
that mips_ejtag_drscan_32() uses buf_set_u32() to load the scan field;
buf_set_u32() is a little-endian formatter. For big endian targets, data buffers
have to be modified so the LSB of each u32 or u16 is at the lower (first) memory
location.
The attached patch for src/target/mips_m4k.c fixes the problem.
Included is a patch for src/target/mips_ejtag.c that fixes the case of a big
endian host. Again it is related to PrAcc. If the drscan out_value word order
is set using buf_set_u32() then it makes sense to also fixup the in_value with
buf_get_u32(); a symmetry argument. This has no affect on little endian hosts.
Index: ./src/target/mips_ejtag.c
===
--- ./src/target/mips_ejtag.c (revision 2201)
+++ ./src/target/mips_ejtag.c (working copy)
@@ -118,7 +118,7 @@
if (tap==NULL)
return ERROR_FAIL;
scan_field_t field;
- u8 t[4];
+ u8 t[4], r[4];
int retval;
field.tap = tap;
@@ -126,7 +126,7 @@
field.out_value = t;
buf_set_u32(field.out_value, 0, field.num_bits, *data);
- field.in_value = (u8*)data;
+ field.in_value = r;
@@ -139,6 +136,8 @@
return retval;
}
+ *data = buf_get_u32(field.in_value, 0, 32);
+
keep_alive();
return ERROR_OK;
Index: ./src/target/mips_m4k.c
===
--- ./src/target/mips_m4k.c (revision 2201)
+++ ./src/target/mips_m4k.c (working copy)
@@ -732,6 +732,7 @@
{
mips32_common_t *mips32 = target-arch_info;
mips_ejtag_t *ejtag_info = mips32-ejtag_info;
+ int retval;
LOG_DEBUG(address: 0x%8.8x, size: 0x%8.8x, count: 0x%8.8x, address, size, count);
@@ -755,22 +756,46 @@
case 1:
/* if noDMA off, use DMAACC mode for memory read */
if(ejtag_info-impcode EJTAG_IMP_NODMA)
-return mips32_pracc_read_mem(ejtag_info, address, size, count, (void *)buffer);
+retval = mips32_pracc_read_mem(ejtag_info, address, size, count, (void *)buffer);
else
-return mips32_dmaacc_read_mem(ejtag_info, address, size, count, (void *)buffer);
+retval = mips32_dmaacc_read_mem(ejtag_info, address, size, count, (void *)buffer);
+ break;
default:
LOG_ERROR(BUG: we shouldn't get here);
exit(-1);
break;
}
- return ERROR_OK;
+ /* TAP data register is loaded LSB first (little endian) */
+ if (target-endianness == TARGET_BIG_ENDIAN)
+ {
+ u32 i, t32;
+ u16 t16;
+
+ for(i = 0; i (count*size); i += size)
+ {
+ switch(size)
+ {
+case 4:
+ t32 = le_to_h_u32(buffer[i]);
+ h_u32_to_be(buffer[i], t32);
+ break;
+case 2:
+ t16 = le_to_h_u16(buffer[i]);
+ h_u16_to_be(buffer[i], t16);
+ break;
+ }
+ }
+ }
+
+ return retval;
}
int mips_m4k_write_memory(struct target_s *target, u32 address, u32 size, u32 count, u8 *buffer)
{
mips32_common_t *mips32 = target-arch_info;
mips_ejtag_t *ejtag_info = mips32-ejtag_info;
+ int retval;
LOG_DEBUG(address: 0x%8.8x, size: 0x%8.8x, count: 0x%8.8x, address, size, count);
@@ -793,10 +818,6 @@
case 2:
case 1:
/* if noDMA off, use DMAACC mode for memory write */
- if(ejtag_info-impcode EJTAG_IMP_NODMA)
-mips32_pracc_write_mem(ejtag_info, address, size, count, (void *)buffer);
- else
-mips32_dmaacc_write_mem(ejtag_info, address, size, count, (void *)buffer);
break;
default:
LOG_ERROR(BUG: we shouldn't get here);
@@ -804,7 +825,35 @@
break;
}
- return ERROR_OK;
+ /* TAP data register is loaded LSB first (little endian) */
+ if (target-endianness == TARGET_BIG_ENDIAN)
+ {
+ u32 i, t32;
+ u16 t16;
+
+ for(i = 0; i (count*size); i += size)
+ {
+ switch(size)
+ {
+case 4:
+ t32 = be_to_h_u32(buffer[i]);
+ h_u32_to_le(buffer[i], t32);
+ break;
+case 2:
+ t16 = be_to_h_u16(buffer[i]);
+ h_u16_to_le(buffer[i], t16);
+ break;
+ }
+ }
+ }
+
+ if(ejtag_info-impcode EJTAG_IMP_NODMA)
+ retval = mips32_pracc_write_mem(ejtag_info, address, size, count, (void *)buffer);
+ else
+ retval = mips32_dmaacc_write_mem(ejtag_info, address, size, count, (void *)buffer);
+
+
+ return retval;
}
int mips_m4k_register_commands(struct command_context_s *cmd_ctx)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
