Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

nt has already 47 pages and 34 of the actual text without content and appendices. Document includes benchmarks under RTEMS load by HTTP traffic, priority inversion prevention confirmation by measurements with performance data etc. It will be published on CTU in May or June https://dspace.cvut.cz/ and l

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

vel PS: Michal Lenc has succeed with this weekend experiment to add support of proposed RTEMS CAN interface into evolving yet toy Rapid Prototyping tool https://github.com/robertobucher/pysimCoder on base of experimental RTEMS target templates. PS2: I have tested to build comp

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

. Only classic CAN frames for now, FD is ignored https://ortcan.sourceforge.net/ https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - Embedded World

to us. If there is some RTEMS meeting, we will try to reserve time. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

Hello Gedare, thanks for feedback. On Tuesday 05 of March 2024 22:54:35 Gedare Bloom wrote: > On Thu, Feb 29, 2024 at 6:40 AM Pavel Pisa wrote: > > On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > > > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote: >

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

Hello Gedare On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote: > > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under > > my supervision. The project has reached a phase where we will be ve

[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

rojects in person. Our latency testing focuses on Linux SocketCAN, but long ago, we tested LinCAN on Linux and even original MSM CAN on RTEMS. I plan to add RTEMS to our actual latency tester project in the frame of some another future student project. Best wishes, Pavel

Re: [PATCH 47/47] bsp/tms570: Update README

same as many other promissing projects in 2016... Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/

Re: [PATCH 24/47] bsp/tms570: Remove double pin configuration

eally abundant but I would suggest to do the analysis again. I need to find some time to refresh TMS570 knowledge because it is eight years already when we build base TMS570L3137 support with Premek... But I am sure that this was the idea behind update in two phases. Best wishes,

Re: [PATCH 0/8] Add basic support for TMS570LC4357

There is some possibility that I will teach computer architectures in the space oriented course so replacement of Raspberry Pi by BeagleV-Fire and RTESM could be great demonstrator on ExoMy or other platform https://github.com/esa-prl/ExoMy Best wishes, Pavel --

RTEMS CAN/CAN FD project - start and initial progress report

in meeting and discussing CAN/CAN FD/CANopen use in space as well as RTEMS, Linux, NuttX related tasks, you can contact me, and we can meet at ESTEC. Best wishes, Pavel Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control

Re: Status of CAN API?

a must. > > The implementation of that API was deficient. It did not support > > multiple read/write transactions, it had a custom-built ring buffer > > that was not fully vetted, and some other problems related to > > threads+priorities. I expect to have some time to look at

Re: [PATCH] TMS570 console driver, SCI frame error (baudrate calculation error)

r SCI/LIN update to ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | TMS570_LIN_BRS_M(bauddiv & 0xf); Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karl

Re: [PATCH 0/8] Add basic support for TMS570LC4357

-- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ company:https://www.pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

ted to RTEMS. We have even done design of experimental ECU based on TMS570LS3137 with my colleague from PiKRON company for Porsche... So we can share knowledge... TMS570LC4357 is even more interesting, becase it has more RAM which could allow better TCP/IP experience even without external RAM. B

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

Hello Sebastian, On Friday 24 of March 2023 11:21:57 Sebastian Huber wrote: > Hello Pavel, > > On 18.03.23 01:04, Pavel Pisa wrote: > > As for > > > > +static inline void > > +tms570_data_sync_barier(void) > > +{ > > +#ifdef __arm__ > >

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

Hello Kinsey and Sebastian, On Thursday 09 of March 2023 14:46:28 Kinsey Moore wrote: > Normally with rtems-lwip I would complain that this doesn't follow the > convention of using #ifdef __rtems__ to modify files from upstream sources > (each root directory except rtemslwip has an upstream

Re: RTEMS LwIP licensing and organization cleanup proposal - actual Ti code license

Hello Joel and Gedare On Friday 03 of March 2023 14:32:33 Pavel Pisa wrote: > The RTEMS core integration layer is held in uLan/ports/os/rtems > subdirectory > > https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c > > It should be moved somewher

Re: CAN driver implementation for Xilinx Zynq

I have some more produced for myself https://cw.fel.cvut.cz/wiki/courses/b35apo/en/documentation/mz_apo/start Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVU

RTEMS LwIP licensing and organization cleanup proposal

Dear Premek and other developers, I am happy that LwIP is getting into state of viable alternative of TCP/IP stack for resource constrained RTEMS targets. But as I have already reported before, I would be happy if the code licenses and locations are cleanup. The RTEMS core integration layer is

Re: TMS570 OpenOCD Flash Support

s his school work where he has rights by our contry laws. So it has almost no connection to left people and former group work. So I see relicensing of that files to RTEMS as nonproblematic... So it is only to find time and obtain confirmation from Premysl Houdek and then cleaning the files locations.

Re: Updated CAN message structure.

Hello Prashanth S, On Tuesday 21 of June 2022 19:00:42 Prashanth S wrote: > This is to present the updated CAN message structure. > > *Updating the CAN message structure:* > > struct can_message { > uint32_t id; // 32 bits to support extended id (29 bits) > uint32_t timestamp;

Re: GSoC 2022 - CAN API test

Hello Prashanth S and others, I am copying reply to the list for recrd and others consideration On Sunday 19 of June 2022 17:30:16 Christian Mauderer wrote: > Would that be a generic test for the CAN API that all BSPs can run? Or > would it be a hardware specific one? The CAN base test can be

Fwd: Re: Request for feedback for CAN message structure

I am forwarding Oliver Hartkopp's founded reply to the list for archival and rest of the RTEMS community -- Forwarded Message -- Subject: Re: Request for feedback for CAN message structure Date: Tuesday 21 of June 2022, 08:55:03 From: Oliver Hartkopp To: Pavel Pisa , devel

Re: Request for feedback for CAN message structure

Hello Prashanth S and others, excuse me for lower activity last weeks. We have exams period and I have lot of other duties and was even ill. I am at Embedded World in Nuremberg now, so may it be there is some chance to meet somebody other from RTEMS community. As for the e-mail it is better to

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

rses/b35apo/en/start including simulator https://github.com/cvut/qtrvsim and public recording (even English, sorry Czenglish) https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M Best wishes, Pavel Pisa == PiKR

Re: Last call for Mentors

On Friday 22 of April 2022 23:21:29 Pavel Pisa wrote: > Hello Gedare, Excuse me for spamming the list. I hit send witout checking that reply to author filled list address but not to him directly. Anyway nothing secret in the email. Nice weekend to all, Pa

Re: Last call for Mentors

art so I should already know enough to try to write it to the simulator... Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35,

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

Hello Kamlesh, On Tuesday 19 of April 2022 16:30:25 Kamlesh Bharodiya wrote: > I was afk for the last two days. As the deadline is already here. I have > submitted the proposal after reviewing your comments from the mail. Thank > you for taking the time out. Thanks to Noor Aman and Gedare, I have

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

there are industrial equivalents RM57L843 and RM48L740. RM are usually little endian, all TMS570 I have met are big endian. As I have reported already On Saturday 16 of April 2022 16:11:02 Pavel Pisa wrote: > As I know, the Cortex-R5 core is already supported > by RTEMS and our TMS570LS

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

xpect two or three round for it and this should be real goal of GSoC and real evaluation. So I suggest move more coding to the first half and some reserve and documention and review process to the second half. Best wishes, Pavel > On Sat, 16 Apr, 2022, 7:41 pm Pavel Pisa, wrote: >

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

Hello Joel, On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote: > On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote: > > On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote: > > > rename {lwip => uLan}/ports/os/lwipopts.h (100%) > > > > >

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

d into RTEMS mainline. But please, do not add there uLAN name nor OMK (our makesystem abbreviation). Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo name

Re: GSoC - CAN driver for BBB Was: CAN Options and Licensing, Testing, etc

er whole summer and I have quite lot to do till semester end, so I can have week or two delay... not ideal for main mentor. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

h ZCU102? I have no much idea how difficult the project is... I can help as co-mentor, I cannot offer main mentor role because I have too many running projects. I CC to Sebastian Huber, because if I remember well they have provided support for some Cortex-R5 platform already. Best wishes,

Re: CAN Options and Licensing, Testing, etc

Dear Prashanth, On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote: > Have you determined how you will test CAN on BBB? > > I planned to test the CAN driver with another BBB running linux. And if CAN > analyzer is economical then I would use that. I think that testing against Linux kernel

Re: CAN Options and Licensing, Testing, etc

Hello Joel, Prashanth and others, On Tuesday 12 of April 2022 15:43:58 Joel Sherrill wrote: > + LinCAN - GPL > + SocketCAN - GPL > + NuttX CAN - Apache > + CANOpen - Apache > > The licensing alone eliminates two of the solutions. LinCAN license is GPL with special exception which I proposed at

Re: CAN driver message structure

Hello Prashanth, Karel and Gedare, On Tuesday 12 of April 2022 08:50:04 Karel Gardas wrote: > not sure about others but Pavel Pisa is CAN expert here. CCing him > directly as I've not seen him active recently. Thanks for poke. I am subscribed on RTEMS devel (and many more lists) bu

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

has been located again it would worth to collect in on one place. We have some enhancements of the LPC driver in our OMK repo, so we can merge updates. I expect that they do not collide with changes for RTEMS build. Best wishes, Pavel Pisa ===

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

Hello Vijay, thanks of the status. On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote: > Hi Pavel, > > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa wrote: > > Is it devel branch of Vijay Kumar Banerjee's > > repo > > > > https://git.rtems.org/vi

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

Hello everybody, I have no technical stuff to share for now, but I am happy that work on LwIP alternative stack for RTEMS continues on. I have question which repo is considered as mainline (integration point) for this work. Is it devel branch of Vijay Kumar Banerjee's repo

Re: [PATCH] Fixes for TMS570 BSP

Hello Robin and Gedare, (sent again to pass into the list) On Monday 19 of April 2021 19:13:29 Gedare Bloom wrote: > Hi Robin, Pavel: > > On Mon, Apr 19, 2021 at 2:57 AM Robin Müller > wrote: > > If this was intentional, I can also adapt the lwIP port sources to use > > ti/herc. I was not sure

Re: How to use lvgl on pc386 BSP.

the last semester and next one has been switched to the distat one on the last Friday as well. Best wishes, Pavel Pisa company:https://www.pikron.com/ e-mail: pp...@pikron.com Czech Technical University in Prague e-mail: p...@cmp.felk.cvut.cz Depar

Re: RTEMS CAN support Was: Hello World on BeagleBone

but generally straightforward and with promissing results. Best wishes, Pavel Pisa On Tuesday 10 of March 2020 23:12:23 Gedare Bloom wrote: > I would be willing to mentor a CAN project. Perhaps another will come > along. If your proposal truly shines, a mentor may be found. > > On

LwIP integration - mapping RTEMS FDs to LwIP ones

CONFIG_LWIP_LWIP_NETIF_API=1 Best wishes, Pavel Pisa ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] score: Introduce new monotonic clock

u and all others, Pavel Pisa ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: TMS570LC43x - what should be done before coding

opy required files to the RTEMS and use it in that HalCoGen assisted mode to run simple shell demo. Use your GSoC project Wiki page to maintain some TODO list and sumarise your achievements and problems https://devel.rtems.org/wiki/GSoC/2017/TMS570_BSP_improv

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

gt; On Tue, Apr 25, 2017 at 4:53 AM, Pavel Pisa <ppisa4li...@pikron.com> wrote: > > From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001 > > Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git. > > pp...@pikron.com> > > From: Pa

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

>From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001 Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.pp...@pikron.com> From: Pavel Pisa <pp...@pikron.com> Date: Tue, 25 Apr 2017 11:45:57 +0200 Subject: [PATCH] bsp/raspberrypi: GPIO

Re: [PATCH 0/2] Zynq7000 series device configuration driver

Hello Chris, Patrick and others, I am sending pointers to some of our Zynq work which can be used for test designs. On Friday 21 of April 2017 00:37:16 Chris Johns wrote: > On 21/04/2017 07:55, Patrick Gauvin wrote: > > Gedare, > > > > > > if the test programs are specific to the Zynq BSP,

Re: Lots of BSPs Fail to Build Tests on Master

Hello Joel, On Saturday 14 of January 2017 00:01:09 Joel Sherrill wrote: > Hi > > The following BSPs do not successfully complete a build with all > tests enabled. A spot check of a few shows that some tests do > not fit in memory. There may be other issues. This is a major > regression. > >

Re: Update virtio network driver

Hello Jin-Hyun, On Tuesday 15 of November 2016 11:29:05 Pavel Pisa wrote: > Hello Jin-Hyun, > > thanks for update. > > I have returned from my USA holydays now and catching up > with e-mails and work backlogs. > > On Thursday 10 of November 2016 10:42:34 Jinhyun wrote:

Re: Update virtio network driver

-in function of gcc, __sync_synchronize(). This function generates > proper memory barrier for target architecture on compile time. In addition, > we replaced pcib_conf_read/write functions to pci_read/write_config > functions. We added several lines of codes for exception handling suggested &

Re: i386 SMP buils - Was: libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

Hello Chris, On Monday 17 of October 2016 03:00:56 Chris Johns wrote: > I have built and tested these patches with no issues and 0 spurious > interrupts. > > The changes look fine to me. Thanks much for testing. I have pushed changes to the master. I have spent considerable time over weekend by

Re: Time spent in ticks...

Hello Joel, On Friday 14 of October 2016 00:56:21 Joel Sherrill wrote: > On Thu, Oct 13, 2016 at 1:37 PM, Joel Sherrill wrote: > > On Thu, Oct 13, 2016 at 11:21 AM, Jakob Viketoft < > > > > jakob.viket...@aacmicrotec.com> wrote: > >> *From:* Joel Sherrill [j...@rtems.org] > >>

Re: Time spent in ticks...

Hello Jakob, On Thursday 13 of October 2016 18:21:05 Jakob Viketoft wrote: > I re-tested my case using an -O3 optimization (we have been using -O0 > during development for debugging purposes) and I got a good performance > boost, but I'm still nowhere near your numbers. I can vouch for that the >

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

Some typo corrections of e-mail written when I have returned late in night from meeting with friends. And some more clarification as well. On Thursday 13 of October 2016 01:55:30 Pavel Pisa wrote: > Hello Chris, > > On Wednesday 12 of October 2016 23:05:30 Chris Johns wrote: > > O

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

Hello Chris, On Wednesday 12 of October 2016 23:05:30 Chris Johns wrote: > On 13/10/2016 03:22, Pavel Pisa wrote: > > But RTEMS i8269 support has been broken to disable > > vector for level triggered interrupts in generic > > IRQ processing code. > > I am not sure where

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

Hello Gedare, On Wednesday 12 of October 2016 18:10:19 Gedare Bloom wrote: > On Wed, Oct 12, 2016 at 4:26 AM, <p...@cmp.felk.cvut.cz> wrote: > > From: Pavel Pisa <p...@cmp.felk.cvut.cz> > > > > The single write to memory or ioport output are mostly > >

Re: [PATCH 2/3] bsps/i386: use Pentimum instructions for pc586 and pc686 builds.

Hello Sebastian, On Wednesday 12 of October 2016 10:35:55 Sebastian Huber wrote: > On 12/10/16 10:26, p...@cmp.felk.cvut.cz wrote: > > SMP build is broken with i386 set because libatomic and GCC > > generate infinite loop for __atomic_fetch_add_4 used > > in rtems_interrupt_lock_acquire > > > >

Re: [PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

On Sunday 25 of September 2016 02:48:03 Pavel Pisa wrote: > From: Pavel Pisa <p...@cmp.felk.cvut.cz> > > The global state of enabled and disabled interrupts has to hold > interrupts really disabled by drivers and system. If the state is > combined with interrupts tempora

Re: Backport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

Hello Chris, On Tuesday 04 of October 2016 23:10:20 Chris Johns wrote: > On 04/10/2016 09:51, Pavel Pisa wrote: > > Hello Chris and Joel, > > > > I would like to correct my mistake which breaks RTEMS 4.11 build for > > non-ARM architectures, as fast as possible.

Re: Update Atsam BSP Support

Hello Gedare and Alexander, one possible solution to keep that in sync. Change of README in BSP directory to MarkDown or Rest-Text syntax and put on the web generated pages synced directly from master and last stable. On the other hand, wiki allows to include more information and relation

Re: Backport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

Hello Chris and Joel, I would like to correct my mistake which breaks RTEMS 4.11 build for non-ARM architectures, as fast as possible. Proposed solution on devel list. [PATCH] libdl/rtl-obj.c: synchronize cache should not depend on CPU_CACHE_LINE_BYTES. [PATCH] bsps/arm: do not introduce

[PATCH] bsps/arm: do not introduce CPU_CACHE_LINE_BYTES in 4.11 and correct CPU_STRUCTURE_ALIGNMENT.

--- cpukit/score/cpu/arm/rtems/score/cpu.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h b/cpukit/score/cpu/arm/rtems/score/cpu.h index 25d4ee2..69838c5 100644 --- a/cpukit/score/cpu/arm/rtems/score/cpu.h +++

[PATCH] libdl/rtl-obj.c: synchronize cache should not depend on CPU_CACHE_LINE_BYTES.

The CPU_CACHE_LINE_BYTES has been introduced after 4.11 branch fork and is not available for all architectures on RTEMS 4.11. Use of rtems_cache_get_maximal_line_size() is more descriptive choice. The min/max data/instruction cache line size is not critical there, value is used for optimization

Re: Bacport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

Hello Alan, thanks much for test. On Monday 03 of October 2016 03:40:46 Alan Cudmore wrote: > Hi Pavel, > I have built the Raspberry Pi 1 and 2 BSPs with the latest 4.11 branch. I > plan on testing them soon. > > I also tried to build the 4.11 sparc/sis BSP, but it failed to compile: >

Bacport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

hes, Pavel On Tuesday 06 of September 2016 09:28:42 Pavel Pisa wrote: > Hello Chris, > > On Tuesday 06 of September 2016 07:12:53 Chris Johns wrote: > > Hi Tim and Pavel, > > > > Thank you for the patches and testing. I will have a chat to Joel > > to

Re: [PATCH] score: Unify CORE mutex seize/surrender

Hello Sebastian, On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote: > On 28/09/16 10:47, Sebastian Huber wrote: > > On 28/09/16 10:38, Pavel Pisa wrote: > >> Hello Sebastian and Gedare, > >> > >> I cannot hold myself to not express my opin

Re: [PATCH] score: Unify CORE mutex seize/surrender

Hello Sebastian and Gedare, I cannot hold myself to not express my opinion there. On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote: > On 27/09/16 16:59, Gedare Bloom wrote: > > A mostly unrelated question: why do we have two different > > _Semaphore_Get functions, one static in

Re: [PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

Hello Chris, On Sunday 25 of September 2016 03:24:06 Chris Johns wrote: > Hi Pavel, > > Thank you for this. What testing has the patch had? Only QEMU, serial and E100 and VirtIO NIC. So I agree that testing on the real HW is a must. We have some test PCs with remote booting and monitoring at

Re: VirtIO based network driver works well after i8259 masks maintenance correction

Hello Jin-Hyun Kim, Hyun-Wook Jin and others, I have returned back to VirtIO based network driver after I have make PCI based E100 card work by woraround which re-enables IRQ in driver worker daemon. In meanwhile, I have included alternative networking setup with E100 to RTEMS QEMU Wiki page

[PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

From: Pavel Pisa <p...@cmp.felk.cvut.cz> The global state of enabled and disabled interrupts has to hold interrupts really disabled by drivers and system. If the state is combined with interrupts temporarily disabled because they are processed at given time then it is impossible to maintain

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

Hello Gedare, On Thursday 22 of September 2016 03:26:32 Gedare Bloom wrote: > I only added a couple of very minor inline comments. Looks good, I > think you can push directly no one else needs to re-read this > BSP-specific stuff. thanks much for reading that huge pieces. I have corrected some

Re: RTEMS classic networking: fixed FXP driver works under QEMU on Linux

Hello all, the driver works after hours of problem seeking in incorrect directions. I have debugged, examined and patched both, RTEMS and QEMU. The main problem is quite simple. Update of RTEMS interrupts processing disable level type interrupts when they arrive and the driver/daemon has to

[PATCH] classic networking: adapt FXP driver to work with actual PCI

From: Pavel Pisa <p...@cmp.felk.cvut.cz> Tested to work with QEMU provided Intel i82557b network controller emulation. qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \ -vga cirrus \ -append "--console=/dev/com1" \ -serial stdio \ -net nic,vlan=1,macadd

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

Hello Gedare, On Wednesday 14 of September 2016 02:13:47 Gedare Bloom wrote: > On Tue, Sep 13, 2016 at 5:11 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote: > > Hello Gedare, > > > > thanks for the review. It is huge piece and not in a state > > as nice as I wou

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

Hello Chris and others, On Sunday 11 of September 2016 08:53:09 Chris Johns wrote: > On 09/09/2016 17:47, Sebastian Huber wrote: > > On 09/09/16 09:43, Pavel Pisa wrote: > >> Hello Chris and others, > >> > >> On Friday 09 of September 2016 02:06:19 Chris Joh

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

Hello Chris, On Thursday 08 of September 2016 09:14:00 Chris Johns wrote: > On 05/09/2016 00:38, Alan Cudmore wrote: > > I applied your patches, and verified that my apps still work on the > > Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests. > > I have verified a few tests

Re: Raspberry Pi 2 SMP pushed to the master - Was: [PATCH 11 minor addeum] ...

Hello Sebastian, Alan and others, On Wednesday 07 of September 2016 09:27:21 Sebastian Huber wrote: > > should they go to the same compilation unit as _CPU_SMP_Start_processor > > or bspsmp-init.c separate one. > > > > Or I should not care about smpfatal08 or add required symbol to it. > > It

Re: [PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

Hello Sebastian, On Wednesday 07 of September 2016 07:33:36 Sebastian Huber wrote: > Hello Pavel, > > On 06/09/16 21:48, Pavel Pisa wrote: > > Hello Sebastian, > > > > On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote: > >> The interrupt locks

Re: [PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

Hello Sebastian, On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote: > The interrupt locks are simple interrupt disable/enable or spin locks. So, > they always work. Allmost, on UP they are simple local IRQ disable. But on SMP they are spinlock combined with IRQ disable. But spinlock

[PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

Locking can be used only when RTEMS reaches multitasking state _System_state_Is_up( _System_state_Get() ) --- c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

Hello Alan, On Sunday 04 of September 2016 16:38:36 Alan Cudmore wrote: > Hi Pavel, > I applied your patches, and verified that my apps still work on the > Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests. > > When building for the Pi 2, I need to use the —enable-smp

Re: [PATCH v3 1/7] Imported files for driver: bcm283x_dwcotg

Hello Deval, I cannot comment much libbsd changes because I have little experience there, but I am curious if you have some results from testing on real hardware. Is USB bus correctly enumerated? Is ETHERNET chip found? Can you send ping or other communication works? If all is yes, what is

Re: arm/xilinx_zynq: Disable the MMU on startup and CPU CP15 recognized cache levels

Hello Chrisn, thanks for commiting. Have you tested code on Zynq in SMP RTEMS build? I have tested only on Zynq UP for now. I have run test to document which cache levels are maintained by CP15 by different ARM chips. I print only data and unified ones ones because it is enough for levels and

[PATCH v4 ppisa] arm/xilinx_zynq: ensure that cache is cleaned and MMU disabled when initialization starts.

The u-boot loader enables the MMU plus the data and instruction caches in some versions which results in RTEMS boot failure. Closes #2774. --- .../libbsp/arm/xilinx-zynq/startup/bspstarthooks.c | 35 ++ 1 file changed, 35 insertions(+) diff --git

Re: [PATCH v3] arm/xilinx_zynq: Disable the MMU and the data and instruction cache on boot.

Hello Chris, I am trying to think about consequences. On Wednesday 31 of August 2016 04:16:34 Chris Johns wrote: > The u-boot loader can enable the MMU plus the data and instruction caches. > Disable them and if the data cache is enabled clear it before turn the > caches off. > > Closes #2774.

Re: [PATCH v2] Mailbox : Extending functionality

gress in DMA API testing corrections. See my branch https://github.com/ppisa/rtems/tree/rtems-rpi-devel-dma-test The most commits are self describing commit 3612ab75aba53ae911232f30ff115672d5e2e06f Author: Pavel Pisa <p...@cmp.felk.cvut.cz> Date: Fri Aug 26 02:53:08 2016 +0200 arm/ra

Re: [PATCH v2] Mailbox : Extending functionality

Hello Mudit, On Saturday 27 of August 2016 08:15:04 Mudit Jain wrote: > Adding functionality to get board serial, > power state & clock rate I have pushed patch to the master. Have you some info/progress with DMA? Best wishes, Pavel

Re: [PATCH] DMA : Added DMA API for Raspberrypi

Hello Mudit Jain, I have tried to test the DMA API code I have setup temporary branch on my RTEMS tests repo https://github.com/ppisa/rtems/tree/rtems-rpi-devel-dma-test I have applied patches extracted from your GitHub repository Re: [PATCH] Mailbox : Extending functionality

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

Hello Gedare, On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote: > On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa <ppisa4li...@pikron.com> wrote: > > Is there some defined function/way to check if RTEMS executive > > reached switch

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

hen scheduler is running for further update of system state. More complete analysis and context in previous communication. Best wishes, Pavel On Tuesday 16 of August 2016 15:28:42 Pavel Pisa wrote: > Hello Chris and Sebastian, > > On Tuesday 16 of August 2016 07:55:57 Seb

Re: [PATCH] Added interrupt handler for DMA channel 0, 1 & 2

Hello Mudit, please, send information what is RTEMS GIT revision are your changes based on. See comment below On Saturday 20 of August 2016 17:04:19 Mudit Jain wrote: > Added macros for DMA channels 0-12 > Added interrupt handlers for DMA 0, 1 & 2 > > The added IRQs are in accordance with the >

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

Hello Chris and Sebastian, On Tuesday 16 of August 2016 07:55:57 Sebastian Huber wrote: > On 16/08/16 07:45, Chris Johns wrote: > > --- > > c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git

Re: [PATCH] arm/cortex-a: Fix cache flush/invalidate after u-boot.

Hello Chris, On Monday 15 of August 2016 07:30:56 Chris Johns wrote: > This is a copy of the patch from Pavel to fix some strange behaviour with > data cache, instruction cache and MMU being enabled by u-boot on the > RaspberryPi. > > Closes #2774. My code can have issues with SMP. If the

Re: [PATCH] arm/xilinx_zynq: Disable the MMU and the data and instruction cache on boot.

Hello Chris, On Tuesday 09 of August 2016 09:19:51 Chris Johns wrote: > The u-boot loader can enable the MMU plus the data and instruction caches. > Disable them and if the data cache is enabled clear it before turn the > caches off. > > Closes #2774. > --- >

Re: Expanding Mailbox API

Hello Mudit and Gedare, I have returned from my mountain trip and digging through e-mails flood, some oversight possible. On Saturday 06 of August 2016 20:52:58 Gedare Bloom wrote: > It would make sense to me to refactor this code. I can't recall if > there was a compelling reason to have all of

Re: nanosleep.c remarks

Hello Gedare On Monday 01 of August 2016 17:21:14 Gedare Bloom wrote: > On Mon, Aug 1, 2016 at 1:18 AM, Sebastian Huber > It would be good to add some test cases calling clock_settime() and > delivering signals while a thread nanosleep()s. I don't know that we > have those cases tested yet. > >

Re: DMA for RPi

Hello Mudit, I have put some comments inline on GitHub. On Sunday 31 of July 2016 13:14:46 Mudit Jain wrote: > Hi all, > > I have added code for DMA support for RPi. Here is the link for the same : > > GitHub Link : > https://github.com/spark1729/rtems/commit/f328c4cd89b02977ccc5d7154b4af5ee9

  1   2   3   >