ARM: dts: omap3-evm: Fix missing NAND partition information
PATCH 1/1 ARM: dts: omap3-evm: Fix missing NAND partition information
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.
tree processor data")
--- arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
arch/arm/boot/dts/omap3-evm.dts +25 -0
@@ -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>; + }; }; };
Signature · 1 line
2.15.1
Quoted 2 lines · Derald D. Woods
The partition information was omitted during the conversion to OMAP3430 specific data.
That could be intentional...
Quoted 2 lines
The data added by this commit is consistent with current U-Boot default definitions.
What about passing U-Boot partitions information to kernel instead?
Quoted 50 lines
Fixes 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific devicetree processor data")
Signed-off-by Derald D. Woods <[email protected]>--- arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)arch/arm/boot/dts/omap3-evm.dts +25
-0@@ -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>; + }; }; };Signature · 6 lines
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
Quoted 5 lines · Ladislav Michl
Quoted 2 lines · Derald D. Woods
The partition information was omitted during the conversion to OMAP3430 specific data.
That could be intentional...
I am fixing an addition that I created.
Quoted 6 lines
Quoted 3 lines
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
Quoted 50 lines
Quoted 50 lines
Fixes 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific devicetree processor data")
Signed-off-by Derald D. Woods <[email protected]>--- arch/arm/boot/dts/omap3-evm.dts | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)arch/arm/boot/dts/omap3-evm.dts +25
-0@@ -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>; + }; }; };Signature · 6 lines
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
Quoted 16 lines · Derald D. Woods
Quoted 5 lines · Ladislav Michl
Quoted 2 lines · Derald D. Woods
The partition information was omitted during the conversion to OMAP3430 specific data.
That could be intentional...
I am fixing an addition that I created.
Quoted 6 lines
Quoted 3 lines
The data added by this commit is consistent with current U-Boot default definitions.
What about passing U-Boot partitions information to kernel instead?
Quoted 7 lines
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
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Derald D. Woods
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.
Quoted 6 lines
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 :)
Quoted 10 lines · Ladislav Michl
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Derald D. Woods
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.
Quoted 8 lines
Quoted 6 lines
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
Quoted 20 lines · Derald D. Woods
Quoted 10 lines · Ladislav Michl
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Derald D. Woods
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.
Quoted 8 lines
Quoted 6 lines
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 :)
Quoted 10 lines
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
Quoted 32 lines · Tony Lindgren
Quoted 20 lines · Derald D. Woods
Quoted 10 lines · Ladislav Michl
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Derald D. Woods
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.
Quoted 8 lines
Quoted 6 lines
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 :)
Quoted 10 lines
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.
Quoted 3 lines
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
Quoted 9 lines · Derald D. Woods
Quoted 3 lines · Tony Lindgren
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
A message that is not in the archive (sent off-list or not yet received): CAHCN7xKn2-6NVhy6MegJgEZrF3=DFigvHW6xf0Gb2BFRTJMDNw@mail.gmail.com
Quoted 12 lines · Adam Ford
On Dec 12, 2017 12:41 PM, "Ladislav Michl" <[email protected]> wrote:
Quoted 4 lines · Derald D. Woods
Quoted 3 lines · Tony Lindgren
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
Quoted 18 lines
Quoted 5 lines
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.cis 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
Quoted 45 lines · Derald D. Woods
Quoted 12 lines · Adam Ford
On Dec 12, 2017 12:41 PM, "Ladislav Michl" <[email protected]> wrote:
Quoted 4 lines · Derald D. Woods
Quoted 3 lines · Tony Lindgren
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_CONTROLfor booting. I spent some time last night adding the use ofOF_CONTROLfor 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.harch/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.dtsiThe Logic PD devkits(s) are the most recent additions and best examples to date.
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 20 lines
- Derald
Quoted 18 lines
Quoted 5 lines
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.cis 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
Quoted 54 lines · Ladislav Michl
Quoted 45 lines · Derald D. Woods
Quoted 12 lines · Adam Ford
On Dec 12, 2017 12:41 PM, "Ladislav Michl" <[email protected]> wrote:
Quoted 4 lines · Derald D. Woods
Quoted 3 lines · Tony Lindgren
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_CONTROLfor booting. I spent some time last night adding the use ofOF_CONTROLfor 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.harch/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.dtsiThe Logic PD devkits(s) are the most recent additions and best examples to date.
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 24 lines
Thank you,
ladisQuoted 20 lines
- Derald
Quoted 18 lines
Quoted 5 lines
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.cis 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
Quoted 9 lines · Derald D. Woods
Quoted 1 line
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