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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
