Hi

I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.

[1] https://www.arm.com/products/tools/development-boards/versatile-express/cortex-m-prototyping-system.php

It seems to me that 'BOARD' is what the build system expects to use to
specify the thing to build, but adding a dozen new boards under /boards
(one for each 'SoC') doesn't seem the right way to go - and I would then
need somewhere to put the common code for the physical board.

I'm going to be in a similar situation for creating my dozen or so SoC's
but I believe that the build system may be a bit more flexible in that
situation, with SOC_FAMILY and SOC_SERIES.

As well as the hardware board there is a host of software simulations
[2] for similar but differing configurations as the hardware. I don't
believe that adds any extra complexity though, apart from the number of
ever expanding versions and them not being definitively identified by
name or number. Oh joy...

[2] https://developer.arm.com/docs/dui0837/latest/programming-reference-for-mps2-fvps/mps2-about

Thanks for any advice.

--
Tixy

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:

I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.

I realised this and $subject may be a bit ambiguous, I meant that the
FPGA can be programmed at any one time with a single CPU type chosen
from a range of a dozen or so. I'm not trying to support multiple CPU
and 'SoC' types in a single Zephyr image at the same time. I'm looking
at a separate image for each one.

--
Tixy

Ok, there is a JIRA about board/soc structure documentation already and it happens to be assigned to me, I will address this ASAP, this might help you with the issue below.

Anas

On Fri, 2016-09-02 at 15:29 +0000, Nashif, Anas wrote:

Ok, there is a JIRA about board/soc structure documentation already
and it happens to be assigned to me, I will address this ASAP

Thanks, that would be helpful. I've been using existing code as examples
and decoding Makefiles to see what's possible, but I'm aware that the
end result would probably not be a desirable or 'best' solution :-)

My situation is also the inverse of the normal common SoC being used on
multiple boards, as I have multiple SoC's custom made for a fixed board.

--
Tixy

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:

I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and
varying support IP, and I'm wondering how to organise this.

I realised this and $subject may be a bit ambiguous, I meant that the FPGA can
be programmed at any one time with a single CPU type chosen from a range of
a dozen or so. I'm not trying to support multiple CPU and 'SoC' types in a single
Zephyr image at the same time. I'm looking at a separate image for each one.

What I did for Nios II (which is a soft-CPU that runs on Altera FPGAs) is to define each different Nios II configuration as a different soc in the Zephyr build.

So for example I have the "nios2f-zephyr" soc which is the reference config. Then another one "nios2-qemu" for the QEMU emulator which has slightly different settings. Each one has a system.h header file with all the configuration details. In this case the system.h was generated by the Altera tools.

See arch/nios2/soc/ for what I mean.
This is assuming that the CPU types you want to support are of a family of the same basic architecture with different configuration options.

HTH,
Andrew

On Tue, 2016-09-06 at 16:03 +0000, Boie, Andrew P wrote:

What I did for Nios II (which is a soft-CPU that runs on Altera FPGAs)
is to define each different Nios II configuration as a different soc
in the Zephyr build.

So for example I have the "nios2f-zephyr" soc which is the reference
config. Then another one "nios2-qemu" for the QEMU emulator which has
slightly different settings. Each one has a system.h header file with
all the configuration details. In this case the system.h was generated
by the Altera tools.

See arch/nios2/soc/ for what I mean.
This is assuming that the CPU types you want to support are of a
family of the same basic architecture with different configuration
options.

Well, they are all ARM at least :-). Some v7 some v8 architecture, some
single core, some multi core, some with caches, memory and security
protection areas. Some with DMA.

From looking at the nios stuff, it seems there is a separate board and
soc for each combinations, so in my case 20 socs and 20 boards. :-(

Perhaps I'll end up with some custom makefiles and scripts to generate
all these from some kind of meta config. Though possibly it might be as
simple as one board, one SoC and multiple defconfigs (but zephyr top
level scripts seem to assume one board == one defconfig ??).

For now, I hacked up a couple of board directories and a soc directory
just so I can write and test device drivers, but I'm aware I'll need to
dealing with this properly at some point.

As a slight tangent, I'm also doing other things in 'non-standard'
Zephyr ways for things like drivers, because I can't bring myself to
cut'n'paste Kconfig and code segments to support multiple instances of
drivers (most boards have 5 UARTs and 5 SPI devices).

HTH,
Andrew

Not sure it did, but thanks for reply. :-)

--
Tixy