Re: [Buildroot] [PATCH v3 2/2] configs/microchip_mpfs_icicle: add support for Microchip's Icicle Kit

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: <Jamie.Gibbons@microchip.com>
Cc: Ludovic.Desroches@microchip.com, Nicolas.Ferre@microchip.com,
	Conor.Dooley@microchip.com, buildroot@buildroot.org,
	Valentina.FernandezAlanis@microchip.com,
	giulio.benetti@benettiengineering.com
Subject: Re: [Buildroot] [PATCH v3 2/2] configs/microchip_mpfs_icicle: add support for Microchip's Icicle Kit
Date: Wed, 9 Aug 2023 17:02:30 +0200	[thread overview]
Message-ID: <20230809170230.59759159@windsurf> (raw)
In-Reply-To: <40906858eaa11edb306b0f56e425d7b13948e0b9.camel@microchip.com>

Hello Jamie,

On Wed, 9 Aug 2023 14:43:19 +0000
<Jamie.Gibbons@microchip.com> wrote:

> > Could you clarify what this "embedded in a Hart Software Services
> > payload" means? Does it mean that there is additional code running on
> > the target other than U-Boot, Linux and user-space? I don't see
> > OpenSBI
> > being compiled in this defconfig.
> > 
> > I'd like to make sure we have properly captured all the code that
> > ends
> > up running on the target, so that we are complete from a licensing
> > stand-point.
> >   
> The HSS (Hart Software Services) acts as a zero-stage bootloader on the
> Icicle kit.

Where is this HSS code located? Is it build by Buildroot, or it is part
of some kind of ROM code burned into the SoC?

> The HSS reads an HSS formatted payload from eMMC/SD that
> contains binary images (e.g. U-boot) to be booted via OpenSBI. The HSS
> includes OpenSBI so we don't need to enable OpenSBI in the buildroot
> defconfig.

Who is building the OpenSBI code?

Again, my concern is to make sure that we have properly captured the
licensing of all software components built by Buildroot and that we're
providing the relevant source code matching the software components
that are built by Buildroot.

Right now, it is clear that your defconfig is building U-Boot + Linux +
rootfs, but it isn't clear where the HSS code and OpenSBI code comes
from, and who builds it.

> > So you're not a riscv_g core because you don't have the atomic
> > extension?  
> We have selected riscv_custom because we have compressed instructions
> extension (RVC) which is not part of riscv_g.
> 
> While looking into that we noticed that we don't have
> BR2_RISCV_ISA_CUSTOM_RVA in our defconfig which we need to add, this
> was because BR2_RISCV_ISA_CUSTOM_RVA was selected in previous versions
> of buildroot using riscv_custom, and now it isn't.
> 
> I can send a patch to add BR2_RISCV_ISA_CUSTOM_RVA?

Yes.

I am wondering if we also don't need to move the following options:

config BR2_RISCV_ISA_CUSTOM_RVC
	bool "Compressed Instructions (C)"
	select BR2_RISCV_ISA_RVC

config BR2_RISCV_ISA_CUSTOM_RVV
	bool "Vector Instructions (V)"
	select BR2_RISCV_ISA_RVV
	select BR2_ARCH_NEEDS_GCC_AT_LEAST_12

to be available/visible even when BR2_riscv_g is selected.

Indeed to me riscv_g implies IMAFD, but you can have IMAFD + C or IMAFD
+ V, so it should be possible to say "I have a RISC-V G core, which
  also supports those extra C and/or V extensions".

Does that make sense in the RISC-V world?

Thanks!

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