Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Bin Meng]

+QEMU dev list

On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
<anton@advancedtelematic.com> wrote:
> Hi all,
>
> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
> run into a "trying to execute code outside of RAM or ROM at xxxxx"
> issue. It happens both when I build and use u-boot as a bios and as EFI
> payload, just the addresses in the error message are different. On qemu
> v2.5.0 at least EFI option works fine.
>
> I understand that it can be (and probably is) a QEMU issue, but maybe
> someone on the list already encountered it and knows a workaround or has
> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>

Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
2.10.1.

I built U-Boot as follows:

$ make qemu-x86_defconfig
$ make

Does anyone have any hints?

Regards,
Bin

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

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's just three lines added,
I'll paste the whole patch here. Not quite sure what can we do here though.


  diff --git a/hw/i386/pc.c b/hw/i386/pc.c
  index 22e16031b0..59435390ba 100644
  --- a/hw/i386/pc.c
  +++ b/hw/i386/pc.c
  @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
       option_rom_mr = g_malloc(sizeof(*option_rom_mr));
       memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
                              &error_fatal);
  +    if (pcmc->pci_enabled) {
  +        memory_region_set_readonly(option_rom_mr, true);
  +    }
       memory_region_add_subregion_overlap(rom_memory,
                                           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
> <anton@advancedtelematic.com> wrote:
>> Hi all,
>>
>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>> run into a "trying to execute code outside of RAM or ROM at xxxxx"
>> issue. It happens both when I build and use u-boot as a bios and as EFI
>> payload, just the addresses in the error message are different. On qemu
>> v2.5.0 at least EFI option works fine.
>>
>> I understand that it can be (and probably is) a QEMU issue, but maybe
>> someone on the list already encountered it and knows a workaround or has
>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>
> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
> 2.10.1.
>
> I built U-Boot as follows:
>
> $ make qemu-x86_defconfig
> $ make
>
> Does anyone have any hints?
>
> Regards,
> Bin


-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

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's just three lines added,
> I'll paste the whole patch here. Not quite sure what can we do here though.
>
>
>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>   index 22e16031b0..59435390ba 100644
>   --- a/hw/i386/pc.c
>   +++ b/hw/i386/pc.c
>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>                               &error_fatal);
>   +    if (pcmc->pci_enabled) {
>   +        memory_region_set_readonly(option_rom_mr, true);
>   +    }
>        memory_region_add_subregion_overlap(rom_memory,
>                                            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
>> <anton@advancedtelematic.com> wrote:
>>> Hi all,
>>>
>>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>>> run into a "trying to execute code outside of RAM or ROM at xxxxx"
>>> issue. It happens both when I build and use u-boot as a bios and as EFI
>>> payload, just the addresses in the error message are different. On qemu
>>> v2.5.0 at least EFI option works fine.
>>>
>>> I understand that it can be (and probably is) a QEMU issue, but maybe
>>> someone on the list already encountered it and knows a workaround or has
>>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>>
>> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
>> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
>> 2.10.1.
>>
>> I built U-Boot as follows:
>>
>> $ make qemu-x86_defconfig
>> $ make
>>
>> Does anyone have any hints?
>>
>> Regards,
>> Bin
>

-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Bin Meng]

On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
<anton@advancedtelematic.com> wrote:
> Adding Igor Mammedov to the loop.
>

Really add Igor Mammedov.

Igor, can you help look at this?

> 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's just three lines added,
>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>
>>
>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>   index 22e16031b0..59435390ba 100644
>>   --- a/hw/i386/pc.c
>>   +++ b/hw/i386/pc.c
>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>                               &error_fatal);
>>   +    if (pcmc->pci_enabled) {
>>   +        memory_region_set_readonly(option_rom_mr, true);
>>   +    }
>>        memory_region_add_subregion_overlap(rom_memory,
>>                                            PC_ROM_MIN_VGA,
>>                                            option_rom_mr,
>>
>>

Regards,
Bin

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

New guess:

in the most safe configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
fails on the first 'ret' instruction. GDB shows that memory at $esp
(0xdfffc at the entrance to board_init_f_mem) and everything 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 Meng wrote:
> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
> <anton@advancedtelematic.com> wrote:
>> Adding Igor Mammedov to the loop.
>>
> Really add Igor Mammedov.
>
> Igor, can you help look at this?
>
>> 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's just three lines added,
>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>
>>>
>>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>   index 22e16031b0..59435390ba 100644
>>>   --- a/hw/i386/pc.c
>>>   +++ b/hw/i386/pc.c
>>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>                               &error_fatal);
>>>   +    if (pcmc->pci_enabled) {
>>>   +        memory_region_set_readonly(option_rom_mr, true);
>>>   +    }
>>>        memory_region_add_subregion_overlap(rom_memory,
>>>                                            PC_ROM_MIN_VGA,
>>>                                            option_rom_mr,
>>>
>>>
> Regards,
> Bin


-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

Yes, apparently 0xdfffc is in ROM area for QEMU (0xc0000 -- 0xe0000,
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 configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
> with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
> fails on the first 'ret' instruction. GDB shows that memory at $esp
> (0xdfffc at the entrance to board_init_f_mem) and everything 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 Meng wrote:
>> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
>> <anton@advancedtelematic.com> wrote:
>>> Adding Igor Mammedov to the loop.
>>>
>> Really add Igor Mammedov.
>>
>> Igor, can you help look at this?
>>
>>> 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's just three lines added,
>>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>>
>>>>
>>>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>   index 22e16031b0..59435390ba 100644
>>>>   --- a/hw/i386/pc.c
>>>>   +++ b/hw/i386/pc.c
>>>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>>                               &error_fatal);
>>>>   +    if (pcmc->pci_enabled) {
>>>>   +        memory_region_set_readonly(option_rom_mr, true);
>>>>   +    }
>>>>        memory_region_add_subregion_overlap(rom_memory,
>>>>                                            PC_ROM_MIN_VGA,
>>>>                                            option_rom_mr,
>>>>
>>>>
>> Regards,
>> Bin
>

-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

Hooray, changing SYS_CAR_ADDR to 0x10000 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 (0xc0000 -- 0xe0000,
> 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 configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
>> with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
>> fails on the first 'ret' instruction. GDB shows that memory at $esp
>> (0xdfffc at the entrance to board_init_f_mem) and everything 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 Meng wrote:
>>> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
>>> <anton@advancedtelematic.com> wrote:
>>>> Adding Igor Mammedov to the loop.
>>>>
>>> Really add Igor Mammedov.
>>>
>>> Igor, can you help look at this?
>>>
>>>> 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's just three lines added,
>>>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>>>
>>>>>
>>>>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>>   index 22e16031b0..59435390ba 100644
>>>>>   --- a/hw/i386/pc.c
>>>>>   +++ b/hw/i386/pc.c
>>>>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>>>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>>>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>>>                               &error_fatal);
>>>>>   +    if (pcmc->pci_enabled) {
>>>>>   +        memory_region_set_readonly(option_rom_mr, true);
>>>>>   +    }
>>>>>        memory_region_add_subregion_overlap(rom_memory,
>>>>>                                            PC_ROM_MIN_VGA,
>>>>>                                            option_rom_mr,
>>>>>
>>>>>
>>> Regards,
>>> Bin


-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

[Bin Meng]

Hi Anton,

On Sat, Nov 11, 2017 at 1:34 AM, Anton Gerasimov
<anton@advancedtelematic.com> wrote:
> Hooray, changing SYS_CAR_ADDR to 0x10000 in arch/x86/cpu/qemu/Kconfig
> does the trick. Bin, what do you think about it?
>

Great! Would you please create a patch against U-Boot QEMU?

> Best regards,
> Anton Gerasimov
>
> On 11/10/2017 06:25 PM, Anton Gerasimov wrote:
>> Yes, apparently 0xdfffc is in ROM area for QEMU (0xc0000 -- 0xe0000,
>> 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 configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
>>> with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
>>> fails on the first 'ret' instruction. GDB shows that memory at $esp
>>> (0xdfffc at the entrance to board_init_f_mem) and everything 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 Meng wrote:
>>>> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
>>>> <anton@advancedtelematic.com> wrote:
>>>>> Adding Igor Mammedov to the loop.
>>>>>
>>>> Really add Igor Mammedov.
>>>>
>>>> Igor, can you help look at this?
>>>>
>>>>> 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's just three lines added,
>>>>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>>>>
>>>>>>
>>>>>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>>>   index 22e16031b0..59435390ba 100644
>>>>>>   --- a/hw/i386/pc.c
>>>>>>   +++ b/hw/i386/pc.c
>>>>>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>>>>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>>>>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>>>>                               &error_fatal);
>>>>>>   +    if (pcmc->pci_enabled) {
>>>>>>   +        memory_region_set_readonly(option_rom_mr, true);
>>>>>>   +    }
>>>>>>        memory_region_add_subregion_overlap(rom_memory,
>>>>>>                                            PC_ROM_MIN_VGA,
>>>>>>                                            option_rom_mr,
>>>>>>
>>>>>>
>>>> Regards,
>>>> Bin
>

Regards,
Bin