[U-Boot] Support of latest qemux86-64
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
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
+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
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
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
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
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
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
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
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
participants (2)
-
Anton Gerasimov -
Bin Meng