RE: [PATCH 0/6] Add aarch64/xilinx-versal
Looks good. It's odd that we can't step down from EL3->EL2S->EL1S and have the timer work on the versal. It'd be nice if we could just flip the security bit one way or the other on the way down and share the cascade from EL3 to EL1 without skipping parts of it. This might be something to look into further in the future. Kinsey -Original Message- From: devel On Behalf Of Gedare Bloom Sent: Tuesday, June 22, 2021 23:30 To: devel@rtems.org Subject: [PATCH 0/6] Add aarch64/xilinx-versal This patch series adds support for the Xilinx Versal ACAP targeting the qemu emulated support (xlnx-versal-virt) and with a config for vck190. The hardware support on vck190 is still work-in-progress, and the ilp32 has not been tested. The patch set includes non-functional changes to make the icspicfgr0/1 an array for better indexing, to add the physical secure timer, and a mnemonic to access the group 1 interrupt enable at EL3. These non-functional changes wound up being unnecessary, but were left in case they are useful to someone in the future. The virtual and physical secure timers do not work with the xilinx_versal_lp64_qemu BSP. Only the physical non-secure timer works, and only in EL1 security mode. The xlnx-versal-virt direct boots on qemu in EL3. The current approach steps down directly to EL1 in Secure Mode. If EL3 is instead stepped down to EL2 and then to EL1 non-secure, the timer IRQ dispatching does not work properly for some reason. So now we have support in place to run in EL1 Secure mode or in EL1 Non-Secure mode, controlled by a configuration option. The a53 and a72 BSPs can only work in the EL1 Non-Secure mode, while the xilinx_zynq_lp64_qemu seems to be able to work with both EL1 Secure and Non-Secure modes. The selection is made by a new config option, AARCH_IS_NON_SECURE. Tester Results for xilinx_versal_lp64_qemu: Passed:549 Failed: 1 User Input: 5 Expected Fail: 0 Indeterminate: 0 Benchmark: 3 Timeout: 0 Test too long: 0 Invalid: 0 Wrong Version: 0 Wrong Build: 0 Wrong Tools: 0 -- Total: 558 Failures: spcpucounter01.exe User Input: top.exe fileio.exe capture.exe monitor.exe termios.exe Benchmark: dhrystone.exe whetstone.exe linpack.exe The failure in spcpucounter01.exe appears to be related to the ongoing problem with qemu random failures. Manual testing can pass or fail. No regressions noted in a53, a72, or zynqmp qemu testing. Gedare Bloom (5): aarch64/xilinx-versal: new BSPs for qemu and vck190 bsps/dev/irq: make icspicfgr an indexable array bsps/aarch64: add mnemonic for ICC_IGRPEN1_EL3 bsps/aarch64: add physical secure timer bsps/aarch64: add non-secure mode and versal support Kinsey Moore (1): aarch64: add support to drop EL3 to EL2 .../shared/clock/arm-generic-timer-aarch64.c | 8 + bsps/aarch64/shared/start/start.S | 38 ++- bsps/aarch64/xilinx-versal/console/console.c | 134 ++ .../dev/serial/versal-uart-polled.c | 228 ++ bsps/aarch64/xilinx-versal/include/bsp.h | 81 +++ bsps/aarch64/xilinx-versal/include/bsp/irq.h | 72 ++ .../include/dev/serial/versal-uart-regs.h | 141 +++ .../include/dev/serial/versal-uart.h | 90 +++ bsps/aarch64/xilinx-versal/include/tm27.h | 45 bsps/aarch64/xilinx-versal/start/bspstart.c | 48 .../xilinx-versal/start/bspstarthooks.c | 51 .../aarch64/xilinx-versal/start/bspstartmmu.c | 77 ++ bsps/include/dev/irq/arm-gic-regs.h | 6 +- bsps/shared/dev/irq/arm-gicv3.c | 24 +- spec/build/bsps/aarch64/a53/grp.yml | 2 + spec/build/bsps/aarch64/a72/grp.yml | 2 + spec/build/bsps/aarch64/optgtuseps.yml| 17 ++ spec/build/bsps/aarch64/optgtusevirt.yml | 16 ++ spec/build/bsps/aarch64/optisns.yml | 20 ++ spec/build/bsps/aarch64/xilinx-versal/abi.yml | 22 ++ .../aarch64/xilinx-versal/bspqemuilp32.yml| 19 ++ .../aarch64/xilinx-versal/bspqemulp64.yml | 19 ++ .../aarch64/xilinx-versal/bspvck190ilp32.yml | 19 ++ .../aarch64/xilinx-versal/bspvck190lp64.yml | 19 ++ spec/build/bsps/aarch64/xilinx-versal/grp.yml | 56 + .../bsps/aarch64/xilinx-versal/grp_qemu.yml | 18 ++ .../bsps/aarch64/xilinx-versal/grp_vck190.yml | 18 ++ .../aarch64/xilinx-versal/linkcmds_ilp32.yml | 74 ++ .../aarch64/xilinx-versal/linkcmds_lp64.yml | 74 ++ spec/build/bsps/aarch64/xilinx-versal/obj.yml | 44 .../bsps/aarch64/xilinx-versal/optclkuart.yml | 20 ++ .../aarch64/xilinx-versal/optconminor.yml | 16 ++ .../bsps/aarch64/xilinx-versal/optloadoff.yml | 22 ++ .../aarch64/xilinx-versal/optnocachelen.yml | 18 ++ .../bsps/aarch64/xilinx-versal/optramlen.yml | 18 ++ .../bsps/aarch64/xilinx-versal/optramori.yml | 22 ++ .../bsps/aarch64/xilinx-versal/tstqemu.yml| 19 ++ .../bsps/aarch64/xilinx-versal/tstvck190.ym
Re: [PATCH] part of implimenting a monotonic clock in rtems part of this is not the final patch.
I tried to do some testing with the code I write. I tired to test it by making a rtems app. I modified the code from the ubuntu manpage ( here https://manpages.ubuntu.com/manpages/bionic/man2/timer_create.2.html)so it does not need command line arguments and my code was able to compile. When I run the program it does not print anything. I double-checked the POSIX calls and all were compatible with rtems. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, June 19th, 2021 at 6:49 PM, zack_on_the_speed_chanel wrote: > I have added the tests and added the ones that create the timer. My idea for > testing is that if I change the wall clock and I'll check the monotonic > clock's time. But I think I have to make a signal and arm the timer. > > Thanks > > Zack > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, June 18th, 2021 at 8:01 AM, Christian Mauderer o...@c-mauderer.de > wrote: > > > Hello Zack, > > > > On 18/06/2021 04:34, zack_on_the_speed_chanel wrote: > > > > > so I tested it with the but I have not made a new test file I'll do that > > > soon. How do I add a new test? All the tests that test the timer > > > functionality do work. I"m confident that all the changes I had to made > > > to implement a monotonic clock should be there. > > > > Regarding a new test: Just grep for example for psxtimer01 in the > > > > sources and add the new test simmilar to the existing one. > > > > The most relevant files are spec/build/testsuites/psxtests/*.yml for the > > > > waf based build system and testsuites/psxtests/Makefile.am and > > > > .../configure.ac for the old build system. > > > > But please check whether you need a new test program. If you basically > > > > only copy the test routine of psxtimer01 or psxtimer02 and replace all > > > > CLOCK_REALTIME by CLOCK_MONOTONIC then you shouldn't add a new test. > > > > Instead create a function in the test that is called once with > > > > CLOCK_REALTIME and once with CLOCK_MONOTONIC. > > > > Please make sure that the test not only tests the API but also whether > > > > the timer work as expected. A timer with CLOCK_REALTIME can be affected > > > > by changes in the wall clock. CLOCK_MONOTONIC should not be affected. So > > > > please make sure that your test checks whether that is really the case. > > > > Best regards > > > > Christian > > > > > Thanks > > > > > > Zack > > > > > > Sent with ProtonMail Secure Email. > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Tuesday, June 15th, 2021 at 7:29 AM, Christian Mauderer > > > o...@c-mauderer.de wrote: > > > > > > > If you add a new functionallity you should add a test that tests the > > > > > > > > expected behaviour. You just shouldn't replace one but add a new test or > > > > > > > > a new test case to an existing test. > > > > > > > > Best regards > > > > > > > > Christian > > > > > > > > On 14/06/2021 22:18, zack_on_the_speed_chanel wrote: > > > > > > > > > also i'll revert the posix test that I changed back to normal because > > > > > it was only for testing. > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > On Monday, June 14th, 2021 at 8:14 PM, zack_on_the_speed_chanel > > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > > > > > I've made most of the corrections to the code. I fixed up the > > > > > > formatting but I still don't know if I have to add anything for the > > > > > > settime and delete_timer(). i assume as the monotonic clock only > > > > > > affects the value I think it's all I have to do. I also can try to > > > > > > modify a posix test to check my theory. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Zack > > > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > > > On Saturday, June 12th, 2021 at 9:31 AM, Christian Mauderer > > > > > > o...@c-mauderer.de wrote: > > > > > > > > > > > > > Hello Zack, > > > > > > > > > > > > > > I don't really know a lot about the timer toppic. So this is more > > > > > > > of a > > > > > > > > > > > > > > style and general suggestion review. > > > > > > > > > > > > > > On 09/06/2021 20:27, zack wrote: > > > > > > > > > > > > > > > From: zack zack_on_the_speed_cha...@protonmail.ch > > > > > > > > > > > > > > > > cpukit/include/rtems/posix/timer.h | 6 ++- > > > > > > > > > > > > > > > > cpukit/posix/src/psxtimercreate.c | 5 +- > > > > > > > > > > > > > > > > cpukit/posix/src/timergettime.c | 61 --- > > > > > > > > > > > > > > > > testsuites/psxtests/psxtimer02/psxtimer.c | 26 +++--- > > > > > > > > > > > > > > > > 4 files changed, 81 insertions(+), 17 deletions(-) > > > > > > > > > > > > > > > > diff --git a/cpukit/include/rtems/posix/timer.h > > > > > > > > b/cpukit/include/rtems/posix/timer.h > > > > > > > > > > > > > > > > index bcbf07a65a..f8cf6115b2 1
Re: [PATCH] part of implimenting a monotonic clock in rtems part of this is not the final patch.
On Wed, Jun 23, 2021 at 12:16 PM zack_on_the_speed_chanel wrote: > > I tried to do some testing with the code I write. I tired to test it by > making a rtems app. I modified the code from the ubuntu manpage ( here > https://manpages.ubuntu.com/manpages/bionic/man2/timer_create.2.html)so it > does not need command line arguments and my code was able to compile. When I > run the program it does not print anything. I double-checked the POSIX calls > and all were compatible with rtems. > The easiest thing to do is to modify an existing test to add new test cases, or else copy a test that is similar to what you need to do. > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Saturday, June 19th, 2021 at 6:49 PM, zack_on_the_speed_chanel > wrote: > > > I have added the tests and added the ones that create the timer. My idea > > for testing is that if I change the wall clock and I'll check the monotonic > > clock's time. But I think I have to make a signal and arm the timer. > > > > Thanks > > > > Zack > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Friday, June 18th, 2021 at 8:01 AM, Christian Mauderer > > o...@c-mauderer.de wrote: > > > > > Hello Zack, > > > > > > On 18/06/2021 04:34, zack_on_the_speed_chanel wrote: > > > > > > > so I tested it with the but I have not made a new test file I'll do > > > > that soon. How do I add a new test? All the tests that test the timer > > > > functionality do work. I"m confident that all the changes I had to made > > > > to implement a monotonic clock should be there. > > > > > > Regarding a new test: Just grep for example for psxtimer01 in the > > > > > > sources and add the new test simmilar to the existing one. > > > > > > The most relevant files are spec/build/testsuites/psxtests/*.yml for the > > > > > > waf based build system and testsuites/psxtests/Makefile.am and > > > > > > .../configure.ac for the old build system. > > > > > > But please check whether you need a new test program. If you basically > > > > > > only copy the test routine of psxtimer01 or psxtimer02 and replace all > > > > > > CLOCK_REALTIME by CLOCK_MONOTONIC then you shouldn't add a new test. > > > > > > Instead create a function in the test that is called once with > > > > > > CLOCK_REALTIME and once with CLOCK_MONOTONIC. > > > > > > Please make sure that the test not only tests the API but also whether > > > > > > the timer work as expected. A timer with CLOCK_REALTIME can be affected > > > > > > by changes in the wall clock. CLOCK_MONOTONIC should not be affected. So > > > > > > please make sure that your test checks whether that is really the case. > > > > > > Best regards > > > > > > Christian > > > > > > > Thanks > > > > > > > > Zack > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > On Tuesday, June 15th, 2021 at 7:29 AM, Christian Mauderer > > > > o...@c-mauderer.de wrote: > > > > > > > > > If you add a new functionallity you should add a test that tests the > > > > > > > > > > expected behaviour. You just shouldn't replace one but add a new test > > > > > or > > > > > > > > > > a new test case to an existing test. > > > > > > > > > > Best regards > > > > > > > > > > Christian > > > > > > > > > > On 14/06/2021 22:18, zack_on_the_speed_chanel wrote: > > > > > > > > > > > also i'll revert the posix test that I changed back to normal > > > > > > because it was only for testing. > > > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > > > On Monday, June 14th, 2021 at 8:14 PM, zack_on_the_speed_chanel > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > > > > > > > I've made most of the corrections to the code. I fixed up the > > > > > > > formatting but I still don't know if I have to add anything for > > > > > > > the settime and delete_timer(). i assume as the monotonic clock > > > > > > > only affects the value I think it's all I have to do. I also can > > > > > > > try to modify a posix test to check my theory. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Zack > > > > > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > > > > > On Saturday, June 12th, 2021 at 9:31 AM, Christian Mauderer > > > > > > > o...@c-mauderer.de wrote: > > > > > > > > > > > > > > > Hello Zack, > > > > > > > > > > > > > > > > I don't really know a lot about the timer toppic. So this is > > > > > > > > more of a > > > > > > > > > > > > > > > > style and general suggestion review. > > > > > > > > > > > > > > > > On 09/06/2021 20:27, zack wrote: > > > > > > > > > > > > > > > > > From: zack zack_on_the_speed_cha...@protonmail.ch > > > > > > > > > > > > > > > > > > cpukit/include/rtems/posix/timer.h | 6 ++- > > > > > > > > > > > > > > > > > > cpukit/posix/src/psxt
Re: [PATCH 10/10] sparc: Simplify trap table initialization
This patch set looks ok, but it touches a lot of assembly. Try to
ensure all variants have been thoroughly tested, including the
different ways to setup the FPU on sparc (lazy, hard/soft), with SMP,
and Profiling.
On Wed, Jun 23, 2021 at 12:50 AM Sebastian Huber
wrote:
>
> Move _ISR_Handler() to a separate file since it is now only used if a handler
> is installed by _CPU_ISR_install_raw_handler().
>
> Statically initialize the traps for external interrupts to use the new
> _SPARC_Interrupt_trap() which directly dispatches the interrupt handlers
> installed by rtems_interrupt_handler_install() via the BSP-provided
> _SPARC_Interrupt_dispatch().
>
> Since the trap table is now fully statically initialized, there is no longer a
> dependency on the Cache Manager in the default configuration.
>
> Update #4458.
> ---
> bsps/sparc/erc32/include/bsp.h| 6 -
> bsps/sparc/erc32/start/bspstart.c | 15 +-
> bsps/sparc/leon2/include/bsp.h| 6 -
> bsps/sparc/leon2/start/bspstart.c | 2 +-
> bsps/sparc/leon3/include/bsp.h| 6 -
> bsps/sparc/leon3/start/bspsmp.c | 24 +-
> bsps/sparc/leon3/start/bspstart.c | 34 +-
> bsps/sparc/shared/irq/bsp_isr_handler.c | 27 +-
> bsps/sparc/shared/irq/irq-shared.c| 21 -
> bsps/sparc/shared/start/start.S | 39 +-
> cpukit/Makefile.am| 1 +
> cpukit/score/cpu/sparc/cpu_asm.S | 64 +-
> .../score/cpu/sparc/include/rtems/score/cpu.h | 8 +-
> cpukit/score/cpu/sparc/sparc-isr-handler.S| 620 ++
> spec/build/cpukit/cpusparc.yml| 1 +
> 15 files changed, 704 insertions(+), 170 deletions(-)
> create mode 100644 cpukit/score/cpu/sparc/sparc-isr-handler.S
>
> diff --git a/bsps/sparc/erc32/include/bsp.h b/bsps/sparc/erc32/include/bsp.h
> index 7fb2fa9d72..fd453fb6c2 100644
> --- a/bsps/sparc/erc32/include/bsp.h
> +++ b/bsps/sparc/erc32/include/bsp.h
> @@ -95,12 +95,6 @@ void BSP_fatal_exit(uint32_t error);
> /* Interrupt Service Routine (ISR) pointer */
> typedef void (*bsp_shared_isr)(void *arg);
>
> -/* Initializes the Shared System Interrupt service */
> -extern void BSP_shared_interrupt_init(void);
> -
> -/* Called directly from IRQ trap handler TRAP[0x10..0x1F] = IRQ[0..15] */
> -void bsp_isr_handler(rtems_vector_number vector);
> -
> /* Registers a shared IRQ handler, and enable it at IRQ controller. Multiple
> * interrupt handlers may use the same IRQ number, all ISRs will be called
> * when an interrupt on that line is fired.
> diff --git a/bsps/sparc/erc32/start/bspstart.c
> b/bsps/sparc/erc32/start/bspstart.c
> index d56d3b2ff2..1979c68308 100644
> --- a/bsps/sparc/erc32/start/bspstart.c
> +++ b/bsps/sparc/erc32/start/bspstart.c
> @@ -12,22 +12,15 @@
>
> #include
> #include
> +#include
> #include
>
> /*
> - * Called just before drivers are initialized. Is used to initialize shared
> - * interrupt handling.
> + * Initialize shared interrupt handling, must be done after IRQ controller
> has
> + * been found and initialized.
> */
> -static void erc32_pre_driver_hook( void )
> -{
> - /* Initialize shared interrupt handling, must be done after IRQ
> - * controller has been found and initialized.
> - */
> - BSP_shared_interrupt_init();
> -}
> -
> RTEMS_SYSINIT_ITEM(
> - erc32_pre_driver_hook,
> + bsp_interrupt_initialize,
>RTEMS_SYSINIT_BSP_PRE_DRIVERS,
>RTEMS_SYSINIT_ORDER_MIDDLE
> );
> diff --git a/bsps/sparc/leon2/include/bsp.h b/bsps/sparc/leon2/include/bsp.h
> index bdd9c1ca70..510262206b 100644
> --- a/bsps/sparc/leon2/include/bsp.h
> +++ b/bsps/sparc/leon2/include/bsp.h
> @@ -119,12 +119,6 @@ void BSP_fatal_exit(uint32_t error);
> /* Interrupt Service Routine (ISR) pointer */
> typedef void (*bsp_shared_isr)(void *arg);
>
> -/* Initializes the Shared System Interrupt service */
> -extern void BSP_shared_interrupt_init(void);
> -
> -/* Called directly from IRQ trap handler TRAP[0x10..0x1F] = IRQ[0..15] */
> -void bsp_isr_handler(rtems_vector_number vector);
> -
> /* Registers a shared IRQ handler, and enable it at IRQ controller. Multiple
> * interrupt handlers may use the same IRQ number, all ISRs will be called
> * when an interrupt on that line is fired.
> diff --git a/bsps/sparc/leon2/start/bspstart.c
> b/bsps/sparc/leon2/start/bspstart.c
> index 8ffd0aa2e7..e90cfad5a8 100644
> --- a/bsps/sparc/leon2/start/bspstart.c
> +++ b/bsps/sparc/leon2/start/bspstart.c
> @@ -111,7 +111,7 @@ static void leon2_pre_driver_hook( void )
>/* Initialize shared interrupt handling, must be done after IRQ
> * controller has been found and initialized.
> */
> - BSP_shared_interrupt_init();
> + bsp_interrupt_initialize();
>
> #ifdef RTEMS_DRVMGR_STARTUP
>leon2_root_register(&leon2_bus_config, &leon2_amba_res);
> diff --git a/bsps/sparc/leon3/include/bsp.h b/bsps/sparc/leon3/include/bsp.h
> index 82f1f9f8ac..cb0
Re: [PATCH rtems] bsps/powerpc, bsps/shared: Move remaining legacy networking header files
On Wed, Jun 23, 2021 at 1:24 PM Joel Sherrill wrote:
>
> Assuming you built the bsps in question, I'm ok with this.
>
I tested the build and install for both the bsps involved.
> Any insight info the tftp code? Did it really need rtems_bsdnet.h?
>
It looks like, the tftp code uses the hostname and
rtems_bsdnet_bootp_server_address from the legacy stack. The
rtems_bsdnet.h has the extern declaration for it. I couldn't come up
with a clean solution to add the values to tftp code. Any suggestion?
Or we can make copies of this in each stack.
I'm planning to work on two different networking submodule
"net-services" and "net-drivers" for the common services and to expand
the driver support for each stack. This can shift to the services repo
later if we make copies of it as a temporary workaround.
> On Wed, Jun 23, 2021, 2:21 PM Vijay Kumar Banerjee wrote:
>>
>> ---
>> bsps/headers.am |3 -
>> bsps/include/grlib/greth.h| 165 --
>> bsps/include/grlib/network_interface_add.h| 47 -
>> bsps/powerpc/beatnik/headers.am |3 -
>> bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 -
>> bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 -
>> bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 -
>> bsps/shared/grlib/net/greth.c | 1663 -
>> spec/build/bsps/objgrlib.yml |2 -
>> .../build/bsps/powerpc/beatnik/bspbeatnik.yml |3 -
>> 10 files changed, 2364 deletions(-)
>> delete mode 100644 bsps/include/grlib/greth.h
>> delete mode 100644 bsps/include/grlib/network_interface_add.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
>> delete mode 100644 bsps/shared/grlib/net/greth.c
>>
>> diff --git a/bsps/headers.am b/bsps/headers.am
>> index b89e5c2b28..b5821564b1 100644
>> --- a/bsps/headers.am
>> +++ b/bsps/headers.am
>> @@ -82,7 +82,6 @@ include_grlib_HEADERS +=
>> ../../bsps/include/grlib/gradcdac.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grascs.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grcan.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grctm.h
>> -include_grlib_HEADERS += ../../bsps/include/grlib/greth.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grgpio.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/griommu.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grlib.h
>> @@ -102,7 +101,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/l2c.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/l4stat.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/mctrl.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/memscrub.h
>> -include_grlib_HEADERS += ../../bsps/include/grlib/network_interface_add.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/occan.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/pcif.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/satcan.h
>> @@ -118,7 +116,6 @@ include_libchip_HEADERS +=
>> ../../bsps/include/libchip/ata.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/ata_internal.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/disp_hcms29xx.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/ds1375-rtc.h
>> -include_libchip_HEADERS += ../../bsps/include/libchip/greth.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-2b-eeprom.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-ds1621.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-sc620.h
>> diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
>> deleted file mode 100644
>> index e7970a79f7..00
>> --- a/bsps/include/grlib/greth.h
>> +++ /dev/null
>> @@ -1,165 +0,0 @@
>> -/*
>> - * Cobham Gaisler ethernet MAC driver
>> - * adapted from Opencores driver by Marko Isomaki
>> - *
>> - * The license and distribution terms for this file may be
>> - * found in found in the file LICENSE in this distribution or at
>> - * http://www.rtems.org/license/LICENSE.
>> - */
>> -
>> -#ifndef __GRETH_H__
>> -#define __GRETH_H__
>> -
>> -#ifdef __cplusplus
>> -extern "C" {
>> -#endif
>> -
>> -/* Ethernet configuration registers */
>> -
>> -typedef struct _greth_regs {
>> - volatile uint32_t ctrl; /* Ctrl Register */
>> - volatile uint32_t status; /* Status Register */
>> - volatile uint32_t mac_addr_msb; /* Bit 47-32 of MAC address */
>> - volatile uint32_t mac_addr_lsb; /* Bit 31-0 of MAC address */
>> - volatile uint32_t mdio_ctrl;/* MDIO control and status */
>> - volatile uint32_t txdesc; /* Transmit descriptor pointer */
>> - volatile uint32_t rxdesc; /* Receive descriptor pointer */
>> - volatile uint32_t edcl; /* EDCL IP register */
>> - volatile uint32_t ht_msb; /* Multicast MSB hash */
>> - volatile
[PATCH rtems-net-legacy] bsps: Add remaining networking header files from RTEMS repository
---
bsp_drivers.py| 1 +
bsps/include/grlib/greth.h| 165 +++
bsps/include/grlib/network_interface_add.h| 47 ++
bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 +
bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 ++
bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 ++
6 files changed, 691 insertions(+)
create mode 100644 bsps/include/grlib/greth.h
create mode 100644 bsps/include/grlib/network_interface_add.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
diff --git a/bsp_drivers.py b/bsp_drivers.py
index bb31789..7d07d3d 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -72,4 +72,5 @@ def bsp_files(bld):
if bsp in special_case_sources:
source_files[bsp].extend(special_case_sources[bsp])
include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'net'))
+include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'include'))
return (include_dirs, source_files)
diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
new file mode 100644
index 000..e7970a7
--- /dev/null
+++ b/bsps/include/grlib/greth.h
@@ -0,0 +1,165 @@
+/*
+ * Cobham Gaisler ethernet MAC driver
+ * adapted from Opencores driver by Marko Isomaki
+ *
+ * The license and distribution terms for this file may be
+ * found in found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef __GRETH_H__
+#define __GRETH_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Ethernet configuration registers */
+
+typedef struct _greth_regs {
+ volatile uint32_t ctrl; /* Ctrl Register */
+ volatile uint32_t status; /* Status Register */
+ volatile uint32_t mac_addr_msb; /* Bit 47-32 of MAC address */
+ volatile uint32_t mac_addr_lsb; /* Bit 31-0 of MAC address */
+ volatile uint32_t mdio_ctrl;/* MDIO control and status */
+ volatile uint32_t txdesc; /* Transmit descriptor pointer */
+ volatile uint32_t rxdesc; /* Receive descriptor pointer */
+ volatile uint32_t edcl; /* EDCL IP register */
+ volatile uint32_t ht_msb; /* Multicast MSB hash */
+ volatile uint32_t ht_lsb; /* Multicast LSB hash */
+} greth_regs;
+
+#define GRETH_TOTAL_BD 128
+#define GRETH_MAXBUF_LEN 1520
+
+/* Tx BD */
+#define GRETH_TXD_ENABLE 0x0800 /* Tx BD Enable */
+#define GRETH_TXD_WRAP0x1000 /* Tx BD Wrap (last BD) */
+#define GRETH_TXD_IRQ 0x2000 /* Tx BD IRQ Enable */
+#define GRETH_TXD_MORE0x2 /* Tx BD More (more descs for packet) */
+#define GRETH_TXD_IPCS0x4 /* Tx BD insert ip chksum */
+#define GRETH_TXD_TCPCS 0x8 /* Tx BD insert tcp chksum */
+#define GRETH_TXD_UDPCS 0x10 /* Tx BD insert udp chksum */
+
+#define GRETH_TXD_UNDERRUN0x4000 /* Tx BD Underrun Status */
+#define GRETH_TXD_RETLIM 0x8000 /* Tx BD Retransmission Limit Status */
+#define GRETH_TXD_LATECOL 0x1 /* Tx BD Late Collision */
+
+#define GRETH_TXD_STATS (GRETH_TXD_UNDERRUN| \
+ GRETH_TXD_RETLIM | \
+ GRETH_TXD_LATECOL)
+
+#define GRETH_TXD_CS (GRETH_TXD_IPCS| \
+ GRETH_TXD_TCPCS | \
+ GRETH_TXD_UDPCS)
+
+/* Rx BD */
+#define GRETH_RXD_ENABLE 0x0800 /* Rx BD Enable */
+#define GRETH_RXD_WRAP0x1000 /* Rx BD Wrap (last BD) */
+#define GRETH_RXD_IRQ 0x2000 /* Rx BD IRQ Enable */
+
+#define GRETH_RXD_DRIBBLE 0x4000 /* Rx BD Dribble Nibble Status */
+#define GRETH_RXD_TOOLONG 0x8000 /* Rx BD Too Long Status */
+#define GRETH_RXD_CRCERR 0x1 /* Rx BD CRC Error Status */
+#define GRETH_RXD_OVERRUN 0x2 /* Rx BD Overrun Status */
+#define GRETH_RXD_LENERR 0x4 /* Rx BD Length Error */
+#define GRETH_RXD_ID 0x4 /* Rx BD IP Detected */
+#define GRETH_RXD_IR 0x4 /* Rx BD IP Chksum Error */
+#define GRETH_RXD_UD 0x4 /* Rx BD UDP Detected*/
+#define GRETH_RXD_UR 0x4 /* Rx BD UDP Chksum Error */
+#define GRETH_RXD_TD 0x4 /* Rx BD TCP Detected */
+#define GRETH_RXD_TR 0x4 /* Rx BD TCP Chksum Error */
+
+
+#define GRETH_RXD_STATS (GRETH_RXD_OVERRUN | \
+ GRETH_RXD_DRIBBLE | \
+ GRETH_RXD_TOOLONG | \
+ GRETH_RXD_CRCERR)
+
+/* CTRL Register */
+#define GRETH_CTRL_TXEN 0x0001 /* Transmit Enable */
+#define GRETH_CTRL_RXEN
[PATCH rtems] bsps/powerpc, bsps/shared: Move remaining legacy networking header files
---
bsps/headers.am |3 -
bsps/include/grlib/greth.h| 165 --
bsps/include/grlib/network_interface_add.h| 47 -
bsps/powerpc/beatnik/headers.am |3 -
bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 -
bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 -
bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 -
bsps/shared/grlib/net/greth.c | 1663 -
spec/build/bsps/objgrlib.yml |2 -
.../build/bsps/powerpc/beatnik/bspbeatnik.yml |3 -
10 files changed, 2364 deletions(-)
delete mode 100644 bsps/include/grlib/greth.h
delete mode 100644 bsps/include/grlib/network_interface_add.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
delete mode 100644 bsps/shared/grlib/net/greth.c
diff --git a/bsps/headers.am b/bsps/headers.am
index b89e5c2b28..b5821564b1 100644
--- a/bsps/headers.am
+++ b/bsps/headers.am
@@ -82,7 +82,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/gradcdac.h
include_grlib_HEADERS += ../../bsps/include/grlib/grascs.h
include_grlib_HEADERS += ../../bsps/include/grlib/grcan.h
include_grlib_HEADERS += ../../bsps/include/grlib/grctm.h
-include_grlib_HEADERS += ../../bsps/include/grlib/greth.h
include_grlib_HEADERS += ../../bsps/include/grlib/grgpio.h
include_grlib_HEADERS += ../../bsps/include/grlib/griommu.h
include_grlib_HEADERS += ../../bsps/include/grlib/grlib.h
@@ -102,7 +101,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/l2c.h
include_grlib_HEADERS += ../../bsps/include/grlib/l4stat.h
include_grlib_HEADERS += ../../bsps/include/grlib/mctrl.h
include_grlib_HEADERS += ../../bsps/include/grlib/memscrub.h
-include_grlib_HEADERS += ../../bsps/include/grlib/network_interface_add.h
include_grlib_HEADERS += ../../bsps/include/grlib/occan.h
include_grlib_HEADERS += ../../bsps/include/grlib/pcif.h
include_grlib_HEADERS += ../../bsps/include/grlib/satcan.h
@@ -118,7 +116,6 @@ include_libchip_HEADERS += ../../bsps/include/libchip/ata.h
include_libchip_HEADERS += ../../bsps/include/libchip/ata_internal.h
include_libchip_HEADERS += ../../bsps/include/libchip/disp_hcms29xx.h
include_libchip_HEADERS += ../../bsps/include/libchip/ds1375-rtc.h
-include_libchip_HEADERS += ../../bsps/include/libchip/greth.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-2b-eeprom.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-ds1621.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-sc620.h
diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
deleted file mode 100644
index e7970a79f7..00
--- a/bsps/include/grlib/greth.h
+++ /dev/null
@@ -1,165 +0,0 @@
-/*
- * Cobham Gaisler ethernet MAC driver
- * adapted from Opencores driver by Marko Isomaki
- *
- * The license and distribution terms for this file may be
- * found in found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef __GRETH_H__
-#define __GRETH_H__
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/* Ethernet configuration registers */
-
-typedef struct _greth_regs {
- volatile uint32_t ctrl; /* Ctrl Register */
- volatile uint32_t status; /* Status Register */
- volatile uint32_t mac_addr_msb; /* Bit 47-32 of MAC address */
- volatile uint32_t mac_addr_lsb; /* Bit 31-0 of MAC address */
- volatile uint32_t mdio_ctrl;/* MDIO control and status */
- volatile uint32_t txdesc; /* Transmit descriptor pointer */
- volatile uint32_t rxdesc; /* Receive descriptor pointer */
- volatile uint32_t edcl; /* EDCL IP register */
- volatile uint32_t ht_msb; /* Multicast MSB hash */
- volatile uint32_t ht_lsb; /* Multicast LSB hash */
-} greth_regs;
-
-#define GRETH_TOTAL_BD 128
-#define GRETH_MAXBUF_LEN 1520
-
-/* Tx BD */
-#define GRETH_TXD_ENABLE 0x0800 /* Tx BD Enable */
-#define GRETH_TXD_WRAP0x1000 /* Tx BD Wrap (last BD) */
-#define GRETH_TXD_IRQ 0x2000 /* Tx BD IRQ Enable */
-#define GRETH_TXD_MORE0x2 /* Tx BD More (more descs for packet) */
-#define GRETH_TXD_IPCS0x4 /* Tx BD insert ip chksum */
-#define GRETH_TXD_TCPCS 0x8 /* Tx BD insert tcp chksum */
-#define GRETH_TXD_UDPCS 0x10 /* Tx BD insert udp chksum */
-
-#define GRETH_TXD_UNDERRUN0x4000 /* Tx BD Underrun Status */
-#define GRETH_TXD_RETLIM 0x8000 /* Tx BD Retransmission Limit Status */
-#define GRETH_TXD_LATECOL 0x1 /* Tx BD Late Collision */
-
-#define GRETH_TXD_STATS (GRETH_TXD_UNDERRUN| \
- GRETH_TXD_RETLIM | \
- GRETH_TXD_LATECOL)
-
-#define GRETH_TXD_CS (GRETH_TXD_IP
Re: [PATCH v2 12/12] bsp/atsam: Fix BSP_INTERRUPT_VECTOR_COUNT
On 23/06/2021 18:10, Gedare Bloom wrote: I'm good with the patch set. Thanks for the review. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 09/12] bsps/irq: Use BSP_INTERRUPT_VECTOR_COUNT
On 23/06/2021 18:07, Gedare Bloom wrote:
diff --git a/bsps/m68k/genmcf548x/irq/irq.c b/bsps/m68k/genmcf548x/irq/irq.c
index d010865152..547e851cdd 100644
--- a/bsps/m68k/genmcf548x/irq/irq.c
+++ b/bsps/m68k/genmcf548x/irq/irq.c
@@ -19,7 +19,7 @@
static inline bool is_valid_vector(rtems_vector_number vector)
{
return 1 <= vector
-&& vector <= (rtems_vector_number) BSP_INTERRUPT_VECTOR_MAX;
+&& vector < (rtems_vector_number) BSP_INTERRUPT_VECTOR_COUNT;
}
This one is weird. I don't know if there's an elegant solution though.
The "BSP_INTERRUPT_VECTOR_COUNT" isn't actually the number of vectors
in this BSP, since 0 is not a valid vector. However, I'm ok because
BSP_INTERRUPT_VECTOR_COUNT is an upper bound on the number of vectors.
Probably, this point needs to be documented carefully at least for
this particular BSP.
This irq.c of this BSP is already not an elegant solution. I had to add
this hacked together glue layer to be able to use the interrupt server
for libbsd support. There is no functional change for this BSP.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 06/12] smpcapture02: Fix use of BSP_INTERRUPT_VECTOR_MAX
On 23/06/2021 18:10, Gedare Bloom wrote: Is this bug worth fixing on 5? It is not really a severe bug. The function would return an error for an invalid vector number which is ignored by the test. My guess is not worthwhile. Yes. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 03/10] score: Move _ISR_Vector_table[] to separate file
On 23/06/2021 18:59, Gedare Bloom wrote: +#if (CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE) + ISR_Handler_entry _ISR_Vector_table[ CPU_INTERRUPT_NUMBER_OF_VECTORS ]; +#elif defined(CPU_INTERRUPT_NUMBER_OF_VECTORS) Do we want to change this to _VECTOR_COUNT to be consistent with the other patch set/API? Yes, changing this to CPU_INTERRUPT_VECTOR_COUNT or CPU_SIMPLE_INTERRUPT_VECTOR_COUNT would be an option. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 04/10] bsps/sparc: Add a symbol for each trap table entry
On 23/06/2021 19:06, Gedare Bloom wrote: + BAD_TRAP(0x0f)! 0F undefined + BAD_TRAP(0x10)! 10 undefined This code could be simplified using assembly macros (.irp) something like what I did in bsps/sparc64/shared/start/trap_table.S .irp idx, 0x07, 0x08, 0x10 BAD_TRAP(\idx) .endr For loops are definitely missing in the C preprocessor. Not necessary to do, but came to my mind. Perhaps, keeping them broken out makes it easier to document with comments. Yes, next time it could save some editing time. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 04/10] bsps/sparc: Add a symbol for each trap table entry
On Wed, Jun 23, 2021 at 12:49 AM Sebastian Huber wrote: > > This makes it easier to review start.o and set break points to trap table > entries. This change was checked by inspecting the trap table in start.o with > objdump. > > Update #4458. > --- > bsps/sparc/shared/start/start.S | 359 +++- > 1 file changed, 264 insertions(+), 95 deletions(-) > > diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S > index 13c3cffc00..9bdc752fa2 100644 > --- a/bsps/sparc/shared/start/start.S > +++ b/bsps/sparc/shared/start/start.S > @@ -23,10 +23,13 @@ >#define START_LEON3_ENABLE_SMP > #endif > > +#define TRAP_SYM(_vector) SYM(trap_##_vector) > + > /* > * Unexpected trap will halt the processor by forcing it to error state > */ > -#define BAD_TRAP \ > +#define BAD_TRAP(_vector) \ > + TRAP_SYM(_vector):; \ >ta 0; \ >nop; \ >nop; \ > @@ -81,7 +84,7 @@ > * Software trap. Treat as BAD_TRAP for the time being... > */ > > -#define SOFT_TRAP BAD_TRAP > +#define SOFT_TRAP(_vector) BAD_TRAP(_vector) > >.section".text" >PUBLIC(start) > @@ -105,73 +108,143 @@ start: > SYM(trap_table): > >RTRAP( 0, SYM(hard_reset) ); ! 00 reset trap > - BAD_TRAP; ! 01 instruction access > + BAD_TRAP(0x01)! 01 instruction access > !exception > - BAD_TRAP; ! 02 illegal instruction > - BAD_TRAP; ! 03 privileged instruction > + BAD_TRAP(0x02)! 02 illegal instruction > + BAD_TRAP(0x03)! 03 privileged instruction > #if defined(SPARC_USE_LAZY_FP_SWITCH) > +TRAP_SYM(0x04): >FPDIS_TRAP(SYM(syscall_lazy_fp_switch)); ! 04 fp disabled > #else > - BAD_TRAP; ! 04 fp disabled > + BAD_TRAP(0x04)! 04 fp disabled > #endif > +TRAP_SYM(0x05): >WOTRAP(5, SYM(window_overflow_trap_handler)); ! 05 window overflow > +TRAP_SYM(0x06): >WUTRAP(6, SYM(window_underflow_trap_handler));! 06 window underflow > - BAD_TRAP; ! 07 memory address not > aligned > - BAD_TRAP; ! 08 fp exception > - BAD_TRAP; ! 09 data access exception > - BAD_TRAP; ! 0A tag overflow > - BAD_TRAP; ! 0B undefined > - BAD_TRAP; ! 0C undefined > - BAD_TRAP; ! 0D undefined > - BAD_TRAP; ! 0E undefined > - BAD_TRAP; ! 0F undefined > - BAD_TRAP; ! 10 undefined > + BAD_TRAP(0x07)! 07 memory address not > aligned > + BAD_TRAP(0x08)! 08 fp exception > + BAD_TRAP(0x09)! 09 data access exception > + BAD_TRAP(0x0a)! 0A tag overflow > + BAD_TRAP(0x0b)! 0B undefined > + BAD_TRAP(0x0c)! 0C undefined > + BAD_TRAP(0x0d)! 0D undefined > + BAD_TRAP(0x0e)! 0E undefined > + BAD_TRAP(0x0f)! 0F undefined > + BAD_TRAP(0x10)! 10 undefined > This code could be simplified using assembly macros (.irp) something like what I did in bsps/sparc64/shared/start/trap_table.S .irp idx, 0x07, 0x08, 0x10 BAD_TRAP(\idx) .endr Not necessary to do, but came to my mind. Perhaps, keeping them broken out makes it easier to document with comments. >/* > - * ERC32 defined traps > + * External interrupt traps > */ > > - BAD_TRAP; ! 11 masked errors > - BAD_TRAP; ! 12 external 1 > - BAD_TRAP; ! 13 external 2 > - BAD_TRAP; ! 14 UART A RX/TX > - BAD_TRAP; ! 15 UART B RX/TX > - BAD_TRAP; ! 16 correctable memory error > - BAD_TRAP; ! 17 UART error > - BAD_TRAP; ! 18 DMA access error > - BAD_TRAP; ! 19 DMA timeout > - BAD_TRAP; ! 1A external 3 > - BAD_TRAP; ! 1B external 4 > - BAD_TRAP; ! 1C general purpose timer > - BAD_TRAP; ! 1D real time clock > - BAD_TRAP; ! 1E external
Re: [PATCH 03/10] score: Move _ISR_Vector_table[] to separate file
On Wed, Jun 23, 2021 at 12:49 AM Sebastian Huber
wrote:
>
> The _ISR_Handler_initialization() does not touch the _ISR_Vector_table[].
> Move
> the definition of _ISR_Vector_table[] to a separate file.
>
> Change license to BSD-2-Clause according to file history and re-licensing
> agreement.
>
> Update #3053.
> ---
> cpukit/Makefile.am| 1 +
> cpukit/score/src/isr.c| 8 --
> cpukit/score/src/isrvectortable.c | 48 +++
> spec/build/cpukit/librtemscpu.yml | 1 +
> 4 files changed, 50 insertions(+), 8 deletions(-)
> create mode 100644 cpukit/score/src/isrvectortable.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index df970e5a1c..25382f38ca 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -1023,6 +1023,7 @@ librtemscpu_a_SOURCES += score/src/chainnodecount.c
> librtemscpu_a_SOURCES += score/src/debugisthreaddispatchingallowed.c
> librtemscpu_a_SOURCES += score/src/interr.c
> librtemscpu_a_SOURCES += score/src/isr.c
> +librtemscpu_a_SOURCES += score/src/isrvectortable.c
> librtemscpu_a_SOURCES += score/src/wkspace.c
> librtemscpu_a_SOURCES += score/src/wkspaceisunifieddefault.c
> librtemscpu_a_SOURCES += score/src/wkspacemallocinitdefault.c
> diff --git a/cpukit/score/src/isr.c b/cpukit/score/src/isr.c
> index 28a6b3082e..b77f682663 100644
> --- a/cpukit/score/src/isr.c
> +++ b/cpukit/score/src/isr.c
> @@ -25,14 +25,6 @@
> #include
> #include
>
> -#if (CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE)
> - ISR_Handler_entry _ISR_Vector_table[ CPU_INTERRUPT_NUMBER_OF_VECTORS ];
> -#elif defined(CPU_INTERRUPT_NUMBER_OF_VECTORS)
> - #error "CPU_INTERRUPT_NUMBER_OF_VECTORS is defined for non-simple vectored
> interrupts"
> -#elif defined(CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER)
> - #error "CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER is defined for non-simple
> vectored interrupts"
> -#endif
> -
> void _ISR_Handler_initialization( void )
> {
>uint32_t cpu_max;
> diff --git a/cpukit/score/src/isrvectortable.c
> b/cpukit/score/src/isrvectortable.c
> new file mode 100644
> index 00..4bd892757e
> --- /dev/null
> +++ b/cpukit/score/src/isrvectortable.c
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreISR
> + *
> + * @brief This source file contains the definition of ::_ISR_Vector_table.
> + */
> +
> +/*
> + * Copyright (C) 2014 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include
> +
> +#if (CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE)
> + ISR_Handler_entry _ISR_Vector_table[ CPU_INTERRUPT_NUMBER_OF_VECTORS ];
> +#elif defined(CPU_INTERRUPT_NUMBER_OF_VECTORS)
Do we want to change this to _VECTOR_COUNT to be consistent with the
other patch set/API?
> + #error "CPU_INTERRUPT_NUMBER_OF_VECTORS is defined for non-simple vectored
> interrupts"
> +#elif defined(CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER)
> + #error "CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER is defined for non-simple
> vectored interrupts"
> +#endif
> diff --git a/spec/build/cpukit/librtemscpu.yml
> b/spec/build/cpukit/librtemscpu.yml
> index e3f328ec5f..0abff9d439 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -1417,6 +1417,7 @@ source:
> - cpukit/score/src/iovprintf.c
> - cpukit/score/src/isr.c
> - cpukit/score/src/isrisinprogress.c
> +- cpukit/score/src/isrvectortable.c
> - cpukit/score/src/iterateoverthreads.c
> - cpukit/score/src/kern_tc.c
> - cpukit/score/src/libatomic.c
> --
> 2.26.2
>
> _
Re: [PATCH v2 06/12] smpcapture02: Fix use of BSP_INTERRUPT_VECTOR_MAX
Is this bug worth fixing on 5?
My guess is not worthwhile.
On Sat, Jun 19, 2021 at 8:05 AM Sebastian Huber
wrote:
>
> This define represents the last valid interrupt vector number.
>
> Update #3269.
> ---
> testsuites/smptests/smpcapture02/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testsuites/smptests/smpcapture02/init.c
> b/testsuites/smptests/smpcapture02/init.c
> index 9cf1f0b006..329fd344e6 100644
> --- a/testsuites/smptests/smpcapture02/init.c
> +++ b/testsuites/smptests/smpcapture02/init.c
> @@ -316,7 +316,7 @@ static void Init(rtems_task_argument arg)
>test(cpu_count);
>
>/* Try to find the clock interrupt handler */
> - for ( vec = 0; vec < BSP_INTERRUPT_VECTOR_MAX; vec++ ) {
> + for ( vec = 0; vec <= BSP_INTERRUPT_VECTOR_MAX; vec++ ) {
> rtems_interrupt_handler_iterate(vec, locate_clock_interrupt_handler,
> &cih);
> if ( cih.found )
>break;
> --
> 2.26.2
>
> ___
> 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 v2 12/12] bsp/atsam: Fix BSP_INTERRUPT_VECTOR_COUNT
I'm good with the patch set. On Sat, Jun 19, 2021 at 8:05 AM Sebastian Huber wrote: > > Fix an off by one error. > > Update #3269. > --- > bsps/arm/atsam/include/bsp/irq.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bsps/arm/atsam/include/bsp/irq.h > b/bsps/arm/atsam/include/bsp/irq.h > index fa3d56ab1e..e788570469 100644 > --- a/bsps/arm/atsam/include/bsp/irq.h > +++ b/bsps/arm/atsam/include/bsp/irq.h > @@ -23,6 +23,6 @@ >#include > #endif > > -#define BSP_INTERRUPT_VECTOR_COUNT 65 > +#define BSP_INTERRUPT_VECTOR_COUNT 64 > > #endif /* LIBBSP_ARM_ATSAM_ESV_70_IRQ_H */ > -- > 2.26.2 > > ___ > 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 v2 09/12] bsps/irq: Use BSP_INTERRUPT_VECTOR_COUNT
On Sat, Jun 19, 2021 at 8:05 AM Sebastian Huber
wrote:
>
> Use BSP_INTERRUPT_VECTOR_COUNT instead of BSP_INTERRUPT_VECTOR_MAX.
>
> Update #3269.
> ---
> bsps/arm/atsam/start/bspstart.c | 2 +-
> bsps/arm/beagle/irq/irq.c | 2 +-
> bsps/arm/lpc176x/irq/irq.c | 2 +-
> bsps/arm/lpc24xx/irq/irq.c | 4 ++--
> bsps/arm/lpc32xx/include/bsp/irq.h | 2 +-
> bsps/arm/shared/irq/irq-armv7m.c| 2 +-
> bsps/arm/shared/start/start.S | 2 +-
> bsps/arm/tms570/irq/irq.c | 2 +-
> bsps/include/bsp/irq-generic.h | 8
> bsps/m68k/genmcf548x/irq/irq.c | 4 ++--
> bsps/mips/shared/irq/irq.c | 2 +-
> bsps/powerpc/qoriq/irq/irq.c| 6 +++---
> bsps/shared/irq/irq-info.c | 2 +-
> bsps/shared/irq/irq-server.c| 2 +-
> testsuites/smptests/smpcapture02/init.c | 2 +-
> 15 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/bsps/arm/atsam/start/bspstart.c b/bsps/arm/atsam/start/bspstart.c
> index b463bab696..3f49779797 100644
> --- a/bsps/arm/atsam/start/bspstart.c
> +++ b/bsps/arm/atsam/start/bspstart.c
> @@ -21,7 +21,7 @@
> #include
>
> RTEMS_STATIC_ASSERT(
> - PERIPH_COUNT_IRQn <= BSP_INTERRUPT_VECTOR_MAX,
> + PERIPH_COUNT_IRQn <= BSP_INTERRUPT_VECTOR_COUNT,
>PERIPH_COUNT_IRQn
> );
>
> diff --git a/bsps/arm/beagle/irq/irq.c b/bsps/arm/beagle/irq/irq.c
> index 721703b87b..8e9294cae9 100644
> --- a/bsps/arm/beagle/irq/irq.c
> +++ b/bsps/arm/beagle/irq/irq.c
> @@ -133,7 +133,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
>}
>
>/* Mask all interrupts */
> - for(i = 0; i <= BSP_INTERRUPT_VECTOR_MAX; i++)
> + for(i = 0; i < BSP_INTERRUPT_VECTOR_COUNT; i++)
> bsp_interrupt_vector_disable(i);
>
>/* Install generic interrupt handler */
> diff --git a/bsps/arm/lpc176x/irq/irq.c b/bsps/arm/lpc176x/irq/irq.c
> index e05fd59e6c..a060401d0b 100644
> --- a/bsps/arm/lpc176x/irq/irq.c
> +++ b/bsps/arm/lpc176x/irq/irq.c
> @@ -38,7 +38,7 @@
> */
> static inline bool lpc176x_irq_is_valid( const rtems_vector_number vector )
> {
> - return vector <= BSP_INTERRUPT_VECTOR_MAX;
> + return vector < BSP_INTERRUPT_VECTOR_COUNT;
> }
>
> void lpc176x_irq_set_priority(
> diff --git a/bsps/arm/lpc24xx/irq/irq.c b/bsps/arm/lpc24xx/irq/irq.c
> index 2fed80efda..ed07805a9a 100644
> --- a/bsps/arm/lpc24xx/irq/irq.c
> +++ b/bsps/arm/lpc24xx/irq/irq.c
> @@ -31,7 +31,7 @@
>
> static inline bool lpc24xx_irq_is_valid(rtems_vector_number vector)
> {
> - return vector <= BSP_INTERRUPT_VECTOR_MAX;
> + return vector < BSP_INTERRUPT_VECTOR_COUNT;
> }
>
> void lpc24xx_irq_set_priority(rtems_vector_number vector, unsigned priority)
> @@ -91,7 +91,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
>/* Use IRQ category */
>VICIntSelect = 0;
>
> - for (i = 0; i <= BSP_INTERRUPT_VECTOR_MAX; ++i) {
> + for (i = 0; i < BSP_INTERRUPT_VECTOR_COUNT; ++i) {
> /* Use the vector address register to store the vector number */
> addr [i] = i;
>
> diff --git a/bsps/arm/lpc32xx/include/bsp/irq.h
> b/bsps/arm/lpc32xx/include/bsp/irq.h
> index d6f7e3144e..02fce3258a 100644
> --- a/bsps/arm/lpc32xx/include/bsp/irq.h
> +++ b/bsps/arm/lpc32xx/include/bsp/irq.h
> @@ -142,7 +142,7 @@ extern "C" {
> #define BSP_INTERRUPT_VECTOR_MAX LPC32XX_IRQ_SYSCLK
> #define BSP_INTERRUPT_VECTOR_COUNT (LPC32XX_IRQ_SYSCLK + 1)
>
> -#define LPC32XX_IRQ_COUNT (BSP_INTERRUPT_VECTOR_MAX + 1)
> +#define LPC32XX_IRQ_COUNT BSP_INTERRUPT_VECTOR_COUNT
>
> void lpc32xx_irq_set_priority(rtems_vector_number vector, unsigned priority);
>
> diff --git a/bsps/arm/shared/irq/irq-armv7m.c
> b/bsps/arm/shared/irq/irq-armv7m.c
> index 7c7c1ab114..2bf8c9df74 100644
> --- a/bsps/arm/shared/irq/irq-armv7m.c
> +++ b/bsps/arm/shared/irq/irq-armv7m.c
> @@ -67,7 +67,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
>
>_ARMV7M_SCB->icsr = ARMV7M_SCB_ICSR_PENDSVCLR | ARMV7M_SCB_ICSR_PENDSTCLR;
>
> - for (i = 0; i <= BSP_INTERRUPT_VECTOR_MAX; ++i) {
> + for (i = 0; i < BSP_INTERRUPT_VECTOR_COUNT; ++i) {
> _ARMV7M_NVIC_Clear_enable(i);
> _ARMV7M_NVIC_Clear_pending(i);
> _ARMV7M_NVIC_Set_priority(i, BSP_ARMV7M_IRQ_PRIORITY_DEFAULT);
> diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
> index bd623178ed..698495d32e 100644
> --- a/bsps/arm/shared/start/start.S
> +++ b/bsps/arm/shared/start/start.S
> @@ -529,7 +529,7 @@ bsp_start_vector_table_begin:
> .word _ARMV7M_Exception_default /* Reserved */
> .word _ARMV7M_Pendable_service_call /* PendSV */
> .word _ARMV7M_Clock_handler /* SysTick */
> - .rept BSP_INTERRUPT_VECTOR_MAX + 1
> + .rept BSP_INTERRUPT_VECTOR_COUNT
> .word _ARMV7M_NVIC_Interrupt_dispatch /* IRQ */
> .endr
>
> diff --git a/bsps/arm/tms570/irq/irq.c b/bsps/arm/tms570/irq/irq.c
> index 7129915c93..4abab8feb3 100644
> --- a/bsps/arm/tms570/irq/ir
Re: BBB hello does not run...
Hello Chris, Am 23.06.21 um 10:41 schrieb Chris Johns: Hi Christian, Thanks for the reply. My uboot SD card does not have any FDT blobs so this is the reason for the failure. We seem to now have a dependency on an FDT. I have played a bit and found the cause of the error: https://git.rtems.org/rtems/tree/bsps/shared/ofw/ofw.c#n86 I have no problem with the FDT being used in RTEMS but I do have some concerns about how we handle things. A hard error here is a bit abrupt and maybe just not having the drivers installed and available would be a better solution. An app will fail when the driver does not exist. On the other hand a hard error is fine if we packaged the FDT blob in the executable, something we currently do not do. The big advantage of the FDT is that we can support multiple Beagle variants without problems. Big disadvantage is that we need the FDT. With the current direction, sooner or later (or maybe already implemented) the BSP will also get the information for the serial interface from the FDT. As soon as that happens, it won't be really possible to start a useful application without the FDT. What would be alternative approaches? We could continue to add special cases in the code for variants. Or we could basically write a similar source of information like the FDT. In that case most likely it would be the better idea to write a minimal FDT that is linked into the BSP. I think we should consider the single executable approach to handling FDT blobs, that is embedding the blob into RTEMS. This is not something we can reach in a simple single step plus we have the licensing issue but I feel we can make it happen. It's really quite easy to embedd a DTB into the executables. Difficult part is compiling the FDT to a DTB. After that it's only using rtems_bin2c to convert it into a c file and return a pointer to that array in bsp_fdt_get(). Disadvantage (beneath licensing) of a FDT blob in the binary is that the binary then is fixed for one beagle variant. If the FDT is separate, the same binary works for pocketbeagle or BBB. But that's only a small disadvantage. It only means that we need more variants. The first step I am looking at is the building of the FDT source with includes. A command in the rtems-tool that is installed would be a good first step. The FreeBSD script is a good base but it is all a bit awkward to get to and use. I agree that this would be a great improvement. We could use that kind of tool regardless what solution we find. I think the big problem with FDTs is that they can have difficult licenses. GPL is the most prominent example and it's the case for a lot of FDTs based on the Linux sources. But it could also be a blob with some odd vendor license generated by some toolchain (for example for FPGA / CPU combo chips like Zynq). Possible approaches are: 1) Do something similar like FreeBSD: Add a "GPL" or maybe rather a "other licenses" subdirectory to RTEMS and collect FDTs there. We could put a defined FreeBSD FDT export, special blobs or similar into that directory. A BSP can then generate (for example with your planned tool) the matching blob from these sources and provide it as a separate file in the default case. Alternatively a BSP option with a clear name (like "BSP_I_WANT_TO_INTEGRATE_GPL_LICENSED_FDT_BLOB_INTO_THE_BINARY") could link it directly into the binary. 2) Keep the FDTs with odd licenses in a separate repo or on an FTP. That won't allow to link them into the binaries but it would keep the tree clean of other licenses. From my point of view, the first one would be an OK solution - at least if no one finds a better one. It would need a good structure and a good idea how to make it absolutely clear that the code is not RTEMS licensed. Beneath that it would need clear rules that it is _only_ for FDT so that we avoid getting other non-RTEMS-licensed code there too. But it should be somehow possible and it would simplify the handling for the user. Best regards Christian Chris On 23/6/21 5:10 pm, Christian Mauderer wrote: Hello Chris, there is no new requirement that I know of. The driver should parse the same FDT fields that have been parsed by libbsd earlier. It only want's to avoid the double initialization that had been done by RTEMS and libbsd. But there is a simple method how we can find out whether it's FDT related: Please try the dtb that I normally use: https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf That FDT is build from the FreeBSD sources from that revision: https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418 Note: I don't think that using that FDT is a solution. It's just to find out whether it's the problem. A solution would be to find a method how we can distribute matching FDTs with various licenses. Best regards Christian On 23/06/2021 07:24, Chris Johns wrote: I have bisect'ed the failure and this is the commit that is th
Re: BBB hello does not run...
Hi Christian, Thanks for the reply. My uboot SD card does not have any FDT blobs so this is the reason for the failure. We seem to now have a dependency on an FDT. I have played a bit and found the cause of the error: https://git.rtems.org/rtems/tree/bsps/shared/ofw/ofw.c#n86 I have no problem with the FDT being used in RTEMS but I do have some concerns about how we handle things. A hard error here is a bit abrupt and maybe just not having the drivers installed and available would be a better solution. An app will fail when the driver does not exist. On the other hand a hard error is fine if we packaged the FDT blob in the executable, something we currently do not do. I think we should consider the single executable approach to handling FDT blobs, that is embedding the blob into RTEMS. This is not something we can reach in a simple single step plus we have the licensing issue but I feel we can make it happen. The first step I am looking at is the building of the FDT source with includes. A command in the rtems-tool that is installed would be a good first step. The FreeBSD script is a good base but it is all a bit awkward to get to and use. Chris On 23/6/21 5:10 pm, Christian Mauderer wrote: > Hello Chris, > > there is no new requirement that I know of. The driver should parse the same > FDT > fields that have been parsed by libbsd earlier. It only want's to avoid the > double initialization that had been done by RTEMS and libbsd. > > But there is a simple method how we can find out whether it's FDT related: > Please try the dtb that I normally use: > > https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf > > That FDT is build from the FreeBSD sources from that revision: > > > https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418 > > > Note: I don't think that using that FDT is a solution. It's just to find out > whether it's the problem. A solution would be to find a method how we can > distribute matching FDTs with various licenses. > > Best regards > > Christian > > On 23/06/2021 07:24, Chris Johns wrote: >> I have bisect'ed the failure and this is the commit that is the problem: >> >> https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0 >> >> Hm Is there a new requirement on the needed FDT for a >> beagleboneblack. >> >> Chris >> >> >> On 23/6/21 2:52 pm, Chris Johns wrote: >>> Hi, >>> >>> hello.exe is not running. Any hints? >>> >>> master at ... >>> >>> https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d >>> >>> config.ini: >>> [DEFAULT] >>> BUILD_TESTS = False >>> RTEMS_DEBUG = True >>> RTEMS_POSIX_API = True >>> >>> [arm/beagleboneblack] >>> BUILD_TESTS = True >>> >>> output: >>> >>> RTEMS Beagleboard: am335x-based >>> ARM Debug: 0x4b141000 >>> >>> *** FATAL *** >>> fatal source: 1 (INTERNAL_ERROR_RTEMS_API) >>> fatal code: 22 (0x0016) >>> RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73 >>> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB >>> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) >>> executing thread ID: 0x089010001 >>> executing thread name: IDLE >>> >>> Chris >>> ___ >>> 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: BBB hello does not run...
Hello Chris, there is no new requirement that I know of. The driver should parse the same FDT fields that have been parsed by libbsd earlier. It only want's to avoid the double initialization that had been done by RTEMS and libbsd. But there is a simple method how we can find out whether it's FDT related: Please try the dtb that I normally use: https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf That FDT is build from the FreeBSD sources from that revision: https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418 Note: I don't think that using that FDT is a solution. It's just to find out whether it's the problem. A solution would be to find a method how we can distribute matching FDTs with various licenses. Best regards Christian On 23/06/2021 07:24, Chris Johns wrote: I have bisect'ed the failure and this is the commit that is the problem: https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0 Hm Is there a new requirement on the needed FDT for a beagleboneblack. Chris On 23/6/21 2:52 pm, Chris Johns wrote: Hi, hello.exe is not running. Any hints? master at ... https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d config.ini: [DEFAULT] BUILD_TESTS = False RTEMS_DEBUG = True RTEMS_POSIX_API = True [arm/beagleboneblack] BUILD_TESTS = True output: RTEMS Beagleboard: am335x-based ARM Debug: 0x4b141000 *** FATAL *** fatal source: 1 (INTERNAL_ERROR_RTEMS_API) fatal code: 22 (0x0016) RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73 RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) executing thread ID: 0x089010001 executing thread name: IDLE Chris ___ 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
