date:20200424

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

2020-04-24 Thread Greg Gallagher via Xenomai

On Fri, Apr 24, 2020 at 3:14 PM Jan Kiszka  wrote:
>
> On 24.04.20 20:28, Greg Gallagher wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 2:06 PM Greg Gallagher  > > wrote:
> >
> > Sure no problem
> >
> > On Fri, Apr 24, 2020 at 2:00 PM Jan Kiszka  > > wrote:
> >
> > On 22.04.20 06:34, xenomai--- via Xenomai wrote:
> >  > Download URL:
> > 
> > https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-5.patch
> >  >
> >  > Repository: https://git.xenomai.org/ipipe-arm64
> >  > Release tag: ipipe-core-4.19.115-arm64-5
> >  >
> >
> > I think we have a build regression here:
> >
> > https://travis-ci.com/github/xenomai-ci/xenomai/jobs/323104732
> >
> > Could your have a look, Greg?
> >
> >
> > I must have missed a commit, I’ll have it fixed up tonight. If I delete
> > the tag and regenerate the patch can it stay at 05 or do I need to bump
> > to 06?
>
> Don't do history rewriting on releases. I did quite a few bad releases
> as well already. Just roll out a better one. ;)
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

Should all be fixed, apologizes to anyone that was using that patch.

Thanks

Greg

[I-PIPE] ipipe-core-4.19.115-arm64-6 released

2020-04-24 Thread xenomai--- via Xenomai

Download URL: 
https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-6.patch

Repository: https://git.xenomai.org/ipipe-arm64
Release tag: ipipe-core-4.19.115-arm64-6

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

2020-04-24 Thread Jan Kiszka via Xenomai

On 24.04.20 20:28, Greg Gallagher wrote:

On Fri, Apr 24, 2020 at 2:06 PM Greg Gallagher > wrote:

Sure no problem

On Fri, Apr 24, 2020 at 2:00 PM Jan Kiszka mailto:jan.kis...@siemens.com>> wrote:

On 22.04.20 06:34, xenomai--- via Xenomai wrote:
 > Download URL:

https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-5.patch
 >
 > Repository: https://git.xenomai.org/ipipe-arm64
 > Release tag: ipipe-core-4.19.115-arm64-5
 >

I think we have a build regression here:

https://travis-ci.com/github/xenomai-ci/xenomai/jobs/323104732

Could your have a look, Greg?

I must have missed a commit, I’ll have it fixed up tonight. If I delete 
the tag and regenerate the patch can it stay at 05 or do I need to bump 
to 06?

Don't do history rewriting on releases. I did quite a few bad releases 
as well already. Just roll out a better one. ;)

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

2020-04-24 Thread Greg Gallagher via Xenomai

On Fri, Apr 24, 2020 at 2:06 PM Greg Gallagher 
wrote:

> Sure no problem
>
> On Fri, Apr 24, 2020 at 2:00 PM Jan Kiszka  wrote:
>
>> On 22.04.20 06:34, xenomai--- via Xenomai wrote:
>> > Download URL:
>> https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-5.patch
>> >
>> > Repository: https://git.xenomai.org/ipipe-arm64
>> > Release tag: ipipe-core-4.19.115-arm64-5
>> >
>>
>> I think we have a build regression here:
>>
>> https://travis-ci.com/github/xenomai-ci/xenomai/jobs/323104732
>>
>> Could your have a look, Greg?
>
>
I must have missed a commit, I’ll have it fixed up tonight. If I delete the
tag and regenerate the patch can it stay at 05 or do I need to bump to 06?

Thanks

Greg


>>
>> Thanks,
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
>>
>

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

2020-04-24 Thread Greg Gallagher via Xenomai

Sure no problem

On Fri, Apr 24, 2020 at 2:00 PM Jan Kiszka  wrote:

> On 22.04.20 06:34, xenomai--- via Xenomai wrote:
> > Download URL:
> https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-5.patch
> >
> > Repository: https://git.xenomai.org/ipipe-arm64
> > Release tag: ipipe-core-4.19.115-arm64-5
> >
>
> I think we have a build regression here:
>
> https://travis-ci.com/github/xenomai-ci/xenomai/jobs/323104732
>
> Could your have a look, Greg?
>
> Thanks,
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

2020-04-24 Thread Jan Kiszka via Xenomai


On 22.04.20 06:34, xenomai--- via Xenomai wrote:

Download URL: 
https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.115-arm64-5.patch

Repository: https://git.xenomai.org/ipipe-arm64
Release tag: ipipe-core-4.19.115-arm64-5



I think we have a build regression here:

https://travis-ci.com/github/xenomai-ci/xenomai/jobs/323104732

Could your have a look, Greg?

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Fwd: [PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

2020-04-24 Thread Laurentiu-Cristian Duca via Xenomai

-- 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
>

Re: [PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

2020-04-24 Thread Jan Kiszka via Xenomai


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

Re: [PATCH] testsuite/smokey: Do not load .gdbinit in gdb test

2020-04-24 Thread Jan Kiszka via Xenomai


On 23.04.20 08:45, Vitaly Chikunov wrote:

Avoid possible prompt being redefined in `.gdbinit' which could break
gdb test.

Signed-off-by: Vitaly Chikunov 
---
  testsuite/smokey/gdb/gdb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git testsuite/smokey/gdb/gdb.c testsuite/smokey/gdb/gdb.c
index cc11d2352..eabf75e6a 100644
--- testsuite/smokey/gdb/gdb.c
+++ testsuite/smokey/gdb/gdb.c
@@ -273,7 +273,7 @@ static int run_gdb(struct smokey_test *t, int argc, char 
*const argv[])
  
  			snprintf(run_param, sizeof(run_param), "--run=%d",

 t->__reserved.id);
-   execlp("gdb", "gdb", "--args",
+   execlp("gdb", "gdb", "--nx", "--args",
  argv[0], run_param, "run_target", (char *)NULL);
_exit(ESRCH);
  



Thanks, applied.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

RE: Regarding Xenomai patch installation on Live USB

2020-04-24 Thread Meng, Fino via Xenomai


>From: gopi ratnakaram  Sent: Friday, April 
>24, 2020 3:44 PM
>
>Dear Fino,
>
>After doing all of the steps mentioned in the following link,
>https://github.com/intel/linux-stable-xenomai/wiki/Guide-
>the following error I am getting during testing on my C246P chipset based 
>industrial motherboard loaded with Ubuntu18.04.
>$ sudo /opt/xenomai-3.1/bin/latency
>  0"000.000| BUG in low_init(): [main] Cobalt core not enabled in kernel 
>
>Is there any installation related issue and how can I resolve this issue?
>I tried the same in my laptop loaded  with Ubuntu 16.04, I didn't face any 
>issue and everything works fine. I am also checking with a laptop loaded with 
>Ubuntu 18.04.
>I am totally confused that this issue is  with the motherboard or Ubuntu 
>version?

Looks like u didn't select Xenomai patched kernel on grub menu;

$sudo nano /etc/default/grub
### comment out GRUB_TIMEOUT_STYLE=hidden
### update GRUB_TIMEOUT=10
$sudo update-grub  ### don't forget this
$sudo reboot
### grub menu should show during boot, wait for 10 seconds, 
### enter advanced options and select Linux 4.19.59-xenomai+
### u can check if kernel patched with Xenomai I-Pipe patches by
$dmesg | grep -i xenomai

We will add this part on the wiki; 

BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

On Mon, Apr 20, 2020 at 4:17 PM Meng, Fino mailto:fino.m...@intel.com> > wrote:



>
>Thank you for your email response Fino.
>
>Maybe due to 4.9.* is too far away from Ubuntu 1804's original kernel; 
What will be the issue in this case? Due to any hardware
>driver dependency causing this issue?
>
>We make this repo for convenience, Kernel version is 4.19.59 with some 
Intel BSP patches.
>working good on Ubuntu 1804; but didn't make it on Live USB yet, 
https://github.com/intel/linux-stable-xenomai/wiki/Guide-
>of-Xenomai-Build-and-Installation-on-Top-of-Ubuntu
>
>
>Is there any restriction to use the Xenomai on live USB or can I 
proceed and install using the steps provided by you?
>

We didn't study it yet, we internally build out live USB image from 
yocto/bitbake based codebase; u can try, 

>
>One more thing is I am trying to install this on a specific 
motherboard of industrial grade which is based on a c246p chipset and
>core i7 6 core processor (i7 8700). Will my hardware cause any issue. 
Because I have installed Xenomai on different PCs and
>Laptops multiple times and never faced any issue.

We have seen 4.9.* working on newest WHL-U and other platform; the 
thing is if it fail to boot any certain machine, 
It take time to debug, u may need a serial port to printout boot log to 
speed up the debug process.

>
>--thanks & regards,
>R Gopi Krishna
>
>
>
>On Mon, Apr 20, 2020 at 10:57 AM Meng, Fino mailto:fino.m...@intel.com>   > > wrote:
>
>
>
>   >
>   >Dear team members,
>   >
>   >I tried installing the Xenomai patch on live USB loaded with 
Ubuntu 18.04.
>   >I have patched kernel version 4.9.38 and tried to boot the 
Xenomai patched one. When I try to boot my motherboard
>it is
>   >unable to boot. Can I install the Xenomai patch on Live USB? 
What is causing this problem?
>   >
>   >--best regards,
>   >R Gopi Krishna,
>
>
>   Maybe due to 4.9.* is too far away from Ubuntu 1804's original 
kernel;
>   We make this repo for convenience, Kernel version is 4.19.59 
with some Intel BSP patches.
>   working good on Ubuntu 1804; but didn't make it on Live USB yet,
>   
https://github.com/intel/linux-stable-xenomai/wiki/Guide-of-Xenomai-Build-and-Installation-on-Top-of-Ubuntu
>
>   BR / Fino (孟祥夫)
>   Intel – IOTG Developer Enabling
>


BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

[PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

2020-04-24 Thread Laurentiu-Cristian Duca via Xenomai

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: Regarding Xenomai patch installation on Live USB

2020-04-24 Thread gopi ratnakaram via Xenomai

Dear Fino,

After doing all of the steps mentioned in the following link,

https://github.com/intel/linux-stable-xenomai/wiki/Guide-

the following error I am getting during testing on my C246P chipset based
industrial motherboard loaded with Ubuntu18.04.

$ sudo /opt/xenomai-3.1/bin/latency
   0"000.000| BUG in low_init(): [main] Cobalt core not enabled in kernel

Is there any installation related issue and how can I resolve this issue?

I tried the same in my laptop loaded  with Ubuntu 16.04, I didn't face any
issue and everything works fine. I am also checking with a laptop loaded
with Ubuntu 18.04.

I am totally confused that this issue is  with the motherboard or Ubuntu
version?


--best regards,
R Gopi Krishna,


On Mon, Apr 20, 2020 at 4:17 PM Meng, Fino  wrote:

>
> >
> >Thank you for your email response Fino.
> >
> >Maybe due to 4.9.* is too far away from Ubuntu 1804's original kernel;
> What will be the issue in this case? Due to any hardware
> >driver dependency causing this issue?
> >
> >We make this repo for convenience, Kernel version is 4.19.59 with some
> Intel BSP patches.
> >working good on Ubuntu 1804; but didn't make it on Live USB yet,
> https://github.com/intel/linux-stable-xenomai/wiki/Guide-
> >of-Xenomai-Build-and-Installation-on-Top-of-Ubuntu
> >
> >
> >Is there any restriction to use the Xenomai on live USB or can I proceed
> and install using the steps provided by you?
> >
>
> We didn't study it yet, we internally build out live USB image from
> yocto/bitbake based codebase; u can try,
>
> >
> >One more thing is I am trying to install this on a specific motherboard
> of industrial grade which is based on a c246p chipset and
> >core i7 6 core processor (i7 8700). Will my hardware cause any issue.
> Because I have installed Xenomai on different PCs and
> >Laptops multiple times and never faced any issue.
>
> We have seen 4.9.* working on newest WHL-U and other platform; the thing
> is if it fail to boot any certain machine,
> It take time to debug, u may need a serial port to printout boot log to
> speed up the debug process.
>
> >
> >--thanks & regards,
> >R Gopi Krishna
> >
> >
> >
> >On Mon, Apr 20, 2020 at 10:57 AM Meng, Fino  fino.m...@intel.com> > wrote:
> >
> >
> >
> >   >
> >   >Dear team members,
> >   >
> >   >I tried installing the Xenomai patch on live USB loaded with
> Ubuntu 18.04.
> >   >I have patched kernel version 4.9.38 and tried to boot the
> Xenomai patched one. When I try to boot my motherboard
> >it is
> >   >unable to boot. Can I install the Xenomai patch on Live USB? What
> is causing this problem?
> >   >
> >   >--best regards,
> >   >R Gopi Krishna,
> >
> >
> >   Maybe due to 4.9.* is too far away from Ubuntu 1804's original
> kernel;
> >   We make this repo for convenience, Kernel version is 4.19.59 with
> some Intel BSP patches.
> >   working good on Ubuntu 1804; but didn't make it on Live USB yet,
> >
> https://github.com/intel/linux-stable-xenomai/wiki/Guide-of-Xenomai-Build-and-Installation-on-Top-of-Ubuntu
> >
> >   BR / Fino (孟祥夫)
> >   Intel – IOTG Developer Enabling
> >
>
>
> BR / Fino (孟祥夫)
> Intel – IOTG Developer Enabling
>
>

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

[I-PIPE] ipipe-core-4.19.115-arm64-6 released

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

Re: [I-PIPE] ipipe-core-4.19.115-arm64-5 released

Fwd: [PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

Re: [PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

Re: [PATCH] testsuite/smokey: Do not load .gdbinit in gdb test

RE: Regarding Xenomai patch installation on Live USB

[PATCH] Avoid a possible too early interrupt from the omap mcSPI controller

Re: Regarding Xenomai patch installation on Live USB

12 matches

Site Navigation

Mail list logo

Footer information