GSOC: GSOC2024_Yang_Adding SPI and Watchdog support to Raspberry Pi 4B BSP
I've prepared a draft for my proposal. Please let me know how I could improve it. Thank you in advance. https://docs.google.com/document/d/1NjlUSWhqwUvrsQPBISU05ah0I0IGkEuq6BIThrkMBsg/edit___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/6] build: Add support to make bootloader images
On 07.03.24 02:09, Chris Johns wrote: On 6/3/2024 8:33 am, Gedare Bloom wrote: If script generation needs to be done, it should be implemented in Python with input from the yml spec item as necessary to fill out a templated script with variables to customize for the BSP, and with appropriate injection of comments etc to allow traceability backward to the original source data and source program that generated the script. We cannot import the YML data in external code without coping it as it all resides in the wscript file. I would prefer seeing the YML python support moved into `spec` as modules with unitests that can be imported. This would allow us to add eco-system tools to support, manage and use the YML data. The module to work with specification items is here: https://github.com/RTEMS/rtems-central/blob/master/rtemsspec/items.py This stuff has tests, code formatting, static analysis, and even a CI script. Independent of this, working with the build specification items would be the wrong approach. You need the input of a configured BSP. -- embedded brains GmbH & Co. KG 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 4/6] build: Add support to make bootloader images
On 05.03.24 22:33, Gedare Bloom wrote:
On Mon, Mar 4, 2024 at 12:19 AM Chris Johns wrote:
On 1/3/2024 9:57 pm, Sebastian Huber wrote:
On 29.02.24 00:05, Chris Johns wrote:
If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?
Application build systems can query the tool using the RTEMS_MKIMAGE package
configuration varible, for example:
pkg-config --variable=RTEMS_MKIMAGE
${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc
Nice. This is my preferred way of handling this.
If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
"false".
So the process has to be a single command?
Yes, a single command which is written in Python. For the U-Boot image it
converts the ELF file to binary, then to a gz file, then to the U-Boot image.
I see it is in a YAML spec file. Sorry that is a no from me. See below.
+1
We should not be in the habit of serializing source code inside a data
file without very good reasons to do so. This feels wrong.
I don't see the issue here. The variable substitution in the build
specification items is not as obscure as with m4.
If script generation needs to be done, it should be implemented in
Python with input from the yml spec item as necessary to fill out a
templated script with variables to customize for the BSP, and with
appropriate injection of comments etc to allow traceability backward
to the original source data and source program that generated the
script.
I think this is exactly the approach of the patch set. The Python script
which fills out the templated script with variables to customize for the
BSP is the wscript. You can of course also put comments into the
generated script. If you use the
if __name__ == "__main__":
approach, you could even provide an executable script and a module.
--
embedded brains GmbH & Co. KG
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: Getting started Task completed
Hi Ashish Baghel,
On Wed, Mar 6, 2024 at 6:30 AM ashish ashish wrote:
>
> Hello all, This is Ashish Baghel email: ashishashish7...@gmail.com pursuing
> computer science and engineering and this is my patch for getting started task
>
> "hello.c"
I see you are copying the contents of the files into your email. This
is not the intended product as described in
https://docs.rtems.org/branches/master/user/start/gsoc.html#creating-and-sending-patches
If you're not sure how to use git and create patches, then I would
suggest you follow some online tutorials. This one looks to be
instructive: https://git-scm.com/docs/gittutorial
Gedare
> #include
> #include
> #include
>
> rtems_task Init(
> rtems_task_argument ignored
> )
> {
> printf( "\nHello World from core of my heart\n" );
> exit( 0 );
> }
>
> "init.c"
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>
> #define CONFIGURE_UNLIMITED_OBJECTS
> #define CONFIGURE_UNIFIED_WORK_AREAS
>
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>
> #define CONFIGURE_INIT
>
> #include
>
> "wscript"
> from __future__ import print_function
>
> rtems_version = "6"
>
> try:
> import rtems_waf.rtems as rtems
> except:
> print('error: no rtems_waf git submodule')
> import sys
> sys.exit(1)
>
> def init(ctx):
> rtems.init(ctx, version = rtems_version, long_commands = True)
>
> def bsp_configure(conf, arch_bsp):
> # Add BSP specific configuration checks
> pass
>
> def options(opt):
> rtems.options(opt)
>
> def configure(conf):
> rtems.configure(conf, bsp_configure = bsp_configure)
>
> def build(bld):
> rtems.build(bld)
>
> bld(features = 'c cprogram',
> target = 'hello.exe',
> cflags = '-g -O2',
> source = ['hello.c',
> 'init.c'])
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuites/libtest/dl12: add DL test for incrementally linked object
This adds a test to verify the incremental linking in RTL.
Update #3740
---
spec/build/bsps/tstnolibdl.yml | 1 +
spec/build/testsuites/libtests/dl12.yml | 46
spec/build/testsuites/libtests/grp.yml | 2 +
testsuites/libtests/dl12/dl-load.c | 138
testsuites/libtests/dl12/dl-load.h | 33 ++
testsuites/libtests/dl12/dl12-o1.c | 42
testsuites/libtests/dl12/dl12-o2.c | 42
testsuites/libtests/dl12/dl12.doc | 47
testsuites/libtests/dl12/dl12.scn | 15 +++
testsuites/libtests/dl12/init.c | 103 ++
10 files changed, 469 insertions(+)
create mode 100644 spec/build/testsuites/libtests/dl12.yml
create mode 100644 testsuites/libtests/dl12/dl-load.c
create mode 100644 testsuites/libtests/dl12/dl-load.h
create mode 100644 testsuites/libtests/dl12/dl12-o1.c
create mode 100644 testsuites/libtests/dl12/dl12-o2.c
create mode 100644 testsuites/libtests/dl12/dl12.doc
create mode 100644 testsuites/libtests/dl12/dl12.scn
create mode 100644 testsuites/libtests/dl12/init.c
diff --git a/spec/build/bsps/tstnolibdl.yml b/spec/build/bsps/tstnolibdl.yml
index 3e09033f37..7f45f55520 100644
--- a/spec/build/bsps/tstnolibdl.yml
+++ b/spec/build/bsps/tstnolibdl.yml
@@ -15,6 +15,7 @@ actions:
- dl09
- dl10
- dl11
+- dl12
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
diff --git a/spec/build/testsuites/libtests/dl12.yml
b/spec/build/testsuites/libtests/dl12.yml
new file mode 100644
index 00..fbd8098358
--- /dev/null
+++ b/spec/build/testsuites/libtests/dl12.yml
@@ -0,0 +1,46 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: script
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH & Co. KG
+cppflags: []
+do-build: |
+ path = "testsuites/libtests/dl12/"
+ objs = []
+ objs.append(self.cc(bld, bic, path + "dl12-o1.c"))
+ objs.append(self.cc(bld, bic, path + "dl12-o2.c"))
+ def ld(self, bld, bic, flags, source, target):
+bld(rule="${LD} " + flags + " ${SRC} -o ${TGT}",
+ source=source,
+ target=target)
+return target
+ objs = [ld(self, bld, bic, '-r', objs,
"testsuites/libtests/dl12/dl12-inc.o")]
+ tar = path + "dl12.tar"
+ self.tar(bld, objs, [path], tar)
+ tar_c, tar_h = self.bin2c(bld, tar)
+ objs = []
+ objs.append(self.cc(bld, bic, tar_c))
+ objs.append(self.cc(bld, bic, path + "init.c", deps=[tar_h],
cppflags=bld.env.TEST_DL12_CPPFLAGS))
+ objs.append(self.cc(bld, bic, path + "dl-load.c"))
+ dl12_pre = path + "dl12.pre"
+ self.link_cc(bld, bic, objs, dl12_pre)
+ dl12_sym_o = path + "dl12-sym.o"
+ objs.append(dl12_sym_o)
+ self.rtems_syms(bld, dl12_pre, dl12_sym_o)
+ self.link_cc(bld, bic, objs, "testsuites/libtests/dl12.exe")
+do-configure: null
+enabled-by:
+- and:
+ - not: TEST_DL12_EXCLUDE
+ - BUILD_LIBDL
+includes:
+- testsuites/libtests/dl12
+ldflags: []
+links: []
+prepare-build: null
+prepare-configure: null
+stlib: []
+target: testsuites/libtests/dl12.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/libtests/grp.yml
b/spec/build/testsuites/libtests/grp.yml
index fae2396a2f..c63d845983 100644
--- a/spec/build/testsuites/libtests/grp.yml
+++ b/spec/build/testsuites/libtests/grp.yml
@@ -110,6 +110,8 @@ links:
uid: dl10
- role: build-dependency
uid: dl11
+- role: build-dependency
+ uid: dl12
- role: build-dependency
uid: dumpbuf01
- role: build-dependency
diff --git a/testsuites/libtests/dl12/dl-load.c
b/testsuites/libtests/dl12/dl-load.c
new file mode 100644
index 00..e928d0c27d
--- /dev/null
+++ b/testsuites/libtests/dl12/dl-load.c
@@ -0,0 +1,138 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (c) 2014 Chris Johns . All rights reserved.
+ * Copyright (c) 2019 On-Line Applications Research
+ *
+ * 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
Re: [PATCH 4/6] build: Add support to make bootloader images
On 6/3/2024 8:33 am, Gedare Bloom wrote: > If script generation needs to be done, it should be implemented in > Python with input from the yml spec item as necessary to fill out a > templated script with variables to customize for the BSP, and with > appropriate injection of comments etc to allow traceability backward > to the original source data and source program that generated the > script. We cannot import the YML data in external code without coping it as it all resides in the wscript file. I would prefer seeing the YML python support moved into `spec` as modules with unitests that can be imported. This would allow us to add eco-system tools to support, manage and use the YML data. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] improved error checking in ticks per timeslice
Hey Zack,
Sebastian posted exactly what he thought those lines should be to match the
surrounding coding style:
#if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
CONFIGURE_TICKS_PER_TIMESLICE <= 0
It should just be a single #if like that and with that order of
conditionals. You'll of course need to remove the second #endif since
you're going to 1 #if.
Kinsey
On Tue, Mar 5, 2024 at 8:44 PM wrote:
> From: Zack leung
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..d480eb3971 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,7 +3312,7 @@
> * @parblock
> * The following constraints apply to this configuration option:
> *
> - * * The value of the configuration option shall be greater than or equal
> to
> + * * The value of the configuration option shall be greater than
> * zero.
> *
> * * The value of the configuration option shall be less than or equal to
> diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..bcca02bd43 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -74,6 +74,12 @@
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
> #endif
>
> +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0
> + #if defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> + #endif
> +#endif
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> --
> 2.43.0
>
> ___
> 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: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)
Hello Gedare, thanks for feedback. On Tuesday 05 of March 2024 22:54:35 Gedare Bloom wrote: > On Thu, Feb 29, 2024 at 6:40 AM Pavel Pisa wrote: > > On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > > > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote: > > > > > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > > > > On a quick review, my recommendation would be to switch to using the > rtems_mutex mechanism of the self-contained objects, see > https://docs.rtems.org/branches/master/c-user/self_contained_objects.html > > I believe this will be a more suitable solution than the more general > interrupt lock. It should be relatively straightforward to implement > this replacement for both the qends and the fifo structures. Each may > embed its own rtems_mutex. I see you already use a > rtems_mutex_recursive to protect the can_bus structure. I would avoid > a design that allows recursive access if possible. I did not see if > you acquire the lock during interrupt service routines. > > Since you have the interrupt_lock mechanism implemented, may be it > would be a nice experiment to evaluate the performance vs the > self-contained rtems_mutex. I agree with switch to self-contained rtems_mutex_lock and probably we try even rtems_binary_semaphore_post for notification. In the fact, this was my question in RFC whether consider self-contained objects for synchronization. By switch of queues protection to mutexes, we lose option to fill it directly from interrupt and implement driver Rx and Tx in interrupts. This could be problem on very slow targets with really short Rx FIFO. But that is not case of CTU CAN FD and even SJA1000 has 128 bytes HW FIFO. The code locking by interrupt disable is for really short time, so it should not be a problem. But we have decided to use chip dedicated thread on RTEMS from start to allow its priority setup even somewhere in middle to allow if there are even some more timing critical tasks running. On Linux kernel, we have used interrupt disabling spinlock to allow write LinCAN Rx and Tx handles directly in interrupt service routine. But that locking mechanism automatically switches to priority aware RT mutexes on the fully preemptive kernel. Anyway, we switch to rtems_mutex_lock on RTEMS, it makes code even simpler and do timing before and after switch ho have idea about behavior on Zynq target (which falls into middle or lower performance range today so it is appropriate for assessment if overhead is significant). Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa social: https://social.kernel.org/ppisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
