* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 [not found] <cb94e9b2-d7c6-68ab-bb25-42f7d8113e03@advancedtelematic.com> @ 2017-11-06 1:55 ` Bin Meng 2017-11-08 12:59 ` Anton Gerasimov 0 siblings, 1 reply; 8+ messages in thread From: Bin Meng @ 2017-11-06 1:55 UTC (permalink / raw) To: Anton Gerasimov, qemu-devel; +Cc: U-Boot Mailing List +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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-06 1:55 ` [Qemu-devel] [U-Boot] Support of latest qemux86-64 Bin Meng @ 2017-11-08 12:59 ` Anton Gerasimov 2017-11-08 13:05 ` Anton Gerasimov 0 siblings, 1 reply; 8+ messages in thread From: Anton Gerasimov @ 2017-11-08 12:59 UTC (permalink / raw) To: Bin Meng, U-Boot Mailing List; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-08 12:59 ` Anton Gerasimov @ 2017-11-08 13:05 ` Anton Gerasimov 2017-11-09 1:58 ` Bin Meng 0 siblings, 1 reply; 8+ messages in thread From: Anton Gerasimov @ 2017-11-08 13:05 UTC (permalink / raw) To: Bin Meng, U-Boot Mailing List; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-08 13:05 ` Anton Gerasimov @ 2017-11-09 1:58 ` Bin Meng 2017-11-10 17:04 ` Anton Gerasimov 0 siblings, 1 reply; 8+ messages in thread From: Bin Meng @ 2017-11-09 1:58 UTC (permalink / raw) To: Anton Gerasimov, Igor Mammedov; +Cc: U-Boot Mailing List, qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-09 1:58 ` Bin Meng @ 2017-11-10 17:04 ` Anton Gerasimov 2017-11-10 17:25 ` Anton Gerasimov 0 siblings, 1 reply; 8+ messages in thread From: Anton Gerasimov @ 2017-11-10 17:04 UTC (permalink / raw) To: Bin Meng, Igor Mammedov; +Cc: U-Boot Mailing List, qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-10 17:04 ` Anton Gerasimov @ 2017-11-10 17:25 ` Anton Gerasimov 2017-11-10 17:34 ` Anton Gerasimov 0 siblings, 1 reply; 8+ messages in thread From: Anton Gerasimov @ 2017-11-10 17:25 UTC (permalink / raw) To: Bin Meng, Igor Mammedov; +Cc: U-Boot Mailing List, qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-10 17:25 ` Anton Gerasimov @ 2017-11-10 17:34 ` Anton Gerasimov 2017-11-13 3:16 ` Bin Meng 0 siblings, 1 reply; 8+ messages in thread From: Anton Gerasimov @ 2017-11-10 17:34 UTC (permalink / raw) To: Bin Meng, Igor Mammedov; +Cc: U-Boot Mailing List, qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64 2017-11-10 17:34 ` Anton Gerasimov @ 2017-11-13 3:16 ` Bin Meng 0 siblings, 0 replies; 8+ messages in thread From: Bin Meng @ 2017-11-13 3:16 UTC (permalink / raw) To: Anton Gerasimov; +Cc: Igor Mammedov, U-Boot Mailing List, qemu-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-11-13 3:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <cb94e9b2-d7c6-68ab-bb25-42f7d8113e03@advancedtelematic.com>
2017-11-06 1:55 ` [Qemu-devel] [U-Boot] Support of latest qemux86-64 Bin Meng
2017-11-08 12:59 ` Anton Gerasimov
2017-11-08 13:05 ` Anton Gerasimov
2017-11-09 1:58 ` Bin Meng
2017-11-10 17:04 ` Anton Gerasimov
2017-11-10 17:25 ` Anton Gerasimov
2017-11-10 17:34 ` Anton Gerasimov
2017-11-13 3:16 ` Bin Meng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).