Hooray, changing SYS_CAR_ADDR to 0x1 in arch/x86/cpu/qemu/Kconfig
does the trick. Bin, what do you think about it?
Best regards,
Anton Gerasimov
On 11/10/2017 06:25 PM, Anton Gerasimov wrote:
> Yes, apparently 0xdfffc is in ROM area for QEMU (0xc -- 0xe,
> defined in incl
Yes, apparently 0xdfffc is in ROM area for QEMU (0xc -- 0xe,
defined in include/hw/loader.h). The next thing to figure out is why
u-boot uses it as a stack area.
Best regards,
Anton Gerasimov
On 11/10/2017 06:04 PM, Anton Gerasimov wrote:
> New guess:
>
> in the most safe conf
ng around it
is zero despite 'call' and 'push' instructions executed. If you go one
commit before the breaking one it works fine, stuff gets put onto stack.
Could it that be that stack itself is in this 'readonly' area?
Thanks,
Anton Gerasimov
On 11/09/2017 02:58 AM, Bin
Adding Igor Mammedov to the loop.
On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
> To whoever might be interested: I've bisected qemu and the breaking
> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
> readonly when machine has PCI enabled). It&
PC_ROM_MIN_VGA,
option_rom_mr,
Thanks,
Anton
On 11/06/2017 02:55 AM, Bin Meng wrote:
> +QEMU dev list
>
> On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
> wrote:
>> Hi all,
>>
>> I'm trying to use u-boot (v2017.01) with qe
