linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <linux@rempel-privat.de>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Qing Zhang <zhangqing@loongson.cn>,
	Huacai Chen <chenhuacai@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Ming Wang <wangming01@loongson.cn>
Subject: Re: [PATCH v4 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI
Date: Wed, 10 Mar 2021 14:26:57 +0100	[thread overview]
Message-ID: <7f26fc67-e7b1-d305-90e7-0cfedcc822ca@rempel-privat.de> (raw)
In-Reply-To: <49ddbef4-3d2a-4adb-8fd0-37bba0530c4c@www.fastmail.com>

Am 10.03.21 um 13:12 schrieb Jiaxun Yang:
>
>
> On Wed, Mar 10, 2021, at 6:57 PM, Oleksij Rempel wrote:
>> Hi,
>>
>> Am 10.03.21 um 08:56 schrieb Qing Zhang:
>>> Add DTB boot support, only support Loongson-2K1000 processor
>>> for now, determine whether to use the built-in DTB or the DTB
>>> from the firmware by checking the range of CKSEG0 and XKPHYS.
>>> loongson_fw_interface will be used in the future.
>>>
>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>> Signed-off-by: Qing Zhang <zhangqing@loongson.cn>
>>> Tested-by: Ming Wang <wangming01@loongson.cn>
>>> ---
>>>
>>> v3-v4: Standard submission of information
>>>        Fix error handling
>>>
>>>  .../include/asm/mach-loongson64/boot_param.h     |  6 ++++++
>>>  arch/mips/include/asm/mach-loongson64/loongson.h |  3 ++-
>>>  arch/mips/loongson64/env.c                       | 13 ++++++++++++-
>>>  arch/mips/loongson64/init.c                      | 16 ++++++++++++++--
>>>  4 files changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h b/arch/mips/include/asm/mach-loongson64/boot_param.h
>>> index 4592841b6b0c..43737401dc06 100644
>>> --- a/arch/mips/include/asm/mach-loongson64/boot_param.h
>>> +++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
>>> @@ -198,7 +198,13 @@ enum loongson_bridge_type {
>>>  	VIRTUAL = 3
>>>  };
>>>
>>> +enum loongson_fw_interface {
>>> +	LOONGSON_LEFI,
>>> +	LOONGSON_DTB,
>>> +};
>>> +
>>>  struct loongson_system_configuration {
>>> +	enum loongson_fw_interface fw_interface;
>>>  	u32 nr_cpus;
>>>  	u32 nr_nodes;
>>>  	int cores_per_node;
>>> diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h b/arch/mips/include/asm/mach-loongson64/loongson.h
>>> index ac1c20e172a2..3f885fa26ba6 100644
>>> --- a/arch/mips/include/asm/mach-loongson64/loongson.h
>>> +++ b/arch/mips/include/asm/mach-loongson64/loongson.h
>>> @@ -23,7 +23,8 @@ extern u32 memsize, highmemsize;
>>>  extern const struct plat_smp_ops loongson3_smp_ops;
>>>
>>>  /* loongson-specific command line, env and memory initialization */
>>> -extern void __init prom_init_env(void);
>>> +extern void __init prom_dtb_init_env(void);
>>> +extern void __init prom_lefi_init_env(void);
>>>  extern void __init szmem(unsigned int node);
>>>  extern void *loongson_fdt_blob;
>>>
>>> diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
>>> index 51a5d050a94c..e7d3a06175e3 100644
>>> --- a/arch/mips/loongson64/env.c
>>> +++ b/arch/mips/loongson64/env.c
>>> @@ -43,7 +43,18 @@ const char *get_system_type(void)
>>>  	return "Generic Loongson64 System";
>>>  }
>>>
>>> -void __init prom_init_env(void)
>>> +
>>> +void __init prom_dtb_init_env(void)
>>> +{
>>> +	if ((fw_arg2 < CKSEG0 || fw_arg2 > CKSEG1)
>>> +		&& (fw_arg2 < XKPHYS || fw_arg2 > XKSEG))
>>> +
>>> +		loongson_fdt_blob = __dtb_loongson64_2core_2k1000_begin;
>>> +	else
>>> +		loongson_fdt_blob = (void *)fw_arg2;
>>> +}
>>> +
>>> +void __init prom_lefi_init_env(void)
>>>  {
>>>  	struct boot_params *boot_p;
>>>  	struct loongson_params *loongson_p;
>>> diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
>>> index cfa788bca871..ed280b73bf89 100644
>>> --- a/arch/mips/loongson64/init.c
>>> +++ b/arch/mips/loongson64/init.c
>>> @@ -52,6 +52,10 @@ void __init szmem(unsigned int node)
>>>  	static unsigned long num_physpages;
>>>  	u64 node_id, node_psize, start_pfn, end_pfn, mem_start, mem_size;
>>>
>>> +	/* Otherwise come from DTB */
>>> +	if (loongson_sysconf.fw_interface != LOONGSON_LEFI)
>>> +		return;
>>> +
>>>  	/* Parse memory information and activate */
>>>  	for (i = 0; i < loongson_memmap->nr_map; i++) {
>>>  		node_id = loongson_memmap->map[i].node_id;
>>> @@ -94,12 +98,20 @@ static void __init prom_init_memory(void)
>>>  void __init prom_init(void)
>>>  {
>>>  	fw_init_cmdline();
>>> -	prom_init_env();
>>> +
>>> +	if (fw_arg2 == 0 || (fdt_magic(fw_arg2) == FDT_MAGIC)) {
>>> +		loongson_sysconf.fw_interface = LOONGSON_DTB;
>>> +		prom_dtb_init_env();
>>> +	} else {
>>> +		loongson_sysconf.fw_interface = LOONGSON_LEFI;
>>> +		prom_lefi_init_env();
>>> +	}
>>
>> Is it possible to make it compatible with MIPS UHI boot protocol? So
>> boot loaders will be able to
>> handle Loongson kernel images as any other MIPS kernel images?
>
> Hmm, as Loongson did many stuff in non-generic manner it's almost impossible :-(
> Also their are many devices shipped with current boot protocol.

I would like to understand, why it is impossible. Do fw_arg0 provide memory address or some kind of
count/size? Can it be negative?

We already had same situation with ARM and it was fixed. Why this can't be done for MIPS or LS?

>
>>
>> This protocol is described here on page 15, "3. Boot protocols"
>> https://docplayer.net/62444141-Unified-hosting-interface-md01069-reference-manual.html
>>
>> According to this protocol, you should have:
>> fw_arg0 = -2
>> fw_arg1 = Virtual (kseg0) address of Device Tree Blob
>>
>> This would made LS a first grade resident for many boot loaders and
>> save a lot of needles headaches.
>
> Loongson is stepping away from MIPS and it seems like they're going to use EDK-II for their Loongarch.

It seems to be UEFI related, it seems to be not related to the CPU arch, or do i'm missing something?

In any case, if this is true, then it means, that Loongsoon is about to drop support for old boot
loaders (PMON?) and do new thing (one more boot protocol?). So argumentation, we upstream old own
protocol, but will drop it to make some thing new is not really good example :)

> TBH I've checked Loongson's PMON code and realized it can't be ported to other projects easily.
> Tons of unregonized assembly code.

No need to port it. Here is example of working clean code:
https://git.pengutronix.de/cgit/barebox/tree/arch/mips/boards/loongson-ls1b/lowlevel.S

And this boot loader would boot any

--
Regards,
Oleksij

  reply	other threads:[~2021-03-10 13:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10  7:56 [PATCH v4 0/7] Add basic support for Loongson-2K1000 Qing Zhang
2021-03-10  7:56 ` [PATCH v4 1/7] MIPS: Loongson64: DeviceTree " Qing Zhang
2021-03-10  7:56 ` [PATCH v4 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI Qing Zhang
2021-03-10 10:57   ` Oleksij Rempel
2021-03-10 12:12     ` Jiaxun Yang
2021-03-10 13:26       ` Oleksij Rempel [this message]
     [not found]         ` <a2b1ad18-8f4b-8e43-e175-c372580a7168@flygoat.com>
2021-03-10 16:03           ` Oleksij Rempel
2021-03-10  7:56 ` [PATCH v4 3/7] MIPS: Loongson64: Add support for the Loongson-2K1000 to get cpu_clock_freq Qing Zhang
2021-03-10  8:50   ` Sergei Shtylyov
2021-03-10  9:37     ` zhangqing
2021-03-10 12:06       ` Jiaxun Yang
2021-03-10  7:56 ` [PATCH v4 4/7] MIPS: Loongson64: Add Loongson-2K1000 early_printk_port Qing Zhang
2021-03-10  7:56 ` [PATCH v4 5/7] irqchip/loongson-liointc: irqchip add 2.0 version Qing Zhang
2021-03-10  7:56 ` [PATCH v4 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC Qing Zhang
2021-03-10 12:04   ` Jiaxun Yang
2021-03-11  1:43     ` zhangqing
2021-03-10  7:56 ` [PATCH v4 7/7] MIPS: Loongson64: Add a Loongson-2K1000 default config file Qing Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f26fc67-e7b1-d305-90e7-0cfedcc822ca@rempel-privat.de \
    --to=linux@rempel-privat.de \
    --cc=chenhuacai@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=wangming01@loongson.cn \
    --cc=zhangqing@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).