Date: Sun, 26 May 2024 16:02:32 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 linux-kernel@...r.kernel.org,
 Philippe Mathieu-Daudé <philmd@...aro.org>
Subject: Re: [PATCH v3 0/9] MIPS: Unify low-level debugging functionalities



在2024年5月26日五月 下午1:44，Maciej W. Rozycki写道：
> On Wed, 22 May 2024, Jiaxun Yang wrote:
>
>> That being said, have you noticed that prom_putchar and early_printk is
>> a non-extant on generic mach, ingenic, ralink etc? That's because we
>> really don't want to introduce any platform specific UART code for
>> early debugging on new platforms. With DEBUG_LL introduced by Arm it's
>> only a Kconfig option to do the trick.

Hi Maciej,

Thanks for your thoughts, my two cents below.
>
>  IMHO that is however the logical thing to do.  And then you need no magic 
> options to fiddle with and say a distribution kernel will dump whatever it 
> has to say if something wrong has happened early on.

This is a strict debug only options, we are not expecting any distribution
kernel to enable it. It has made itself explicit that no production device
should enable it.

Setting UART address for debug console by developers know what are they
doing is a proven approach among multiple places in multiple projects.

For kernel we have general earlycon cmdline option that would take MMIO
base address, Arm's DEBUG_LL had taken a similar approach and U-Boot have
CONFIG_DEBUG_UART_BASE, even our old zboot debug print code is taking such
approach.

It takes a balance between platform dependent code addition and bring-up
debugging capability. I fail to see why does it suddenly become an undesired
thing here.

>
>  IOW just wire `prom_putchar' as required, using C code preferably.  NB 
> YAMON does have a `print' entry point for console output, so for the Malta 
> platform you can trivially use just that, no need for messy ad hoc 8250 
> code.

Sadly for the majority of modern MIPS devices are dominated by U-Boot or
vendor's simple loader. In most cases, runtime APIs are not provided by
default. Even if it's enabled, there are still a couple of reasons preventing
it to be utilized properly. U-Boot relies on global pointer stored in K0 to
save global runtime data, kernel will clobber it very early and makes U-Boot
non-functional. On devices with limited memory, it's easy to get U-Boot memory
being clobbered by kernel and render U-Boot's runtime useless anyway.

That's why many new-ish platforms such as lantiq brings it's own UART
implementations for prom_putchar.

However, for generic platform implementing prom_putchar means we need to
introduce platform dependent code, which we had to pay all the price to
avoid. We have many in-tree and out-of tree generic platform users who
don't need to add any single line of code to bring up their platform,
thanks to DeviceTree, but they still need something to help with debugging
bring up process when devicetree went wrong or early panics.

>
>  As to intercepting exceptions, it depends.  Again YAMON does handle that 
> and dumps the register state, so with the Malta you get the information 
> required.  For less capable ones it might make sense, but it ISTM like a 
> candidate for an independent change, and then again I fail to see why the 
> handler has to be written in the assembly language rather than C.

Again for U-Boot debug exception dumping is optional and I know many devices
not shipping with that enabled. Even if it's enabled, it will stop to work
after U-Boot's memory/global pointer being clobbered or ebase being overridden
by kernel. Not to mention that Bootloader's exception dumping won't work
with CPS secondary cores.

Paul wrote cps-vec.S and cps-vec-ns16550.S in pure assembly for reasons.
Stack pointer is not initialized at second core & we really want to reduce
code footprint on secondary core to minimize side effects before coherence
is enabled.

When the infra is here, expand it to generic early exception is just tens
of lines. I fail to see the reason to bring in hundreds lines of C code for
the same functionality.

>
>   Maciej

Although it's a pure technical discussion, I still want to expand that while
I appreciate what you have done to the MIPS, sometimes I feel like we are not
on the same page because you guys are away from frontliner for so long and
missed many contexts. MIPS is still evolving, although I never appeared here
with my corp email, I'm one of those behind the scene. I draft new architecture
specs, write AVP and internal simulators, do RTL coding for future core products,
helping customers design SoC products, design software architecture and bringing
them up. I kept FOSS as my hobby and I tried my best to keep upstream in sync with
modern practices.

I love MIPS heritages, I own an SGI Indy and Algorithmics P-4032, I made some
fixes on MAME emulator for indy to keep kernel running on it. I'm still frequently
fascinated by those brilliant old designs. But I think we still need to make progress.
While maintaining compatibility with all those old things, we need to adopt common
practices that have been proven by other architectures and make our own innovations.
We need to make the development process agile, so no developer is turned away. We
need to adopt modern booting protocols like EFI and ensure generic kernel is really
generic and not being diverted because of different loading address....

I don't know if you would agree with my in both technical details and ideology,
but I think it's the time to make my intention clear.

Thanks
-- 
- Jiaxun

Powered by blists - more mailing lists