Sorry that assumption was very native of me that i didn't have a working baseline. Joel said that the erc32 was similar to the leon bsp
" The ERC32 what's the first space hardened sparc processor. The leon3 is a later processor in the same family. Both use the same build of GCC and are just different bsps. In fact both run on the same sis simulator. " I also though that the bsps were the same and I can work on the issue with only the erc32 BSP. I have one more question: when i run the hello world test. All the test files are within one specific directory and I don't see the executables for specific bsps that's why i thought all tests would be built (there would not be any specific considerations for bsps) . Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, March 29, 2021 2:45 PM, Gedare Bloom <ged...@rtems.org> wrote: > On Sun, Mar 28, 2021 at 1:26 PM zack_on_the_speed_chanel > zack_on_the_speed_cha...@protonmail.ch wrote: > > > Hello all, > > I'm updating on what' i've found out with the issue (forgot to reply all) . > > Joel recommended me check the coverage for the leon BSP( to check if it's > > supported) and i found that the branch with CLOCK_MONOTONIC was not reached > > I think now that it's supported (because the annotated assembly is in the > > sparc instruction set). I also found out that the test would be similar to > > Psxclock02 and it runs the same tests on a different clock. Then I tried to > > build the psxclock02 test , change the create_clock to have the > > clock_monotonic argument and i didn't see the executable or any change in > > the ./waf build. Then I was suggested that you have to enable all tests > > some how? How do i enable all tests? > > Do you use something like: ./waf bsp_defaults ---rtems-bsp=leon3 > config.ini > > Then, take a look, BUILD_TESTS and BUILD_PSXTESTS are two options that > if either is True it should build psxclock02. > > When you write code, you should first make sure you can build the code > as it exists if it is supposed to work, and run it to see that it > works. Then you should make changes from a working baseline. Otherwise > when you get a problem, how do you know if the problem is your > problem, or it already existed? > > > Thanks > > Zack > > > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel