[U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
This patch fixes allow for the DeviceTree and initrd relocation fixing the boot of FSL 3.10.9-1.0.0-alpha kernel.
This changes following boards:
- mx6sabreauto - mx6sabresd - wandboard - udoo - nitrogen6x - cgtqmx6eval
The reasoning, as explained by Hui Liu, is:
,---- | The FDT blob will be placed at DDR physical addr: 0x11000000. When Linux kernel | Boot up, it will decompress the compressed kernel image and place the decompressed | kernel image at the low end of the DDR memory and start running from it. If the | decompressed kernel image is bigger for example than 16M, it may over written the | fdt blob which u-boot loaded to the DDR memory @0x11000000 with fdt_addr=0x11000000 | | To expand the fdt_addr from 0x11000000 to 0x18000000, which can avoid the override | Since we will not likely have one kernel image larger than 128MB. `----
Removing the fdt_high and initrd_high this allows for those to be relocated.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/cgtqmx6eval.h | 2 -- include/configs/mx6sabre_common.h | 2 -- include/configs/nitrogen6x.h | 2 -- include/configs/udoo.h | 2 -- include/configs/wandboard.h | 2 -- 5 files changed, 10 deletions(-)
diff --git a/include/configs/cgtqmx6eval.h b/include/configs/cgtqmx6eval.h index d5db8f5..48acf50 100644 --- a/include/configs/cgtqmx6eval.h +++ b/include/configs/cgtqmx6eval.h @@ -79,8 +79,6 @@ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ "boot_dir=/boot\0" \ "console=ttymxc1\0" \ - "fdt_high=0xffffffff\0" \ - "initrd_high=0xffffffff\0" \ "fdt_addr=0x11000000\0" \ "boot_fdt=try\0" \ "mmcdev=1\0" \ diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 4b4f640..01acd7f 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -108,8 +108,6 @@ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "console=" CONFIG_CONSOLE_DEV "\0" \ - "fdt_high=0xffffffff\0" \ - "initrd_high=0xffffffff\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \ "mmcpart=1\0" \ "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \ diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 3df8de0..93c88c9 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -186,8 +186,6 @@ "script=boot.scr\0" \ "uimage=uImage\0" \ "console=ttymxc1\0" \ - "fdt_high=0xffffffff\0" \ - "initrd_high=0xffffffff\0" \ "fdt_file=imx6q-sabrelite.dtb\0" \ "fdt_addr=0x11000000\0" \ "boot_fdt=try\0" \ diff --git a/include/configs/udoo.h b/include/configs/udoo.h index 78df071..e38a598 100644 --- a/include/configs/udoo.h +++ b/include/configs/udoo.h @@ -74,8 +74,6 @@ "uimage=uImage\0" \ "console=ttymxc1\0" \ "splashpos=m,m\0" \ - "fdt_high=0xffffffff\0" \ - "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ "fdt_addr=0x11000000\0" \ "boot_fdt=try\0" \ diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 68ff724..8d9b5d8 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -118,8 +118,6 @@ "uimage=uImage\0" \ "console=ttymxc0\0" \ "splashpos=m,m\0" \ - "fdt_high=0xffffffff\0" \ - "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ "fdt_addr=0x11000000\0" \ "boot_fdt=try\0" \
On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:
This patch fixes allow for the DeviceTree and initrd relocation fixing the boot of FSL 3.10.9-1.0.0-alpha kernel.
This changes following boards:
- mx6sabreauto
- mx6sabresd
- wandboard
- udoo
- nitrogen6x
- cgtqmx6eval
The reasoning, as explained by Hui Liu, is:
,---- | The FDT blob will be placed at DDR physical addr: 0x11000000. When Linux kernel | Boot up, it will decompress the compressed kernel image and place the decompressed | kernel image at the low end of the DDR memory and start running from it. If the | decompressed kernel image is bigger for example than 16M, it may over written the | fdt blob which u-boot loaded to the DDR memory @0x11000000 with fdt_addr=0x11000000 | | To expand the fdt_addr from 0x11000000 to 0x18000000, which can avoid the override | Since we will not likely have one kernel image larger than 128MB. `----
Removing the fdt_high and initrd_high this allows for those to be relocated.
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
On Tue, Nov 26, 2013 at 10:11 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:
This patch fixes allow for the DeviceTree and initrd relocation fixing the boot of FSL 3.10.9-1.0.0-alpha kernel.
This changes following boards:
- mx6sabreauto
- mx6sabresd
- wandboard
- udoo
- nitrogen6x
- cgtqmx6eval
The reasoning, as explained by Hui Liu, is:
,---- | The FDT blob will be placed at DDR physical addr: 0x11000000. When Linux kernel | Boot up, it will decompress the compressed kernel image and place the decompressed | kernel image at the low end of the DDR memory and start running from it. If the | decompressed kernel image is bigger for example than 16M, it may over written the | fdt blob which u-boot loaded to the DDR memory @0x11000000 with fdt_addr=0x11000000 | | To expand the fdt_addr from 0x11000000 to 0x18000000, which can avoid the override | Since we will not likely have one kernel image larger than 128MB. `----
Removing the fdt_high and initrd_high this allows for those to be relocated.
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
Fabio/Stefano what is your call here? I think moving it to 128MB is good for now.
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
I missed this issue, too :-(
Does it work with your patch ? Most supported i.MX6 boards have more as 768MB, and I am wondering that all kernels can boot.
Fabio/Stefano what is your call here? I think moving it to 128MB is good for now.
Yes, it seems this becomes our choice.
Best regards, Stefano
On Wed, Nov 27, 2013 at 5:53 AM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
I missed this issue, too :-(
Does it work with your patch ? Most supported i.MX6 boards have more as 768MB, and I am wondering that all kernels can boot.
Fabio/Stefano what is your call here? I think moving it to 128MB is good for now.
Yes, it seems this becomes our choice.
Ok; I will send a new patch later today.
El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sbabic@denx.de escribió:
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
I missed this issue, too :-(
Does it work with your patch ? Most supported i.MX6 boards have more as 768MB, and I am wondering that all kernels can boot.
In fedora land we have not seen issues booting 3.10 3.11 3.12 or 3.13 in regards to things getting clobbered. but it does bring me back to my thought that u-boot should be calculating where to place everything to ensure that things do not get clobbered.
Most fedora i.MX6 users are using wandboards with a few utilites.
our wandboard config uses
fdt_high=0xffffffff initrd_high=0xffffffff fdt_addr=0x11100000 fdt_addr_r=0x11200000 pxefile_addr_r=0x11300000 scr_addr_r=0x11400000 kernel_addr_r=0x11500000 ramdisk_addr_r=0x13500000
I put 32M between the kernel and initramfs which can be wildly variable in size the install version is currently at 27M while our kernel is 4.6M
Dennis
On Thu, Nov 28, 2013 at 06:35:00PM -0600, Dennis Gilmore wrote:
El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sbabic@denx.de escribi?:
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
I missed this issue, too :-(
Does it work with your patch ? Most supported i.MX6 boards have more as 768MB, and I am wondering that all kernels can boot.
In fedora land we have not seen issues booting 3.10 3.11 3.12 or 3.13 in regards to things getting clobbered. but it does bring me back to my thought that u-boot should be calculating where to place everything to ensure that things do not get clobbered.
I know we talked on IRC yesterday, and this email predates that, but there's a lot of (potential) problems with "oh just let someone else figure out where to place things", such as "what is that thing going to do once it runs" ? I'm fine with (and would encourage) standardized names and a suggested base layout (ie memory base + 0x$FOO for ...)
Most fedora i.MX6 users are using wandboards with a few utilites.
our wandboard config uses
fdt_high=0xffffffff
Note that this disables relocation of the DT, which is what I was saying is the problem in the original patch, not the location.
El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sbabic@denx.de escribió:
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
I'm going to suggest this is the wrong path. Once you see i.MX systems with > 768MB DDR you're going to have initrd/fdt placed into memory Linux can't access without HIGHMEM on, and you need the FDT before then.
I didn't catch this case but it is a valid problem, indeed :-(
I missed this issue, too :-(
Does it work with your patch ? Most supported i.MX6 boards have more as 768MB, and I am wondering that all kernels can boot.
In fedora land we have not seen issues booting 3.10 3.11 3.12 or 3.13 in regards to things getting clobbered. but it does bring me back to my thought that u-boot should be calculating where to place everything to ensure that things do not get clobbered.
Most fedora i.MX6 users are using wandboards with a few utilites.
our wandboard config uses
fdt_high=0xffffffff initrd_high=0xffffffff fdt_addr=0x11100000 fdt_addr_r=0x11200000 pxefile_addr_r=0x11300000 scr_addr_r=0x11400000 kernel_addr_r=0x11500000 ramdisk_addr_r=0x13500000
I put 32M between the kernel and initramfs which can be wildly variable in size the install version is currently at 27M while our kernel is 4.6M
Dennis
participants (4)
-
Dennis Gilmore -
Otavio Salvador -
Stefano Babic -
Tom Rini