mbox series

[00/16] LoongArch initial support

Message ID 20240522-loongarch-v1-0-1407e0b69678@flygoat.com
Headers show
Series LoongArch initial support | expand

Message

Jiaxun Yang May 22, 2024, 3:34 p.m. UTC
Hi all,

Sorry for flooding the mailing list recently, yet another huge RFC series ahead.

So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
by Heinrich.

So far this series has implemented general support for initializing CPU,
exceptions, kernel booting, CPU and timer drivers, QEMU LoongArch virt machine
support and UEFI standard compliant EFI booting support.

LoongArch had defined 3 ISA variants, LA64, LA32 and LA32R (Reduced, intended
for MCUs). Currently, only LA64 is implemented as 32bit support in open sourc
 world is not mature yet. However, most of the code is written with 32 bit
support in mind, so it should be trivial to add 32 bit support in the future. 

It is a little endian only architecture.

This series had passed checkpatch with exceptions on some false alarms and
headers imported elsewhere.

I had tested virtio devices, qfw direct kernel booting, efistub kernel
booting and grub.

Toolchain can be found at [1] or using upstream one, I had also discovered a
couple of issues in kernel and QEMU in the porting process, patches
at [2] and [3].

To build:
```
make qemu-loongarch64_defconfig
make
``

To run in QEMU (patched):
```
qemu-system-loongarch64 -nographic -machine virt -bios u-boot.bin
```

TODOs for me on this series:
- Documents
	- I'll write board level document for QEMU,
	  what should I write at architecture level?
- MAINTAINERS entries
	- I'm not sure what I should add here, please suggest!
- Further clean-ups

TODOs on the architecture & board:
- loongson,ls7a-rtc driver
	- The only device on QEMU board haven't been supported yet
- LoongArch sandbox host support
- Implement LoongArch's PE relocations
	- No application is using it so far,
	  pe-format spec is not really clear.
- TLB enablement
	- This is required for real CPU to utilize caches
- Possibly EFI-APP support for real machine

Porting to real SoCs is out of my scope as a hobbyist, I'll try to
convince Loongson people or other hobbyists to work on that.
I intended to use U-Boot as an OVMF replacement and second stage BL.

Any comments are much appreciated!

Thanks

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
Jiaxun Yang (16):
      lib: fdtdec: Handle multiple memory nodes
      linux/io.h: Use map_physmem to implement ioremap
      image: Take entry point as an output of setup_booti
      elf.h Define LoongArch bits
      image: Define IH_ARCH_LOONGARCH
      LoongArch: skeleton and headers
      LoongArch: lib: General routines
      LoongArch: CPU assembly routines
      LoongArch: Exception handling
      LoongArch: Boot Image bits
      LoongArch: Generic CPU type
      cpu: Add loongarch_cpu driver
      timer: Add loongarch_timer driver
      board: emulation: Add qemu-loongarch
      efi: LoongArch: Define LoongArch bits everywhere
      efi: LoongArch: Implement everything

 arch/Kconfig                                       |   15 +
 arch/arm/lib/image.c                               |    3 +-
 arch/loongarch/Kconfig                             |   49 +
 arch/loongarch/Makefile                            |   19 +
 arch/loongarch/config.mk                           |   27 +
 arch/loongarch/cpu/Makefile                        |    9 +
 arch/loongarch/cpu/cpu.c                           |   28 +
 arch/loongarch/cpu/generic/Kconfig                 |   13 +
 arch/loongarch/cpu/generic/Makefile                |    7 +
 arch/loongarch/cpu/generic/cpu.c                   |   22 +
 arch/loongarch/cpu/generic/dram.c                  |   21 +
 arch/loongarch/cpu/genex.S                         |   21 +
 arch/loongarch/cpu/smp_secondary.S                 |   55 +
 arch/loongarch/cpu/start.S                         |  169 +++
 arch/loongarch/cpu/u-boot.lds                      |   85 ++
 arch/loongarch/dts/Makefile                        |   13 +
 arch/loongarch/dts/qemu-loongarch64.dts            |    9 +
 arch/loongarch/include/asm/acpi_table.h            |    8 +
 arch/loongarch/include/asm/addrspace.h             |   87 ++
 .../include/asm/arch-generic/entry-init.h          |   15 +
 arch/loongarch/include/asm/asm.h                   |  186 +++
 arch/loongarch/include/asm/atomic.h                |   12 +
 arch/loongarch/include/asm/barrier.h               |  138 ++
 arch/loongarch/include/asm/bitops.h                |  156 +++
 arch/loongarch/include/asm/byteorder.h             |   22 +
 arch/loongarch/include/asm/cache.h                 |   24 +
 arch/loongarch/include/asm/config.h                |   11 +
 arch/loongarch/include/asm/cpu.h                   |  123 ++
 arch/loongarch/include/asm/dma-mapping.h           |   27 +
 arch/loongarch/include/asm/global_data.h           |   43 +
 arch/loongarch/include/asm/gpio.h                  |   11 +
 arch/loongarch/include/asm/io.h                    |  399 ++++++
 arch/loongarch/include/asm/linkage.h               |   11 +
 arch/loongarch/include/asm/loongarch.h             | 1468 ++++++++++++++++++++
 arch/loongarch/include/asm/posix_types.h           |   87 ++
 arch/loongarch/include/asm/processor.h             |   11 +
 arch/loongarch/include/asm/ptrace.h                |   33 +
 arch/loongarch/include/asm/regdef.h                |   42 +
 arch/loongarch/include/asm/sections.h              |    8 +
 arch/loongarch/include/asm/setjmp.h                |   25 +
 arch/loongarch/include/asm/spl.h                   |   11 +
 arch/loongarch/include/asm/stackframe.h            |  175 +++
 arch/loongarch/include/asm/string.h                |   11 +
 arch/loongarch/include/asm/system.h                |   74 +
 arch/loongarch/include/asm/types.h                 |   37 +
 arch/loongarch/include/asm/u-boot-loongarch.h      |   23 +
 arch/loongarch/include/asm/u-boot.h                |   30 +
 arch/loongarch/include/asm/unaligned.h             |   11 +
 arch/loongarch/lib/Makefile                        |   26 +
 arch/loongarch/lib/asm-offsets.c                   |   66 +
 arch/loongarch/lib/boot.c                          |   14 +
 arch/loongarch/lib/bootm.c                         |  177 +++
 arch/loongarch/lib/cache.c                         |   73 +
 arch/loongarch/lib/crt0_loongarch_efi.S            |  182 +++
 arch/loongarch/lib/elf_loongarch_efi.lds           |   76 +
 arch/loongarch/lib/image.c                         |   66 +
 arch/loongarch/lib/interrupts.c                    |  189 +++
 arch/loongarch/lib/reloc_loongarch_efi.c           |  107 ++
 arch/loongarch/lib/reset.c                         |   14 +
 arch/loongarch/lib/setjmp.S                        |   52 +
 arch/riscv/lib/image.c                             |    4 +-
 arch/sandbox/lib/bootm.c                           |    2 +-
 board/emulation/qemu-loongarch/Kconfig             |   68 +
 board/emulation/qemu-loongarch/MAINTAINERS         |    7 +
 board/emulation/qemu-loongarch/Makefile            |    6 +
 board/emulation/qemu-loongarch/qemu-loongarch.c    |   84 ++
 board/emulation/qemu-loongarch/qemu-loongarch.env  |    6 +
 boot/bootm.c                                       |    5 +-
 boot/bootmeth_efi.c                                |    2 +
 boot/image.c                                       |    1 +
 cmd/Kconfig                                        |    2 +-
 cmd/booti.c                                        |    5 +-
 common/spl/spl.c                                   |    9 +-
 configs/qemu-loongarch64_defconfig                 |   36 +
 drivers/cpu/Kconfig                                |    6 +
 drivers/cpu/Makefile                               |    1 +
 drivers/cpu/loongarch_cpu.c                        |  148 ++
 drivers/timer/Kconfig                              |    8 +
 drivers/timer/Makefile                             |    1 +
 drivers/timer/loongarch_timer.c                    |  112 ++
 include/asm-generic/pe.h                           |    2 +
 include/config_distro_bootcmd.h                    |    5 +
 include/configs/qemu-loongarch.h                   |   13 +
 include/efi_default_filename.h                     |    2 +
 include/elf.h                                      |    9 +-
 include/image.h                                    |    4 +-
 include/linux/io.h                                 |    3 +-
 lib/efi_loader/Kconfig                             |    2 +-
 lib/efi_loader/efi_image_loader.c                  |    7 +
 lib/efi_loader/efi_runtime.c                       |    4 +
 lib/efi_selftest/efi_selftest_miniapp_exception.c  |    2 +
 lib/fdtdec.c                                       |  137 +-
 92 files changed, 5559 insertions(+), 70 deletions(-)
---
base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
change-id: 20240522-loongarch-8a04c1e34a47

Best regards,

Comments

Tom Rini May 23, 2024, 3:25 p.m. UTC | #1
On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:

> Hi all,
> 
> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
> 
> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
> by Heinrich.

My big feedback here, and it applies to all of your other series as
well, is to please update CI to make use of and test this. On the Docker
side, update tools/docker/Dockerfile as needed. For Azure, you can tell
it to use a different image and then follow the documentation on
https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
you can at least use their "linter" to make sure that your additions
have the correct syntax. Thanks.
Jiaxun Yang May 23, 2024, 3:38 p.m. UTC | #2
在2024年5月23日五月 下午4:25,Tom Rini写道:
> On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
>
>> Hi all,
>> 
>> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
>> 
>> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
>> by Heinrich.
>
> My big feedback here, and it applies to all of your other series as
> well, is to please update CI to make use of and test this. On the Docker
> side, update tools/docker/Dockerfile as needed. For Azure, you can tell
> it to use a different image and then follow the documentation on
> https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
> you can at least use their "linter" to make sure that your additions
> have the correct syntax. Thanks.

Hi Tom,

Thanks for the feedback, I thought CI is for custodians only :-)

Do you mean I should include azure/gitlab pipeline file to create
pipeline for those new qemu targets?

Thanks

>
> -- 
> Tom
>
> 附件:
> * signature.asc
Tom Rini May 23, 2024, 3:43 p.m. UTC | #3
On Thu, May 23, 2024 at 04:38:52PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年5月23日五月 下午4:25,Tom Rini写道:
> > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
> >
> >> Hi all,
> >> 
> >> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
> >> 
> >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
> >> by Heinrich.
> >
> > My big feedback here, and it applies to all of your other series as
> > well, is to please update CI to make use of and test this. On the Docker
> > side, update tools/docker/Dockerfile as needed. For Azure, you can tell
> > it to use a different image and then follow the documentation on
> > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
> > you can at least use their "linter" to make sure that your additions
> > have the correct syntax. Thanks.
> 
> Hi Tom,
> 
> Thanks for the feedback, I thought CI is for custodians only :-)
> 
> Do you mean I should include azure/gitlab pipeline file to create
> pipeline for those new qemu targets?

Yes, just like the rest of the QEMU targets.
Peter Robinson May 23, 2024, 3:47 p.m. UTC | #4
On Thu, 23 May 2024 at 16:39, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
>
>
> 在2024年5月23日五月 下午4:25,Tom Rini写道:
> > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
> >
> >> Hi all,
> >>
> >> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
> >>
> >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
> >> by Heinrich.
> >
> > My big feedback here, and it applies to all of your other series as
> > well, is to please update CI to make use of and test this. On the Docker
> > side, update tools/docker/Dockerfile as needed. For Azure, you can tell
> > it to use a different image and then follow the documentation on
> > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
> > you can at least use their "linter" to make sure that your additions
> > have the correct syntax. Thanks.
>
> Hi Tom,
>
> Thanks for the feedback, I thought CI is for custodians only :-)

Well when this lands you'll become a custodian ;-)

> Do you mean I should include azure/gitlab pipeline file to create
> pipeline for those new qemu targets?
>
> Thanks
>
> >
> > --
> > Tom
> >
> > 附件:
> > * signature.asc
>
> --
> - Jiaxun
Jiaxun Yang June 4, 2024, 10:50 a.m. UTC | #5
在2024年5月23日五月 下午4:43,Tom Rini写道:
> On Thu, May 23, 2024 at 04:38:52PM +0100, Jiaxun Yang wrote:
>> 
>> 
>> 在2024年5月23日五月 下午4:25,Tom Rini写道:
>> > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
>> >
>> >> Hi all,
>> >> 
>> >> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
>> >> 
>> >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
>> >> by Heinrich.
>> >
>> > My big feedback here, and it applies to all of your other series as
>> > well, is to please update CI to make use of and test this. On the Docker
>> > side, update tools/docker/Dockerfile as needed. For Azure, you can tell
>> > it to use a different image and then follow the documentation on
>> > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
>> > you can at least use their "linter" to make sure that your additions
>> > have the correct syntax. Thanks.
>> 
>> Hi Tom,
>> 
>> Thanks for the feedback, I thought CI is for custodians only :-)
>> 
>> Do you mean I should include azure/gitlab pipeline file to create
>> pipeline for those new qemu targets?
>
> Yes, just like the rest of the QEMU targets.

Hi Tom,

I've got CI working on azure-pipeline for my arm64be, xtensa and LoongArch
work.

What is the best way to submit all these changes? I think I can send patches to
update Dockerfile and CI hooks first, then after new docker image being built
I'll combine CI related changes into these series and refresh all those series.

Will it work for you?

Thanks

>
> -- 
> Tom
>
> 附件:
> * signature.asc
Tom Rini June 4, 2024, 5:09 p.m. UTC | #6
On Tue, Jun 04, 2024 at 11:50:20AM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年5月23日五月 下午4:43,Tom Rini写道:
> > On Thu, May 23, 2024 at 04:38:52PM +0100, Jiaxun Yang wrote:
> >> 
> >> 
> >> 在2024年5月23日五月 下午4:25,Tom Rini写道:
> >> > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
> >> >
> >> >> Hi all,
> >> >> 
> >> >> Sorry for flooding the mailing list recently, yet another huge RFC series ahead.
> >> >> 
> >> >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as suggested
> >> >> by Heinrich.
> >> >
> >> > My big feedback here, and it applies to all of your other series as
> >> > well, is to please update CI to make use of and test this. On the Docker
> >> > side, update tools/docker/Dockerfile as needed. For Azure, you can tell
> >> > it to use a different image and then follow the documentation on
> >> > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab
> >> > you can at least use their "linter" to make sure that your additions
> >> > have the correct syntax. Thanks.
> >> 
> >> Hi Tom,
> >> 
> >> Thanks for the feedback, I thought CI is for custodians only :-)
> >> 
> >> Do you mean I should include azure/gitlab pipeline file to create
> >> pipeline for those new qemu targets?
> >
> > Yes, just like the rest of the QEMU targets.
> 
> Hi Tom,
> 
> I've got CI working on azure-pipeline for my arm64be, xtensa and LoongArch
> work.
> 
> What is the best way to submit all these changes? I think I can send patches to
> update Dockerfile and CI hooks first, then after new docker image being built
> I'll combine CI related changes into these series and refresh all those series.
> 
> Will it work for you?

Yes, please do a series that updates the Dockerfile and CI yaml files
(do your best to update .gitlab-ci.yml as well, I'll fix it up if
needed). Then say the other series depend on that previous one being
applied. You can post an RFC patch or what have you that just changes to
pointing at your test images instead and so long as it's a stand alone
patch it's easy to drop. Thanks!