wants to resuse our work,
is welcomed.
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.cv
Hello Emanuel,
On Sunday 23 of June 2024 17:15:13 emanuel stiebler wrote:
> On 2024-06-21 06:27, Pavel Pisa wrote:
> > I want to inform you about the progress of the project.
> >
> > The CTU local project project links can be found in the
> > section CAN/CAN FD Subsyst
usted).
Best wishes,
Pavel Pisa
phone: +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
s
have even 68060
based PEP VME system at university on the shelf.
Best wishes,
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://cont
cial
RTEMS one. The full document 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
t of the pah name.
Best wishes,
Pavel
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
. 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 of
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
unive
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:
>
Hello Gedare
On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote:
> On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote:
> > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under
> > my supervision. The project has reached a phase where we will be very
>
her projects 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
anted 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
ouble run is really 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,
ESA.
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
--
ed 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 Co
he rest as 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
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
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/
company:https://www.pikron.com/
personal: http://cmp.felk.cvu
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
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__
> >
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 source
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
o the university
and 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
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 h
mysl Houdek's one
was 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 clean
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;
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 HW
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 ,
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 ad
i/courses/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
==
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
n/lectures/09/start
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 names
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 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 TMS570LS313
Expect 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:
> > D
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%)
> > >
> >
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
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
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,
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 i
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 un
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)
b
if it 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
=
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.o
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
https://git.rtems.o
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
aching
in 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
load
of work 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.
CONFIG_LWIP_LWIP_NETIF_API=1
Best wishes,
Pavel Pisa
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
u and all others,
Pavel Pisa
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
e 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_improvements
It may be possible Trac issue tracking system to or
gt; On Tue, Apr 25, 2017 at 4:53 AM, Pavel Pisa wrote:
> > From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
> > Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.
> > pp...@pikron.com>
> > From: Pavel Pisa
> > Da
>From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
Message-Id:
<3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.pp...@pikron.com>
From: Pavel Pisa
Date: Tue, 25 Apr 2017 11:45:57 +0200
Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure tha
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, th
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.
>
> arm-l
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:
lt-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 sugges
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
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]
> >> *Sent:* Thursday, O
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
>
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
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
Hello Gedare,
On Wednesday 12 of October 2016 18:10:19 Gedare Bloom wrote:
> On Wed, Oct 12, 2016 at 4:26 AM, wrote:
> > From: Pavel Pisa
> >
> > The single write to memory or ioport output are mostly
> > atomic operations already. The proper memory synchronization
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
> >
> > __
On Sunday 25 of September 2016 02:48:03 Pavel Pisa wrote:
> From: Pavel Pisa
>
> 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
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.
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 links.
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 CPU_CA
---
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
+++ b/cpukit/score/cpu/ar
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 on
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:
> ../../../.
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
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 opinion
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 sc
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 univ
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
ht
From: Pavel Pisa
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 state
by interrupt handlers
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 t
Hello Sebastian,
On Wednesday 21 of September 2016 09:08:25 Sebastian Huber wrote:
> Hello,
>
> I checked in a patch set today that reworks the thread priority
> management. This improves the priority inheritance protocol for example.
big congratulation and thanks. I have checked master today and
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 re-en
From: Pavel Pisa
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,macaddr=be:be:be:10:00:01,mod
Hello Gedare,
I have tried to update code according to your review.
I have added even enabled/uncommented and added implementation
for some more test. Especially ECC integrated TCRAM single errors
correction and reporting test. I have commented why double errors
abort exception based test is comme
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 wrote:
> > Hello Gedare,
> >
> > thanks for the review. It is huge piece and not in a state
> > as nice as I would like it.
> >
> > O
Hello Gedare,
thanks for the review. It is huge piece and not in a state
as nice as I would like it.
On Tuesday 13 of September 2016 21:42:48 Gedare Bloom wrote:
> I'm slowly reading through these. Is there a doc or is it worth it to
> generate one that maps the HalcoGen functions to their RTEMS
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
Hello Chris and others,
On Friday 09 of September 2016 02:06:19 Chris Johns wrote:
> On 09/09/2016 07:46, Pavel Pisa wrote:
> > I have provided simple bsp_reset() for Raspberry Pi and pushed it into
> > master.
>
> Thank you. Is the reset on exit on by default? I rebuilt wi
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 r
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 woul
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 ar
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
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
b/
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 configur
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 throu
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 sha
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 a/c/src/lib/libbsp/arm/xilinx
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.
I
Hello Mudit,
On Sunday 28 of August 2016 09:27:16 Mudit Jain wrote:
> Hi,
>
> That's great news Pavel.
> Should I start merging all your findings and push it as a patch ?
> What would be the next steps ?
I suggest to invest the time into SD part of the project now.
It needs to use DMA as well. As
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
Date: Fri Aug 26 02:53:08 2016 +0200
arm/raspberrypi: DMA API: add simp
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
___
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
https://git
1 - 100 of 345 matches
Mail list logo
