Question: trace_printk() in xenomai?
Dear friends, Is it safe to use trace_printk() in xenomai or it does a domain switch? Until now I have used only rtdm_printk() and raw_printk(). Another question: is raw_printk() only on arm (and not on arm64, nor x86_64)? Thank you, L-C.
Re: Announce RTnet on PREEMPT_RT Linux
On 2/8/21, Jan Kiszka wrote: > On 08.02.21 15:45, Laurentiu-Cristian Duca via Xenomai wrote: >> Dear friends, >> >> Please let me announce the port of the RTnet core on PREEMPT_RT Linux >> 5.9. >> Features: >> - ported raspberry pi 4 (bcmgenet), orange pi one (stmmac), >> realtek (8139too), ticpsw (beaglebone black), microchip (enc28j60) >> - rtnet UDP socket, bind, recvmsg, sendto, recvfrom, sendmsg, select, >> poll system calls; >> - sockets with AF_INET (UDP) or AF_PACKET (raw) family; >> - rtnetproxy for ssh and scp (but uses RT driver bandwidth) >> >> The project is available on my github [1]. >> I've made the code available although it needs some polishing. >> >> Best regards, >> L-C. Duca >> >> [1] https://github.com/laurentiuduca/rtnet-preempt_rt >> > > Thanks for sharing! > > Very interesting to see this direction while people are (validly) > concerned about maintaining the driver forks that RTnet implies. Can you > share your motivation for and plans with this work? > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > Hi, I consider RTnet an interesting project and I was curious about RTnet architecture and wondered if its core can be ported to PREEMPT_RT because some people asked about this. L.-C.
Announce RTnet on PREEMPT_RT Linux
Dear friends, Please let me announce the port of the RTnet core on PREEMPT_RT Linux 5.9. Features: - ported raspberry pi 4 (bcmgenet), orange pi one (stmmac), realtek (8139too), ticpsw (beaglebone black), microchip (enc28j60) - rtnet UDP socket, bind, recvmsg, sendto, recvfrom, sendmsg, select, poll system calls; - sockets with AF_INET (UDP) or AF_PACKET (raw) family; - rtnetproxy for ssh and scp (but uses RT driver bandwidth) The project is available on my github [1]. I've made the code available although it needs some polishing. Best regards, L-C. Duca [1] https://github.com/laurentiuduca/rtnet-preempt_rt
Fwd: [PATCH] Avoid a possible too early interrupt from the omap mcSPI controller
-- Forwarded message -
From: Laurentiu-Cristian Duca
Date: Fri, Apr 24, 2020, 20:38
Subject: Re: [PATCH] Avoid a possible too early interrupt from the omap
mcSPI controller
To: Jan Kiszka
In Xenomai the issue did not happen in my tests. It happened in the
preempt_rt port of the Xenomai omap4 mcSPI real time driver.
On Fri, Apr 24, 2020, 20:24 Jan Kiszka wrote:
> On 24.04.20 13:41, Laurentiu-Cristian Duca via Xenomai wrote:
> > In order to avoid a possible too early interrupt
> > from the omap mcSPI controller,
> > disable interrupts before writing the number of bytes from the SPI
> message
> > that fill up the omap mcSPI controller queue,
> > and enable interrupts after that.
> >
> > Signed-off-by: Laurentiu-Cristian Duca
> > ---
> > kernel/drivers/spi/spi-omap2-mcspi-rt.c | 28 -
> > 1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/drivers/spi/spi-omap2-mcspi-rt.c
> b/kernel/drivers/spi/spi-omap2-mcspi-rt.c
> > index a7a005b22..03678b991 100644
> > --- a/kernel/drivers/spi/spi-omap2-mcspi-rt.c
> > +++ b/kernel/drivers/spi/spi-omap2-mcspi-rt.c
> > @@ -149,6 +149,7 @@ struct spi_master_omap2_mcspi {
> > int rx_len;
> > int fifo_depth;
> > rtdm_event_t transfer_done;
> > + rtdm_lock_t lock;
> > unsigned int pin_dir:1;
> > struct omap2_mcspi_cs cs[OMAP2_MCSPI_CS_N];
> > /* logging */
> > @@ -421,6 +422,26 @@ static void mcspi_wr_fifo(struct
> spi_master_omap2_mcspi *spim, int cs_id)
> > }
> > }
> >
> > +static void mcspi_wr_fifo_bh(struct spi_master_omap2_mcspi *spim, int
> cs_id)
> > +{
> > + u8 byte;
> > + int i;
> > + rtdm_lockctx_t c;
> > +
> > + rtdm_lock_get_irqsave(>lock, c);
> > +
> > + for (i = 0; i < spim->fifo_depth; i++) {
> > + if (spim->tx_len <= 0)
> > + byte = 0;
> > + else
> > + byte = spim->tx_buf ? *spim->tx_buf++ : 0;
> > + mcspi_wr_cs_reg(spim, cs_id, OMAP2_MCSPI_TX0, byte);
> > + spim->tx_len--;
> > + }
> > +
> > + rtdm_lock_put_irqrestore(>lock, c);
> > +}
> > +
> > static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
> > {
> > struct spi_master_omap2_mcspi *spim;
> > @@ -428,6 +449,8 @@ static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
> > int i, cs_id = 0;
> >
> > spim = rtdm_irq_get_arg(irqh, struct spi_master_omap2_mcspi);
> > + rtdm_lock_get(>lock);
> > +
> > for (i = 0; i < OMAP2_MCSPI_CS_N; i++)
> > if (spim->cs[i].chosen) {
> > cs_id = i;
> > @@ -459,6 +482,8 @@ static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
> > rtdm_event_signal(>transfer_done);
> > }
> >
> > + rtdm_lock_put(>lock);
> > +
> > return RTDM_IRQ_HANDLED;
> > }
> >
> > @@ -572,7 +597,7 @@ static int do_transfer_irq_bh(struct
> rtdm_spi_remote_slave *slave)
> > mcspi_wr_reg(spim, OMAP2_MCSPI_IRQENABLE, l);
> >
> > /* TX_EMPTY will be raised only after data is transfered */
> > - mcspi_wr_fifo(spim, slave->chip_select);
> > + mcspi_wr_fifo_bh(spim, slave->chip_select);
> >
> > /* wait for transfer completion */
> > ret = rtdm_event_wait(>transfer_done);
> > @@ -905,6 +930,7 @@ static int omap2_mcspi_probe(struct platform_device
> *pdev)
> >
> > spim = container_of(master, struct spi_master_omap2_mcspi, master);
> > rtdm_event_init(>transfer_done, 0);
> > + rtdm_lock_init(>lock);
> >
> > spim->pin_dir = pin_dir;
> > r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >
>
> Thanks, applied.
>
> Did you see the issue in reality or did you identify it as "can
> potentially happen"?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
[PATCH] Avoid a possible too early interrupt from the omap mcSPI controller
In order to avoid a possible too early interrupt
from the omap mcSPI controller,
disable interrupts before writing the number of bytes from the SPI message
that fill up the omap mcSPI controller queue,
and enable interrupts after that.
Signed-off-by: Laurentiu-Cristian Duca
---
kernel/drivers/spi/spi-omap2-mcspi-rt.c | 28 -
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/kernel/drivers/spi/spi-omap2-mcspi-rt.c
b/kernel/drivers/spi/spi-omap2-mcspi-rt.c
index a7a005b22..03678b991 100644
--- a/kernel/drivers/spi/spi-omap2-mcspi-rt.c
+++ b/kernel/drivers/spi/spi-omap2-mcspi-rt.c
@@ -149,6 +149,7 @@ struct spi_master_omap2_mcspi {
int rx_len;
int fifo_depth;
rtdm_event_t transfer_done;
+ rtdm_lock_t lock;
unsigned int pin_dir:1;
struct omap2_mcspi_cs cs[OMAP2_MCSPI_CS_N];
/* logging */
@@ -421,6 +422,26 @@ static void mcspi_wr_fifo(struct spi_master_omap2_mcspi
*spim, int cs_id)
}
}
+static void mcspi_wr_fifo_bh(struct spi_master_omap2_mcspi *spim, int cs_id)
+{
+ u8 byte;
+ int i;
+ rtdm_lockctx_t c;
+
+ rtdm_lock_get_irqsave(>lock, c);
+
+ for (i = 0; i < spim->fifo_depth; i++) {
+ if (spim->tx_len <= 0)
+ byte = 0;
+ else
+ byte = spim->tx_buf ? *spim->tx_buf++ : 0;
+ mcspi_wr_cs_reg(spim, cs_id, OMAP2_MCSPI_TX0, byte);
+ spim->tx_len--;
+ }
+
+ rtdm_lock_put_irqrestore(>lock, c);
+}
+
static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
{
struct spi_master_omap2_mcspi *spim;
@@ -428,6 +449,8 @@ static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
int i, cs_id = 0;
spim = rtdm_irq_get_arg(irqh, struct spi_master_omap2_mcspi);
+ rtdm_lock_get(>lock);
+
for (i = 0; i < OMAP2_MCSPI_CS_N; i++)
if (spim->cs[i].chosen) {
cs_id = i;
@@ -459,6 +482,8 @@ static int omap2_mcspi_interrupt(rtdm_irq_t *irqh)
rtdm_event_signal(>transfer_done);
}
+ rtdm_lock_put(>lock);
+
return RTDM_IRQ_HANDLED;
}
@@ -572,7 +597,7 @@ static int do_transfer_irq_bh(struct rtdm_spi_remote_slave
*slave)
mcspi_wr_reg(spim, OMAP2_MCSPI_IRQENABLE, l);
/* TX_EMPTY will be raised only after data is transfered */
- mcspi_wr_fifo(spim, slave->chip_select);
+ mcspi_wr_fifo_bh(spim, slave->chip_select);
/* wait for transfer completion */
ret = rtdm_event_wait(>transfer_done);
@@ -905,6 +930,7 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
spim = container_of(master, struct spi_master_omap2_mcspi, master);
rtdm_event_init(>transfer_done, 0);
+ rtdm_lock_init(>lock);
spim->pin_dir = pin_dir;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
2.17.1
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
gt;>> I sent a patch offline, if you could try it that would be >> >> > > >>> >>> great. >> >> > > >>> >>> I'm >> >> > > >>> >>> having issues getting my board set up. >> >> > > >>> >>> >> >> > > >>> >> >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather >> >> > > >>> >> something >> >> > > >>> >> cobalt-related? >> >> > > >>> >> >> >> > > >>> >> Jan >> >> > > >>> >> >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> >> > > >>> >>> >> >> > > >>> >>> wrote: >> >> > > >>> >>>> >> >> > > >>> >>>> Hi, >> >> > > >>> >>>> >> >> > > >>> >>>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> >> > > >>> >>>> wrote: >> >> > > >>> >>>>> >> >> > > >>> >>>>> Hi, the interrupt comes one per second in my test, so >> >> > > >>> >>>>> there >> >> > > >>> >>>>> is no >> >> > > >>> >>>>> flood. >> >> > > >>> >>>>> In 4.19 the system it blinks the gpioout but it does not >> >> > > >>> >>>>> respond >> >> > > >>> >>>>> to >> >> > > >>> >>>>> keyboard and does not show anything more on the screen. >> >> > > >>> >>>> >> >> > > >>> >>>> Okay, there's a couple things that are different between >> >> > > >>> >>>> 4.4 >> >> > > >>> >>>> and >> >> > > >>> >>>> 4.19 >> >> > > >>> >>>> that I'm looking into, which is taking me a little long >> >> > > >>> >>>> then >> >> > > >>> >>>> I >> >> > > >>> >>>> thought. I won't have this patch ready till tomorrow >> >> > > >>> >>>> morning. I >> >> > > >>> >>>> finally have beaglebone black hardware, I'll make sure >> >> > > >>> >>>> the >> >> > > >>> >>>> kernel >> >> > > >>> >>>> boots and then send the patch to you for testing. >> >> > > >>> >>>> >> >> > > >>> >>>> -Greg >> >> > > >>> >>>> >> >> > > >>> >>>> >> >> > > >>> >>>>> >> >> > > >>> >>>>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher >> >> > > >>> >>>>> >> >> > > >>> >>>>> wrote: >> >> > > >>> >>>>>> >> >> > > >>> >>>>>> Hi, >> >> > > >>> >>>>>> >> >> > > >>> >>>>>> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca >> >> > > >>> >>>>>> via >> >> > > >>> >>>>>> Xenomai >> >> > > >>> >>>>>> wrote: >> >> > > >>> >>>>>>> >> >> > > >>> >>>>>>> Hello xenomai community, >> >> > > >>> >>>>>>> >> >> > > >>> >>>>>>> I have successfully tested in xenomai SPI with >> >> > > >>> >>>>>>> interrupts >> >> > > >>> >>>>>>> on >> >> > > >>> >>>>>>> bbb. >> >> > > >>> >>>>>>> However, on bbb,
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hello there Greg, any news? Thanks On 1/31/20, Greg Gallagher wrote: > Hey, > > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher > wrote: >> >> Hey, >> >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher >> wrote: >> > >> > Hi, >> > >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca >> > wrote: >> > > >> > > Again, to make things clear: >> > > I have tested two modules: one with RTDM gpio-interrupts and one with >> > > classic linux interrupts. >> > > The one with RTDM gpio-interrupts: >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and >> > > 4.9.51 >> > > The one with classic linux interrupts: >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT >> > > non-ipipe non-xenomai) >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 >> > > for xenomai ipipe enabled kernels >> > > >> > > On 1/28/20, Laurentiu-Cristian Duca wrote: >> > > > This does not happen with non-ipipe enabled kernels. >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it >> > > > works, >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and >> > > > 4.19.82) >> > > > got kernel freeze. >> > > > >> > > > On 1/28/20, Greg Gallagher wrote: >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> > > >> laurentiu.d...@gmail.com> wrote: >> > > >> >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> > > >>> >> > > >>> On 1/28/20, Laurentiu-Cristian Duca >> > > >>> wrote: >> > > >>> > Hello Jan and friends, >> > > >>> > >> > > >>> > The situation is the following for bbb: >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> > > >>> > freeze when trying to use gpio-interrupts; >> > > >>> > when interrupt comes the gpioout is toggled but the system >> > > >>> > do not respond anymore to keyboard and nothing more is shown on >> > > >>> > the >> > > >>> screen >> > > >>> > - note that even if I try a classic (linux only, non-xenomai) >> > > >> >> > > >> This happens even with non-ipipe enables kernels? >> > > > >> > > >> >> > > >> >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >> > > >>> > the system freeze when interrupt comes >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> > > >>> > blinking gpioout and do not block, >> > > >>> > but both show warnings when interrupt comes >> > > >>> > which significantly increase interrupt latency. >> > > >>> > >> > > >>> > >> > > >>> > On 1/28/20, Jan Kiszka wrote: >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> > > >>> >>> I sent a patch offline, if you could try it that would be >> > > >>> >>> great. >> > > >>> >>> I'm >> > > >>> >>> having issues getting my board set up. >> > > >>> >>> >> > > >>> >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather >> > > >>> >> something >> > > >>> >> cobalt-related? >> > > >>> >> >> > > >>> >> Jan >> > > >>> >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> > > >>> >>> >> > > >>> >>> wrote: >> > > >>> >>>> >> > > >>> >>>> Hi, >> > > >>> >>>> >> > > >>> >>>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> > > >>> >>>> wrote: >> > > >>
Beaglebone black raw_printk
Hello xenomai family In this way I was able to use raw_printk on evl. Maybe works on xenomai too. CONFIG_DEBUG_RAW_PRINTK=y CONFIG_DEBUG_LL=y # under LL menu entry CONFIG_DEBUG_UART_8250=y CONFIG_DEBUG_UART_PHYS=0x44e09000 CONFIG_DEBUG_UART_VIRT=0xf9e09000
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Again, to make things clear: I have tested two modules: one with RTDM gpio-interrupts and one with classic linux interrupts. The one with RTDM gpio-interrupts: - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and 4.9.51 The one with classic linux interrupts: - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT non-ipipe non-xenomai) - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 for xenomai ipipe enabled kernels On 1/28/20, Laurentiu-Cristian Duca wrote: > This does not happen with non-ipipe enabled kernels. > I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, > but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) > got kernel freeze. > > On 1/28/20, Greg Gallagher wrote: >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> laurentiu.d...@gmail.com> wrote: >> >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >>> >>> On 1/28/20, Laurentiu-Cristian Duca wrote: >>> > Hello Jan and friends, >>> > >>> > The situation is the following for bbb: >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >>> > freeze when trying to use gpio-interrupts; >>> > when interrupt comes the gpioout is toggled but the system >>> > do not respond anymore to keyboard and nothing more is shown on the >>> screen >>> > - note that even if I try a classic (linux only, non-xenomai) >> >> This happens even with non-ipipe enables kernels? > >> >> >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >>> > the system freeze when interrupt comes >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >>> > blinking gpioout and do not block, >>> > but both show warnings when interrupt comes >>> > which significantly increase interrupt latency. >>> > >>> > >>> > On 1/28/20, Jan Kiszka wrote: >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >>> >>> I sent a patch offline, if you could try it that would be great. >>> >>> I'm >>> >>> having issues getting my board set up. >>> >>> >>> >> >>> >> Do we know by now if this is an I-pipe issue or rather something >>> >> cobalt-related? >>> >> >>> >> Jan >>> >> >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >>> >>> >>> >>> wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi, the interrupt comes one per second in my test, so there is no >>> >>>>> flood. >>> >>>>> In 4.19 the system it blinks the gpioout but it does not respond >>> >>>>> to >>> >>>>> keyboard and does not show anything more on the screen. >>> >>>> >>> >>>> Okay, there's a couple things that are different between 4.4 and >>> >>>> 4.19 >>> >>>> that I'm looking into, which is taking me a little long then I >>> >>>> thought. I won't have this patch ready till tomorrow morning. I >>> >>>> finally have beaglebone black hardware, I'll make sure the kernel >>> >>>> boots and then send the patch to you for testing. >>> >>>> >>> >>>> -Greg >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi, >>> >>>>>> >>> >>>>>> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via >>> >>>>>> Xenomai >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> Hello xenomai community, >>> >>>>>>> >>> >>>>>>> I have successfully tested in xenomai SPI with interrupts >>> >>>>>>> on >>> >>>>>>> bbb. >>> >>>>>>> However, on bbb, if I try to test a basic
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
This does not happen with non-ipipe enabled kernels. I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) got kernel freeze. On 1/28/20, Greg Gallagher wrote: > On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > laurentiu.d...@gmail.com> wrote: > >> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> >> On 1/28/20, Laurentiu-Cristian Duca wrote: >> > Hello Jan and friends, >> > >> > The situation is the following for bbb: >> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> > freeze when trying to use gpio-interrupts; >> > when interrupt comes the gpioout is toggled but the system >> > do not respond anymore to keyboard and nothing more is shown on the >> screen >> > - note that even if I try a classic (linux only, non-xenomai) > > This happens even with non-ipipe enables kernels? > > >> > gpio interrupt handler in 4.19.82 with xenomai-3 >> > the system freeze when interrupt comes >> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> > blinking gpioout and do not block, >> > but both show warnings when interrupt comes >> > which significantly increase interrupt latency. >> > >> > >> > On 1/28/20, Jan Kiszka wrote: >> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> >>> I sent a patch offline, if you could try it that would be great. I'm >> >>> having issues getting my board set up. >> >>> >> >> >> >> Do we know by now if this is an I-pipe issue or rather something >> >> cobalt-related? >> >> >> >> Jan >> >> >> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> >>> >> >>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> >>>> wrote: >> >>>>> >> >>>>> Hi, the interrupt comes one per second in my test, so there is no >> >>>>> flood. >> >>>>> In 4.19 the system it blinks the gpioout but it does not respond to >> >>>>> keyboard and does not show anything more on the screen. >> >>>> >> >>>> Okay, there's a couple things that are different between 4.4 and >> >>>> 4.19 >> >>>> that I'm looking into, which is taking me a little long then I >> >>>> thought. I won't have this patch ready till tomorrow morning. I >> >>>> finally have beaglebone black hardware, I'll make sure the kernel >> >>>> boots and then send the patch to you for testing. >> >>>> >> >>>> -Greg >> >>>> >> >>>> >> >>>>> >> >>>>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via >> >>>>>> Xenomai >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Hello xenomai community, >> >>>>>>> >> >>>>>>> I have successfully tested in xenomai SPI with interrupts on >> >>>>>>> bbb. >> >>>>>>> However, on bbb, if I try to test a basic gpio interrupts driver, >> >>>>>>> problems appear. >> >>>>>>> Please see details below. I appreciate any idea. >> >>>>>>> >> >>>>>>> 1. xenomai-3 master linux 4.19.82, default dts >> >>>>>>> # insmod xeno_osc-gpio-rtdm.ko >> >>>>>>> [ 105.582245] IRQ number 62 ! >> >>>>>>> [ 105.585976] after request irq = 62 >> >>>>>>> System freeze when first interrupt occurs and I must power off. >> >>>>>> Is it possible to use raw_printk and see if the system is still >> >>>>>> working but possibly getting flooded by interrupts? When I >> >>>>>> encountered this issue with the BCM2835 port I placed a raw_printk >> in >> >>>>>> one of the functions that initially hand
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 On 1/28/20, Laurentiu-Cristian Duca wrote: > Hello Jan and friends, > > The situation is the following for bbb: > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > freeze when trying to use gpio-interrupts; > when interrupt comes the gpioout is toggled but the system > do not respond anymore to keyboard and nothing more is shown on the screen > - note that even if I try a classic (linux only, non-xenomai) > gpio interrupt handler in 4.19.82 with xenomai-3 > the system freeze when interrupt comes > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > blinking gpioout and do not block, > but both show warnings when interrupt comes > which significantly increase interrupt latency. > > > On 1/28/20, Jan Kiszka wrote: >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >>> I sent a patch offline, if you could try it that would be great. I'm >>> having issues getting my board set up. >>> >> >> Do we know by now if this is an I-pipe issue or rather something >> cobalt-related? >> >> Jan >> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >>> wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >>>> wrote: >>>>> >>>>> Hi, the interrupt comes one per second in my test, so there is no >>>>> flood. >>>>> In 4.19 the system it blinks the gpioout but it does not respond to >>>>> keyboard and does not show anything more on the screen. >>>> >>>> Okay, there's a couple things that are different between 4.4 and 4.19 >>>> that I'm looking into, which is taking me a little long then I >>>> thought. I won't have this patch ready till tomorrow morning. I >>>> finally have beaglebone black hardware, I'll make sure the kernel >>>> boots and then send the patch to you for testing. >>>> >>>> -Greg >>>> >>>> >>>>> >>>>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai >>>>>> wrote: >>>>>>> >>>>>>> Hello xenomai community, >>>>>>> >>>>>>> I have successfully tested in xenomai SPI with interrupts on >>>>>>> bbb. >>>>>>> However, on bbb, if I try to test a basic gpio interrupts driver, >>>>>>> problems appear. >>>>>>> Please see details below. I appreciate any idea. >>>>>>> >>>>>>> 1. xenomai-3 master linux 4.19.82, default dts >>>>>>> # insmod xeno_osc-gpio-rtdm.ko >>>>>>> [ 105.582245] IRQ number 62 ! >>>>>>> [ 105.585976] after request irq = 62 >>>>>>> System freeze when first interrupt occurs and I must power off. >>>>>> Is it possible to use raw_printk and see if the system is still >>>>>> working but possibly getting flooded by interrupts? When I >>>>>> encountered this issue with the BCM2835 port I placed a raw_printk in >>>>>> one of the functions that initially handles the interrupt to see if >>>>>> it >>>>>> was being ack'd. >>>>>>> >>>>>>> >>>>>>> 2. xenomai 3.0.5 linux 4.4.71, default dts >>>>>>> # insmod xeno_osc-gpio-rtdm.ko >>>>>>> [ 39.901907] IRQ number 142 ! >>>>>>> [ 39.905447] after request irq = 142 >>>>>>> >>>>>>> When first interrupt occurs: >>>>>>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, >>>>>>> unhandled: >>>>>>> 0 >>>>>>> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >>>>>>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >>>>>>> [ 322.122702] ->action(): (null) >>>>>>> [ 322.126067]IRQ_NOPROBE set >>>>>>> [ 322.129252] unexpected IRQ trap at vector 8e >>>>>>> [ 322.133706] [ cut here ] >>>>>>> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >>>>>>> __ipipe
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hello Jan and friends, The situation is the following for bbb: - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels freeze when trying to use gpio-interrupts; when interrupt comes the gpioout is toggled but the system do not respond anymore to keyboard and nothing more is shown on the screen - note that even if I try a classic (linux only, non-xenomai) gpio interrupt handler in 4.19.82 with xenomai-3 the system freeze when interrupt comes - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work blinking gpioout and do not block, but both show warnings when interrupt comes which significantly increase interrupt latency. On 1/28/20, Jan Kiszka wrote: > On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> I sent a patch offline, if you could try it that would be great. I'm >> having issues getting my board set up. >> > > Do we know by now if this is an I-pipe issue or rather something > cobalt-related? > > Jan > >> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> wrote: >>> >>> Hi, >>> >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >>> wrote: >>>> >>>> Hi, the interrupt comes one per second in my test, so there is no flood. >>>> In 4.19 the system it blinks the gpioout but it does not respond to >>>> keyboard and does not show anything more on the screen. >>> >>> Okay, there's a couple things that are different between 4.4 and 4.19 >>> that I'm looking into, which is taking me a little long then I >>> thought. I won't have this patch ready till tomorrow morning. I >>> finally have beaglebone black hardware, I'll make sure the kernel >>> boots and then send the patch to you for testing. >>> >>> -Greg >>> >>> >>>> >>>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai >>>>> wrote: >>>>>> >>>>>> Hello xenomai community, >>>>>> >>>>>> I have successfully tested in xenomai SPI with interrupts on >>>>>> bbb. >>>>>> However, on bbb, if I try to test a basic gpio interrupts driver, >>>>>> problems appear. >>>>>> Please see details below. I appreciate any idea. >>>>>> >>>>>> 1. xenomai-3 master linux 4.19.82, default dts >>>>>> # insmod xeno_osc-gpio-rtdm.ko >>>>>> [ 105.582245] IRQ number 62 ! >>>>>> [ 105.585976] after request irq = 62 >>>>>> System freeze when first interrupt occurs and I must power off. >>>>> Is it possible to use raw_printk and see if the system is still >>>>> working but possibly getting flooded by interrupts? When I >>>>> encountered this issue with the BCM2835 port I placed a raw_printk in >>>>> one of the functions that initially handles the interrupt to see if it >>>>> was being ack'd. >>>>>> >>>>>> >>>>>> 2. xenomai 3.0.5 linux 4.4.71, default dts >>>>>> # insmod xeno_osc-gpio-rtdm.ko >>>>>> [ 39.901907] IRQ number 142 ! >>>>>> [ 39.905447] after request irq = 142 >>>>>> >>>>>> When first interrupt occurs: >>>>>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: >>>>>> 0 >>>>>> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >>>>>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >>>>>> [ 322.122702] ->action(): (null) >>>>>> [ 322.126067]IRQ_NOPROBE set >>>>>> [ 322.129252] unexpected IRQ trap at vector 8e >>>>>> [ 322.133706] [ cut here ] >>>>>> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >>>>>> __ipipe_ack_bad_irq+0x24/0x3c() >>>>>> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) >>>>>> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O >>>>>> 4.4.71-ipipe #1 >>>>>> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree) >>>>>> [ 322.166791] I-pipe domain: Linux >>>>>> [ 322.170175] [] (unwind_backtrace) from [] >>>>>> (show_stack+0x10/0x14) >>>>>> [ 322
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
I forgot to mention that on xenomai 3.0.5 linux 4.4.71 with default dts,
although warnings appear, the driver works
but in xenomai-3 master linux 4.19.82 with default dts got system freeze.
On 1/23/20, Laurentiu-Cristian Duca wrote:
> Hello xenomai community,
>
> I have successfully tested in xenomai SPI with interrupts on bbb.
> However, on bbb, if I try to test a basic gpio interrupts driver,
> problems appear.
> Please see details below. I appreciate any idea.
>
> 1. xenomai-3 master linux 4.19.82, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 105.582245] IRQ number 62 !
> [ 105.585976] after request irq = 62
> System freeze when first interrupt occurs and I must power off.
>
>
> 2. xenomai 3.0.5 linux 4.4.71, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 39.901907] IRQ number 142 !
> [ 39.905447] after request irq = 142
>
> When first interrupt occurs:
> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.122702] ->action(): (null)
> [ 322.126067]IRQ_NOPROBE set
> [ 322.129252] unexpected IRQ trap at vector 8e
> [ 322.133706] [ cut here ]
> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843
> __ipipe_ack_bad_irq+0x24/0x3c()
> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O)
> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
> 4.4.71-ipipe #1
> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 322.166791] I-pipe domain: Linux
> [ 322.170175] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 322.178273] [] (show_stack) from []
> (dump_stack+0x9c/0xc4)
> [ 322.185829] [] (dump_stack) from []
> (warn_slowpath_common+0x78/0xb4)
> [ 322.194280] [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x1c/0x24)
> [ 322.203455] [] (warn_slowpath_null) from []
> (__ipipe_ack_bad_irq+0x24/0x3c)
> [ 322.212542] [] (__ipipe_ack_bad_irq) from []
> (__ipipe_dispatch_irq+0x78/0x1d8)
> [ 322.221903] [] (__ipipe_dispatch_irq) from []
> (omap_gpio_irq_handler+0x134/0x1a4)
> [ 322.231532] [] (omap_gpio_irq_handler) from []
> (handle_irq_event_percpu+0xa4/0x304)
> [ 322.241341] [] (handle_irq_event_percpu) from
> [] (handle_irq_event+0x38/0x5c)
> [ 322.250605] [] (handle_irq_event) from []
> (handle_level_irq+0x88/0xe4)
> [ 322.259235] [] (handle_level_irq) from []
> (generic_handle_irq+0x20/0x34)
> [ 322.268045] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x64/0xd4)
> [ 322.277127] [] (__handle_domain_irq) from []
> (__ipipe_do_sync_stage+0x21c/0x25c)
> [ 322.286665] [] (__ipipe_do_sync_stage) from []
> (__ipipe_grab_irq+0x5c/0x7c)
> [ 322.295753] [] (__ipipe_grab_irq) from []
> (__irq_svc+0x54/0x60)
> [ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0)
> [ 322.309017] 7f40:
> df91d240
> [ 322.317556] 7f60: c092e240 c0938a24
> c09f4c3c c09389c4 0001
> [ 322.326095] 7f80: c064d88c c0937fa8 c0080f04
> c00df35c 6013
> [ 322.334634] [] (__irq_svc) from []
> (ipipe_unstall_root+0x38/0x50)
> [ 322.342822] [] (ipipe_unstall_root) from []
> (cpu_startup_entry+0x68/0x2b8)
> [ 322.351826] [] (cpu_startup_entry) from []
> (start_kernel+0x370/0x3e8)
> [ 322.360361] ---[ end trace 3de49b4cee31ba0b ]---
>
> When other interrupts occur:
> [ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.378183] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.383277] ->action(): (null)
> [ 322.386641]IRQ_NOPROBE set
> [ 322.389825] unexpected IRQ trap at vector 8e
> [ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 324.677980] ->irq_data.chip(): df156710, 0xdf156710
> [ 324.683077] ->action(): (null)
> [ 324.686442]IRQ_NOPROBE set
> ...
>
>
>
> 3. Source code of the basic gpio interrupt driver:
>
> #include
> #include
> #include
> #include
>
> #include
>
>
> static unsigned int irq_num;
> // bbb gpios that work on PREEMPT_RT linux 4.19.59 and 5.4.5 with default
> dts
> static unsigned int gpio_out = 48;
> static unsigned int gpio_in = 115;
> static bool value = false;
> static rtdm_irq_t irq_handle;
> static int num_of_intr = 0;
>
>
> static int gpio_irq_handler(rtdm_irq_t * irq)
> {
> value = !value;
> gpio_set_value(gpio_out, value); // toggle the led everytime irq
> handler is invoked
> trace_printk("GPIO interrupt \n");
> num_of_intr++;
> return RTDM_IRQ_HANDLED;
> }
>
>
> static int __init rtdm_init (void)
> {
> int err;
>
> if ((err = gpio_request(gpio_in, THIS_MODULE->name)) != 0) {
> printk(" gpio_request gpio_in failed ! \n");
> return err;
> }
>
> if ((err =
system freeze - beaglebone black xenomai - gpio interrupts driver
Hello xenomai community,
I have successfully tested in xenomai SPI with interrupts on bbb.
However, on bbb, if I try to test a basic gpio interrupts driver,
problems appear.
Please see details below. I appreciate any idea.
1. xenomai-3 master linux 4.19.82, default dts
# insmod xeno_osc-gpio-rtdm.ko
[ 105.582245] IRQ number 62 !
[ 105.585976] after request irq = 62
System freeze when first interrupt occurs and I must power off.
2. xenomai 3.0.5 linux 4.4.71, default dts
# insmod xeno_osc-gpio-rtdm.ko
[ 39.901907] IRQ number 142 !
[ 39.905447] after request irq = 142
When first interrupt occurs:
[ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 322.117606] ->irq_data.chip(): df156710, 0xdf156710
[ 322.122702] ->action(): (null)
[ 322.126067]IRQ_NOPROBE set
[ 322.129252] unexpected IRQ trap at vector 8e
[ 322.133706] [ cut here ]
[ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843
__ipipe_ack_bad_irq+0x24/0x3c()
[ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O)
[ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
4.4.71-ipipe #1
[ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 322.166791] I-pipe domain: Linux
[ 322.170175] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 322.178273] [] (show_stack) from []
(dump_stack+0x9c/0xc4)
[ 322.185829] [] (dump_stack) from []
(warn_slowpath_common+0x78/0xb4)
[ 322.194280] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 322.203455] [] (warn_slowpath_null) from []
(__ipipe_ack_bad_irq+0x24/0x3c)
[ 322.212542] [] (__ipipe_ack_bad_irq) from []
(__ipipe_dispatch_irq+0x78/0x1d8)
[ 322.221903] [] (__ipipe_dispatch_irq) from []
(omap_gpio_irq_handler+0x134/0x1a4)
[ 322.231532] [] (omap_gpio_irq_handler) from []
(handle_irq_event_percpu+0xa4/0x304)
[ 322.241341] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x38/0x5c)
[ 322.250605] [] (handle_irq_event) from []
(handle_level_irq+0x88/0xe4)
[ 322.259235] [] (handle_level_irq) from []
(generic_handle_irq+0x20/0x34)
[ 322.268045] [] (generic_handle_irq) from []
(__handle_domain_irq+0x64/0xd4)
[ 322.277127] [] (__handle_domain_irq) from []
(__ipipe_do_sync_stage+0x21c/0x25c)
[ 322.286665] [] (__ipipe_do_sync_stage) from []
(__ipipe_grab_irq+0x5c/0x7c)
[ 322.295753] [] (__ipipe_grab_irq) from []
(__irq_svc+0x54/0x60)
[ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0)
[ 322.309017] 7f40:
df91d240
[ 322.317556] 7f60: c092e240 c0938a24
c09f4c3c c09389c4 0001
[ 322.326095] 7f80: c064d88c c0937fa8 c0080f04
c00df35c 6013
[ 322.334634] [] (__irq_svc) from []
(ipipe_unstall_root+0x38/0x50)
[ 322.342822] [] (ipipe_unstall_root) from []
(cpu_startup_entry+0x68/0x2b8)
[ 322.351826] [] (cpu_startup_entry) from []
(start_kernel+0x370/0x3e8)
[ 322.360361] ---[ end trace 3de49b4cee31ba0b ]---
When other interrupts occur:
[ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 322.378183] ->irq_data.chip(): df156710, 0xdf156710
[ 322.383277] ->action(): (null)
[ 322.386641]IRQ_NOPROBE set
[ 322.389825] unexpected IRQ trap at vector 8e
[ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 324.677980] ->irq_data.chip(): df156710, 0xdf156710
[ 324.683077] ->action(): (null)
[ 324.686442]IRQ_NOPROBE set
...
3. Source code of the basic gpio interrupt driver:
#include
#include
#include
#include
#include
static unsigned int irq_num;
// bbb gpios that work on PREEMPT_RT linux 4.19.59 and 5.4.5 with default dts
static unsigned int gpio_out = 48;
static unsigned int gpio_in = 115;
static bool value = false;
static rtdm_irq_t irq_handle;
static int num_of_intr = 0;
static int gpio_irq_handler(rtdm_irq_t * irq)
{
value = !value;
gpio_set_value(gpio_out, value); // toggle the led everytime irq
handler is invoked
trace_printk("GPIO interrupt \n");
num_of_intr++;
return RTDM_IRQ_HANDLED;
}
static int __init rtdm_init (void)
{
int err;
if ((err = gpio_request(gpio_in, THIS_MODULE->name)) != 0) {
printk(" gpio_request gpio_in failed ! \n");
return err;
}
if ((err = gpio_direction_input(gpio_in)) != 0) {
printk(" gpio_direction_input gpio_in failed ! \n");
gpio_free(gpio_in);
return err;
}
irq_num = gpio_to_irq(gpio_in);
printk(" IRQ number %d ! \n",irq_num);
if ((err = gpio_request(gpio_out, THIS_MODULE->name)) != 0) {
printk(" gpio_request gpio_out failed ! \n");
gpio_free(gpio_in);
return err;
}
if ((err = gpio_direction_output(gpio_out, 0)) != 0) {
printk("
[PATCH] spi: update Makefile and Kconfig to include bbb spi driver
Updated SPI Makefile and Kconfig in order to contain the option to compile am335x beaglebone black omap4 spi real-time driver. Signed-off-by: Laurentiu-Cristian Duca --- kernel/drivers/spi/Kconfig | 10 ++ kernel/drivers/spi/Makefile | 2 ++ 2 files changed, 12 insertions(+) diff --git a/kernel/drivers/spi/Kconfig b/kernel/drivers/spi/Kconfig index c2d47aa6c..b48aaf3f9 100644 --- a/kernel/drivers/spi/Kconfig +++ b/kernel/drivers/spi/Kconfig @@ -22,6 +22,16 @@ config XENO_DRIVERS_SPI_SUN6I Enables support for the SPI controller available from Allwinner's A31, H3 SoCs. +config XENO_DRIVERS_SPI_OMAP2_MCSPI_RT + tristate "McSPI rt-driver for OMAP" + depends on HAS_DMA + depends on ARCH_OMAP2PLUS || COMPILE_TEST + select XENO_DRIVERS_SPI + help + + SPI real-time master controller for OMAP24XX and later Multichannel SPI + (McSPI) modules. + config XENO_DRIVERS_SPI_DEBUG depends on XENO_DRIVERS_SPI bool "Enable SPI core debugging features" diff --git a/kernel/drivers/spi/Makefile b/kernel/drivers/spi/Makefile index 075641f92..889033c4f 100644 --- a/kernel/drivers/spi/Makefile +++ b/kernel/drivers/spi/Makefile @@ -7,6 +7,8 @@ xeno_spi-y := spi-master.o spi-device.o obj-$(CONFIG_XENO_DRIVERS_SPI_BCM2835) += xeno_spi_bcm2835.o obj-$(CONFIG_XENO_DRIVERS_SPI_SUN6I) += xeno_spi_sun6i.o +obj-$(CONFIG_XENO_DRIVERS_SPI_OMAP2_MCSPI_RT) += xeno_spi_omap2_mcspi_rt.o xeno_spi_bcm2835-y := spi-bcm2835.o xeno_spi_sun6i-y := spi-sun6i.o +xeno_spi_omap2_mcspi_rt-y := spi-omap2-mcspi-rt.o -- 2.17.1
[PATCH 4/5] am335x (beaglebone black) omap4 spi real-time driver.
From: Laurentiu-Cristian Duca spi-omap2-mcspi-rt.c: I/O handling is lifted from omap2/4 mcspi linux driver. The code follows the model in spi-bcm2835.c. The theoretical maximum spi frequency of am335x omap4 is 48MHz, and the driver practical maximum frequency is limited to 40MHz. The omap4 maximum fifo queue size is 64 bytes, but when the transfer implies both sending and receiving it is limited to 32, so, in the driver things are kept simple: max 32 for tx and max 32 for rx. When the driver must transfer N bytes then ((int)(N/32))*32 bytes are transfered with fifo queue size 32 and (N mod 32) bytes are transfered with fifo queue size (N mod 32); between fifo setup, the slave chip select line is kept active by using the FORCE bit in the channel configuration register. Signed-off-by: Laurentiu-Cristian Duca --- kernel/drivers/spi/spi-omap2-mcspi-rt.c | 999 1 file changed, 999 insertions(+) create mode 100644 kernel/drivers/spi/spi-omap2-mcspi-rt.c diff --git a/kernel/drivers/spi/spi-omap2-mcspi-rt.c b/kernel/drivers/spi/spi-omap2-mcspi-rt.c new file mode 100644 index 0..a7a005b22 --- /dev/null +++ b/kernel/drivers/spi/spi-omap2-mcspi-rt.c @@ -0,0 +1,999 @@ +/** + * I/O handling lifted from drivers/spi/spi-omap2-mcspi.c: + * Copyright (C) 2019 Laurentiu-Cristian Duca + * + * RTDM integration by: + * Copyright (C) 2016 Philippe Gerum + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "spi-master.h" + +#define RTDM_SUBCLASS_OMAP2_MCSPI 3 + +#define OMAP4_MCSPI_REG_OFFSET 0x100 +#define OMAP2_MCSPI_SPI_MODE_BITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH) + +#define OMAP2_MCSPI_MAX_FREQ 4800 +#define OMAP2_MCSPI_DRIVER_MAX_FREQ4000 +#define OMAP2_MCSPI_MAX_DIVIDER4096 +#define OMAP2_MCSPI_MAX_FIFODEPTH 64 +#define OMAP2_MCSPI_MAX_FIFOWCNT 0x +#define SPI_AUTOSUSPEND_TIMEOUT2000 +#define PM_NEGATIVE_DELAY -2000 + +#define OMAP2_MCSPI_REVISION 0x00 +#define OMAP2_MCSPI_SYSCONFIG 0x10 +#define OMAP2_MCSPI_SYSSTATUS 0x14 +#define OMAP2_MCSPI_IRQSTATUS 0x18 +#define OMAP2_MCSPI_IRQENABLE 0x1c +#define OMAP2_MCSPI_WAKEUPENABLE 0x20 +#define OMAP2_MCSPI_SYST 0x24 +#define OMAP2_MCSPI_MODULCTRL 0x28 +#define OMAP2_MCSPI_XFERLEVEL 0x7c + +/* per-channel (chip select) banks, 0x14 bytes each, first is: */ +#define OMAP2_MCSPI_CHANNELBANK_SIZE 0x14 +#define OMAP2_MCSPI_CHCONF00x2c +#define OMAP2_MCSPI_CHSTAT00x30 +#define OMAP2_MCSPI_CHCTRL00x34 +#define OMAP2_MCSPI_TX00x38 +#define OMAP2_MCSPI_RX00x3c + +/* per-register bitmasks: */ +#define OMAP2_MCSPI_IRQSTATUS_EOW BIT(17) +#define OMAP2_MCSPI_IRQSTATUS_RX1_FULL BIT(6) +#define OMAP2_MCSPI_IRQSTATUS_TX1_EMPTYBIT(4) +#define OMAP2_MCSPI_IRQSTATUS_RX0_FULL BIT(2) +#define OMAP2_MCSPI_IRQSTATUS_TX0_EMPTYBIT(0) + +#define OMAP2_MCSPI_IRQENABLE_EOW BIT(17) +#define OMAP2_MCSPI_IRQENABLE_RX1_FULL BIT(6) +#define OMAP2_MCSPI_IRQENABLE_TX1_EMPTYBIT(4) +#define OMAP2_MCSPI_IRQENABLE_RX0_FULL BIT(2) +#define OMAP2_MCSPI_IRQENABLE_TX0_EMPTYBIT(0) + +#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0) +#define OMAP2_MCSPI_MODULCTRL_MS BIT(2) +#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3) + +#define OMAP2_MCSPI_CHCONF_PHA BIT(0) +#define OMAP2_MCSPI_CHCONF_POL BIT(1) +#define OMAP2_MCSPI_CHCONF_CLKD_MASK (0x0f << 2) +#define OMAP2_MCSPI_CHCONF_EPOLBIT(6) +#define OMAP2_MCSPI_CHCONF_WL_MASK (0x1f << 7) +#define OMAP2_MCSPI_CHCONF_TRM_RX_ONLY BIT(12) +#define OMAP2_MCSPI_CHCONF_TRM_TX_ONLY BIT(13) +#define OMAP2_MCSPI_CHCONF_TRM_MASK(0x03 << 12) +#define OMAP2_MCSPI_CHCONF_DMAWBIT(14) +#define OMAP2_MCSPI_CHCONF_DMARBIT(15) +#define OMAP2_MCSPI_CHCONF_DPE0BIT(16) +#define OMAP2_MCSPI_CHCONF_DPE1BIT(17) +#define OMAP2_MCSPI_CHCONF_IS BIT(18) +#define OMAP2_MCSPI_CHCONF_TURBO
[PATCH 5/5] extending spitest with SPI_RTIOC_TRANSFER_N ioctl
From: Laurentiu-Cristian Duca
The ioctl_n user parameter must be set to non-zero value
in order to perform ioctl(SPI_RTIOC_TRANSFER_N, TRANSFER_SIZE);
if ioctl_n is 0 or undefined then the test performs ioctl(SPI_RTIOC_TRANSFER).
Default SPI clock speed is set to 40MHz instead of 60MHz
because bbb am335x realtime SPI driver has its maximum set to this value.
Signed-off-by: Laurentiu-Cristian Duca
---
testsuite/spitest/spitest.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/testsuite/spitest/spitest.c b/testsuite/spitest/spitest.c
index debf1b673..e3a1c6a44 100644
--- a/testsuite/spitest/spitest.c
+++ b/testsuite/spitest/spitest.c
@@ -40,17 +40,19 @@ smokey_test_plugin(spi_transfer,
SMOKEY_STRING(device),
SMOKEY_INT(speed),
SMOKEY_BOOL(latency),
+ SMOKEY_INT(ioctl_n)
),
"Run a SPI transfer.\n"
"\tdevice=\n"
"\tspeed=\n"
- "\tlatency"
+ "\tlatency\n"
+ "\tioctl_n="
);
#define ONE_BILLION10
#define TEN_MILLIONS 1000
-static int with_traffic = 1, with_latency;
+static int with_traffic = 1, with_latency, with_ioctl_n = 0;
#define SEQ_SHIFT 24
#define SEQ_MASK ((1 << SEQ_SHIFT) - 1)
@@ -311,8 +313,16 @@ static int do_spi_loop(int fd)
if (ret < 0)
break;
clock_gettime(CLOCK_MONOTONIC, );
- if (!__Terrno(ret, ioctl(fd, SPI_RTIOC_TRANSFER)))
- return ret;
+ if(with_ioctl_n == 0) {
+ if (!__Terrno(ret,
+ ioctl(fd, SPI_RTIOC_TRANSFER)))
+ return ret;
+ } else {
+if (!__Terrno(ret,
+ ioctl(fd, SPI_RTIOC_TRANSFER_N,
+ TRANSFER_SIZE)))
+return ret;
+ }
if (with_latency) {
clock_gettime(CLOCK_MONOTONIC, );
dt = (int32_t)diff_ts(, );
@@ -348,7 +358,7 @@ static int do_spi_loop(int fd)
static int run_spi_transfer(struct smokey_test *t, int argc, char
*const argv[])
{
- int fd, ret, speed_hz = 6000;
+ int fd, ret, speed_hz = 4000;
struct rtdm_spi_config config;
struct rtdm_spi_iobufs iobufs;
const char *device = NULL;
@@ -366,7 +376,12 @@ static int run_spi_transfer(struct smokey_test
*t, int argc, char *const argv[])
if (SMOKEY_ARG_ISSET(spi_transfer, speed))
speed_hz = SMOKEY_ARG_INT(spi_transfer, speed);
-
+
+if (SMOKEY_ARG_ISSET(spi_transfer, ioctl_n)) {
+ with_ioctl_n = SMOKEY_ARG_INT(spi_transfer, ioctl_n);
+ smokey_note("ioctl_n enabled; using SPI_RTIOC_TRANSFER_N");
+ }
+
if (!SMOKEY_ARG_ISSET(spi_transfer, device)) {
warning("missing device= specification");
return -EINVAL;
--
2.17.1
[PATCH 3/5] spi: add functions ..._transfer_iobufs_n()
From: Laurentiu-Cristian Duca
spi-bcm2835.c, spi-sun6i.c:
In order to support SPI_RTIOC_TRANSFER_N ioctl option
add functions bcm2835_transfer_iobufs_n() and sun6i_transfer_iobufs_n()
which are similar to ..._transfer_iobufs(),
but allow user specified len for spi transfer.
Signed-off-by: Laurentiu-Cristian Duca
---
kernel/drivers/spi/spi-bcm2835.c | 19 +++
kernel/drivers/spi/spi-sun6i.c | 19 +++
2 files changed, 38 insertions(+)
diff --git a/kernel/drivers/spi/spi-bcm2835.c b/kernel/drivers/spi/spi-bcm2835.c
index e4a95d081..fab6f6e77 100644
--- a/kernel/drivers/spi/spi-bcm2835.c
+++ b/kernel/drivers/spi/spi-bcm2835.c
@@ -318,6 +318,24 @@ static int bcm2835_transfer_iobufs(struct
rtdm_spi_remote_slave *slave)
return do_transfer_irq(slave);
}
+static int bcm2835_transfer_iobufs_n(struct rtdm_spi_remote_slave *slave,
+
int len)
+{
+ struct spi_master_bcm2835 *spim = to_master_bcm2835(slave);
+ struct spi_slave_bcm2835 *bcm = to_slave_bcm2835(slave);
+
+ if ((bcm->io_len == 0) ||
+ (len <= 0) || (len > (bcm->io_len / 2)))
+ return -EINVAL;
+
+ spim->tx_len = len;
+ spim->rx_len = len;
+ spim->tx_buf = bcm->io_virt + bcm->io_len / 2;
+ spim->rx_buf = bcm->io_virt;
+
+ return do_transfer_irq(slave);
+}
+
static ssize_t bcm2835_read(struct rtdm_spi_remote_slave *slave,
void *rx, size_t len)
{
@@ -549,6 +567,7 @@ static struct rtdm_spi_master_ops bcm2835_master_ops = {
.mmap_iobufs = bcm2835_mmap_iobufs,
.mmap_release = bcm2835_mmap_release,
.transfer_iobufs = bcm2835_transfer_iobufs,
+ .transfer_iobufs_n = bcm2835_transfer_iobufs_n,
.write = bcm2835_write,
.read = bcm2835_read,
.attach_slave = bcm2835_attach_slave,
diff --git a/kernel/drivers/spi/spi-sun6i.c b/kernel/drivers/spi/spi-sun6i.c
index ec08c98d8..940c98b31 100644
--- a/kernel/drivers/spi/spi-sun6i.c
+++ b/kernel/drivers/spi/spi-sun6i.c
@@ -355,6 +355,24 @@ static int sun6i_transfer_iobufs(struct
rtdm_spi_remote_slave *slave)
return do_transfer_irq(slave);
}
+static int sun6i_transfer_iobufs_n(struct rtdm_spi_remote_slave *slave,
+int len)
+{
+ struct spi_master_sun6i *spim = to_master_sun6i(slave);
+ struct spi_slave_sun6i *sun6i = to_slave_sun6i(slave);
+
+ if ((sun6i->io_len == 0) ||
+ (len <= 0) || (len > (sun6i->io_len / 2)))
+ return -EINVAL;
+
+ spim->tx_len = len;
+ spim->rx_len = len;
+ spim->tx_buf = sun6i->io_virt + sun6i->io_len / 2;
+ spim->rx_buf = sun6i->io_virt;
+
+ return do_transfer_irq(slave);
+}
+
static ssize_t sun6i_read(struct rtdm_spi_remote_slave *slave,
void *rx, size_t len)
{
@@ -480,6 +498,7 @@ static struct rtdm_spi_master_ops sun6i_master_ops = {
.mmap_iobufs = sun6i_mmap_iobufs,
.mmap_release = sun6i_mmap_release,
.transfer_iobufs = sun6i_transfer_iobufs,
+ .transfer_iobufs_n = sun6i_transfer_iobufs_n,
.write = sun6i_write,
.read = sun6i_read,
.attach_slave = sun6i_attach_slave,
--
2.17.1
[PATCH 2/5] spi: new SPI_RTIOC_TRANSFER_N ioctl option
From: Laurentiu-Cristian Duca
SPI_RTIOC_TRANSFER_N allows the user
to make SPI transfers of arbitrary lengths
by using the same mmapped memory area.
Signed-off-by: Laurentiu-Cristian Duca
---
include/rtdm/uapi/spi.h | 1 +
kernel/drivers/spi/spi-master.c | 15 ++-
kernel/drivers/spi/spi-master.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/rtdm/uapi/spi.h b/include/rtdm/uapi/spi.h
index 8f042377f..184a2b027 100644
--- a/include/rtdm/uapi/spi.h
+++ b/include/rtdm/uapi/spi.h
@@ -37,5 +37,6 @@ struct rtdm_spi_iobufs {
#define SPI_RTIOC_GET_CONFIG _IOR(RTDM_CLASS_SPI, 1, struct
rtdm_spi_config)
#define SPI_RTIOC_SET_IOBUFS _IOR(RTDM_CLASS_SPI, 2, struct
rtdm_spi_iobufs)
#define SPI_RTIOC_TRANSFER _IO(RTDM_CLASS_SPI, 3)
+#define SPI_RTIOC_TRANSFER_N _IOR(RTDM_CLASS_SPI, 4, int)
#endif /* !_RTDM_UAPI_SPI_H */
diff --git a/kernel/drivers/spi/spi-master.c b/kernel/drivers/spi/spi-master.c
index e04f7ca10..104af8023 100644
--- a/kernel/drivers/spi/spi-master.c
+++ b/kernel/drivers/spi/spi-master.c
@@ -150,7 +150,7 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
struct rtdm_spi_remote_slave *slave = fd_to_slave(fd);
struct rtdm_spi_master *master = slave->master;
struct rtdm_spi_config config;
- int ret;
+ int ret, len;
switch (request) {
case SPI_RTIOC_SET_CONFIG:
@@ -178,6 +178,19 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
rtdm_mutex_unlock(>bus_lock);
}
break;
+ case SPI_RTIOC_TRANSFER_N:
+ ret = -EINVAL;
+ if (master->ops->transfer_iobufs_n) {
+ len = (int)arg;
+ rtdm_mutex_lock(>bus_lock);
+ ret = do_chip_select(slave);
+ if (ret == 0) {
+ ret = master->ops->transfer_iobufs_n(slave,
len);
+ do_chip_deselect(slave);
+ }
+ rtdm_mutex_unlock(>bus_lock);
+ }
+ break;
default:
ret = -ENOSYS;
}
diff --git a/kernel/drivers/spi/spi-master.h b/kernel/drivers/spi/spi-master.h
index b5a9ce762..ecfea2f90 100644
--- a/kernel/drivers/spi/spi-master.h
+++ b/kernel/drivers/spi/spi-master.h
@@ -39,6 +39,7 @@ struct rtdm_spi_master_ops {
struct vm_area_struct *vma);
void (*mmap_release)(struct rtdm_spi_remote_slave *slave);
int (*transfer_iobufs)(struct rtdm_spi_remote_slave *slave);
+ int (*transfer_iobufs_n)(struct rtdm_spi_remote_slave *slave, int len);
ssize_t (*write)(struct rtdm_spi_remote_slave *slave,
const void *tx, size_t len);
ssize_t (*read)(struct rtdm_spi_remote_slave *slave,
--
2.17.1
[PATCH 1/5] spi: fix read() return code checking in spi_master_read_rt()
From: Laurentiu-Cristian Duca spi-master.c: spi_master_read_rt(): when master->ops->read() completes successfully it returns > 0, so, in this case, copy data to userspace. Signed-off-by: Laurentiu-Cristian Duca --- kernel/drivers/spi/spi-master.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/drivers/spi/spi-master.c b/kernel/drivers/spi/spi-master.c index 12a1ad1f1..e04f7ca10 100644 --- a/kernel/drivers/spi/spi-master.c +++ b/kernel/drivers/spi/spi-master.c @@ -240,8 +240,8 @@ static ssize_t spi_master_read_rt(struct rtdm_fd *fd, do_chip_deselect(slave); } rtdm_mutex_unlock(>bus_lock); - if (ret == 0) - ret = rtdm_safe_copy_to_user(fd, u_buf, rx, len); + if (ret > 0) + ret = rtdm_safe_copy_to_user(fd, u_buf, rx, ret); xnfree(rx); -- 2.17.1
Re: [patch 2/5] SPI_RTIOC_TRANSFER_N ioctl with len parameter
Hi Nitin, rpi 3b has bcm2837 chip. Xenomai SPI drivers are for bcm2835. I only tested bcm2835 drivers on rpi 0. However, from rpi doc: "Note that the BCM2837 processor is an evolution of the BCM2835 processor. The only real differences are that the BCM2837 can address more RAM (up to 1Gbyte) and the ARM CPU complex has been upgraded from a single core ARM11 in BCM2835 to a Quad core Cortex A53 with dedicated 512Kbyte L2 cache in BCM2837. All IO interfaces and peripherals stay the same and hence the two chips are largely software and hardware compatible." On 1/9/20, Nitin Kulkarni wrote: >> >> Date: Mon, 30 Dec 2019 17:07:21 +0200 >> From: Laurentiu-Cristian Duca >> To: xenomai >> Subject: [patch 2/5] SPI_RTIOC_TRANSFER_N ioctl with len parameter >> Message-ID: >> > uxrvjbmsxd-7uclmke56xhkk6zy_iss9...@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> >From d47ede0283b68ac972d7f6a4b87ba1caa4fa9d5f Mon Sep 17 00:00:00 2001 >> From: Laurentiu-Cristian Duca >> Date: Mon, 23 Dec 2019 16:49:05 +0200 >> Subject: [PATCH] SPI_RTIOC_TRANSFER_N ioctl with len parameter to >> transfer >> only len bytes to SPI slave >> >> Note that set_iobufs() used in xenomai-spi-drivers >> (spi-bcm2835.c and other drivers using its model) >> allocates for the user ioctl(SPI_RTIOC_SET_IOBUFS) >> len = L1_CACHE_ALIGN(len) * 2; >> (half for tx and half for rx) >> which in case of am335x for example the resulted len will be greater than >> 2 multiplied with user requested len. So, ioctl(SPI_RTIOC_TRANSFER) >> will transfer more bytes than requested in case of am335x. >> Hence, a new ioctl(SPI_RTIOC_TRANSFER_N, int requested_len) was added >> to transfer only requested_len bytes to SPI slave. >> > > For the above patch that you submitted a few days ago, > I just wanted to know if you tested on RPI 3B or 3B+ board ? > I had some issues with the Xenomai SPI RTDM drivers with RPI 3B+. > It was long back but what I can remember is that the GPIO interrupts were > working fine with rtdm interrupts but none of the peripheral devices' > interrupts were working. > > Since the SPI RTDM driver works in interrupt mode, I couldn't use it and > had to go for a polling based driver. Just want to confirm if you didn't > have to do anything special to use the xenomai drivers for SPI on RPI > 3B/3B+. > > Thanks, > Nitin >
Re: [patch 2/5] SPI_RTIOC_TRANSFER_N ioctl with len parameter
SPI_RTIOC_TRANSFER_N is also useful because it allows
the user to make SPI transfers of arbitrary length
by using the same mmapped memory area.
On 12/30/19, Laurentiu-Cristian Duca wrote:
> From d47ede0283b68ac972d7f6a4b87ba1caa4fa9d5f Mon Sep 17 00:00:00 2001
> From: Laurentiu-Cristian Duca
> Date: Mon, 23 Dec 2019 16:49:05 +0200
> Subject: [PATCH] SPI_RTIOC_TRANSFER_N ioctl with len parameter to transfer
> only len bytes to SPI slave
>
> Note that set_iobufs() used in xenomai-spi-drivers
> (spi-bcm2835.c and other drivers using its model)
> allocates for the user ioctl(SPI_RTIOC_SET_IOBUFS)
> len = L1_CACHE_ALIGN(len) * 2;
> (half for tx and half for rx)
> which in case of am335x for example the resulted len will be greater than
> 2 multiplied with user requested len. So, ioctl(SPI_RTIOC_TRANSFER)
> will transfer more bytes than requested in case of am335x.
> Hence, a new ioctl(SPI_RTIOC_TRANSFER_N, int requested_len) was added
> to transfer only requested_len bytes to SPI slave.
>
> Signed-off-by: Laurentiu-Cristian Duca
> ---
> include/rtdm/uapi/spi.h | 1 +
> kernel/drivers/spi/spi-master.c | 15 ++-
> kernel/drivers/spi/spi-master.h | 1 +
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/include/rtdm/uapi/spi.h b/include/rtdm/uapi/spi.h
> index 8f042377f..001d08ab7 100644
> --- a/include/rtdm/uapi/spi.h
> +++ b/include/rtdm/uapi/spi.h
> @@ -37,5 +37,6 @@ struct rtdm_spi_iobufs {
> #define SPI_RTIOC_GET_CONFIG _IOR(RTDM_CLASS_SPI, 1, struct
> rtdm_spi_config)
> #define SPI_RTIOC_SET_IOBUFS _IOR(RTDM_CLASS_SPI, 2, struct
> rtdm_spi_iobufs)
> #define SPI_RTIOC_TRANSFER _IO(RTDM_CLASS_SPI, 3)
> +#define SPI_RTIOC_TRANSFER_N_IOR(RTDM_CLASS_SPI, 4, int)
>
> #endif /* !_RTDM_UAPI_SPI_H */
> diff --git a/kernel/drivers/spi/spi-master.c
> b/kernel/drivers/spi/spi-master.c
> index e04f7ca10..104af8023 100644
> --- a/kernel/drivers/spi/spi-master.c
> +++ b/kernel/drivers/spi/spi-master.c
> @@ -150,7 +150,7 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
> struct rtdm_spi_remote_slave *slave = fd_to_slave(fd);
> struct rtdm_spi_master *master = slave->master;
> struct rtdm_spi_config config;
> - int ret;
> + int ret, len;
>
> switch (request) {
> case SPI_RTIOC_SET_CONFIG:
> @@ -178,6 +178,19 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
> rtdm_mutex_unlock(>bus_lock);
> }
> break;
> + case SPI_RTIOC_TRANSFER_N:
> + ret = -EINVAL;
> + if (master->ops->transfer_iobufs_n) {
> + len = (int)arg;
> + rtdm_mutex_lock(>bus_lock);
> + ret = do_chip_select(slave);
> + if (ret == 0) {
> + ret = master->ops->transfer_iobufs_n(slave,
> len);
> + do_chip_deselect(slave);
> + }
> + rtdm_mutex_unlock(>bus_lock);
> + }
> + break;
> default:
> ret = -ENOSYS;
> }
> diff --git a/kernel/drivers/spi/spi-master.h
> b/kernel/drivers/spi/spi-master.h
> index b5a9ce762..ecfea2f90 100644
> --- a/kernel/drivers/spi/spi-master.h
> +++ b/kernel/drivers/spi/spi-master.h
> @@ -39,6 +39,7 @@ struct rtdm_spi_master_ops {
> struct vm_area_struct *vma);
> void (*mmap_release)(struct rtdm_spi_remote_slave *slave);
> int (*transfer_iobufs)(struct rtdm_spi_remote_slave *slave);
> + int (*transfer_iobufs_n)(struct rtdm_spi_remote_slave *slave, int len);
> ssize_t (*write)(struct rtdm_spi_remote_slave *slave,
>const void *tx, size_t len);
> ssize_t (*read)(struct rtdm_spi_remote_slave *slave,
> --
> 2.17.1
>
[patch 5/5] spitest.c: adding ioctl(SPI_RTIOC_TRANSFER_N, TRANSFER_SIZE)
>From a642fc578486af9f232033db216cdff8f27ab779 Mon Sep 17 00:00:00 2001
From: Laurentiu-Cristian Duca
Date: Mon, 30 Dec 2019 16:53:21 +0200
Subject: [PATCH] spitest.c: extending spi_transfer test in order to allow
testing ioctl(SPI_RTIOC_TRANSFER_N, TRANSFER_SIZE) via ioctl_n parameter
- the ioctl_n user parameter must be set to non-zero value
in order to perform ioctl(SPI_RTIOC_TRANSFER_N, TRANSFER_SIZE);
if ioctl_n is 0 or undefined then the test performs ioctl(SPI_RTIOC_TRANSFER).
- default SPI clock speed set to 40MHz
because bbb am335x realtime SPI driver has its maximum set to this value.
Signed-off-by: Laurentiu-Cristian Duca
---
testsuite/spitest/spitest.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/testsuite/spitest/spitest.c b/testsuite/spitest/spitest.c
index debf1b673..2ca25f457 100644
--- a/testsuite/spitest/spitest.c
+++ b/testsuite/spitest/spitest.c
@@ -40,17 +40,19 @@ smokey_test_plugin(spi_transfer,
SMOKEY_STRING(device),
SMOKEY_INT(speed),
SMOKEY_BOOL(latency),
+ SMOKEY_INT(ioctl_n)
),
"Run a SPI transfer.\n"
"\tdevice=\n"
"\tspeed=\n"
- "\tlatency"
+ "\tlatency\n"
+ "\tioctl_n="
);
#define ONE_BILLION10
#define TEN_MILLIONS 1000
-static int with_traffic = 1, with_latency;
+static int with_traffic = 1, with_latency, with_ioctl_n = 0;
#define SEQ_SHIFT 24
#define SEQ_MASK ((1 << SEQ_SHIFT) - 1)
@@ -311,8 +313,16 @@ static int do_spi_loop(int fd)
if (ret < 0)
break;
clock_gettime(CLOCK_MONOTONIC, );
- if (!__Terrno(ret, ioctl(fd, SPI_RTIOC_TRANSFER)))
- return ret;
+ if(with_ioctl_n == 0) {
+ if (!__Terrno(ret,
+ ioctl(fd, SPI_RTIOC_TRANSFER)))
+ return ret;
+ } else {
+if (!__Terrno(ret,
+ ioctl(fd, SPI_RTIOC_TRANSFER_N,
+ TRANSFER_SIZE)))
+return ret;
+ }
if (with_latency) {
clock_gettime(CLOCK_MONOTONIC, );
dt = (int32_t)diff_ts(, );
@@ -348,7 +358,7 @@ static int do_spi_loop(int fd)
static int run_spi_transfer(struct smokey_test *t, int argc, char
*const argv[])
{
- int fd, ret, speed_hz = 6000;
+ int fd, ret, speed_hz = 4000;
struct rtdm_spi_config config;
struct rtdm_spi_iobufs iobufs;
const char *device = NULL;
@@ -366,7 +376,12 @@ static int run_spi_transfer(struct smokey_test
*t, int argc, char *const argv[])
if (SMOKEY_ARG_ISSET(spi_transfer, speed))
speed_hz = SMOKEY_ARG_INT(spi_transfer, speed);
-
+
+if (SMOKEY_ARG_ISSET(spi_transfer, ioctl_n)) {
+ with_ioctl_n = SMOKEY_ARG_INT(spi_transfer, ioctl_n);
+ smokey_note("ioctl_n enabled; using SPI_RTIOC_TRANSFER_N");
+ }
+
if (!SMOKEY_ARG_ISSET(spi_transfer, device)) {
warning("missing device= specification");
return -EINVAL;
--
2.17.1
[patch 4/5] spi-omap2-mcspi-rt.c: am335x (beaglebone black) omap4 spi real-time driver
>From ad798823570c001f640e9ab353ce3362d02f5777 Mon Sep 17 00:00:00 2001 From: Laurentiu-Cristian Duca Date: Sat, 28 Dec 2019 12:13:17 +0200 Subject: [PATCH] spi-omap2-mcspi-rt.c: am335x (beaglebone black) omap4 spi real-time driver I/O handling is lifted from omap2/4 mcspi linux driver. The code follows the model in spi-bcm2835.c. The theoretical maximum spi frequency of am335x omap4 is 48MHz, and the driver practical maximum frequency is limited to 40MHz. The omap4 maximum fifo queue size is 64 bytes, but when the transfer implies both sending and receiving it is limited to 32, so, in the driver things are kept simple: max 32 for tx and max 32 for rx. When the driver must transfer N bytes then ((int)(N/32))*32 bytes are transfered with fifo queue size 32 and (N mod 32) bytes are transfered with fifo queue size (N mod 32); between fifo setup, the slave chip select line is kept active by using the FORCE bit in the channel configuration register. Signed-off-by: Laurentiu-Cristian Duca --- kernel/drivers/spi/spi-omap2-mcspi-rt.c | 1003 +++ 1 file changed, 1003 insertions(+) create mode 100644 kernel/drivers/spi/spi-omap2-mcspi-rt.c diff --git a/kernel/drivers/spi/spi-omap2-mcspi-rt.c b/kernel/drivers/spi/spi-omap2-mcspi-rt.c new file mode 100644 index 0..578d3fce5 --- /dev/null +++ b/kernel/drivers/spi/spi-omap2-mcspi-rt.c @@ -0,0 +1,1003 @@ +/** + * I/O handling lifted from drivers/spi/spi-omap2-mcspi.c: + * Copyright (C) 2019 Laurentiu-Cristian Duca + * + * RTDM integration by: + * Copyright (C) 2016 Philippe Gerum + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "spi-master.h" + +#define RTDM_SUBCLASS_OMAP2_MCSPI 3 + +#define OMAP4_MCSPI_REG_OFFSET 0x100 +#define OMAP2_MCSPI_SPI_MODE_BITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH) + +#define OMAP2_MCSPI_MAX_FREQ 4800 +#define OMAP2_MCSPI_DRIVER_MAX_FREQ4000 +#define OMAP2_MCSPI_MAX_DIVIDER4096 +#define OMAP2_MCSPI_MAX_FIFODEPTH 64 +#define OMAP2_MCSPI_MAX_FIFOWCNT 0x +#define SPI_AUTOSUSPEND_TIMEOUT2000 +#define PM_NEGATIVE_DELAY -2000 + +#define OMAP2_MCSPI_REVISION 0x00 +#define OMAP2_MCSPI_SYSCONFIG 0x10 +#define OMAP2_MCSPI_SYSSTATUS 0x14 +#define OMAP2_MCSPI_IRQSTATUS 0x18 +#define OMAP2_MCSPI_IRQENABLE 0x1c +#define OMAP2_MCSPI_WAKEUPENABLE 0x20 +#define OMAP2_MCSPI_SYST 0x24 +#define OMAP2_MCSPI_MODULCTRL 0x28 +#define OMAP2_MCSPI_XFERLEVEL 0x7c + +/* per-channel (chip select) banks, 0x14 bytes each, first is: */ +#define OMAP2_MCSPI_CHANNELBANK_SIZE 0x14 +#define OMAP2_MCSPI_CHCONF00x2c +#define OMAP2_MCSPI_CHSTAT00x30 +#define OMAP2_MCSPI_CHCTRL00x34 +#define OMAP2_MCSPI_TX00x38 +#define OMAP2_MCSPI_RX00x3c + +/* per-register bitmasks: */ +#define OMAP2_MCSPI_IRQSTATUS_EOW BIT(17) +#define OMAP2_MCSPI_IRQSTATUS_RX1_FULL BIT(6) +#define OMAP2_MCSPI_IRQSTATUS_TX1_EMPTYBIT(4) +#define OMAP2_MCSPI_IRQSTATUS_RX0_FULL BIT(2) +#define OMAP2_MCSPI_IRQSTATUS_TX0_EMPTYBIT(0) + +#define OMAP2_MCSPI_IRQENABLE_EOW BIT(17) +#define OMAP2_MCSPI_IRQENABLE_RX1_FULL BIT(6) +#define OMAP2_MCSPI_IRQENABLE_TX1_EMPTYBIT(4) +#define OMAP2_MCSPI_IRQENABLE_RX0_FULL BIT(2) +#define OMAP2_MCSPI_IRQENABLE_TX0_EMPTYBIT(0) + +#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0) +#define OMAP2_MCSPI_MODULCTRL_MS BIT(2) +#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3) + +#define OMAP2_MCSPI_CHCONF_PHA BIT(0) +#define OMAP2_MCSPI_CHCONF_POL BIT(1) +#define OMAP2_MCSPI_CHCONF_CLKD_MASK (0x0f << 2) +#define OMAP2_MCSPI_CHCONF_EPOLBIT(6) +#define OMAP2_MCSPI_CHCONF_WL_MASK (0x1f << 7) +#define OMAP2_MCSPI_CHCONF_TRM_RX_ONLY BIT(12) +#define OMAP2_MCSPI_CHCONF_TRM_TX_ONLY BIT(13) +#define OMAP2_MCSPI_CHCONF_TRM_MASK(0x03 << 12) +#define OMAP2_MCSPI_CHCONF_DMAWBIT(14) +#define OMAP2_MCSPI_CHCONF_DMARBIT(15) +#define
[patch 2/5] SPI_RTIOC_TRANSFER_N ioctl with len parameter
>From d47ede0283b68ac972d7f6a4b87ba1caa4fa9d5f Mon Sep 17 00:00:00 2001
From: Laurentiu-Cristian Duca
Date: Mon, 23 Dec 2019 16:49:05 +0200
Subject: [PATCH] SPI_RTIOC_TRANSFER_N ioctl with len parameter to transfer
only len bytes to SPI slave
Note that set_iobufs() used in xenomai-spi-drivers
(spi-bcm2835.c and other drivers using its model)
allocates for the user ioctl(SPI_RTIOC_SET_IOBUFS)
len = L1_CACHE_ALIGN(len) * 2;
(half for tx and half for rx)
which in case of am335x for example the resulted len will be greater than
2 multiplied with user requested len. So, ioctl(SPI_RTIOC_TRANSFER)
will transfer more bytes than requested in case of am335x.
Hence, a new ioctl(SPI_RTIOC_TRANSFER_N, int requested_len) was added
to transfer only requested_len bytes to SPI slave.
Signed-off-by: Laurentiu-Cristian Duca
---
include/rtdm/uapi/spi.h | 1 +
kernel/drivers/spi/spi-master.c | 15 ++-
kernel/drivers/spi/spi-master.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/rtdm/uapi/spi.h b/include/rtdm/uapi/spi.h
index 8f042377f..001d08ab7 100644
--- a/include/rtdm/uapi/spi.h
+++ b/include/rtdm/uapi/spi.h
@@ -37,5 +37,6 @@ struct rtdm_spi_iobufs {
#define SPI_RTIOC_GET_CONFIG _IOR(RTDM_CLASS_SPI, 1, struct
rtdm_spi_config)
#define SPI_RTIOC_SET_IOBUFS _IOR(RTDM_CLASS_SPI, 2, struct
rtdm_spi_iobufs)
#define SPI_RTIOC_TRANSFER _IO(RTDM_CLASS_SPI, 3)
+#define SPI_RTIOC_TRANSFER_N_IOR(RTDM_CLASS_SPI, 4, int)
#endif /* !_RTDM_UAPI_SPI_H */
diff --git a/kernel/drivers/spi/spi-master.c b/kernel/drivers/spi/spi-master.c
index e04f7ca10..104af8023 100644
--- a/kernel/drivers/spi/spi-master.c
+++ b/kernel/drivers/spi/spi-master.c
@@ -150,7 +150,7 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
struct rtdm_spi_remote_slave *slave = fd_to_slave(fd);
struct rtdm_spi_master *master = slave->master;
struct rtdm_spi_config config;
- int ret;
+ int ret, len;
switch (request) {
case SPI_RTIOC_SET_CONFIG:
@@ -178,6 +178,19 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
rtdm_mutex_unlock(>bus_lock);
}
break;
+ case SPI_RTIOC_TRANSFER_N:
+ ret = -EINVAL;
+ if (master->ops->transfer_iobufs_n) {
+ len = (int)arg;
+ rtdm_mutex_lock(>bus_lock);
+ ret = do_chip_select(slave);
+ if (ret == 0) {
+ ret = master->ops->transfer_iobufs_n(slave,
len);
+ do_chip_deselect(slave);
+ }
+ rtdm_mutex_unlock(>bus_lock);
+ }
+ break;
default:
ret = -ENOSYS;
}
diff --git a/kernel/drivers/spi/spi-master.h b/kernel/drivers/spi/spi-master.h
index b5a9ce762..ecfea2f90 100644
--- a/kernel/drivers/spi/spi-master.h
+++ b/kernel/drivers/spi/spi-master.h
@@ -39,6 +39,7 @@ struct rtdm_spi_master_ops {
struct vm_area_struct *vma);
void (*mmap_release)(struct rtdm_spi_remote_slave *slave);
int (*transfer_iobufs)(struct rtdm_spi_remote_slave *slave);
+ int (*transfer_iobufs_n)(struct rtdm_spi_remote_slave *slave, int len);
ssize_t (*write)(struct rtdm_spi_remote_slave *slave,
const void *tx, size_t len);
ssize_t (*read)(struct rtdm_spi_remote_slave *slave,
--
2.17.1
Re: [patch 1/4] fix: spi_master_read_rt()
On 12/20/19, Jan Kiszka wrote: > On 20.12.19 12:14, Laurentiu-Cristian Duca via Xenomai wrote: >> From 6e9138e92a4b9a3f163faeb4ad04f257157fd2f5 Mon Sep 17 00:00:00 2001 >> From: Laurentiu-Cristian Duca >> Date: Fri, 20 Dec 2019 13:00:42 +0200 >> Subject: [PATCH] - spi_master_read_rt(): if master->ops->read() returns > >> 0, >> then copy data to userspace. >> > > I'm lacking a little bit the description of the issue here, means a > brief but catchy subject line and then some separate paragraph which > explains /why/ we need the change. > >> Signed-off-by: Laurentiu-Cristian Duca >> --- >> kernel/drivers/spi/spi-master.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/drivers/spi/spi-master.c >> b/kernel/drivers/spi/spi-master.c >> index 12a1ad1f1..1e81bd02e 100644 >> --- a/kernel/drivers/spi/spi-master.c >> +++ b/kernel/drivers/spi/spi-master.c >> @@ -240,7 +240,7 @@ static ssize_t spi_master_read_rt(struct rtdm_fd *fd, >> do_chip_deselect(slave); >> } >> rtdm_mutex_unlock(>bus_lock); >> -if (ret == 0) >> +if (ret > 0) >> ret = rtdm_safe_copy_to_user(fd, u_buf, rx, len); >> >> xnfree(rx); >> > > To my reading of the two existing master drivers, this change is not > needed so far. They either return < 0 on error or the requested length > on success. > > However, I see the point that, if the interface should be "return the > actual length", we should only copy back that length. But that's also > not what the change does because that would require passing ret as > length to copy_to_user, rather than len. Am I missing something? > The error was in the line "if (ret == 0)" which is false when the read successfully returns len and the copy_to_user does not happen. So I put "if (ret > 0)". Indeed, instead of len should pass ret to copy_to_user as a follow of read() definition. > BTW, this claims to be patch 1 of 4, but the other three are still > missing on the list. I reduce the number of patches from 4 to 2 (this error correction and bbb spi rt driver) by postponing the ioctl() enhancement (allowing user to send less data than mmaped - which I have tested on rpi and bbb, but further tests need to be done for spi-sun6i.c and I do not have the board) until implementing a public test (eventually in spitest.c). Thanks for kindness, L-C. > > Regarding submission format: buildroot has a nice setup tutorial how to > route local git commits to mailing lists, individually or as series. > Have a look at > https://buildroot.org/downloads/manual/manual.html#submitting-patches, > specifically "Preparing a patch series". > > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux >
Re: am335x omap4 beaglebone black spi rt driver
It is a fix for: - spi_master_read_rt(): if master->ops->read() returns > 0, then copy data to userspace; and two contributions: - add a user option in ioctl to be able to transfer a part of mmaped area (and not all mmaped area every time) tested with a personal test this needs an official test (I did not study the source of spitest.c in detail) - bbb spi rt driver - tested with spitest and the personal test On 12/19/19, Jan Kiszka wrote: > Thanks for the contribution! > > Some quick requests: First, please split up the changes to the SPI core > and the addition of the new driver. Should give 2, if not 3 pieces in > the end. > > Then is there a chance to extend testsuite/spitest/spitest.c in order to > cover also the new interface (ioctl)? > > Last: There is the kernel's scripts/checkpatch.pl tool which can help > with identifying small glitches in the patch format. Please apply this > to keep our code (widely) consistent. > > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux >
[patch 1/4] fix: spi_master_read_rt()
>From 6e9138e92a4b9a3f163faeb4ad04f257157fd2f5 Mon Sep 17 00:00:00 2001 From: Laurentiu-Cristian Duca Date: Fri, 20 Dec 2019 13:00:42 +0200 Subject: [PATCH] - spi_master_read_rt(): if master->ops->read() returns > 0, then copy data to userspace. Signed-off-by: Laurentiu-Cristian Duca --- kernel/drivers/spi/spi-master.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/drivers/spi/spi-master.c b/kernel/drivers/spi/spi-master.c index 12a1ad1f1..1e81bd02e 100644 --- a/kernel/drivers/spi/spi-master.c +++ b/kernel/drivers/spi/spi-master.c @@ -240,7 +240,7 @@ static ssize_t spi_master_read_rt(struct rtdm_fd *fd, do_chip_deselect(slave); } rtdm_mutex_unlock(>bus_lock); - if (ret == 0) + if (ret > 0) ret = rtdm_safe_copy_to_user(fd, u_buf, rx, len); xnfree(rx); -- 2.17.1
am335x omap4 beaglebone black spi rt driver
>From f29ae3372aec94703139b75b7acb5608c8bf62fd Mon Sep 17 00:00:00 2001
From: Laurentiu-Cristian Duca
Date: Thu, 19 Dec 2019 18:28:20 +0200
Subject: [PATCH] - am335x (beaglebone black) omap4 mcspi real-time driver,
with I/O handling lifted from omap2/4 mcspi linux driver -
SPI_RTIOC_TRANSFER_N ioctl option to transfer only len bytes from mmaped
region - spi_master_read_rt(): if master->ops->read() returns > 0, then copy
data to userspace.
Signed-off-by: Laurentiu-Cristian Duca
---
include/rtdm/uapi/spi.h | 1 +
kernel/drivers/spi/Kconfig | 10 +
kernel/drivers/spi/Makefile | 5 +-
kernel/drivers/spi/spi-bcm2835.c| 19 +
kernel/drivers/spi/spi-master.c | 17 +-
kernel/drivers/spi/spi-master.h | 1 +
kernel/drivers/spi/spi-omap2-mcspi-rt.c | 989
7 files changed, 1038 insertions(+), 4 deletions(-)
create mode 100644 kernel/drivers/spi/spi-omap2-mcspi-rt.c
diff --git a/include/rtdm/uapi/spi.h b/include/rtdm/uapi/spi.h
index 8f042377f..001d08ab7 100644
--- a/include/rtdm/uapi/spi.h
+++ b/include/rtdm/uapi/spi.h
@@ -37,5 +37,6 @@ struct rtdm_spi_iobufs {
#define SPI_RTIOC_GET_CONFIG _IOR(RTDM_CLASS_SPI, 1, struct
rtdm_spi_config)
#define SPI_RTIOC_SET_IOBUFS _IOR(RTDM_CLASS_SPI, 2, struct
rtdm_spi_iobufs)
#define SPI_RTIOC_TRANSFER _IO(RTDM_CLASS_SPI, 3)
+#define SPI_RTIOC_TRANSFER_N_IOR(RTDM_CLASS_SPI, 4, int)
#endif /* !_RTDM_UAPI_SPI_H */
diff --git a/kernel/drivers/spi/Kconfig b/kernel/drivers/spi/Kconfig
index c2d47aa6c..bf5dab0e8 100644
--- a/kernel/drivers/spi/Kconfig
+++ b/kernel/drivers/spi/Kconfig
@@ -22,6 +22,16 @@ config XENO_DRIVERS_SPI_SUN6I
Enables support for the SPI controller available from
Allwinner's A31, H3 SoCs.
+config XENO_DRIVERS_SPI_OMAP2_MCSPI_RT
+ tristate "McSPI rt-driver for OMAP"
+ depends on HAS_DMA
+ depends on ARCH_OMAP2PLUS || COMPILE_TEST
+ select XENO_DRIVERS_SPI
+ help
+
+ SPI real-time master controller for OMAP24XX and later Multichannel SPI
+ (McSPI) modules.
+
config XENO_DRIVERS_SPI_DEBUG
depends on XENO_DRIVERS_SPI
bool "Enable SPI core debugging features"
diff --git a/kernel/drivers/spi/Makefile b/kernel/drivers/spi/Makefile
index 075641f92..07e5d11fb 100644
--- a/kernel/drivers/spi/Makefile
+++ b/kernel/drivers/spi/Makefile
@@ -3,10 +3,11 @@ ccflags-$(CONFIG_XENO_DRIVERS_SPI_DEBUG) := -DDEBUG
obj-$(CONFIG_XENO_DRIVERS_SPI) += xeno_spi.o
-xeno_spi-y := spi-master.o spi-device.o
-
obj-$(CONFIG_XENO_DRIVERS_SPI_BCM2835) += xeno_spi_bcm2835.o
obj-$(CONFIG_XENO_DRIVERS_SPI_SUN6I) += xeno_spi_sun6i.o
+obj-$(CONFIG_XENO_DRIVERS_SPI_OMAP2_MCSPI_RT) += xeno_spi_omap2_mcspi_rt.o
+xeno_spi-y := spi-master.o spi-device.o
xeno_spi_bcm2835-y := spi-bcm2835.o
xeno_spi_sun6i-y := spi-sun6i.o
+xeno_spi_omap2_mcspi_rt-y := spi-omap2-mcspi-rt.o
\ No newline at end of file
diff --git a/kernel/drivers/spi/spi-bcm2835.c b/kernel/drivers/spi/spi-bcm2835.c
index e4a95d081..696a1fd89 100644
--- a/kernel/drivers/spi/spi-bcm2835.c
+++ b/kernel/drivers/spi/spi-bcm2835.c
@@ -318,6 +318,24 @@ static int bcm2835_transfer_iobufs(struct
rtdm_spi_remote_slave *slave)
return do_transfer_irq(slave);
}
+static int bcm2835_transfer_iobufs_n(struct rtdm_spi_remote_slave *slave,
+
int len)
+{
+ struct spi_master_bcm2835 *spim = to_master_bcm2835(slave);
+ struct spi_slave_bcm2835 *bcm = to_slave_bcm2835(slave);
+
+ if ((bcm->io_len == 0) ||
+ (len <= 0) || (len > (bcm->io_len / 2)))
+ return -EINVAL;
+
+ spim->tx_len = len;
+ spim->rx_len = len;
+ spim->tx_buf = bcm->io_virt + bcm->io_len / 2;
+ spim->rx_buf = bcm->io_virt;
+
+ return do_transfer_irq(slave);
+}
+
static ssize_t bcm2835_read(struct rtdm_spi_remote_slave *slave,
void *rx, size_t len)
{
@@ -549,6 +567,7 @@ static struct rtdm_spi_master_ops bcm2835_master_ops = {
.mmap_iobufs = bcm2835_mmap_iobufs,
.mmap_release = bcm2835_mmap_release,
.transfer_iobufs = bcm2835_transfer_iobufs,
+ .transfer_iobufs_n = bcm2835_transfer_iobufs_n,
.write = bcm2835_write,
.read = bcm2835_read,
.attach_slave = bcm2835_attach_slave,
diff --git a/kernel/drivers/spi/spi-master.c b/kernel/drivers/spi/spi-master.c
index 12a1ad1f1..39e0738a6 100644
--- a/kernel/drivers/spi/spi-master.c
+++ b/kernel/drivers/spi/spi-master.c
@@ -150,7 +150,7 @@ static int spi_master_ioctl_rt(struct rtdm_fd *fd,
struct rtdm_spi_remote_slave *slave = fd_to_slave(fd);
struct rtdm_spi_master *master = slave->master;
struct rtdm_spi_config config;
- int ret;
+ int ret, len;
switch (request) {
case SPI_RTIOC_SET_CONFIG:
@@
Re: RTnet vnic0 non-rt traffic bug
I have tested the nomac discipline: - on rteth0 ethernet traffic has ethernet type = IPv4 = 0x0800 (tested rtping and rtt-sender <-> rtt-responder) - on vnic0 ethernet traffic has ethernet type 0x9021 (tested using ping and ssh between two rtnet machines) I captured the traffic with wireshark. It is easy to see this behavior by consulting the link from my previous email. On 10/4/19, Jan Kiszka wrote: > On 03.10.19 15:34, Laurentiu-Cristian Duca via Xenomai wrote: >> Hello rtnet dev, >> >>I think I found a bug in RTnet: >> ping and non-rt applications (e.g. dropbear) send non-rt traffic via >> vnic0, >> but the ethernet type is 0x9021 (real-time media access control type): >> xenomai-3.0.9/kernel/drivers/net/stack/rtmac/rtmac_vnic.c:156:res >> = rtmac_add_header(rtdev, ethernet->h_dest, rtskb, >> xenomai-3.0.9/kernel/drivers/net/stack/include/rtmac/rtmac_proto.h:32:#define >> ETH_RTMAC 0x9021 >> xenomai-3.0.9/kernel/drivers/net/stack/include/rtmac/rtmac_proto.h:59: >> (rtdev->hard_header(skb, rtdev, ETH_RTMAC, daddr, >> I have caught the traffic through wireshark which confirmed this info. >> >>I succesfully can ping and ssh between qemu rtnet virtual machines on >> vnic0 >> but I can not ping a non-rtnet machine from a rtnet machine via vnic0 >> and I can not connect using ssh from a non-rtnet machine to a rtnet >> machine. > > This is by design: RTmac implies all participants in the network play > according > to its rule. The vnic is a non-rt tunnel between them, so the remote side > has to > use that protocol as well. > > Jan > >> >>In order to reproduce the bug I have posted a qemu rtnet virtual >> machine and instructions to this link: >> https://github.com/laurentiuduca/rtnet-geek >> >>I mention that rtping works ok. >> >> Kind regards, >> L-C. Duca >> > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux >
RTnet vnic0 non-rt traffic bug
Hello rtnet dev, I think I found a bug in RTnet: ping and non-rt applications (e.g. dropbear) send non-rt traffic via vnic0, but the ethernet type is 0x9021 (real-time media access control type): xenomai-3.0.9/kernel/drivers/net/stack/rtmac/rtmac_vnic.c:156:res = rtmac_add_header(rtdev, ethernet->h_dest, rtskb, xenomai-3.0.9/kernel/drivers/net/stack/include/rtmac/rtmac_proto.h:32:#define ETH_RTMAC 0x9021 xenomai-3.0.9/kernel/drivers/net/stack/include/rtmac/rtmac_proto.h:59: (rtdev->hard_header(skb, rtdev, ETH_RTMAC, daddr, I have caught the traffic through wireshark which confirmed this info. I succesfully can ping and ssh between qemu rtnet virtual machines on vnic0 but I can not ping a non-rtnet machine from a rtnet machine via vnic0 and I can not connect using ssh from a non-rtnet machine to a rtnet machine. In order to reproduce the bug I have posted a qemu rtnet virtual machine and instructions to this link: https://github.com/laurentiuduca/rtnet-geek I mention that rtping works ok. Kind regards, L-C. Duca
RTNet beaglebone-black drivers
Dear all, I posted to github a version of RTNet beaglebone-black drivers ported to xenomai linux 4.14 as long as an x86_64 RTNet enabled qemu virtual machine: https://github.com/laurentiuduca/rtnet-geek Kind regards, L-C. Duca
Re: i-pipe tracer - how to view traced data
ndle_syscall+0x5a)
: + func 0 0.553 handle_head_syscall+0x0
(ipipe_fastcall_hook+0x14)
: + func 0 0.258 CoBaLt_trace+0x0
(handle_head_syscall+0x100)
< + freeze 0x000f 0 0.404 CoBaLt_trace+0xdd (<>)
|+ begin 0x8000 0 1.275 do_syscall_64+0x57 (<>)
|+ func 1 0.377 do_syscall_64+0x0
(entry_SYSCALL_64_after_hwframe+0x42)
|+ end 0x8000 2 0.162 do_syscall_64+0x14f (<>)
+ func 2 0.158 ipipe_handle_syscall+0x0
(do_syscall_64+0x37)
+ func 2 0.151 ipipe_fastcall_hook+0x0
(ipipe_handle_syscall+0x5a)
+ func 2 0.240 handle_head_syscall+0x0
(ipipe_fastcall_hook+0x14)
+ func 2 0.156 CoBaLt_sendmsg+0x0
(handle_head_syscall+0x100)
|+ begin 0x8001 2 0.162 CoBaLt_sendmsg+0x9b (<>)
|+ end 0x8001 3 0.293 CoBaLt_sendmsg+0xb5 (<>)
+ func 3 0.000 rtdm_fd_sendmsg+0x0
(CoBaLt_sendmsg+0x7c)
On 8/28/19, Jan Kiszka wrote:
> On 28.08.19 10:11, Laurentiu-Cristian Duca via Xenomai wrote:
>> Hello there,
>>
>>I want to use ipipe tracer for tracing RTNet drivers.
>>In the tutorial
>> https://gitlab.denx.de/Xenomai/xenomai/wikis/Using_The_I_Pipe_Tracer
>> it does not specify which file to "cat" in order to view the function
>> traces
>> so if anybody used it please provide this info.
>>How to view the traced data?
>>
>
> cat .../frozen or .../max
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
-- next part --
Here is a test of rtt-responder on qemu.
I use the ipipe-trace api to freeze trancing from C code.
I see that rtdm_fd_recvmsg and rtdm_fd_sendmsg are called
(and I wanted to see that).
I have some questions (I have some ideas but just want to be sure).
Please answer to those that have relevance.
1. On Hard IRQs column, I see only ':' and space; what do they mean?
What does mean Hard IRQs ('|': locked) ?
2. On Xenomai column I see only '|' and space; what do they mean?
3. What does the following column mean:
Linux ('*': domain stalled, '+': current, '#': current+stalled)
4. Type 'func' I think it means a function is called; correct?
What do 'begin' and 'end' mean on the Type column? Are they important?
5. NMI noise 'N' ?
I-pipe frozen back-tracing service on 4.14.71/ipipe release #2112
CPU: 0, Freeze: 1176197529135 cycles, Trace Points: 100 (+10)
Calibrated minimum trace-point overhead: 0.074 us
+- Hard IRQs ('|': locked)
|+-- Xenomai
||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
||| +-- Delay flag ('+': > 1 us, '!': > 10 us)
||| |+- NMI noise ('N')
||| ||
TypeUser Val. TimeDelay Function (Parent)
:|# func -27 0.574 xnsynch_wakeup_one_sleeper+0x0
(rtdm_sem_up+0xed)
:|# func -26 0.406 xnthread_resume+0x0
(xnsynch_wakeup_one_sleeper+0x14a)
:|# [ 121] rtt-res 81 -26 0.184 xnthread_resume+0x113 (<>)
:|# func -26 0.149 xnsched_rt_enqueue+0x0
(xnthread_resume+0x14f)
:|# func -26 0.335 xnsched_addq_tail+0x0
(xnthread_resume+0x14f)
:|# func -25 0.185 ___xnsched_run+0x0 (rtdm_sem_up+0x18d)
:|# func -25 0.202 ___xnsched_run.part.63+0x0
(rtdm_sem_up+0x18d)
:|# [ 100] rtnet-s 98 -25 0.165 ___xnsched_run.part.63+0x102
(<>)
:|# func -25 0.207 xnsched_pick_next+0x0
(___xnsched_run.part.63+0x137)
:|# func -25 0.160 xnsched_rt_requeue+0x0
(xnsched_pick_next+0x56)
:|# func -24 0.193 xnsched_addq+0x0
(xnsched_pick_next+0x56)
:|# func -24 0.165 xnsched_rt_pick+0x0
(xnsched_pick_next+0x8b)
:|# func -24 0.200 del_q+0x0 (xnsched_rt_pick+0x5a)
:|# func -24 0.198 xnlock_dbg_release+0x0
(rtdm_sem_up+0x1b2)
:|# func -24 0.156 __ipipe_restore_head+0x0
(rtdm_sem_up+0x14c)
:|+ end 0x8000 -23 0.142 __ipipe_restore_head+0x4d (<>)
:|+ begin 0x8000 -23 0.193 rt_udp_rcv+0xe4 [rtudp] (<>)
:|# func -23 0.156 xnsched_lock+0x0 (rt_udp_rcv+0x11c
[rtudp])
:|# func -23 0.185 xnsched_unlock+0x0 (rt_udp_rcv+0x136
[rtudp])
:|# func -23 0.156 __ipipe_restore_head+0x0
(rt_udp_rcv+0x15a [rtudp])
:|+ end 0x8000 -23 0.209 __ip
i-pipe tracer - how to view traced data
Hello there, I want to use ipipe tracer for tracing RTNet drivers. In the tutorial https://gitlab.denx.de/Xenomai/xenomai/wikis/Using_The_I_Pipe_Tracer it does not specify which file to "cat" in order to view the function traces so if anybody used it please provide this info. How to view the traced data? Thank you and kind regards, L-C.
Re: RTNet - vnic0 question
Success I had to run on target xeno-config and paste the output to my makefile, because I was doing cross-compile for bbb on a x86_64 host. So, the tests are: frag-ip between bbb and qemu-x86-64-rt_8139too which use alchemy: success rtt-sender/rtt-responder which use posix skin: success. However the ping fails even if vnic0 is fully configured just as rteth0 for which rtping succeds. Thank you all On 8/22/19, Jan Kiszka wrote: > On 22.08.19 16:27, Laurentiu-Cristian Duca via Xenomai wrote: >> Hi, >> >> I have used rtifconfig, rtroute and rtping and I mentioned that worked, >> I have written that rtt-sender and rtt-responder which use posix skin >> worked only on vnic0 and not on rteth0. >> >> I have ported frag-ip.c (from rtnet 0.9.13 to xenomai 3) >> which uses alchemy instead of posix and it works on rteth0 link >> between two qemu-x86_64-rt_8139too virtual machines, >> but do not work on bbb (I think the drivers I use have problems on bbb). > > I still suspect your ported rtt-sender/responder have some binding issue to > > RTnet so that UDP sockets fall back to plan Linux. You can check that by > running > "netstat -lun" while the two are active. If someone listens on a suspicious > > port, you have the prove. > > Looking at your makefile... > >> >> Thx >> >> On 8/22/19, Per Oberg wrote: >>> >>> >>> - Den 22 aug 2019, på kl 13:21, xenomai xenomai@xenomai.org skrev: >>> >>>> Hi, >>> >>>> I have made a test between two qemu-x86_64-rt_8139too with different >>>> mac and IP addresses, >>>> one is master one is slave. In each of them I do: >>>> /usr/xenomai/sbin/rtnet start >>>> Then the applications rtt-sender and rtt-responder (taken from rtnet >>>> 0.9.13 release) work, >>>> but if I turn off vnic0, then rtt-sender reports error: "sendto >>>> failed: Network is unreachable", >>>> even if rteth0 is up and fully configured. >>>> Do you have any simple apps that work on rtnet? >>> >>> You have : >>> rtping >>> rtifconfig >>> rtroute >>> >>> Perhaps these can be of assistance? >>> >>>> Thank you, >>>> Kind regards >>> >>>> On 8/22/19, Laurentiu-Cristian Duca wrote: >>>>> The rt drivers for bbb are taken from: >>>>> https://github.com/G-Ray/xenomai-boneblack-rtnet-drivers >>>>> and I am not 100% sure that they are working correctly. >>> >>>>> On 8/22/19, Laurentiu-Cristian Duca wrote: >>>>>> Hello Jan and friends >>> >>>>>> Thank you for your fast answer. Please find below the details. >>> >>>>>> On 8/21/19, Jan Kiszka wrote: >>>>>>> On 21.08.19 16:20, Laurentiu-Cristian Duca via Xenomai wrote: >>>>>>>> Hello rtnet community, >>> >>>>>>>> I successfully tested the examples rtt-sender and rtt-responder >>>>>>>> within a rtnet made from one beaglebone black and one >>>>>>>> qemu-x86_64-8139too, >>>>>>>> with tdma and also with nomac. >>> >>>>>>> Are we talking about some legacy Xenomai or even RTnet version? Or >>>>>>> where >>>>>>> did >>>>>>> you >>>>>>> get the examples from? They are not part of RTnet in Xenomai 3. >>> >>>>>> I got the examples from rtnet-0.9.13. I know they are quite old, but >>>>>> I needed a start point. >>>>>> Are these obsolete? Do you have any examples for Xenomai 3? >>>>>> rtnet-0.9.13/examples/xenomai/posix/rtt-sender.c >>>>>> rtnet-0.9.13/examples/xenomai/posix/rtt-responder.c >>> >>> >>>>>>>> I have noted that the presence of vnic0 as an up and fully >>>>>>>> configured interface is mandatory, >>>>>>>> even if rteth0 is up and fully configured. >>>>>>>> Otherwise the rtt-sender announces "sendto failed: Network is >>>>>>>> unreachable". >>>>>>>> Could anybody tell me why is this happening? >>> >>>>>>>> I have also noted that if I disable vnic0 (ifconfig vnic0 down), >>>>>>>> rtping works if rteth0 is up and fully configured. >>>>>>>> Why does not work rtt-sender in this case? >>>>>>
Re: RTNet - vnic0 question
Hi, I have used rtifconfig, rtroute and rtping and I mentioned that worked, I have written that rtt-sender and rtt-responder which use posix skin worked only on vnic0 and not on rteth0. I have ported frag-ip.c (from rtnet 0.9.13 to xenomai 3) which uses alchemy instead of posix and it works on rteth0 link between two qemu-x86_64-rt_8139too virtual machines, but do not work on bbb (I think the drivers I use have problems on bbb). Thx On 8/22/19, Per Oberg wrote: > > > - Den 22 aug 2019, på kl 13:21, xenomai xenomai@xenomai.org skrev: > >> Hi, > >> I have made a test between two qemu-x86_64-rt_8139too with different >> mac and IP addresses, >> one is master one is slave. In each of them I do: >> /usr/xenomai/sbin/rtnet start >> Then the applications rtt-sender and rtt-responder (taken from rtnet >> 0.9.13 release) work, >> but if I turn off vnic0, then rtt-sender reports error: "sendto >> failed: Network is unreachable", >> even if rteth0 is up and fully configured. >> Do you have any simple apps that work on rtnet? > > You have : > rtping > rtifconfig > rtroute > > Perhaps these can be of assistance? > >> Thank you, >> Kind regards > >> On 8/22/19, Laurentiu-Cristian Duca wrote: >> > The rt drivers for bbb are taken from: >> > https://github.com/G-Ray/xenomai-boneblack-rtnet-drivers >> > and I am not 100% sure that they are working correctly. > >> > On 8/22/19, Laurentiu-Cristian Duca wrote: >> >> Hello Jan and friends > >> >> Thank you for your fast answer. Please find below the details. > >> >> On 8/21/19, Jan Kiszka wrote: >> >>> On 21.08.19 16:20, Laurentiu-Cristian Duca via Xenomai wrote: >> >>>> Hello rtnet community, > >> >>>> I successfully tested the examples rtt-sender and rtt-responder >> >>>> within a rtnet made from one beaglebone black and one >> >>>> qemu-x86_64-8139too, >> >>>> with tdma and also with nomac. > >> >>> Are we talking about some legacy Xenomai or even RTnet version? Or >> >>> where >> >>> did >> >>> you >> >>> get the examples from? They are not part of RTnet in Xenomai 3. > >> >> I got the examples from rtnet-0.9.13. I know they are quite old, but >> >> I needed a start point. >> >> Are these obsolete? Do you have any examples for Xenomai 3? >> >> rtnet-0.9.13/examples/xenomai/posix/rtt-sender.c >> >> rtnet-0.9.13/examples/xenomai/posix/rtt-responder.c > > >> >>>> I have noted that the presence of vnic0 as an up and fully >> >>>> configured interface is mandatory, >> >>>> even if rteth0 is up and fully configured. >> >>>> Otherwise the rtt-sender announces "sendto failed: Network is >> >>>> unreachable". >> >>>> Could anybody tell me why is this happening? > >> >>>> I have also noted that if I disable vnic0 (ifconfig vnic0 down), >> >>>> rtping works if rteth0 is up and fully configured. >> >>>> Why does not work rtt-sender in this case? >> >>>> Could it be a problem with rtnet drivers? > >> >>> I bet your examples are falling back to normal network here, and that >> >>> is >> >>> provided between your test nodes via the vnics. This leads to my >> >>> first >> >>> question: >> >>> Where did you pick the examples up, how did you build them etc.? >> >>> Also, >> >>> did >> >>> you >> >>> make sure that rtudp was loaded? > >> >> I am 100% sure that rtudp was loaded. The modules were loaded by a >> >> script: >> >> modprobe rt_smsc && modprobe rt_davinci_mdio && modprobe rt_ticpsw >> >> modprobe rtipv4 && modprobe rtpacket && modprobe rtudp >> >> modprobe rtmac >> >> modprobe nomac >> >> #modprobe tdma > >> >> I used robertcnelson Xenomai 3.0.9 patch for beaglebone black linux >> >> 4.14.108. It's on github. >> >> I have also copied the rtnet header files to xenomai-userspace >> >> include. The files compile without warnings. >> >> The makefile is: >> >> # Tested with linaro toolchain >> >> (gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf) >> >> CC = arm-linux-gnueabihf-gcc >> >> XENO_INSTALL = >> >> /home/laur/lucru/rasp
Re: RTNet - vnic0 question
Hi, I have made a test between two qemu-x86_64-rt_8139too with different mac and IP addresses, one is master one is slave. In each of them I do: /usr/xenomai/sbin/rtnet start Then the applications rtt-sender and rtt-responder (taken from rtnet 0.9.13 release) work, but if I turn off vnic0, then rtt-sender reports error: "sendto failed: Network is unreachable", even if rteth0 is up and fully configured. Do you have any simple apps that work on rtnet? Thank you, Kind regards On 8/22/19, Laurentiu-Cristian Duca wrote: > The rt drivers for bbb are taken from: > https://github.com/G-Ray/xenomai-boneblack-rtnet-drivers > and I am not 100% sure that they are working correctly. > > On 8/22/19, Laurentiu-Cristian Duca wrote: >> Hello Jan and friends >> >> Thank you for your fast answer. Please find below the details. >> >> On 8/21/19, Jan Kiszka wrote: >>> On 21.08.19 16:20, Laurentiu-Cristian Duca via Xenomai wrote: >>>> Hello rtnet community, >>>> >>>>I successfully tested the examples rtt-sender and rtt-responder >>>> within a rtnet made from one beaglebone black and one >>>> qemu-x86_64-8139too, >>>> with tdma and also with nomac. >>> >>> Are we talking about some legacy Xenomai or even RTnet version? Or where >>> did >>> you >>> get the examples from? They are not part of RTnet in Xenomai 3. >>> >> I got the examples from rtnet-0.9.13. I know they are quite old, but >> I needed a start point. >> Are these obsolete? Do you have any examples for Xenomai 3? >> rtnet-0.9.13/examples/xenomai/posix/rtt-sender.c >> rtnet-0.9.13/examples/xenomai/posix/rtt-responder.c >> >>>> >>>>I have noted that the presence of vnic0 as an up and fully >>>> configured interface is mandatory, >>>> even if rteth0 is up and fully configured. >>>> Otherwise the rtt-sender announces "sendto failed: Network is >>>> unreachable". >>>> Could anybody tell me why is this happening? >>>> >>>>I have also noted that if I disable vnic0 (ifconfig vnic0 down), >>>> rtping works if rteth0 is up and fully configured. >>>> Why does not work rtt-sender in this case? >>>> Could it be a problem with rtnet drivers? >>> >>> I bet your examples are falling back to normal network here, and that is >>> provided between your test nodes via the vnics. This leads to my first >>> question: >>> Where did you pick the examples up, how did you build them etc.? Also, >>> did >>> you >>> make sure that rtudp was loaded? >> >>I am 100% sure that rtudp was loaded. The modules were loaded by a >> script: >> modprobe rt_smsc && modprobe rt_davinci_mdio && modprobe rt_ticpsw >> modprobe rtipv4 && modprobe rtpacket && modprobe rtudp >> modprobe rtmac >> modprobe nomac >> #modprobe tdma >> >> I used robertcnelson Xenomai 3.0.9 patch for beaglebone black linux >> 4.14.108. It's on github. >> I have also copied the rtnet header files to xenomai-userspace >> include. The files compile without warnings. >> The makefile is: >> # Tested with linaro toolchain >> (gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf) >> CC = arm-linux-gnueabihf-gcc >> XENO_INSTALL = >> /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace >> RTNET_INSTALL = >> /home/laur/lucru/raspberry-pi/robertcnelson/rtnet-hiddeate2m >> >> #XENO_CONFIG := >> /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace/usr/xenomai/bin/xeno-config >> #/usr/xenomai/bin/xeno-config >> #CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags) >> #LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags) >> >> LIBCFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt >> LIBCFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include >> >> CFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt >> CFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include/alchemy >> -I$(XENO_INSTALL)/usr/xenomai/include >> CFLAGS += -march=armv7-a -mfpu=vfpv4 -D_GNU_SOURCE -D_REENTRANT >> -D__COBALT__ -D__COBALT_WRAP_ >> CFLAGS += -I$(RTNET_INSTALL)/stack/include >> >> LFLAGS = -lalchemy -lcopperplate >> $(XENO_INSTALL)/usr/xenomai/lib/xenomai/bootstrap.o >> LFLAGS += -Wl,--wrap=main -Wl,--wrap=malloc -Wl,--wrap=free >> #-Wl,--dynamic-list=$(XENO_INSTALL)/usr/xenomai/lib/dynlist.ld >> LFLAGS += -L$(XENO_INSTALL)/usr/xenomai/lib -lcobalt -lpthread -lrt >> LFLAGS += -march=armv7-a -mfpu=vfpv4 -Llib >> >> all: rtt-sender rtt-responder >> rtt-sender: rtt-sender.o >> $(CC) -o rtt-sender rtt-sender.o $(LFLAGS) >> rtt-sender.o: rtt-sender.c >> $(CC) -c -o rtt-sender.o rtt-sender.c $(CFLAGS) $(LIBCFLAGS) >> (same for rtt-responder) >> >> >> Kind regards, >> L-C. >> >
Re: RTNet - vnic0 question
The rt drivers for bbb are taken from: https://github.com/G-Ray/xenomai-boneblack-rtnet-drivers and I am not 100% sure that they are working correctly. On 8/22/19, Laurentiu-Cristian Duca wrote: > Hello Jan and friends > > Thank you for your fast answer. Please find below the details. > > On 8/21/19, Jan Kiszka wrote: >> On 21.08.19 16:20, Laurentiu-Cristian Duca via Xenomai wrote: >>> Hello rtnet community, >>> >>>I successfully tested the examples rtt-sender and rtt-responder >>> within a rtnet made from one beaglebone black and one >>> qemu-x86_64-8139too, >>> with tdma and also with nomac. >> >> Are we talking about some legacy Xenomai or even RTnet version? Or where >> did >> you >> get the examples from? They are not part of RTnet in Xenomai 3. >> > I got the examples from rtnet-0.9.13. I know they are quite old, but > I needed a start point. > Are these obsolete? Do you have any examples for Xenomai 3? > rtnet-0.9.13/examples/xenomai/posix/rtt-sender.c > rtnet-0.9.13/examples/xenomai/posix/rtt-responder.c > >>> >>>I have noted that the presence of vnic0 as an up and fully >>> configured interface is mandatory, >>> even if rteth0 is up and fully configured. >>> Otherwise the rtt-sender announces "sendto failed: Network is >>> unreachable". >>> Could anybody tell me why is this happening? >>> >>>I have also noted that if I disable vnic0 (ifconfig vnic0 down), >>> rtping works if rteth0 is up and fully configured. >>> Why does not work rtt-sender in this case? >>> Could it be a problem with rtnet drivers? >> >> I bet your examples are falling back to normal network here, and that is >> provided between your test nodes via the vnics. This leads to my first >> question: >> Where did you pick the examples up, how did you build them etc.? Also, >> did >> you >> make sure that rtudp was loaded? > >I am 100% sure that rtudp was loaded. The modules were loaded by a > script: > modprobe rt_smsc && modprobe rt_davinci_mdio && modprobe rt_ticpsw > modprobe rtipv4 && modprobe rtpacket && modprobe rtudp > modprobe rtmac > modprobe nomac > #modprobe tdma > > I used robertcnelson Xenomai 3.0.9 patch for beaglebone black linux > 4.14.108. It's on github. > I have also copied the rtnet header files to xenomai-userspace > include. The files compile without warnings. > The makefile is: > # Tested with linaro toolchain > (gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf) > CC = arm-linux-gnueabihf-gcc > XENO_INSTALL = > /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace > RTNET_INSTALL = > /home/laur/lucru/raspberry-pi/robertcnelson/rtnet-hiddeate2m > > #XENO_CONFIG := > /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace/usr/xenomai/bin/xeno-config > #/usr/xenomai/bin/xeno-config > #CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags) > #LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags) > > LIBCFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt > LIBCFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include > > CFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt > CFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include/alchemy > -I$(XENO_INSTALL)/usr/xenomai/include > CFLAGS += -march=armv7-a -mfpu=vfpv4 -D_GNU_SOURCE -D_REENTRANT > -D__COBALT__ -D__COBALT_WRAP_ > CFLAGS += -I$(RTNET_INSTALL)/stack/include > > LFLAGS = -lalchemy -lcopperplate > $(XENO_INSTALL)/usr/xenomai/lib/xenomai/bootstrap.o > LFLAGS += -Wl,--wrap=main -Wl,--wrap=malloc -Wl,--wrap=free > #-Wl,--dynamic-list=$(XENO_INSTALL)/usr/xenomai/lib/dynlist.ld > LFLAGS += -L$(XENO_INSTALL)/usr/xenomai/lib -lcobalt -lpthread -lrt > LFLAGS += -march=armv7-a -mfpu=vfpv4 -Llib > > all: rtt-sender rtt-responder > rtt-sender: rtt-sender.o > $(CC) -o rtt-sender rtt-sender.o $(LFLAGS) > rtt-sender.o: rtt-sender.c > $(CC) -c -o rtt-sender.o rtt-sender.c $(CFLAGS) $(LIBCFLAGS) > (same for rtt-responder) > > > Kind regards, > L-C. >
Re: RTNet - vnic0 question
Hello Jan and friends Thank you for your fast answer. Please find below the details. On 8/21/19, Jan Kiszka wrote: > On 21.08.19 16:20, Laurentiu-Cristian Duca via Xenomai wrote: >> Hello rtnet community, >> >>I successfully tested the examples rtt-sender and rtt-responder >> within a rtnet made from one beaglebone black and one >> qemu-x86_64-8139too, >> with tdma and also with nomac. > > Are we talking about some legacy Xenomai or even RTnet version? Or where did > you > get the examples from? They are not part of RTnet in Xenomai 3. > I got the examples from rtnet-0.9.13. I know they are quite old, but I needed a start point. Are these obsolete? Do you have any examples for Xenomai 3? rtnet-0.9.13/examples/xenomai/posix/rtt-sender.c rtnet-0.9.13/examples/xenomai/posix/rtt-responder.c >> >>I have noted that the presence of vnic0 as an up and fully >> configured interface is mandatory, >> even if rteth0 is up and fully configured. >> Otherwise the rtt-sender announces "sendto failed: Network is >> unreachable". >> Could anybody tell me why is this happening? >> >>I have also noted that if I disable vnic0 (ifconfig vnic0 down), >> rtping works if rteth0 is up and fully configured. >> Why does not work rtt-sender in this case? >> Could it be a problem with rtnet drivers? > > I bet your examples are falling back to normal network here, and that is > provided between your test nodes via the vnics. This leads to my first > question: > Where did you pick the examples up, how did you build them etc.? Also, did > you > make sure that rtudp was loaded? I am 100% sure that rtudp was loaded. The modules were loaded by a script: modprobe rt_smsc && modprobe rt_davinci_mdio && modprobe rt_ticpsw modprobe rtipv4 && modprobe rtpacket && modprobe rtudp modprobe rtmac modprobe nomac #modprobe tdma I used robertcnelson Xenomai 3.0.9 patch for beaglebone black linux 4.14.108. It's on github. I have also copied the rtnet header files to xenomai-userspace include. The files compile without warnings. The makefile is: # Tested with linaro toolchain (gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf) CC = arm-linux-gnueabihf-gcc XENO_INSTALL = /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace RTNET_INSTALL = /home/laur/lucru/raspberry-pi/robertcnelson/rtnet-hiddeate2m #XENO_CONFIG := /home/laur/lucru/raspberry-pi/robertcnelson/ti-linux-kernel-dev/ignore/xenomai-userspace/usr/xenomai/bin/xeno-config #/usr/xenomai/bin/xeno-config #CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags) #LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags) LIBCFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt LIBCFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include CFLAGS = -Wall -I$(XENO_INSTALL)/usr/xenomai/include/cobalt CFLAGS += -I$(XENO_INSTALL)/usr/xenomai/include/alchemy -I$(XENO_INSTALL)/usr/xenomai/include CFLAGS += -march=armv7-a -mfpu=vfpv4 -D_GNU_SOURCE -D_REENTRANT -D__COBALT__ -D__COBALT_WRAP_ CFLAGS += -I$(RTNET_INSTALL)/stack/include LFLAGS = -lalchemy -lcopperplate $(XENO_INSTALL)/usr/xenomai/lib/xenomai/bootstrap.o LFLAGS += -Wl,--wrap=main -Wl,--wrap=malloc -Wl,--wrap=free #-Wl,--dynamic-list=$(XENO_INSTALL)/usr/xenomai/lib/dynlist.ld LFLAGS += -L$(XENO_INSTALL)/usr/xenomai/lib -lcobalt -lpthread -lrt LFLAGS += -march=armv7-a -mfpu=vfpv4 -Llib all: rtt-sender rtt-responder rtt-sender: rtt-sender.o $(CC) -o rtt-sender rtt-sender.o $(LFLAGS) rtt-sender.o: rtt-sender.c $(CC) -c -o rtt-sender.o rtt-sender.c $(CFLAGS) $(LIBCFLAGS) (same for rtt-responder) Kind regards, L-C.
RTNet - vnic0 question
Hello rtnet community, I successfully tested the examples rtt-sender and rtt-responder within a rtnet made from one beaglebone black and one qemu-x86_64-8139too, with tdma and also with nomac. I have noted that the presence of vnic0 as an up and fully configured interface is mandatory, even if rteth0 is up and fully configured. Otherwise the rtt-sender announces "sendto failed: Network is unreachable". Could anybody tell me why is this happening? I have also noted that if I disable vnic0 (ifconfig vnic0 down), rtping works if rteth0 is up and fully configured. Why does not work rtt-sender in this case? Could it be a problem with rtnet drivers? Thank you and best regards, L-C. Duca
Fwd: Xenomai - RTNet - patch error
-- Forwarded message --
From: Laurentiu-Cristian Duca
Date: Wed, 14 Aug 2019 20:46:19 +0300
Subject: Re: Xenomai - RTNet - patch error
To: Quirin Gylstorff
Hello Quirin,
Thank you for this quick answer.
On 8/14/19, Quirin Gylstorff wrote:
> Hi Laurentiu,
>
>> Hello xenomai community,
>>
>>I am an open source enthusiast interested in Xenomai and RTNet.
>> I have the RTNet modules successfully installed on BeagleBone black
>> and now I want to install RTNet on qemu-system-x86_64
>> in order to do more tests with bbb and x86_64.
>>
> We are also interested using the beagle bone black as the target device
> for xenomai. Do you want to supply us the patches for it?
Here are some hints, I just wanted to have something that works:
- tested on 4.14.108 robertcnelson kernel sources,
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-xenomai-4.14.y
- https://github.com/G-Ray/xenomai-boneblack-rtnet-drivers
those drivers were adapted after Hidde (see RTNet mailing list on
sourceforge and search for beaglebone), written and tested on linux
4.1
quick and dirty fixes in order to run on 4.14.108 (success with
rtping, more tests will follow)
- rt_ticpsw must be inserted after rt_smsc and rt_davinci_mdio and
before rtnet start
- drivers/xenomai/net/drivers/ticpsw/cpsw.c
if (of_property_read_u32(node, "rx_descs", )) {
dev_err(>dev, "Missing rx_descs property in the DT;
default to 64\n");
prop = 64;
//return -EINVAL;
}
- rt_davinci_mdio.c, davinci_mdio_probe()
...
/* scan and dump the bus */
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
phy = mdiobus_get_phy(data->bus, addr);
if (phy) {
dev_info(dev, "phy[%d]: device %s, driver %s\n",
phy->mdio.addr, phydev_name(phy),
phy->drv ? phy->drv->name : "unknown");
}
}
return 0;
}
- in kernel
drivers/net/phy/phy_device.c
int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface)
{
//struct module *ndev_owner = dev->dev.parent->driver->owner;
// comment all lines that use ndev_owner
>
>
>>I have tried to compile the project
>> https://github.com/jan-kiszka/xenomai-images
>> with the command
>> kas-docker --isar build kas.yml:board-qemu-amd64.yml
>
>
> The github repository from Jan is outdated an no longer
> maintained/updated. Use https://gitlab.denx.de/Xenomai/xenomai-images
> instead.
>
> How did you get to the github repository?
I found it on google.
>
>> and it returns the below copied error. > Do you have any ideas how to get
>> over it? Maybe to transform it into
> an warning,
>> or by automatically/manually answer to patch anyway.
>>
>> ERROR: xenomai--next-r0 do_patch: patching failed
>> ERROR: xenomai--next-r0 do_patch: Function failed: do_patch
>> ERROR: Logfile of failure stored in:
>> /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch.123
>> ERROR: Task (/repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch)
>> failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 46 tasks of which 45 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>/repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch
>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>> code.
>>
>> $ cat
>> build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch
>> DEBUG: Executing python function do_patch
>> DEBUG: Fetcher accessed the network with the command git -c
>> core.fsyncobjectfiles=0 ls-remote
>> https://gitlab.denx.de/Xenomai/xenomai.git
>> DEBUG: Running export PSEUDO_DISABLED=1; export
>> GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export
>> PATH="/work/isar/bitbake/bin:/work/isar/scripts:/usr/sbin:/usr/bin:/sbin:/bin";
>> export HOME="/tmp/tmp89g2x4r8"; git -c core.fsyncobjectfiles=0
>> ls-remotehttps://gitlab.denx.de/Xenomai/xenomai.git
>> NOTE: patch --no-backup-if-mismatch -p 1 --directory
>> /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/git
>> --input
>> /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/0001-debian-Add-config-folder-to-xenomai-kernel-source.patch
>> patching file debian/rules
>>
>> Reversed (or previously applied) patch detected! Assume -R? [n]
>> Apply anyway? [n]
>> Skipping patch.
>> 1 out of 1 hunk ignored -- saving rejects to file debian/rules.rej
>> ERROR: patching failed
>> DEBUG: Python function do_patch finished
>> ERROR: Function failed: do_patch
>>
> ISAR tries to apply the patch on the current HEAD of next, but the patch
> is already submitted patch and therefore git fails to apply the patch.
>
>>
>> Thank you and kind regards,
>> L-C. Duca
>
>
> Can we clarify for you that
> https://gitlab.denx.de/Xenomai/xenomai-images is the correct image. Like
> linking it to Xenomai Main page or mention it the in the README?
>
> Kind regards,
> Quirin
>
Kind regads,
Re: Xenomai - RTNet - patch error
I have fixed it quick and dirty: remove the patch file from package/xenomai/ On 8/14/19, Laurentiu-Cristian Duca wrote: > Hello xenomai community, > > I am an open source enthusiast interested in Xenomai and RTNet. > I have the RTNet modules successfully installed on BeagleBone black > and now I want to install RTNet on qemu-system-x86_64 > in order to do more tests with bbb and x86_64. > > I have tried to compile the project > https://github.com/jan-kiszka/xenomai-images > with the command > kas-docker --isar build kas.yml:board-qemu-amd64.yml > and it returns the below copied error. > Do you have any ideas how to get over it? Maybe to transform it into an > warning, > or by automatically/manually answer to patch anyway. > > ERROR: xenomai--next-r0 do_patch: patching failed > ERROR: xenomai--next-r0 do_patch: Function failed: do_patch > ERROR: Logfile of failure stored in: > /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch.123 > ERROR: Task (/repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch) > failed with exit code '1' > NOTE: Tasks Summary: Attempted 46 tasks of which 45 didn't need to be > rerun and 1 failed. > > Summary: 1 task failed: > /repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > $ cat > build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch > DEBUG: Executing python function do_patch > DEBUG: Fetcher accessed the network with the command git -c > core.fsyncobjectfiles=0 ls-remote > https://gitlab.denx.de/Xenomai/xenomai.git > DEBUG: Running export PSEUDO_DISABLED=1; export > GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export > PATH="/work/isar/bitbake/bin:/work/isar/scripts:/usr/sbin:/usr/bin:/sbin:/bin"; > export HOME="/tmp/tmp89g2x4r8"; git -c core.fsyncobjectfiles=0 > ls-remote https://gitlab.denx.de/Xenomai/xenomai.git > NOTE: patch --no-backup-if-mismatch -p 1 --directory > /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/git > --input > /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/0001-debian-Add-config-folder-to-xenomai-kernel-source.patch > patching file debian/rules > > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file debian/rules.rej > ERROR: patching failed > DEBUG: Python function do_patch finished > ERROR: Function failed: do_patch > > > Thank you and kind regards, > L-C. Duca >
Xenomai - RTNet - patch error
Hello xenomai community, I am an open source enthusiast interested in Xenomai and RTNet. I have the RTNet modules successfully installed on BeagleBone black and now I want to install RTNet on qemu-system-x86_64 in order to do more tests with bbb and x86_64. I have tried to compile the project https://github.com/jan-kiszka/xenomai-images with the command kas-docker --isar build kas.yml:board-qemu-amd64.yml and it returns the below copied error. Do you have any ideas how to get over it? Maybe to transform it into an warning, or by automatically/manually answer to patch anyway. ERROR: xenomai--next-r0 do_patch: patching failed ERROR: xenomai--next-r0 do_patch: Function failed: do_patch ERROR: Logfile of failure stored in: /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch.123 ERROR: Task (/repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 46 tasks of which 45 didn't need to be rerun and 1 failed. Summary: 1 task failed: /repo/recipes-xenomai/xenomai/xenomai_next.bb:do_patch Summary: There were 2 ERROR messages shown, returning a non-zero exit code. $ cat build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/temp/log.do_patch DEBUG: Executing python function do_patch DEBUG: Fetcher accessed the network with the command git -c core.fsyncobjectfiles=0 ls-remote https://gitlab.denx.de/Xenomai/xenomai.git DEBUG: Running export PSEUDO_DISABLED=1; export GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export PATH="/work/isar/bitbake/bin:/work/isar/scripts:/usr/sbin:/usr/bin:/sbin:/bin"; export HOME="/tmp/tmp89g2x4r8"; git -c core.fsyncobjectfiles=0 ls-remote https://gitlab.denx.de/Xenomai/xenomai.git NOTE: patch --no-backup-if-mismatch -p 1 --directory /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/git --input /work/build/tmp/work/xenomai-demo-amd64/xenomai--next-r0/0001-debian-Add-config-folder-to-xenomai-kernel-source.patch patching file debian/rules Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file debian/rules.rej ERROR: patching failed DEBUG: Python function do_patch finished ERROR: Function failed: do_patch Thank you and kind regards, L-C. Duca
