Zynq
I attended RTEMS training a couple weeks ago. I got RTEMS running on the Snickerdoodle (https://krtkl.com/snickerdoodle/). The WiFi device has pretty much no documentation appropriate for writing a BSP or drivers. The manufacturer just supplies Linux driver source code and proprietary non-Linux driver source code. So I’m going to pass on any further work on it. I got RTEMS running on the Aerotenna Ocpoc Mini (https://aerotenna.com/shop/ocpoc-zynq-mini/) which we are current flying on a drone with our autopilot on Linux. I’m going to stick with this until we complete our own Zynq Ultrascale+ avionics board, and port our autopilot to RTEMS. Quick question. Is it possible to run RTEMS on one core (or set of cores), and Linux on the other core (or set of cores)? Xilinx posted a recipe for how to run multiple asymmetrical operating systems, but nothing specific to RTEMS. Just checking. Mathew Benson___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx Zynq console rx not working
I just built and ran the zc702 build on Qemu yesterday with no problems. I ran the hello.exe sample. But, I launched it using Vitis 2020.2 so maybe it was a qemu difference? Master branch. RTEMS 6. Sent from my iPhone > On Aug 16, 2021, at 08:03, Kinsey Moore wrote: > > On 8/16/2021 04:45, Chris Johns wrote: >>> On 16/8/21 6:38 pm, Chris Johns wrote: >>> I have taken a closer look at the driver. I am receiving RX interrupts and >>> the >>> characters are being queued however the receive FIFO trigger interrupt is >>> only >>> raised when the FIFO reaches the set threshold of half the FIFO size. I >>> suspect >>> there is an assumption the RX timeout will fire but it is not. >> Doing this is questionable >> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222 >> You cannot send a character when touching the attributes. Where is this >> hardware >> bug documented by Xilinx? > The attributes are done being touched and the TX/RX enable flags are set > again before sending the character. I was seeing the same behavior on Zynq > QEMU even with this code removed. > > I couldn't find the hardware bug documented anywhere, but out of the 3 ZynqMP > boards I have one requires this consistently. >> My application does this ... >>if (tcgetattr(fileno(stdout), &term) < 0) >>error_message(); >>cfsetispeed (&term, B115200); >>cfsetospeed (&term, B115200); >>if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0) >>error_message(); >>if (tcgetattr(fileno(stdin), &term) < 0) >>error_message(); >>cfsetispeed (&term, B115200); >>cfsetospeed (&term, B115200); >>if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0) >>error_message(); >> and this kills the receive interrupts. > > Does removing the null character kick restore functionality for you in this > case? > > > Kinsey > > ___ > 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: Xilinx Zynq console rx not working
Ah. Yes. I did not test input. Thanks for the heads up. Sent from my iPhone > On Aug 16, 2021, at 09:04, Kinsey Moore wrote: > > On 8/16/2021 08:40, mben...@windhoverlabs.com wrote: >> I just built and ran the zc702 build on Qemu yesterday with no problems. I >> ran the hello.exe sample. But, I launched it using Vitis 2020.2 so maybe it >> was a qemu difference? Master branch. RTEMS 6. >> >> Sent from my iPhone > > Output seems to work fine; it's the input that's not working properly. You'll > see this behavior if you run the fileio.exe test since it requires > interaction with the console. I haven't tried on hardware, so that may also > be a difference. > > > Kinsey > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsps/xilinx-zynqmp : Add BSP for RPU
This is great. I will carve out time to check this out on the ZU3EG and
provide feedback if needed. Good job.
Sent from my iPhone
> On Jun 14, 2023, at 08:49, Joel Sherrill wrote:
>
>
> Thanks for submitting this. It has been on the wish list for a while.
>
> My first comment is that information needs to be added to the Users Guide on
> this BSP. Guidance on capabilities, use, and debug is always appreciated by
> the
> next user. Remember that often this is where search engines and other humans
> find out if something is supported.
>
> Comments inline. Hoping others who know this hardware better do a more
> technical review.
>
>> On Wed, Jun 14, 2023 at 3:08 AM Philip Kirkpatrick
>> wrote:
>> This patch adds support for running RTEMS on the RPU (cortex R5) cores of
>> the ZynqMP. This is only a basic BSP and does not yet support the following:
>> - SMP
>> - Cache
>> - MPU
>>
>> Also, everything except for the startup and exception vectors runs out of
>> DRAM, which is slow without cache. At some point in the future, I plan to
>> move some of the fast memory sections to ATCM and BTCM and enable cache.
>>
>> Lastly, credit to Stanislav (s.pankev...@gmail.com, also on this mailing
>> list), for internal reviews and feedback.
>>
>> The steps done to implement this BSP are as follows:
>> - to xilinx_zynqmp_ultra96 bsp (spec/build/bsps/arm/xilinx-zynqmp/*)
>> - Added optprocunitapu.yml to pass C define ZYNQMP_PROC_UNIT_APU
>> - Copied xilinx_zynqmp_ultra96 bsp to xilinx_zynqmp_mercuryxu5_rpu in
>> spec/build/bsps/arm/xilinx-zynqmp-rpu/*
>> - In new BSP
>> - changed optprocunitapu.yml to optprocunitrpu.yml to pass C define
>> ZYNQMP_PROC_UNIT_RPU
>> - Removed all things regarding MMU, and SMP
>> - Changed source: bsps/arm/shared/cache/cache-cp15.c to
>> bsps/shared/cache/nocache.c
>> - Removed all other references to cache
>> - Changed abi flags
>> - Updated the linkcmds to remove MMU and cache sections.
>> - Updated optint0len, optint0ori, optint1len, and optint1ori to target
>> ATCM and BTCM.
>> - Updated linkcmds to place START and VECTOR regions in ATCM
>> - In BSP C sources
>> - Used ZYNQMP_PROC_UNIT_APU and ZYNQMP_PROC_UNIT_RPU to enable/disable
>> MPU, SMP, and cache.
>> - Used PROC_UNIT flags to control GIC address.
>> - Added hook0 code for RPU code to make sure SCTLR[M, I, A, C, V] are
>> cleared
>> - Created a timer driver for the Triple Timer Counter (TTC) module since
>> the RPU doesn't have an ARM generic timer
>>
>> ---
>> diff --git a/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
>> b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
>> new file mode 100644
>> index 00..dd0bc3a3c9
>> --- /dev/null
>> +++ b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
>> @@ -0,0 +1,219 @@
>> +/**
>> + * @file
>> + *
>> + * @ingroup RTEMSBSPsARMZynqMP
>> + *
>> + * @brief Triple Timer Counter clock functions definitions.
>> + */
>> +
>> +/*
>> + * SPDX-License-Identifier: BSD-2-Clause
>> + *
>> + * Copyright (C) 2023 Reflex Aerospace GmbH
>> + *
>> + * Written by Philip Kirkpatrick
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct timecounter zynqmp_ttc_tc;
>> +
>> +#define TTC_REFERENCE_CLOCK 1
>> +
>> +/* This is defined in dev/clock/clockimpl.h */
>> +void Clock_isr(rtems_irq_hdl_param arg);
>> +
>> +static uint32_t irq_match_interval;
>> +
>> +static uint32_t zynqmp_ttc_get_timecount(struct timecounter *tc)
>> +{
>> + uint32_t time;
>> + time = XTtcPs_ReadReg(ZYNQMP_TTC0, XTTCPS_COUNT_VALUE_O
Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu
I’ve received a few emails about our RTEMS on R5 work. Sorry I haven’t responded yet. I made a quick and dirty BSP about 6 months ago just to prove to myself that this was a viable effort. I got it running in the Xilinx Qemu in about a day. I would be happy to mentor anybody wanting to take this on. Sadly, a hard drive failure caused me to lose all my work before I could commit it. One of my new employees has taken up the task. I can introduce you. Our goal is to port RTEMS to the R5 on the Zynq Ultrascale+ first, and a custom FMC with an R5 that we designed in house second. The first iteration of the R5 board is complete and printed but we haven’t had time to assemble and test it yet. The port to the R5 on the Zynq Ultrascale+ is low lying fruit and should be the easiest by far to complete, since it’s booting from Linux on the A53s. The FSBL runs on the A53, which loads the FPGA and configures the hard cores. Until isolation mode is enabled, the RTEMS/R5 basically piggy backs on Linux/A53. Linux sets up the MMU, the Global Interrupt Controller, and the console UART (if shared). RTEMS just has to setup the timer, and map the console to the correct UART. No uboot. Linux loads the R5 reserved memory and signals the PMU to enable power to the R5. The BSP is trivial. All the work is in the drivers. However, if you use our Zynq Ultrascale+ avionics board (should be publicly available next year), driver development is simplified for designs that follow the commonly used rate monotonic design pattern. Driver code actually runs partitioned in a separate CPU, independent of RTEMS, relieving the R5 from non-deterministic interrupts. Our second board has a dedicated R5 device. No Zynq. It’s an FPGA Mezzanine Card (FMC), so it follows a form factor common among FPGA boards. You can use it as an expansion to a main board, but it it does not require a main board. It will also work just as well as a stand-alone board. Just give it power and ground. This platform will take a bit more work to add RTEMS support since you have no A53 doing all the heavy lifting. In its current prototype iteration, it has no attached memory, only internal memory. It also has a UART chip to give us additional UARTs. The next iterations will include additional memory and line drivers for RS-422 support. This board will require driver development. I am most interested in getting RTEMS running on the R5 FMC. Sent from my iPhone > On Apr 17, 2022, at 10:20, Joel Sherrill wrote: > > On Sun, Apr 17, 2022, 5:17 AM Pavel Pisa wrote: > >> Dear Kamlesh, >> >>> On Sunday 17 of April 2022 10:19:01 Kamlesh Bharodiya wrote: >>> Thanks for your mail. I have not worked on ZCU102. Though, I'm working >> with >>> R4F currently. Shall I go ahead with the GSoC application? Or should I >> wait >>> for any other mentor to reply ? >> >> I do not feel competent to be main mentor for this project >> and some feedback from people working on RTEMS core >> would be helpfull. But I expect that most are on Easters >> now so the time to submission deadline is relatively tight. >> > > The R5 basic BSP is needed by the RTEMS community. If you get through that, > you could look at the Xilinx code for interacting with it. > > > > > >> I am not sure if somebody else see potential to use RTEMS or Cortex-R5 >> integrated into ZCU102. I see it in general but do not see any >> such project on my horizon university work nor company projects >> horizon. I have actually neither project with TMS570LC4357, >> but I have at least HW and it could be nice platform to test >> RTEMS CAN support if it is updated during this year another GSoC >> and interesting platform for LwIP testing... But there is no >> QEMU support and I do not suggest to change your project to this >> direction. >> >> As I have checked, it seems that it is possible to use ZCU102 R5 >> somehow with local UART and timer so it makes project initial >> phases as feasible in the GSoC frame. Do you plan project as >> the longer or shorter GSoC variant? >> >> I suggest to apply before submission deadline even if the >> project is not fully clarified before deadline. It will >> be discussed by RTEMS mentors and can be slightly adjusted, >> extended before coding phase to match core team vision. >> Other option is to select another open topic which is on >> the RTEMS project interest list >> >> https://devel.rtems.org/wiki/Developer/OpenProjects >> >> But if you have already some experience with Cortex-R4 >> and see some real application use for your work then >> the goal has reason. >> >> You wrote in your proposal >> >> Testing R4 BSP on Qemu - but I think that there is no such >> available target for now >> >> As for the timeline, I suggest to move testing and familiarization >> with RTEMS and QEMU ecosystem into bonding period and start real >> coding with start of GSoC coding period to have something to >> to evaluate and running in t
Re:
I’m just curious. What school do you go to? What other schools have similar programs? We need more good embedded software engineers. Sent from my iPhone > On Nov 8, 2023, at 03:35, Shreyas Udaya wrote: > > > https://devel.rtems.org/ticket/3850 > > I would like to contribute to the project as part of a course assignment, and > would like to ask the mentors on how much of this project is finished and how > much is remaining. Thank you. > ___ > 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
