SDK Build outside of SDK tree using latest arm toolchain

Technical Discussion Standard SDK
1

I’ve been fighting with the standard SDK for a couple of weeks now, trying to build anything using something approaching a modern toolchain.

I’ve not managed to get very far, as the Makefile in the …/asdk folder in the SDK is quite complex, and it also includes the additionally-complex Makefile.include.gen file.

Ideally, what I’d like to do is to be able to:

  • Build with my own toolchain, being the latest gcc-arm-embedded-eabi from embeddedarm;
  • Build whatever sdk components are required for my own project (configured with “make manuconfig” or similar);
  • Build against a reasonably up to date FreeRTOS as contained in the sdk;
  • Build outside the sdk file tree, so I can have my own files under my own version control.
  • Not have to modify any of the SDK makefiles (ie, keep the sdk completely separate, and clean compared to upstream).

So, I’ve been playing with the Makefiles, and trying to adapt the head Makefile for this scenario, by copying over the head Makefile and making a subdirectory for asdk and copying the asdk Makefile & Makefile.include.gen files, editing those as necessary.

I got as far as being able to “make menuconfig” but building anything else just caused a whole stack of “file not found” errors"

My next strategy was to copy the entire asdk file tree except the included toolchain into a sub directory of my project. This meant I could edit any of the included Makefiles with appropriate paths etc, removing the included toolchain and using the up to date one. I also didn’t get very far with this - I failed eventually on an unfound ram.a file and it was also difficult to work out where to add my own files to the spaghetti of Makefiles.

So, I guess my question is two-fold:

  1. How do I build the SDK and my own project using a different C compiler instead of the one supplied in the SDK, outside the sdk itself. I want to be able to have my project as a separate repo, and ideally the sdk should be a submodule of my project.

Something like this:
.
├── ambd_sdk
│ ├── component
│ ├── doc
│ ├── project
│ │ └── realtek_amebaD_va0_example
├── myproject
│ ├── km0
│ │ └── src
│ └── km4
│ ├── config
│ ├── inc
│ └── src

The main Makefiles for the two cores should be in the head directory of each of the directories km0 and km4 in the above tree.

Is this just a dream? I really need to be making progress with my project instead of fighting the build system, but I just can’t stomach using a binary blob toolchain of unknown provenance that is several versions behind the latest. Also I want to keep the source for my project as cleanly separate from the SDK so I can keep it under my own company’s source control system.

2

Thanks for trying this SDK so hard and give us feedback.
the GitHub standard SDK is an opensource version of closed SDK internally. So, we had modified the toolchain. Which means the toolchain has to be used but switch back to original.
You are right the asdk is very complex and hard to do customize. It is possible to make this SDK a submodule of any project. If you are just wanting to have different project, there are 2 ways.

  • just directly change the ambd_sdk/project/realtek_amebaD_va0_example
  • modify the compile path to relocate the current project.

Personally, I would like to suggest you use Arduino SDK. It is more stable and opensource for many requests. It is kind of a Arduino layer of the freertos SDK.

3

Thanks Michael; I’ve done exactly that for the short term, to get my project started to meet an interim client deadline.

The code I’ve written is very generic FreeRTOS though, so I’ll hopefully be able to port to the proper SDK when I get time to revisit.

Ultimately, my goal will be to write my own Makefile and link the Ameba SDK, taking advantage of the premade linker scripts. I’ve done this before for an STM32 project so I have a rough understanding of the ARM build process.

The only thing that I’m a bit concerned about is the KM0/KM4 separation and communication between the two processors. The Arduino code doesn’t seem to use the KM0 at all though, so maybe that will be the option for me at least at the start.

Without using the AMDK build system I’ll have to rely on my own configuration, but I can take a hint from the menuconfig config file generation for which #defines to enable for my project.

4

KM0 is close source and for security usage. So, for opensource env we cannot modify it too much.
I suggest if you are not going any security functions just ignore the KM0.