Re: [Buildroot] Interested in board support for BeagleV-Ahead

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Kilian,

On Thu, 10 Aug 2023 17:25:00 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> It actually was not my own fault regarding the errors about unknown vector 
> instructions. It seems that the core of the TH1520 SoC - the Xuantie C910 - 
> implements a now obsolete version of the RiscV vector extension, namely 
> version 0.7.1 (see [1]). However, only past gcc version seem to have supported 
> this vector extension version. Recent gcc versions seem to not support it. 
> Regarding the Xuantie C906 core, I found out that there now exists some -
> mcpu=thead-c906 option (see [2]). However, I was not able to successfully 
> compile a dummy example with one of the v0.7.1 vector instructions myself, 
> using that option.

From the gcc documentation, it seems like there is no -mcpu=thead-c906,
but only a -mtune=thead-c906, which only changes optimization
"details", I don't think it will do anything in terms of supporting a
non-standard vector extension. However, I'm not an expert in RISC-V
extensions, so maybe I'm wrong on this.

> Then I also found a RiscV toolchain, which has some "rvv-0.7.1" branch 
> (https://github.com/brucehoult/riscv-gnu-toolchain). However, I was not able 
> to build it (may be my own fault). But anyway the branch seems very old and I 
> am afraid, if I try to use it, I may run into other issues.

I also don't think this is a path worth pursuing.

> So I decided to accept that I currently have a gcc which does not support the 
> old 0.7.1 version of the vector extension. Therefore, I disabled vector 
> extension support in the kernel config. This is part of my current 
> beaglev_ahead_defconfig:
> 
> BR2_GCC_VERSION_13_X=y
> BR2_GLOBAL_PATCH_DIR="board/beaglev-ahead/patches"
> BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/beaglev-ahead/linux.fragment"
> 
> The linux.fragment file overwrites the vector extension settings:
> 
> CONFIG_VECTOR=n
> CONFIG_VECTOR_0_7=n

This seems like the right thing to do, at least in a first step.

> Now, there was one more error in the custom kernel code: One function's 
> prototype and its implementation did not match, causing a -Werror=enum-int-
> mismatch:
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beaglev-v5.10.113-1.1.2/drivers/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h#L338
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beaglev-v5.10.113-1.1.2/drivers/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c#L6144
> 
> I changed the prototype accordingly and put a patch for this in my board/
> beaglev-ahead/patches/linux directory. After all this, it continued building 
> till the end.

The Vivante mess, meh.

> Now I don't know, whether the compiled uboot, kernel and rootfs would 
> function. I would have to test this. But to do so, I guess I would have to 
> figure out how to assemble these parts into an image and how to flash it into 
> the eMMC of the board.

I only briefly started looking into this. Let me know if you want me to
summarize my findings.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot