Date
1 - 6 of 6
How to handle a board with a dozen SoC's?
Jon Medhurst (Tixy) <tixy@...>
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
|
|
Jon Medhurst (Tixy) <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 anI 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
|
|
Nashif, Anas
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.
toggle quoted messageShow quoted text
Anas
On 2 Sep 2016, at 11:23, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:
|
|
Jon Medhurst (Tixy) <tixy@...>
On Fri, 2016-09-02 at 15:29 +0000, Nashif, Anas wrote:
Ok, there is a JIRA about board/soc structure documentation alreadyThanks, 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
|
|
Boie, Andrew P
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 anI realised this and $subject may be a bit ambiguous, I meant that the FPGA can 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
|
|
Jon Medhurst (Tixy) <tixy@...>
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)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,Not sure it did, but thanks for reply. :-) -- Tixy
|
|