TMS570 BSP testing and problem with VFP enabled build
Pavel Pisa
pisa at cmp.felk.cvut.cz
Thu Nov 26 12:31:26 UTC 2015
Hello Martin,
On Tuesday 24 of November 2015 15:35:47 Martin Galvan wrote:
> I tested this both with and without the VFP, and in both cases I can't
> even make it to bsp_start. Even worse, Uniflash will almost fail to
> load the binaries to the board, which makes it quite cumbersome to
> perform the tests. While I may've done something wrong, the errors
> Uniflash is reporting are the exact same as the ones we used to have
> when POM was enabled by default. So there's that.
>
> For now we'll keep working with 4.11 prior to your changes. I suspect
> your issue is different than the one I'm seeing though; you may want
> to check if your loader doesn't do anything with the FP registers
> before you get to bsp_start_init_registers_vfp.
thanks for testing and I am sorry if shame is on our side.
But, please, help to find cause. Using shadow branch is
not good idea. There are many (most unrelated to TMS570)
corrections even in 4.11 branch and new problems would appear
and be solved. Backporting to shadow branch is waste
of time.
Please, what is the last version which you know to run with your
HaCoGen your patchstack?
I have done analysis of changes in TMS570 BSP which has been applied
past application of your change "TMS570: Add board reset code to bsp_reset"
in March 2015. There is link to complete (full size) set of
changes in TMS570 BSP
http://cmp.felk.cvut.cz/~pisa/tms570/tms570-150326-151125.diff.gz
The most of changes are related to header files and should not
have any influence to actual execution code path.
I am attaching filtered differences which are related to actual
execution.
The most code intrusive overall RTEMS change
bsps: Convert clock drivers to use a timecounter
by Alexander Krutwig done in April
+++ b/c/src/lib/libbsp/arm/tms570/clock/clock.c
....
It is for sure step in right direction, previous code attempt
to increase time measurement resolution by retrieving and adding
time from last tick has been nonsense which has been tried
in Linux and other operating systems and cannot be done
really well and all reasonable systems do not use it anymore.
There are some more fixes in clock.c to correct mistakes
in conversion by Premek and then there is update to reflect
new headers. But that all should be fully tested by our setup.
+++ b/c/src/lib/libbsp/arm/tms570/console/printk-support.c
only headers adaptation
+++ b/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
headers update
close deadlock loop correction
@@ -520,15 +525,19 @@ static void tms570_sci_interrupt_last_close(
{
tms570_sci_context *ctx = (tms570_sci_context *) base;
rtems_interrupt_lock_context lock_context;
+ rtems_interval tw;
+ int32_t baudrate;
/* Turn off RX interrupts */
rtems_termios_device_lock_acquire(base, &lock_context);
tms570_sci_disable_interrupts(ctx);
rtems_termios_device_lock_release(base, &lock_context);
- /* Flush device */
- while ( ( ctx->regs->SCIFLR & (1<<11) ) > 0 ) {
- ;/* Wait until all data has been sent */
+ tw = rtems_clock_get_ticks_per_second();
+ baudrate = rtems_termios_baud_to_number(cfgetospeed(&tty->termios));
+ tw = tw * 10 / baudrate + 1;
+ while ( ( ctx->regs->FLR & TMS570_SCI_FLR_TX_EMPTY ) == 0 ) {
+ rtems_task_wake_after(tw);
}
/* uninstall ISR */
+++ b/c/src/lib/libbsp/arm/tms570/irq/irq.c
added and documented interrupt bypass option
permanently disabled - so no influence to the code
sctlr &= ~(1 << 24);
+ #if 0
.....
+ sctlr |= 1 << 24;
+ #endif
asm volatile ("mcr p15, 0, %0, c1, c0, 0\n": : "r" (sctlr));
You can try to enable it then branch instruction ons satrt of
is not used for interrupt processing. VIM is configured
to pass execution to right whole system RTEMS exeption
handler _ARMV4_Exception_interrupt then. It has issues with
ETHERNET interrupts not seen in IRQINDEX. But else it is stable
and using VIM bypass is suggested by Ti support but with
direct pointing to individual handlers. There would be no
issue for ETHERNET in such case, but RTEMS schedule would not
be called right.
+++ b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
headers update - not called during initialization
So we are getting to real code changes in 4.11 TMS570 BSP
> +++ b/c/src/lib/libbsp/arm/tms570/startup/bspstart.c
> @@ -27,13 +27,49 @@
> #include <bsp/irq-generic.h>
> #include <bsp/start.h>
> #include <bsp/bootcard.h>
> +#include <bsp/linker-symbols.h>
> +#include <rtems/endian.h>
>
> void bsp_start( void )
> {
> - /* set the cpu mode to supervisor and big endian */
> - arm_cpu_mode = 0x213;
> + #if BYTE_ORDER == BIG_ENDIAN
> + /*
> + * If CPU is big endian (TMS570 family variant)
> + * set the CPU mode to supervisor and big endian.
> + * Do not set mode if CPU is little endian
> + * (RM48 family variant) for which default mode 0x13
> + * defined in cpukit/score/cpu/arm/cpu.c
> + * is right.
> + */
> + arm_cpu_mode = 0x213;
check that your tools do endian selection right, put there some error
and check it during compilation that condition is true
> + #endif
>
> - tms570_pom_remap();
> + tms570_initialize_and_clear();
The code has been there with unconditional POM map which
has is not required in your case. Previous code has been
known to not work reliably. Code changed to initialization
and cleanup only.
But delete this line to be sure that it is not problem cause
> + /*
> + * If RTEMS image does not start at address 0x00000000
> + * then first level exception table at memory begin has
> + * to be replaced to point to RTEMS handlers addresses.
> + *
> + * There is no VBAR or other option because Cortex-R
> + * does provides only fixed address 0x00000000 for exceptions
> + * (0xFFFF0000-0xFFFF001C alternative SCTLR.V = 1 cannot
> + * be used because target area corersponds to PMM peripheral
> + * registers on TMS570).
> + *
> + * Alternative is to use jumps over SRAM based trampolines
> + * but that is not compatible with
> + * Check TCRAM1 ECC error detection logic
> + * which intentionally introduces data abort during startup
> + * to check SRAM and if exception processing goes through
> + * SRAM then it leads to CPU error halt.
> + *
> + * So use of POM to replace jumps to vectors target
> + * addresses seems to be the best option.
> + */
> + if ( (uintptr_t)bsp_start_vector_table_begin != 0 ) {
> + tms570_pom_remap();
> + }
if condition is right then function should not be called for your
case. Delete lines to be sure that this is not cause of problems.
> /* Interrupts */
> bsp_interrupt_initialize();
There are more changes in POM support code but if above functions
are not called then it would not be even linked in.
What is left is move of VFP enable from your Flash only case to
filer for all varinats
b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137.inc
CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian -mfpu=vfpv3-d16 -mfloat-abi=hard
So this cause should be checked by changing back to
CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian
And last thing is our reserve of 256 bytes on start of internal SRAM.
It can be reverted
diff --git a/c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
b/c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
index 5ecd4ed..a32562f 100644
--- a/c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
+++ b/c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
@@ -1,7 +1,8 @@
MEMORY {
ROM_INT (RX) : ORIGIN = 0x00000000, LENGTH = 3M
- RAM_INT (AIW) : ORIGIN = 0x08000000, LENGTH = 256k
+ RAM_INT_VEC : ORIGIN = 0x08000000, LENGTH = 256
+ RAM_INT (AIWX) : ORIGIN = 0x08000100, LENGTH = 256k - 256
RAM_EXT (AIWX) : ORIGIN = 0x80000000, LENGTH = 8M
}
@@ -26,4 +27,6 @@ REGION_ALIAS ("REGION_NOCACHE_LOAD", RAM_INT);
bsp_stack_main_size = DEFINED (bsp_stack_main_size) ? bsp_stack_main_size : 1024;
bsp_stack_main_size = ALIGN (bsp_stack_main_size, bsp_stack_align);
+bsp_int_vec_overlay_start = ORIGIN(RAM_INT_VEC);
+
INCLUDE linkcmds.armv4
If undo/disable of above changes does not help then the problem
is most probably some change unrelated to the BSP
and it very desirable to catch it early because it would take
more time to find it later.
I have started work on preparation of HalCoGen RTEMS mix to test
application starting from address 0 ourselves. I am not happy
that I have to sacrifice my time for this because setup
without loader is not too much interresting to us and I do not
consider this mix to be allowed into RTEMS mainline. But if I
find time we provide that setup in public branch on GitHub.
Best wishes,
Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tms570-150326-151125-important.diff
Type: text/x-diff
Size: 22514 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151126/10595a27/attachment-0001.bin>
More information about the devel
mailing list