[PATCH 3/3] MIPS: Loongson64: Add kexec/kdump support

[Jiaxun Yang]

在 2020/9/24 9:19, Huacai Chen 写道:
> Hi, Jiaxun,
[...]
>
>
> I'm just a little bit uncomfortable with this kind of hardcoded address.
> Is it possible to generate kexec_smp_wait with uasm, or pass the SMP
> base as a parameter of this function?
> This is very difficult, and moreover, uasm wrap the assembly in C
> functions, can it be more beautiful? In my opinion, uasm is only used
> for performance-critical routines, not for beautiful code. But anyway,
> 0x900000003ff01000 should be improved.
>
>> Also I do think we can handle kexec_flag in Loongson's platform SMP,
>> or even generic MIPS SMP code just like what cavium did so this kind
>> of platform quirk can be avoided.
> I doubt this can be done, every CPU has its own method of SMP bringup.
Hi Huacai,

I don't know kexec very well.. So please ignore my ideas if they're not 
applicatable.

Hmm, as we've got control of all secondnary processors at the point, I 
suspect
we can skip platform bring-up code.

Cavium makes use of secondary_kexec_args, can we do it as well?

I think kexec_flag was designed for this reason.
Current code is sending all secondnary processors to the entry point
of the new kernel, probably we can do something here.

>>
>> I won't say it's safe.
>> Loongson-2K's PMON may place reboot vector here, also some
>> UEFI firmware may place their suspend stack here.
>> What if we allocate these buffer at runtime?
> The layout of low 2MB in our design:
> 0x80000000 the first MB, the first 64K：Exception vector
> 0x80010000 the first MB, the second 64K：STR(suspend) data
> 0x80020000 the first MB, the third and fourth 64K：UEFI HOB
> 0x80040000 the first MB, the fifth 64K：RT-Thread for SMC
> 0x80100000 the second MB, the first 64K：KEXEC code
> 0x80108000 the second MB, the second 64K：KEXEC data

Well, there are some other vendors violating this design.
Especially for embedded systems like Loongson-2K.

> All allocated buffer from the old kernel is not safe, because the new
> kernel may be larger than the old kernel. Even if the low 2MB is not a
> perfect place, it is the best place we can choose.
Oops I ignored overlapping..
Then it looks fine for me..

Thanks.

- Jiaxun


>
> Huacai
>
>> Thanks.
>>
>> - Jiaxun
>>