[Buildroot] Interested in board support for BeagleV-Ahead

[Buildroot] Interested in board support for BeagleV-Ahead

[Kilian Zinnecker via buildroot]

Hello,

I am interested in adding board support for the BeagleV-Ahead.

I already started trying to setup the board support, but at the moment it does 
not work yet, due to some gcc 12 and zicsr and zifencei RiscV extension issue 
(see below).

My first question is: As long as it does not yet work: Shall I already send 
(not yet working) patches to the mailing list, so that people can discuss 
about it and potentially help me? Maybe marked as RFC? Or shall I describe 
what I try as part of a normal email (like I do in this mail)?


Regarding board support, Yocto support already seems to exist:

https://git.beagleboard.org/beaglev-ahead/xuantie-yocto

Also a uboot and kernel:

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot
https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux

I was able to successfully build the uboot, flash it onto an SD card and boot 
uboot. I then started to write a defconfig for the BeagleV-Ahead, starting from 
the already existing beaglev_defconfig. I used the following uboot settings:

BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_GIT=y
BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/beagleboard/beaglev-ahead-u-boot.git"
BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="beaglev-v2020.01-1.1.2"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="light_beagle"
BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/beaglev-ahead/uboot.fragment"

The uboot fragment file overwrites a switch of the custom uboot defconfig, such 
that the custom uboot generates u-boot.dtb (without it the build fails):

CONFIG_OF_EMBED=n

For the kernel I use:

BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_10=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/archive/beaglev-v5.10.113-1.1.2/beaglev-ahead-linux-beaglev-v5.10.113-1.1.2.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="light"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="thead/light-beagle"
BR2_LINUX_KERNEL_INSTALL_TARGET=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y


When trying to build, I currently encounter the following problems:

The SoC of the BeagleV-Ahead needs RiscV Vector Extension support enabled, 
else the build fails, because it cannot deal with the assembly instructions in 
some parts of the code. Hence, I believe one needs to activate support for 
this:

BR2_RISCV_ISA_CUSTOM_RVV=y

However, this enforces that gcc 12 or higher is used, see Config.in.riscv:

https://gitlab.com/buildroot.org/buildroot/-/blob/
b10ceec75520fab80f76081f50daaaab9df890f5/arch/Config.in.riscv#L69-72

It seems that the RiscV ISA was reorganized at some point, regarding which 
extension some microarch maintenance instructions belong to. Also it seems 
that this change was adopted in gcc 12 and that this caused some issues in the 
past, also within buildroot, see here:

https://lists.buildroot.org/pipermail/buildroot/2022-July/646795.html

The patch seems to be active in buildroot currently, see here:

https://gitlab.com/buildroot.org/buildroot/-/blob/
b10ceec75520fab80f76081f50daaaab9df890f5/arch/arch.mk.riscv#L38-39

However, when trying to build, I get lots of errors, that opcodes are not 
recognised and the zicsr and zifencei extension are required, e.g.:

"arch/riscv/cpu/mtrap.S:68: Error: unrecognized opcode `csrr a0,mcause', 
extension `zicsr' required"

I already tried using gcc 11 instead (omitting BR2_RISCV_ISA_CUSTOM_RVV and 
setting BR2_GCC_VERSION_11_X=y), however, as expected I get errors that vector 
instructions are unknown. Does anyone has an idea and can help me?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

Hello,

On Wed, 09 Aug 2023 15:57:21 +0200
Kilian Zinnecker via buildroot <buildroot@buildroot.org> wrote:

> I am interested in adding board support for the BeagleV-Ahead.

Ah, ah, I was working on this as well!

> BR2_TARGET_UBOOT=y
> BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> BR2_TARGET_UBOOT_CUSTOM_GIT=y
> BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/beagleboard/beaglev-ahead-u-boot.git"
> BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="beaglev-v2020.01-1.1.2"
> BR2_TARGET_UBOOT_BOARD_DEFCONFIG="light_beagle"
> BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/beaglev-ahead/uboot.fragment"

Backport commit 1dde977518f13824b847e23275001191139bc384 from upstream
U-Boot on top of this vendor branch, it will solve your problem.

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

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

[Kilian Zinnecker via buildroot]

Hello Thomas,


> > I am interested in adding board support for the BeagleV-Ahead.
> 
> Ah, ah, I was working on this as well!

Nice, then let's do it together?

> > BR2_TARGET_UBOOT=y
> > BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> > BR2_TARGET_UBOOT_CUSTOM_GIT=y
> > BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/beagleboard/beaglev-a
> > head-u-boot.git"
> > BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="beaglev-v2020.01-1.1.2"
> > BR2_TARGET_UBOOT_BOARD_DEFCONFIG="light_beagle"
> > BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/beaglev-ahead/uboot.fragment
> > "
> 
> Backport commit 1dde977518f13824b847e23275001191139bc384 from upstream
> U-Boot on top of this vendor branch, it will solve your problem.

Great, thanks, that did the trick!

I however run into a similar problem with opensbi afterwards. As I use the 
beaglev_defconfig as basis, I also used the opensbi version defined there:

https://gitlab.com/buildroot.org/buildroot/-/blob/3a4ce27f/configs/
beaglev_defconfig#L29

However, the (2 years old) opensbi version (currently defined in the 
beaglev_defconfig) does not define the neccessary flags for the zicsr and 
zifencei extensions, needed by gcc12, as seen here in the newer opensbi 
release-1.3.x version:

https://github.com/riscv-software-src/opensbi/blob/release-1.3.x/Makefile#L274

So my build broke until I changed to release-1.3.x. This makes me wonder about 
the current beaglev_defconfig: It might be broken since bumbing gcc to v12, but 
I actually don't know. I could try building an image for the beaglev later 
today?

Now, regarding the bealgev-ahead, it seems to build opensbi on my machine. But 
I don't know whether the official opensbi is actually needed, or the custom 
version, i.e.:

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi

I still have some other problem with the build at the moment, where I have to 
look into (might be my very own fault - the errors about unknown vector 
instructions are back for some reason). But as soon as I have questions or 
news, I will send an update to the ML.

Best regards,
Kilian




_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Thomas, all

[--SNIP--]

> So my build broke until I changed to release-1.3.x. This makes me wonder
> about the current beaglev_defconfig: It might be broken since bumbing gcc
> to v12, but I actually don't know. I could try building an image for the
> beaglev later today?

fyi it seems that currently the build of the beaglev_defconfig actually is 
broken, as I suspected (current buildroot master branch). When I try to build, 
I get the following errors during starfive uboot compilation:

...
arch/riscv/cpu/mtrap.S: Assembler messages:
arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause', 
extension `zicsr' required
arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc', 
extension `zicsr' required
arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval', 
extension `zicsr' required
arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0', 
extension `zicsr' required
make[3]: *** [scripts/Makefile.build:301: arch/riscv/cpu/mtrap.o] Error 1
...
arch/riscv/cpu/start.S: Assembler messages:
arch/riscv/cpu/start.S:65: Error: unrecognized opcode `csrw stvec,t0', 
extension `zicsr' required
arch/riscv/cpu/start.S:72: Error: unrecognized opcode `csrw sie,zero', 
extension `zicsr' required
arch/riscv/cpu/start.S:347: Error: unrecognized opcode `csrw stvec,t0', 
extension `zicsr' required
make[3]: *** [scripts/Makefile.build:301: arch/riscv/cpu/start.o] Error 1
...
arch/riscv/lib/cache.c: Assembler messages:
arch/riscv/lib/cache.c:12: Error: unrecognized opcode `fence.i', extension 
`zifencei' required
make[3]: *** [scripts/Makefile.build:266: arch/riscv/lib/cache.o] Error 1
... and more ....

I also think that there is are similar issues regarding the beaglev_defconfig 
and the used, very old opensbi version and maybe also the used starfive custom 
kernel version.

I could try to bump the versions or add patches until it compiles again. 
However, I don't have a BeagleV currently at hand, so I would not be able to 
really test what I produced afterwards. So it might be better someone else, 
which has access to a BeagleV, has a look.

[--SNIP--]

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

On Thu, 10 Aug 2023 13:02:32 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> I also think that there is are similar issues regarding the beaglev_defconfig 
> and the used, very old opensbi version and maybe also the used starfive custom 
> kernel version.
> 
> I could try to bump the versions or add patches until it compiles again. 
> However, I don't have a BeagleV currently at hand, so I would not be able to 
> really test what I produced afterwards. So it might be better someone else, 
> which has access to a BeagleV, has a look.

I do have a BeagleV (not here with me though), but as I replied to
another e-mail, I think we could simply drop beaglev_defconfig as not
many samples of this platform were shipped, and it's no longer produced.

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

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

[Robert Nelson]

On Fri, Aug 11, 2023 at 9:42 AM Thomas Petazzoni via buildroot
<buildroot@buildroot.org> wrote:
>
> On Thu, 10 Aug 2023 13:02:32 +0200
> Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:
>
> > I also think that there is are similar issues regarding the beaglev_defconfig
> > and the used, very old opensbi version and maybe also the used starfive custom
> > kernel version.
> >
> > I could try to bump the versions or add patches until it compiles again.
> > However, I don't have a BeagleV currently at hand, so I would not be able to
> > really test what I produced afterwards. So it might be better someone else,
> > which has access to a BeagleV, has a look.
>
> I do have a BeagleV (not here with me though), but as I replied to
> another e-mail, I think we could simply drop beaglev_defconfig as not
> many samples of this platform were shipped, and it's no longer produced.

So the plan from BeagleBoard.org is:

beaglev-<device>

So the TH1520 based BeagleV is: beaglev-ahead

Looking at all our gitlab repos, yeah i called every config `beaglev_`...

add that to my cleanup list..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

On Fri, Aug 11, 2023 at 4:30 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>
> On Fri, Aug 11, 2023 at 9:42 AM Thomas Petazzoni via buildroot
> <buildroot@buildroot.org> wrote:
> >
> > On Thu, 10 Aug 2023 13:02:32 +0200
> > Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:
> >
> > > I also think that there is are similar issues regarding the beaglev_defconfig
> > > and the used, very old opensbi version and maybe also the used starfive custom
> > > kernel version.
> > >
> > > I could try to bump the versions or add patches until it compiles again.
> > > However, I don't have a BeagleV currently at hand, so I would not be able to
> > > really test what I produced afterwards. So it might be better someone else,
> > > which has access to a BeagleV, has a look.
> >
> > I do have a BeagleV (not here with me though), but as I replied to
> > another e-mail, I think we could simply drop beaglev_defconfig as not
> > many samples of this platform were shipped, and it's no longer produced.
>
> So the plan from BeagleBoard.org is:
>
> beaglev-<device>
>
> So the TH1520 based BeagleV is: beaglev-ahead
>
> Looking at all our gitlab repos, yeah i called every config `beaglev_`...
>
> add that to my cleanup list..

Okay Kilian, these all build with x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

opensbi: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/tree/0.9-1.1.2-ubuntu
u-boot: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beaglev-v2020.01-1.1.2-ubuntu
linux: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/tree/beaglev-v5.10.113-1.1.2-ubuntu

For bandwidth issues, please use the github mirrors directly in
patches for buildroot, as these are push mirrored from
git.beagleboard.org/ , at worst they lag by 10 minutes after a new
commit

opensbi: https://github.com/beagleboard/beaglev-ahead-opensbi/tree/0.9-1.1.2-ubuntu
u-boot: https://github.com/beagleboard/beaglev-ahead-u-boot/tree/beaglev-v2020.01-1.1.2-ubuntu
linux: https://github.com/beagleboard/linux/tree/beaglev-v5.10.113-1.1.2-ubuntu

Verification ci image, available for the next 14 days..

https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/jobs/13303

```
voodoo@hestia:~/Downloads$ unzip xuantie-ubuntu-1.1.2-13303.zip
Archive:  xuantie-ubuntu-1.1.2-13303.zip
  inflating: deploy/boot.ext4.xz
  inflating: deploy/fastboot_emmc.sh
  inflating: deploy/mac_fastboot_emmc.sh
  inflating: deploy/root.ext4.xz
  inflating: deploy/u-boot-with-spl.bin
