[U-Boot] Support of latest qemux86-64

[U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

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.

Thanks in advance.

Best regards,
Anton Gerasimov

[U-Boot] Support of latest qemux86-64

[Anton Gerasimov]

Some more details: EFI on QEMU v2.9.0 works as well, it's v2.10.0 where
some incompatibilities are introduced.

The last stable tag of u-boot that works (under qemu <= v2.9.0) as BIOS
for me is v2015.07. Starting from v2015.10 when I run

    qemu-system-x86_64 --bios u-boot.rom -nographic

I get the following dump:

Invalid Opcode (Undefined Opcode)
EIP: 0010:[<07f56583>] EFLAGS: 00000006
Original EIP :[<fff00583>]
EAX: 000000aa EBX: 07fab61c ECX: 0000006a EDX: 0000006b
ESI: 00000000 EDI: 00000003 EBP: 00000000 ESP: 07d52620
 DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Stack:
    0x07d52660 : 0x07f58460
    0x07d5265c : 0x07f77947
    0x07d52658 : 0x00000000
    0x07d52654 : 0x00000000
    0x07d52650 : 0x00000001
    0x07d5264c : 0x07fab61c
    0x07d52648 : 0x00000000
    0x07d52644 : 0x07fa319c
    0x07d52640 : 0x00000000
    0x07d5263c : 0x07f8ba2f
    0x07d52638 : 0x07d52780
    0x07d52634 : 0x07fab61c
    0x07d52630 : 0x07fcf200
    0x07d5262c : 0x07f77cb2
    0x07d52628 : 0x00000202
    0x07d52624 : 0x00000010
--->0x07d52620 : 0x07f77bdc
    0x07d5261c : 0x00000006
    0x07d52618 : 0x00000010
    0x07d52614 : 0x07f56583
### ERROR ### Please RESET the board ###

Debugging with gdb shows that it happens after transferring control to
RAM (board_f.c:1027 in v2015.10), but couldn't get more details so far,
so any help is appreciated.

Best regards,
Anton Gerasimov

On 11/03/2017 03:07 PM, Anton Gerasimov 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.
>
> Thanks in advance.
>
> Best regards,
> Anton Gerasimov
>
>

-- 
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]

+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

[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

[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

[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

[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

[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

[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

[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

[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