Re: [PATCH 01/25] score: Add Blackfin CPU architecture group

[Sebastian Huber]

On 30/03/2019 00:12, Chris Johns wrote:

Hi,

Thank you for these changes. It is nice to see doxygen support being improved.

Could I please suggest the first line of the commit message has `doxygen` in it,
such as 'doxygen: score: Add Blackfin CPU architecture group' so a compact git
log report of just the first line indicates the patch is only doxygen? The
message for this patch could mean a few things and for someone new to the code
base it could mean anything.


I checked in the patch set and we added a "doxygen: " to the commit 
messages. I still work on an update of the Doxygen recommendations. The 
basic plan is to get the groups in order first. In a second step, all 
files should be assigned to a group.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019

[Sebastian Huber]

On 02/04/2019 07:28, Vaibhav Gupta wrote:
I had this discussion under comments section in my drafted proposal. 
Aditya said we will be using the Version control, they are using, to 
figure out the origin of file.


It is much easier to work with the Git mirrors if you want to track the 
upstream. You can use the commit date as a version system independent 
datum to record the file version.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019

[Vaibhav Gupta]

I had this discussion under comments section in my drafted proposal. Aditya
said we will be using the Version control, they are using, to figure out
the origin of file.

On Tue, 2 Apr, 2019, 10:24 AM Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/04/2019 05:44, Vaibhav Gupta wrote:
> > - getting familiar with SVN (for FreeBSD) and CVS (for NetBSD).
>
> Both project have Git mirrors. I would use them.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] bsps/riscv: HTIF - Use 32-bit HTIF syscalls on RV32

[Sebastian Huber]

On 31/03/2019 16:33, Hesham Almatary wrote:

+static ISR_lock_Control htif_lock;
+static ISR_lock_Context htif_lock_context;


The lock context must be unique for each caller, so please use a stack 
variable for it. Please use the rtems_interrupt_lock_* API and not the 
internal API.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019

[Sebastian Huber]

On 02/04/2019 05:44, Vaibhav Gupta wrote:
- getting familiar with SVN (for FreeBSD) and CVS (for NetBSD). 


Both project have Git mirrors. I would use them.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2019

[Vaibhav Gupta]

Hello,
.
I am not able to get much active on devel these days as my mid-semester
exams are going on (April 1-6). I have already mentioned this in my
proposal under the heading, "Conflict of Interests".
.
My proposal- ​
https://docs.google.com/document/d/1NLbcFdHwWTEAismvz0E_C07Oos_4p6Y3IRGcE8fugSg/edit?usp=sharing

.
But I am doing my daily homework for GSoC, reading about:
- porting codes from FreeBSD and NetBSD.
- writing architecture specific codes.
- getting familiar with SVN (for FreeBSD) and CVS (for NetBSD).
- Aditya gave few suggestions on my proposal and provided me with some
resources, read them too.
.
I am giving 2.5-3 hours daily during my examination period.
.
It would be great if I can get more feedback and suggestions for my
proposal.
.
.
Thanks
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Proposal : BeagleBoard project

[Chris Johns]

On 2/4/19 12:06 am, Sebastian Huber wrote:
> On 31/03/2019 03:57, Chris Johns wrote:
>> On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
>>> On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom >> > wrote:
>>>
>>>  Remember you can submit your "Final" proposal many times on GSoC site.
>>>  I made a few comments just regarding the 'public' view of your
>>>  project. I think the technical plan looks reasonable, and leave it to
>>>  the potential mentors to steer your technical path.
>>>
>>>  Gedare
>>>
>>> Thank you for reviewing the proposal. I have made the changes according to 
>>> the
>>> comments and also have uploaded the final proposal in the summer of code 
>>> site.
>> How will this be tested?
>>
>> Is https://github.com/littlevgl/lvgl  of any value?
> 
> This looks like a really nice graphics library for RTEMS. How did you find 
> this
> one?

I did not, a client did and we are using it on an embedded Linux box with a
small DVI LCD display. It says it is for small devices and it looked to me like
a good fit for RTEMS.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

Doing a make for all, I'm getting this not found error ...

make: freebsd-org/contrib/libpcap/gen_version_header.sh: Command not found
make: *** [Makefile.todo:277: freebsd/contrib/libpcap/pcap_version.h] Error
127
.

But it successefully builds the .m files into .c and .h files (I haven't
edited the Makefile yet).
after the make, if I try to ./waf it, it gives this error ...
==
In file included from ../../rtemsbsd/include/machine/bus.h:781:0,
 from ../../rtemsbsd/include/machine/_bus.h:1,
 from ../../freebsd/sys/sys/bus.h:35,
 from ../../rtemsbsd/local/usb_if.c:17:
