linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@bootlin.com>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: "Paul Burton" <paulburton@kernel.org>,
	linux-mips@vger.kernel.org,
	"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>,
	"Tawfik Bayouk" <tawfik.bayouk@mobileye.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Théo Lebrun" <theo.lebrun@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC
Date: Thu, 21 Dec 2023 16:26:02 +0100	[thread overview]
Message-ID: <87a5q3bmr9.fsf@BL-laptop> (raw)
In-Reply-To: <ZYRR7zIZax7yUgsZ@alpha.franken.de>

Thomas Bogendoerfer <tsbogend@alpha.franken.de> writes:

> On Thu, Dec 21, 2023 at 08:57:55AM +0100, Gregory CLEMENT wrote:
>> I do not oppose the addition of a new platform, even though, like
>> Jiaxun, I would prefer to avoid duplicating code. The only thing
>> preventing the use of the same kernel for EyeQ5 and other platforms is
>> the starting address.
>
> there shouldn't be code duplication.
>
> My rough idea would be something like

Thanks for the feedback, I am going to test it.

>
> diff --git a/arch/mips/Kbuild b/arch/mips/Kbuild
> index af2967bffb73..d683993ed331 100644
> --- a/arch/mips/Kbuild
> +++ b/arch/mips/Kbuild
> @@ -17,6 +17,7 @@ obj- := $(platform-y)
>  # mips object files
>  # The object files are linked as core-y files would be linked
>  
> +obj-y += generic/
>  obj-y += kernel/
>  obj-y += mm/
>  obj-y += net/
> diff --git a/arch/mips/generic/Makefile b/arch/mips/generic/Makefile
> index e37a59bae0a6..56011d738441 100644
> --- a/arch/mips/generic/Makefile
> +++ b/arch/mips/generic/Makefile
> @@ -4,9 +4,9 @@
>  # Author: Paul Burton <paul.burton@mips.com>
>  #
>  
> -obj-y += init.o
> -obj-y += irq.o
> -obj-y += proc.o
> +obj-$(CONFIG_MACH_GENERIC_CORE) += init.o
> +obj-$(CONFIG_MACH_GENERIC_CORE) += irq.o
> +obj-$(CONFIG_MACH_GENERIC_CORE) += proc.o
>  
>  obj-$(CONFIG_YAMON_DT_SHIM)            += yamon-dt.o
>  obj-$(CONFIG_LEGACY_BOARD_SEAD3)       += board-sead3.o
>
> so everyboady needing these parts of a generic kernel is able
> to take it.
>
>> Therefore, if it were possible to have a relocatable kernel, this
>> issue would disappear.
>
> yes. There is support for relocatable kernel, so what are we missing
> there ?

But in arch/mips/generic/Platform we have:

load-$(CONFIG_MIPS_GENERIC)    += 0xffffffff80100000

So, the load address is defined during compilation; for example, I don't
think there is such a mechanism currently for ARM. hat's what I mean by
'relocatable,' but perhaps it's not exactly what you have in mind.

Gregory

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

  reply	other threads:[~2023-12-21 15:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 16:34 [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 01/22] MIPS: compressed: Use correct instruction for 64 bit code Gregory CLEMENT
2023-12-21 14:38   ` Thomas Bogendoerfer
2023-12-12 16:34 ` [PATCH v5 02/22] MIPS: Export higher/highest relocation functions in uasm Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 03/22] MIPS: spaces: Define a couple of handy macros Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 04/22] MIPS: genex: Fix except_vec_vi for kernel in XKPHYS Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 05/22] MIPS: Fix set_uncached_handler for ebase " Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 06/22] MIPS: Refactor mips_cps_core_entry implementation Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 07/22] MIPS: Fix cache issue with mips_cps_core_entry Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 08/22] MIPS: Allow kernel base to be set from Kconfig for all platforms Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 09/22] MIPS: traps: Handle CPU with non standard vint offset Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 10/22] MIPS: Avoid unnecessary reservation of exception space Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 11/22] MIPS: traps: Enhance memblock ebase allocation process Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 12/22] MIPS: Get rid of CONFIG_NO_EXCEPT_FILL Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 13/22] MIPS: traps: Give more explanations if ebase doesn't belong to KSEG0 Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 14/22] dt-bindings: Add vendor prefix for Mobileye Vision Technologies Ltd Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 15/22] dt-bindings: mips: cpus: Sort the entries Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 16/22] dt-bindings: mips: cpu: Add I-Class I6500 Multiprocessor Core Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 17/22] dt-bindings: mips: Add bindings for Mobileye SoCs Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 18/22] dt-bindings: mfd: syscon: Document EyeQ5 OLB Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 19/22] MIPS: mobileye: Add EyeQ5 dtsi Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 20/22] MIPS: mobileye: Add EPM5 device tree Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 21/22] MIPS: generic: Add support for Mobileye EyeQ5 Gregory CLEMENT
2023-12-14  9:46   ` Jiaxun Yang
2023-12-15 16:52     ` Gregory CLEMENT
2023-12-15 20:29       ` Jiaxun Yang
2023-12-12 16:34 ` [PATCH v5 22/22] MAINTAINERS: Add entry for Mobileye MIPS SoCs Gregory CLEMENT
2023-12-15 16:39 ` [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC Gregory CLEMENT
2023-12-20 21:49   ` Thomas Bogendoerfer
2023-12-21  1:57     ` Jiaxun Yang
2023-12-21  7:57     ` Gregory CLEMENT
2023-12-21  9:13       ` Gregory CLEMENT
2023-12-21 14:40         ` Thomas Bogendoerfer
2023-12-21 14:55       ` Thomas Bogendoerfer
2023-12-21 15:26         ` Gregory CLEMENT [this message]
2023-12-21 16:55           ` Thomas Bogendoerfer
2023-12-21 22:25         ` Jiaxun Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5q3bmr9.fsf@BL-laptop \
    --to=gregory.clement@bootlin.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=paulburton@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tawfik.bayouk@mobileye.com \
    --cc=theo.lebrun@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=vladimir.kondratiev@mobileye.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).