Re: About Loongson platforms' directories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018年1月17日星期三 CST 下午1:25:13 James Hogan wrote:
>
> Can you expand on these. To what extent is Loongson's EFI similar to the
> EFI from the x86 world? Do these allow multiple new platforms to be
> supported more easily without much new platform code (like devicetree
> support would)?
Hi James

Since I'm not familiar with loongson-3 platform, It's hard for me to expand 
difference between X86's EFI and Loongson's EFI. Maybe Huacai can explain that 
exactly. Here is a SPEC for reference (in Chinese):http://ftp.loongnix.org/
doc/05spec/%E9%BE%99%E8%8A%AFCPU%E5%BC%80%E5%8F%91%E7%B3%BB%E7%BB%9F%E5%9B%BA
%E4%BB%B6%E4%B8%8E%E5%86%85%E6%A0%B8%E6%8E%A5%E5%8F%A3%E8%AF%A6%E7%BB
%86%E8%A7%84%E8%8C%83V2.0.pdf . As far as I know, new platform with same 
chipsets can be supported by SMBIOS without any addition code in kernel. 
However, that feature is only avliable for Loongson-3.

> 
> I believe the general approach in the ARM camp since Linus put his foot
> down about the proliferation of platform code is to have it all
> devicetree based rather than littering the arch directories with
> platform devices. That way a single multiplatform kernel can boot on a
> variety of different platforms with the DT provided by the bootloader or
> appended to the kernel.

> 
> As well as cleaning up and reducing platform code it also simplifies the
> work for distributions since they only need a small number of kernel
> builds.

Yes I would like to do so. Loongson-2K have a limited support with DeviceTree 
(OpenFirmware) by U-Boot bootloader. Later SoC chips will also support DT as I 
know.
But Loongson-1 series and 2E/2F only have leagcy boot support, no EFI, no DT, 
even not all bootloader support machtype (in boot cmdline). That's why we want 
to creat different entries for these platforms.

Loongson's bootloader is pretty in mass. Loongson-3 is using both PMON2000 v3 
and KunLunBIOS(A close-source EFI bootloader), Loongson-2E/2F is using 
PMON2000 v1 (also third-part out of tree U-boot support but not working 
perfectly). Loongson-1 is only using PMON2000. Newer SoCs will support both 
PMON2000 v3 and U-boot .  PMON2000 have no DT support but I decide to submit 
only DT support to mainline.

> 
> On that front MIPS has the "generic" platform (Paul CC'd) which is
> effectively a multi-platform configuration. It is possible to produce a
> single ITB file which contains a kernel and multiple device tree files
> for different platforms which the bootloader can choose from. It may be
> possible to also boot using legacy boot protocols too, though it depends
> on how it differs from the MIPS UHI spec (so a single kernel could boot
> on either platform), and it may require some form of DT shim to set up a
> DT for the kernel to use internally.
> 
> What challenges would you foresee if Loongson headed this way? (even if
> it was a single separate loongson platform in the kernel source). It may
> require some driver revamping, and the boot protocol might be an issue
> for it to share with the other "generic" platforms. Each new board
> potentially becomes easier to upstream though since the only new arch
> code is devicetree, and the rest is drivers in various other subsystems.
> 

Loongson isn't purchasing any IP core and made all the things by themself so 
we can't reuse most drivers already in kernel. We have to write many platform 
drivers such as PCI, BridgeChip, EC, addtion arch_init for chip and etc. 
That's why we prefer entries for Loongson platforms. Or generic may be filled 
with our platform drivers. Also for now loongson64 already have plenty of 
driver. I don't want to spend time in turn them to generic for other MIPS 
chips because they are not general....

> That's the way things should be heading in my opinion (and already are).
> 

Thanks




-- 
--
Jiaxun Yang


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux