-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Use SDK from git to build #516
Conversation
This avoids git being overly ambitious with git hygiene, as our target does not follow git etiquette using crlf line endings. This was re-introduced with the 20240710 build, so lets do it again. Contributes to Koenkk#511 again. Signed-off-by: Olliver Schinagl <[email protected]>
The maclib binary patches are quite 'heavy' for editors and github won't even show it. Split it into two patches, so it is easier to manage. Signed-off-by: Olliver Schinagl <[email protected]>
98aebdf
to
190e49c
Compare
Note that this MR includes changes from #507 and #515. One option issue is the 'other' traget, which needs some fighting of CCS/sysconfig. We currently are based of the 'launchpad board' (which really is just abusing things :p I bet none of the boards used are actual launchpad boards :p) which forces us into certain configurations. This can be changed, but needs some figuring out. |
8a49d3d
to
0d34518
Compare
This commit adds a Container which holds the CCS and SDK so they can be used to build the various firmwares. The pipeline can be later expanded to also actually build the firmware(s). Signed-off-by: Olliver Schinagl <[email protected]>
Lets keep a reference of the SimpleLink examples and SDK that our patches are based off. This keeps everything together and makes it possible to reference and find things. As a submodule, it's not cloned by default (requires --recursive) so none-developers aren't bothered by this. Signed-off-by: Olliver Schinagl <[email protected]>
There's a bunch of SDK bugfixes and improvements that have been added over time. This commit adds them on the SDK submodule. See the submodule for more details. Signed-off-by: Olliver Schinagl <[email protected]>
There's no point in setting the txPower to 20 in our config, when in fact the txPower is set to 9 via a hardcoded define in this very same patch. Instead, ensure that the generated files have the proper txPower defined so that the `ti_zstack_config.h` [0] can set it properly internally. [0]: source/ti/zstack/.meta/templates/ti_zstack_config.h.xdt:463 Signed-off-by: Olliver Schinagl <[email protected]>
Xiaomi devices do not support aging leaving nor coordinators that are not of the Xiaomi brand. Lets try to help here. Signed-off-by: Olliver Schinagl <[email protected]>
Instead of patching the workspace, move preinclude into the projectspec and SDK sources instead. This allows to get everything when importing a project, reducing the need to patch the workspace a bit. Note, that this commit breaks support for 'other' platform, by no longer offering the preinclude define hack. Also note that support is not broken, just that the GPIO's need to be correctly set in the IDE/znp.syscfg. This is intended and will be resolved in a next patch in this series. Signed-off-by: Olliver Schinagl <[email protected]>
Instead of blindly relying on whatever CCS/Sysconfig generates, lets commit it to the repository. This ensures that every build will be the same. This also means eclipse (GUI) is no longer needed if commands are executed shell. Changes will still require to be managed by a human in the end, but this should be done by one of the developers, instead of everybody for themselves. Ideally, these files would be generated at runtime using sysconfig instead, but at this time that was not possible/figured out yet. See [0] for more information. [0]: https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1397346/cc2652p-using-sysconfig-from-the-cli-to-generate-znp-sysfg Signed-off-by: Olliver Schinagl <[email protected]>
Since we are now tracking the config file in git, we no longer have to post-patch the workspace. This has multiple advantages. We no longer have to build all targets, patch all targets and can actually track changes in code. Signed-off-by: Olliver Schinagl <[email protected]>
Lets not have sysconfig randomly assign pins and peripherials. We want fixed assignments that we can track in git, and change where needed. Signed-off-by: Olliver Schinagl <[email protected]>
Some devices have the ability to run with hardware flow control, e.g. sonoff's dongle. Lets add a config option for it. Signed-off-by: Olliver Schinagl <[email protected]>
This brings back the 'other' board variant that is not a Launchpad device. The only differences are as was described in preinclude before: xoscCapArrayDelta = 0xFA and that RF Antenna switch pins are DIO_6 and DIO_5. Note, that by default, DIO_6 is assigned to the RED led in the original firmware, and toggeling the RED LED would also toggle the RF switch chip! This is here now rectified by removing the LED existance. Signed-off-by: Olliver Schinagl <[email protected]>
0d34518
to
683f3bb
Compare
I'm trying to build the SDK on Mac but it fails with the same error as on https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1263021/simplelink-cc13xx-cc26xx-sdk-github-sdk-build-errors, seems Mac is not well supported so that's a bummer. I guess we should first start with a container in which we can start CCS + webvnc server to access it. |
This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
Initially I had both in the same MR; but it become 'to big'. Doing the container first is certainly possible though |
This MR switches from a pre-downloaded SDK, to using the SDK from git. This also means we can store our changes in the git repo, instead of managing local patches. With the addition of #507 we can actually use docker to build the entire firmware headless, allowing for the next step, to build from the CI.
One thing I don't know, is how to do the build of the SDK libraries from within CCS. Headless it is trivially calling
make
. Surely there must be an easy clickable way, but that is needed to be added to the documentation.