Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
On Thu, Nov 28, 2013 at 06:35:00PM -0600, Dennis Gilmore wrote: El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sba...@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=0x Note that this disables relocation of the DT, which is what I was saying is the problem in the original patch, not the location. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sba...@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=0x initrd_high=0x fdt_addr=0x1110 fdt_addr_r=0x1120 pxefile_addr_r=0x1130 scr_addr_r=0x1140 kernel_addr_r=0x1150 ramdisk_addr_r=0x1350 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
El Wed, 27 Nov 2013 08:53:55 +0100 Stefano Babic sba...@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=0x initrd_high=0x fdt_addr=0x1110 fdt_addr_r=0x1120 pxefile_addr_r=0x1130 scr_addr_r=0x1140 kernel_addr_r=0x1150 ramdisk_addr_r=0x1350 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
On Wed, Nov 27, 2013 at 5:53 AM, Stefano Babic sba...@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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[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: 0x1100. 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 @0x1100 with fdt_addr=0x1100 | | To expand the fdt_addr from 0x1100 to 0x1800, 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 ota...@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=0x\0 \ - initrd_high=0x\0 \ fdt_addr=0x1100\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=0x\0 \ - initrd_high=0x\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=0x\0 \ - initrd_high=0x\0 \ fdt_file=imx6q-sabrelite.dtb\0 \ fdt_addr=0x1100\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=0x\0 \ - initrd_high=0x\0 \ fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \ fdt_addr=0x1100\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=0x\0 \ - initrd_high=0x\0 \ fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \ fdt_addr=0x1100\0 \ boot_fdt=try\0 \ -- 1.8.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
On Tue, Nov 26, 2013 at 10:11 AM, Tom Rini tr...@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: 0x1100. 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 @0x1100 with fdt_addr=0x1100 | | To expand the fdt_addr from 0x1100 to 0x1800, 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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
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: 0x1100. 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 @0x1100 with fdt_addr=0x1100 | | To expand the fdt_addr from 0x1100 to 0x1800, 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. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping
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 -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
