Hi Peter, Thanks for your prompt response.
> First of all, please retry this with QEMU built from current git master. > A lot of patches went in a few weeks ago to improve our big-endian support. > We may well still have some bugs, but there doesn't seem much point trying to > diagnose problems in the old code... Good point. I have been using release 2.3.0. Need to try this out. > (1) we don't implement an R4 model at all in QEMU (we do have an R5), > so are you using some out of tree patches for R4 support or are > you trying to run the code on an R5 CPU? I grabbed the R4 init function from Xilinx Qemu repo. Though not quite sure if it is fully implemented/tested to work there or not. > (2) which board model are you using? One in QEMU mainline or an out > of tree one? What is your QEMU command line? It is essentially a completely new board. I started with the vexpress (with A9) as a base reference and had to modify all memory regions, device addresses along with a number of custom device implementations. I am confident about the new device implementations as I have already tested them on yet another board using A9. However, not quite so with the memory regions as R4 uses MPU, and this is the first time I had to use aliased regions for the DRAM. Looking at the line where Qemu crashes trying to run the firmware, it seems to be in the configuration of MPU. As I mentioned earlier, the firmware code has been tested to run on the actual hardware. So, it must be how I am defining the regions in the board model, aliased DRAM as well as ITCM/DTCM. Without the debugging capability I can't put my finger on it. > Regarding gdb, QEMU just provides facilities for reading and writing memory, > so if asking gdb to do a memory dump shows correct data but disassembly does > not, then the problem is at the gdb end (probably a config switch); If I understand correctly, inside the function gen_intermediate_code_internal(...), arm_ldl_code() reads the instruction-bytes according to PC and then disassemble. Initially, the output of this disassembly did not make much sense. It's only after I forced the last parameter (bswap_code) to 1 in the arm_ldl_code() function call that it started reading the instructions properly (execution moved further than before). I was hoping that Qemu will pass this properly read instructions for gdb. If gdb is given just the raw data (i.e. instructions read assuming LE format) then it makes sense. GDB client probably doesn't have any idea that it should interpret them in BE format and defaults to LE. If I open the object file directly in gdb and disassemble, then it already knows the format from the ELF header section and that's why able to read the instruction properly in that case. If this is what is happening, then as you have suggested, one option is to tell gdb client to expect instructions in BE format (config switch). I'll explore this option. Another will be to flip the byte-order before putting it on the gdb server socket. Can you please point me to exactly where gdb is reading these instructions? Thanks & regards, Kaustav -----Original Message----- From: Peter Maydell [mailto:peter.mayd...@linaro.org] Sent: Wednesday, March 16, 2016 7:53 PM To: Paul, Kaustav Kumar <kaustav.p...@hp.com> Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Request for help with Qemu GDB for big-endian instructions (R4) On 16 March 2016 at 10:06, Paul, Kaustav Kumar <kaustav.p...@hp.com> wrote: > The firmware is compiled for Cortex-R4, runs ThreadX OS and is > configured to use both instructions and data in big-endian (BE32 ?) format. The Cortex-R4 is an ARMv7 CPU, and so only supports BE8. > The code is > compiled with GHS toolchain. I understand that out of the box, GDB > will not be able to do source code debugging. However, I expected that > it’ll at least be able to do assembly level debugging. We have another > ASIC with Cortex-A9 configured for BE8, also running ThreadX. And it > does work at assembly level. First of all, please retry this with QEMU built from current git master. A lot of patches went in a few weeks ago to improve our big-endian support. We may well still have some bugs, but there doesn't seem much point trying to diagnose problems in the old code... That said, if your R4 is configured to use big-endian instruction order (presumably by the CFGIE signal being set high), then you're probably running into the fact that QEMU does not implement the (PMSAv7) SCTLR.IE bit which allows big-endian instructions for R profile. Further questions: (1) we don't implement an R4 model at all in QEMU (we do have an R5), so are you using some out of tree patches for R4 support or are you trying to run the code on an R5 CPU? (2) which board model are you using? One in QEMU mainline or an out of tree one? What is your QEMU command line? Regarding gdb, QEMU just provides facilities for reading and writing memory, so if asking gdb to do a memory dump shows correct data but disassembly does not, then the problem is at the gdb end (probably a config switch); you probably need to ask a gdb person about that. thanks -- PMM
