New SoC upstreaming

[MDr164]

Hi Andrea,
I'm currently working on a couple new ports (2 active and almost done just need to add some more peripherals, 3 more lined up afterwards) that I would like to upstream here as well. I currently got a couple question around the logistics there:

1. Is there already a preferred way how to structure a HAL for different peripheral interfaces like SPI, I2C, etc shared between ports?
2. I got a platform that uses some SiFive IPs in silicon but is not a SiFive based system, is it fine for platforms like these to just import from other ports or should items like that maybe made common somehow?
3. One of the platforms has a pretty extensive 32GBit l2 switch peripheral, I could upstream that one here as well but that part is specific and therefore no really reusable, I assume it should be used just within the SoC. Any opinion on 'internal' packages for stuff like that or should I just place it directly into the soc folder to match other platforms structure?

I can also open up draft PRs for each SoC under which we could discuss in more detail but I assume things like where to place common driver interfaces would affect both anyways (I'm currently duplicating a bit of code there)

[abarisani]

Hi, have these ports been tested on actual hardware or emulated.

Can you list the platforms so that I can ponder where to begin with this?

Thanks

[MDr164]

Currently I'm porting the Fisilink FSL91030 which I got hardware in form of the MilkV Vega here and also a Qemu variant which emulates the Nuclei UX600 core used in this SoC. The other active SoC I'm working on is the Nuvoton NUC980 which I currently only tried via Hardware as I don't think that there is a Qemu port for it.

Once I got those working with all its peripherals I'm moving on the Aspeed SoCs from AST2500 to AST2700.

I can push my preliminary work to my fork next week.

[abarisani]

A Google search for Fisilink FSL91030 leads to zero results, please provide links to this part.

The NUC980 is an ARM9 and this instruction set is not supported by the TamaGo compiler, so I am not sure how you are making it work.

If you publish a PR please ensure that the code and documentation is consistent with the rest of the project, I will be happy to review and I suggest you start with a single PR, the simplest one, to get things goin.

[MDr164]

The Fisilink FSL91030 is a single core RISCV64 (IMACFDPBKVZfh/Zc), the core used is a Nuclei UX600 (https://www.nucleisys.com/product/600.php) and its datasheet is available on GitHub from MilkV which used it on one of their boards but only in Chinese (https://github.com/milkv-vega/vega-files/tree/main/development-documentation).

The NUC980 uses ARM9 but more specifically ARM926EJ-S which is ARMv5TEJ (some other ARM9 socs are v4) and ARMv5 is still the lowest ARM version supported by Go, so given upstream Go supports it I would be surprised TamaGo didn't. I got JTAG on both boards to debug and for the RV64 one I already get to the runtime, on the NUC980 I'm still digging a bit through the assembly so maybe there was an oversight regarding that particular ARM variant on my side.

I"ll start with the RV64 chip then, this one is working better on my side already. 👍

[MDr164]

I added #67 and #66 for each of my two platforms that I'm currently working on. Feel free to start with either one regarding initial input or questions.

[abarisani]

I added #67 and #66 for each of my two platforms that I'm currently working on. Feel free to start with either one regarding initial input or questions.

I will sort them out, kindly hold on additional PRs until we settle these. Thanks!

[MDr164]

I got no more lined up, just these two development branches. So don't worry, I'm not flooding you with code 😅