| Message ID | 20231212163459.1923041-1-gregory.clement@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for the Mobileye EyeQ5 SoC | expand |
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. >
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