On Tue, Dec 12, 2017 at 06:13:51PM -0600, Adam Ford wrote:
> On Dec 12, 2017 12:41 PM, "Ladislav Michl" <la...@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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
