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%)
> > >
> > > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> Ok. Any suggestions for a directory name? :)
I am not in the full sync and I have lost the tracks where
are all RTEMS LwIP repo copies.
Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
If it is that way then LwIP uses practice to put integration
stuff into "ports" directory so I would leave the structure
under LwIP as it is
ports/os/rtems/arch/sys_arch.c
Or if you want to somehow separate sources into more repos
then possible but would complicate keep the drivers and targets
in a sync in future. I am losing tracks of the build tools etc...
I hope that when it settles the simple instructions
would be added on the integration page
https://devel.rtems.org/wiki/Packages/LWIP
If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
then it should be something like
rtems-support/ports/os/rtems/arch/sys_arch.c
if the code can be used over all RTEMS targets. Which should be
a goal anyway and I have initiated it such way years ago.
But I am not sure why to not let code in the actual
lwip/ports/drivers together as well. I see that
in devel branch is the most of our TMS570 code wiped
out... hmm.. why. There is
lwip/ports/drivers/bbb
this location seems to me as OK.
In the suggested changes is
{lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
I agree with move of all TMS570 specific code under
/ports/driver/tms570_emac
Again if all these shuffles are done only for some license changes
I would prefer to be noticed and I think that I would not be blocked
by any of my former studnets nor the faculty to relicense code.
I would inform the faculty (where I am only left from former group,
where I have lead part of this development, part was at my company)
as well as students.
I would prefer if real developer names who invested time into work
are included at least as Authors in the files but the copyright can
be moved to RTEMS foundation or whatever.
But as I have said I have lost track and hope that stuff will survive
in some form till the time when I have some free time or studnet
to work on the project as his/her theses, GSoC etc...
I have used the code with external OMK make, I agree that this
is not right way forward but I wait for outcome of these who
have more experience with RSB and related tools and propose
integration.
Best wishes,
Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote:
> Hi Vijay and Kinsey,
>
> I monitor from distance LwIP for RTEMS progress and I am happy
> for that and when the code settles and I find a time,
> I try to test it with TMS570. But I have notices next moves
>
> On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> >
> > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> please do not use uLAN for directory name inside LwIP.
> uLAN is our RS-485 communication protocol project
> and it includes sysless (bare hardware integration layer)
> as well as others for RTEMS, NuttX, GNU/Linux.
> And LwIP is used as subproject inside our larger projects.
> Yes, project is used as base for more our project even
> unrelated to RS-485 but that is historical relict
> and should not propagate into RTEMS.
>
> But there is no reason to keep uLAN in the name.
> These parts which I have written myself or has been
> writtent by Roman Bartosinski under my company
> (PiKRON) and colleague Alvat.cz funding acan be
> relicensed under any RTEMS compatible preferred license.
> Only me and Roman needs to agree on that and I do not
> see that as a problem. So do not put there uLAN name.
> This RTEMS specific integration should stay in some
> RTEMS specific LwIP subdirectory or can be even included
> into RTEMS mainline. But please, do not add there uLAN
> name nor OMK (our makesystem abbreviation).
>
Ok. Any suggestions for a directory name? :)
--joel
> 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/
> company:https://www.pikron.com/
> personal: http://cmp.felk.cvut.cz/~pisa
> projects: https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Vijay and Kinsey,
I monitor from distance LwIP for RTEMS progress and I am happy
for that and when the code settles and I find a time,
I try to test it with TMS570. But I have notices next moves
On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> rename {lwip => uLan}/ports/os/lwipopts.h (100%)
>
> > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
please do not use uLAN for directory name inside LwIP.
uLAN is our RS-485 communication protocol project
and it includes sysless (bare hardware integration layer)
as well as others for RTEMS, NuttX, GNU/Linux.
And LwIP is used as subproject inside our larger projects.
Yes, project is used as base for more our project even
unrelated to RS-485 but that is historical relict
and should not propagate into RTEMS.
But there is no reason to keep uLAN in the name.
These parts which I have written myself or has been
writtent by Roman Bartosinski under my company
(PiKRON) and colleague Alvat.cz funding acan be
relicensed under any RTEMS compatible preferred license.
Only me and Roman needs to agree on that and I do not
see that as a problem. So do not put there uLAN name.
This RTEMS specific integration should stay in some
RTEMS specific LwIP subdirectory or can be even included
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 namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC - CAN driver for BBB Was: CAN Options and Licensing, Testing, etc
Hello Prashanth,
On Thursday 14 of April 2022 20:20:45 Prashanth S wrote:
> This is to summarize the things suggested from the discussions and clarify
> on CAN generic APIs.
>
> Things on the plate:
>
>- CAN driver for BBB.
OK
>- CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on
>x86, Zynq UltraScale+ MPSo on QEMU).
usesfull for testing
>- Generic CAN APIs
yes
>- ADC driver (not using libbsd) for BBB.
it is my opinion, may it be somebody else should express his/her
from other perspective.
> Please correct me if I missed out anything.
> Query on CAN generic APIs:
> With my understanding on the discussions, Should I use the mentioned stacks
> (LinCAN, CANOpen) as reference
CANopen is higher layer, not relevant for the low level code and should
be possible to build above any of the drivers.
LinCAN not strict, may be only some inspiration
> and define the data structures (CAN message header and CAN message
> structures) or port one of the stacks (In case port one of the stacks is
> the right option:
I would suggest to go through CAN message structures of the existing
projects and use one of them or define one which is easy to use
and port. I would help. I do not suggest unsigned long for ID as it is
in LiNCAN for example. I suggest uint32_t.
> From the suggestions given in the discussions, I could not conclude which
> stack to choose, Considering the future Scalability (both software stack
> and CAN protocol features) and portability) to RTEMS.
The minimal driver can be directly based on MPC5200 direct use
of rtems_message_queue(s), one for Rx and one for Tx
https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan
Its message format there
https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/include/bsp/mscan.h
Again problematic uint16_t mess_id; which prevents compatability
with extended message format.
I suggest some single bigger unsigned type used with masks for RTR,
EXT and futire BRS and CAN FD flags, flags.
uint8_t mess_rtr; is not extensible.
It would be great to find if somebody is actually using MPC5200 RTEMS BSP
still and in such case negotiate changes with them. May it be GrLib
unification could be usesfull as well.
I look at
https://git.rtems.org/rtems/tree/bsps/include/grlib/grcan.h#n133
/* CAN-FD MESSAGE */
typedef struct {
uint8_t extended; /* 1= Extended Frame (29-bit id), 0= STD Frame
(11-bit id) */
uint8_t rtr; /* RTR - Remote Transmission Request */
uint8_t fdopts; /* Bit1: 1=Switch bit rate. bit2: 1=FD frame. */
uint8_t len; /* 0-8, 12, 16, 20, 24, 32, 48 or 64 bytes */
uint32_t id;
union {
uint64_t dwords[8]; /* up to 64 bytes if FD=1 and len>8 */
uint8_t bytes[64]; /* up to 64 bytes if FD=1 and len>8 */
} data;
} CANFDMsg;
This messageformat look acceptable. The first uint8_t forms in the fact
aligned unit32_t. I would personally put extended, rtr and fdopts
into single masked integer, but this is acceptable. Missing is space
for 16-bit or better at least 32-bit timestamp.
As for the infrastructure/stack, I would prefer to prepare code
for multiple prioritized queues and LinCAN and SocketCAN
provides. But as I have mentioned simple RTEMS queues can be used
for initial proof and change later to something with more
functions would not be problem if API is designed such way,
that it does not need to be changed.
I offer co-mentor role or possibly even mentor but I would not have
time over 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 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
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu
Dear Kamlesh, On Friday 15 of April 2022 06:50:44 Kamlesh Bharodiya wrote: > I am looking for mentors for my project. How can I connect to interested > mentors? I have uploaded the draft proposal on GSoC tracking page. I have long time interrest in RTEMS running on TMS570LC4357 which is Arm Cortex-R5F based. I have TMDX570LC43HDK at home and some smaller boards are at Elktroline.cz. As I know, the Cortex-R5 core is already supported by RTEMS and our TMS570LS3137 BSP has been used with TMS570LC4357 chips by Frankfurt University https://www.rz.uni-frankfurt.de/65100666/dcs Relevant repository https://github.com/jalmito/rtems It would worth to get mainline TMS570 BSP compatible with both chips. But back to your project, possibility to run RTEMS on Cortex-R5 architecture in QEMU would be usesfull for testing. My search through actual QEMU sources confirms Cortex-R support and only in Cortex-R5 and Cortex-R52 variants and only integration on ZCU102. But support of Cortex-R5 comprocessor on "big" Xilinx platforms can be usesfull. I have helped with bought of these boards years ago but for the team which moved away. But I probably can find even somebody with HW who could test the code. The minimal set of the peripherals supported to make port usable and living needs to include GIC (generic interrupt controller), TTC (system timer) and UART (serial port). Other option is some mailbox based exchange with main Cortex-A CPU. Have you some experience with 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, 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 projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
