OpenRISC patch series...
Hello! I have a number of bug fixes for the OpenRISC/or1k implementation in RTEMS that I would like to contribute. This is taken from our internal development tree and is spread out over several commits. For what I contribute here, I have grouped the commits based on files which are interdependent and extracted it as a "normal" git diff. I hope this is good enough, but otherwise, please comment on the patches. Best regards, /Jakob Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/7] Patches for the OR1k CPU handling and definitions
diff --git a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h index 98bbe41..78f2468 100644 --- a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h +++ b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h @@ -4,8 +4,12 @@ * @brief OR1K utility */ /* + * COPYRIGHT (c) 2014-2015 ÅAC Microtec AB + * Karol Gugala + * Jakob Viketoft * COPYRIGHT (c) 2014 Hesham ALMatary * * The license and distribution terms for this file may be * found in the file LICENSE in this distribution or at * http://www.rtems.org/license/LICENSE. @@ -26,8 +30,8 @@ #define SPR_GRP7_PERF_CTR (7 << SPR_GRP_SHAMT) #define SPR_GRP8_PWR_MNG (8 << SPR_GRP_SHAMT) #define SPR_GRP9_PIC (9 << SPR_GRP_SHAMT) -#define SPR_GPR10_TICK_TMR (10 << SPR_GRP_SHAMT) -#define SPR_GPR11_FPU (11 << SPR_GRP_SHAMT) +#define SPR_GRP10_TICK_TMR (10 << SPR_GRP_SHAMT) +#define SPR_GRP11_FPU (11 << SPR_GRP_SHAMT) /* SPR registers definitions */ @@ -196,8 +200,8 @@ #define CPU_OR1K_SPR_PICSR (SPR_GRP9_PIC + 2) /* Group10: Tick Timer registers */ -#define CPU_OR1K_SPR_TTMR (SPR_GPR10_TICK_TMR + 0) -#define CPU_OR1K_SPR_TTCR (SPR_GPR10_TICK_TMR + 1) +#define CPU_OR1K_SPR_TTMR (SPR_GRP10_TICK_TMR + 0) +#define CPU_OR1K_SPR_TTCR (SPR_GRP10_TICK_TMR + 1) /* Shift amount macros for bits position in Supervision Register */ #define CPU_OR1K_SPR_SR_SHAMT_SM (0) @@ -258,6 +262,114 @@ /*Context ID (Fast Context Switching) */ #define CPU_OR1K_SPR_SR_CID (F << CPU_OR1K_SPR_SR_SHAMT_CID) +/* + * Bit definitions for the Version Register + * + */ +#define CPU_OR1K_SPR_VR_VER 0xff00 /* Processor version */ +#define CPU_OR1K_SPR_VR_CFG 0x00ff /* Processor configuration */ +#define CPU_OR1K_SPR_VR_RES 0xffc0 /* Reserved */ +#define CPU_OR1K_SPR_VR_REV 0x003f /* Processor revision */ + +#define CPU_OR1K_SPR_VR_VER_OFF 24 +#define CPU_OR1K_SPR_VR_CFG_OFF 16 +#define CPU_OR1K_SPR_VR_REV_OFF 0 + +/* + * Bit definitions for the Unit Present Register + * + */ +#define CPU_OR1K_SPR_UPR_UP0x0001 /* UPR present */ +#define CPU_OR1K_SPR_UPR_DCP 0x0002 /* Data cache present */ +#define CPU_OR1K_SPR_UPR_ICP 0x0004 /* Instruction cache present */ +#define CPU_OR1K_SPR_UPR_DMP 0x0008 /* Data MMU present */ +#define CPU_OR1K_SPR_UPR_IMP 0x0010 /* Instruction MMU present */ +#define CPU_OR1K_SPR_UPR_MP0x0020 /* MAC present */ +#define CPU_OR1K_SPR_UPR_DUP 0x0040 /* Debug unit present */ +#define CPU_OR1K_SPR_UPR_PCUP 0x0080 /* Performance counters unit present */ +#define CPU_OR1K_SPR_UPR_PMP 0x0100 /* Power management present */ +#define CPU_OR1K_SPR_UPR_PICP 0x0200 /* PIC present */ +#define CPU_OR1K_SPR_UPR_TTP 0x0400 /* Tick timer present */ +#define CPU_OR1K_SPR_UPR_RES 0x00fe /* Reserved */ +#define CPU_OR1K_SPR_UPR_CUP 0xff00 /* Context units present */ + +/* + * Bit definitions for the CPU configuration register + * + */ +#define CPU_OR1K_SPR_CPUCFGR_NSGF 0x000f /* Number of shadow GPR files */ +#define CPU_OR1K_SPR_CPUCFGR_CGF0x0010 /* Custom GPR file */ +#define CPU_OR1K_SPR_CPUCFGR_OB32S 0x0020 /* ORBIS32 supported */ +#define CPU_OR1K_SPR_CPUCFGR_OB64S 0x0040 /* ORBIS64 supported */ +#define CPU_OR1K_SPR_CPUCFGR_OF32S 0x0080 /* ORFPX32 supported */ +#define CPU_OR1K_SPR_CPUCFGR_OF64S 0x0100 /* ORFPX64 supported */ +#define CPU_OR1K_SPR_CPUCFGR_OV64S 0x0200 /* ORVDX64 supported */ +#define CPU_OR1K_SPR_CPUCFGR_RES0xfc00 /* Reserved */ + +/* + * Bit definitions for the Debug configuration register and other + * constants. + * + */ +#define CPU_OR1K_SPR_DCFGR_NDP 0x0007 /* Number of matchpoints mask */ +#define CPU_OR1K_SPR_DCFGR_NDP1 0x /* One matchpoint supported */ +#define CPU_OR1K_SPR_DCFGR_NDP2 0x0001 /* Two matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP3 0x0002 /* Three matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP4 0x0003 /* Four matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP5 0x0004 /* Five matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP6 0x0005 /* Six matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP7 0x0006 /* Seven matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_NDP8 0x0007 /* Eight matchpoints supported */ +#define CPU_OR1K_SPR_DCFGR_WPCI 0x0008 /* Watchpoint counters implemented */ + +/* + * Bit definitions for Data Cache Control register + * + */ +#define CPU_OR1K_SPR_DCCR_EW 0x00ff /* Enable ways */ + +/* + * Bit definitions for Insn Cache Control register + * + */ +#define CPU_OR1K_SPR_ICCR_EW 0x00ff /* Enable ways */ + +/* + * Bit definitions for Data Cache Configuration Register + * + */ + +#define
[PATCH 2/7] Exception handling and start code
diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S index d951a55..0afad8f 100644 --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S @@ -1,11 +1,16 @@ /* * Copyright (c) 2014-2015 Hesham ALMatary + * Copyright (c) 2014-2016 ÅAC Microtec AB + * Jakob Viketoft * - * The license and distribution terms for this file may be - * found in the file LICENSE in this distribution or at - * http://www.rtems.org/license/LICENSE + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE */ #include +#include + + .extern _ISR_Handler /* The following macro defines the first instructions every exception * should execute before jumping to its handler function from the @@ -16,35 +21,23 @@ */ #define EXCEPTION_SETUP(vector) \ l.nop ;\ - l.addi r1, r1, -200 ;\ - l.sw0(r1), r3; \ + /* Add space for redzone and make space on the current stack \ + * (from the interrupted thread) */ \ + l.addi r1, r1, -(REDZONE_SIZE + EX_FRAME_SIZE); \ + l.swOR1K_EC_GPR3(r1), r3; \ l.addi r3, r0, vector; \ l.j _ISR_Handler; \ l.nop - .extern bsp_start .extern boot_card - .extern bsp_section_bss_begin - .extern bsp_section_bss_end - - .extern bsp_start_vector_table_end - .extern bsp_start_vector_table_size - .extern bsp_vector_table_size - .extern bsp_section_stack_begin - .extern exception_frame_save - .extern _OR1K_Exception_Process .extern _OR1K_Exception_default - .extern rtems_clock_tick - .extern _exit - .extern printk - .extern bsp_interrupt_handler_default /* Global symbols */ .global _start .global bsp_start_vector_table_begin -/* Popualte HW vector table */ +/* Populate HW vector table */ .section .vector, "ax" @@ -62,7 +55,7 @@ _dPageFault: EXCEPTION_SETUP(3) .org 0x400 -_iPageFaule: +_iPageFault: EXCEPTION_SETUP(4) .org 0x500 @@ -106,18 +99,74 @@ _trap: EXCEPTION_SETUP(14) .org 0xF00 -_undef1: +_res_future1: EXCEPTION_SETUP(15) -.org 0x1500 -_undef2: +.org 0x1000 +_res_future2: EXCEPTION_SETUP(16) -.org 0x1900 -_undef3: +.org 0x1100 +_res_future3: EXCEPTION_SETUP(17) +.org 0x1200 +_res_future4: + EXCEPTION_SETUP(18) + +.org 0x1300 +_res_future5: + EXCEPTION_SETUP(19) + +.org 0x1400 +_res_future6: + EXCEPTION_SETUP(20) + +.org 0x1500 +_res_impspec1: + EXCEPTION_SETUP(21) + +.org 0x1600 +_res_impspec2: + EXCEPTION_SETUP(22) + +.org 0x1700 +_res_impspec3: + EXCEPTION_SETUP(23) + +.org 0x1800 +_res_impspec4: + EXCEPTION_SETUP(24) + +.org 0x1900 +_res_custom1: + EXCEPTION_SETUP(25) + +.org 0x1A00 +_res_custom2: + EXCEPTION_SETUP(26) + +.org 0x1B00 +_res_custom3: + EXCEPTION_SETUP(27) + +.org 0x1C00 +_res_custom4: + EXCEPTION_SETUP(28) + +.org 0x1D00 +_res_custom5: + EXCEPTION_SETUP(29) + +.org 0x1E00 +_res_custom6: + EXCEPTION_SETUP(30) + .org 0x1F00 +_res_custom7: + EXCEPTION_SETUP(31) + +.org 0x2000 bsp_start_vector_table_begin: @@ -128,7 +177,7 @@ bsp_start_vector_table_begin: .word _OR1K_Exception_default /* Instruction Page Fault */ .word _OR1K_Exception_default /* Tick timer */ .word _OR1K_Exception_default /* Alignment */ - .word _OR1K_Exception_default /* Undefiend Instruction */ + .word _OR1K_Exception_default /* Undefined Instruction */ .word _OR1K_Exception_default /* External Interrupt */ .word _OR1K_Exception_default /* Data TLB Miss */ .word _OR1K_Exception_default /* Instruction TLB Miss */ @@ -136,8 +185,22 @@ bsp_start_vector_table_begin: .word _OR1K_Exception_default /* System Call */ .word _OR1K_Exception_default /* Floating Point Exception */ .word _OR1K_Exception_default /* Trap */ - .word _OR1K_Exception_default /* Reserver for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for future use */ + .word _OR1K_Exception_default /* Reserved for implementation-specific */ .word _OR1K_Exception_default /* Reserved for implementation-specific */ + .word _OR1K_Exception_default /* Reserved for implementation-specific */ + .word _OR1K_Exception_default /* Reserved for implementation-specific */ + .word _OR1K_Exception_default /* Reserved for custom exceptions. */ + .word _OR1K_Exception_default /* Reserved for custom exceptions. */ + .word _OR1K_Exception_default /* Reserved for custom exceptions. */ + .word _OR1K_Exception_default /* Reserved for custom exceptions. */ + .word _OR1K_Exception_default /* Reserved for custom exceptions. */ + .word _OR1K_Exception_default /*
[PATCH 3/7] OR1k context handling
diff --git a/cpukit/score/cpu/or1k/or1k-context-initialize.c
b/cpukit/score/cpu/or1k/or1k-context-initialize.c
index a7205e3..d37458e 100644
--- a/cpukit/score/cpu/or1k/or1k-context-initialize.c
+++ b/cpukit/score/cpu/or1k/or1k-context-initialize.c
@@ -29,13 +29,22 @@ void _CPU_Context_Initialize(
void *tls_area
)
{
- /* Decrement 200 byte to account for red-zone */
- uint32_t stack = ((uint32_t) stack_area_begin) - 200;
+ /* Decrement to account for redzone */
+ uint32_t stack = ((uint32_t) stack_area_begin) - REDZONE_SIZE;
uint32_t sr;
uint32_t stack_high = stack + stack_area_size;
sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
+ /* Make sure we will adhere to the requested level */
+ if (new_level > 0) {
+/* Interrupts disable in our local sr */
+sr &= ~(CPU_OR1K_SPR_SR_IEE | CPU_OR1K_SPR_SR_TEE);
+ } else {
+/* Interrupts enable in our local sr */
+sr |= CPU_OR1K_SPR_SR_IEE | CPU_OR1K_SPR_SR_TEE;
+ }
+
memset(context, 0, sizeof(*context));
context->r1 = stack_high;
diff --git a/cpukit/score/cpu/or1k/or1k-context-switch.S
b/cpukit/score/cpu/or1k/or1k-context-switch.S
index 91521e4..2a98cac 100644
--- a/cpukit/score/cpu/or1k/or1k-context-switch.S
+++ b/cpukit/score/cpu/or1k/or1k-context-switch.S
@@ -22,93 +22,96 @@ PUBLIC(_CPU_Context_restore_fp)
PUBLIC(_CPU_Context_save_fp)
SYM(_CPU_Context_switch):
- l.sw 0(r3),r1
- l.sw 4(r3),r2
- l.sw 8(r3),r3
- l.sw 12(r3),r4
- l.sw 16(r3),r5
- l.sw 20(r3),r6
- l.sw 24(r3),r7
- l.sw 28(r3),r8
- l.sw 32(r3),r9
- /* Skip r10 as it's preserved to be used by TLS */
- /* The following set if registers are preserved across function calls */
- l.sw 52(r3),r14
- l.sw 60(r3),r16
- l.sw 68(r3),r18
- l.sw 76(r3),r20
- l.sw 84(r3),r22
- l.sw 92(r3),r24
- l.sw 100(r3),r26
- l.sw 108(r3),r28
- l.sw 116(r3),r30
+ l.swOR1K_CC_GPR1(r3), r1
+ l.swOR1K_CC_GPR2(r3), r2
+ l.swOR1K_CC_GPR3(r3), r3
+ l.swOR1K_CC_GPR4(r3), r4
+ l.swOR1K_CC_GPR5(r3), r5
+ l.swOR1K_CC_GPR6(r3), r6
+ l.swOR1K_CC_GPR7(r3), r7
+ l.swOR1K_CC_GPR8(r3), r8
+ l.swOR1K_CC_GPR9(r3), r9
+ /* The following set of registers are preserved across function calls
+ * (callee-saved) */
+ l.swOR1K_CC_GPR10(r3), r10
+ l.swOR1K_CC_GPR12(r3), r12
+ l.swOR1K_CC_GPR14(r3), r14
+ l.swOR1K_CC_GPR16(r3), r16
+ l.swOR1K_CC_GPR18(r3), r18
+ l.swOR1K_CC_GPR20(r3), r20
+ l.swOR1K_CC_GPR22(r3), r22
+ l.swOR1K_CC_GPR24(r3), r24
+ l.swOR1K_CC_GPR26(r3), r26
+ l.swOR1K_CC_GPR28(r3), r28
+ l.swOR1K_CC_GPR30(r3), r30
/* Supervision Register */
- l.mfspr r13,r0, CPU_OR1K_SPR_SR
- l.sw 124(r3),r13
+ l.mfspr r13, r0, CPU_OR1K_SPR_SR
+ l.swOR1K_CC_SR(r3), r13
/* EPCR */
l.mfspr r13, r0, CPU_OR1K_SPR_EPCR0
- l.sw 128(r3), r13 /* epcr */
+ l.swOR1K_CC_EPCR0(r3), r13
/* EEAR */
l.mfspr r13, r0, CPU_OR1K_SPR_EEAR0
- l.sw 132(r3), r13 /* eear */
+ l.swOR1K_CC_EEAR0(r3), r13
/* ESR */
l.mfspr r13, r0, CPU_OR1K_SPR_ESR0
- l.sw 136(r3), r13 /* esr */
+ l.swOR1K_CC_ESR0(r3), r13
SYM(restore):
- l.lwz r13,124(r4)
- l.mtspr r0,r13, CPU_OR1K_SPR_SR
-
- /* Exception level related registers */
+ l.lwz r13, OR1K_CC_SR(r4)
+ l.mtspr r0, r13, CPU_OR1K_SPR_SR
/* EPCR */
- l.lwz r13, 128(r4)
+ l.lwz r13, OR1K_CC_EPCR0(r4)
l.mtspr r0, r13, CPU_OR1K_SPR_EPCR0
/* EEAR */
- l.lwz r13, 132(r4)
+ l.lwz r13, OR1K_CC_EEAR0(r4)
l.mtspr r0, r13, CPU_OR1K_SPR_EEAR0
/* ESR */
- l.lwz r13, 136(r4)
+ l.lwz r13, OR1K_CC_ESR0(r4)
l.mtspr r0, r13, CPU_OR1K_SPR_ESR0
- l.lwz r1,0(r4)
- l.lwz r2,4(r4)
- l.lwz r3,8(r4)
+ l.lwz r1, OR1K_CC_GPR1(r4)
+ l.lwz r2, OR1K_CC_GPR2(r4)
+ l.lwz r3, OR1K_CC_GPR3(r4)
/* Skip r4 as it contains the current buffer address */
- l.lwz r5,16(r4)
- l.lwz r6,20(r4)
- l.lwz r7,24(r4)
- l.lwz r8,28(r4)
- l.lwz r9,32(r4)
- l.lwz r14,52(r4)
- l.lwz r16,60(r4)
- l.lwz r18,68(r4)
- l.lwz r20,76(r4)
- l.lwz r22,84(r4)
- l.lwz r24,92(r4)
- l.lwz r26,100(r4)
- l.lwz r28,108(r4)
- l.lwz r30,116(r4)
-
- l.lwz r4,12(r4)
-
- l.jr r9
+ l.lwz r5, OR1K_CC_GPR5(r4)
+ l.lwz r6, OR1K_CC_GPR6(r4)
+ l.lwz r7, OR1K_CC_GPR7(r4)
+ l.lwz r8, OR1K_CC_GPR8(r4)
+ l.lwz r9, OR1K_CC_GPR9(r4)
+ l.lwz r10, OR1K_CC_GPR10(r4)
+ l.lwz r12, OR1K_CC_GPR12(r4)
+ l.lwz r14, OR1K_CC_GPR14(r4)
+ l.lwz r16, OR1K_CC_GPR16(r4)
+ l.lwz r18, OR1K_CC_GPR18(r4)
+ l.lwz r20, OR1K_CC_GPR20(r4)
+ l.lwz r22, OR1K_CC_GPR22(r4)
+ l.lwz r24, OR1K_CC_GPR24(r4)
+ l.lwz r26, OR1K_CC_GPR26(r4)
+ l.lwz r28, OR1K_CC_GPR28(r4)
+ l.lwz r30, OR1K_CC_GPR30(r4)
+
+ l.lwz r4, OR1K_CC_GPR4(r4)
+
+ l.jrr9
l.nop
SYM(_CPU_Context_restore):
- l.add r4,r3,r0
- l.add r13,r0,r0
+ l.add r4, r3, r0
l.j restore
l.nop
SYM(_CPU_Context_restore_fp):
+ l.jrr9
l.nop
SYM(_CPU_Context_save_fp):
+
[PATCH 4/7] generic_or1k BSP clock driver correction
diff --git a/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
b/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
index e01d2e5..2dc914a 100644
--- a/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
+++ b/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
@@ -3,13 +3,15 @@
*
* @ingroup bsp_clock
*
- * @brief or1k clock support.
+ * @brief generic_or1k clock support.
*/
/*
* generic_or1k Clock driver
*
* COPYRIGHT (c) 2014-2015 Hesham ALMatary
+ * Copyright (c) 2014-2016 ÅAC Microtec AB
+ * Jakob Viketoft
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
@@ -25,35 +27,30 @@
#include
/* The number of clock cycles before generating a tick timer interrupt. */
-#define TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT 0x09ED9
-#define OR1K_CLOCK_CYCLE_TIME_NANOSECONDS 10
+#define OR1K_CLOCK_CYCLE_TIME_NANOSECONDS (10 /
OR1K_BSP_CLOCK_FREQ)
-static struct timecounter or1ksim_tc;
-
-/* CPU counter */
+static struct timecounter generic_or1k_tc;
static CPU_Counter_ticks cpu_counter_ticks;
+static uint32_t timer_counts_per_clock_tick;
-/* This prototype is added here to Avoid warnings */
+/* These prototypes are added here to avoid warnings */
void Clock_isr(void *arg);
+static uint32_t generic_or1k_get_timecount(struct timecounter *tc);
static void generic_or1k_clock_at_tick(void)
{
- uint32_t TTMR;
+ uint32_t ttmr;
- /* For TTMR register,
- * The least significant 28 bits are the number of clock cycles
- * before generating a tick timer interrupt. While the most
- * significant 4 bits are used for mode configuration, tick timer
- * interrupt enable and pending interrupts status.
- */
- TTMR = (CPU_OR1K_SPR_TTMR_MODE_RESTART | CPU_OR1K_SPR_TTMR_IE |
- (TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT & CPU_OR1K_SPR_TTMR_TP_MASK)
- ) & ~(CPU_OR1K_SPR_TTMR_IP);
+ /* Get TTMR value */
+ ttmr = _OR1K_mfspr(CPU_OR1K_SPR_TTMR);
- _OR1K_mtspr(CPU_OR1K_SPR_TTMR, TTMR);
- _OR1K_mtspr(CPU_OR1K_SPR_TTCR, 0);
+ /* Clear interrupt */
+ ttmr &= ~(CPU_OR1K_SPR_TTMR_IP);
- cpu_counter_ticks += TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT;
+ /* Write it back */
+ _OR1K_mtspr(CPU_OR1K_SPR_TTMR, ttmr);
+
+ cpu_counter_ticks += timer_counts_per_clock_tick;
}
static void generic_or1k_clock_handler_install(
@@ -61,35 +58,19 @@ static void generic_or1k_clock_handler_install(
proc_ptr old_isr
)
{
- rtems_status_code sc = RTEMS_SUCCESSFUL;
old_isr = NULL;
_CPU_ISR_install_vector(OR1K_EXCEPTION_TICK_TIMER,
new_isr,
old_isr);
-
- if (sc != RTEMS_SUCCESSFUL) {
-rtems_fatal_error_occurred(0xdeadbeef);
- }
-}
-
-static uint32_t or1ksim_get_timecount(struct timecounter *tc)
-{
- uint32_t ticks_since_last_timer_interrupt;
-
- ticks_since_last_timer_interrupt = _OR1K_mfspr(CPU_OR1K_SPR_TTCR);
-
- return cpu_counter_ticks + ticks_since_last_timer_interrupt;
-}
-
-CPU_Counter_ticks _CPU_Counter_read(void)
-{
- return or1ksim_get_timecount(NULL);
}
static void generic_or1k_clock_initialize(void)
{
- uint64_t frequency = (10 / OR1K_CLOCK_CYCLE_TIME_NANOSECONDS);
- uint32_t TTMR;
+ uint32_t ttmr;
+
+ /* Calculate timer value for given time per clock tick */
+ timer_counts_per_clock_tick = (1000 *
rtems_configuration_get_microseconds_per_tick()) /
+OR1K_CLOCK_CYCLE_TIME_NANOSECONDS;
/* For TTMR register,
* The least significant 28 bits are the number of clock cycles
@@ -101,36 +82,52 @@ static void generic_or1k_clock_initialize(void)
/* FIXME: Long interval should pass since initializing the tick timer
* registers fires exceptions dispite interrupts has not been enabled yet.
*/
- TTMR = (CPU_OR1K_SPR_TTMR_MODE_RESTART | CPU_OR1K_SPR_TTMR_IE |
- (0xFFED9 & CPU_OR1K_SPR_TTMR_TP_MASK)
- ) & ~(CPU_OR1K_SPR_TTMR_IP);
+ ttmr = (CPU_OR1K_SPR_TTMR_MODE_RESTART | CPU_OR1K_SPR_TTMR_IE |
+ (timer_counts_per_clock_tick & CPU_OR1K_SPR_TTMR_TP_MASK)) &
+~(CPU_OR1K_SPR_TTMR_IP);
- _OR1K_mtspr(CPU_OR1K_SPR_TTMR, TTMR);
+ _OR1K_mtspr(CPU_OR1K_SPR_TTMR, ttmr);
_OR1K_mtspr(CPU_OR1K_SPR_TTCR, 0);
+ /* Initialize CPU Counter */
+ cpu_counter_ticks = 0;
+
/* Initialize timecounter */
- or1ksim_tc.tc_get_timecount = or1ksim_get_timecount;
- or1ksim_tc.tc_counter_mask = 0x;
- or1ksim_tc.tc_frequency = frequency;
- or1ksim_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
- rtems_timecounter_install(&or1ksim_tc);
+ generic_or1k_tc.tc_get_timecount = generic_or1k_get_timecount;
+ generic_or1k_tc.tc_counter_mask = 0x;
+ generic_or1k_tc.tc_frequency = OR1K_BSP_CLOCK_FREQ;
+ generic_or1k_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
+ rtems_timecounter_install(&generic_or1k_tc);
}
static void generic_or1k_clock_cleanup(void)
{
- uint32_t sr;
+ uint32_t sr;
sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
/* Disabl
[PATCH 5/7] OR1k shared and generic_or1k BSP link script rewrite
diff --git a/c/src/lib/libbsp/or1k/generic_or1k/startup/linkcmds
b/c/src/lib/libbsp/or1k/generic_or1k/startup/linkcmds
index cef99d3..3a34186 100644
--- a/c/src/lib/libbsp/or1k/generic_or1k/startup/linkcmds
+++ b/c/src/lib/libbsp/or1k/generic_or1k/startup/linkcmds
@@ -8,16 +8,22 @@
/*
* COPYRIGHT (c) 2014 Hesham ALMatary
+ * Copyright (c) 2015 ÅAC Microtec AB
+ *Jakob Viketoft
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
* http://www.rtems.org/license/LICENSE
*/
+/* Set up system characteristics */
+HeapSize = 0;
+StackSize = 16K;
+
MEMORY
{
- VECTOR_RAM (AIW) : ORIGIN = 0x0 , LENGTH = 8260
- RAM : org = 0x2048, l = 0x1FFDFB8
+ VECTOR_RAM (AIW): ORIGIN = 0x, LENGTH = 8K + 128
+ RAM : ORIGIN = 0x2080, LENGTH = 32M - 8K - 128
UNEXPECTED_SECTIONS : ORIGIN = 0x, LENGTH = 0
}
@@ -35,7 +41,5 @@ REGION_ALIAS ("REGION_BSS", RAM);
REGION_ALIAS ("REGION_WORK", RAM);
REGION_ALIAS ("REGION_STACK", RAM);
-bsp_section_vector_begin = 0;
-bsp_section_stack_begin = 0x1FFDFB8;
INCLUDE linkcmds.base
diff --git a/c/src/lib/libbsp/or1k/shared/include/linker-symbols.h
b/c/src/lib/libbsp/or1k/shared/include/linker-symbols.h
index f0f8377..bae619a 100644
--- a/c/src/lib/libbsp/or1k/shared/include/linker-symbols.h
+++ b/c/src/lib/libbsp/or1k/shared/include/linker-symbols.h
@@ -1,5 +1,5 @@
-#ifndef LIBBSP_OR1k_SHARED_LINKER_SYMBOLS_H
-#define LIBBSP_OR1k_SHARED_LINKER_SYMBOLS_H
+#ifndef LIBBSP_OR1K_SHARED_LINKER_SYMBOLS_H
+#define LIBBSP_OR1K_SHARED_LINKER_SYMBOLS_H
#ifdef __cplusplus
extern "C" {
@@ -59,10 +59,6 @@ LINKER_SYMBOL(bsp_section_stack_begin)
LINKER_SYMBOL(bsp_section_stack_end)
LINKER_SYMBOL(bsp_section_stack_size)
-LINKER_SYMBOL(bsp_vector_table_begin)
-LINKER_SYMBOL(bsp_vector_table_end)
-LINKER_SYMBOL(bsp_vector_table_size)
-
LINKER_SYMBOL(bsp_start_vector_table_begin)
LINKER_SYMBOL(bsp_start_vector_table_end)
LINKER_SYMBOL(bsp_start_vector_table_size)
diff --git a/c/src/lib/libbsp/or1k/shared/startup/linkcmds.base
b/c/src/lib/libbsp/or1k/shared/startup/linkcmds.base
index 31bb92d..4651d4b 100644
--- a/c/src/lib/libbsp/or1k/shared/startup/linkcmds.base
+++ b/c/src/lib/libbsp/or1k/shared/startup/linkcmds.base
@@ -8,6 +8,7 @@
/*
* COPYRIGHT (c) 2014 Hesham ALMatary
+ * COPYRIGHT (c) 2015 ÅAC Microtec AB
+ *Jakob Viketoft
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
@@ -19,35 +20,49 @@ OUTPUT_ARCH (or1k)
ENTRY (_start)
/*
- * Global symbols that may be defined externally
+ * The memory map looks like this:
+ * ++ <- low memory
+ * | .vector| exception vectors and exception
+ * || handler's table
+ * ++
+ * | .start | entry point (setup) code
+ * ++
+ * | .text |
+ * |init|
+ * |fini|
+ * |ctor list | the ctor and dtor lists are for
+ * |dtor list | C++ support
+ * |eh_frame|
+ * |etext |
+ * ++
+ * | .tdata | TLS data
+ * ++
+ * | .tbss | TLS bss
+ * ++
+ * | .data | initialized data goes here
+ * ++
+ * | .bss | section cleared by entry code
+ * ++
+ * | .stack |
+ * ++ <- high memory (top of stack)
*/
-bsp_start_vector_table_begin = 0x1F00;
-bsp_vector_table_size = DEFINED (bsp_vector_table_size) ? bsp_vector_table_size
-: 8260;
-/* 8192 for raw vector table, and 17 * 4 for handlers vector. */
+/* Make sure we have predefined some crucial variables */
+StackSize = DEFINED (StackSize) ? StackSize : 16K;
+HeapSize = DEFINED (HeapSize) ? HeapSize : 0;
-bsp_section_xbarrier_align = DEFINED (bsp_section_xbarrier_align) ?
bsp_section_xbarrier_align : 1;
-bsp_section_robarrier_align = DEFINED (bsp_section_robarrier_align) ?
bsp_section_robarrier_align : 1;
-bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ?
bsp_section_rwbarrier_align : 1;
-
-bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
-
-bsp_stack_main_size = DEFINED (bsp_stack_main_size) ? bsp_stack_main_size : 0;
-bsp_stack_main_size = ALIGN (bsp_stack_main_size, bsp_stack_align);
-
-bsp_processor_count = DEFINED (bsp_processor_count) ? bsp_processor_count : 1;
+bsp_section_stack_size = DEFINED (bsp_section_stack_size) ?
bsp_section_stack_size : 0x4000;
SECTIONS {
.vector : ALIGN_WITH_INPUT {
+bsp_section_vector_begin = .;
*(.vector)
-. = ALIGN(bsp_vector_table_size);
+. = ALIGN(LENGTH(REGION_VECTOR));
bsp_section_vector_end = .;
} > REGION_VECTOR AT > REGION_VECTOR
+
bsp_section_vector_
[PATCH 6/7] OR1k cache invalidate additions
diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache.c
b/c/src/lib/libcpu/or1k/shared/cache/cache.c
index d17fec2..49f5ca9 100644
--- a/c/src/lib/libcpu/or1k/shared/cache/cache.c
+++ b/c/src/lib/libcpu/or1k/shared/cache/cache.c
@@ -4,9 +4,14 @@
* COPYRIGHT (c) 1989-2006
* On-Line Applications Research Corporation (OAR).
*
+ * Copyright (c) 2014 ÅAC Microtec AB
+ * Contributor(s):
+ * Karol Gugala
+ *
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
* http://www.rtems.org/license/LICENSE.
+ *
*/
#include
@@ -14,13 +19,15 @@
#include
#include
#include
+#include
static inline void _CPU_OR1K_Cache_enable_data(void)
{
uint32_t sr;
- ISR_Level level;
+ ISR_Level level;
_ISR_Disable (level);
+
sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
_OR1K_mtspr(CPU_OR1K_SPR_SR, sr | CPU_OR1K_SPR_SR_DCE);
@@ -30,7 +37,7 @@ static inline void _CPU_OR1K_Cache_enable_data(void)
static inline void _CPU_OR1K_Cache_disable_data(void)
{
uint32_t sr;
- ISR_Level level;
+ ISR_Level level;
_ISR_Disable (level);
@@ -43,7 +50,7 @@ static inline void _CPU_OR1K_Cache_disable_data(void)
static inline void _CPU_OR1K_Cache_enable_instruction(void)
{
uint32_t sr;
- ISR_Level level;
+ ISR_Level level;
_ISR_Disable (level);
@@ -79,7 +86,8 @@ static inline void _CPU_OR1K_Cache_data_block_prefetch(const
void *d_addr)
static inline void _CPU_OR1K_Cache_data_block_flush(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_DCBFR, (uintptr_t) d_addr);
@@ -89,7 +97,8 @@ static inline void _CPU_OR1K_Cache_data_block_flush(const
void *d_addr)
static inline void _CPU_OR1K_Cache_data_block_invalidate(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_DCBIR, (uintptr_t) d_addr);
@@ -99,7 +108,8 @@ static inline void
_CPU_OR1K_Cache_data_block_invalidate(const void *d_addr)
static inline void _CPU_OR1K_Cache_data_block_writeback(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_DCBWR, (uintptr_t) d_addr);
@@ -109,7 +119,8 @@ static inline void
_CPU_OR1K_Cache_data_block_writeback(const void *d_addr)
static inline void _CPU_OR1K_Cache_data_block_lock(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_DCBLR, (uintptr_t) d_addr);
@@ -120,7 +131,8 @@ static inline void _CPU_OR1K_Cache_data_block_lock(const
void *d_addr)
static inline void _CPU_OR1K_Cache_instruction_block_prefetch
(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_ICBPR, (uintptr_t) d_addr);
@@ -131,7 +143,8 @@ static inline void
_CPU_OR1K_Cache_instruction_block_prefetch
static inline void _CPU_OR1K_Cache_instruction_block_invalidate
(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_ICBIR, (uintptr_t) d_addr);
@@ -142,7 +155,8 @@ static inline void
_CPU_OR1K_Cache_instruction_block_invalidate
static inline void _CPU_OR1K_Cache_instruction_block_lock
(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_OR1K_mtspr(CPU_OR1K_SPR_ICBLR, (uintptr_t) d_addr);
@@ -152,9 +166,11 @@ static inline void _CPU_OR1K_Cache_instruction_block_lock
/* Implement RTEMS cache manager functions */
-void _CPU_cache_flush_1_data_line(const void *d_addr)
+void _CPU_cache_flush_1_data_line
+(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_CPU_OR1K_Cache_data_block_flush(d_addr);
@@ -164,9 +180,11 @@ void _CPU_cache_flush_1_data_line(const void *d_addr)
_ISR_Enable(level);
}
-void _CPU_cache_invalidate_1_data_line(const void *d_addr)
+void _CPU_cache_invalidate_1_data_line
+(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_CPU_OR1K_Cache_data_block_invalidate(d_addr);
@@ -184,9 +202,11 @@ void _CPU_cache_unfreeze_data(void)
/* Do nothing */
}
-void _CPU_cache_invalidate_1_instruction_line(const void *d_addr)
+void _CPU_cache_invalidate_1_instruction_line
+(const void *d_addr)
{
- ISR_Level level;
+ ISR_Level level;
+
_ISR_Disable (level);
_CPU_OR1K_Cache_instruction_block_invalidate(d_addr);
@@ -206,17 +226,45 @@ void _CPU_cache_unfreeze_instruction(void)
void _CPU_cache_flush_entire_data(void)
{
-
+ int addr;
+
+ /* We have only 0 level cache so we do not need to invalidate others */
+ for (addr = _CPU_cache_get_data_cache_size(0);
+ addr > 0;
+ addr -= CPU_DATA_CACHE_ALIGNMENT) {
+_CPU_OR1K_Cache_data_block_flush((void*) addr);
+ }
}
void _CPU_cache_invalidate_entire_data(void)
{
-
+ int addr;
+
+ /* We have only 0 level cache so we do not need to i
[PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir
diff --git a/c/src/lib/libbsp/or1k/configure.ac b/c/src/lib/libbsp/or1k/configure.ac index e809e40..6bb9c13 100644 --- a/c/src/lib/libbsp/or1k/configure.ac +++ b/c/src/lib/libbsp/or1k/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ([2.69]) AC_INIT([rtems-c-src-lib-libbsp-or1k],[_RTEMS_VERSION],[https://devel.rtems.org/newticket]) -AC_CONFIG_SRCDIR([generic_or1k]) +AC_CONFIG_SRCDIR([../or1k]) RTEMS_TOP(../../../../..) RTEMS_CANONICAL_TARGET_CPU diff --git a/config.sub b/config.sub index 8b612ab..fbeac69 100755 --- a/config.sub +++ b/config.sub @@ -296,7 +296,7 @@ case $basic_machine in | nios | nios2 | nios2eb | nios2el \ | ns16k | ns32k \ | open8 \ - | or1k | or32 \ + | or1k | or32 | or1k-* \ | pdp10 | pdp11 | pj | pjl \ | powerpc | powerpc64 | powerpc64le | powerpcle \ | pyramid \ @@ -1589,7 +1589,7 @@ case $basic_machine in mips*-*) os=-elf ;; - or1k-*) + or1k-* | or1k*-*-*) os=-elf ;; or32-*) Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Correct telnetd uint declaration
Hello!
We came across this when running part of the network tests. I don't know if
it's completely unused since it's been there for a while or we misunderstood
how this declaration is supposed to happen, but here's a patch anyway.
Best regards,
/Jakob
diff --git a/cpukit/telnetd/des.c b/cpukit/telnetd/des.c
index 542e896..ee0f863 100644
--- a/cpukit/telnetd/des.c
+++ b/cpukit/telnetd/des.c
@@ -847,7 +847,7 @@ __des_crypt(const char *key, const char *setting)
void
des_snap(void **pf, void **pd)
{
- uint8* pfc;
+ uint8_t * pfc;
*pf = malloc(sizeof(struct fixed1) + sizeof(struct fixed2) + sizeof(struct
fixed3) + sizeof(struct fixed4));
pfc = *pf;
memcpy(pfc, &des1_f, sizeof(des1_f));
@@ -864,7 +864,7 @@ des_snap(void **pf, void **pd)
void
des_check(void *pf, void *pd)
{
- uint8* pfc1, pfc2, pfc3, pfc4;
+ uint8_t * pfc1, pfc2, pfc3, pfc4;
pfc1 = pf;
pfc2 = pfc1 + sizeof(des1_f);
pfc3 = pfc2 + sizeof(des2_f);
Jakob Viketoft
Senior Engineer in RTL and embedded software
ÅAC Microtec AB
Dag Hammarskjölds väg 48
SE-751 83 Uppsala, Sweden
T: +46 702 80 95 97
http://www.aacmicrotec.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir
On 19/02/16 10:34, Jakob Viketoft wrote: diff --git a/config.sub b/config.sub index 8b612ab..fbeac69 100755 --- a/config.sub +++ b/config.sub @@ -296,7 +296,7 @@ case $basic_machine in | nios | nios2 | nios2eb | nios2el \ | ns16k | ns32k \ | open8 \ - | or1k | or32 \ + | or1k | or32 | or1k-* \ | pdp10 | pdp11 | pj | pjl \ | powerpc | powerpc64 | powerpc64le | powerpcle \ | pyramid \ Why do you need this change? @@ -1589,7 +1589,7 @@ case $basic_machine in mips*-*) os=-elf ;; - or1k-*) + or1k-* | or1k*-*-*) os=-elf ;; or32-*) This change is superfluous. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: OpenRISC patch series...
Are these patches relative to the 4.11 branch or the master? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: OpenRISC patch series...
From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:37 To: devel@rtems.org Subject: Re: OpenRISC patch series... > Are these patches relative to the 4.11 branch or the master? Sorry that I forgot to mention that, they are relative to 4.11 as of d85db176e7d5bcb832ce0764d7db8b94090c4256. /Jakob Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: OpenRISC patch series...
On 19/02/16 13:40, Jakob Viketoft wrote: From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:37 To:devel@rtems.org Subject: Re: OpenRISC patch series... >Are these patches relative to the 4.11 branch or the master? Sorry that I forgot to mention that, they are relative to 4.11 as of d85db176e7d5bcb832ce0764d7db8b94090c4256. Ok, please rebase them on the master. Once they are integrated, we should discuss if they are back ported to 4.11. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir
From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:36 To: Jakob Viketoft; devel@rtems.org Subject: Re: [PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir >On 19/02/16 10:34, Jakob Viketoft wrote: >> diff --git a/config.sub b/config.sub >> index 8b612ab..fbeac69 100755 >> --- a/config.sub >> +++ b/config.sub >> @@ -296,7 +296,7 @@ case $basic_machine in >> | nios | nios2 | nios2eb | nios2el \ >> | ns16k | ns32k \ >> | open8 \ >> - | or1k | or32 \ >> + | or1k | or32 | or1k-* \ >> | pdp10 | pdp11 | pj | pjl \ >> | powerpc | powerpc64 | powerpc64le | powerpcle \ >> | pyramid \ > >Why do you need this change? We roll our own toolchain with a number of smaller changes as we need to put them in and to make that distinction clear, we have it named or1k-aac-rtems4.11-*. This is identified as the machine in RTEMS and won't map to or1k properly unless we add these extra identifiers. I pushed this in an effort to go towards more upstream, but you are right in that it's not required for the generic_or1k to build with a standard RSB toolchain. >> @@ -1589,7 +1589,7 @@ case $basic_machine in >> mips*-*) >> os=-elf >> ;; >> - or1k-*) >> + or1k-* | or1k*-*-*) >> os=-elf >> ;; >> or32-*) > >This change is superfluous. See above. Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: OpenRISC patch series...
From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:44 To: Jakob Viketoft; devel@rtems.org Subject: Re: OpenRISC patch series... >On 19/02/16 13:40, Jakob Viketoft wrote: >> >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber >> [sebastian.hu...@embedded-brains.de] >> Sent: Friday, February 19, 2016 13:37 >> To:devel@rtems.org >> Subject: Re: OpenRISC patch series... >> >>> >Are these patches relative to the 4.11 branch or the master? >> Sorry that I forgot to mention that, they are relative to 4.11 as of >> d85db176e7d5bcb832ce0764d7db8b94090c4256. > >Ok, please rebase them on the master. Once they are integrated, we >should discuss if they are back ported to 4.11. Ok, does the format work on this first set? I assume it's okay to resend all 7 patches again, rebased on master. As for the backporting, most of the changes are crucial for having OpenRISC working at all since there were some mistakes in _ISR_enable/disable and also the link scripts was a pure copy of an arm-variant that didn't make much sense and got the stack wrong. I.e. I hope it will be able to make it to 4.11. Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir
On 19/02/16 13:52, Jakob Viketoft wrote: From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:36 To: Jakob Viketoft;devel@rtems.org Subject: Re: [PATCH 7/7] Add more OR1k machine types and correct OR1k configure subdir >On 19/02/16 10:34, Jakob Viketoft wrote: >>diff --git a/config.sub b/config.sub >>index 8b612ab..fbeac69 100755 >>--- a/config.sub >>+++ b/config.sub >>@@ -296,7 +296,7 @@ case $basic_machine in >> | nios | nios2 | nios2eb | nios2el \ >> | ns16k | ns32k \ >> | open8 \ >>- | or1k | or32 \ >>+ | or1k | or32 | or1k-* \ >> | pdp10 | pdp11 | pj | pjl \ >> | powerpc | powerpc64 | powerpc64le | powerpcle \ >> | pyramid \ > >Why do you need this change? We roll our own toolchain with a number of smaller changes as we need to put them in and to make that distinction clear, we have it named or1k-aac-rtems4.11-*. This is identified as the machine in RTEMS and won't map to or1k properly unless we add these extra identifiers. I pushed this in an effort to go towards more upstream, but you are right in that it's not required for the generic_or1k to build with a standard RSB toolchain. Why can't you use the standard RSB tool chain? Patches to config.sub should go into the config.sub upstream first. Then we can update the complete file from it. See commit log of this file. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] Add option to limit bootstrap to a single arch
Using the -o|--only option, it is now possible to limit the
bootstrapping operation of arch-specific libbsp, libcpu and cpukit paths
to a single arch, for example:
$ bootstrap -p -o or1k
and
$ bootstrap -o or1k
This is a somewhat ugly implementation, but may be sufficient for the
intended usage.
* The cleaning operation is not currently able to selectively clean
archs
* It is currently not possible to specify more than one arch at a time
This reduces bootstrap time to around a third compared to a full run.
---
bootstrap | 60
1 file changed, 60 insertions(+)
diff --git a/bootstrap b/bootstrap
index e9cb851..3434e51 100755
--- a/bootstrap
+++ b/bootstrap
@@ -17,6 +17,7 @@ verbose=""
quiet="false"
mode="autoreconf"
force=0
+bsp_to_build=
usage()
{
@@ -27,6 +28,7 @@ usage()
echo " -c .. clean, remove all aclocal/autoconf/automake generated
files"
echo " -h .. display this message and exit"
echo " -p .. regenerate preinstall.am files"
+ echo " -o .. only generate for given "
echo " -q .. quiet, don't display directories"
echo " -v .. verbose, pass -v to autotools"
echo
@@ -94,6 +96,11 @@ case $1 in
-g|--ge|--gen|--gene|--gener|--genera|--generat|--generate)
mode="generate"
shift;;
+-o|--on|--onl|--only)
+ test $# -gt 1 || usage
+ bsp_to_build=$2
+ shift
+ shift;;
-*) echo "unknown option $1"
usage ;;
*) echo "invalid parameter $1"
@@ -105,6 +112,27 @@ case $mode in
preinstall)
confs=`find . -name Makefile.am -exec grep -l 'include .*/preinstall\.am' {}
\;`
for i in $confs; do
+if test -n "$bsp_to_build"; then
+ case $i in
+ ./c/src/lib/libbsp/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libbsp/*)
+ continue; # skip this file
+ ;;
+ ./c/src/lib/libcpu/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libcpu/*)
+ continue #skip this file
+ ;;
+ ./cpukit/score/cpu/$bsp_to_build/*)
+ ;;
+ ./cpukit/score/cpu/*)
+ continue #skip this file
+ ;;
+ *)
+ ;;
+ esac
+fi
dir=$(dirname $i)
test "$quite" = "true" || echo "Generating $dir/preinstall.am"
${top_srcdir}/ampolish3 "$dir/Makefile.am" > "$dir/preinstall.am"
@@ -145,6 +173,22 @@ generate)
confs=`find . \( -name 'configure.in' -o -name 'configure.ac' \) -print`
for i in $confs; do
+ if test -n "$bsp_to_build"; then
+case $i in
+ ./c/src/lib/libbsp/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libbsp/*)
+ continue # skip this file
+ ;;
+ ./c/src/lib/libcpu/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libcpu/*)
+ continue #skip this file
+ ;;
+ *)
+ ;;
+esac
+ fi
dir=`dirname $i`
configure=`basename $i`
( test "$quiet" = "true" || echo "$dir"
@@ -177,6 +221,22 @@ autoreconf)
confs=`find . -name 'configure.ac' -print`
for i in $confs; do
+ if test -n "$bsp_to_build"; then
+case $i in
+ ./c/src/lib/libbsp/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libbsp/*)
+ continue # skip this file
+ ;;
+ ./c/src/lib/libcpu/$bsp_to_build/*)
+ ;;
+ ./c/src/lib/libcpu/*)
+ continue #skip this file
+ ;;
+ *)
+ ;;
+esac
+ fi
dir=`dirname $i`
configure=`basename $i`
( test "$quiet" = "true" || echo "$dir"
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] Add option to run bootstrap in parallel
Using the -t|--threads option, it is now possible to specify the
amount of threads to use when running autoreconf, for example:
$ bootstrap -t 5
Since each file is autoreconf'd individually, this should not cause any
sequencing issues.
This reduces bootstrap runtime to about a half when using 5 threads on a
dual-core machine.
---
bootstrap | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/bootstrap b/bootstrap
index 3434e51..00457ff 100755
--- a/bootstrap
+++ b/bootstrap
@@ -18,6 +18,7 @@ quiet="false"
mode="autoreconf"
force=0
bsp_to_build=
+threads=1
usage()
{
@@ -29,6 +30,7 @@ usage()
echo " -h .. display this message and exit"
echo " -p .. regenerate preinstall.am files"
echo " -o .. only generate for given "
+ echo " -t .. use threads to run autoreconf in parallel"
echo " -q .. quiet, don't display directories"
echo " -v .. verbose, pass -v to autotools"
echo
@@ -101,6 +103,11 @@ case $1 in
bsp_to_build=$2
shift
shift;;
+-t|--th|--thr|--thre|--thread|--threads)
+ test $# -gt 1 || usage
+ threads=$2
+ shift
+ shift;;
-*) echo "unknown option $1"
usage ;;
*) echo "invalid parameter $1"
@@ -220,6 +227,11 @@ autoreconf)
fi
confs=`find . -name 'configure.ac' -print`
+ if test "$threads" -gt 1; then
+# Since jobs can't be called from a subshell, use a tempfile to store
output
+trap 'rm -f "$jobs_tempfile"' EXIT
+jobs_tempfile=$(mktemp)
+ fi
for i in $confs; do
if test -n "$bsp_to_build"; then
case $i in
@@ -246,8 +258,21 @@ autoreconf)
${AUTORECONF} -i --no-recursive $verbose
test -f Makefile.am && test -n "`grep 'stamp-h\.in' Makefile.in`" \
&& echo timestamp > stamp-h.in
- )
+ ) &
+ if test "$threads" -gt 1; then
+# Wait for amount of threads to drop below max
+jobs >"$jobs_tempfile"
+while test "$(wc -l "$jobs_tempfile")" -ge "$threads"; do
+ sleep 1
+ jobs >"$jobs_tempfile"
+done
+rm -f "$jobs_tempfile"
+trap - EXIT
+ else
+wait
+ fi
done
+ wait
;;
clean)
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] _ARMV7M_Is_vector_an_irq: Use ARMV7M_VECTOR_SYSTICK instead of hardcoded 16
Also add a comment explaining why we use that value.
---
cpukit/score/cpu/arm/rtems/score/armv7m.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/arm/rtems/score/armv7m.h
b/cpukit/score/cpu/arm/rtems/score/armv7m.h
index 251ecdc..0a69363 100644
--- a/cpukit/score/cpu/arm/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/rtems/score/armv7m.h
@@ -386,7 +386,8 @@ typedef struct {
static inline bool _ARMV7M_Is_vector_an_irq( int vector )
{
- return vector >= 16;
+ /* External (i.e. non-system) IRQs start after the SysTick vector. */
+ return vector > ARMV7M_VECTOR_SYSTICK;
}
static inline uint32_t _ARMV7M_Get_basepri(void)
--
2.7.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] Add option to limit bootstrap to a single arch
You may want to use the sb-bootstrap in RSB.
You can invoke bootstrap from any directory with config.ac to avoid
rebootstrapping the whole tree..
On Fri, Feb 19, 2016 at 8:07 AM, Martin Erik Werner
wrote:
> Using the -o|--only option, it is now possible to limit the
> bootstrapping operation of arch-specific libbsp, libcpu and cpukit paths
> to a single arch, for example:
>
> $ bootstrap -p -o or1k
>
> and
>
> $ bootstrap -o or1k
>
> This is a somewhat ugly implementation, but may be sufficient for the
> intended usage.
>
> * The cleaning operation is not currently able to selectively clean
> archs
> * It is currently not possible to specify more than one arch at a time
>
> This reduces bootstrap time to around a third compared to a full run.
> ---
> bootstrap | 60
> 1 file changed, 60 insertions(+)
>
> diff --git a/bootstrap b/bootstrap
> index e9cb851..3434e51 100755
> --- a/bootstrap
> +++ b/bootstrap
> @@ -17,6 +17,7 @@ verbose=""
> quiet="false"
> mode="autoreconf"
> force=0
> +bsp_to_build=
>
> usage()
> {
> @@ -27,6 +28,7 @@ usage()
>echo " -c .. clean, remove all aclocal/autoconf/automake generated
> files"
>echo " -h .. display this message and exit"
>echo " -p .. regenerate preinstall.am files"
> + echo " -o .. only generate for given "
>echo " -q .. quiet, don't display directories"
>echo " -v .. verbose, pass -v to autotools"
>echo
> @@ -94,6 +96,11 @@ case $1 in
> -g|--ge|--gen|--gene|--gener|--genera|--generat|--generate)
>mode="generate"
>shift;;
> +-o|--on|--onl|--only)
> + test $# -gt 1 || usage
> + bsp_to_build=$2
> + shift
> + shift;;
> -*) echo "unknown option $1"
>usage ;;
> *) echo "invalid parameter $1"
> @@ -105,6 +112,27 @@ case $mode in
> preinstall)
>confs=`find . -name Makefile.am -exec grep -l 'include .*/preinstall\.am'
> {} \;`
>for i in $confs; do
> +if test -n "$bsp_to_build"; then
> + case $i in
> + ./c/src/lib/libbsp/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libbsp/*)
> + continue; # skip this file
> + ;;
> + ./c/src/lib/libcpu/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libcpu/*)
> + continue #skip this file
> + ;;
> + ./cpukit/score/cpu/$bsp_to_build/*)
> + ;;
> + ./cpukit/score/cpu/*)
> + continue #skip this file
> + ;;
> + *)
> + ;;
> + esac
> +fi
> dir=$(dirname $i)
> test "$quite" = "true" || echo "Generating $dir/preinstall.am"
> ${top_srcdir}/ampolish3 "$dir/Makefile.am" > "$dir/preinstall.am"
> @@ -145,6 +173,22 @@ generate)
>
>confs=`find . \( -name 'configure.in' -o -name 'configure.ac' \) -print`
>for i in $confs; do
> + if test -n "$bsp_to_build"; then
> +case $i in
> + ./c/src/lib/libbsp/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libbsp/*)
> + continue # skip this file
> + ;;
> + ./c/src/lib/libcpu/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libcpu/*)
> + continue #skip this file
> + ;;
> + *)
> + ;;
> +esac
> + fi
>dir=`dirname $i`
>configure=`basename $i`
>( test "$quiet" = "true" || echo "$dir"
> @@ -177,6 +221,22 @@ autoreconf)
>
>confs=`find . -name 'configure.ac' -print`
>for i in $confs; do
> + if test -n "$bsp_to_build"; then
> +case $i in
> + ./c/src/lib/libbsp/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libbsp/*)
> + continue # skip this file
> + ;;
> + ./c/src/lib/libcpu/$bsp_to_build/*)
> + ;;
> + ./c/src/lib/libcpu/*)
> + continue #skip this file
> + ;;
> + *)
> + ;;
> +esac
> + fi
>dir=`dirname $i`
>configure=`basename $i`
>( test "$quiet" = "true" || echo "$dir"
> --
> 1.9.1
>
> ___
> 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
Re: OpenRISC patch series...
Hi Jakob, On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft wrote: > > > From: Sebastian Huber [sebastian.hu...@embedded-brains.de] > Sent: Friday, February 19, 2016 13:44 > To: Jakob Viketoft; devel@rtems.org > Subject: Re: OpenRISC patch series... > > >On 19/02/16 13:40, Jakob Viketoft wrote: > >> > >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber > >> [sebastian.hu...@embedded-brains.de] > >> Sent: Friday, February 19, 2016 13:37 > >> To:devel@rtems.org > >> Subject: Re: OpenRISC patch series... > >> > >>> >Are these patches relative to the 4.11 branch or the master? > >> Sorry that I forgot to mention that, they are relative to 4.11 as of > >> d85db176e7d5bcb832ce0764d7db8b94090c4256. > > > >Ok, please rebase them on the master. Once they are integrated, we > >should discuss if they are back ported to 4.11. > > Ok, does the format work on this first set? I assume it's okay to resend all > 7 patches again, rebased on master. > > As for the backporting, most of the changes are crucial for having OpenRISC > working at all since there were some mistakes in _ISR_enable/disable and also > the link scripts was a pure copy of an arm-variant that didn't make much > sense and got the stack wrong. I.e. I hope it will be able to make it to 4.11. > The port was working fine late 2014 on both or1ksim and QEMU. Actually it passed the 467 out of 503 tests part of RTEMS Tester at this time. In 2015, the port supported running or1k on real hardware FPGA/Atlys and that's why the BSP name changes from or1ksim to generic_or1k. Have you tested the changes on real hardware and/or simulator? I noticed you said you're using your own toolchain and not RSB. This might not work for RTEMS, as the port assumes the upstream tools built by RSB (except for GCC since it didn't get upstream yet). The other option is to add your own changes to or1k gcc [1] and push any other patches upstream like what Sebastian suggested. [1] https://github.com/openrisc/or1k-gcc/tree/or1k-5.2.0 > > Jakob Viketoft > Senior Engineer in RTL and embedded software > > ÅAC Microtec AB > Dag Hammarskjölds väg 48 > SE-751 83 Uppsala, Sweden > > T: +46 702 80 95 97 > http://www.aacmicrotec.com > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: OpenRISC patch series...
On Fri, Feb 19, 2016 at 7:59 AM, Jakob Viketoft wrote: > > From: Sebastian Huber [sebastian.hu...@embedded-brains.de] > Sent: Friday, February 19, 2016 13:44 > To: Jakob Viketoft; devel@rtems.org > Subject: Re: OpenRISC patch series... > >>On 19/02/16 13:40, Jakob Viketoft wrote: > Ok, does the format work on this first set? I assume it's okay to resend all > 7 patches again, rebased on master. > I haven't tried to apply these patches, but they don't quite look like they were sent properly by git-send-email. Your signature line is appended at the bottom. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: OpenRISC patch series...
Hello Hesham, From: Hesham Almatary [heshamelmat...@gmail.com] Sent: Friday, February 19, 2016 15:51 To: Jakob Viketoft Cc: devel@rtems.org Subject: Re: OpenRISC patch series... >Hi Jakob, > >On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft > wrote: >> >> >> From: Sebastian Huber [sebastian.hu...@embedded-brains.de] >> Sent: Friday, February 19, 2016 13:44 >> To: Jakob Viketoft; devel@rtems.org >> Subject: Re: OpenRISC patch series... >> >> >On 19/02/16 13:40, Jakob Viketoft wrote: >> >> >> >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber >> >> [sebastian.hu...@embedded-brains.de] >> >> Sent: Friday, February 19, 2016 13:37 >> >> To:devel@rtems.org >> >> Subject: Re: OpenRISC patch series... >> >> >> >>> >Are these patches relative to the 4.11 branch or the master? >> >> Sorry that I forgot to mention that, they are relative to 4.11 as of >> >> d85db176e7d5bcb832ce0764d7db8b94090c4256. >> > >> >Ok, please rebase them on the master. Once they are integrated, we >> >should discuss if they are back ported to 4.11. >> >> Ok, does the format work on this first set? I assume it's okay to resend all >> 7 patches again, rebased on master. >> >> As for the backporting, most of the changes are crucial for having OpenRISC >> working at all since there were some mistakes in _ISR_enable/disable and >> also the link scripts was a pure copy of an arm-variant that didn't make >> much sense and got the stack wrong. I.e. I hope it will be able to make it >> to 4.11. >> >The port was working fine late 2014 on both or1ksim and QEMU. >Actually it passed the 467 out of 503 tests part of RTEMS Tester at >this time. In 2015, the port supported running or1k on real hardware >FPGA/Atlys and that's why the BSP name changes from or1ksim to >generic_or1k. >Have you tested the changes on real hardware and/or simulator? I >noticed you said you're using your own toolchain and not RSB. This >might not work for RTEMS, as the port assumes the upstream tools built >by RSB (except for GCC since it didn't get upstream yet). The other >option is to add your own changes to or1k gcc [1] and push any other >patches upstream like what Sebastian suggested. > >[1] https://github.com/openrisc/or1k-gcc/tree/or1k-5.2.0 Yes, we have run it quite extensively on real hardware for a while now. I also know that the test code in RTEMS passes without fail, but when we use it with some more advanced software which make heavy use of threads and signals, it went berserk on the watchdog list. A more demanding test using extended ticker.c code showed it to be the error in ISR_enable/disable (along with some needed bugfixes in RTEMS on signals). Some of the changes are for readability where hardcoded values were used for registers or bits in them, and others had to do with setting up the system into a known state each boot. Without that we would require a power cycling of the board each time instead of a simple re-load of the application software. If you would review the patches on a simple code read basis, I don't think you would disagree much with what has been put there, I'm happy to answer any question or concern that you might have. I didn't say we didn't use RSB to build the toolchain, I just have it pointed to use our internal repos in cases where we have had to add code to complement what's available upstream. To distinct it from a "standard" build of RSB we simply added the name -aac- to avoid confusion, but if it's a big problem we might revert this or keep the config.sub patch only in our tree. Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: OpenRISC patch series...
Hi Jakob, On Sat, Feb 20, 2016 at 2:12 AM, Jakob Viketoft wrote: > Hello Hesham, > > > From: Hesham Almatary [heshamelmat...@gmail.com] > Sent: Friday, February 19, 2016 15:51 > To: Jakob Viketoft > Cc: devel@rtems.org > Subject: Re: OpenRISC patch series... > >>Hi Jakob, >> >>On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft >> wrote: >>> >>> >>> From: Sebastian Huber [sebastian.hu...@embedded-brains.de] >>> Sent: Friday, February 19, 2016 13:44 >>> To: Jakob Viketoft; devel@rtems.org >>> Subject: Re: OpenRISC patch series... >>> >>> >On 19/02/16 13:40, Jakob Viketoft wrote: >>> >> >>> >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber >>> >> [sebastian.hu...@embedded-brains.de] >>> >> Sent: Friday, February 19, 2016 13:37 >>> >> To:devel@rtems.org >>> >> Subject: Re: OpenRISC patch series... >>> >> >>> >>> >Are these patches relative to the 4.11 branch or the master? >>> >> Sorry that I forgot to mention that, they are relative to 4.11 as of >>> >> d85db176e7d5bcb832ce0764d7db8b94090c4256. >>> > >>> >Ok, please rebase them on the master. Once they are integrated, we >>> >should discuss if they are back ported to 4.11. >>> >>> Ok, does the format work on this first set? I assume it's okay to resend >>> all 7 patches again, rebased on master. >>> >>> As for the backporting, most of the changes are crucial for having OpenRISC >>> working at all since there were some mistakes in _ISR_enable/disable and >>> also the link scripts was a pure copy of an arm-variant that didn't make >>> much sense and got the stack wrong. I.e. I hope it will be able to make it >>> to 4.11. >>> >>The port was working fine late 2014 on both or1ksim and QEMU. >>Actually it passed the 467 out of 503 tests part of RTEMS Tester at >>this time. In 2015, the port supported running or1k on real hardware >>FPGA/Atlys and that's why the BSP name changes from or1ksim to >>generic_or1k. > >>Have you tested the changes on real hardware and/or simulator? I >>noticed you said you're using your own toolchain and not RSB. This >>might not work for RTEMS, as the port assumes the upstream tools built >>by RSB (except for GCC since it didn't get upstream yet). The other >>option is to add your own changes to or1k gcc [1] and push any other >>patches upstream like what Sebastian suggested. >> >>[1] https://github.com/openrisc/or1k-gcc/tree/or1k-5.2.0 > > Yes, we have run it quite extensively on real hardware for a while now. I > also know that the test code in RTEMS passes without fail, but when we use it > with some more advanced software which make heavy use of threads and signals, > it went berserk on the watchdog list. Great, thanks for the details and contributing back with the fixes. I am interested to know what hardware (FPGA board and RTL SoC) did you use? It might be a good idea to have a list of targets that the port has run on since the hardware implementation is very flexible. > A more demanding test using extended ticker.c code showed it to be the error > in ISR_enable/disable (along with some needed bugfixes in RTEMS on signals). > Some of the changes are for readability Yes I totally support the readability-related patches. where hardcoded values were used for registers or bits in them, and others had to do with setting up the system into a known state each boot. Without that we would require a power cycling of the board each time instead of a simple re-load of the application software. If you would review the patches on a simple code read basis, I don't think you would disagree much with what has been put there, I'm happy to answer any question or concern that you might have. > > I didn't say we didn't use RSB to build the toolchain, I just have it pointed > to use our internal repos in cases where we have had to add code to > complement what's available upstream. To distinct it from a "standard" build > of RSB we simply added the name -aac- to avoid confusion, but if it's a big > problem we might revert this or keep the config.sub patch only in our tree. > Do any of the patches add code that assumes your new "aac" additions? I'll have to setup the RTEMS dev env, apply the patches and perhaps run a few test cases and RTEMS Tester. > Jakob Viketoft > Senior Engineer in RTL and embedded software > > ÅAC Microtec AB > Dag Hammarskjölds väg 48 > SE-751 83 Uppsala, Sweden > > T: +46 702 80 95 97 > http://www.aacmicrotec.com -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: OpenRISC patch series...
From: Hesham Almatary [heshamelmat...@gmail.com] Sent: Friday, February 19, 2016 16:28 To: Jakob Viketoft Cc: devel@rtems.org Subject: Re: OpenRISC patch series... >On Sat, Feb 20, 2016 at 2:12 AM, Jakob Viketoft > wrote: >> Hello Hesham, >> >> >> From: Hesham Almatary [heshamelmat...@gmail.com] >> Sent: Friday, February 19, 2016 15:51 >> To: Jakob Viketoft >> Cc: devel@rtems.org >> Subject: Re: OpenRISC patch series... >> >>>Hi Jakob, >>> >>>On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft >>> wrote: From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Friday, February 19, 2016 13:44 To: Jakob Viketoft; devel@rtems.org Subject: Re: OpenRISC patch series... >On 19/02/16 13:40, Jakob Viketoft wrote: >> >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber >> [sebastian.hu...@embedded-brains.de] >> Sent: Friday, February 19, 2016 13:37 >> To:devel@rtems.org >> Subject: Re: OpenRISC patch series... >> >>> >Are these patches relative to the 4.11 branch or the master? >> Sorry that I forgot to mention that, they are relative to 4.11 as of >> d85db176e7d5bcb832ce0764d7db8b94090c4256. > >Ok, please rebase them on the master. Once they are integrated, we >should discuss if they are back ported to 4.11. Ok, does the format work on this first set? I assume it's okay to resend all 7 patches again, rebased on master. As for the backporting, most of the changes are crucial for having OpenRISC working at all since there were some mistakes in _ISR_enable/disable and also the link scripts was a pure copy of an arm-variant that didn't make much sense and got the stack wrong. I.e. I hope it will be able to make it to 4.11. >>>The port was working fine late 2014 on both or1ksim and QEMU. >>>Actually it passed the 467 out of 503 tests part of RTEMS Tester at >>>this time. In 2015, the port supported running or1k on real hardware >>>FPGA/Atlys and that's why the BSP name changes from or1ksim to >>>generic_or1k. >> >>>Have you tested the changes on real hardware and/or simulator? I >>>noticed you said you're using your own toolchain and not RSB. This >>>might not work for RTEMS, as the port assumes the upstream tools built >>>by RSB (except for GCC since it didn't get upstream yet). The other >>>option is to add your own changes to or1k gcc [1] and push any other >>>patches upstream like what Sebastian suggested. >>> >>>[1] https://github.com/openrisc/or1k-gcc/tree/or1k-5.2.0 >> >> Yes, we have run it quite extensively on real hardware for a while now. I >> also know that the test code in RTEMS passes without fail, but when we use >> it with some more advanced software which make heavy use of threads and >> signals, it went berserk on the watchdog list. >Great, thanks for the details and contributing back with the fixes. >I am interested to know what hardware (FPGA board and RTL SoC) did you >use? It might be a good idea to have a list of targets that the port >has run on since the hardware implementation is very flexible. First I need to point out that we have a custom BSP which uses much of the common or1k stuff, but where we haven't run generic_or1k directly. In my patches however, I have patched all the relevant work that we have done in our BSP back to the generic_or1k one. I would also like to add the interrupt handler there, but I haven't done so at this point. We would also like to upstream our BSP as well, but we haven't quite sorted out yet how we want to go about with the drivers since we at the moment compile with out-of-tree drivers for practical (git-repo) reasons. FPGA boards and RTL SoC are all custom, but you can read a bit more about them here: http://www.aacmicrotec.com/index.php/2012-04-17-12-17-04/products/space-wire-avionics >> A more demanding test using extended ticker.c code showed it to be the error >> in ISR_enable/disable (along with some needed bugfixes in RTEMS on signals). >> Some of the changes are for readability > >Yes I totally support the readability-related patches. > > where hardcoded values were used for registers or bits in them, and >others had to do with setting up the system into a known state each >boot. Without that we would require a power cycling of the board each >time instead of a simple re-load of the application software. If you >would review the patches on a simple code read basis, I don't think >you would disagree much with what has been put there, I'm happy to >answer any question or concern that you might have. >> >> I didn't say we didn't use RSB to build the toolchain, I just have it >> pointed to use our internal repos in cases where we have had to add code to >> complement what's available upstream. To di
RE: OpenRISC patch series...
From: ged...@gwmail.gwu.edu [ged...@gwmail.gwu.edu] on behalf of Gedare Bloom [ged...@rtems.org] Sent: Friday, February 19, 2016 15:58 To: Jakob Viketoft Cc: devel@rtems.org Subject: Re: OpenRISC patch series... >On Fri, Feb 19, 2016 at 7:59 AM, Jakob Viketoft > wrote: >> >> From: Sebastian Huber [sebastian.hu...@embedded-brains.de] >> Sent: Friday, February 19, 2016 13:44 >> To: Jakob Viketoft; devel@rtems.org >> Subject: Re: OpenRISC patch series... >> >>>On 19/02/16 13:40, Jakob Viketoft wrote: >> Ok, does the format work on this first set? I assume it's okay to resend all >> 7 patches again, rebased on master. >> >I haven't tried to apply these patches, but they don't quite look like >they were sent properly by git-send-email. Your signature line is >appended at the bottom. The simple answer is because I didn't. :) I was hoping to get away anyway since I'm working through a less then optimal e-mail solution in git terms, but I'll have a go at sending them directly instead. Jakob Viketoft Senior Engineer in RTL and embedded software ÅAC Microtec AB Dag Hammarskjölds väg 48 SE-751 83 Uppsala, Sweden T: +46 702 80 95 97 http://www.aacmicrotec.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: OpenRISC patch series...
On Fri, Feb 19, 2016 at 10:48 AM, Jakob Viketoft wrote: > > From: ged...@gwmail.gwu.edu [ged...@gwmail.gwu.edu] on behalf of Gedare Bloom > [ged...@rtems.org] > Sent: Friday, February 19, 2016 15:58 > To: Jakob Viketoft > Cc: devel@rtems.org > Subject: Re: OpenRISC patch series... > >>On Fri, Feb 19, 2016 at 7:59 AM, Jakob Viketoft >> wrote: >>> >>> From: Sebastian Huber [sebastian.hu...@embedded-brains.de] >>> Sent: Friday, February 19, 2016 13:44 >>> To: Jakob Viketoft; devel@rtems.org >>> Subject: Re: OpenRISC patch series... >>> On 19/02/16 13:40, Jakob Viketoft wrote: >>> Ok, does the format work on this first set? I assume it's okay to resend >>> all 7 patches again, rebased on master. >>> >>I haven't tried to apply these patches, but they don't quite look like >>they were sent properly by git-send-email. Your signature line is >>appended at the bottom. > > The simple answer is because I didn't. :) I was hoping to get away anyway > since I'm working through a less then optimal e-mail solution in git terms, > but I'll have a go at sending them directly instead. > If you can't use git-send-email, just attach them separately, Anything else is complicated to pull the patch out of the email. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Regarding GSOC 2016 BSP for BBB
On Thu, Feb 18, 2016 at 12:09 PM, punit vara wrote: > According to final report > https://devel.rtems.org/wiki/GSoC/2015/Final_Report , Ketul shah's > work can be extended to develop PWM driver and it seems i2c driver is > not yet done correctly or have some problem. What would you suggest me > to do further ? > > On Tue, Feb 16, 2016 at 1:13 PM, punit vara wrote: >> On Mon, Feb 15, 2016 at 9:46 PM, Joel Sherrill wrote: >>> >>> >>> On Mon, Feb 15, 2016 at 7:31 AM, punit vara wrote: I am in my final year of Master of embedded system course. Last year only I came to know about GSOC .I came to know about amazing rtos rtems while searching for embedded system projects. I was bit late to proceed proposal last year as I was not aware that much.This could be my last chance to get selected for GSOC 2016. I am interested for developing BSP for BBB as I have beaglebone black. I have read some of peripheral need support. Could I take this project this year ? If yes , any suggestions for improving my chance to get selected this year are welcome. >>> >>> I wasn't the mentor for the BB and Pi tasks last year although I tracked >>> and helped answer questions. >>> >>> The BBB has a BSP with a number of the peripherals completed. I think you >>> need to review the current BSP to see what is missing. Looking at the status >>> reports from the projects last year will also help. >>> >>> I am honestly unsure of what remains. >>> >>> --joel >>> Regards, Punit Vara ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >>> >> Last year Ketul has done BSP for BBB who is good friend of mine. He >> has done BSP for GPIO and ADC. He told me apart from this most of >> peripheral need support and also suggested me to ask Ben about this. >> @Ben Can you please suggest me what further BSP idea I can take for >> GSOC 2016 ? .Also please suggest me some reading so I can improve my >> chances this time to get accepted in gsoc 2016. Yet I am going through >> RTEMS docs provided on official site.But you may particular point me >> out. I have checked c/src/lib/libbsp/arm/beagle/ ...It seems SPI , USB is yet to be developed. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Regarding GSOC 2016 BSP for BBB
CAN, USB and I2C still need to be developed. We're currently using the AM335x StarterWare code and it works fine; you may want to base your work on it. Keep an eye open for licensing issues, though. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] arm: Fixed typo in file bbb-gpio.c
This patch fixes typo "moode".
Signed-off: Punit Vara
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index 2a3f7e8..8532f54 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -269,7 +269,7 @@ rtems_status_code rtems_gpio_bsp_set_resistor_mode(
uint32_t pin,
rtems_gpio_pull_mode mode
) {
- /* TODO: Add support for setting up resistor moode */
+ /* TODO: Add support for setting up resistor mode */
return RTEMS_NOT_DEFINED;
}
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] _ARMV7M_Is_vector_an_irq: Use ARMV7M_VECTOR_SYSTICK instead of hardcoded 16
This should be committed now. Thanks.
On Fri, Feb 19, 2016 at 8:32 AM, Martin Galvan <
martin.gal...@tallertechnologies.com> wrote:
> Also add a comment explaining why we use that value.
> ---
> cpukit/score/cpu/arm/rtems/score/armv7m.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/arm/rtems/score/armv7m.h
> b/cpukit/score/cpu/arm/rtems/score/armv7m.h
> index 251ecdc..0a69363 100644
> --- a/cpukit/score/cpu/arm/rtems/score/armv7m.h
> +++ b/cpukit/score/cpu/arm/rtems/score/armv7m.h
> @@ -386,7 +386,8 @@ typedef struct {
>
> static inline bool _ARMV7M_Is_vector_an_irq( int vector )
> {
> - return vector >= 16;
> + /* External (i.e. non-system) IRQs start after the SysTick vector. */
> + return vector > ARMV7M_VECTOR_SYSTICK;
> }
>
> static inline uint32_t _ARMV7M_Get_basepri(void)
> --
> 2.7.1
>
> ___
> 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
Re: [PATCH] arm: Fixed typo in file bbb-gpio.c
This should be committed now. Thanks.
On Fri, Feb 19, 2016 at 12:24 PM, punitvara wrote:
> This patch fixes typo "moode".
>
> Signed-off: Punit Vara
> ---
> c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
> b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
> index 2a3f7e8..8532f54 100644
> --- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
> +++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
> @@ -269,7 +269,7 @@ rtems_status_code rtems_gpio_bsp_set_resistor_mode(
>uint32_t pin,
>rtems_gpio_pull_mode mode
> ) {
> - /* TODO: Add support for setting up resistor moode */
> + /* TODO: Add support for setting up resistor mode */
>return RTEMS_NOT_DEFINED;
> }
>
> --
> 1.9.1
>
> ___
> 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
Re: [PATCH 1/2] Add option to limit bootstrap to a single arch
On 20/02/2016 12:07 AM, Martin Erik Werner wrote: > Using the -o|--only option, it is now possible to limit the > bootstrapping operation of arch-specific libbsp, libcpu and cpukit paths > to a single arch, for example: > > $ bootstrap -p -o or1k > > This is a somewhat ugly implementation, but may be sufficient for the > intended usage. -1 It is normal to expect the full tree to be in a completely sync'ed state and I see this as a way to have that not happen. As a result I see this option as dangerous and do not support it being merged. FYI we are moving to waf and the sooner we can get the doco sorted and 4.11 released the sooner we have the waf work moved to the master repo and branch. On fast hardware a BSP can build in under 30 seconds. > This reduces bootstrap time to around a third compared to a full run. Have you tried the sb-bootstrap tool in the RSB? It can do the same and better on a multi-core machine for a full bootstrap. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuits: Fixed typo in fileio.doc
This patch basically fixes some typo in document file. Signed-off: Punit Vara --- testsuites/samples/fileio/fileio.doc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/testsuites/samples/fileio/fileio.doc b/testsuites/samples/fileio/fileio.doc index 0a43601..95d50b1 100644 --- a/testsuites/samples/fileio/fileio.doc +++ b/testsuites/samples/fileio/fileio.doc @@ -22,17 +22,17 @@ A sample session might look like this: - start this system - select "p" (part_table_initialize) to read in the partition table of -first harddisk, enter the device name "/dev/hda", when prompted +first hard disk, enter the device name "/dev/hda", when prompted - select "f" (fsmount) to try to mount the partitions - /dev/hda1../dev/hdc4 to corresponding mount points. Non-existant + /dev/hda1../dev/hdc4 to corresponding mount points. Non-existent partitions will report an error, but will not abort the tests - select "w" (write file) to create a new file on the mounted disk (or in the IMFS). Enter the file name (e.g. "/mnt/hda1/test_1M.txt"), the file size (e.g. 64K or 2M) and the buffer size to use for the write calls (e.g. 32 or 4K). Then the sample will try to write the - corresponding file and print the time consumed and data rate achived. + corresponding file and print the time consumed and data rate achieved. - select "r" (read file) to read a file (without displaying the contents). It has similar parameters as "write file", but does not -- 2.7.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] arm: Fixed typo in file bbb-gpio.c
Your welcome Joel :-)
On Sat, Feb 20, 2016 at 3:44 AM, Joel Sherrill wrote:
> This should be committed now. Thanks.
>
> On Fri, Feb 19, 2016 at 12:24 PM, punitvara wrote:
>>
>> This patch fixes typo "moode".
>>
>> Signed-off: Punit Vara
>> ---
>> c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> index 2a3f7e8..8532f54 100644
>> --- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> +++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> @@ -269,7 +269,7 @@ rtems_status_code rtems_gpio_bsp_set_resistor_mode(
>>uint32_t pin,
>>rtems_gpio_pull_mode mode
>> ) {
>> - /* TODO: Add support for setting up resistor moode */
>> + /* TODO: Add support for setting up resistor mode */
>>return RTEMS_NOT_DEFINED;
>> }
>>
>> --
>> 1.9.1
>>
>> ___
>> 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
