| Message ID | 20171212041213.27436-1-woods.technical@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 11, 2017 at 10:12:13PM -0600, Derald D. Woods wrote: > The partition information was omitted during the conversion to OMAP3430 > specific data. That could be intentional... > The data added by this commit is consistent with current U-Boot default > definitions. What about passing U-Boot partitions information to kernel instead? > Fixes: 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific device > tree processor data") > > Signed-off-by: Derald D. Woods <woods.technical@gmail.com> > --- > arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts > index 21a3b88aef0c..1220deb47aae 100644 > --- a/arch/arm/boot/dts/omap3-evm.dts > +++ b/arch/arm/boot/dts/omap3-evm.dts > @@ -85,5 +85,30 @@ > > #address-cells = <1>; > #size-cells = <1>; > + > + partition@0 { > + label = "spl"; > + reg = <0 0x80000>; > + }; > + partition@80000 { > + label = "u-boot"; > + reg = <0x80000 0x1c0000>; > + }; > + partition@240000 { > + label = "dtb"; > + reg = <0x240000 0x20000>; > + }; > + partition@260000 { > + label = "u-boot-env"; > + reg = <0x260000 0x20000>; > + }; > + partition@280000 { > + label = "kernel"; > + reg = <0x280000 0x600000>; > + }; > + partition@880000 { > + label = "rootfs"; > + reg = <0x880000 0>; > + }; > }; > }; > -- > 2.15.1 > > -- > 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
On Tue, Dec 12, 2017 at 07:39:30AM +0100, Ladislav Michl wrote: > On Mon, Dec 11, 2017 at 10:12:13PM -0600, Derald D. Woods wrote: > > The partition information was omitted during the conversion to OMAP3430 > > specific data. > > That could be intentional... I am fixing an addition that I created. > > > The data added by this commit is consistent with current U-Boot default > > definitions. > > What about passing U-Boot partitions information to kernel instead? > I am testing using an appended device-tree. This has been the most reliable method for the OMAP34XX boards that I have. If you have an example config, with working command line MTDPARTS, for beagleboard(Rev. C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note that other OMAP34XX boards currently provide a default partition layout. Is that bad practice for all of those as well? I am open to exploring the method that actually works. - Derald > > Fixes: 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific device > > tree processor data") > > > > Signed-off-by: Derald D. Woods <woods.technical@gmail.com> > > --- > > arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ > > 1 file changed, 25 insertions(+) > > > > diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts > > index 21a3b88aef0c..1220deb47aae 100644 > > --- a/arch/arm/boot/dts/omap3-evm.dts > > +++ b/arch/arm/boot/dts/omap3-evm.dts > > @@ -85,5 +85,30 @@ > > > > #address-cells = <1>; > > #size-cells = <1>; > > + > > + partition@0 { > > + label = "spl"; > > + reg = <0 0x80000>; > > + }; > > + partition@80000 { > > + label = "u-boot"; > > + reg = <0x80000 0x1c0000>; > > + }; > > + partition@240000 { > > + label = "dtb"; > > + reg = <0x240000 0x20000>; > > + }; > > + partition@260000 { > > + label = "u-boot-env"; > > + reg = <0x260000 0x20000>; > > + }; > > + partition@280000 { > > + label = "kernel"; > > + reg = <0x280000 0x600000>; > > + }; > > + partition@880000 { > > + label = "rootfs"; > > + reg = <0x880000 0>; > > + }; > > }; > > }; > > -- > > 2.15.1 > > > > -- > > 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
* Derald D. Woods <woods.technical@gmail.com> [171212 16:34]: > On Tue, Dec 12, 2017 at 07:39:30AM +0100, Ladislav Michl wrote: > > On Mon, Dec 11, 2017 at 10:12:13PM -0600, Derald D. Woods wrote: > > > The partition information was omitted during the conversion to OMAP3430 > > > specific data. > > > > That could be intentional... > > I am fixing an addition that I created. > > > > > > The data added by this commit is consistent with current U-Boot default > > > definitions. > > > > What about passing U-Boot partitions information to kernel instead? > > > > I am testing using an appended device-tree. This has been the most > reliable method for the OMAP34XX boards that I have. If you have an > example config, with working command line MTDPARTS, for beagleboard(Rev. > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > that other OMAP34XX boards currently provide a default partition > layout. Is that bad practice for all of those as well? I am open to > exploring the method that actually works. I think we came to the conclusion at some point that it's best to rely on u-boot passed partitions because with later u-boot versions the size was increased for the bootloader partition. Ideally of course we would read the partition information from the MTD device somewhere.. Regards, Tony -- 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 Tue, Dec 12, 2017 at 10:31:26AM -0600, Derald D. Woods wrote: > > What about passing U-Boot partitions information to kernel instead? > > I am testing using an appended device-tree. This has been the most > reliable method for the OMAP34XX boards that I have. If you have an > example config, with working command line MTDPARTS, for beagleboard(Rev. > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > that other OMAP34XX boards currently provide a default partition > layout. Is that bad practice for all of those as well? I am open to > exploring the method that actually works. Well, appended device tree is indeed good only for testing purposes where bootloader is unable to provide one. Problem with hardcoded partitions is that you need to keep bootloader and kernel view of partitions the same. That's why U-Boot introduced CONFIG_FDT_FIXUP_PARTITIONS which will add mtdparts into DTB. 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 Tue, Dec 12, 2017 at 08:55:42AM -0800, Tony Lindgren wrote: > * Derald D. Woods <woods.technical@gmail.com> [171212 16:34]: > > I am testing using an appended device-tree. This has been the most > > reliable method for the OMAP34XX boards that I have. If you have an > > example config, with working command line MTDPARTS, for beagleboard(Rev. > > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > > that other OMAP34XX boards currently provide a default partition > > layout. Is that bad practice for all of those as well? I am open to > > exploring the method that actually works. > > I think we came to the conclusion at some point that it's best to rely > on u-boot passed partitions because with later u-boot versions the > size was increased for the bootloader partition. > > Ideally of course we would read the partition information from the > MTD device somewhere.. Already done and called UBI :) -- 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 Tue, Dec 12, 2017 at 06:50:54PM +0100, Ladislav Michl wrote: > On Tue, Dec 12, 2017 at 08:55:42AM -0800, Tony Lindgren wrote: > > * Derald D. Woods <woods.technical@gmail.com> [171212 16:34]: > > > I am testing using an appended device-tree. This has been the most > > > reliable method for the OMAP34XX boards that I have. If you have an > > > example config, with working command line MTDPARTS, for beagleboard(Rev. > > > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > > > that other OMAP34XX boards currently provide a default partition > > > layout. Is that bad practice for all of those as well? I am open to > > > exploring the method that actually works. > > > > I think we came to the conclusion at some point that it's best to rely > > on u-boot passed partitions because with later u-boot versions the > > size was increased for the bootloader partition. > > > > Ideally of course we would read the partition information from the > > MTD device somewhere.. > > Already done and called UBI :) I am aware of all of these things. From an architectural standpoint I agree with everything that has been said. But has anyone checked booting lately? I helped fix an issue in U-Boot, a few months ago, where OMAP34XX boards could not boot for one and half releases. Structural changes were introduced, but booting was not verified on older OMAP3 boards. I will build with clean configs, for both U-Boot and Linux, and report my findings on this thread. I recently took over maintaining the OMAP3-EVM in U-Boot. This is why I am pursuing this effort. I am just looking for the consistent and bootable method going forward. It will be later tonight before I can verify builds. - Derald -- 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
* Derald D. Woods <woods.technical@gmail.com> [171212 18:11]: > On Tue, Dec 12, 2017 at 06:50:54PM +0100, Ladislav Michl wrote: > > On Tue, Dec 12, 2017 at 08:55:42AM -0800, Tony Lindgren wrote: > > > * Derald D. Woods <woods.technical@gmail.com> [171212 16:34]: > > > > I am testing using an appended device-tree. This has been the most > > > > reliable method for the OMAP34XX boards that I have. If you have an > > > > example config, with working command line MTDPARTS, for beagleboard(Rev. > > > > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > > > > that other OMAP34XX boards currently provide a default partition > > > > layout. Is that bad practice for all of those as well? I am open to > > > > exploring the method that actually works. > > > > > > I think we came to the conclusion at some point that it's best to rely > > > on u-boot passed partitions because with later u-boot versions the > > > size was increased for the bootloader partition. > > > > > > Ideally of course we would read the partition information from the > > > MTD device somewhere.. > > > > Already done and called UBI :) > > I am aware of all of these things. From an architectural standpoint I > agree with everything that has been said. But has anyone checked booting > lately? I helped fix an issue in U-Boot, a few months ago, where > OMAP34XX boards could not boot for one and half releases. Structural > changes were introduced, but booting was not verified on older OMAP3 > boards. I will build with clean configs, for both U-Boot and Linux, and > report my findings on this thread. I recently took over maintaining the > OMAP3-EVM in U-Boot. This is why I am pursuing this effort. I am just > looking for the consistent and bootable method going forward. It will be > later tonight before I can verify builds. Well that's good to hear :) My only concern with your patch is what happens if somebody boots with older u-boot with different partition sizes? Regards, Tony -- 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 Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote: > * Derald D. Woods <woods.technical@gmail.com> [171212 18:11]: > > On Tue, Dec 12, 2017 at 06:50:54PM +0100, Ladislav Michl wrote: > > > On Tue, Dec 12, 2017 at 08:55:42AM -0800, Tony Lindgren wrote: > > > > * Derald D. Woods <woods.technical@gmail.com> [171212 16:34]: > > > > > I am testing using an appended device-tree. This has been the most > > > > > reliable method for the OMAP34XX boards that I have. If you have an > > > > > example config, with working command line MTDPARTS, for beagleboard(Rev. > > > > > C4), Overo TOBI, or similiar OMAP34XX, I will gladly use it. Also note > > > > > that other OMAP34XX boards currently provide a default partition > > > > > layout. Is that bad practice for all of those as well? I am open to > > > > > exploring the method that actually works. > > > > > > > > I think we came to the conclusion at some point that it's best to rely > > > > on u-boot passed partitions because with later u-boot versions the > > > > size was increased for the bootloader partition. > > > > > > > > Ideally of course we would read the partition information from the > > > > MTD device somewhere.. > > > > > > Already done and called UBI :) > > > > I am aware of all of these things. From an architectural standpoint I > > agree with everything that has been said. But has anyone checked booting > > lately? I helped fix an issue in U-Boot, a few months ago, where > > OMAP34XX boards could not boot for one and half releases. Structural > > changes were introduced, but booting was not verified on older OMAP3 > > boards. I will build with clean configs, for both U-Boot and Linux, and > > report my findings on this thread. I recently took over maintaining the > > OMAP3-EVM in U-Boot. This is why I am pursuing this effort. I am just > > looking for the consistent and bootable method going forward. It will be > > later tonight before I can verify builds. > > Well that's good to hear :) My only concern with your patch is what > happens if somebody boots with older u-boot with different partition > sizes? I agree. The 'bootargs' mechanisms have seen some recent changes that may be a factor in what I am seeing. I had to include the command line in my config to test some NAND partitioning schemes and UBI. I am learning and Hopefully fixing some things as I go. - Derald -- 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 Tue, Dec 12, 2017 at 12:24:02PM -0600, Derald D. Woods wrote: > On Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote: > > Well that's good to hear :) My only concern with your patch is what > > happens if somebody boots with older u-boot with different partition > > sizes? > > I agree. The 'bootargs' mechanisms have seen some recent changes that > may be a factor in what I am seeing. I had to include the command line > in my config to test some NAND partitioning schemes and UBI. I am > learning and Hopefully fixing some things as I go. u-boot/board/isee/igep00x0/igep00x0.c is using only two MTD partitions, runtime generated. As OMAP's BootROM tries to read from atmost first four sectors before it gives up, size of SPL partiton is runtime generated according to NAND sector size. The rest of NAND is UBI managed. This of course breaks backward compatibility, but is unlikely to break in future. Someone needs to decide :) 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 Tue, Dec 12, 2017 at 06:13:51PM -0600, Adam Ford wrote: > On Dec 12, 2017 12:41 PM, "Ladislav Michl" <ladis@linux-mips.org> wrote: > > On Tue, Dec 12, 2017 at 12:24:02PM -0600, Derald D. Woods wrote: > > On Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote: > > > Well that's good to hear :) My only concern with your patch is what > > > happens if somebody boots with older u-boot with different partition > > > sizes? > > > It is for this reason that I submitted a patch for the logic PD Torpedo > board to remove the partitions from the device tree. > I used this same rationale when I updated the device-tree for omap3-evm. The issue is that the OMAP34XX boards have been left behind. Though the rationale is correct, it is not as applicable to SOC/board combinations that have not seen recent maintenance. Two things were apparent after some investigation: 1. There are no current OMAP34XX boards in U-Boot using CONFIG_OF_CONTROL for booting. I spent some time last night adding the use of OF_CONTROL for omap3-evm. Obviously no other boards have gone down this path, since the '.dtsi' files have yet to be included. I attempt to get this working over the next few days. The following U-Boot files will modified and added. modified: arch/arm/dts/Makefile modified: configs/omap3_evm_defconfig modified: include/configs/omap3_evm.h arch/arm/dts/omap-gpmc-smsc911x.dtsi arch/arm/dts/omap3-evm-37xx-u-boot.dtsi arch/arm/dts/omap3-evm-37xx.dts arch/arm/dts/omap3-evm-common.dtsi arch/arm/dts/omap3-evm-processor-common.dtsi arch/arm/dts/omap3-evm-u-boot.dtsi arch/arm/dts/omap3-evm.dts arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi arch/arm/dts/omap34xx.dtsi The Logic PD devkits(s) are the most recent additions and best examples to date. 2. The issue is really with passing the kernel command line. OMAP36XX boards seem to have the command line passed regardless of FDT usage. With OMAP34XX that is not the case. I have a BeageBoard(OMAP3530) and a BeagleBoard-xM(DM3730) to test with. This is an interesting test setup because they share the same U-Boot board files and general architecture. There is something different, with respect to kernel command line passing, between these OMAP3 variants. I will dig a bit deeper over the next few days. I just want to get the omap3-evm platform to work properly. I have a few of these systems. I/O and peripheral wise, they are the most complete test systems that I own. - Derald > > > > I agree. The 'bootargs' mechanisms have seen some recent changes that > > may be a factor in what I am seeing. I had to include the command line > > in my config to test some NAND partitioning schemes and UBI. I am > > learning and Hopefully fixing some things as I go. > > u-boot/board/isee/igep00x0/igep00x0.c is using only two MTD partitions, > runtime generated. As OMAP's BootROM tries to read from atmost first > four sectors before it gives up, size of SPL partiton is runtime > generated according to NAND sector size. The rest of NAND is UBI managed. > This of course breaks backward compatibility, but is unlikely to break > in future. Someone needs to decide :) > > 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 -- 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, Dec 13, 2017 at 07:44:25AM -0600, Derald D. Woods wrote: > On Tue, Dec 12, 2017 at 06:13:51PM -0600, Adam Ford wrote: > > On Dec 12, 2017 12:41 PM, "Ladislav Michl" <ladis@linux-mips.org> wrote: > > > > On Tue, Dec 12, 2017 at 12:24:02PM -0600, Derald D. Woods wrote: > > > On Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote: > > > > Well that's good to hear :) My only concern with your patch is what > > > > happens if somebody boots with older u-boot with different partition > > > > sizes? > > > > > > It is for this reason that I submitted a patch for the logic PD Torpedo > > board to remove the partitions from the device tree. > > > > I used this same rationale when I updated the device-tree for omap3-evm. > The issue is that the OMAP34XX boards have been left behind. Though the > rationale is correct, it is not as applicable to SOC/board combinations > that have not seen recent maintenance. > > Two things were apparent after some investigation: > > 1. There are no current OMAP34XX boards in U-Boot using > CONFIG_OF_CONTROL for booting. I spent some time last night adding > the use of OF_CONTROL for omap3-evm. Obviously no other boards have > gone down this path, since the '.dtsi' files have yet to be included. > I attempt to get this working over the next few days. The following > U-Boot files will modified and added. > > modified: arch/arm/dts/Makefile > modified: configs/omap3_evm_defconfig > modified: include/configs/omap3_evm.h > > arch/arm/dts/omap-gpmc-smsc911x.dtsi > arch/arm/dts/omap3-evm-37xx-u-boot.dtsi > arch/arm/dts/omap3-evm-37xx.dts > arch/arm/dts/omap3-evm-common.dtsi > arch/arm/dts/omap3-evm-processor-common.dtsi > arch/arm/dts/omap3-evm-u-boot.dtsi > arch/arm/dts/omap3-evm.dts > arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi > arch/arm/dts/omap34xx.dtsi > > The Logic PD devkits(s) are the most recent additions and best > examples to date. > > 2. The issue is really with passing the kernel command line. OMAP36XX > boards seem to have the command line passed regardless of FDT usage. > With OMAP34XX that is not the case. I have a BeageBoard(OMAP3530) and > a BeagleBoard-xM(DM3730) to test with. This is an interesting test > setup because they share the same U-Boot board files and general > architecture. There is something different, with respect to kernel > command line passing, between these OMAP3 variants. There really isn't anything special. Just fixup FDT before passing it to kernel. Btw, IGEPv2 boards come with both DM3730 and OMAP3530 and also NAND or OneNAND. All supported by single setup. > I will dig a bit deeper over the next few days. I just want to get the > omap3-evm platform to work properly. I have a few of these systems. I/O > and peripheral wise, they are the most complete test systems that I own. Please move this discussion to the U-Boot mailing list as it is getting off topic here. Thank you, ladis > - Derald > > > > > > > I agree. The 'bootargs' mechanisms have seen some recent changes that > > > may be a factor in what I am seeing. I had to include the command line > > > in my config to test some NAND partitioning schemes and UBI. I am > > > learning and Hopefully fixing some things as I go. > > > > u-boot/board/isee/igep00x0/igep00x0.c is using only two MTD partitions, > > runtime generated. As OMAP's BootROM tries to read from atmost first > > four sectors before it gives up, size of SPL partiton is runtime > > generated according to NAND sector size. The rest of NAND is UBI managed. > > This of course breaks backward compatibility, but is unlikely to break > > in future. Someone needs to decide :) > > > > 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 -- 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, Dec 13, 2017 at 04:05:06PM +0100, Ladislav Michl wrote: > On Wed, Dec 13, 2017 at 07:44:25AM -0600, Derald D. Woods wrote: > > On Tue, Dec 12, 2017 at 06:13:51PM -0600, Adam Ford wrote: > > > On Dec 12, 2017 12:41 PM, "Ladislav Michl" <ladis@linux-mips.org> wrote: > > > > > > On Tue, Dec 12, 2017 at 12:24:02PM -0600, Derald D. Woods wrote: > > > > On Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote: > > > > > Well that's good to hear :) My only concern with your patch is what > > > > > happens if somebody boots with older u-boot with different partition > > > > > sizes? > > > > > > > > > It is for this reason that I submitted a patch for the logic PD Torpedo > > > board to remove the partitions from the device tree. > > > > > > > I used this same rationale when I updated the device-tree for omap3-evm. > > The issue is that the OMAP34XX boards have been left behind. Though the > > rationale is correct, it is not as applicable to SOC/board combinations > > that have not seen recent maintenance. > > > > Two things were apparent after some investigation: > > > > 1. There are no current OMAP34XX boards in U-Boot using > > CONFIG_OF_CONTROL for booting. I spent some time last night adding > > the use of OF_CONTROL for omap3-evm. Obviously no other boards have > > gone down this path, since the '.dtsi' files have yet to be included. > > I attempt to get this working over the next few days. The following > > U-Boot files will modified and added. > > > > modified: arch/arm/dts/Makefile > > modified: configs/omap3_evm_defconfig > > modified: include/configs/omap3_evm.h > > > > arch/arm/dts/omap-gpmc-smsc911x.dtsi > > arch/arm/dts/omap3-evm-37xx-u-boot.dtsi > > arch/arm/dts/omap3-evm-37xx.dts > > arch/arm/dts/omap3-evm-common.dtsi > > arch/arm/dts/omap3-evm-processor-common.dtsi > > arch/arm/dts/omap3-evm-u-boot.dtsi > > arch/arm/dts/omap3-evm.dts > > arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi > > arch/arm/dts/omap34xx.dtsi > > > > The Logic PD devkits(s) are the most recent additions and best > > examples to date. > > > > 2. The issue is really with passing the kernel command line. OMAP36XX > > boards seem to have the command line passed regardless of FDT usage. > > With OMAP34XX that is not the case. I have a BeageBoard(OMAP3530) and > > a BeagleBoard-xM(DM3730) to test with. This is an interesting test > > setup because they share the same U-Boot board files and general > > architecture. There is something different, with respect to kernel > > command line passing, between these OMAP3 variants. > > There really isn't anything special. Just fixup FDT before passing it > to kernel. > I know. I am not asking about 'how it is done'. I am an engineer debugging something that actually is happening. > Btw, IGEPv2 boards come with both DM3730 and OMAP3530 and also NAND > or OneNAND. All supported by single setup. > As I stated, it does not have anything to do with the board setup. I was making that very point/observation. > > I will dig a bit deeper over the next few days. I just want to get the > > omap3-evm platform to work properly. I have a few of these systems. I/O > > and peripheral wise, they are the most complete test systems that I own. > > Please move this discussion to the U-Boot mailing list as it is getting > off topic here. Agreed. More investigation is required. - Derald > > Thank you, > ladis > > > - Derald > > > > > > > > > > I agree. The 'bootargs' mechanisms have seen some recent changes that > > > > may be a factor in what I am seeing. I had to include the command line > > > > in my config to test some NAND partitioning schemes and UBI. I am > > > > learning and Hopefully fixing some things as I go. > > > > > > u-boot/board/isee/igep00x0/igep00x0.c is using only two MTD partitions, > > > runtime generated. As OMAP's BootROM tries to read from atmost first > > > four sectors before it gives up, size of SPL partiton is runtime > > > generated according to NAND sector size. The rest of NAND is UBI managed. > > > This of course breaks backward compatibility, but is unlikely to break > > > in future. Someone needs to decide :) > > > > > > 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 -- 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-evm.dts b/arch/arm/boot/dts/omap3-evm.dts index 21a3b88aef0c..1220deb47aae 100644 --- a/arch/arm/boot/dts/omap3-evm.dts +++ b/arch/arm/boot/dts/omap3-evm.dts @@ -85,5 +85,30 @@ #address-cells = <1>; #size-cells = <1>; + + partition@0 { + label = "spl"; + reg = <0 0x80000>; + }; + partition@80000 { + label = "u-boot"; + reg = <0x80000 0x1c0000>; + }; + partition@240000 { + label = "dtb"; + reg = <0x240000 0x20000>; + }; + partition@260000 { + label = "u-boot-env"; + reg = <0x260000 0x20000>; + }; + partition@280000 { + label = "kernel"; + reg = <0x280000 0x600000>; + }; + partition@880000 { + label = "rootfs"; + reg = <0x880000 0>; + }; }; };
The partition information was omitted during the conversion to OMAP3430 specific data. The data added by this commit is consistent with current U-Boot default definitions. Fixes: 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific device tree processor data") Signed-off-by: Derald D. Woods <woods.technical@gmail.com> --- arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)