How to use custom hal-config and efr32mg1.ld linker doc #388
Assignees
Comments
|
Hey @gabekassel , thanks for pointing this out! Sorry it's been a few days since you posted. I'm working on writing something up and will have a more formal response with detailed instructions. I should be able to get back to you by EOD tomorrow |
|
CC: @romacdon |
|
Hey @gabekassel ! Sorry for the delay. As part of #324, the decision was made to deprecate the old hal-config method for configuration. This allowed us to transition to leveraging the new Silicon Labs SLC tool for generating config files on-the-fly and gives us the ability to greatly expand board support in this repo. What this means for you is that you'll need to generate a set new config files and port your customizations to the new format. From a high-level:
./script/bootstrap
./script/build brd4161a
mkdir -p src/platform_libs
cp -R build/brd4161a/slc/soc/platform src/platform_libs/openthread-efr32-soc-eero
cp -R build/brd4161a/slc/rcp/platform src/platform_libs/openthread-efr32-rcp-eeroThe result should look something like this SiliconLabs#533. Note that this does break the ability for you to build targeting other boards. This is a known issue and something I'm trying to think of an elegant solution for Even though #324 was merged a few months ago, this is still a very new change to the build process so I'm sure there are many areas for improvement. If you have any suggestions at all or encounter any pain points, please feel free to open a PR or an issue! |
|
Thanks Mason. I'll give it a try when time permits. |
|
@lmnotran do you know what version of java SLC expects? |
|
Actually I think this an arm mac issue. Any help for: |
|
Hi @gabekassel, @lmnotran is out today but I believe you need Java 64-bit JVM version 11 or higher, available through Amazon Correto as documented in section 2 of https://www.silabs.com/documents/public/user-guides/ug520-software-project-generation-configuration-with-slc-cli.pdf. Mason and I will sync up tomorrow when he returns. |
|
@mhallam91 confirmed SLC isn't supported on ARM macs yet. So I'll go with a VM for now |
|
actually i think this is incompatible on ARM in general |
|
@gabekassel Did you try running Both @romacdon and @bertoldi-silabs have M1 Macs and I've confirmed that they both are able to use https://www.silabs.com/documents/login/software/slc_cli_mac.zip to build applications using |
|
@gabekassel are you still experiencing issues running SLC? |
|
@romacdon yes, I'm still having trouble running SLC. I believe this is mostly due to not having an x86 machine at the moment (I have an arm64 Ubuntu VM on m1 Mac, for example). I haven't had time this week to come back to it. Simplest solution is to crack open an older intel Mac or setup a cloud host for this. |
|
@gabekasselI I also have an M1 MAC but I'm able to run SLC without the use a VM so something must be different with my setup and yours. Have you tried @lmnotran's suggestion above and running ./script/bootstrap? |
|
Yes I did. Are you using ubuntu arm64 or a different VM guest OS? I can play with this again today if time permits. |
|
I'm not using a VM at all. I'm am running SLC from macOS. |
|
@romacdon my current sticking point |
|
@gabekassel have you tried using the specific Java version mentioned in documentation? You need Java 64-bit JVM version 11 or higher, available through Amazon Correto as documented in section 2 of https://www.silabs.com/documents/public/user-guides/ug520-software-project-generation-configuration-with-slc-cli.pdf. |
|
better! here's where i get to next: |
|
I guess that's due to |
|
after installing manually and setting in my path (also removed the other jvm i had) |
|
@romacdon on a different (also M1 mac) machine: |
|
@gabekassel - Regarding this message - "The 'slc-cli' command could not be found in your PATH.". That is really not an issue. The script first tries to use the slc command in your path and if it doesn't find it reports that message but then downloads it and uses the version it downloads. As for the "The JVM shared library "/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home/bin/../lib/server/libjvm.dylib" does not contain the JNI_CreateJavaVM symbol." - I'm not sure what that is and will need to investigate. |
|
@gabekassel - I think I know what the issue is. As @mhallam91 said SLC isn't supported on ARM macs yet. However, you should be able to load the x86-64 version of Java and run through Rosetta. Thats how its working for me. |
|
makes sense! that seems to have done the trick |
|
failed on an actual build issue now. need to see if this is a real failure or toolchain issue |
|
here's 4161a. @romacdon have you seen this? |
|
@gabekassel - I think the binary content pulled down in the GSDK may not be correct. Can you try |
|
Thanks @romacdon - git-lfs did pull quite a bit more content, but still failing similarly |
|
though now it claims git lfs isn't installed in that directory/repo? |
|
I do have git-lfs installed. It seemed to pull the large files but then subsequently think lfs isnt provided in that submodule. I believe that message is saying the directory doesn't have LFS, not my host. I can play around more. |
|
figured that out. have to run and it finally builds! woohoo now...back to the original goal. i'll track through Mason's suggestions when i have time |
|
Thats great news @gabekassel - sorry it was such a pain. I'll work with the team here to see what we can to do to make this better. |
|
@lmnotran i finally got back to this. is |
|
Almost all thread capable boards should be supported, including brd4151a. Could you paste your command and the command line output? |
... |
|
@gabekassel have you modified anything in your ot-efr32 repo? Can you do a "git status" and send along the result? The build does work for Mason and I but I do know you needed to make some customizations for your device. Also, could you pass along the build/brd4151a/build.ninja file. Thanks |
|
this is something happening after applying @lmnotran 's draft PR as a patch on top of main. i'll look at it more closely. it builds fine with a clean main before trying to fork my own board config |
|
@gabekassel I wasn't aware you were trying to use @lmnotran's PR. He created that as an example and it was based off brd4161a not brd4151a. I think if you follow the instructions in this post, #388 (comment), but use brd4151a you should be able to recreate what Mason's had done for brd4161a. |
|
Makes sense. I'll follow the instructions more closely. |
|
@lmnotran i finally got this working. next question...i need to port hal-config.h changes. do these go in the various files in after that, i have some small changes to diags commands and use an sl_mult_timer for one use case i need to port |
I think the directory is |
|
i think Mason named it |
|
@gabekassel I see now. In his instructions he says So essentially the directory named |
Yes, your |
|
Thanks. That was pretty simple. Next I need to figure out how to re-implement some diag commands we added, and make sure the application_properties struct is correctly added to create a GBL. |
|
@lmnotran can you confirm that HAL config changes, especially flipping pin assignment for something like CTS/RTS, only needs to happen in |
|
Hi @gabekassel, anything in the config directory should be customizable. Which specific gecko sdk files were you referring to? For CTS/RTS, you will need to modify |
|
Thanks. will look at pin_config.h as well. |
|
@romacdon where is |
|
@gabekassel you're right. It does not exist on the GitHub side of things. To answer your previous question about which files to modify when changing the pin configuration I went into Simplicity Studio and created a dummy project then tried modifying some pins to see what generated files got updated. I noticed that two files got updated, |
|
thanks @romacdon - my first attempt resulted in not being able to communicate with the NCP after i flashed it. we have CTS/RTS flipped which is usually the reason this happens. wondering if i need to edit any files in GSDK sources or it may be a totally different issue i can build for brd4151a and flash to wstk without my pin flip to test first, i suppose |
|
@gabekassel you should not have to modify anything in the GSDK (third_party/silabs/gecko_sdk). Anything that needs to be customized should be capable of being changed from the generated config directory. In the previous, hal-config build env you didn't change anything in the gsdk did you? |
|
@romacdon correct. i guess i'll switch back to WSTK to test my changes |
|
@romacdon @lmnotran it looks like things have already been restructured quite a bit for the uart+spi division. i did notice a please advise if the approach should be the same now. |
|
@gabekassel - I added Are there any pain points in particular that you're running into? |
|
It seems like path names and structuring in the main CMakefile and build script have changed, so I want to be sure I'm updating the right things. It didn't immediately feel like your PR example matched up any longer. This is obvious. Thanks Mason |
|
Further, here's what I've been trying to do and struggling with.
Still confused what I'm missing. I can go through an FAE if easier. |
|
I got this working, but not sure it's as you expected. In addition to changing this leads me to think the defines generated by slc outside of the gecko sdk folder are ignored. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed that recent changes have moved the hal-config and efr32mgx.ld out of this repo. I'm presuming these are linked from GSDK using the defaults in the SDK.
I have customizations to both files required for this to build/run for my platform. Before I fork the entire GSDK, is there a preferred way to pass these in?
cc: @lmnotran
Thanks
The text was updated successfully, but these errors were encountered: