Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 2015-01-07 08:40:06, Tony Lindgren wrote:
> * Nishanth Menon <nm@xxxxxx> [150107 07:47]:
> > On 01/07/2015 03:57 AM, Pavel Machek wrote:
> > > On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
> > >> * Pavel Machek <pavel@xxxxxx> [150106 00:03]:
> > >>> On Mon 2015-01-05 15:02:29, Tony Lindgren wrote:
> > >>>> Revert "ARM: dts: Disable smc91x on n900 until bootloader
> > >>>> dependency is removed". We've now fixed the issues that
> > >>>> caused problems with uninitialized hardware depending on
> > >>>> the bootloader version. Mostly things got fixed with
> > >>>> the following commits:
> > >>>>
> > >>>> 9a894953a97b ("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")
> > >>>> 7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting")
> > >>>>
> > >>>> Note that this only affects the early development boards
> > >>>> with Ethernet that we still have in a few automated boot
> > >>>> test systems.
> > >>>>
> > >>>> Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > >>>
> > >>> Normally, the early development boards should have separate dts file
> > >>> (then include common parts), no?
> > >>
> > >> In this case it won't matter. The GPMC hardware is there, the probe
> > >> just fails if no smsc91x is found.
> > >>  
> > >>> Could you at least add a note to the dts file what is it? Because I
> > >>> always thought it is a bug.
> > >>
> > >> Sure, updated patch below. Can somebody please test boot it on
> > >> a production n900 too to make sure it no longer causes issues?
> > > 
> > > Actually... how do you manage your n900 to boot? Does it also boot
> > > from 0xffff?
> > > 
> > > I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot
> > > unless I somehow make dtb smaller... like the patch below.
> > > 
> > > ---
> > > 
> > > make dtb smaller so that it boots.
> > 
> > I am using chained boot (NOLO->u-boot->kernel (zImage +dtb
> > concatenated) on a real n900
> > 
> > I have the same issue as well. using omap2plus_defconfig.
> > I was able to bisect next tags as follows: next-20141128 worked,
> > next-20141201 stopped booting and the change was new dts addition,
> > removing the dts addition helped next-20141201 boot as well.
> > 
> > Current state:
> > 
> > https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
> > 
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
> > 
> > 
> > I had complained originally here:
> > http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following
> > up on the thread, got distracted.
> 
> Hmm strange a plain omap2plus_defconfig kernel boots just fine here.
> Also boots fine with appended DTB and 0xFFFF using something like:

Interesting.

> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb >  /tmp/zImage
> $ 0xFFFF -m /tmp/zImage -l -b

I'm doing something similar, with difference that I also pass
commandline using -b. 

> My boot log is appended in case that provides any clues. Note that
> I'm only loading it with -l and not flashing it though.

Ok, I'll try with defconfig, and am sending you my .config in case it
depends on it.
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: config.gz
Description: application/gzip


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux