[v5,00/22] Add support for the Mobileye EyeQ5 SoC

  Hello,

The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
and features multiple controllers such as the classic UART, I2C, SPI,
as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
Security Module, Functional Safety Hardware, and MJPEG encoder.

One peculiarity of this SoC is that the physical address of the DDDR
exceeds 32 bits. Given that the architecture is 64 bits, this is not
an issue, but it requires some changes in how the mips64 is currently
managed during boot.

In this fifth version, there aren't many changes, mostly just tweaking
commit messages based on Sergey's feedback and fixing up the code
style. But, the real reason for this series is a bit of a whoopsie on
my end. It turns out, despite what I confidently claimed in the last
round, some configuration tweaks were missing. All sorted now, though!

To build and test the kernel, we need to run the following commands:

make 64r6el_defconfig BOARDS=eyeq5
make vmlinuz.itb

Changelog:

 v4 -> v5:

   - Improve commit messages for patch 3, 5, 12 and 13.

   - Fix style in patch 9

   - Really enable SPARSMEM and use correct address in
     board-eyeq5.config in patch 21

 v3 -> v4:

 - Fix build warning in "MIPS: Get rid of CONFIG_NO_EXCEPT_FILL":
   check that we are in 64bit mode before using KSEG0 that exist only
   in this mode.

 - Modify "MIPS: spaces: Define a couple of handy macros" to be
   buildable in 32bit mode.

 - Use correct format specifier to print address in "MIPS: traps: Give
   more explanations if ebase doesn't belong to KSEG0"

 - In "MIPS: generic: Add support for Mobileye EyeQ5",remove
   CONFIG_ZBOOT_LOAD_ADDRESS from board-eyeq5.config, (as well as
   CONFIG_USE_XKPHYS that does not exist anymore) and add
   CONFIG_SPARSEMEM_MANUAL to enable SPARSMEM.

v2 -> v3

 - Added more reviewed-by and acked-by tags

 - Fix sorting for cpus entries in

 - Fix indentation issue in Documentation/devicetree/bindings/mips/mobileye.yaml

 v1 -> v2

 - Added reviewed-by and acked-by tags

 - Fix typos reported

 - In patch 15 use 'img' vendor string instead of mti

 - In patch 16 modify licence

 - In patch 17 give more explanations about the block usage.

 - In patch 18, remove _ in node names, don't use anymore
   CONFIG_BUILTIN_DTB in Makefile, remove macro, modify licence.

 - In patch 19 remove most of the bootargs and only keeps earlycon. I
   also split the memory in 2 part in the device tree.

 - Integrate the series from Jiaxun Yang
   https://lore.kernel.org/linux-mips/20231027221106.405666-1-jiaxun.yang@flygoat.com/

  They are patches 2 to 6 and 8 to 12

  Then I added patch 7 to fix the cache issue visible on the Mobileye
  platform, I also add patch 13 to improve warning message when ebase
  doesn't belong to KSEG0

Regards,

Gregory

Gregory CLEMENT (13):
  MIPS: compressed: Use correct instruction for 64 bit code
  MIPS: spaces: Define a couple of handy macros
  MIPS: Fix cache issue with mips_cps_core_entry
  MIPS: traps: Give more explanations if ebase doesn't belong to KSEG0
  dt-bindings: Add vendor prefix for Mobileye Vision Technologies Ltd.
  dt-bindings: mips: cpus: Sort the entries
  dt-bindings: mips: cpu: Add I-Class I6500 Multiprocessor Core
  dt-bindings: mips: Add bindings for Mobileye SoCs
  dt-bindings: mfd: syscon: Document EyeQ5 OLB
  MIPS: mobileye: Add EyeQ5 dtsi
  MIPS: mobileye: Add EPM5 device tree
  MIPS: generic: Add support for Mobileye EyeQ5
  MAINTAINERS: Add entry for Mobileye MIPS SoCs

Jiaxun Yang (9):
  MIPS: Export higher/highest relocation functions in uasm
  MIPS: genex: Fix except_vec_vi for kernel in XKPHYS
  MIPS: Fix set_uncached_handler for ebase in XKPHYS
  MIPS: Refactor mips_cps_core_entry implementation
  MIPS: Allow kernel base to be set from Kconfig for all platforms
  MIPS: traps: Handle CPU with non standard vint offset
  MIPS: Avoid unnecessary reservation of exception space
  MIPS: traps: Enhance memblock ebase allocation process
  MIPS: Get rid of CONFIG_NO_EXCEPT_FILL

 .../devicetree/bindings/mfd/syscon.yaml       |   1 +
 .../devicetree/bindings/mips/cpus.yaml        |  13 +-
 .../devicetree/bindings/mips/mobileye.yaml    |  32 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |  12 +
 arch/mips/Kconfig                             |  26 +-
 arch/mips/boot/compressed/head.S              |   4 +-
 arch/mips/boot/dts/Makefile                   |   1 +
 arch/mips/boot/dts/mobileye/Makefile          |   4 +
 arch/mips/boot/dts/mobileye/eyeq5-epm5.dts    |  24 ++
 .../boot/dts/mobileye/eyeq5-fixed-clocks.dtsi | 292 ++++++++++++++++++
 arch/mips/boot/dts/mobileye/eyeq5.dtsi        | 134 ++++++++
 arch/mips/configs/generic/board-eyeq5.config  |  42 +++
 arch/mips/generic/Kconfig                     |  15 +
 arch/mips/generic/Platform                    |   2 +
 arch/mips/generic/board-epm5.its.S            |  24 ++
 arch/mips/include/asm/addrspace.h             |   5 +
 arch/mips/include/asm/mach-generic/spaces.h   |   2 +
 arch/mips/include/asm/mips-cm.h               |   1 +
 arch/mips/include/asm/smp-cps.h               |   4 +-
 arch/mips/include/asm/traps.h                 |   1 -
 arch/mips/include/asm/uasm.h                  |   2 +
 arch/mips/kernel/cps-vec.S                    | 110 +++----
 arch/mips/kernel/cpu-probe.c                  |   5 -
 arch/mips/kernel/cpu-r3k-probe.c              |   2 -
 arch/mips/kernel/genex.S                      |  19 +-
 arch/mips/kernel/head.S                       |   7 +-
 arch/mips/kernel/smp-cps.c                    | 171 ++++++++--
 arch/mips/kernel/traps.c                      |  90 ++++--
 arch/mips/mm/uasm.c                           |   6 +-
 30 files changed, 894 insertions(+), 159 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/mobileye.yaml
 create mode 100644 arch/mips/boot/dts/mobileye/Makefile
 create mode 100644 arch/mips/boot/dts/mobileye/eyeq5-epm5.dts
 create mode 100644 arch/mips/boot/dts/mobileye/eyeq5-fixed-clocks.dtsi
 create mode 100644 arch/mips/boot/dts/mobileye/eyeq5.dtsi
 create mode 100644 arch/mips/configs/generic/board-eyeq5.config
 create mode 100644 arch/mips/generic/board-epm5.its.S
  

Hello Thomas,

> Hello,
>
> The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
> and features multiple controllers such as the classic UART, I2C, SPI,
> as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
> Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
> Security Module, Functional Safety Hardware, and MJPEG encoder.
>
> One peculiarity of this SoC is that the physical address of the DDDR
> exceeds 32 bits. Given that the architecture is 64 bits, this is not
> an issue, but it requires some changes in how the mips64 is currently
> managed during boot.
>
> In this fifth version, there aren't many changes, mostly just tweaking
> commit messages based on Sergey's feedback and fixing up the code
> style. But, the real reason for this series is a bit of a whoopsie on
> my end. It turns out, despite what I confidently claimed in the last
> round, some configuration tweaks were missing. All sorted now, though!
>

A few weeks ago, you were concerned about the introduction of the
specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
to set up a new platform instead. Since then, Jiaxun proposed a series
that was merged here to provide more generic support.

I had other issues in the initial series, and I think that now I've
fixed all of them. So, I would like to know what your opinion is now
about this series.

Will you accept it, or do you still think that a new platform has to be
set up?

