Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko <denys@ti.com>]

On Wed, Jan 20, 2016 at 07:58:30PM -0600, Troy Benjegerdes wrote:
> On Tue, Jan 19, 2016 at 02:08:08PM -0500, Denys Dmytriyenko wrote:
> > On Mon, Jan 18, 2016 at 02:05:07PM -0600, Troy Benjegerdes wrote:
> > > On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> > > > On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > > > > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > > > > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > > > > of the 2.6.x series, and it seems like somewhere along the way something
> > > > > broke, and I'm trying to figure out what it was.
> > > > 
> > > > Do you have any specifics for the breakage?
> > > > 
> > > > -- 
> > > > Denys
> > > 
> > > The kernel stops after discovering the MMC, but before mounting the 
> > > filesystem:
> > > 
> > > [    2.446441] Key type dns_resolver registered
> > > [    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
> > > [    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
> > > [    2.479156] PM: no software I/O chain control; some wakeups may be lost
> > > [    2.486816] ThumbEE CPU extension supported.
> > > [    2.491363] Registering SWP/SWPB emulation handler
> > > [    2.503784] regulator-dummy: incomplete constraints, leaving on
> > > [    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
> > > [    2.622650] Waiting for root device /dev/mmcblk0p2...
> > > [    2.629638] mmc0: new high speed SDHC card at address aaaa
> > > [    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
> > 
> > Looks like it did not recognize the partitions on the MMC, hence waiting for 
> > the second partition /dev/mmcblk0p2 to become available to mount root from.
> 
> Didn't 3.x kernels start requiring a device tree somewhere along the line?
> 
> I know the Beaglebone uses a device tree, but I can't seem to manage find
> all the right pieces to build a working u-boot for am3517-evm that can 
> properly pass it off to the kernel, at least with the Legacy image format(s).

Well, am3517 is one of the legacy platforms and I don't believe it was ever 
converted to use device tree...

-- 
Denys


> So speaking of which, what prevents us from using the CONFIG_OF_CONTROL
> options in u-boot so we could have the same u-boot binary work on both a
> beaglebone and an am3517 based platform, provided you have the right device
> trees for each board?