Message-Id: <b20873d4-1627-4e68-8646-c3837c0d135c@app.fastmail.com>
Date: Thu, 21 Dec 2023 01:57:42 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Gregory CLEMENT" <gregory.clement@...tlin.com>
Cc: "paulburton@...nel.org" <paulburton@...nel.org>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 "Rob Herring" <robh+dt@...nel.org>,
 "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 "Vladimir Kondratiev" <vladimir.kondratiev@...ileye.com>,
 "Tawfik Bayouk" <tawfik.bayouk@...ileye.com>,
 "Alexandre Belloni" <alexandre.belloni@...tlin.com>,
 Théo Lebrun <theo.lebrun@...tlin.com>,
 "Thomas Petazzoni" <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC



在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 ]

-- 
- Jiaxun

Powered by blists - more mailing lists