[Buildroot] Setting Defaults for RISCV64 Architecture

[Buildroot] Setting Defaults for RISCV64 Architecture

[Mark Corbin]

Hello

I am working on adding RISCV64 support to Buildroot and was wondering
how best to set some of the defaults when the riscv64 architecture is
selected.

The two issues that I currently have are that the version of binutils
needs to be 2.30 (or greater) and that the kernel needs to be a custom
version from the riscv git repo (the 4.17 mainline kernel doesn't appear
to have full riscv support).

In both of these cases I could either:

a) Add some architecture specific options to the 'Config.in' files, i.e.
packages/binutils/Config.in.host and linux/Config.in, to select the
appropriate default versions/values .
or
b)? Set the appropriate variables in a board or architecture specific
'_defconfig' file, e.g.
??? ??? BR2_BINUTILS_VERSION_2_30_X=y
??? ??? BR2_LINUX_KERNEL=y
??? ??? BR2_LINUX_KERNEL_CUSTOM_GIT=y
??? ???
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/riscv/riscv-linux.git"
??? ??? BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="riscv-linux-4.15"

I think that I prefer option a) as option b) would require a specific
config to be selected every time rather than just working by default
when you set the Target Architecture.

Any thoughts or comments regarding the most appropriate approach would
be much appreciated.

Many thanks

Mark

-- 
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3139 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180814/c3d35b4b/attachment.key>

[Buildroot] Setting Defaults for RISCV64 Architecture

[Thomas Petazzoni]

Hello Mark,

On Tue, 14 Aug 2018 10:39:01 +0100, Mark Corbin wrote:

> I am working on adding RISCV64 support to Buildroot

Nice!

> and was wondering how best to set some of the defaults when the
> riscv64 architecture is selected.
> 
> The two issues that I currently have are that the version of binutils
> needs to be 2.30 (or greater) and that the kernel needs to be a custom
> version from the riscv git repo (the 4.17 mainline kernel doesn't
> appear to have full riscv support).
> 
> In both of these cases I could either:
> 
> a) Add some architecture specific options to the 'Config.in' files,
> i.e. packages/binutils/Config.in.host and linux/Config.in, to select
> the appropriate default versions/values .
> or
> b)? Set the appropriate variables in a board or architecture specific
> '_defconfig' file, e.g.
> ??? ??? BR2_BINUTILS_VERSION_2_30_X=y
> ??? ??? BR2_LINUX_KERNEL=y
> ??? ??? BR2_LINUX_KERNEL_CUSTOM_GIT=y
> ??? ???
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/riscv/riscv-linux.git"
> ??? ??? BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="riscv-linux-4.15"
> 
> I think that I prefer option a) as option b) would require a specific
> config to be selected every time rather than just working by default
> when you set the Target Architecture.

Yes, in general (a) is preferred, as a defconfig is just an "example"
configuration, and nothing prevents a user from not using some existing
example configuration: he can instead start from scratch his
Buildroot configuration, and we should ensure that only valid
configurations can be created by the user.

For binutils, things are pretty easy, since
package/binutils/Config.in.host already hides/show some binutils
versions depending on the architecture. For example,
BR2_BINUTILS_VERSION_2_28_X is not visible on the ARC architecture.

For the Linux kernel itself, there isn't really a problem, as we allow
the user to select the Linux kernel version/source with lots of freedom
(arbitrary official version from kernel.org, arbitrary commit/tag from
a Git repository, arbitrary tarball, etc.).

However, there is a problem for the kernel headers. If the recently
released 4.18 kernel still doesn't have what's need for RISCV64, then I
guess we'll have to temporarily add a special Linux kernel headers
version in package/linux-headers/Config.in.host for RISCV64.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Setting Defaults for RISCV64 Architecture

[Mark Corbin]

Hello Thomas

On 14/08/18 13:03, Thomas Petazzoni wrote:
> Hello Mark,
>
> On Tue, 14 Aug 2018 10:39:01 +0100, Mark Corbin wrote:
>
>> I am working on adding RISCV64 support to Buildroot
> Nice!
>
>> and was wondering how best to set some of the defaults when the
>> riscv64 architecture is selected.
>>
>> The two issues that I currently have are that the version of binutils
>> needs to be 2.30 (or greater) and that the kernel needs to be a custom
>> version from the riscv git repo (the 4.17 mainline kernel doesn't
>> appear to have full riscv support).
>>
>> In both of these cases I could either:
>>
>> a) Add some architecture specific options to the 'Config.in' files,
>> i.e. packages/binutils/Config.in.host and linux/Config.in, to select
>> the appropriate default versions/values .
>> or
>> b)? Set the appropriate variables in a board or architecture specific
>> '_defconfig' file, e.g.
>> ??? ??? BR2_BINUTILS_VERSION_2_30_X=y
>> ??? ??? BR2_LINUX_KERNEL=y
>> ??? ??? BR2_LINUX_KERNEL_CUSTOM_GIT=y
>> ??? ???
>> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/riscv/riscv-linux.git"
>> ??? ??? BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="riscv-linux-4.15"
>>
>> I think that I prefer option a) as option b) would require a specific
>> config to be selected every time rather than just working by default
>> when you set the Target Architecture.
> Yes, in general (a) is preferred, as a defconfig is just an "example"
> configuration, and nothing prevents a user from not using some existing
> example configuration: he can instead start from scratch his
> Buildroot configuration, and we should ensure that only valid
> configurations can be created by the user.
>
> For binutils, things are pretty easy, since
> package/binutils/Config.in.host already hides/show some binutils
> versions depending on the architecture. For example,
> BR2_BINUTILS_VERSION_2_28_X is not visible on the ARC architecture.
That's good - I will go ahead and update Config.in.host for binutils.
>
> For the Linux kernel itself, there isn't really a problem, as we allow
> the user to select the Linux kernel version/source with lots of freedom
> (arbitrary official version from kernel.org, arbitrary commit/tag from
> a Git repository, arbitrary tarball, etc.).
I know that the options are pretty flexible,? but is there a good way to
preselect the correct version for riscv64? At the moment the default is
'Latest version (4.17)' and the user would have to go and reconfigure
this by hand to point at the custom git repo.
>
> However, there is a problem for the kernel headers. If the recently
> released 4.18 kernel still doesn't have what's need for RISCV64, then I
> guess we'll have to temporarily add a special Linux kernel headers
> version in package/linux-headers/Config.in.host for RISCV64.
Is this for building the toolchain? I'll have to take a look and think
about adding a custom version.

Thanks

Mark
>
> Best regards,
>
> Thomas

-- 
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3139 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180814/e19c2323/attachment.key>

[Buildroot] Setting Defaults for RISCV64 Architecture

[Thomas Petazzoni]

Hello,

On Tue, 14 Aug 2018 13:35:37 +0100, Mark Corbin wrote:

> > For the Linux kernel itself, there isn't really a problem, as we allow
> > the user to select the Linux kernel version/source with lots of freedom
> > (arbitrary official version from kernel.org, arbitrary commit/tag from
> > a Git repository, arbitrary tarball, etc.).  
> I know that the options are pretty flexible,? but is there a good way to
> preselect the correct version for riscv64? At the moment the default is
> 'Latest version (4.17)' and the user would have to go and reconfigure
> this by hand to point at the custom git repo.

Nope, for the Linux kernel source code, I don't think we want to add
architecture-specific default versions. Just leave it to the user to
know which version to build. It's already something a user has to do on
other architectures as well: the vanilla v4.17 is not always the right
choice for a given HW platform.

> > However, there is a problem for the kernel headers. If the recently
> > released 4.18 kernel still doesn't have what's need for RISCV64, then I
> > guess we'll have to temporarily add a special Linux kernel headers
> > version in package/linux-headers/Config.in.host for RISCV64.  
> Is this for building the toolchain?

Yes, this is for building the toolchain.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com