> ROM images are in form of binary blobs with no location information,
> they must be loaded to a known address. For boot ROMs, the address
> range would cover CPU hard reset entry vector.
So, for a BIOS or boot ROM that has been stripped, the board needs to
be hard-coded to not just load the imag
I'm attempting to familiarize myself with the APIs used to add
support for boards in qemu, and I have a few questions.
* How does using load_elf differ from load_image_targphys?
As an example, many of the boards I've looked at have a hard-coded
entrypoint. In mpc8455, it looks as though it d
On Fri, Mar 2, 2012 at 9:10 AM, GaoYi wrote:
> Hi all,
>
>I am trying to run Vxworks on KVM under X86_64 platform. Now I can
> startup vxworks without 'no-kvm' option. However, the bootup failed with
> hardware virtualization selected. Has anybody run it successfully?
>
>Any of your sugges
Public bug reported:
The options -mtdblock, -option-rom, and -pflash are severely under-
documented. For example:
-mtdblock -- It isn't at all clear what this does from --help or the
documentation, and it's especially not clear that it's only implemented
for ARM right now
-option-rom is only i
> Yeah - at this point the kernel should have taken over completely and so I
> expect that you're hitting an emulation bug (probably the Solaris compiler
> emits certain instruction sequences not used by gcc which is why this has
> only just come to light).
Alright. I'll do what I can. Thanks
> If the problem is on the QEMU side, getting relevant QEMU debug logs
> (-d in_asm,int which needs #define DEBUG_PCALL enabled in
> target-sparc/op_helper.c) would be needed. Those will be quite large
> and the relevant info is only near the end.
I'm not sure I'll be able to get/make available
