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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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 [email protected]
> 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 <[email protected]>
> > ---
> > 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
* Derald D. Woods <[email protected]> [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
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
On Tue, Dec 12, 2017 at 08:55:42AM -0800, Tony Lindgren wrote:
> * Derald D. Woods <[email protected]> [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 :)
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 <[email protected]> [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
* Derald D. Woods <[email protected]> [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 <[email protected]> [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
On Tue, Dec 12, 2017 at 10:15:03AM -0800, Tony Lindgren wrote:
> * Derald D. Woods <[email protected]> [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 <[email protected]> [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
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
On Tue, Dec 12, 2017 at 06:13:51PM -0600, Adam Ford wrote:
> On Dec 12, 2017 12:41 PM, "Ladislav Michl" <[email protected]> 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 [email protected]
> 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" <[email protected]> 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 [email protected]
> > 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" <[email protected]> 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 [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html