Regards,

Gregory

> To build and test the kernel, we need to run the following commands:
>
> make 64r6el_defconfig BOARDS=eyeq5
> make vmlinuz.itb
>
> Changelog:
>
>  v4 -> v5:
>
>    - Improve commit messages for patch 3, 5, 12 and 13.
>
>    - Fix style in patch 9
>
>    - Really enable SPARSMEM and use correct address in
>      board-eyeq5.config in patch 21
>
>  v3 -> v4:
>
>  - Fix build warning in "MIPS: Get rid of CONFIG_NO_EXCEPT_FILL":
>    check that we are in 64bit mode before using KSEG0 that exist only
>    in this mode.
>
>  - Modify "MIPS: spaces: Define a couple of handy macros" to be
>    buildable in 32bit mode.
>
>  - Use correct format specifier to print address in "MIPS: traps: Give
>    more explanations if ebase doesn't belong to KSEG0"
>
>  - In "MIPS: generic: Add support for Mobileye EyeQ5",remove
>    CONFIG_ZBOOT_LOAD_ADDRESS from board-eyeq5.config, (as well as
>    CONFIG_USE_XKPHYS that does not exist anymore) and add
>    CONFIG_SPARSEMEM_MANUAL to enable SPARSMEM.
>
> v2 -> v3
>
>  - Added more reviewed-by and acked-by tags
>
>  - Fix sorting for cpus entries in
>
>  - Fix indentation issue in Documentation/devicetree/bindings/mips/mobileye.yaml
>
>  v1 -> v2
>
>  - Added reviewed-by and acked-by tags
>
>  - Fix typos reported
>
>  - In patch 15 use 'img' vendor string instead of mti
>
>  - In patch 16 modify licence
>
>  - In patch 17 give more explanations about the block usage.
>
>  - In patch 18, remove _ in node names, don't use anymore
>    CONFIG_BUILTIN_DTB in Makefile, remove macro, modify licence.
>
>  - In patch 19 remove most of the bootargs and only keeps earlycon. I
>    also split the memory in 2 part in the device tree.
>
>  - Integrate the series from Jiaxun Yang
>    https://lore.kernel.org/linux-mips/20231027221106.405666-1-jiaxun.yang@flygoat.com/
>
>   They are patches 2 to 6 and 8 to 12
>
>   Then I added patch 7 to fix the cache issue visible on the Mobileye
>   platform, I also add patch 13 to improve warning message when ebase
>   doesn't belong to KSEG0
>
> Regards,
>
> Gregory
>
> Gregory CLEMENT (13):
>   MIPS: compressed: Use correct instruction for 64 bit code
>   MIPS: spaces: Define a couple of handy macros
>   MIPS: Fix cache issue with mips_cps_core_entry
>   MIPS: traps: Give more explanations if ebase doesn't belong to KSEG0
>   dt-bindings: Add vendor prefix for Mobileye Vision Technologies Ltd.
>   dt-bindings: mips: cpus: Sort the entries
>   dt-bindings: mips: cpu: Add I-Class I6500 Multiprocessor Core
>   dt-bindings: mips: Add bindings for Mobileye SoCs
>   dt-bindings: mfd: syscon: Document EyeQ5 OLB
>   MIPS: mobileye: Add EyeQ5 dtsi
>   MIPS: mobileye: Add EPM5 device tree
>   MIPS: generic: Add support for Mobileye EyeQ5
>   MAINTAINERS: Add entry for Mobileye MIPS SoCs
>
> Jiaxun Yang (9):
>   MIPS: Export higher/highest relocation functions in uasm
>   MIPS: genex: Fix except_vec_vi for kernel in XKPHYS
>   MIPS: Fix set_uncached_handler for ebase in XKPHYS
>   MIPS: Refactor mips_cps_core_entry implementation
>   MIPS: Allow kernel base to be set from Kconfig for all platforms
>   MIPS: traps: Handle CPU with non standard vint offset
>   MIPS: Avoid unnecessary reservation of exception space
>   MIPS: traps: Enhance memblock ebase allocation process
>   MIPS: Get rid of CONFIG_NO_EXCEPT_FILL
>
>  .../devicetree/bindings/mfd/syscon.yaml       |   1 +
>  .../devicetree/bindings/mips/cpus.yaml        |  13 +-
>  .../devicetree/bindings/mips/mobileye.yaml    |  32 ++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  MAINTAINERS                                   |  12 +
>  arch/mips/Kconfig                             |  26 +-
>  arch/mips/boot/compressed/head.S              |   4 +-
>  arch/mips/boot/dts/Makefile                   |   1 +
>  arch/mips/boot/dts/mobileye/Makefile          |   4 +
>  arch/mips/boot/dts/mobileye/eyeq5-epm5.dts    |  24 ++
>  .../boot/dts/mobileye/eyeq5-fixed-clocks.dtsi | 292 ++++++++++++++++++
>  arch/mips/boot/dts/mobileye/eyeq5.dtsi        | 134 ++++++++
>  arch/mips/configs/generic/board-eyeq5.config  |  42 +++
>  arch/mips/generic/Kconfig                     |  15 +
>  arch/mips/generic/Platform                    |   2 +
>  arch/mips/generic/board-epm5.its.S            |  24 ++
>  arch/mips/include/asm/addrspace.h             |   5 +
>  arch/mips/include/asm/mach-generic/spaces.h   |   2 +
>  arch/mips/include/asm/mips-cm.h               |   1 +
>  arch/mips/include/asm/smp-cps.h               |   4 +-
>  arch/mips/include/asm/traps.h                 |   1 -
>  arch/mips/include/asm/uasm.h                  |   2 +
>  arch/mips/kernel/cps-vec.S                    | 110 +++----
>  arch/mips/kernel/cpu-probe.c                  |   5 -
>  arch/mips/kernel/cpu-r3k-probe.c              |   2 -
>  arch/mips/kernel/genex.S                      |  19 +-
>  arch/mips/kernel/head.S                       |   7 +-
>  arch/mips/kernel/smp-cps.c                    | 171 ++++++++--
>  arch/mips/kernel/traps.c                      |  90 ++++--
>  arch/mips/mm/uasm.c                           |   6 +-
>  30 files changed, 894 insertions(+), 159 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mips/mobileye.yaml
>  create mode 100644 arch/mips/boot/dts/mobileye/Makefile
>  create mode 100644 arch/mips/boot/dts/mobileye/eyeq5-epm5.dts
>  create mode 100644 arch/mips/boot/dts/mobileye/eyeq5-fixed-clocks.dtsi
>  create mode 100644 arch/mips/boot/dts/mobileye/eyeq5.dtsi
>  create mode 100644 arch/mips/configs/generic/board-eyeq5.config
>  create mode 100644 arch/mips/generic/board-epm5.its.S
>
> -- 
> 2.42.0
>
  

