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
--
https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/can-queue.c
LinCAN queues are documented in section 1.4. LinCAN Driver
Architecture of the LinCAN manual
https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
The actual architectural decision (based even on the previous discussi
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
there
https://cmp.felk.cvut.cz/~pisa/tms570/openocd-patches/
There is some set of utilities to use it from GDB
in Premysl Houdek's repository
https://github.com/AoLaD/rtems-tms570-utils
It includes even tools to generate RTEMS style header files
from TI manuals.
As for th
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
nance burden.
>
> You can see an interface/implementation like this in:
> https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan
or look at
https://sourceforge.net/p/ortcan/lincan/ci/master/tree/
and related documentation
https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
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://pikron.com/
personal: http://cmp.felk.cvut.cz/~pisa
projects
e no errors. Here is that output:
> [image: successful_openocd.png]
That is great, that mainline supports TMS570 reliably now. There has been
problem on big-endian R4 to access memory behind EIM (DRAM) in the
older version if I remember well. I have some hack in my patches, I think
https:/
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
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.fe
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
g it even
on NuttX above its character driver API.
http://ortcan.sourceforge.net/vca/
https://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf
But the code would need to be extended with CANopen FD support.
I have been in invited academic guest position at the CANopen
FD standard SIG group meetings and ev
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
select 115200
when baudrate is not selected anywhere. But this is hack which is probably
solved on the other level already
--- a/bsps/arm/tms570/console/tms570-sci.c
+++ b/bsps/arm/tms570/console/tms570-sci.c
@@ -261,6 +261,8 @@ bool tms570_sci_set_attributes(
/* Baud rate */
baudrate = rtems_t
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
from the manual
http://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
The complete concept of our CAN/CANopen components support there
http://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf
But the head of former Real-Time Systems group at our department
has no interrest to continue on
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
ime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo:/system/src/constrs
The schematic diagrams and photos of our design can be found
in the directory
http://cmp.felk.cvut.cz/~pisa/apo/mz_apo/
I have archived/published some U-boot patches and
my local build configu
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
> >
> > __
From: Pavel Pisa
The single write to memory or ioport output are mostly
atomic operations already. The proper memory synchronization barrier
should be used around them to guarantee ordering (sync or eieio
on PowerPC for example) but because I have not found settable
portable primitive only
From: Pavel Pisa
---
c/src/lib/libbsp/i386/pc386/clock/ckinit.c | 19 ++---
c/src/lib/libbsp/i386/pc386/console/inch.c | 10 +++--
c/src/lib/libbsp/i386/pc386/console/keyboard.c | 55 --
c/src/lib/libbsp/i386/pc386/console/vt.c | 13 +++---
c/src/lib
From: Pavel Pisa
The elimination of global interrupt lock is necessity condition
but far from being sufficient for RTEMS x86 SMP support.
Provided changes allows to build i386 BSP with configure
option --enable-smp. The build BSP runs in UP and SMP
configurations on QEMU when only one/boot CPU
From: Pavel Pisa
When GCC option -march is not specifies i386-rtems toolchain
defaults to i386 architecture instruction set. It does not
provide atomic instructions which results in really inefficient
atomic_fetch_or even on UP build.
SMP build is broken with i386 set because libatomic and GCC
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
From: Pavel Pisa
---
c/src/lib/libbsp/arm/tms570/preinstall.am | 13 +
1 file changed, 13 insertions(+)
diff --git a/c/src/lib/libbsp/arm/tms570/preinstall.am
b/c/src/lib/libbsp/arm/tms570/preinstall.am
index be8e42e..7d79184 100644
--- a/c/src/lib/libbsp/arm/tms570/preinstall.am
From: Pavel Pisa
---
c/src/lib/libbsp/arm/tms570/README | 104 +
1 file changed, 82 insertions(+), 22 deletions(-)
diff --git a/c/src/lib/libbsp/arm/tms570/README
b/c/src/lib/libbsp/arm/tms570/README
index f48744f..840ce68 100644
--- a/c/src/lib/libbsp/arm
From: Pavel Pisa
---
c/src/lib/libbsp/arm/tms570/Makefile.am | 21 +
c/src/lib/libbsp/arm/tms570/configure.ac | 4
2 files changed, 25 insertions(+)
diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am
b/c/src/lib/libbsp/arm/tms570/Makefile.am
index c4d39bc..012ce23
From: Pavel Pisa
The configuration is specific for TMS570LS3137 based HDK.
But pins configuration can be easily changed in
rtems/c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c
file.
---
.../arm/tms570/hwinit/bspstarthooks-hwinit.c | 393 ++
.../libbsp/arm/tms570/hwinit
From: Pavel Pisa
Generated header file ti_herc/reg_spi.h contains complete registers
and fields set for Ti MibSPI peripheral.
Care has to be taken that only TMS570_SPI1, TMS570_SPI3 and TMS570_SPI5
are of this complete multibuffer type. TMS570_SPI2 and TMS570_SPI4
have substantial part of
From: Pavel Pisa
The code introduces initialization algorithms bases on Ti HalCoGen
generated files. The most of the code has been rewritten to use
RTEMS much more complete header files. This allowed to replace most
of the hardcoded hexadecimal values by appropriate fields macros documenting
how
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
1 - 100 of 389 matches
Mail list logo
