Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)
Hello Gedare On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote: > > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under > > my supervision. The project has reached a phase where we will be very > > grateful for the review and pointing to required changes to start a > > discussion of possible inclusion into the RTEMS mainline. The project is > > currently being developed as a separate RTEMS application based on the > > OMK build > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > > > But long-term intention is to move > > > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/can > >drv > > > > directory into RTEMS cpukit/dev/can directory and corresponding include > > files into cpukit/include/dev/can directory. > > Thanks. I will review this design and code, but it will be a few weeks > before I can do that. The directory location is a suitable choice. Thanks. I consider critical to discuse if queues access protection by rtems_interrupt_lock_acquire is appropriate etc. I.e., I see rtems_semaphore_obtain problematic because it would exhaust fixed configures resources easily. I am not sure, if there is rtems core / "kernel" equivalent to contained objects as are used for "userspace" pthread_mutex_lock etc... There are more such architectural questions where feedback from you, Joel, Sebastian and or Chis with deeper knowledge would help. This discussion should continue in public list or as issues setup for RTEMS CAN FD subsystem. > > We have reached a state where the virtual interface has been tested on an > > MZ_APO Xilinx/AMD Zynq-based board and an LX_CPU/LX_RoCoN NXP > > LPC4088-based board. The communication with a complete CAN interface has > > been successfully tested on the MZ_APO Xilinx/AMD Zynq board with CTU CAN > > FD IP cores implemented in FPGA. > > > > Building on other RTEMS BSP should be possible by changing a single > > definition in the config.target file > > > > RTEMS_MAKEFILE_PATH=/opt/rtems/6/arm-rtems6/xilinx_zynq_zedboard > > When ported to cpukit, this would become part of the spec/build opts. For sure, but we want to have easy way to build code against different targets when it is still standalone. > > Michal Lenc will submit work as his Master's Thesis this May > > so I hope that Gedare would be willing to take the thesis > > reviewer role as we have already discussed. > > Indeed I will. I think this work is exciting and needed. Thanks for confirmation. There is limited time window when we can steer his work direction. When he finishes then I hope that he will be helpfull and I want to keep an eye on the project and maintain it as I have done 20 years with LinCAN and helped SocketCAN etc., but the resources for deeper redesign will be limited until some another studnet is found or me or some company has funded project which would be willing to invest even into infrastructural work. You have asked bout XCAN in an another thread, so I reply there even to inform the public. XCAN is AMD/XilinX controller integrated onto Zynq chips. I remember that there has been invested into the driver at German Aerospace Center. Carlo Brokering has worked on it based on the Prashanth S work on Beagle Bone in the frame of GSoC. But the work on infrastructure and FIFOs was not finished from any side even that I have provided our LinCAN sources etc. and later the result has be removed as broken from mainline. https://lists.rtems.org/pipermail/devel/2023-March/074504.html We have XCAN on our Zynq board routed to CTU CAN FD, so it can be tested but porting to new infrastructure hardly fits to Michal Lenc's thesis plan. Another interesting platform and controllers would be xilinx-zynqmp and xilinx-versal. These have advantage that CAN FD controller emulation is included in QEMU mainline. For our project testing for developers without HW, we plan to add support for PCI mapped CTU CAN FD on some x86 RTEMS BSP, because we have that support included in QEMU mainline. I have tried to provide even platform bus (AMBA) mapping for Xilinx Zynq as an experimental patch for QEMU https://github.com/ppisa/qemu/commit/2bcfd7b8dfd7d657ada2f8ec2b972f6469b33c94 Mmaped IO works but interrupt mapping is not working and I am not sure how it should be done correctly for dynamically plugable sysbus device yet. 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 http
6.1rc2 on Rocky 9
Hi Looks pretty good overall. This appears to be the only issue: Testing: riscv rv64imac_spike BSP to Build: rv64imac 'distclean' finished successfully (0.011s) Regenerate build specification cache (needs a couple of seconds)... real 0m25.545s user 2m30.639s sys 0m29.614s *** /home/joel/rtems-6.1rc2/rtems Exception in thread _stdout[spike]: Traceback (most recent call last): File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, in _bootstrap_inner self.run() File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/home/joel/rtems-6.1rc2/tools/6/share/rtems/rtemstoolkit/execute.py", line 226, in _readthread data = data.decode(sys.stdout.encoding) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 6.1rc2 on Rocky 9
On 1/3/2024 2:43 am, Joel Sherrill wrote: > Hi > > Looks pretty good overall. This appears to be the only issue: > > Testing: riscv rv64imac_spike > BSP to Build: rv64imac > 'distclean' finished successfully (0.011s) > Regenerate build specification cache (needs a couple of seconds)... > > real 0m25.545s > user 2m30.639s > sys 0m29.614s > *** /home/joel/rtems-6.1rc2/rtems > Exception in thread _stdout[spike]: > Traceback (most recent call last): > File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, > in > _bootstrap_inner > self.run() > File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, > in run > self._target(*self._args, **self._kwargs) > File "/home/joel/rtems-6.1rc2/tools/6/share/rtems/rtemstoolkit/execute.py", > line 226, in _readthread > data = data.decode(sys.stdout.encoding) > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: > invalid > start byte This looks like rtems-tools needs to be updated to use the same decoder as the RSB: https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/execute.py#n185 Happy to review a patch and your ever improving python skills :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use -frandom-seed=0
On 29/2/2024 6:36 pm, Sebastian Huber wrote: > On 29.02.24 00:29, Chris Johns wrote: >> On 28/2/2024 6:24 pm, Sebastian Huber wrote: >>> On 28.02.24 06:34, Chris Johns wrote: The manual says: The string can either be a number (decimal, octal or hex) or an arbitrary string (in which case it’s converted to a number by computing CRC32). The string should be different for every file you compile. I take this to mean the option `-frandom-seed=0` uses `0` as a number however it is the same for every file and the manual clearly says it must be different? >>> Using -frandom-seed=0 seems to be quite common on the internet. The random >>> seed >>> is rarely used in GCC. The only use case in RTEMS I found is related to the >>> gcov >>> code coverage instrumentation. >> There are lots of things that are common on the internet I ignore 😉 >> >> Is this a bug in the documentation? > > From my point of view this random seed is a gray area in the compiler. The > cases > in which it is used should not matter for the RTEMS build (except for the code > coverage): > > https://gcc.gnu.org/pipermail/gcc-help/2024-February/143324.html > > I will try to add it only to the coverage flags. I would prefer knowing which path is right. If the documentation for gcc says not to do something then I am not sure it is good for us to add it anywhere. For example it is working now in your testing but a future release of gcc changes and subtle issues appear our testing does not pick up. If the gcc maintainers say it is OK then I am fine but they need to update their documentation. I know nothing about this options so it is difficult for me to say yes to the change when it is in conflict to the published documentation. Others may have a different view. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] testsuites/dhrystone: Initialize before use
On 28.02.24 19:15, Kinsey Moore wrote: This resovles a warning where a variable could be used before it is initialized in some code paths. I am not sure if we should modify benchmark code. -- 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 1/2] cpukit/libtest: Remove unused variable
On 28.02.24 19:15, Kinsey Moore wrote: This unused variable causes a warning. It is never set or used. Thanks for fixing this. -- 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: [RFC] libdl: Make Elf_Sym::st_other available
On 29.02.24 00:27, Chris Johns wrote:
On 27/2/2024 6:46 pm, Sebastian Huber wrote:
The 64-bit PowerPC ELFv2 relocation support needs access to the
Elf_Sym::st_other symbol information. The machine-specific relocation handler
had only access to the Elf_Sym::st_info symbol information. This change
extends the 8-bit syminfo parameter to 16-bit and uses the additional
8-bits to provide Elf_Sym::st_other. Another approach could be to pass
a pointer to an Elf_Sym object instead of symname, syminfo, and
symvalue.
I think symname and symvalue have to stay or the code needed to support them
moves out to all reloc handlers [1]. I agree there is a limit to the number args
to keep adding. If there is a need for more fields then it may pay to pass in
Elf_Sym* or rtems_rtl_obj_sym* which is the symbol table reference?
Chris
[1] https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-elf.c#n429
What do you prefer, a new st_other parameter, use Elf_Sym*, or use
rtems_rtl_obj_sym*?
The
/**
* An object file symbol.
*/
typedef struct rtems_rtl_obj_sym
{
rtems_chain_node node;/**< The node's link in the chain. */
const char* name;/**< The symbol's name. */
void*value; /**< The value of the symbol. */
uint32_t data;/**< Format specific data. */
} rtems_rtl_obj_sym;
has no st_info and st_other members. I tend to pass a Elf_Sym* pointer.
--
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
