lkml.org 
[lkml]   [2017]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ARM: dts: omap3-evm: Fix missing NAND partition information
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

\
 
 \ /
  Last update: 2017-12-13 16:36    [W:0.047 / U:3.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site