英文:
Linux Kernel Boot Error: reserving fdt memory region failed
问题
The boot error you mentioned, "ERROR: reserving fdt memory region failed (addr=38000000 size=8000000)," is related to the device tree memory reservation. This error occurs when the kernel tries to reserve a memory region specified in the device tree but encounters a problem. It's likely not directly causing the kernel panic, but it might be related indirectly.
To correct the boot error, you can consider the following steps:
-
Check Device Tree Configuration: Ensure that the memory region specified in your device tree matches the actual memory configuration of your hardware. The error message indicates that the reservation for the memory region at address 0x38000000 with a size of 0x08000000 failed. Verify that these values are correct for your board.
-
Memory Availability: Make sure that the specified memory region is available and not already reserved by other kernel components or device drivers. If it's in use by another part of the system, you may need to adjust the memory reservation.
-
Device Tree Compatibility: Verify that the compatible string in the device tree node matches the driver that is trying to access this memory region. In your device tree, it's set to "ingeniars,gpu4sat-memory," so ensure that the corresponding driver is compatible with this.
-
Driver Configuration: Check the configuration of the driver responsible for this memory region (krnl_gpu4sat_memory) to ensure it's correctly configured to use the reserved memory.
Regarding the kernel panic issue, it appears to be a separate problem. Kernel panics can have various causes, and they are not always directly related to memory reservations. It could be related to drivers, hardware issues, or other kernel configurations. Unfortunately, without more specific information about the kernel panic message and context, it's challenging to pinpoint the exact cause.
To address the kernel panic, you may need to gather more information from the panic message and possibly enable kernel debugging to get a more detailed trace. Once you have more information about the kernel panic, you can then focus on addressing that issue.
In summary, start by verifying and adjusting the memory reservation in your device tree to match your hardware configuration. If the kernel panic issue persists, investigate it separately, as it may have different underlying causes.
英文:
I am working on a Xilinx zcu706 board. I have developed the Linux Kernel but, when it is booting, I get an error on reserving the memory defined in device tree: ERROR: reserving fdt memory region failed (addr=38000000 size=8000000)
This is my device-tree, which I have copied from Xilinx tutorial:
/include/ "system-conf.dtsi"
/ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
reserved: buffer@0x38000000 {
compatible = "shared-dma-pool";
no-map;
reg = <0x38000000 0x08000000>;
};
};
reserved-driver@0x38000000 {
compatible = "ingeniars,gpu4sat-memory";
memory-region = <&reserved>;
};
};
This is what happened at boot before the error:
Hit any key to stop autoboot: 0
JTAG: Trying to boot script at 0x3000000
## Executing script at 03000000
## Booting kernel from Legacy Image at 00200000 ...
Image Name: Linux-5.4.0-xilinx-v2020.2
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4325984 Bytes = 4.1 MiB
Load Address: 00200000
Entry Point: 00200000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name: petalinux-image-minimal-zynq-gen
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 7885622 Bytes = 7.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00100000
Booting using the fdt blob at 0x100000
Loading Kernel Image
Loading Ramdisk to 1f87a000, end 1ffff336 ... OK
ERROR: reserving fdt memory region failed (addr=38000000 size=8000000)
Loading Device Tree to 1f872000, end 1f879ce8 ... OK
Starting kernel ...
After the error, the boot seems to end correctly and I can use the apps that I have developed but eventually I get a Kernel Panic, that I think may be related to the error reserving memory.
Here is the kernel panic stack trace:
Unable to handle kernel NULL pointer dereference at virtual address 000009b4
pgd = 330888c5
[000009b4] *pgd=00000000
Internal error: Oops - BUG: 5 [#1] PREEMPT SMP ARM
Modules linked in: krnl_gpu4sat_memory(O) krnl_gpu_sat(O) uio_pdrv_genirq
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 5.4.0-xilinx-v2020.2 #1
Hardware name: Xilinx Zynq Platform
PC is at update_rq_clock+0x0/0xe8
LR is at dequeue_task+0x20/0x40
pc : [<c013acfc>] lr : [<c013ae44>] psr: 400f0193
sp : c0b01d90 ip : 00000000 fp : c0b01da4
r10: 00000000 r9 : c0b03df4 r8 : 800f0193
r7 : ee57d104 r6 : 00000400 r5 : c0a3f180 r4 : ef7f5180
r3 : 0bea0be9 r2 : c0a3f180 r1 : ef7f5180 r0 : 00000400
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 2e4ec04a DAC: 00000051
Process swapper/0 (pid: 0, stack limit = 0x23873ec4)
Stack: (0xc0b01d90 to 0xc0b02000)
1d80: ee57cc80 ee57cc80 00000000 ee57d104
1da0: c0b01db4 c0140f48 ef7f5180 ee57cc80 c0b01dcc c013b74c ee57cc80 ef7f5180
1dc0: 00000000 ee57d104 c0b01dfc c013c318 ee487f20 c0b03c48 ef7f3600 ef7f3640
1de0: ef7f3600 ef7f3600 ee487f20 00000000 35cca1c4 000000a7 00000001 c016d768
1e00: ef7f3640 c016dbf0 35cca1c4 000000a7 ffffffff c016d748 c0b00000 ef7f3600
1e20: 200f0193 00000011 ffffffff 7fffffff 000000a7 000000a7 000000a7 c016e528
1e40: 200f0193 0000000f 00000003 c016e3ac 69871980 35cca1c4 000000a7 35cc9c0c
1e60: 000000a3 00000001 c0b040d4 00000011 ef015ec0 f8f01100 c0b00000 000000a7
1e80: 000000a7 c010dcfc ef008900 c015db40 00000000 00000000 ef006600 00000001
1ea0: f8f01100 c0158d90 00000000 c015933c c0b01ee0 f8f00100 c0b040cc c0b17b3c
1ec0: f8f01100 c033ec18 c052bcd0 600f0013 ffffffff c0b01f14 3768e24e c0101a8c
1ee0: 00000000 000000a7 2edb6000 ef7f5180 c0b2d5ac 00000000 ef7f4578 00000000
1f00: 3768e24e 376d9005 000000a7 000000a7 fffffff5 c0b01f30 c052bcac c052bcd0
1f20: 600f0013 ffffffff 00000051 00000000 c0b01f83 00000000 0004c5d8 00000000
1f40: ee9aef00 c0548278 00000000 ef7f4578 c0b2d5ac 00000000 c0b03c68 00000001
1f60: c0b01f80 c0b03ca8 00000000 c052bea8 ef7f4578 c0b2d5ac c0b00000 c01400ec
1f80: 017f5180 c0b03c48 00000000 000000cf 00000001 c0b36440 00000000 c0b36440
1fa0: 00000001 c0a2da40 00000000 c0140278 c0b36494 c0a00cb8 ffffffff ffffffff
1fc0: 00000000 c0a00578 00000000 c0a2da40 d337e4a0 c0b03c48 c0a00330 00000051
1fe0: 10c0387d 00000000 1f872000 413fc090 18c5387d 00000000 00000000 00000000
[<c013acfc>] (update_rq_clock) from [<c0140f48>] (update_overutilized_status.part.0+0x20/0x3c)
[<c0140f48>] (update_overutilized_status.part.0) from [<c013b74c>] (ttwu_do_activate+0x38/0x50)
Code: eaffffe4 e24bd014 e8bd88f0 c0801b38 (e59035b4)
---[ end trace 3e666a7ba6e33cb7 ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D O 5.4.0-xilinx-v2020.2 #1
Hardware name: Xilinx Zynq Platform
[<c010e37c>] (unwind_backtrace) from [<c010a124>] (show_stack+0x10/0x14)
[<c010a124>] (show_stack) from [<c06a24e8>] (dump_stack+0xb4/0xd0)
[<c06a24e8>] (dump_stack) from [<c010c964>] (ipi_cpu_stop+0x3c/0x98)
[<c010c964>] (ipi_cpu_stop) from [<c010d1b0>] (handle_IPI+0x64/0x80)
[<c010d1b0>] (handle_IPI) from [<c033ec44>] (gic_handle_irq+0x84/0x90)
[<c033ec44>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0xa8)
Exception stack(0xef085f20 to 0xef085f68)
5f20: 00000000 000000a7 2edc5000 ef804180 c0b2d5ac 00000001 ef803578 00000000
5f40: 3ae0ed5b 4689c05e 000000a7 000000a7 fffffff5 ef085f70 c052bcac c052bcd0
5f60: 60010013 ffffffff
[<c0101a8c>] (__irq_svc) from [<c052bcd0>] (cpuidle_enter_state+0xec/0x288)
[<c052bcd0>] (cpuidle_enter_state) from [<c052bea8>] (cpuidle_enter+0x28/0x38)
[<c052bea8>] (cpuidle_enter) from [<c01400ec>] (do_idle+0x230/0x258)
[<c01400ec>] (do_idle) from [<c0140278>] (cpu_startup_entry+0x18/0x1c)
[<c0140278>] (cpu_startup_entry) from [<0010242c>] (0x10242c)
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
As I said, the kernel panic can not be traced, since it is not deterministic: it does not happened at every execution and it happened with different configurations.
Do you think the boot error can be related to the kernel panic? Do you know how can I correct the boot error?
答案1
得分: 0
以下是您要翻译的内容：
"那个错误消息是在Linux内核开始执行之前由U-Boot输出的。请注意，Starting kernel ...消息在这个错误消息之后。
U-Boot正在处理保留的内存列表，以确保其放置DT blob和（可选的）initramfs归档或initrd映像不会与这些规格发生冲突。这在boot/image-fdt.c的注释中有记录：
- 添加memreserve区域可以防止u-boot将其用于存储initrd或fdt blob。
虽然这是一个“错误”消息，但当它来自U-Boot而不是Linux内核时，可以忽略这个消息。生成此消息的U-Boot例程位于boot/image-fdt.c：
static void boot_fdt_reserve_region(struct lmb *lmb, uint64_t addr,
uint64_t size, enum lmb_flags flags)
{
long ret;
ret = lmb_reserve_flags(lmb, addr, size, flags);
if (ret >= 0) {
debug(" reserving fdt memory region: addr=%llx size=%llx flags=%x\n",
(unsigned long long)addr,
(unsigned long long)size, flags);
} else {
puts("ERROR: reserving fdt memory region failed ");
printf("(addr=%llx size=%llx flags=%x)\n",
(unsigned long long)addr,
(unsigned long long)size, flags);
}
}
请注意，在尝试为内存块/区域设置保留标志后，成功或失败只会显示消息。由于此例程的类型为void，因此不会传回返回代码，并且U-Boot会丢弃错误条件。
您认为启动错误与内核恐慌有关吗？
不，U-Boot消息与内核恐慌无关。U-Boot报告的“错误”可能表示与在高内存中执行的U-Boot映像（已重新定位）发生冲突。（物理内存的地址范围是多少？）这样的（临时）冲突对Linux内核（尚未开始执行）应该没有任何影响。
您需要查看内核引导日志和**/proc/iomem**，以验证内核是否正确保留了指定的内存区域。
您知道如何纠正启动错误吗？
要么忽略它，要么尝试在内存中较低的区域保留一个区域。
关于内核恐慌的原因，这应该是另一个/不同的帖子（需要更多信息，例如内核版本、配置等）。
英文:
That error message is output by U-Boot before the Linux kernel ever begins execution. Note that the Starting kernel ... message is after this error message.
U-Boot is processing the reserved memory list to ensure that its placement of the DT blob and (optional) initramfs archive or initrd image do not conflict with those specifications. This is documented in a comment in boot/image-fdt.c:
* Adding the memreserve regions prevents u-boot from using them to store the
* initrd or the fdt blob.
Although it's an "error" message, this message can probably be ignored when it's from U-Boot rather than the Linux kernel. The U-Boot routine that generates this message is from boot/image-fdt.c:
static void boot_fdt_reserve_region(struct lmb *lmb, uint64_t addr,
uint64_t size, enum lmb_flags flags)
{
long ret;
ret = lmb_reserve_flags(lmb, addr, size, flags);
if (ret >= 0) {
debug(" reserving fdt memory region: addr=%llx size=%llx flags=%x\n",
(unsigned long long)addr,
(unsigned long long)size, flags);
} else {
puts("ERROR: reserving fdt memory region failed ");
printf("(addr=%llx size=%llx flags=%x)\n",
(unsigned long long)addr,
(unsigned long long)size, flags);
}
}
Note that after trying to set the reserve flag for the memory block/region, success or failure do nothing other than display messages. Since this routine has type void, no return code is passed back, and the error condition is discarded by U-Boot.
> Do you think the boot error can be related to the kernel panic?
No, the U-Boot message is unrelated to the kernel panic.
The "error" reported by U-Boot probably indicates a conflict with the (relocated) image of U-Boot executing in high memory. (What is the address range of physical memory?) Such a (temporary) conflict should have zero effect on the Linux kernel (that has yet to begin execution).
You need to review the kernel boot log and /proc/iomem to verify that the designated memory region was properly reserved by the kernel.
> Do you know how can I correct the boot error?
Either ignore it, or try reserving a region lower in memory.
As to the cause of the kernel panic, that should be another/different post (which will require more information, e.g. the kernel version, configuration, etc.).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论