Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20200221195256.54016-1-tony@atomide.com> <20200221195256.54016-7-tony@atomide.com>
 <CAHCN7xJ0j4kZXiQs-5GrrKLxXYgkYJsnNDreH0MKi8mHPs_Xvw@mail.gmail.com> <YiG4O2h4oVX7CqIe@atomide.com>
In-Reply-To: <YiG4O2h4oVX7CqIe@atomide.com>
From:   Adam Ford <aford173@gmail.com>
Date:   Fri, 4 Mar 2022 07:57:35 -0600
Message-ID: <CAHCN7xKL8x2=As35PG4T_qbgvqReVk8i_+SaibK9zF86+tGVZQ@mail.gmail.com>
Subject: Re: [PATCH 6/7] bus: ti-sysc: Implement SoC revision handling
To:     Tony Lindgren <tony@atomide.com>
Cc:     Linux-OMAP <linux-omap@vger.kernel.org>,
        "Andrew F . Davis" <afd@ti.com>, Dave Gerlach <d-gerlach@ti.com>,
        Faiz Abbas <faiz_abbas@ti.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Keerthy <j-keerthy@ti.com>, Nishanth Menon <nm@ti.com>,
        Peter Ujfalusi <peter.ujfalusi@ti.com>,
        Roger Quadros <rogerq@ti.com>, Suman Anna <s-anna@ti.com>,
        Tero Kristo <t-kristo@ti.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        arm-soc <linux-arm-kernel@lists.infradead.org>,
        =?UTF-8?Q?Andr=C3=A9_Hentschel?= <nerv@dawncrow.de>,
        "H . Nikolaus Schaller" <hns@goldelico.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Mar 4, 2022 at 12:57 AM Tony Lindgren <tony@atomide.com> wrote:
>
> Hi,
>
> * Adam Ford <aford173@gmail.com> [220302 14:37]:
> > I apologize for digging up an old thread, but I finally managed to get
> > my hands on an OMAP3503.  It seems like older kernels do not boot at
> > all or hang somewhere in the boot process.  I am still seeing a
> > difference in behavior between OMAP3503 and OMAP3530, where 3505
> > throws a bunch of splat and a kernel panic, while the 3530 appears to
> > boot happily.
> >
> > Using the latest 5.17-rc6, I had to remove some IVA and SGX references
> > from omap_l3_smx.h to get the 3503 to stop crashing on boot.
>
> OK interesting, I did not know those registers are not accessible
> on 3503.
>
> > Do you have any ideas how we can make the omap3_l3_app_bases and
> > omap3_l3_debug_bases more cleanly remove the IVA and SGX references
> > if/when OMAP3503 is detected?  I assume the same algorithm would have
> > to detect a AM3703 as well.  I'm trying to get my hands on an AM3703
> > to see if there is similar behavior as what I'm seeing on the
> > OMAP3503.
>
> As there are possibly multiple omap3 variants used on the same
> boards, we need to rely on the runtime detection of the SoC.
> So yeah soc_device_attribute is the way to go here.
>
> I don't recall any similar issues booting 3703 but it's been a while
> so worth testing for sure.

In addition to the OMAP3503, I managed to get an AM3703.  From what I
can tell, going back as far as kernel 4.9, the OMAP3503 does not boot
at all. I haven't tried the 4.4 since it's marked EOL at this point.

I have not started testing the AM3703 yet, but I think it would be a
good idea to backport this to stable at some point, since it appears
to fix a serious regression,  not booting.  I'm going to work on some
experiments with both the AM3703 and OMAP3503 to see what works, what
doesn't and I'm going try to come up with some ideas on how to address
the omap3_l3_app changes, but if you have any ideas on how to do it
cleanly, I'm open for suggestions.

adam
>
> Regards,
>
> Tony