On Wed, Jan 17, 2018 at 05:52:47PM +0800, Jiaxun Yang wrote: > Hi, MIPS maintainers > > Recently Loongson has released their now SystemOnChip chip called > Loongson2K, and I'm going to submit patches for that chip soon. But I > noticed that currently, Loongson64 code in mainline kernel is pretty > in confusion. We mixed loongson2e/2f/3a/3b together in > /arch/mips/loongson64, but they don't have many similarities. 2E/2F are > legacy products that don't support many features such as EFI or SMBIOS, 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)? > only a little code can be reused with 3 series. After discussed with > another maintainer Huacai Chen, we thought we can separate 2E/2F with 3 > series and make 4 directories. > > /loongson-1 (Loongson 1B/1C Micro Control Units formal loongson32) > /loongson-2ef (Loongson 2E/2F legacy CPU machines formal > loongson64/lemote-2f fuloong-2e) > /loongson-2soc (Loongson2H/2K SoCs will be submited latter) > /loongson-3 (Loongson 3A/3B CPU machines formal loongson64/loongson3) > > So we can maintain code for different family chips easier. Just ask if > anybody have a better idea about that. 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. 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. That's the way things should be heading in my opinion (and already are). > > BTW: My recent patches have been ignored for a long time. Probably > because Ralf didn't appear for a long time. Just ask if these patches > can get a chance to be applied. And I don't know what's the proper > upstream for me, Ralf's mips-next or James's mips-next? Currently Ralf's mips-next, though there isn't a lot there yet and the merge window is imminent... Cheers James
Attachment:
signature.asc
Description: Digital signature
