[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <13aa508f-6830-4d52-87fd-5063f737c990@app.fastmail.com>
Date: Wed, 22 May 2024 09:28:22 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>
Cc: "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月22日五月 上午9:03,Thomas Bogendoerfer写道:
[...]
>
> hmmm, I thought I was clear enough on version 1 of this series.
>
> I don't want an additional printk like debug interface, There is
> prom_putchar() and early printk console, which always got me past
> any boot issue.
So it's not an additional printk like debug interface, it actually
merged 3 existing debug interfaces, the first being zboot's assembly
print routines, the second being CPS's assembly print routines, the
third being some platform specific early printk. I think they are
all essential for debugging early faults, for zboot that's the only
way to print something at decompressing stage, for CPS as other cores
are booting in non-coherent state we can't safely use any kernel
functions, for early_printk that can help us *reduce* the amount
of early printk code by just adding UART base to config.
The only thing being added is the ability to debug very early exception,
even that is partially ported from existing CPS assembly debugging routines.
Please let me know your thoughts.
Thanks
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 23 ]
--
- Jiaxun
Powered by blists - more mailing lists