[PATCH v2 00/16] LoongArch initial support

[Tom Rini]

On Wed, Jul 01, 2026 at 11:17:52AM +0000, Yao Zi wrote:

> Hi all,
> 
> After talking to Jiaxun privately, I decided to take over the series.
> 
> 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 and education purpose). This is a little-endian only
> architecture. Only LA64 is implemented in this series since the hardware
> is more widely available, and I'll work on 32bit support later.
> 
> This series had passed checkpatch with exceptions on some false alarms
> and headers imported elsewhere. I've tested virtio devices, direct
> kernel booting, efistub kernel booting and grub. For loongarch64 CI, I
> would continue to work on Jiaxun's another series[1] soon.
> 
> Toolchain can be found at [2] or using upstream one, to build
> 
> 	make qemu-loongarch64_defconfig
> 	make
> 
> To run in QEMU:
> 
> 	qemu-system-loongarch64 -nographic -machine virt -bios u-boot.bin

So on this note, we need to also have changes for:
- buildman to fetch the toolchain, which is easy since it's part of the
  normal kernel.org ones.
- tools/docker/Dockerfile to fetch the toolchain, for CI
- Changes to .gitlab-ci.yml and .azure-pipelines.yml to build loongarch
- Changes to those files to also fire off QEMU for loonarch
- Changes to https://source.denx.de/u-boot/u-boot-test-hooks to support
  the previous requirement.

> 
> TODOs on the architecture & board:
> - loongson,ls7a-rtc driver
>  - The only device on QEMU board haven't been supported yet
> - LoongArch sandbox host support
> - TLB enablement
>  - This is required for real CPU to utilize caches
> - Possibly EFI-APP support for real machine
> 
> I have one question regarding the process: I've decided to
> coordinate with Jiaxun to maintain the loongarch port, and AFAIK we
> would need a custodian tree on U-Boot's GitLab instance in order to run
> CI. If this true, what's the process of creating a tree?

I can work with you both off-list to get one created.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260701/c8e06402/attachment.sig>