Thanks for the help, Peter!
I have referred to the versatilepb board for setting the property.
This is what I'm doing now, in my machine_init:
Object* cpuobj = obj_new(machine->cpu_type);
object_property_set_bool(cpuobj, true, "cfgend", &error_fatal);
object_property_set_bool(cpuobj, true, "realized", &error_fatal);
ARMCPU* armcpu = ARM_CPU(cpuobj);
CPUState* cpu = CPU(armcpu);
cpu_set_pc(cpu, 0x40000000);
<board code>
boot_info.entry = 0x40000000;
arm_load_kernel(armcpu, machine, &boot_info);
In the code above, I am not able to change the pc of the cpu. cpu_set_pc does set the pc, but its value gets changed back to 0 on the call to arm_load_kernel.
Could you tell me how I can set the pc in this case?
I don't use the -kernel option, because I'm loading the binaries to memory in the <board code> section.
Also, I get a segfault if I don't set the "realized" property. Is setting it like I have the proper way to do it?
Thanks,
Tanay
On Fri, 6 Mar 2020 at 14:28, Tanay Gupta <address@hidden> wrote:
> I'm trying to write my own board, and I'm not quite sure how to set the endianness to BE32.
>
> I am loading binaries to memory using load_image_targphys_as.
>
> I have tried:
> - passing -cpu arm1136,cfgend=yes
> - using the setend be instruction
> - using mrc/mcr to change CP15
BE32 is basically something that's pretty much unused
by any of the boards that QEMU supports upstream. The
code is in theory present and should work, but it could
well have bitrotted. You'll probably have to dive into the
QEMU sourcecode itself to see what's going on.
The theoretical "right way" is for your board model to set
the 'cfgend' QOM property when it creates the CPU.
(None of our in-tree boards do that but you can see a similar
thing where some boards set has_el2 or has_el3 properties
on the CPU.) In theory the command line -cpu arm1136,cfgend=yes
should be equivalent but this relies on the board code you
have written honouring the user-specified CPU option rather
than ignoring it. If in doubt, put a breakpoint on
arm_cpu_realizefn() and check that cpu->cfgend is true and
that the code in the middle of the function then sets the
SCTLR_B flag.
> In all the above cases, I check whether the endianness has changed in these ways:
>
> - xp /10i 0x40000000 in qemu monitor; which prints the LE interpretation of the code no matter what I do
I would not necessarily trust this as an indication of what
QEMU itself is doing; the monitor debug/print path is
separate from the actual JIT/execution, so you can have
endianness bugs in one and not the other.
Bear in mind that BE32 is word-invariant big-endian,
not byte-invariant big-endian, when you try to interpret
what's going on :-)
It's possible that the bug is just in how we load the
image into memory. As a test you could try byte-swapping
every word in the image file and then running it.
QEMU's variety of '-d' options will help in figuring
out what the JIT is doing, though the output somewhat
assumes you know a bit about QEMU internals.
thanks
-- PMM