> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, September 09, 2010 9:25 PM > To: Shilimkar, Santosh > Cc: linux-omap@xxxxxxxxxxxxxxx; tony@xxxxxxxxxxx > Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 > > "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> writes: > > >> -----Original Message----- > >> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > >> Sent: Thursday, September 09, 2010 8:52 PM > >> To: Shilimkar, Santosh > >> Cc: linux-omap@xxxxxxxxxxxxxxx; tony@xxxxxxxxxxx > >> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 > >> > >> Santosh Shilimkar <santosh.shilimkar@xxxxxx> writes: > >> > >> > This series has few fixes, hacks to get omap4 es2.0 working > >> > on mainline. The patches are generated against the mainline > >> > 2.6.36-rc3. > >> > >> Hi Santosh, thanks for this... > >> > >> > The series is boot tested tested on 4430 SDP, Blaze with > >> > omap_4430sdp_defconfig with file over NFS and MMC. > >> > > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 > >> > SDPs. Same observation with Panda > >> > > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the > >> > boot hangs. Same observation with Panda > >> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series. > >> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA. > > Note that I said "now working". I think you read my message as "not > working." > Yes I read it otherway ... Second time today :) > IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied > your series to current l-o master, and it works. > Cool!! > >> However, rootfs over NFS is not yet working, presumably because the > >> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work > >> properly. > >> > > This is correct. We need to get the MMC fixed o.w panda is unusable in > > it's current form. > > > >> > >> > [ 5.794616] regulator_init_complete: incomplete constraints, > leaving > >> VUSIM on > >> > [ 5.802764] regulator_init_complete: incomplete constraints, > leaving > >> VPP on > >> > [ 5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 > >> 00:53:12 UTC (9 ) > >> > [ 5.849304] mmc0: new high speed MMC card at address 0001 > >> > [ 5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB > >> > [ 5.862091] mmcblk0: unknown partition table > >> > [ 6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate > >> latency 0: 6 > >> > >> Based on this message, this is not a mainline kernel, but one where the > >> omap_device conversion for MMC has been applied. > >> > > This is mainline 2.6.36-rc3.... > > http://dev.omapzoom.org/?p=santosh/kernel-omap4- > base.git;a=shortlog;h=refs/heads/omap4-for-tony > > Then I don't understand where the 'omap_device: mmci-omap-hs.1:...' > message is coming from in your kernel boot log. > > It should not be present in a mainline kernel as the MMC conversion to > hwmod/omap_device is not in mainline, or linux-omap. > > That's why I assumed your boot log excerpt came from an internal kernel > and not a mainline kernel. > I might have mixed kernel Images ... Just too many things together :( Regards, Santosh -- 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