../../rtemsbsd/include/machine/bus_dma.h:44:2: error: #error "the header
file  must be included first"
 #error "the header file  must be
included first"
  ^
../../rtemsbsd/local/usb_if.c:18:10: fatal error: usb_if.h: No such file or
directory
 #include "usb_if.h"
  ^~
compilation terminated.

==
it seems like it's not changing it to #include .
Is it supposed
to be done manually by opening each file or am I missing a script?

On Mon, Apr 1, 2019 at 7:32 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:
>
> [...] (I removed some of the discussion to make it more readable)
>
> >
> > If you use the fb and framebuffer headers from RTEMS, you will get an
> > RTEMS interface. The RTEMS based console code will work fine. But it
> > might would be the solution where more work is necessary to port
> other
> > applications or libraries. It seems that we have some libs already
> (like
> > nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would
> be OK
> > with that.
> >
> > The other alternative would be to use the FreeBSD code that does the
> > same. I'm not sure whether they call it framebuffer or something
> else.
> > But I would expect that there is something similar. In that case it
> > might would be simpler to port graphics libraries that already work
> on
> > FreeBSD.
> >
> > Both ways could be nice. I'm really not sure which one I would
> prefer.
> > The first one is better integrated into the existing RTEMS ecosystem.
> > The second one promises a wider world. So either take the one that
> > interests you more or just use the one that looks simpler ;-)
> >
> > I will take the 2nd path and use the codes from freebsd fb. In the
> > forked branch
> > I have imported them along with the iic souce files just to make sure
> > that it builds.
> > I have also added the driver references in the nexus-device.h
> > I have a few questions/doubts before moving on to creating a fresh
> > branch to import
> > the file cleanly so that porting work can be started.
> >
> > There are a lot of files that are imported and out of them some were .m
> > files that
> > I built manually with the awk scripts and imported using the libbsd.py .
> > It seems like those
> > will need a cleanup and will need to be added to the Makefile.todo (?)
>
> Most likely Makefile.todo is currently the right place. Also in long
> term it should move to waf. But that's out of the scope of your project.
>
> >
> > Will the whole thing be one big patch? or will it be done in chunks of
> > the subdirectory
> > like videomode headers and souce imported in one patch, fb in another ?
>
> I think I already have made a note at your proposal: I would suggest to
> split it up in smaller functional blocks. That even allows to merge
> small parts during the GSoC instead of having one big block at the end.
> But please note that all parts should be useful and every commit in
> libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
> `git bisect` won't work.
>
> So if you have functional groups: Split it up. If a big block is
> necessary because the small parts can't work on their own: Keep it in
> one import + one port commit.
>
> >
> [...]
>
>
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