voodoo@hestia:~/Downloads$ cd deploy/
voodoo@hestia:~/Downloads/deploy$ sudo ./fastboot_emmc.sh
```

Boot log: https://gist.github.com/RobertCNelson/42deb24c41a92ce5e89e80dfe058e3d8


Regards,

--
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

thanks for all the information you provided so far! It is much appreciated!

However, I have to digest all of it, as I am not so familiar with a lot of 
thinks and I will ask some "stupid" questions ;)

[--SNIP--]

> Okay Kilian, these all build with
> x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

Where exactly do I find kernel.org's x86_64-gcc-13.2.0-nolibc-riscv64-
linux.tar.xz toolchain? (Yes, my questions are that stupid ;)) Should I prefer 
it to the gcc 13.2 toolchain build by buildroot natively?

> opensbi:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/tree/0.9-> 1.1.2-ubuntu u-boot:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagl
> ev-v2020.01-1.1.2-ubuntu linux:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/tree/beagle
> v-v5.10.113-1.1.2-ubuntu
> 
> For bandwidth issues, please use the github mirrors directly in
> patches for buildroot, as these are push mirrored from
> git.beagleboard.org/ , at worst they lag by 10 minutes after a new
> commit
> 
> opensbi:
> https://github.com/beagleboard/beaglev-ahead-opensbi/tree/0.9-1.1.2-ubuntu
> u-boot:
> https://github.com/beagleboard/beaglev-ahead-u-boot/tree/beaglev-v2020.01-1
> .1.2-ubuntu linux:
> https://github.com/beagleboard/linux/tree/beaglev-v5.10.113-1.1.2-ubuntu

Yes, I saw the notes about the mirrors on github on the beagleboard gitlab 
page. I will use the mirrors!

> Verification ci image, available for the next 14 days..
> 
> https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/jobs/13303
> 
> ```
> voodoo@hestia:~/Downloads$ unzip xuantie-ubuntu-1.1.2-13303.zip
> Archive:  xuantie-ubuntu-1.1.2-13303.zip
>   inflating: deploy/boot.ext4.xz
>   inflating: deploy/fastboot_emmc.sh
>   inflating: deploy/mac_fastboot_emmc.sh
>   inflating: deploy/root.ext4.xz
>   inflating: deploy/u-boot-with-spl.bin
> voodoo@hestia:~/Downloads$ cd deploy/
> voodoo@hestia:~/Downloads/deploy$ sudo ./fastboot_emmc.sh
> ```

Great, thanks! So this is then meant, that I can use it for myself to see that 
my board boots with this and I can also look what is done in the scripts, so 
that I can reproduce that in the buildroot board support?

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

On Sat, 12 Aug 2023 11:51:47 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> > Okay Kilian, these all build with
> > x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz  
> 
> Where exactly do I find kernel.org's x86_64-gcc-13.2.0-nolibc-riscv64-
> linux.tar.xz toolchain? (Yes, my questions are that stupid ;)) Should I prefer 
> it to the gcc 13.2 toolchain build by buildroot natively?

Kernel.org toolchains are at https://mirrors.edge.kernel.org/pub/tools/crosstool/.

However, this is not very relevant: if it doesn't build with the
Buildroot provided toolchain, we cannot take it.

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

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

[Kilian Zinnecker via buildroot]

Hello Robert and Thomas,

I am making a bit of progress. However, I still have some issues.

[--SNIP--]

> Okay Kilian, these all build with
> x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz
> 
> opensbi:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/tree/0.9-> 1.1.2-ubuntu u-boot:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagl
> ev-v2020.01-1.1.2-ubuntu linux:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/tree/beagle
> v-v5.10.113-1.1.2-ubuntu
> 
> For bandwidth issues, please use the github mirrors directly in
> patches for buildroot, as these are push mirrored from
> git.beagleboard.org/ , at worst they lag by 10 minutes after a new
> commit
> 
> opensbi:
> https://github.com/beagleboard/beaglev-ahead-opensbi/tree/0.9-1.1.2-ubuntu
> u-boot:
> https://github.com/beagleboard/beaglev-ahead-u-boot/tree/beaglev-v2020.01-1
> .1.2-ubuntu linux:
> https://github.com/beagleboard/linux/tree/beaglev-v5.10.113-1.1.2-ubuntu

When buildroot compiles opensbi, I get a lot of "undefined reference to 
`__stack_chk_guard'" errors. I think that either the necessary "-fno-stack-
protector" flag is not active during build, or that the toolchain does not 
provide the necessary functions. I tried adding something similar like this

https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/arm-trusted-firmware.mk?ref_type=heads#L67-72
https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/Config.in?ref_type=heads#L234-251

to the opensbi config and make files, but it did not help. I also checked and 
the .config contains the following flags:

BR2_SSP_STRONG=y
BR2_SSP_OPTION="-fstack-protector-strong"
BR2_TARGET_OPENSBI_SSP=y
BR2_TARGET_OPENSBI_SSP_LEVEL="strong"

Does anyone have an idea? I can provide more info if needed.

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

On Fri, Aug 18, 2023 at 12:18 PM Kilian Zinnecker
<kilian.zinnecker@mail.de> wrote:
>
> Hello Robert and Thomas,
>
> I am making a bit of progress. However, I still have some issues.
>
> [--SNIP--]
>
> > Okay Kilian, these all build with
> > x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz
> >
> > opensbi:
> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/tree/0.9-> 1.1.2-ubuntu u-boot:
> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagl
> > ev-v2020.01-1.1.2-ubuntu linux:
> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/tree/beagle
> > v-v5.10.113-1.1.2-ubuntu
> >
> > For bandwidth issues, please use the github mirrors directly in
> > patches for buildroot, as these are push mirrored from
> > git.beagleboard.org/ , at worst they lag by 10 minutes after a new
> > commit
> >
> > opensbi:
> > https://github.com/beagleboard/beaglev-ahead-opensbi/tree/0.9-1.1.2-ubuntu
> > u-boot:
> > https://github.com/beagleboard/beaglev-ahead-u-boot/tree/beaglev-v2020.01-1
> > .1.2-ubuntu linux:
> > https://github.com/beagleboard/linux/tree/beaglev-v5.10.113-1.1.2-ubuntu
>
> When buildroot compiles opensbi, I get a lot of "undefined reference to
> `__stack_chk_guard'" errors. I think that either the necessary "-fno-stack-
> protector" flag is not active during build, or that the toolchain does not
> provide the necessary functions. I tried adding something similar like this
>
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/arm-trusted-firmware.mk?ref_type=heads#L67-72
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/Config.in?ref_type=heads#L234-251
>
> to the opensbi config and make files, but it did not help. I also checked and
> the .config contains the following flags:
>
> BR2_SSP_STRONG=y
> BR2_SSP_OPTION="-fstack-protector-strong"
> BR2_TARGET_OPENSBI_SSP=y
> BR2_TARGET_OPENSBI_SSP_LEVEL="strong"
>
> Does anyone have an idea? I can provide more info if needed.

Oh let's backport:
https://github.com/riscv-software-src/opensbi/commit/6139ab272b1e69e4ff8a37655969c877ae86de49

Remember, our version of OpenSBI is pretty ancient (0.9) we are only
stuck on it for the thead v5.10.113-1.1.2-ubuntu branch, on mainline
we are already usig mainline openSBI..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

On Fri, Aug 18, 2023 at 4:33 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>
> On Fri, Aug 18, 2023 at 12:18 PM Kilian Zinnecker
> <kilian.zinnecker@mail.de> wrote:
> >
> > Hello Robert and Thomas,
> >
> > I am making a bit of progress. However, I still have some issues.
> >
> > [--SNIP--]
> >
> > > Okay Kilian, these all build with
> > > x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz
> > >
> > > opensbi:
> > > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/tree/0.9-> 1.1.2-ubuntu u-boot:
> > > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagl
> > > ev-v2020.01-1.1.2-ubuntu linux:
> > > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/tree/beagle
> > > v-v5.10.113-1.1.2-ubuntu
> > >
> > > For bandwidth issues, please use the github mirrors directly in
> > > patches for buildroot, as these are push mirrored from
> > > git.beagleboard.org/ , at worst they lag by 10 minutes after a new
> > > commit
> > >
> > > opensbi:
> > > https://github.com/beagleboard/beaglev-ahead-opensbi/tree/0.9-1.1.2-ubuntu
> > > u-boot:
> > > https://github.com/beagleboard/beaglev-ahead-u-boot/tree/beaglev-v2020.01-1
> > > .1.2-ubuntu linux:
> > > https://github.com/beagleboard/linux/tree/beaglev-v5.10.113-1.1.2-ubuntu
> >
> > When buildroot compiles opensbi, I get a lot of "undefined reference to
> > `__stack_chk_guard'" errors. I think that either the necessary "-fno-stack-
> > protector" flag is not active during build, or that the toolchain does not
> > provide the necessary functions. I tried adding something similar like this
> >
> > https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/arm-trusted-firmware.mk?ref_type=heads#L67-72
> > https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/arm-trusted-firmware/Config.in?ref_type=heads#L234-251
> >
> > to the opensbi config and make files, but it did not help. I also checked and
> > the .config contains the following flags:
> >
> > BR2_SSP_STRONG=y
> > BR2_SSP_OPTION="-fstack-protector-strong"
> > BR2_TARGET_OPENSBI_SSP=y
> > BR2_TARGET_OPENSBI_SSP_LEVEL="strong"
> >
> > Does anyone have an idea? I can provide more info if needed.
>
> Oh let's backport:
> https://github.com/riscv-software-src/opensbi/commit/6139ab272b1e69e4ff8a37655969c877ae86de49
>
> Remember, our version of OpenSBI is pretty ancient (0.9) we are only
> stuck on it for the thead v5.10.113-1.1.2-ubuntu branch, on mainline
> we are already usig mainline openSBI..

and pushed: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/commits/0.9-1.1.2-ubuntu

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

> > Oh let's backport:
> > https://github.com/riscv-software-src/opensbi/commit/6139ab272b1e69e4ff8a3
> > 7655969c877ae86de49
> > 
> > Remember, our version of OpenSBI is pretty ancient (0.9) we are only
> > stuck on it for the thead v5.10.113-1.1.2-ubuntu branch, on mainline
> > we are already usig mainline openSBI..
> 
> and pushed:
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi/-/commits/0
> .9-1.1.2-ubuntu

Great, thanks, it does work now!

I am now able to compile everything. The u-boot-with-spl.bin, generated by 
buildroot, is also working. When I flash it to an SD card, I can boot the uboot 
(see also the beagle forum thread how booting the u-boot-with-spl.bin from SD 
card works here: https://forum.beagleboard.org/t/beaglev-ahead-automatic-sd-card-boot/35586)

I also have created a genimage.cfg, which creates a boot partition with all 
files you mentioned earlier. However, when creating an sdcard.img with this 
genimage.cfg, then the uboot does not boot anymore. I therefore believe, that 
my script is not yet correct, probably with regards to how the uboot partition 
is set up. I am not so much familiar with this. Does anyone have an idea? are 
the contents of my current genimage.cfg:

# SD card image for BeagleV-Ahead

image boot.vfat {
	vfat {
		files = {
			"fw_dynamic.bin",
			"Image",
			"light_aon_fpga.bin",
			"light-beagle.dtb",
			"light_c906_audio.bin",
		}

		file overlays/BBORG_LOAD-00A2.dtbo {
			image = "overlays/BBORG_LOAD-00A2.dtbo"
		}

		file overlays/BBORG_RELAY-00A2.dtbo {
			image = "overlays/BBORG_RELAY-00A2.dtbo"
		}

		file overlays/BONE-LED_P8_03.dtbo {
			image = "overlays/BONE-LED_P8_03.dtbo"
		}

		file overlays/BONE-LED_P9_11.dtbo {
			image = "overlays/BONE-LED_P9_11.dtbo"
		}

		file overlays/BVA-MIKROBUS-0.dtbo {
			image = "overlays/BVA-MIKROBUS-0.dtbo"
		}

		file extlinux/extlinux.conf {
			image = "extlinux.conf"
		}
	}
	size = 32M
}

image sdcard.img {
	hdimage {
		partition-table-type = "hybrid"
	}

	partition uboot {
		in-partition-table = "false"
		image = "u-boot-with-spl.bin"
		offset = 0K
		size = 1048576
		holes = {"(440; 1048576)"}
	}

	partition boot {
		partition-type = "0xC"
		bootable = "true"
		image = "boot.vfat"
	}

	partition rootfs {
		partition-type = 0x83
		image = "rootfs.ext2"
	}
}

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

Hello,

On Fri, 18 Aug 2023 19:18:28 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> When buildroot compiles opensbi, I get a lot of "undefined reference to 
> `__stack_chk_guard'" errors. I think that either the necessary "-fno-stack-
> protector" flag is not active during build, or that the toolchain does not 
> provide the necessary functions. I tried adding something similar like this

undefined reference to __stack_chk_guard happens when the code is built
with Stack Smashing Protection enabled, but that doesn't work well for
freestanding code (like bootloader/firmware code), unless it explicitly
provides the runtime code needed to support Stack Smashing Protection.
So indeed to override that, -fno-stack-protector needs to be passed
when building such bootloader/firmware code.

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

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

[Kilian Zinnecker via buildroot]

Hello Thomas,

[--SNIP--]

> I still have some other problem with the build at the moment, where I have
> to look into (might be my very own fault - the errors about unknown vector
> instructions are back for some reason). But as soon as I have questions or
> news, I will send an update to the ML.

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.

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.

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

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.

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.

Best regards,
Kilian

[1] https://ftp.libre-soc.org/466100a052.pdf
[2] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/RISC-V-Options.html


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

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

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

[Kilian Zinnecker via buildroot]

Hello Thomas,

[--SNIP--]

> 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.

Yes, I agree. I must have confused it. So it makes sense, that this switch did 
not help.

[--SNIP--]

> > 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.

Yes, I really appreciate all information that may help! I am not very 
experienced, especially when it comes to assembling a boot image from the 
artifacts, so it would be a great help.

Best regards,
Kilian




_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

On Sat, 12 Aug 2023 11:56:45 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> Yes, I really appreciate all information that may help! I am not very 
> experienced, especially when it comes to assembling a boot image from the 
> artifacts, so it would be a great help.

Wanted to experiment a bit. Turns out that the USB TTL cable I happen
to have with me falls into the "It has been noticed that 6pin FTDI
cables like this doesn’t seem work with BeagleV Ahead debug port and
there might be other cables/modules that will show garbage when
connected to the board" at
https://docs.beagleboard.org/latest/boards/beaglev/ahead/02-quick-start.html,
so I don't have access to the board UART to explore things, sadly.

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

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

[Kilian Zinnecker via buildroot]

Hello Thomas,

> > Yes, I really appreciate all information that may help! I am not very
> > experienced, especially when it comes to assembling a boot image from the
> > artifacts, so it would be a great help.
> 
> Wanted to experiment a bit. Turns out that the USB TTL cable I happen
> to have with me falls into the "It has been noticed that 6pin FTDI
> cables like this doesn’t seem work with BeagleV Ahead debug port and
> there might be other cables/modules that will show garbage when
> connected to the board" at
> https://docs.beagleboard.org/latest/boards/beaglev/ahead/02-quick-start.html
> , so I don't have access to the board UART to explore things, sadly.

Yes, same problem over here: None of my FTDI cables works. There is also a 
forum post about this. I did have one cheap adapter, that did work indeed, 
however it decided to not want to continue working for some reason. I ordered 
a few one with a CP2102, like it was suggested on the forum. Till they arrive 
(around mid of next week) there is not too much I can do, too ...

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

Hello Kilian,

On Thu, 10 Aug 2023 11:20:49 +0200
Kilian Zinnecker <kilian.zinnecker@mail.de> wrote:

> > Ah, ah, I was working on this as well!  
> 
> Nice, then let's do it together?

Sure, why not. You seem to be ahead of me already, so let me know when
you have something and I can give it a test. Or if you face some issue,
I can have a look and try to help.

> > Backport commit 1dde977518f13824b847e23275001191139bc384 from upstream
> > U-Boot on top of this vendor branch, it will solve your problem.  
> 
> Great, thanks, that did the trick!

I know, because I already encountered this exactly same problem while
trying to build U-Boot for the BeagleV-Ahead :-)

> I however run into a similar problem with opensbi afterwards. As I use the 
> beaglev_defconfig as basis, I also used the opensbi version defined there:
> 
> https://gitlab.com/buildroot.org/buildroot/-/blob/3a4ce27f/configs/
> beaglev_defconfig#L29

I'm not sure it makes sense to use the same OpenSBI version as the one
that was used for the original BeagleV. You probably want to check the
Yocto layers for the BeagleV-Ahead to see which OpenSBI
version/configuration they are building.

> However, the (2 years old) opensbi version (currently defined in the 
> beaglev_defconfig) does not define the neccessary flags for the zicsr and 
> zifencei extensions, needed by gcc12, as seen here in the newer opensbi 
> release-1.3.x version:
> 
> https://github.com/riscv-software-src/opensbi/blob/release-1.3.x/Makefile#L274
> 
> So my build broke until I changed to release-1.3.x. This makes me wonder about 
> the current beaglev_defconfig: It might be broken since bumbing gcc to v12, but 
> I actually don't know. I could try building an image for the beaglev later 
> today?

The beaglev_defconfig indeed fails to build in U-Boot:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4839059972

However, I think beaglev_defconfig should probably be removed, this
board is not produced.

> Now, regarding the bealgev-ahead, it seems to build opensbi on my machine. But 
> I don't know whether the official opensbi is actually needed, or the custom 
> version, i.e.:
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-opensbi

See
https://git.beagleboard.org/beaglev-ahead/xuantie-yocto/-/tree/Linux_SDK_V1.1.2-light-beagle/meta-light/recipes-bsp/opensbi
for how they are building OpenSBI.

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

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

[Robert Nelson]

On Wed, Aug 9, 2023 at 8:57 AM Kilian Zinnecker via buildroot
<buildroot@buildroot.org> wrote:
>
> Hello,
>
> I am interested in adding board support for the BeagleV-Ahead.
>
> I already started trying to setup the board support, but at the moment it does
> not work yet, due to some gcc 12 and zicsr and zifencei RiscV extension issue
> (see below).

Awesome work!

BTW, i've created a special u-boot branch for mainline gcc situations,
with *-ubuntu extension on the branch..

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beaglev-v2020.01-1.1.2-ubuntu

Using kernel.org's x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

I've been mostly working on mainline for the board with @Drew Fustini

Otherwise on the mainline we've been using main branch of opensbi and
linu's 6.5.x-rc (only eMMC wip support).. not much else on the
mainline branch yet..
Regards,



-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

> > I am interested in adding board support for the BeagleV-Ahead.
> > 
> > I already started trying to setup the board support, but at the moment it
> > does not work yet, due to some gcc 12 and zicsr and zifencei RiscV
> > extension issue (see below).
> 
> Awesome work!

Thanks!

> BTW, i've created a special u-boot branch for mainline gcc situations,
> with *-ubuntu extension on the branch..
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagle
> v-v2020.01-1.1.2-ubuntu

So should I try using that branch then?

> Using kernel.org's x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz
> 
> I've been mostly working on mainline for the board with @Drew Fustini
> 
> Otherwise on the mainline we've been using main branch of opensbi and
> linu's 6.5.x-rc (only eMMC wip support).. not much else on the
> mainline branch yet..

Do you suggest, that I should then try to use mainline kernel, instead of 
"beaglev-ahead-linux" (https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux)?

You seem to also be a maintainer for the "beaglev-ahead-linux" repository? Is 
the light_defconfig the proper one for the beaglev-ahead? What do you think 
about the issues I encountered regarding vector extension v0.7.1 and recent 
gcc apparently not supporting it? What do you think about maybe removing the 
CONFIG_VECTOR flags from the light_defconfig?

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beaglev-v5.10.113-1.1.2/arch/riscv/configs/light_defconfig#L21-22

And also as mentioned in my other mail, I encountered an enum-int-mismatch 
error when compiling with (buildroot generated) gcc v13.2 between a functions 
an its prototype, see here:

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

And one more question: I was able to generate some binaries, but so far I 
don't have a clue how to assemble them to a proper image and how I would flash 
that image to the BeagleV-Ahead's eMMC. Do you happen to have some hint(s) for 
me, e.g., some link, some documentation, anything?

Best regards,
Kilian



_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

On Thu, Aug 10, 2023 at 12:03 PM Kilian Zinnecker
<kilian.zinnecker@mail.de> wrote:
>
> Hello Robert,
>
> > > I am interested in adding board support for the BeagleV-Ahead.
> > >
> > > I already started trying to setup the board support, but at the moment it
> > > does not work yet, due to some gcc 12 and zicsr and zifencei RiscV
> > > extension issue (see below).
> >
> > Awesome work!
>
> Thanks!
>
> > BTW, i've created a special u-boot branch for mainline gcc situations,
> > with *-ubuntu extension on the branch..
> >
> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/beagle
> > v-v2020.01-1.1.2-ubuntu
>
> So should I try using that branch then?

Correct, for u-boot, use that branch, that'll get things to build with
gcc-13.x ;)

>
> > Using kernel.org's x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz
> >
> > I've been mostly working on mainline for the board with @Drew Fustini
> >
> > Otherwise on the mainline we've been using main branch of opensbi and
> > linu's 6.5.x-rc (only eMMC wip support).. not much else on the
> > mainline branch yet..
>
> Do you suggest, that I should then try to use mainline kernel, instead of
> "beaglev-ahead-linux" (https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux)?

Nope, the mainline isn't really ready, unless you like hardware bring
up, our microSD/eMMC is still in RFC and only one core works!

I just forked the linux branch:

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/commits/beaglev-v5.10.113-1.1.2-ubuntu

Please use this one for gcc-12/gcc-13/etc...  The "*-ubuntu" branch
name is to signify ubuntu/mainline toolchain and not the forked THEAD
vector one..  So let's patch it up to work with
x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

> You seem to also be a maintainer for the "beaglev-ahead-linux" repository? Is
> the light_defconfig the proper one for the beaglev-ahead? What do you think
> about the issues I encountered regarding vector extension v0.7.1 and recent
> gcc apparently not supporting it? What do you think about maybe removing the
> CONFIG_VECTOR flags from the light_defconfig?

Yeah for the -ubuntu branch, we need to just disable vector, the revos
guys have done this, i need to cherry pick it..

> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beaglev-v5.10.113-1.1.2/arch/riscv/configs/light_defconfig#L21-22

Our shipping defconfig is: beaglev_defconfig the light_defconfig is
the vendor example, they were targeting a basic yocto build..

> And also as mentioned in my other mail, I encountered an enum-int-mismatch
> error when compiling with (buildroot generated) gcc v13.2 between a functions
> an its prototype, see here:
>
> 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
>
> And one more question: I was able to generate some binaries, but so far I
> don't have a clue how to assemble them to a proper image and how I would flash
> that image to the BeagleV-Ahead's eMMC. Do you happen to have some hint(s) for
> me, e.g., some link, some documentation, anything?

Okay, this is where things get fun.. since we never got full docs on
the bootrom, we've been just using the Android fastboot tools, to be
fair the TH1520 actually implemented a lot of Android in the bootrom..

From buildroot, today we need 2 generic partitions, (we can do more
custom, but that requires end users tweak u-boot's partition layout,
since we u-boot/fastboot to copy the partitions)..

"boot", this is a 200 MB 'ext4' partition:

You 'need' two magical closed source bins:

https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/bins

light_aon_fpga.bin
light_c906_audio.bin

light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
management... If you don't have this, the board will boot, but things
like cpufreq don't work..
light_c906_audio.bin: Probably Audio, never really tested it too much...

Then fw_dynamic.bin from OpenSBI

Then Image from the linux kernel along with all *.dtb's

Special directory for all device-tree overlays *.dtbo's

./overlays/

Then "extlinux.conf" for distroboot..

Our default is:

```
label Linux eMMC
    kernel /Image
    append root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
console=ttyS0,115200 earlycon clk_ignore_unused net.ifnames=0
    fdtdir /
    #fdtoverlays /overlays/<file>.dtbo
```

In the end, boot partition will look like:

```
./ignore/.boot/
├── extlinux
│   └── extlinux.conf
├── fw_dynamic.bin
├── Image
├── light_aon_fpga.bin
├── light-beagle.dtb
├── light_c906_audio.bin
└── overlays
    ├── BBORG_LOAD-00A2.dtbo
    ├── BBORG_RELAY-00A2.dtbo
    ├── BONE-LED_P8_03.dtbo
    ├── BONE-LED_P9_11.dtbo
    └── BVA-MIKROBUS-0.dtbo
```

Now here's the tricky part, I assume Buildroot can build whatever this
is called from "mkfs.ext4"..

This is the first piece of hardware where I've just dumped everything
into a directory and created a partition "-F" file with a "-d", so
kinda cool..

```
dd if=/dev/zero of=./deploy/boot.ext4 bs=1 count=0 seek=190M
mkfs.ext4 -F ./deploy/boot.ext4 -d ./ignore/.boot
```

That createst the boot.ext4 we dump thru Android tools..

The RootFS is pretty generic, note the 3rd partitions offset: `/dev/mmcblk0p3`

Our default etc/fstab is:
/dev/mmcblk0p2  /boot/firmware/ auto  defaults  0  2
/dev/mmcblk0p3  /  auto  errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  mode=755,uid=root,gid=gpio,defaults  0  0'

Similar to generate rootfs.ext4:

```
dd if=/dev/zero of=./deploy/root.ext4 bs=1 count=0 seek=4000M
mkfs.ext4 -F ./deploy/root.ext4 -d ./ignore/.root
```

4000M was only set as we had large rootfs, tailor to what you need..

On first bootup, we just have systemd call:

```
/usr/sbin/resize2fs /dev/mmcblk0p3
```

The nice thing, android tools already extended the partition fully, we
just need to tell ext4 to use it all..

Our generic flashing script is:

```
#!/bin/bash

if ! id | grep -q root; then
echo "./fastboot_emmc.sh must be run as root:"
echo "sudo ./fastboot_emmc.sh"
exit
fi

fastboot flash ram ./u-boot-with-spl.bin
fastboot reboot
sleep 10
fastboot oem format
fastboot flash uboot ./u-boot-with-spl.bin
fastboot flash boot ./boot.ext4
fastboot flash root ./root.ext4
fastboot reboot
```

fastboot oem format = this will actually partition the eMMC based on
what we defined in u-boot..

u-boot-with-spl.bin is magically stored in partition1..

As you develop your patchset, since uboot, boot and root are sorta
independent partitions, you can flash only what you are working on and
testing.. for OpenSBI and U-boot, just update u-boot/boot... for
kernel, just boot/root..

Side-note-extra credit.. We are working on distro extlinux support to
just boot off microSD using the eMMC's parttion1/2 as a generic
'bootloader'..  We did have one user on our forum, get the "microSD"
boto to actually work... once...  Vendor refused to share how to do
that, i was amazed user got it to work, but since then it's not
booting..  I think we are just going to asume eMMC will be the generic
bootloader going forward..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

u-boot partition:

This is where I chopped up the multi partition eMMC into 2 generic
ones..  SO if you want to do all the A/B rootfs stuff, this how they
originally did it;

https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/commit/d594ec74845b38d84edd845b019c837258b64cb7

`fastboot oem format` is what runs this:

Factory A/B boot:

partitions=name=table,size=2031KB;name=boot,size=200MiB,type=boot;name=root,size=4000MiB,type=linux,uuid=${uuid_rootfsA};name=bootB,size=200MiB,type=boot;name=rootB,size=4000MiB,type=linux,uuid=${uuid_rootfsB};name=data,size=-,type=linux

Our simple 2 partition:

partitions=name=table,size=2031KB;name=boot,size=200MiB,type=boot;name=root,size=-,type=linux,uuid=${uuid_rootfsA}

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

[--SNIP--]

> > > BTW, i've created a special u-boot branch for mainline gcc situations,
> > > with *-ubuntu extension on the branch..
> > > 
> > > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/be
> > > agle v-v2020.01-1.1.2-ubuntu
> > 
> > So should I try using that branch then?
> 
> Correct, for u-boot, use that branch, that'll get things to build with
> gcc-13.x ;)

I already tried and it did build - thanks!

[--SNIP--]

> Nope, the mainline isn't really ready, unless you like hardware bring
> up, our microSD/eMMC is still in RFC and only one core works!
> 
> I just forked the linux branch:
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/commits/beag
> lev-v5.10.113-1.1.2-ubuntu
> 
> Please use this one for gcc-12/gcc-13/etc...  The "*-ubuntu" branch
> name is to signify ubuntu/mainline toolchain and not the forked THEAD
> vector one..  So let's patch it up to work with
> x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

kk, I will also use the *ubuntu branch for the beaglev-ahead-linux kernel.

> > You seem to also be a maintainer for the "beaglev-ahead-linux" repository?
> > Is the light_defconfig the proper one for the beaglev-ahead? What do you
> > think about the issues I encountered regarding vector extension v0.7.1
> > and recent gcc apparently not supporting it? What do you think about
> > maybe removing the CONFIG_VECTOR flags from the light_defconfig?
> 
> Yeah for the -ubuntu branch, we need to just disable vector, the revos
> guys have done this, i need to cherry pick it..

Thanks! No hurries though, it currently works with the linux.fragment file I 
created.

> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beagl
> > ev-v5.10.113-1.1.2/arch/riscv/configs/light_defconfig#L21-22
> Our shipping defconfig is: beaglev_defconfig the light_defconfig is
> the vendor example, they were targeting a basic yocto build..

Thanks, I didn't know. To be honest I find it a bit confusing that it is called 
beaglev_defconfig, because afaik there exists a BeagleV board, without the "-
Ahead" suffix (https://old.beagleboard.org/static/beagleV/beagleV.html). So if I 
don't know any better, I would assume that a beaglev_defconfig would correspond 
to the BeagleV and not to the BeagleV-Ahead.

[--SNIP--]

> > And one more question: I was able to generate some binaries, but so far I
> > don't have a clue how to assemble them to a proper image and how I would
> > flash that image to the BeagleV-Ahead's eMMC. Do you happen to have some
> > hint(s) for me, e.g., some link, some documentation, anything?
> 
> Okay, this is where things get fun.. since we never got full docs on
> the bootrom, we've been just using the Android fastboot tools, to be
> fair the TH1520 actually implemented a lot of Android in the bootrom..
> 
> From buildroot, today we need 2 generic partitions, (we can do more
> custom, but that requires end users tweak u-boot's partition layout,
> since we u-boot/fastboot to copy the partitions)..
> 
> "boot", this is a 200 MB 'ext4' partition:
> 
> You 'need' two magical closed source bins:
> 
> https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/bins
> 
> light_aon_fpga.bin
> light_c906_audio.bin
> 
> light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
> management... If you don't have this, the board will boot, but things
> like cpufreq don't work..
> light_c906_audio.bin: Probably Audio, never really tested it too much...
> 
> Then fw_dynamic.bin from OpenSBI
> 
> Then Image from the linux kernel along with all *.dtb's
> 
> Special directory for all device-tree overlays *.dtbo's
> 
> ./overlays/
> 
> Then "extlinux.conf" for distroboot..
> 
> Our default is:
> 
> ```
> label Linux eMMC
>     kernel /Image
>     append root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
> console=ttyS0,115200 earlycon clk_ignore_unused net.ifnames=0
>     fdtdir /
>     #fdtoverlays /overlays/<file>.dtbo
> ```
> 
> In the end, boot partition will look like:
> 
> ```
> ./ignore/.boot/
> ├── extlinux
> │   └── extlinux.conf
> ├── fw_dynamic.bin
> ├── Image
> ├── light_aon_fpga.bin
> ├── light-beagle.dtb
> ├── light_c906_audio.bin
> └── overlays
>     ├── BBORG_LOAD-00A2.dtbo
>     ├── BBORG_RELAY-00A2.dtbo
>     ├── BONE-LED_P8_03.dtbo
>     ├── BONE-LED_P9_11.dtbo
>     └── BVA-MIKROBUS-0.dtbo
> ```
> 
> Now here's the tricky part, I assume Buildroot can build whatever this
> is called from "mkfs.ext4"..
> 
> This is the first piece of hardware where I've just dumped everything
> into a directory and created a partition "-F" file with a "-d", so
> kinda cool..
> 
> ```
> dd if=/dev/zero of=./deploy/boot.ext4 bs=1 count=0 seek=190M
> mkfs.ext4 -F ./deploy/boot.ext4 -d ./ignore/.boot
> ```
> 
> That createst the boot.ext4 we dump thru Android tools..
> 
> The RootFS is pretty generic, note the 3rd partitions offset:
> `/dev/mmcblk0p3`
> 
> Our default etc/fstab is:
> /dev/mmcblk0p2  /boot/firmware/ auto  defaults  0  2
> /dev/mmcblk0p3  /  auto  errors=remount-ro  0  1
> debugfs  /sys/kernel/debug  debugfs  mode=755,uid=root,gid=gpio,defaults  0 
> 0'
> 
> Similar to generate rootfs.ext4:
> 
> ```
> dd if=/dev/zero of=./deploy/root.ext4 bs=1 count=0 seek=4000M
> mkfs.ext4 -F ./deploy/root.ext4 -d ./ignore/.root
> ```
> 
> 4000M was only set as we had large rootfs, tailor to what you need..
> 
> On first bootup, we just have systemd call:
> 
> ```
> /usr/sbin/resize2fs /dev/mmcblk0p3
> ```
> 
> The nice thing, android tools already extended the partition fully, we
> just need to tell ext4 to use it all..
> 
> Our generic flashing script is:
> 
> ```
> #!/bin/bash
> 
> if ! id | grep -q root; then
> echo "./fastboot_emmc.sh must be run as root:"
> echo "sudo ./fastboot_emmc.sh"
> exit
> fi
> 
> fastboot flash ram ./u-boot-with-spl.bin
> fastboot reboot
> sleep 10
> fastboot oem format
> fastboot flash uboot ./u-boot-with-spl.bin
> fastboot flash boot ./boot.ext4
> fastboot flash root ./root.ext4
> fastboot reboot
> ```
> 
> fastboot oem format = this will actually partition the eMMC based on
> what we defined in u-boot..
> 
> u-boot-with-spl.bin is magically stored in partition1..
> 
> As you develop your patchset, since uboot, boot and root are sorta
> independent partitions, you can flash only what you are working on and
> testing.. for OpenSBI and U-boot, just update u-boot/boot... for
> kernel, just boot/root..

Thanks a lot for all the info! I must admit I am very unexperienced with much 
of this, so I will try, and thereby maybe do something wrong and then maybe 
ask some more questions about it. 

> Side-note-extra credit.. We are working on distro extlinux support to
> just boot off microSD using the eMMC's parttion1/2 as a generic
> 'bootloader'..  We did have one user on our forum, get the "microSD"
> boto to actually work... once...  Vendor refused to share how to do
> that, i was amazed user got it to work, but since then it's not
> booting..  I think we are just going to asume eMMC will be the generic
> bootloader going forward..

Yeah, that "Kilian" on the BeagleBoard forum is actually me :D
I am super sorry: I cannot reproduce what I did myself and I also don't know 
so much what is going on. The boot log I posted is really true. I still have 
that exact SD card and today it still booted. I however could not reproduce it 
with another SD card, which is of the same type. Tbh. I have no clue ...

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

> > Side-note-extra credit.. We are working on distro extlinux support to
> > just boot off microSD using the eMMC's parttion1/2 as a generic
> > 'bootloader'..  We did have one user on our forum, get the "microSD"
> > boto to actually work... once...  Vendor refused to share how to do
> > that, i was amazed user got it to work, but since then it's not
> > booting..  I think we are just going to asume eMMC will be the generic
> > bootloader going forward..
>
> Yeah, that "Kilian" on the BeagleBoard forum is actually me :D
> I am super sorry: I cannot reproduce what I did myself and I also don't know
> so much what is going on. The boot log I posted is really true. I still have
> that exact SD card and today it still booted. I however could not reproduce it
> with another SD card, which is of the same type. Tbh. I have no clue ...

Oh Sweet!

Yeah, your one boot 'showing' it actually worked 'once' is still way
more info than we ever got from the vendor on requesting info on our
goal of booting from external microSD!

I was at the office for my job that day, and didn't have the board in
my grab bag.

Regards.

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

[--SNIP--]
> Yeah, your one boot 'showing' it actually worked 'once' is still way
> more info than we ever got from the vendor on requesting info on our
> goal of booting from external microSD!
> 
> I was at the office for my job that day, and didn't have the board in
> my grab bag.

Maybe I did flash something else and documented it wrong? I don't know. I will 
try to help figuring out about this on the beagleboard forum.

Best regards,
Kilian




_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

[--SNIP--]

> You 'need' two magical closed source bins:
> 
> https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/bins
> 
> light_aon_fpga.bin
> light_c906_audio.bin
> 
> light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
> management... If you don't have this, the board will boot, but things
> like cpufreq don't work..
> light_c906_audio.bin: Probably Audio, never really tested it too much...

If we need these binary blobs, I think we also need the licensing information 
about the blobs. We had a similar case with blobs from Rockchip for the Radxa 
Rock 5B. Can you tell what the license for those blobs is? Do they originate 
from another repository?

[--SNIP--]

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Robert Nelson]

On Thu, Aug 10, 2023 at 3:38 PM Kilian Zinnecker
<kilian.zinnecker@mail.de> wrote:
>
> Hello Robert,
>
> [--SNIP--]
>
> > You 'need' two magical closed source bins:
> >
> > https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/bins
> >
> > light_aon_fpga.bin
> > light_c906_audio.bin
> >
> > light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
> > management... If you don't have this, the board will boot, but things
> > like cpufreq don't work..
> > light_c906_audio.bin: Probably Audio, never really tested it too much...
>
> If we need these binary blobs, I think we also need the licensing information
> about the blobs. We had a similar case with blobs from Rockchip for the Radxa
> Rock 5B. Can you tell what the license for those blobs is? Do they originate
> from another repository?

They are pure 'blobs', sadly they are just listed here:

https://github.com/beagleboard/xuantie-yocto/tree/Linux_SDK_V1.1.2-light-beagle/meta-light/recipes-bsp/opensbi/opensbi

no license or any other info..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Kilian Zinnecker via buildroot]

Hello Robert,

> > > You 'need' two magical closed source bins:
> > > 
> > > https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/b
> > > ins
> > > 
> > > light_aon_fpga.bin
> > > light_c906_audio.bin
> > > 
> > > light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
> > > management... If you don't have this, the board will boot, but things
> > > like cpufreq don't work..
> > > light_c906_audio.bin: Probably Audio, never really tested it too much...
> > 
> > If we need these binary blobs, I think we also need the licensing
> > information about the blobs. We had a similar case with blobs from
> > Rockchip for the Radxa Rock 5B. Can you tell what the license for those
> > blobs is? Do they originate from another repository?
> 
> They are pure 'blobs', sadly they are just listed here:
> 
> https://github.com/beagleboard/xuantie-yocto/tree/Linux_SDK_V1.1.2-light-bea
> gle/meta-light/recipes-bsp/opensbi/opensbi
> 
> no license or any other info..

The commit, which adds the binaries seems to contain the email addresses to 
some developers from alibaba (from some added patches) and one alibaba service 
email. Would you mind if I kindly ask them about the licensing status of the 
binaries, i.e., whether they can provide a LICENSE file?

Best regards,
Kilian



_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot