| Message ID | 8dcf3efd3270451314a663c125841ca87ed2b387.1532501910.git.hns@goldelico.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/32] ARM: dts: omap3-gta04: fix typo in backlight pins node name | expand |
On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > Vendor defined U-Boot has changed the partition scheme a while ago: > > * kernel partition 6MB > * file system partition uses the remainder up to end of the NAND > * increased size of the environment partition (to get an OneNAND compatible base address) > * shrink the U-Boot partition > > Let's be compatible (e.g. Debian kernel built from upstream). That, in fact, is breaking compatibility. So once you are touching this what about relying on partitioning provided by bootloader just to prevent something like this happening again? ladis > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > --- > arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi > index 65f77a0b5dd4..03fe404cbf56 100644 > --- a/arch/arm/boot/dts/omap3-gta04.dtsi > +++ b/arch/arm/boot/dts/omap3-gta04.dtsi > @@ -645,22 +645,22 @@ > > bootloaders@80000 { > label = "U-Boot"; > - reg = <0x80000 0x1e0000>; > + reg = <0x80000 0x1c0000>; > }; > > - bootloaders_env@260000 { > + bootloaders_env@240000 { > label = "U-Boot Env"; > - reg = <0x260000 0x20000>; > + reg = <0x240000 0x40000>; > }; > > kernel@280000 { > label = "Kernel"; > - reg = <0x280000 0x400000>; > + reg = <0x280000 0x600000>; > }; > > - filesystem@680000 { > + filesystem@880000 { > label = "File System"; > - reg = <0x680000 0xf980000>; > + reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ > }; > }; > }; > -- > 2.12.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: >> Vendor defined U-Boot has changed the partition scheme a while ago: >> >> * kernel partition 6MB >> * file system partition uses the remainder up to end of the NAND >> * increased size of the environment partition (to get an OneNAND compatible base address) >> * shrink the U-Boot partition >> >> Let's be compatible (e.g. Debian kernel built from upstream). > > That, in fact, is breaking compatibility. With what? Nobody is using the old u-boot partition scheme any more (it is >5 years old). > So once you are touching this > what about relying on partitioning provided by bootloader just to prevent > something like this happening again? Well, we define what compatible means here (since we are the vendor). And people complain with us. We simply recommend them to upgrade the boot-loader. BR, Nikolaus > > ladis > >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >> --- >> arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi >> index 65f77a0b5dd4..03fe404cbf56 100644 >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi >> @@ -645,22 +645,22 @@ >> >> bootloaders@80000 { >> label = "U-Boot"; >> - reg = <0x80000 0x1e0000>; >> + reg = <0x80000 0x1c0000>; >> }; >> >> - bootloaders_env@260000 { >> + bootloaders_env@240000 { >> label = "U-Boot Env"; >> - reg = <0x260000 0x20000>; >> + reg = <0x240000 0x40000>; >> }; >> >> kernel@280000 { >> label = "Kernel"; >> - reg = <0x280000 0x400000>; >> + reg = <0x280000 0x600000>; >> }; >> >> - filesystem@680000 { >> + filesystem@880000 { >> label = "File System"; >> - reg = <0x680000 0xf980000>; >> + reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ >> }; >> }; >> }; >> -- >> 2.12.2 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Am 25.07.2018 um 10:18 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > >> Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: >> >> On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: >>> Vendor defined U-Boot has changed the partition scheme a while ago: >>> >>> * kernel partition 6MB >>> * file system partition uses the remainder up to end of the NAND >>> * increased size of the environment partition (to get an OneNAND compatible base address) >>> * shrink the U-Boot partition >>> >>> Let's be compatible (e.g. Debian kernel built from upstream). >> >> That, in fact, is breaking compatibility. > > With what? Nobody is using the old u-boot partition scheme any more > (it is >5 years old). > >> So once you are touching this >> what about relying on partitioning provided by bootloader just to prevent >> something like this happening again? > > Well, we define what compatible means here (since we are the vendor). > And people complain with us. We simply recommend them to upgrade the > boot-loader. I should also mention that a modern and fully configured kernel binary is already too big for a 4MB kernel partition. > > >> >> ladis >> >>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>> --- >>> arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++++++------ >>> 1 file changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi >>> index 65f77a0b5dd4..03fe404cbf56 100644 >>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi >>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi >>> @@ -645,22 +645,22 @@ >>> >>> bootloaders@80000 { >>> label = "U-Boot"; >>> - reg = <0x80000 0x1e0000>; >>> + reg = <0x80000 0x1c0000>; >>> }; >>> >>> - bootloaders_env@260000 { >>> + bootloaders_env@240000 { >>> label = "U-Boot Env"; >>> - reg = <0x260000 0x20000>; >>> + reg = <0x240000 0x40000>; >>> }; >>> >>> kernel@280000 { >>> label = "Kernel"; >>> - reg = <0x280000 0x400000>; >>> + reg = <0x280000 0x600000>; >>> }; >>> >>> - filesystem@680000 { >>> + filesystem@880000 { >>> label = "File System"; >>> - reg = <0x680000 0xf980000>; >>> + reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ >>> }; >>> }; >>> }; >>> -- >>> 2.12.2 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > _______________________________________________ > http://projects.goldelico.com/p/gta04-kernel/ > Letux-kernel mailing list > Letux-kernel@openphoenux.org > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: > > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > >> Vendor defined U-Boot has changed the partition scheme a while ago: > >> > >> * kernel partition 6MB > >> * file system partition uses the remainder up to end of the NAND > >> * increased size of the environment partition (to get an OneNAND compatible base address) > >> * shrink the U-Boot partition > >> > >> Let's be compatible (e.g. Debian kernel built from upstream). > > > > That, in fact, is breaking compatibility. > > With what? Nobody is using the old u-boot partition scheme any more > (it is >5 years old). > > > So once you are touching this > > what about relying on partitioning provided by bootloader just to prevent > > something like this happening again? > > Well, we define what compatible means here (since we are the vendor). > And people complain with us. We simply recommend them to upgrade the > boot-loader. Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether and let U-Boot provide one. But you being vendor you decide, of course :) (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store everything in UBI volumes. That's a bit more flexible approach) ladis > BR, > Nikolaus > > > > > ladis > > > >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > >> --- > >> arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++++++------ > >> 1 file changed, 6 insertions(+), 6 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi > >> index 65f77a0b5dd4..03fe404cbf56 100644 > >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi > >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi > >> @@ -645,22 +645,22 @@ > >> > >> bootloaders@80000 { > >> label = "U-Boot"; > >> - reg = <0x80000 0x1e0000>; > >> + reg = <0x80000 0x1c0000>; > >> }; > >> > >> - bootloaders_env@260000 { > >> + bootloaders_env@240000 { > >> label = "U-Boot Env"; > >> - reg = <0x260000 0x20000>; > >> + reg = <0x240000 0x40000>; > >> }; > >> > >> kernel@280000 { > >> label = "Kernel"; > >> - reg = <0x280000 0x400000>; > >> + reg = <0x280000 0x600000>; > >> }; > >> > >> - filesystem@680000 { > >> + filesystem@880000 { > >> label = "File System"; > >> - reg = <0x680000 0xf980000>; > >> + reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ > >> }; > >> }; > >> }; > >> -- > >> 2.12.2 > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Am 25.07.2018 um 10:33 schrieb Ladislav Michl <ladis@linux-mips.org>: > > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: >> >>> Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: >>> >>> On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: >>>> Vendor defined U-Boot has changed the partition scheme a while ago: >>>> >>>> * kernel partition 6MB >>>> * file system partition uses the remainder up to end of the NAND >>>> * increased size of the environment partition (to get an OneNAND compatible base address) >>>> * shrink the U-Boot partition >>>> >>>> Let's be compatible (e.g. Debian kernel built from upstream). >>> >>> That, in fact, is breaking compatibility. >> >> With what? Nobody is using the old u-boot partition scheme any more >> (it is >5 years old). >> >>> So once you are touching this >>> what about relying on partitioning provided by bootloader just to prevent >>> something like this happening again? >> >> Well, we define what compatible means here (since we are the vendor). >> And people complain with us. We simply recommend them to upgrade the >> boot-loader. > > Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether > and let U-Boot provide one. But you being vendor you decide, of course :) > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store > everything in UBI volumes. That's a bit more flexible approach) Yes, that is a good goal for a future setup and would of course be better. Like U-Boot already provides the memory layout for RAM. Hopefully, someone will work out patches for u-boot plus kernel (which is always painful to keep these two in sync and tested). But I don't want to do that now. BR and thanks, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 25, 2018 at 02:27:31PM +0200, H. Nikolaus Schaller wrote: > > > Am 25.07.2018 um 10:33 schrieb Ladislav Michl <ladis@linux-mips.org>: > > > > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: > >> > >>> Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: > >>> > >>> On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > >>>> Vendor defined U-Boot has changed the partition scheme a while ago: > >>>> > >>>> * kernel partition 6MB > >>>> * file system partition uses the remainder up to end of the NAND > >>>> * increased size of the environment partition (to get an OneNAND compatible base address) > >>>> * shrink the U-Boot partition > >>>> > >>>> Let's be compatible (e.g. Debian kernel built from upstream). > >>> > >>> That, in fact, is breaking compatibility. > >> > >> With what? Nobody is using the old u-boot partition scheme any more > >> (it is >5 years old). > >> > >>> So once you are touching this > >>> what about relying on partitioning provided by bootloader just to prevent > >>> something like this happening again? > >> > >> Well, we define what compatible means here (since we are the vendor). > >> And people complain with us. We simply recommend them to upgrade the > >> boot-loader. > > > > Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether > > and let U-Boot provide one. But you being vendor you decide, of course :) > > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store > > everything in UBI volumes. That's a bit more flexible approach) > > Yes, that is a good goal for a future setup and would of course be better. > Like U-Boot already provides the memory layout for RAM. > > Hopefully, someone will work out patches for u-boot plus kernel (which is always > painful to keep these two in sync and tested). But I don't want to do that now. At kernel side the only patch needed is to remove partitioning scheme from DTB and u-boot setup can be merely copied from board/isee/igep00x0 Not having hardware I cannot really test it ;-) Best regards, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 25 Jul 2018 10:33:05 +0200 Ladislav Michl <ladis@linux-mips.org> wrote: > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: > > > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: > > > > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > > >> Vendor defined U-Boot has changed the partition scheme a while ago: > > >> > > >> * kernel partition 6MB > > >> * file system partition uses the remainder up to end of the NAND > > >> * increased size of the environment partition (to get an OneNAND compatible base address) > > >> * shrink the U-Boot partition > > >> > > >> Let's be compatible (e.g. Debian kernel built from upstream). > > > > > > That, in fact, is breaking compatibility. > > > > With what? Nobody is using the old u-boot partition scheme any more > > (it is >5 years old). > > > > > So once you are touching this > > > what about relying on partitioning provided by bootloader just to prevent > > > something like this happening again? > > > > Well, we define what compatible means here (since we are the vendor). > > And people complain with us. We simply recommend them to upgrade the > > boot-loader. > > Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether > and let U-Boot provide one. But you being vendor you decide, of course :) > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store > everything in UBI volumes. That's a bit more flexible approach) > hmm, so using mtdparts kernel commandline parameter? Somehow it sounds to be sane to not have partition tables in kernel. What only is needed is to have a nice transition scheme for systems in the wild, can commandline mtdparts overwrite dtb? So dtb is a fallback? But I think all that is a future improvement? Regards, Andreas
On Wed, Jul 25, 2018 at 06:27:45PM +0200, Andreas Kemnade wrote: > On Wed, 25 Jul 2018 10:33:05 +0200 > Ladislav Michl <ladis@linux-mips.org> wrote: > > > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: > > > > > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@linux-mips.org>: > > > > > > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > > > >> Vendor defined U-Boot has changed the partition scheme a while ago: > > > >> > > > >> * kernel partition 6MB > > > >> * file system partition uses the remainder up to end of the NAND > > > >> * increased size of the environment partition (to get an OneNAND compatible base address) > > > >> * shrink the U-Boot partition > > > >> > > > >> Let's be compatible (e.g. Debian kernel built from upstream). > > > > > > > > That, in fact, is breaking compatibility. > > > > > > With what? Nobody is using the old u-boot partition scheme any more > > > (it is >5 years old). > > > > > > > So once you are touching this > > > > what about relying on partitioning provided by bootloader just to prevent > > > > something like this happening again? > > > > > > Well, we define what compatible means here (since we are the vendor). > > > And people complain with us. We simply recommend them to upgrade the > > > boot-loader. > > > > Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether > > and let U-Boot provide one. But you being vendor you decide, of course :) > > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store > > everything in UBI volumes. That's a bit more flexible approach) > > > hmm, so using mtdparts kernel commandline parameter? Somehow it sounds > to be sane to not have partition tables in kernel. What only is needed > is to have a nice transition scheme for systems in the wild, can > commandline mtdparts overwrite dtb? So dtb is a fallback? That's beginning to be offtopic here... Anyway, see U-Boot's CONFIG_FDT_FIXUP_PARTITIONS. Probably better to start a thread on U-Boot mailing list if needed. > But I think all that is a future improvement? Depends on vendor decision, it could be done in a few days :) Best regards, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index 65f77a0b5dd4..03fe404cbf56 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -645,22 +645,22 @@ bootloaders@80000 { label = "U-Boot"; - reg = <0x80000 0x1e0000>; + reg = <0x80000 0x1c0000>; }; - bootloaders_env@260000 { + bootloaders_env@240000 { label = "U-Boot Env"; - reg = <0x260000 0x20000>; + reg = <0x240000 0x40000>; }; kernel@280000 { label = "Kernel"; - reg = <0x280000 0x400000>; + reg = <0x280000 0x600000>; }; - filesystem@680000 { + filesystem@880000 { label = "File System"; - reg = <0x680000 0xf980000>; + reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ }; }; };
Vendor defined U-Boot has changed the partition scheme a while ago: * kernel partition 6MB * file system partition uses the remainder up to end of the NAND * increased size of the environment partition (to get an OneNAND compatible base address) * shrink the U-Boot partition Let's be compatible (e.g. Debian kernel built from upstream). Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)