Re: [PATCH v2] [rsb] Update Spike build

[Hesham Almatary]

Yeah fesvr is now part of Spike in-tree. I didn't like it had to be
built separately either [1].

Joel, AFAIR, dtc was always needed.

[1] https://github.com/riscv/riscv-isa-sim/issues/254

On Fri, 25 Oct 2019 at 14:59, Joel Sherrill  wrote:
>
> Thanks for updating this.
>
> When building on a very clean machine, dtc needs to be referenced and in the 
> PATH.
>
> hecking for dtc... no
> configure: error: device-tree-compiler not found
>
> Is this working for you when dtc is not installed before building spike?
>
> On Thu, Oct 24, 2019 at 4:39 PM Chris Johns  wrote:
>>
>> On 24/10/19 7:57 pm, Hesham Almatary wrote:
>> > Latest Spike integrated fesvr in its source directory, so there
>> > is no separate fesvr anymore.
>>
>> Nice. Building and installing fesvr was a little unusual.
>>
>> Chris
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] [rsb] Update Spike build

[Chris Johns]

On 27/10/19 9:37 pm, Hesham Almatary wrote:
> Yeah fesvr is now part of Spike in-tree. I didn't like it had to be
> built separately either [1].
> 
> Joel, AFAIR, dtc was always needed.

Please have the package build FDT if it is needed. Do no rely on it being
installed as some hosts do not have a package to install.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] [rsb] Update Spike build

[Hesham Almatary]

On Sun, 27 Oct 2019 at 20:54, Chris Johns  wrote:

> On 27/10/19 9:37 pm, Hesham Almatary wrote:
> > Yeah fesvr is now part of Spike in-tree. I didn't like it had to be
> > built separately either [1].
> >
> > Joel, AFAIR, dtc was always needed.
>
> Please have the package build FDT if it is needed. Do no rely on it being
> installed as some hosts do not have a package to install.

I think Joel has already added it
https://github.com/RTEMS/rtems-source-builder/blob/master/bare/config/devel/spike.bset#L7

>
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] [rsb] Update Spike build

[Chris Johns]

On 28/10/19 9:21 am, Hesham Almatary wrote:
> 
> 
> On Sun, 27 Oct 2019 at 20:54, Chris Johns  > wrote:
> 
> On 27/10/19 9:37 pm, Hesham Almatary wrote:
> > Yeah fesvr is now part of Spike in-tree. I didn't like it had to be
> > built separately either [1].
> >
> > Joel, AFAIR, dtc was always needed.
> 
> Please have the package build FDT if it is needed. Do no rely on it being
> installed as some hosts do not have a package to install.
> 
> I think Joel has already added it 
> https://github.com/RTEMS/rtems-source-builder/blob/master/bare/config/devel/spike.bset#L7
> 

Thanks.

The config file has some issues. I am fixing the %hash issues. Is the patch
still needed if the version used has the fix?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Attributes in build specification items

[Sebastian Huber]

On 25/10/2019 19:28, Gedare Bloom wrote:

On Fri, Oct 25, 2019 at 2:35 AM Sebastian Huber
 wrote:


Hello,

for the new build system the specification what to build is contained in
so called build specification items. The items are files in YAML format
and are maintained by Doorstop and a text editor. For example a build
specification item for an integer configuration option could look like:

active: true
build-type: integer-option
default: 1
default-by-variant:
- value: 3
variant: xilinx_zynq_zc702
- value: 7
variant: xilinx_zynq_zedboard
derived: false
header: ''
level: 1.5
links: []
name: BSP_ARM_A9MPCORE_PERIPHCLK
normative: true
ref: ''
reviewed: cKwFFKjf_aPPFZe7fKyxBqYcAqdvU2A0yQaBdhbONQ8=
text: |
ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz
type: build

How do we want to handle optional attributes (e.g. min)? Should we
mandate that they are always present in the item file, e.g.

min: null

or should it be able to omit them and use default values in the wscript,
e.g.

min = self.data.get("min", None)
if min not None:
 if value < min:
 error()

?


I would lean toward mandating that attributes used to configure should
be present in the item file. This way, the item file is archival with
respect to the build, and one doesn't need to know/read the wscript to
understand what was the configuration default value.


Ok, I was also in favour of this approach. I will remove all default 
values from the wscript.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel