[PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

Pavel Pisa ppisa4lists at pikron.com
Thu Sep 22 08:16:27 UTC 2016


Hello Gedare,

On Thursday 22 of September 2016 03:26:32 Gedare Bloom wrote:
> I only added a couple of very minor inline comments. Looks good, I
> think you can push directly no one else needs to re-read this
> BSP-specific stuff.

thanks much for reading that huge pieces.

I have corrected some typos and renamed tms570_test_parity*
files to tms570_selftest_parity* to match function names
you proposed.

I have pushed agreed upon patches.
The result builds without single warning form me.
I need testing on HW. But generally there has been
no real code change after last tests. Only style, comments
etc.

MPU patch is left out, it needs to transform from generated
code (bunch of hexa values) to some readable and verifiable
form.

I have not pushed update of SDRAM init as well.

>  c/src/lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c
> @@ -1,5 +1,6 @@
>  #include <stdint.h>
>  #include <bsp/tms570.h>
> +#include <rtems/score/cpu.h>
>  #include "tms570_hwinit.h"
>
>  void tms570_emif_sdram_init( void )
> @@ -45,12 +46,21 @@ void tms570_emif_sdram_init( void )
>    /* Page Size. This field defines the internal page size of connected
> SDRAM devices. */ sdcr = TMS570_EMIF_SDCR_PAGESIZE_SET( sdcr, 0 ); /*
> elements_256 */
>
> +  _ARM_Data_synchronization_barrier();
> +  _ARM_Instruction_synchronization_barrier();
> +
> @gedare
> gedare 7 hours ago
>
> I think it usually worthwhile to comment why barrier/fence are necessary.

The EMIF/SDRAM address range can be/is on another bus than peripheral
which registers control EMIF timing and setup. So my idea has been that
test/setup propagation read from SDRAM space can reach interface before
it is configured. The barriers should prevent that.

But the code/HW has some glitches even with barriers included.
The sequence is (should be) exactly same as HalCoGen generated code
but it is compiled with Ti tools and they optimize much less
in used basic setup than GCC. But I expect that problem is somewhere
else anyway. May it be initialization too early after power on,
some clock domain or power enable not controlled right way.

Genrally, the SDRAM configuration fails for the first start after
POR, the configuration is correct after second and more system resets.
I can put there code to retry it. But it needs more debugging
and I would like to find real cause.

Best wishes,

               Pavel


More information about the devel mailing list