On Fri, Dec 15, 2023 at 05:39:39PM +0100, Gregory CLEMENT wrote:
> Hello Thomas,
> 
> > Hello,
> >
> > The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
> > and features multiple controllers such as the classic UART, I2C, SPI,
> > as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
> > Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
> > Security Module, Functional Safety Hardware, and MJPEG encoder.
> >
> > One peculiarity of this SoC is that the physical address of the DDDR
> > exceeds 32 bits. Given that the architecture is 64 bits, this is not
> > an issue, but it requires some changes in how the mips64 is currently
> > managed during boot.
> >
> > In this fifth version, there aren't many changes, mostly just tweaking
> > commit messages based on Sergey's feedback and fixing up the code
> > style. But, the real reason for this series is a bit of a whoopsie on
> > my end. It turns out, despite what I confidently claimed in the last
> > round, some configuration tweaks were missing. All sorted now, though!
> >
> 
> A few weeks ago, you were concerned about the introduction of the
> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
> to set up a new platform instead. Since then, Jiaxun proposed a series
> that was merged here to provide more generic support.

well, there is more to improve and stuff I don't like in Jaixun series.
For example misusing CONFIG_PHYSICAL_START to force a load address via config
(IMHO it's already a hack for CRASH_DUMP).

As there is your series and Jiaxun series, where should I comment more
detailed ?

> I had other issues in the initial series, and I think that now I've
> fixed all of them. So, I would like to know what your opinion is now
> about this series.
> 
> Will you accept it, or do you still think that a new platform has to be
> set up?

things have improved, but I'm still in favor to use a new platform.
And my main point stays. A "generic" kernel compiled for EyeQ5 will
just run on that platform, which doesn't sound generic to me.

Thomas.
  

在2023年12月20日十二月 下午9:49，Thomas Bogendoerfer写道：
> On Fri, Dec 15, 2023 at 05:39:39PM +0100, Gregory CLEMENT wrote:
>> Hello Thomas,
>> 
>> > Hello,
>> >
>> > The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
>> > and features multiple controllers such as the classic UART, I2C, SPI,
>> > as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
>> > Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
>> > Security Module, Functional Safety Hardware, and MJPEG encoder.
>> >
>> > One peculiarity of this SoC is that the physical address of the DDDR
>> > exceeds 32 bits. Given that the architecture is 64 bits, this is not
>> > an issue, but it requires some changes in how the mips64 is currently
>> > managed during boot.
>> >
>> > In this fifth version, there aren't many changes, mostly just tweaking
>> > commit messages based on Sergey's feedback and fixing up the code
>> > style. But, the real reason for this series is a bit of a whoopsie on
>> > my end. It turns out, despite what I confidently claimed in the last
>> > round, some configuration tweaks were missing. All sorted now, though!
>> >
>> 
>> A few weeks ago, you were concerned about the introduction of the
>> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
>> to set up a new platform instead. Since then, Jiaxun proposed a series
>> that was merged here to provide more generic support.
>
> well, there is more to improve and stuff I don't like in Jaixun series.
> For example misusing CONFIG_PHYSICAL_START to force a load address via config
> (IMHO it's already a hack for CRASH_DUMP).
>
> As there is your series and Jiaxun series, where should I comment more
> detailed ?

You can comment on my patches in this series, I'm listening.

>> I had other issues in the initial series, and I think that now I've
>> fixed all of them. So, I would like to know what your opinion is now
>> about this series.
>> 
>> Will you accept it, or do you still think that a new platform has to be
>> set up?
>
> things have improved, but I'm still in favor to use a new platform.
> And my main point stays. A "generic" kernel compiled for EyeQ5 will
> just run on that platform, which doesn't sound generic to me.

There are many case generic-ish kernel won't boot on other system, FIT
file built for one platform certainly won't boot on another, not to mention
that we already have systems not following UHI boot protocol in generic platform,
such as MSCC Ocelot.

If only one extra Kconfig option (CONFIG_PHYSICAL_START) can make kernel
support a new type of platform, duplicating the code for a new platform
does not make much sense here.

In multi-cluster boston system we are having the same problem that low RAM
space is not sufficient for kernel image due to GCRs eating up low address
space, that's why I devote my time to get XKPHYS booting work.

Also if we fix up relocatable kernel support, we can indeed share one single
kernel image between all those systems.

Thanks
>
> Thomas.
>
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]
  

Hello Thomas,

Thanks for your fedback

> On Fri, Dec 15, 2023 at 05:39:39PM +0100, Gregory CLEMENT wrote:
>> Hello Thomas,
>> 
>> > Hello,
>> >
>> > The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
>> > and features multiple controllers such as the classic UART, I2C, SPI,
>> > as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
>> > Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
>> > Security Module, Functional Safety Hardware, and MJPEG encoder.
>> >
>> > One peculiarity of this SoC is that the physical address of the DDDR
>> > exceeds 32 bits. Given that the architecture is 64 bits, this is not
>> > an issue, but it requires some changes in how the mips64 is currently
>> > managed during boot.
>> >
>> > In this fifth version, there aren't many changes, mostly just tweaking
>> > commit messages based on Sergey's feedback and fixing up the code
>> > style. But, the real reason for this series is a bit of a whoopsie on
>> > my end. It turns out, despite what I confidently claimed in the last
>> > round, some configuration tweaks were missing. All sorted now, though!
>> >
>> 
>> A few weeks ago, you were concerned about the introduction of the
>> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
>> to set up a new platform instead. Since then, Jiaxun proposed a series
>> that was merged here to provide more generic support.
>
> well, there is more to improve and stuff I don't like in Jaixun series.
> For example misusing CONFIG_PHYSICAL_START to force a load address via config
> (IMHO it's already a hack for CRASH_DUMP).
>
> As there is your series and Jiaxun series, where should I comment more
> detailed ?

I think you could start on Jiaxun series but the one merged in my
series, because I already had a few fixes for it.

>
>> I had other issues in the initial series, and I think that now I've
>> fixed all of them. So, I would like to know what your opinion is now
>> about this series.
>> 
>> Will you accept it, or do you still think that a new platform has to be
>> set up?
>
> things have improved, but I'm still in favor to use a new platform.
> And my main point stays. A "generic" kernel compiled for EyeQ5 will
> just run on that platform, which doesn't sound generic to me.

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. Therefore, if it were possible to have a
relocatable kernel, this issue would disappear.

However, while waiting for your feedback on Jiaxun's part, I will
attempt to add a new platform to assess exactly what the implications
are.

Gregory

>
> Thomas.
>
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]
  

Gregory CLEMENT <gregory.clement@bootlin.com> writes:

[...]

>>> 
>>> A few weeks ago, you were concerned about the introduction of the
>>> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
>>> to set up a new platform instead. Since then, Jiaxun proposed a series
>>> that was merged here to provide more generic support.
>>
>> well, there is more to improve and stuff I don't like in Jaixun series.
>> For example misusing CONFIG_PHYSICAL_START to force a load address via config
>> (IMHO it's already a hack for CRASH_DUMP).
>>
>> As there is your series and Jiaxun series, where should I comment more
>> detailed ?
>
> I think you could start on Jiaxun series but the one merged in my
> series, because I already had a few fixes for it.

This sentence was not very clear, let me rephrase it: I recommend
starting the review with Jiaxun's series, specifically examining the
code that has been incorporated into my series. This is important as I
have already made several modifications to his original code


>>
>>> I had other issues in the initial series, and I think that now I've
>>> fixed all of them. So, I would like to know what your opinion is now
>>> about this series.
>>> 
>>> Will you accept it, or do you still think that a new platform has to be
>>> set up?
>>
>> things have improved, but I'm still in favor to use a new platform.
>> And my main point stays. A "generic" kernel compiled for EyeQ5 will
>> just run on that platform, which doesn't sound generic to me.
>
> 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. Therefore, if it were possible to have a
> relocatable kernel, this issue would disappear.
>
> However, while waiting for your feedback on Jiaxun's part, I will
> attempt to add a new platform to assess exactly what the implications
> are.

Is it possible for you to apply the first patch of this series, which is
only a fix? This would enable me to have a slightly shorter
series. Additionally, it would facilitate dividing the entire series
into two parts: the first part for XKPHYS support and the second part
for EyeQ5 support.

Gregory
  

On Thu, Dec 21, 2023 at 10:13:53AM +0100, Gregory CLEMENT wrote:
> > However, while waiting for your feedback on Jiaxun's part, I will
> > attempt to add a new platform to assess exactly what the implications
> > are.
> 
> Is it possible for you to apply the first patch of this series, which is
> only a fix?

I had this already in my mind and done it just a few minutes ago.

Thomas.
  

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

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 ?

Thomas.
  

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
  

On Thu, Dec 21, 2023 at 04:26:02PM +0100, Gregory CLEMENT wrote:
> Thomas Bogendoerfer <tsbogend@alpha.franken.de> writes:
> 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.

but that's not used, when you have your own Platform file. See
arch/mips/Kbuild.platforms.

Thomas.
  

在 2023/12/21 14:55, Thomas Bogendoerfer 写道:
> 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
>
> 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 ?

It does not handle 64 bit relocations currently.
I tried to look into it and it's not a easy fix.

Thanks
- Jiaxun
> Thomas.
>