The folder structure there look correct.
Technically we call the platform after the type of chips it compiles for – Nexmon only handles Broadcom chips (or Cypress as they’re bought up now?) so a name like platform-broadcom or platform-cypress would be more standard.
I like the choice that you have a Raspberry Pi 3B as board, but still note that it’s the Broadcom WiFi SoC that you’re compiling a firmware for, not the Pi’s main SoC. But since indeed many BCM chips are associated (in different firmware versions) to different devices, like some smartphone or some Raspberry, it makes sense to create a raspberrypi_3b board definition rather than a BCMXYZ definition, you can also directly associate information like target firmware version needed for the build process in there.
But according to my info the Pi 3 Model B has a “BCM43143”, which isn’t supported by nexmon. The bcm43455c0 for the Pi 3B+ is supported though, as well as the bcm43430a1 for a Pi 3 (that’s what I read when I google it).
The data in nexmon/firmwares at master · seemoo-lab/nexmon · GitHub seems pretty constant for the target chips, so that data can be in a common framework-nexmon package. The builder script builder/frameworks/nexmon.py can then include the right files in the include path / build process.
In the nexmon.py builder script you then have to replicate the build process as the Makefiles in the original project does it. You can ofc. also call into the same shell scripts or whatever that the original build process does so that you don’t have to re-implement everything in python.
Beware of the custom toolchains, see nexmon/buildtools at master · seemoo-lab/nexmon · GitHub. This needs a custom gcc version that understands all thesese patch-attributes etc
You would need to create custom toolchain-gccarmnoneeabi packages with a package.json file and the pio package pack command.
Otherwise development is just a continuos loop of looking how other develpoment platforms do it and how your target framework / build system originally did it, and then replicating that in Python/SCons. I can only recommend looking at the other implementations like GitHub - platformio/platform-ststm32: ST STM32: development platform for PlatformIO (which fits because you’re also complining for a Cortex target, concretely the Cortex-R4 on those BCM chippies) and build scripts like e.g. https://github.com/stm32duino/Arduino_Core_STM32/blob/master/tools/platformio-build.py.
Creating a platform is not the easiest thing but doable, but if you’re trying to copy what nexmon does it might get a little bit difficult. You have to fully understand their build process and everything that happens in between – like microcode extraction, extracting flash patches, calling custom GCC toolchains, rebuilding the firmware image, calling a custom assembler on some files for the D11 core etc.