From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40D17C433F5 for ; Fri, 4 Mar 2022 06:57:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238589AbiCDG6E (ORCPT ); Fri, 4 Mar 2022 01:58:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234866AbiCDG6A (ORCPT ); Fri, 4 Mar 2022 01:58:00 -0500 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F0FE418DAB9; Thu, 3 Mar 2022 22:57:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 9549480E1; Fri, 4 Mar 2022 06:55:47 +0000 (UTC) Date: Fri, 4 Mar 2022 08:56:59 +0200 From: Tony Lindgren To: Adam Ford Cc: Linux-OMAP , "Andrew F . Davis" , Dave Gerlach , Faiz Abbas , Greg Kroah-Hartman , Keerthy , Nishanth Menon , Peter Ujfalusi , Roger Quadros , Suman Anna , Tero Kristo , Linux Kernel Mailing List , arm-soc , =?utf-8?B?QW5kcsOp?= Hentschel , "H . Nikolaus Schaller" Subject: Re: [PATCH 6/7] bus: ti-sysc: Implement SoC revision handling Message-ID: References: <20200221195256.54016-1-tony@atomide.com> <20200221195256.54016-7-tony@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, * Adam Ford [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. Regards, Tony