[U-Boot] [PATCH 1/5] mx6sabre{auto, sd}: Change FDT loading address to avoid overlaping
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Tested-by: Daiane Angolini daiane.angolini@freescale.com --- include/configs/mx6sabre_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index bb4db8b..2786a35 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -104,7 +104,7 @@ "script=boot.scr\0" \ "uimage=uImage\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "console=" CONFIG_CONSOLE_DEV "\0" \
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/wandboard.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 75a456c..04952dd 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -121,7 +121,7 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/udoo.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/udoo.h b/include/configs/udoo.h index 78df071..a5991aa 100644 --- a/include/configs/udoo.h +++ b/include/configs/udoo.h @@ -77,7 +77,7 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "mmcdev=0\0" \
Dear Otavio Salvador,
In message 1383305158-26019-3-git-send-email-otavio@ossystems.com.br you wrote:
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
What exactly is "2013.04-3.10.9_1.0.0-alpha" ? It makes no sense to add any such references which are meaningless to the reader.
Best regards,
Wolfgang Denk
On Fri, Nov 1, 2013 at 10:40 AM, Wolfgang Denk wd@denx.de wrote:
Dear Otavio Salvador,
In message 1383305158-26019-3-git-send-email-otavio@ossystems.com.br you wrote:
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
What exactly is "2013.04-3.10.9_1.0.0-alpha" ? It makes no sense to add any such references which are meaningless to the reader.
Please look at the other patch where Fabio and I are discussing about this commit log. In fact it is not meaningless but current FSL fork of U-Boot 2013.04 for 3.10.9-1.0.0 BSP.
Dear Otavio Salvador,
In message CAP9ODKpGwQMN0udK_V_o=Q759sDbn7YG1xnr2BpQyiKXXZYdWQ@mail.gmail.com you wrote:
Please look at the other patch where Fabio and I are discussing about this commit log. In fact it is not meaningless but current FSL fork of U-Boot 2013.04 for 3.10.9-1.0.0 BSP.
It is meaningless to the reader of this commit message. A commit message may be read in a couple of years, and even people who don;t remember what you are discussing now on the mailing list should be able to understand it.
So please provide a desription that provides sufficient context so it can be understood.
Thanks.
Wolfgang Denk
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/nitrogen6x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 3454b86..a2a3bb3 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -182,7 +182,7 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=imx6q-sabrelite.dtb\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "mmcdev=0\0" \
Dear Otavio Salvador,
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
include/configs/nitrogen6x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 3454b86..a2a3bb3 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -182,7 +182,7 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=imx6q-sabrelite.dtb\0" \
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "mmcdev=0\0" \
Why is the FDT not relocated close to the end of DRAM as the other boards do it?
Best regards, Marek Vasut
On Fri, Nov 1, 2013 at 10:19 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
...
Why is the FDT not relocated close to the end of DRAM as the other boards do it?
No idea.
Dear Otavio Salvador,
On Fri, Nov 1, 2013 at 10:19 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
...
Why is the FDT not relocated close to the end of DRAM as the other boards do it?
No idea.
Is this patch papering over some bug in the simplest possible way then?
btw. I mean this portion of the boot log, see the last line:
## Flattened Device Tree blob at 11000000 Booting using the fdt blob at 0x11000000 Loading Kernel Image ... OK Using Device Tree in place at 11000000, end 1100b568
Best regards, Marek Vasut
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/cgtqmx6eval.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/cgtqmx6eval.h b/include/configs/cgtqmx6eval.h index 5cf456a..9dee2b7 100644 --- a/include/configs/cgtqmx6eval.h +++ b/include/configs/cgtqmx6eval.h @@ -81,7 +81,7 @@ "console=ttymxc1\0" \ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x18000000\0" \ "boot_fdt=try\0" \ "mmcdev=1\0" \ "mmcpart=1\0" \
Hi Otavio,
On Fri, Nov 1, 2013 at 9:25 AM, Otavio Salvador otavio@ossystems.com.br wrote:
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Care to explain in more details about the overlap?
Currently we use the following addresses:
- dtb: 0x11000000 - kernel: 0x12000000
Now you propose:
- kernel: 0x12000000 - dtb: 0x18000000
If the kernel is larger in FSL 3.10.9 kernel, how it can overlap with dtb, since in the original code the kernel goes after the dtb?
I have never used FSL 3.10.9 kernel, so I am curious about this fix.
Regards,
Fabio Estevam
On Fri, Nov 1, 2013 at 10:25 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Otavio,
On Fri, Nov 1, 2013 at 9:25 AM, Otavio Salvador otavio@ossystems.com.br wrote:
The new FSL 3.10.9_1.0.0-alpha kernel requires more memory space and with the previous loading address we had ovelap; change it for the same address used in 2013.04-3.10.9_1.0.0-alpha U-Boot.
Care to explain in more details about the overlap?
Currently we use the following addresses:
- dtb: 0x11000000
- kernel: 0x12000000
Now you propose:
- kernel: 0x12000000
- dtb: 0x18000000
If the kernel is larger in FSL 3.10.9 kernel, how it can overlap with dtb, since in the original code the kernel goes after the dtb?
I have never used FSL 3.10.9 kernel, so I am curious about this fix.
I am quoting the original commit change:
ENGR00268032 config/sabre_common: change the fdt_addr to a high address
current the fdt_addr is just 16MB offset from the ddr base address, which will cause the dtb will be overritten by linux kernel(include .bss section) if the linux kernel is bigger than 16MB, which cause setup_machine_fdt failed and thus kernel failed to boot.
This patch change the defaut fdt_addr to 128MB offset from the ddr base address, which should be enough for common user case. user can change it to other value according to their system needs.
Signed-off-by: Jason Liu r64343@freescale.com
I think I can rework the commit log and include this there.
On Fri, Nov 1, 2013 at 11:00 AM, Otavio Salvador otavio@ossystems.com.br wrote:
I am quoting the original commit change:
ENGR00268032 config/sabre_common: change the fdt_addr to a high address current the fdt_addr is just 16MB offset from the ddr base address, which will cause the dtb will be overritten by linux kernel(include .bss section) if the linux kernel is bigger than 16MB, which cause setup_machine_fdt failed and thus kernel failed to boot.
What is the size of the FSL 3.10 kernel?
I still do not understand the fix after reading the commit log you pointed to.
Adding Jason, in case he could help clarifying it.
Regards,
Fabio Estevam
participants (4)
-
Fabio Estevam -
Marek Vasut -
Otavio Salvador -
Wolfgang Denk