On 4/1/2019 9:45 AM, Joel Sherrill wrote:
> On Mon, Apr 1, 2019 at 7:54 AM Jeff Kubascik  > wrote:
> 
> On 3/28/2019 8:00 AM, Sebastian Huber wrote:
> > Hello Jeff,
> >
> > On 27/03/2019 19:11, Jeff Kubascik wrote:
> >> Hello,
> >>
> >> I am interested in porting RTEMS to run as a Xen guest on our distro 
> for the
> >> Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM Cortex-A53 
> processor,
> which
> >> is based on the ARMv8 architecture.
> >>
> >> I have noticed that RTEMS already runs on a few Zynq 7000 boards.
> However, those
> >> are using the Cortex-A9 processor, which is based on the ARMv7 
> architecture.
> >> Looking at the source code, I didn't see any ARMv8 cpu code.
> >>
> >> I was curious if there has been any work done to port RTEMS to an 
> ARMv8 based
> >> platform?
> >
> > AArch64 is a completely new architecture port. I think nobody is working
> > on that. We may work on AArch32 support for the Zynq UltraScale+ this 
> year:
> >
> > http://devel.rtems.org/ticket/3682
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax     : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> 
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> 
> Sebastian,
> 
> We were able to hack up the xilinx-zynq BSP to get it running on the 
> Ultra96 in
> AArch32 mode. Surprisingly, it didn't require too many code changes. Our 
> key
> findings were
> 
> - Set the CP15BEN bit in the SCTLR register to enable legacy memory 
> barrier
> system instructions. This is used in the arm-cp15 cache operations.
> - Clear the TRE bit in the SCTLR register to disable TEX remap. This was 
> causing
> the page table attributes to show up as strongly ordered, resulting in an
> unaligned memory exceptions in the newlib memcpy.
> - Update peripheral addresses, IRQs, clock rates to match the MPSoC.
> - Update the MMU peripheral region mappings.
> - Change the system clock source to clock-generic-timer.
> - Change the cache implementation to cache-cp15.
> 
> With the above changes, we are able to run all the applications under the
> testsuites/samples directory on the Ultra96 via JTAG boot.
> 
> Over the weekend, I started putting together a new xilinx-zynqmp BSP 
> layer to
> support the Xilinx UltraScale+ MPSoC platform, including the Ultra96 
> development
> board. If the RTEMS community is interested in these patches, we are 
> looking to
> submit them later in the week.
> 
> 
> Cool! Sounds of interest.
> 
> This sounds like it would be a variant on the existing xilinx 32-bit BSP. 
> Right?
> Most of the code is unchanged but some conditionals.
> 
> Were there changes outside the BSP?
> 
> If strictly BSP, then it needs a name and then could be a variant of the 
> existing 
> BSP. That basically boils down to a config/*.cfg file with the BSP variant 
> name, 
> some mods to configure.ac  to give you an automake 
> variable
> to switch the timer 
> to clock-generic-time in the Makefile.am, and something to trip the various 
> ifdef's
> on. 
> 
> Then some instructions in the Users Guide on how you ran it.
> 
> Of course, that's if I am understanding the magnitude of the change.
> 
> 
> -Jeff Kubascik
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 

Yes, all the changes are located inside the BSP layer. However, the Zynq 7000
and the Zynq UltraScale+ MPSoC are notably different platforms, enough that I
believe to warrant a new BSP layer.

Differences include
- System addresses are completely different
- Interrupt numbers are completely different
- Cortex-A53 versus Cortex-A9 - this is why I had to change the timer and cache
implementations
- With the MPSoC, power and reset control is performed by a separate PMU 
processor

There is still some overlap, for instance both platforms use the same UART
controllers. I'm thinking this could be brought out to bsps/arm/shared/serial.

-Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:

[...] (I removed some of the discussion to make it more readable)

> 
> If you use the fb and framebuffer headers from RTEMS, you will get an
> RTEMS interface. The RTEMS based console code will work fine. But it
> might would be the solution where more work is necessary to port other
> applications or libraries. It seems that we have some libs already (like
> nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would be OK
> with that.
> 
> The other alternative would be to use the FreeBSD code that does the
> same. I'm not sure whether they call it framebuffer or something else.
> But I would expect that there is something similar. In that case it
> might would be simpler to port graphics libraries that already work on
> FreeBSD.
> 
> Both ways could be nice. I'm really not sure which one I would prefer.
> The first one is better integrated into the existing RTEMS ecosystem.
> The second one promises a wider world. So either take the one that
> interests you more or just use the one that looks simpler ;-)
> 
> I will take the 2nd path and use the codes from freebsd fb. In the
> forked branch 
> I have imported them along with the iic souce files just to make sure
> that it builds.
> I have also added the driver references in the nexus-device.h 
> I have a few questions/doubts before moving on to creating a fresh
> branch to import
> the file cleanly so that porting work can be started.
> 
> There are a lot of files that are imported and out of them some were .m
> files that 
> I built manually with the awk scripts and imported using the libbsd.py .
> It seems like those 
> will need a cleanup and will need to be added to the Makefile.todo (?) 

Most likely Makefile.todo is currently the right place. Also in long
term it should move to waf. But that's out of the scope of your project.

> 
> Will the whole thing be one big patch? or will it be done in chunks of
> the subdirectory
> like videomode headers and souce imported in one patch, fb in another ?

I think I already have made a note at your proposal: I would suggest to
split it up in smaller functional blocks. That even allows to merge
small parts during the GSoC instead of having one big block at the end.
But please note that all parts should be useful and every commit in
libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
`git bisect` won't work.

So if you have functional groups: Split it up. If a big block is
necessary because the small parts can't work on their own: Keep it in
one import + one port commit.

> 
[...]



-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Joel Sherrill]

On Mon, Apr 1, 2019 at 7:54 AM Jeff Kubascik 
wrote:

> On 3/28/2019 8:00 AM, Sebastian Huber wrote:
> > Hello Jeff,
> >
> > On 27/03/2019 19:11, Jeff Kubascik wrote:
> >> Hello,
> >>
> >> I am interested in porting RTEMS to run as a Xen guest on our distro
> for the
> >> Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM Cortex-A53
> processor, which
> >> is based on the ARMv8 architecture.
> >>
> >> I have noticed that RTEMS already runs on a few Zynq 7000 boards.
> However, those
> >> are using the Cortex-A9 processor, which is based on the ARMv7
> architecture.
> >> Looking at the source code, I didn't see any ARMv8 cpu code.
> >>
> >> I was curious if there has been any work done to port RTEMS to an ARMv8
> based
> >> platform?
> >
> > AArch64 is a completely new architecture port. I think nobody is working
> > on that. We may work on AArch32 support for the Zynq UltraScale+ this
> year:
> >
> > http://devel.rtems.org/ticket/3682
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
>
> Sebastian,
>
> We were able to hack up the xilinx-zynq BSP to get it running on the
> Ultra96 in
> AArch32 mode. Surprisingly, it didn't require too many code changes. Our
> key
> findings were
>
> - Set the CP15BEN bit in the SCTLR register to enable legacy memory barrier
> system instructions. This is used in the arm-cp15 cache operations.
> - Clear the TRE bit in the SCTLR register to disable TEX remap. This was
> causing
> the page table attributes to show up as strongly ordered, resulting in an
> unaligned memory exceptions in the newlib memcpy.
> - Update peripheral addresses, IRQs, clock rates to match the MPSoC.
> - Update the MMU peripheral region mappings.
> - Change the system clock source to clock-generic-timer.
> - Change the cache implementation to cache-cp15.
>
> With the above changes, we are able to run all the applications under the
> testsuites/samples directory on the Ultra96 via JTAG boot.
>
> Over the weekend, I started putting together a new xilinx-zynqmp BSP layer
> to
> support the Xilinx UltraScale+ MPSoC platform, including the Ultra96
> development
> board. If the RTEMS community is interested in these patches, we are
> looking to
> submit them later in the week.
>

Cool! Sounds of interest.

This sounds like it would be a variant on the existing xilinx 32-bit BSP.
Right?
Most of the code is unchanged but some conditionals.

Were there changes outside the BSP?

If strictly BSP, then it needs a name and then could be a variant of the
existing
BSP. That basically boils down to a config/*.cfg file with the BSP variant
name,
some mods to configure.ac to give you an automake variable to switch the
timer
to clock-generic-time in the Makefile.am, and something to trip the various
ifdef's
on.

Then some instructions in the Users Guide on how you ran it.

Of course, that's if I am understanding the magnitude of the change.


> -Jeff Kubascik
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Thu, Mar 21, 2019 at 10:21 PM Christian Mauderer 
wrote:

> Am 21.03.19 um 15:36 schrieb Vijay Kumar Banerjee:
> >
> > On Wed, 20 Mar 2019 at 01:52, Christian Mauderer  > > wrote:
> >
> > Am 19.03.19 um 20:37 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > >
> > > On Tue, 19 Mar 2019 at 02:44, Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> > > >
> > > >
> > > >
> > > > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> > > > mailto:vijaykumar9...@gmail.com>
> > >
> > >  >   >  > > wrote:
> > > >
> > > >
> > > > Hi Christian,
> > > >
> > > > (it got sent by mistake :) )
> > > >
> > > > Thanks for telling about the script, now I have the code
> > imported and
> > > > it's building successfully.
> > > > I have forked the repo and created a branch with my commits.
> > > Please have
> > > > a look and see if
> > > > It's going in the right direction.
> > > > https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer
> > > >
> > > > I have also wrote a first draft of the proposal. Are we
> supposed
> > > to send
> > > > the draft proposals only after the the application period
> stars?
> > > or can
> > > > we just share it offlist with the mentors now?
> > > >
> > > > Thanks
> > >
> > > Hello Vijay,
> > >
> > > first regarding the proposal:
> > >
> > > @Joel: Please correct me if I'm wrong!
> > >
> > > I think it should be OK to discuss the proposal as soon as you
> > have
> > > something. I assume you already have completed the Hello world
> > and sent
> > > it to at least one of our Org Admins?
> > >
> > > I have sent pictures in the offlist thread with Joel and you,
> where we
> > > were dicussing the
> > > hardwares. I can send again in an offlist thread, along with the
> > > proposal. :)
> > >
> >
> > If Joel has them, it's OK.
> >
> > >
> > > Regarding the code:
> > >
> > > Although the commits need some polishing (see * at the end) it
> > looks
> > > like a good start that you were already able to import and
> > compile some
> > > of the necessary files.
> > >
> > > From what I've seen, you currently pulled in three parts:
> > >
> > > 1. Some part of videomode. There are some awk scripts in that
> > directory
> > > too so some generated files might need some processing.
> > >
> > > the ediddevs and modelines.c needed the scripts. I added them and
> > > imported, but
> > > there's a strange error with modelines.c
> > > (If I comment it out, it builds fine)
> > > ===
> > > ../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected
> > > declaration specifiers or '...' before string constant
> > >  __KERNEL_RCSID(0, "$NetBSD$");
> > >  ===
> > >
> >
> > Most likely it's necessary to import them sooner or later. It will be
> > necessary to take a look at the original make process in FreeBSD and
> > duplicate the steps. For other awk scripts that's done in the
> > Makefile.todo.
> >
> > >
> > > 2. The iic headers. That looks good. An RTEMS implementation
> > for the
> > > functions most likely is necessary.
> > >
> > > I have added this in the proposal.
> >
> > Great.
> >
> > >
> > > 3. The driver for the chip that converts from the LCD
> > interface to an
> > > HDMI interface. That's good and necessary too.
> > >
> > > What is missing (which is entirely OK at the current phase)
> > are the
> > > following parts:
> > >
> > > A. The LCD controller driver itself (am335x_lcd.c, ...).
> > >
> > > Added. Along with it, I had to import other fb codes that it
> > depends on.
> > > I can push it in my
> > > forked branch for you to see.
> > > Since it has already seen some trial and errors. I think it would
> be
> > > better to create a new
> > > branch after we're happy with what's imported, then we can squash
> > it all
> > > into a commit
> > > and then start the porting work to get two clean commits.
> >
> > If you haven't forgotten the files everything is OK. It's totally OK
> to
> > do some trial and error to find out what's necessary. You can do a
> clean
> > 

Re: GSoC Proposal : BeagleBoard project

[Sebastian Huber]

On 31/03/2019 03:57, Chris Johns wrote:

On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:

On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom mailto:ged...@rtems.org>> wrote:

 Remember you can submit your "Final" proposal many times on GSoC site.
 I made a few comments just regarding the 'public' view of your
 project. I think the technical plan looks reasonable, and leave it to
 the potential mentors to steer your technical path.

 Gedare

Thank you for reviewing the proposal. I have made the changes according to the
comments and also have uploaded the final proposal in the summer of code site.

How will this be tested?

Ishttps://github.com/littlevgl/lvgl  of any value?


This looks like a really nice graphics library for RTEMS. How did you 
find this one?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

On 3/28/2019 8:00 AM, Sebastian Huber wrote:
> Hello Jeff,
> 
> On 27/03/2019 19:11, Jeff Kubascik wrote:
>> Hello,
>>
>> I am interested in porting RTEMS to run as a Xen guest on our distro for the
>> Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM Cortex-A53 processor, 
>> which
>> is based on the ARMv8 architecture.
>>
>> I have noticed that RTEMS already runs on a few Zynq 7000 boards. However, 
>> those
>> are using the Cortex-A9 processor, which is based on the ARMv7 architecture.
>> Looking at the source code, I didn't see any ARMv8 cpu code.
>>
>> I was curious if there has been any work done to port RTEMS to an ARMv8 based
>> platform?
> 
> AArch64 is a completely new architecture port. I think nobody is working
> on that. We may work on AArch32 support for the Zynq UltraScale+ this year:
> 
> http://devel.rtems.org/ticket/3682
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 

Sebastian,

We were able to hack up the xilinx-zynq BSP to get it running on the Ultra96 in
AArch32 mode. Surprisingly, it didn't require too many code changes. Our key
findings were

- Set the CP15BEN bit in the SCTLR register to enable legacy memory barrier
system instructions. This is used in the arm-cp15 cache operations.
- Clear the TRE bit in the SCTLR register to disable TEX remap. This was causing
the page table attributes to show up as strongly ordered, resulting in an
unaligned memory exceptions in the newlib memcpy.
- Update peripheral addresses, IRQs, clock rates to match the MPSoC.
- Update the MMU peripheral region mappings.
- Change the system clock source to clock-generic-timer.
- Change the cache implementation to cache-cp15.

With the above changes, we are able to run all the applications under the
testsuites/samples directory on the Ultra96 via JTAG boot.

Over the weekend, I started putting together a new xilinx-zynqmp BSP layer to
support the Xilinx UltraScale+ MPSoC platform, including the Ultra96 development
board. If the RTEMS community is interested in these patches, we are looking to
submit them later in the week.

-Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel